Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

281–290 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#281

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…

> I think this view disrespects history a little.

I love C, but I'm hard pressed to think of any language other than assembly which is more willing to get out your way if you so much as nudge in an undisciplined direction. C certainly does not impose much discipline on programmers, but it allows them to bring some if they walk the line.

> Okay the language still has goto, hopefully we can agree to not make a big deal out of that.

> It's obviously easy to blow all sorts of holes in C's type system

Yes, I'm willing to politely ignore evidence which refutes your point. I mean you were kind enough to make my case for me. :-)

> I'd ask you to try teaching C to a room full of compsci students who have been raised on something like Python.

Dynamic vs static typing seems orthogonal to what we're talking about here, but maybe I'd have to think about that more. Python just waits to catch your type errors until runtime. Comparing that to JavaScript in a browser which silently ignores your errors (or happily performs crazy type conversions), Python seems disciplined in comparison.

Re: Why OO Sucks by Joe Armstrong (2000)

#282

Earlier quoted context omitted.

I didn't coin the term "object" -- and I shouldn't have used it in 1966 when I did coin the term "object-oriented programming" flippantly in response to the question "what are you working on?". This is partly because the term at the time meant a patch of storage with multiple data fields -- like a punched card image in storage or a Sketchpad data-structure. But my idea was about "things" that were like time-sharing p…

Are you the Alan Kay. Is there any way we can verify this is you? The HN user account seems to have a very low "karma" rating, so one can't help but be more suspicious.

It’s a new account created yesterday. Alan Kay did an AMA here a while back+ with the username “alankay1” and occasionally posted elsewhere. That account’s last post was 7 months ago. Given that user “Alan-1”s style and content is similar, it seems likely that he created a new account after half a year away from HN.

If you want verification, maybe you can convince him to do another AMA =) I’m still thinking about his more cryptic answers from the last one, which is well worth a read. I think that was before Dynamicland existed, but I may be off.

+ https://news.ycombinator.com/item?id=11939851

Re: Why OO Sucks by Joe Armstrong (2000)

#283

Earlier quoted context omitted.

> program hiding state in layers of objects is often counterproductive Do you think it was counterproductive to hide OS-specific file handles, CRT level of caching, and many other things CRT does behind these opaque FILE* object pointers? Such hiding allowed to have very similar and quite easy to use across all platforms. The implementation of these fopen and fwrite functions relies on kernel calls like open/write on…

> Do you think it was counterproductive to hide OS-specific file handles, CRT level of caching, and many other things CRT does behind these opaque FILE* object pointers? To answer that question for parent, no, he obviously doesn't think so. And yes, streams are basically OOP (they are implemented using "method dispatch"). Streams are one of the few successful abstractions out there. And when I say "successful" I most…

> Streams are one of the few successful abstractions out there.

I don’t think they’re few. I think all modern software uses OOP-based abstractions heavily.

For example, for GUIs, it’s visual trees everywhere. HTML DOM is the most widely used one now, but pretty much every GUI framework have something conceptually similar, even 30 years old WinAPI is built on very OOP-like concepts, you have HWND handles but the state is completely hidden and can only be accessed by calling functions.

> Because they're leaky.

No abstraction is 100% waterproof, but some are useful enough for many practical applications, despite they leak occasionally.

These particular file I/O API is less leaky on Windows, but they still leak, and there’re many weird low-level APIs to bypass these abstractions: DeviceIoControl, defragmentation API, backup API, and many others.

> abstractions come at a huge price

I’m not convinced the price is > 0.

We can always skip any abstraction we don’t like and use the next lower-level one. We don’t often do that because developing code based on these lower-level things is often more expensive than using the abstractions, despite they leak.

That’s why people use Electron & JavaScript, Java & .NET, game engines. They all made from large count of the layers you’re talking about, and when they leak that’s indeed can be very expensive to diagnose and fix/workaround. However, dropping them and developing something from lower levels is usually way more expensive.

Re: Why OO Sucks by Joe Armstrong (2000)

#284
post #141

> In an OOPL I have to choose some base object in which I will define the ubiquitous data structure. All other objects that want to use this data structure must inherit this object. So... that's not actually how it works though, right?

It was. Criticisms like this led to implementing hybrid-OO systems. Those are what we now call OO. He’s talking about Smalltalk, Self, that sort of thing.

In no ever existing OO language do you have to inherit from a data structure to use the data structure, I don't think?

Re: Why OO Sucks by Joe Armstrong (2000)

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

C++'s vtable is also late binding, since you don't know which implementation you're calling until runtime. And there's no such thing as "extremely late binding". > In C++, for example, the only kind of late binding that you have is abstract classes and vtables. That's not true, you can always have a "send_message(string id)". Few people do it because you lose static type safety. And some languages, like C# and Scala,…

The only good thing about OO as a architecture is, that there is nearly no education required to introduce it to the most novice in the field. Its basically the default thinking approach rebranded. It comes with all the benefits of a mental model - quick orientation, and all the negative of a mental model. (Badly adapted to fit to machine execution, after acertain complexity level is reached - god like actorobjects - basically programmers in softwaredisguise- start to appear).

Re: Why OO Sucks by Joe Armstrong (2000)

#287
post #218
post #209

Earlier quoted context omitted.

Unfortunately unlike C++ etc constness doesn't propagate inside objects marked final. So final List x = new ArrayList() stops x being reassigned but does nothing to stop the downstream code from mutating the contents of the list.

final List immutable = Collections.immutableList(x)... and pass it around. Never expose your collections directly (unless you are willing to go copy on write and immutable objects inside the collections, the latter is very welcome, though)

Also, if you want to go 'whole hog' you can use any of the functional/immutable collection libraries like vavr, functionaljava, or jimmutable.

Re: Why OO Sucks by Joe Armstrong (2000)

#288
post #258

Earlier quoted context omitted.

I'm surprised the actor model hasn't been mentioned. Isn't this the modern name for what theyre talking about? Completely independent objects passing messages and entirely parallelizable.

My first exposure to the actor model was with Akka on Scala. After working with it for a little while, I thought "this is what OOP should be, perhaps I just hate broken implementations of OOP (i.e., Java, C++), rather than OOP itself." Heck, I like Ada95's implementation of OOP better than Java's. I keep meaning to give Erlang a try, but just haven't had a reason yet. I do a lot of Clojure, these days :)

If you like Akka/Scala, definitely give Erlang a try.

Re: Why OO Sucks by Joe Armstrong (2000)

#289
post #62

Earlier quoted context omitted.

Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to get, it's just ridiculous overengineering 95% of the time. Same goes for a lot of stuff in OO. I attribute it to the corporate mindset it seems to thrive in, but I could be wrong.

I feel like what happened to agile development happened to OOP, people morphed it into something that it was never meant to be.

Evolutionary design is that way in general really. Your intentions never matter - just what it can be used for.

Re: Why OO Sucks by Joe Armstrong (2000)

#290

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…

So, microservices are another attempt at emulating a good pattern with a huge pile of bad ones? :)
Post reply on HN