Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Healthy Hatred of OOP, or the principles of my message-driven framework

bythehilt.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#21

Post by atonparker »

jasode wrote: post #4

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…

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 traditionally taught, which in my experience was closer to Java beans and FactoryFactory classes. In other words, a terrible misinterpretation of Alan Kay's ideas.

If you actually look at the framework they are presenting, it pushes the developer towards many of the "good OOP" points you made. So I'm not sure exactly what you're arguing here.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#22

Post by kevinavery »

amelius wrote: post #16

The only good thing that OOP brings to the table is, in my opinion, access control.

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.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#23

Post by jasode »

atonparker wrote: post #21
jasode wrote: post #4

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…

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.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#24

Post by koder2016 »

> Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information.

In pure Actor Model adding two numbers would probably involve 2+ actors, yet Erlang is not doing this for some reason... I guess on a lower level hardcoding messages makes complete practical sense.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#25

Post by koder2016 »

daxfohl wrote: post #6

The downside of message passing is debugging. No call stack so you can't trace things back to their source.

If the framework is factored well, then you can plug-in a synchronous single-threaded message delivery when debugging.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#26

Post by UK-AL »

patrickmay wrote: post #13
jasode wrote: post #4

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…

> The getX() and setX() is an anti-pattern of good OOP. This needs to be tattooed in reverse on many developers foreheads so it's the first thing they read when brushing their teeth in the morning.

Problem is developers take that as an excuse to make state public, which is even worse.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#27

Post by abiox »

jasode wrote: post #23
atonparker wrote: post #21

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.

the swell thing about "OOP" is how ill-defined and vague the notion can be. just like "correct OOP" and "incorrect OOP".

as a consequence, discussions can go back and forth, frequently resulting in little but gymnastic displays of equivocation and red-herrings. when the dust settles, surprisingly little communication has occurred.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#28

Post by abiox »

kevinavery wrote: post #22
amelius wrote: post #16

The only good thing that OOP brings to the table is, in my opinion, access control.

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.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#29

Post by mpweiher »

abiox wrote: post #27
jasode wrote: post #23

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.

the swell thing about "OOP" is how ill-defined and vague the notion can be. just like "correct OOP" and "incorrect OOP". as a consequence, discussions can go back and forth, frequently resulting in little but gymnastic displays of equivocation and red-herrings. when the dust settles, surprisingly little communication has occurred.

"OOP to me means only messaging, local retention and protection and

hiding of state-process, and extreme late-binding of all things. It

can be done in Smalltalk and in LISP. There are possibly other

systems in which this is possible, but I'm not aware of them."

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#30

Post by kazinator »

jasode wrote: post #4

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…

Moreover, getters and setters can be readily modeled with messages.

That messages and (at least single dispatch) methods are identical was settled decades ago.

(Has someone worked out a multiple dispatch OOP based on message passing?)

Post reply on HN