Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

231–240 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#231

Earlier quoted context omitted.

I'd be really interested to hear what you think they missed, because I find your claim to be surprising and a bit preposterous.

Armstrong wrote the very famous "Why OO sucks" and then a decade or two later, changed his mind when he saw how successful OO was, and then tried to retrofit Erlang into an OO language. Not by changing Erlang, but by twisting the definition of OOP so that Erlang would fit it.

That isn't what happened at all (see the rebuttal by revvx). Joe was a great guy and also a great systems thinker. And he was the last person to worry about "bandwagons" (quite the opposite!)

Re: Why OO Sucks by Joe Armstrong (2000)

#232
post #156

Earlier quoted context omitted.

I don't think that's what happened. Joe Armstrong was criticizing C++-style OOP when he wrote his critique. After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP. He didn't change his stance based on popularity. He changed his stance because in the 80s/90s the term "OOP" was synonymous with C++-style-OOP, but that changed in…

He doesn't even mention C++ in his essay [1], but regardless, the C++ OOP is pretty much the mainstream OOP, which we still use today in Java, Kotlin, C#, etc... And... no, the change in mindset about OOP never happened. Kay and Armstrong's view of OOP never took on. Today, OOP is still not seen as message passing and mostly seen as polymorphism, parametric typing, classes/traits/interfaces, and encapsulation. The co…

Again, please do your homework.

Re: Why OO Sucks by Joe Armstrong (2000)

#233

I'm really sick of these 'why blah sucks' posts. Clearly OOP works for a lot of people. If it doesn't work for you, don't use it. My personal feeling is that FP works better when the problem domain is more data oriented, requiring transformation of data streams whereas OOP is good when the problem domain is about simulating or modeling where you want to think about interacting agents of some kind. The whole 'X is one…

Actually, this is not really about if OO sucks, but to reflect on one of the articles Joe Armstrong wrote. Joe passed away two days ago.

Re: Why OO Sucks by Joe Armstrong (2000)

#234

Earlier quoted context omitted.

Isn't a method call a message, and the return value a message back? Or is it that "true OO" must be asynchronous?

No, it does not have to be async. My impressions from using Squeak regarding this matter: 1. You can send any message to any object. In case the object does not have a suitable handler, you will get an exception: does not understand . The whole thing is very dynamic. 2. There is no `static` BS like in c# or java. This is because each method has to be a method of an object. For each class there is a metaclass which is…

You can implement Smalltalk like patterns in C# via dynamic types and expression trees.

Re: Why OO Sucks by Joe Armstrong (2000)

#236

Earlier quoted context omitted.

In this context, C and JavaScript would not be considered functional. They have functions, but that's not what most people mean by "functional". While it's possible to restrict yourself to a functional subset in both of them, they would typically fall into the "imperative" category. Imperative programming languages (like C and JavaScript) don't generally impose any discipline on the users.

> Imperative programming languages (like C and JavaScript) don't generally impose any discipline on the users. I think this view disrespects history a little. C was one of the earliest languages to be conceived upon a foundation of structured programming principles, i.e. block structure, sequence/selection/repetition, subroutining. (Okay the language still has goto, hopefully we can agree to not make a big deal out o…

Kind of true, however C's type system is very weak versus what 60's Algol and PL/I variants were capable of.

Re: Why OO Sucks by Joe Armstrong (2000)

#237
post #80

Earlier quoted context omitted.

The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementati…

> Python doesn't: o.x does not necessarily mean accessing an x slot C# also 'fixes' that. o.x could be a slot or it could be a getter/setter.

Initially seen in languages like Eiffel and Delphi.

Re: Why OO Sucks by Joe Armstrong (2000)

#238
post #150

Earlier quoted context omitted.

> Isn't a method call a message, and the return value a message back? It is! In my view, the point that Alan Kay and Joe Armstrong are trying to make is that languages like C++/Java/C# etc have very limited message passing abilities. Alan Kay uses the term "late binding". In Kay's opinion, "extreme late binding" is one of the most important aspects of his OOP [1], even more important than polymorphism. Extreme late b…

what does late binding by you? That sounds like an argument for non-strictly typed languages. Isn't in the strict typing that prevents late binding? The compiler wants to know at compile time the types of all the messages and whether or not an object can handle that message hence all messages must be typed and all object must declare which messages they accept.

Objective c is a compiled language

Re: Why OO Sucks by Joe Armstrong (2000)

#239
post #121

Earlier quoted context omitted.

In the original JavaBeans spec, getters and setters served two purposes: 1. By declaring a getter without a setter, you could make a field read-only. 2. A setter could trigger other side effects. Specifically, the JavaBeans spec allowed for an arbitrary number of listeners to register callbacks that trigger whenever a value gets changed. Of course, nobody actually understood or correctly implemented all this, and it…

Finally someone mentions using getters to create read only fields. Objects are the owners and guardians of their own state. I don't see how this is possible without having (some) state-related fields that only can be read from the outside.

Pretty obvious to readers of "Object-Oriented Software Construction" from Meyer.

A big problem is cargo culting without reading the CS references.

Re: Why OO Sucks by Joe Armstrong (2000)

#240
Approaching OO with the mentality that it's easy is what makes OO looks bad. It doesn't get treated with the same focus/attention as other methodologies. This realization often comes in retrospect, after programming for many years and watching how you misunderstood OO and how your abstractions improved over time.

OO is not easy after all. You might be familiar with all the patterns which can give a sense that you know OO well, and you end up with pretty bad design.

Post reply on HN