[Haskell-cafe] Object Oriented programming for Functional Programmers

[wren ng thornton]

On 12/31/12 4:26 PM, Rico Moorman wrote:
> Hello Bob and Mike,
>
> Reading a little within the suggested book I came across the following
> statement.
>
>> We should first examine the merits and limitations of the traditional
>> approach: using
>> functions as a basis for the architecture of software systems. This will
>> not only lead us to
>> appreciate why we need something else — object technology — but also help
>> us avoid,
>> when we do move into the object world, certain methodological pitfalls
>> such as premature
>> operation ordering, which have been known to fool even experienced O-O
>> developers.
>
> Because you both have more experience with this piece of literature, how
> would you interpret it? With a grain of salt or would function really mean
> procedure from the viewpoint of the author?

I'm not Bob nor Mike, and haven't read the text in question, but when 
you encounter "function" in most any imperative or OO setting, it almost 
certainly means a first-order procedure. No mathematical functions. No 
higher-order thingamabobs that you can pass to or return from other 
thingamabobs. Just an address in code with an expected stack frame 
configuration associated with it.


As for learning object orientation, I'd second the suggestion of 
Smalltalk. I'll leave the religious wars aside, but "OOP" means very 
different things to very different people. Most people use the term 
whilst referring to C++ and Java, but most people recognize that the 
ideological framework is best attained by Smalltalk (and related 
languages like Ruby). So, if you're interested in learning the ideology, 
then Smalltalk is a great place to get it.

Also, Smalltalk has the "become" method, which is amazing magic.

-- 
Live well,
~wren