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

51–60 of 98 posts

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

#51

Post by markbnj »

>> When I started learning C++ I was shocked. Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. Instead of communicating between themselves, objects were operated on by some bigger parent object. I found it absurd and fought it for a long time.

This has nothing whatsoever to do with C++. It's like blaming a microwave oven because your kid put a ball of tin foil in it.

C++ is a great language when you are developing big compiled programs and need strong metaphors for decoupling and modularity. Most developers today work on distributed systems where the individual cooperating pieces that they write are much smaller. Your 1000 line HTTP handler in python won't benefit much from strong static type checking, but the linux kernel does, and so do a lot of the infrastructure components we all take for granted every day.

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

#52

Post by kazagistar »

mpweiher wrote: post #29
abiox wrote: post #27

Earlier quoted context omitted.

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...

That is not the definition of OOP the author is using. He made it clear what he meant by OOP; a paradigm seen often in production systems. Productive discussions start by accepting given definitions and arguing against the resulting points, not by arguing that the definitions are wrong because they don't match the exact form defined by someone somewhere.

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

#53

Post by stcredzero »

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…

tl;dr -- Alan Kay emphasized the message passing nature of method dispatch in Smalltalk.

A traditional OOP approach would have much of the functionality taken out of the player objects, using them simply to hold state.

Sounds like C structures. Back in the day, we were always urging and cajoling programmers to stop thinking this way and think more in terms of Objects that knew how to do things in response to messages.

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

#54

Post by [deleted] »

rlt3 wrote: post #9
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…

>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity. One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when…

[deleted]

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

#55

Post by matwood »

jasode wrote: post #41
incepted wrote: post #38

Earlier quoted context omitted.

Good points except saying that getters and setters are an anti-pattern of OOP. Actually, you contradict this a few lines blow: > 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.

>If a class has state, you have to be able to read that state or it's useless. ... That's where getters come into play. No, having a bunch of getABC(), getXYZ(), getEtc() is a code smell . If the class has many getters()+setters() or has the equivalent of many public data members, it means that related actions requiring those variables are happening outside of the class/object instead of inside the class. The more ge…

> I'm not saying all gets() can be eliminated. But the Java practice of having 20 private member variables mirrored by 20 public gets()/sets() is not what OOP is about. It's actually about as opposite to OOP is you can get!

Maybe people are just confusing different sides of the same concept. There are smart objects as you mention and dumb data holders that are used to pass 'messages' around. The classic anemic data model, with objects that operate on said data.

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

#57

Post by spriggan3 »

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.

No it isn't, it provides encapsulation, which the most important aspect of OOP.

I agree with the rest.

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

#58

Post by rdtsc »

incepted wrote: post #39
rdtsc wrote: post #15

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…

FYI, Armstrong thinks that OO sucks [1] so it's weird to see him claim his language is a better OOP language than others. [1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

... "Joe likes to be funny" ...

Besides this idea of taking a label away from something you don't like is also a good strategy in general. He obviously doesn't think Erlang should do multiple inheritance. He just points out languages that have been calling themselves OO these years have been impostors.

Also not sure if I mentioned, Joe like to make witty jokes. So don't take it too seriously.

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

#59

Post by Tloewald »

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…

In a sense the OP is making a point about which paths are paved in most OOP languages. That said, one of the problems I often see in user interfaces is "runaway metaphors". The "objects" and "messages" in question are _metaphors_ and it's important not to let a concept be taken hostage by the metaphors used to describe it.

The main reason controllers exist isn't (or shouldn't be) because of a failure of OOP as a concept, but because of efficiency or complexity. Going back to the baseball example, while it might make intuitive sense for the player to send a "running to first" message, simulating a team's reaction to that event by having player objects communicate purely by messages is horribly complex, whereas a fairly decent simulation can be quickly created by "cheating" with a team controller object (or game controller or whatever).

Even in a "pure" implementation, objects will want to examine each other ("how fast can that player run? Where is she right now? Now? Now? Where's the ball? Who has it? How good an arm do they have?")

If anything, the baseball metaphor shows how complex things can get, and quickly reveals cases where almost any programmer would choose to violate encapsulation to make things work.

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

#60

Post by Tloewald »

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…

In a sense the OP is making a point about which paths are paved in most OOP languages. That said, one of the problems I often see in user interfaces is "runaway metaphors". The "objects" and "message Saying" in question are _metaphors_ and it's important not to let a concept be taken hostage by the metaphors used to describe it.

The main reason controllers exist isn't (or shouldn't be) because of a failure of OOP as a concept, but because of efficiency or complexity. Going back to the baseball example, while it might make intuitive sense for the player to send a "running to first" message, simulating a team's reaction to that event by having player objects communicate by pure message is horrible complex, whereas a fairly decent simulation can be quickly created by "cheating" with a team controller object (or game controller or whatever).

Even in a "pure" implementation, objects will want to examine each other ("how fast can that player run? Where is she right now? Now? Now? Where's the ball? Who has it? How good an arm do they have?")

If anything, the baseball metaphor shows how complex things can get, and quickly reveals cases where almost any programmer would choose to violate encapsulation to make things work.

Post reply on HN