Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

271–280 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

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

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.

Wasn't the design decision (and implementation) involved in place log before Apple had anything to do with it?

Re: Why OO Sucks by Joe Armstrong (2000)

#272

Earlier quoted context omitted.

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…

> 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 If they do, that's your fault for letting them. I guess you mean when people chain stuff thus company.programmers.WebDevs.employ('fred') where .programmers and .WebDevs is an exposed internal of the company and programmers department respectively? (…

Why downvoted? I don't mind being wrong but would like to know where and why.

Re: Why OO Sucks by Joe Armstrong (2000)

#273

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…

Oh wow. I was really not expecting you to join this conversation and I am very thankful to have crossed paths with you, even so briefly. Sorry for getting you wrong about the “objects” vs. “OOP” thing. I have thought you could maybe call it “node-oriented” or “thread-oriented” but after reading this comment I think “ecosystem-oriented” might be more faithful a term?

Alan suggested "server-oriented programming" in Quora:

https://www.quora.com/What-is-Alan-Kays-definition-of-Object...

Re: Why OO Sucks by Joe Armstrong (2000)

#274

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…

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

No, they don't, because “more or less” is not actually directly. Particularly, naive getters and setters can be (and often are) replaced with more complex behavior with no impact to consuming code because they are simply message handlers, and they abstract away the underlying state.

Re: Why OO Sucks by Joe Armstrong (2000)

#275
post #265
post #155

Earlier quoted context omitted.

> Wouldn't this violate the "encapsulation" pillar of OOP? As far as I know, it's always taught with encapsulation, inheritance, polymorphism being its three pillars. Encapsulation is "if you have a state, you should encapsulate it". It does not ask you to have a state (even less a mutable one). I quite often use object to represent a logical piece of code, without any attributes. > I'm not sure functional programmin…

The question isn't if OOP or FP will win, but what mix of both is best. A lot of old OOP languages have added features that move them more towards FP. Out of the top of my head C# got E.g. extension methods, lambdas and many ways to be less mutable or pass multiple values around. The bit of programming history i was allowed to experience most definitively became more functional.

This is exactly it. The question is not "which will take over the world". Both can contribute useful features in various situations, and this is why I like languages that let me use what is best in each situation.

Re: Why OO Sucks by Joe Armstrong (2000)

#276
post #52

Earlier quoted context omitted.

>Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to binding the functions and the types... And the world is not so neatly divided between things that just are (data structures) and thing that do things (functions). Take a date for example. The fact tha…

I'm not sure I'd agree that it being a Wednesday is a "just is" sort of thing. The point in time is a data point (on the time axis, if you will). A function then needs to place it in a calendar. FWIW I'm struggling to come up with a good example of where the line between data and functions is clearcut, except perhaps when the data describes a function: an SQL string, some code that'll get eval'ed, etc.

>The point in time is a data point (on the time axis, if you will)

You need some way to place in on that axis, though. Commonly we use Day, Month, and Year to do so. But we could also define a date as the seventh Wednesday in 2019. Or as an integer relative to Jan 1 1970.

Re: Why OO Sucks by Joe Armstrong (2000)

#277
I suggest OO is a useful abstraction because it maps well to the universe we are trying to describe, especially with respect to state.

Rule of thumb?

Anything that can reasonably be done in FP should be done there, in 'library' like conditions (some people use the term 'FP core' - I think more as lib).

The point is to parse out as much of the problem into highly individual parts that can be built/tested on their own.

Think of parsers, pre-processors, utilities like lodash, node libraries.

These things tend to be truly stateless.

Then OO for the inherently stateful stuff.

I also think the discussion might be coloured by the type of dev: UI is fundamentally stateful. Very much so and there's no avoiding it. OO lends very well to abstractions such as 'button' and 'text field' etc.. Backend, maybe less so, depending on.

Re: Why OO Sucks by Joe Armstrong (2000)

#278

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…

> 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 :)

But not in the way he's describing OO in his blog post. He's talking about a language with functions bound to objects and where objects have some internal state. The OO he's describing does not have isolation between objects because you can share aliases freely; references abound.

Re: Why OO Sucks by Joe Armstrong (2000)

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

> what does late binding by you?

Some things that come to mind:

- Abstract classes/methods, and interfaces. This is implemented using vtables in C++.

- Ability to send messages asynchronously, or to other computers, without exposing the details of such things. You just call a method in another class and let your dispatcher handle it. There was a whole industry built around this concept in the 90s: CORBA, DCOM, SOAP. And Erlang, of course, in a different way.

- Ability to change the class/object during runtime. Like you can with Javascript and Lua, calling `object.method = `. Javascript was inspired by Self (a dialect of Smalltalk), so there's that lineage. Other languages like Python and Ruby allow it too.

- Ability to use the message passing mechanism to capture messages and answer them. Similar to Ruby's "method_missing" and ES6 Proxies in Javascript. This is super useful for DSLs and a great abstraction to work with. Check this out: http://npmjs.com/package/domz

Remember that you can have some of those things without dynamic typing (Objective-C).

Re: Why OO Sucks by Joe Armstrong (2000)

#280
post #163

Earlier quoted context omitted.

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.

Maybe I am a complete philistine but is that really a bad thing or just something which goes against their categorism? I get that there are some circumstances where setters would break assumptions but classes are meant to be worked with, period.
Post reply on HN