Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

161–170 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#161

It really should be noted that years later Joe changed his mind about OO and came to the realization that perhaps Erlang is the only object-oriented language :) From a 2010 interview: ..."I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was par…

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

> "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about [function calls]."

Re: Why OO Sucks by Joe Armstrong (2000)

#162

Earlier quoted context omitted.

I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of funct…

Forces discipline is a double edged sword. It can help you keep things clean and understandable, but it can also limit things. For example: I am pretty good with react and redux, but I was more productive with JQuery. JQuery doesn’t have the forced discipline of react+redux, but it gets the job done. At the same time, I’ve seen larger amounts of crap JQuery code than React+Redux. The real issue: discipline has to be…

> If you force it, then no one knows why things are they way they are.

It's more accurate to say "if you don't teach why' then no one knows why". Forcing or not has nothing to do with it.

I would argue "forcing" is strictly better, since learning discipline requires experience in doing things in every other wrong way. While that's great for learning on your own, I wouldn't want developers to "learn discipline" like this in production.

Re: Why OO Sucks by Joe Armstrong (2000)

#163

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?

In Kay's OO the only way to interact with an object was through method passing. It was important the the internal state of an object was kept private at all times. Getters/setters are technically message-passing methods, but they undermine the design goal because they more or less directly expose internal state to the public world. But we see getters/setters used constantly . People don't use OO in the way Kay intend…

In my experience, getter/setter abuse is always an attempt to use classes as a structs/records.

I wonder if we had different syntax for those cases we'd have less of them.

But then, again, it's very convenient to be able to add a method to a class that was previously a dumb struct.

Re: Why OO Sucks by Joe Armstrong (2000)

#165
post #150

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?

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

Objective-C is much closer to true object orientation than C++, but IMO Apple neutered it by having the program crash if there was no message handler.

Re: Why OO Sucks by Joe Armstrong (2000)

#166
post #156

Earlier quoted context omitted.

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.

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 complete opposite of what Erlang is.

[1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

Re: Why OO Sucks by Joe Armstrong (2000)

#167
My lukewarm enthusiasm for OO stems from a different set of reasons than these. I view its main benefit to be the way it reinforces encapsulation as a design pattern. But good code with clearly organized functions and data structures can achieve that just as well.

I don't have anything against it, and wielded with skill I see its benefit. But after 30 years of programming I think you can achieve many of those benefits more simply without it.

Re: Why OO Sucks by Joe Armstrong (2000)

#168
>Consider “time”. In an OO language a “time” has to be an object.

No it fukin doesn't. OO is a paradigm, useful at times, nothing more.

That's what modern programming is all about - you pick the right tool for the right task.

OP's attempt to force OO onto an abstract concept like time is so far off the mark calling it a strawman wouldn't even be the right word.

Re: Why OO Sucks by Joe Armstrong (2000)

#169
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…

I'm the one mentioning C++. To anyone familiar with both styles, Joe Armstrong is clearly not talking about Smalltalk-style OOP in his essay, he's talking about C++/Java/etc style. And later on he only praised Smalltalk-style OOP.

And sorry, by a "change in mindset in our industry regarding OOP" I mean that it became commonplace to criticize C++-style OOP. Not that everyone stopped programming in that style. Maybe there's a better way to phrase it?

Re: Why OO Sucks by Joe Armstrong (2000)

#170

Earlier quoted context omitted.

Just my personal anecdote. The only functional programming languages I have extensive experience with are C and JS. I have NEVER seen a sensibly organized or maintained medium to large sized C or JS application. Every time it's been total chaos. In Java projects, there's a 50/50 shot of it being moderately sensible. I'm confident other people have completely different experience. Based on your post it sounds like you…

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 of that.) The kind of discipline proposed by structured programming was far from universally well-received at the time, and I think it's fair to say that it lead to huge improvements in the quality of codebases everywhere, and is one of the great successes of programming language thinking of the '70s.

C is also statically typed. It's obviously easy to blow all sorts of holes in C's type system, but if you'd go so far as to say that C's types impose no discipline at all, I'd ask you to try teaching C to a room full of compsci students who have been raised on something like Python.

Post reply on HN