Hacker News Reader

Comment by atonparker | Hacker News Reader

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.

View on HN

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

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.

No, the premises always need to be examined, not accepted at face value.

If the author is using a wrong definition as a starting point, the rest of the argument is largely pointless...or must be explicitly marked as a hypothetical/counterfactual.

"I define the earth as being an infinite flat plane, from this it follows [for the real world] that..."

Well, no, the earth is not an infinite plane, even if it kinda looks that way, was long believed to be that (maybe minus the infinite) and apparently there still are people who believe that.

There is a difference between definition and assumption. An assumption says that something about the world is true. A definition just says what meaning you will intend by a word in the current scope.

When you define OOP, you aren't saying anything about the real world, just stuff about the words you will be using within the current context.

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

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

>I'm guessing the author is using "traditional" in the sense of what is traditionally taught

This is correct and it's my mistake for not making this more clear.

Seems that OOP is going the same way as Agile, and no one can come up with a consistent definition of what it is these days. Encapsulated state and message passing are not exclusive to the OOP paradigm are they?

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.

Reply on news.ycombinator.com