3 ms·

If you're exempting Smalltalk from your generalizations about OO, then your observations probably aren't even about OO so much as the fallout from C++ and Java'

If you're exempting Smalltalk from your generalizations about OO, then your observations probably aren't even about OO so much as the fallout from C++ and Java's attempted graft of it onto C. That's like exempting Haskell from generalizations about functional programming. OO systems can be simple and incredibly useful when solving some problems (without needing tremendous amounts of boilerplate code), but many things claiming to use OOP are doing so for buzzword-compliance. You can, of course, write good OO code in C++ and Java (or even C), but many people working in them do not understand OO design very well (overusing inheritance is especially common), and you will have to write complex and verbose workarounds for fundamental differences in language semantics (e.g. the lack of Smalltalk-style blocks, C-style static typing's requirement for explicit casts). If you want to understand OO, look at Smalltalk (_Smalltalk-80_ is a good book). Post-Smalltalk prototype-oriented languages such as Io (http://www.iolanguage.com/ http://www.iolanguage.com/) and Self (http://research.sun.com/self/language.html http://research.sun.com/self/language.html) also have numerous interesting ideas in them* , but writings about them generally assume familiarity with Smalltalk. Also, read Alan Kay. Whether or not you agree with his conclusions, he writes lucidly about many language design issues. My favorite OO example from Smalltalk is that the language doesn't need a primitive for "if", you just pass an object that calls one of two blocks, depending on whether it receives true or false. A Smalltalk block, by the way, is an anonymous function which is not evaluated until its result is needed. Sound familiar? :) * Prototype-based programming is also easily done in Javascript and Lua, FWIW. Steve Yegge is big on the former (http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html http://steve-yegge.blogspot.com/2008/10/universal-design-pat...), I prefer the latter.

gruseom 18y ago
Note: I mostly wrote the following before I had my coffee. Consider yourself warned :) your observations probably aren't even about OO I programmed professionally in OO for years, have trained many people in OO design and domain modeling, and know what the fuck I am talking about. I know what Smalltalk blocks are, I know what Smalltalk "if" is, and I happen to have read Alan Kay, which you might have seen had you read my post properly instead of just dumping out a pile of predigested tutorial boilerplate. My critique of OO comes from struggling to build serious production systems with it, not from programming language parlor games. exempting Smalltalk from your generalizations about OO ... [is] like exempting Haskell from generalizations about functional programming No, it's not. Kay coined the term OO, but it hasn't meant what he meant by it for a long time. I'm talking about OO in the sense that the overwhelming majority of people now understand it: roughly, the organization of programs into classes that bundle state and behavior in ways that attempt to model the problem domain. Whatever makes Smalltalk great, it isn't this, as the subsequent history of OO makes clear. People thought that this was the contribution of Smalltalk and they tried to abstract the paradigm out and improve on it - but what really happened is they threw the baby out with the bathwater, and now we have static bathwater. I have a hunch this is because they paid too much attention to the Simula strain in Smalltalk and not enough to the Lisp one (http://news.ycombinator.com/item?id=288786 http://news.ycombinator.com/item?id=288786). Had they listened to Alan Kay they wouldn't have made this mistake; there's no question which he emphasizes more. OO systems can be simple and incredibly useful when solving some problems (without needing tremendous amounts of boilerplate code) Anything is simple and useful when you're working on a simple problem. What matters is how it works on complex problems. The claim made about OO for a generation now is that it helps to build complex systems, and this mantra has been repeated and taught so often that most people just believe it. It's not true. In my experience, you do typically end up needing tremendous amounts of boilerplate code when working that way (whether or not you see it as such is a different matter). Worse, your system starts to fight itself because the way you need to organize it over here doesn't work over there, and so on; time to factor out the code you need into a static "utility" class - poof, there just went your OO paradigm. Ultimately, I'm exempting Smalltalk from my critique because of the respect I have for the Smalltalk programmers I know, who can't possibly only be doing OO in the majoritarian sense. I haven't used Smalltalk enough myself to have a clear idea of what they're really doing, and Bob Dylan said not to criticize what you don't understand. I'm not, however, exempting CLOS, which I have used enough to experience several of the limitations I'm talking about, enough so that I don't bother with it anymore. Perhaps that will persuade you that I'm talking about more than C++ and Java?
- silentbicycle 18y ago
  First, I saw that you said that you have read Alan Kay, but I'm speaking to the general discussion audience. And, ok, you know what you're talking about; I'm used to reading people who think that all OO systems necessarily suffer from the same problems as e.g. C++'s, and, not knowing your programming history, had few impressions to the contrary based strictly on what you said. Nothing personal. Be civil, have your coffee. > What matters is how it works on complex problems. Agreed. I don't believe pure-OO (or pure-FP, pure-declarative, etc.) is an ideal approach for anything. OOP is a technique that works well for some problems, and is best understood so you can use it when it is a good fit. I think that the best way to learn OO is via studying Smalltalk. I think the best way to learn FP is via either Haskell or ML, etc. I do real work in OCaml, Lisp, and Python (though I am coming to prefer Lua over Python), but use a multi-paradigm approach based on what I've learned in other languages.
  - gruseom 18y ago
    Be civil, have your coffee. That made me laugh! Actually the coffee kicked in as I was writing, which you can probably tell. I don't know why I didn't go back and edit the first part... I compulsively edit everything else.

gruseom 18y ago

Note: I mostly wrote the following before I had my coffee. Consider yourself warned :) your observations probably aren't even about OO I programmed professionally in OO for years, have trained many people in OO design and domain modeling, and know what the fuck I am talking about. I know what Smalltalk blocks are, I know what Smalltalk "if" is, and I happen to have read Alan Kay, which you might have seen had you read my post properly instead of just dumping out a pile of predigested tutorial boilerplate. My critique of OO comes from struggling to build serious production systems with it, not from programming language parlor games. exempting Smalltalk from your generalizations about OO ... [is] like exempting Haskell from generalizations about functional programming No, it's not. Kay coined the term OO, but it hasn't meant what he meant by it for a long time. I'm talking about OO in the sense that the overwhelming majority of people now understand it: roughly, the organization of programs into classes that bundle state and behavior in ways that attempt to model the problem domain. Whatever makes Smalltalk great, it isn't this, as the subsequent history of OO makes clear. People thought that this was the contribution of Smalltalk and they tried to abstract the paradigm out and improve on it - but what really happened is they threw the baby out with the bathwater, and now we have static bathwater. I have a hunch this is because they paid too much attention to the Simula strain in Smalltalk and not enough to the Lisp one (http://news.ycombinator.com/item?id=288786 http://news.ycombinator.com/item?id=288786). Had they listened to Alan Kay they wouldn't have made this mistake; there's no question which he emphasizes more. OO systems can be simple and incredibly useful when solving some problems (without needing tremendous amounts of boilerplate code) Anything is simple and useful when you're working on a simple problem. What matters is how it works on complex problems. The claim made about OO for a generation now is that it helps to build complex systems, and this mantra has been repeated and taught so often that most people just believe it. It's not true. In my experience, you do typically end up needing tremendous amounts of boilerplate code when working that way (whether or not you see it as such is a different matter). Worse, your system starts to fight itself because the way you need to organize it over here doesn't work over there, and so on; time to factor out the code you need into a static "utility" class - poof, there just went your OO paradigm. Ultimately, I'm exempting Smalltalk from my critique because of the respect I have for the Smalltalk programmers I know, who can't possibly only be doing OO in the majoritarian sense. I haven't used Smalltalk enough myself to have a clear idea of what they're really doing, and Bob Dylan said not to criticize what you don't understand. I'm not, however, exempting CLOS, which I have used enough to experience several of the limitations I'm talking about, enough so that I don't bother with it anymore. Perhaps that will persuade you that I'm talking about more than C++ and Java?

silentbicycle 18y ago
First, I saw that you said that you have read Alan Kay, but I'm speaking to the general discussion audience. And, ok, you know what you're talking about; I'm used to reading people who think that all OO systems necessarily suffer from the same problems as e.g. C++'s, and, not knowing your programming history, had few impressions to the contrary based strictly on what you said. Nothing personal. Be civil, have your coffee. > What matters is how it works on complex problems. Agreed. I don't believe pure-OO (or pure-FP, pure-declarative, etc.) is an ideal approach for anything. OOP is a technique that works well for some problems, and is best understood so you can use it when it is a good fit. I think that the best way to learn OO is via studying Smalltalk. I think the best way to learn FP is via either Haskell or ML, etc. I do real work in OCaml, Lisp, and Python (though I am coming to prefer Lua over Python), but use a multi-paradigm approach based on what I've learned in other languages.
- gruseom 18y ago
  Be civil, have your coffee. That made me laugh! Actually the coffee kicked in as I was writing, which you can probably tell. I don't know why I didn't go back and edit the first part... I compulsively edit everything else.