31–40 of 98 posts
The downside of message passing is debugging. No call stack so you can't trace things back to their source.
"Causeway, an open source distributed debugger written in E, lets you browse the causal graph of events in a distributed computation."
Joe Armstrong's thoughts on how Erlang is more OO than OO languages: http://erlang.org/pipermail/erlang-questions/2009-November/0... Joe likes to be funny, so don't get upset and confrontational about it. The central idea is this I think: --- I now believe the following to be central to the notion of OO. - Isolated concurrent things - Communication through message passing - Polymorphism All the other stuff (inheritan…
The downside of message passing is debugging. No call stack so you can't trace things back to their source.
Message passing OOP doesn't necessarily imply that type of message passing. That is to say, the "send" call doesn't have to return until the target object has processed the message.
Earlier quoted context omitted.
It seems to me like you and the author agree about what good OOP should be (encapsulated state, message passing), except they argue that "traditional" OOP is not useful, and you see Traditional OOP as Good OOP. In fact, "good" is not used a single time in the article so I don't see how they could be constructing a strawman against it. I'm guessing the author is using "traditional" in the sense of what is traditionall…
>, and you see Traditional OOP as Good OOP. No, my comments don't agree with that. In fact, I tried to point out that his "traditional OOP" examples are incorrect OOP and therefore, a straw man to be arguing against.
You successfully replaced his straw man by your true Scotsman.
Earlier quoted context omitted.
>, and you see Traditional OOP as Good OOP. No, my comments don't agree with that. In fact, I tried to point out that his "traditional OOP" examples are incorrect OOP and therefore, a straw man to be arguing against.
> In fact, I tried to point out that his "traditional OOP" examples are incorrect OOP and therefore, a straw man to be arguing against. You successfully replaced his straw man by your true Scotsman.
I don't think "OOP" is an unreachable shared understanding such as the "No True Scotsman" applied to debated concepts like "communism".
Despite the different vocabulary and emphasis of Alan Kay (Smalltalk) and Joe Armstrong (Erlang) about OOP, there is still a commonality of understanding there. The OOP concepts expressed in Objective-C, Borland Delphi, and other GUI toolkits share that understanding of encapsulated state with message passing (methods) via a coherent "public interface".
The author was not arguing against that "shared understanding" of correct OOP. Instead, he highlighted bad coding practices (albeit very common ones), then labeled it as "traditional OOP".
Yes, there is a ton of misunderstood and misapplied programming practices that others label as "OOP". That's the fault of the people doing the mislabeling and not the fault of OOP.
Earlier quoted context omitted.
Also referred to in this context as encapsulation. OOP provides a method of information hiding that allows implementation details to be changed later without changing the public API.
one downside being that you risk creating obscured islands of mutable state, complecting engineering efforts.
Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
> No, good OOP has class/object with both private state
If a class has state, you have to be able to read that state or it's useless.
It's a good practice overall to tell classes what to do but eventually, you need to get information from them. That's where getters come into play.
Joe Armstrong's thoughts on how Erlang is more OO than OO languages: http://erlang.org/pipermail/erlang-questions/2009-November/0... Joe likes to be funny, so don't get upset and confrontational about it. The central idea is this I think: --- I now believe the following to be central to the notion of OO. - Isolated concurrent things - Communication through message passing - Polymorphism All the other stuff (inheritan…
[1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
I always felt that people who had never used C before C++ or Java, nor any other procedural language, aside from some scripting tended to some of the messiest OO. Seemed they'd want to create a sea of objects and patterns even when something simple was staring them in the face.
OO is harder to teach, and clearly harder to understand. That's the top and bottom of most issues with it.