<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2012-12-31, at 4:26 PM, Rico Moorman <<a href="mailto:rico.moorman@gmail.com">rico.moorman@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello Bob and Mike,<div><br></div><div>Reading a little within the suggested book I came across the following statement.</div><div><br></div><div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We should first examine the merits and limitations of the traditional approach: using<br>functions as a basis for the architecture of software systems. This will not only lead us to<br>appreciate why we need something else — object technology — but also help us avoid,<br>
when we do move into the object world, certain methodological pitfalls such as premature<br>operation ordering, which have been known to fool even experienced O-O developers.</blockquote></div><div><br></div><div>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?</div></blockquote><div><br></div>He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language.</div><div><br></div><div>Cheers,</div><div>Bob</div><div><br><blockquote type="cite">
<div><br></div><div>Thank you very much in advance.</div><div><br></div><div>Best regards,</div><div><br></div><div>Rico Moorman</div><div><br><div class="gmail_quote">On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison <span dir="ltr"><<a href="mailto:hutch-lists@recursive.ca" target="_blank">hutch-lists@recursive.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <<a href="mailto:dhelta.diaz@gmail.com" target="_blank">dhelta.diaz@gmail.com</a>> wrote:<br>
<br><blockquote type="cite">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.<br>
<br>So my questions for you all are:<br><br>* Is it really worthwhile for me to learn OO-programming?<br></blockquote><br></div>Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.<br>
<br>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.<br>
<br>I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.<br><br>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 :-)<br>
<br>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.<div class="im"><br><br><blockquote type="cite"><br>* 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".<br>
<br>* Is it true that learning other programming languages leads to a better use of your favorite programming language?<br></blockquote><br></div>That's been my experience. And it'll be harder to name your favourite language too.<div class="im">
<br><br><blockquote type="cite"><br>* Will I learn new programming strategies that I can use back in the Haskell world?<br></blockquote><br></div>Probably.<br><br>Cheers,<br>Bob<br><br><blockquote type="cite"><div class="im">
<br>Thanks in advance for your kind responses,<br>Daniel Díaz.<br></div><div class="im">_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br></div></blockquote><br><br></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></body></html>