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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
