Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OO Sucks by Joe Armstrong (2000)

cs.otago.ac.nz

Post reply on HN
Print view View original

321–330 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#321

Post by tabtab »

leshow wrote: post #278
rhblake wrote: post #123

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

Nobody can agree on what OOP really is. I've been in and seen many long debates on the definition of OOP. It's kind of a like a Rorschach test: people project their preferences and biases into the definition.

Until some central body is officially appointed definition duty, the definition debate will rage on.

Re: Why OO Sucks by Joe Armstrong (2000)

#322

Post by tigershark »

0x445442 wrote: post #308
Nasrudith wrote: post #280

Earlier quoted context omitted.

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.

Objects are meant to have a life cycle in which the state should only be changed by the object itself. Setters violate this idea by allowing the sender of the message direct control over the state of the object. A simplistic example: account.deposit(100) may directly add 100 to the account's balance and a subsequent call to account.balance() may answer 100 more than when account.deposit(100) was called. But those det…

It depends, most of the time is better to have separate functions that transform your data rather than have methods and state conflated together. But obviously it depends from the context.

Re: Why OO Sucks by Joe Armstrong (2000)

#323

Post by jdsully »

dragonwriter wrote: post #271
jdsully wrote: post #165

Earlier quoted context omitted.

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?

NextStep adopted it but did not invent it. Once Apple acquired NextStep and released OS X they were the only major company supporting it and had defacto control over the language.

The complaint I have is with NSObject which can be blamed on Next Step. Although another comment pointed out I just didn’t know about a workaround.

Re: Why OO Sucks by Joe Armstrong (2000)

#324

Post by dragonwriter »

jdsully wrote: post #323
dragonwriter wrote: post #271

Earlier quoted context omitted.

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

NextStep adopted it but did not invent it. Once Apple acquired NextStep and released OS X they were the only major company supporting it and had defacto control over the language. The complaint I have is with NSObject which can be blamed on Next Step. Although another comment pointed out I just didn’t know about a workaround.

There were two different major mutually-incompatible “flavors” of Objective-C (my first book on Objective-C covered both, and my first Objective-C programming was done on a NeXTcube), one of which originated at NeXT (NextStep was the OS that was NeXTs last major surviving product after they dropped hardware, not the company.)

Re: Why OO Sucks by Joe Armstrong (2000)

#325

Post by mercer »

jcadam wrote: post #258
throwaway13337 wrote: post #189

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

I can highly recommend Elixir as a pleasant entry point. I've been looking into learning Erlang too though, much as the syntax is a bit daunting.

Re: Why OO Sucks by Joe Armstrong (2000)

#326

Post by bunderbunder »

convolvatron wrote: post #320
bunderbunder wrote: post #300

Earlier quoted context omitted.

That speaks to one of the things that bothers me about OOP's intellectual traditions: there are two different ideas of what "object" can mean, and most object-oriented languages and practices deeply conflate the two. On the one hand, "object" can mean a unification of data structures with the procedures that act on them. In this view, the ideal is for everything to be an "object", and for all the procedures to actual…

dont forget inheritance. its either orthogonal or essential to what it means to be 'object oriented' depending on who you are talking to.

I haven't, but, at least insofar as my thinking has developed (and insofar as Erlang supports it), the question of inheritance is more orthogonal than essential to the specific point I was trying to make. And failed to state clearly, so here it is: This essay is right, and Armstrong is also right when he said "Erlang might be the only object-oriented language". The tension there isn't, at the root, because Armstrong was confused about what OOP is really about; it's because OOP itself was (and is) confused about what OOP is really about.

That said, I would also argue that, like "object", "inheritance" is a word that can describe many distinct concepts, that and here, too, OOP's intellectual traditions create a muddle by conflating them.

Re: Why OO Sucks by Joe Armstrong (2000)

#327

Post by Misdicorl »

weberc2 wrote: post #266
Misdicorl wrote: post #128

Earlier quoted context omitted.

It's frustrating to read this thread and your comment kind of crystallized this for me so I'll respond to you. Using an array without having to (manually) calculate the size of the objects contained within is like the major triumph of OO. This is a getter that you almost certainly use constantly. Please try to consider your statements and potential counter factuals before spraying nonsense into the void

> Please try to consider your statements and potential counter factuals before spraying nonsense into the void My claim was that getter abstractions as described by the GP (abstracting over the “accessed from memory” implementation detail) are not useful. Why do you imagine that your array length example is a reasonable rebuttal?

Its not the length of the array. Its using things like array[20]. Yes that exists pre-OO and outside of OO, but its the foundational aspect of OO and one of the strongest use cases.

Sorry for the way I communicated- I was tired and should have reconsidered.

Re: Why OO Sucks by Joe Armstrong (2000)

#328

Post by layoutIfNeeded »

overgard wrote: post #109
Animats wrote: post #77

A few notes: Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data. A big problem with OOP in C++ was that it wasn't opaque enough. The headers needed to use an object contain info only useful to the object's private functions. This creates recompile hell. Multiple inheritance is seldom worth the headaches. Overriding a member…

> Binding data and functions together beats operating on global data visible to everything. One of the big wins of OOP is less exposed global data. ... These things are unrelated. Just write functions that don't operate on global exposed data? You know, like, function arguments.

>You know, like, function arguments.

That's a good idea! Although... I wonder if you would get tired of passing around the same piece of data between such functions all the time? Here's a crazy idea: what if we pass the data implicitly to such functions? Like, we could pretend that the data was passed to the function as a hidden argument, and we could call this argument "self" or "this"! :O

Re: Why OO Sucks by Joe Armstrong (2000)

#329

Post by AnimalMuppet »

tigershark wrote: post #318
Nasrudith wrote: post #280

Earlier quoted context omitted.

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.

It’s a different semantic in my opinion. Even in mutable objects it’s better to have setters that act only on the field that they are supposed to mutate and do absolutely nothing else. If you need a notification you can raise an event and then the interested parties will react accordingly. By mutating directly an unrelated field, or even worse, call an unrelated method that brings complete havoc to the current object…

I disagree, slightly. A setter (or any method, for that matter) has to keep the object in a consistent state. If it can't set that one field without having to change others, then it has to change others.

Now, if you want to argue that an object probably shouldn't be written in the way that such things are necessary, you're probably right. And if you want to argue that it should "just set the one field in spirit" (that is, that it should do what it has to to set the field, but not do unrelated things), I would definitely agree with you. But it's not quite as simple as "only ever just set the one field".

Re: Why OO Sucks by Joe Armstrong (2000)

#330

Post by AnimalMuppet »

0x445442 wrote: post #308
Nasrudith wrote: post #280

Earlier quoted context omitted.

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.

Objects are meant to have a life cycle in which the state should only be changed by the object itself. Setters violate this idea by allowing the sender of the message direct control over the state of the object. A simplistic example: account.deposit(100) may directly add 100 to the account's balance and a subsequent call to account.balance() may answer 100 more than when account.deposit(100) was called. But those det…

Well... a setter is the object changing its own state. That's why the setter has to be a member function.

I would say instead that an object shouldn't have setters or getters for any members unless really necessary. And by "necessary", I don't mean "it makes it easier to write code that treats the object as a struct". I mean "setting this field really is an action that this object has to expose to the external world in order to function properly". And not even "necessary" because I coded myself into a corner and that's the easiest way out I see. It needs to be necessary at the design level, not at the code level.

Post reply on HN