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

331–340 of 396 posts

Re: Why OO Sucks by Joe Armstrong (2000)

#331

Post by 0x445442 »

tigershark wrote: post #322
0x445442 wrote: post #308

Earlier quoted context omitted.

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.

Yeah there are no hard and fast rules but a lot of time transformations can be in the object as well. If I need a function to transform Foo to Bar I could just as easily send a toBar() message to an instance of Foo.

Re: Why OO Sucks by Joe Armstrong (2000)

#333

Post by DonaldPShimoda »

IOT_Apprentice wrote: post #332
hota_mazi wrote: post #164

Earlier quoted context omitted.

I don't, but that's not how the burden of proof works.

Alan Kay responded above so...

Link at [0].

I'm a little skeptical. That user certainly writes in a similar style to how I've seen Alan Kay write online, but I wouldn't be opposed to seeing some more proof. A one-day-old HN account claiming to belong to one of the most important people in CS from the past 50 years seems a little suspicious haha.

[0] https://news.ycombinator.com/item?id=19717640

Re: Why OO Sucks by Joe Armstrong (2000)

#334

Post by bluejay2387 »

tabtab wrote: post #321
leshow wrote: post #278

Earlier quoted context omitted.

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

Is this different from ANY other concept in technology? Personal Computing, Big Data, Cloud Computing, Deep Learning, Artificial Intelligence? We never have real definitions for any of these, and if you attempt to make one it will be obsolete before you finish your blog post.

The only real problem I see is that too many technologist insist that there is 'one definition to rule them all' and it's usually the one they most agree with. As long as we all understand that these terms are fluid and can explain the pro's and con's of our particular version we will be fine.

Re: Why OO Sucks by Joe Armstrong (2000)

#335

Post by alankay »

hannofcart wrote: post #259
alankay wrote: post #230

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.

I'm the "computing Alan Kay" from the ARPA/Parc research community (there's a clarinettist, a judge, a wrestler, etc.) I did create a new account for these replies (I used my old ARPA login name).

Re: Why OO Sucks by Joe Armstrong (2000)

#336

Post by tigershark »

0x445442 wrote: post #331
tigershark wrote: post #322

Earlier quoted context omitted.

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.

Yeah there are no hard and fast rules but a lot of time transformations can be in the object as well. If I need a function to transform Foo to Bar I could just as easily send a toBar() message to an instance of Foo.

I think c# really got the best of both worlds with extensions methods, where you can actually define functions that act on a object but are separated from the actual class definition. I still think that pure functions and especially higher kinded types are better probably, although I have no direct experience with Haskell type classes, scala implicits and ocaml modules..

Re: Why OO Sucks by Joe Armstrong (2000)

#337

Post by DonaldPShimoda »

dragonwriter wrote: post #274
DonaldPShimoda wrote: post #148

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

> No, they don't, because “more or less” is not actually directly.

I disagree.

Consider a `Counter` class, intended to be used for counting something. The class has one field: `Counter.count`, which is an integer.

A setter/getter for this field would be like `Counter.setCount(i: Int)` and `Counter.getCount() -> Int`. There is no effective difference between using these methods and having direct access to the internal state of the object.

A more "true OOP" solution would be to use methods with semantic meaning, for example: `Counter.increment()`, `Counter.decrement()`, and `Counter.getCount() -> Int`. (Yes, the getter is here because this is a simple example.) These kinds of methods are not directly exposing the internal state of the object to be freely manipulated by the outside world.

If your getter/setter does something other than just get/set, then it's not really a getter/setter anymore — it's a normal method that happens to manipulate the state, which is fine. But using getters/setters (in the naive, one-line sense) is commonplace with certain people, and I feel that their use undermines the principles Kay was getting at.

Re: Why OO Sucks by Joe Armstrong (2000)

#338

Post by lame88 »

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…

“I mainly wanted to provoke people...” I hate this. I see it way too often. It’s either a cop-out to avoid having to own up to your arguments or its just poisonous rhetoric in the first place that contributes to partisan opinions, especially when the speaker has an air of authority that causes people to accept what they say at face value. It is directly antithetical to critical thinking.

Re: Why OO Sucks by Joe Armstrong (2000)

#339

Post by DonaldPShimoda »

tempguy9999 wrote: post #254
DonaldPShimoda wrote: post #148

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

> I doubt any language can prevent this kind of 'exposing guts' malpractice

Actually, true OOP languages do prevent this. Internal state is completely private and cannot be exposed externally. The only way to interact with an object's state is through its methods — which means the object itself is responsible for knowing how to manipulate its internal state.

Languages like Java are not "true" OOP in this sense, because they provide the programmer with mechanisms to allow external access to internal state.

Internal state should be kept internal. You shouldn't have a class `Foo` with a private internal `.bar` field and then provide public `Foo.getBar()` and `Foo.setBar()` methods, because you may as well just have made the `.bar` field public in that case.

Also, FWIW, I did not downvote you. I dunno why you were downvoted. Seems you had a legitimate point here, even if I disagree with it.

Re: Why OO Sucks by Joe Armstrong (2000)

#340

Post by andybak »

tcgv wrote: post #305
andybak wrote: post #226

Earlier quoted context omitted.

> The important thing is restricting your public interface That is the important thing sometimes . At other times the important thing is to provide a flexible, fluent public interface that can be used in ways you didn't intend. It really depends on what you're building and what properties of a codebase are most valuable to you. Encapsulation always comes at a cost. The current swing back towards strong typing and "bo…

> At other times the important thing is to provide a flexible, fluent public interface that can be used in ways you didn't intend. That scares me. How do you maintain and extend software used in ways you didn't intend? Quality assurance should be challenging.

> That scares me.

It scares you because you're making some assumptions:

1. You assume that I'm writing software that I expect to use for a long period of time.

2. Even if I plan to use my software for an extended period of time, you're assuming that I want future updates from you.

Let me give you an example of my present experience where neither of these things are true. I'm writing some code to create visual effects based on an API provided by a 3rd party. Potentially - once I render the effects (or for interactive applications - once I create a build) my software has done it's job. Even if I want to archive the code for future reuse - I can pin it to a specific version of the API. I don't care if future changes cause breakage.

And going even further - if neither of these conditions apply the worst that happens is that I have to update my code. That's a much less onerous outcome than "I couldn't do what I wanted in the first place because the API had the smallest possible surface area".

I'll happily trade future breakage in return for power and flexibility right now.

Post reply on HN