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?

Thank you very much in advance.

Best regards,

Rico Moorman

On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison <hutch-lists@recursive.ca> wrote:
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <dhelta.diaz@gmail.com> wrote:

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.

I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.

C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)

Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.



* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

That's been my experience. And it'll be harder to name your favourite language too.



* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers,
Bob


Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe