Why OO Sucks by Joe Armstrong (2000) • Hacker News Board

Re: Why OO Sucks by Joe Armstrong (2000)

#341

Post by reallydude » Mon, Apr 22, 2019, 6:48 PM UTC

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.

> dont forget inheritance

Inheritance is a limited convention to do mixins. Including it in the abstract idea of object oriented programming is harmful, other than in reference to the ugly history of "Classical OOP" or "Non-Kay OOP" as you like.

Re: Why OO Sucks by Joe Armstrong (2000)

#342

Post by reallydude » Mon, Apr 22, 2019, 6:53 PM UTC

DonaldPShimoda wrote: post #339

tempguy9999 wrote: post #254

Earlier quoted context omitted.

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

> Internal state should be kept internal.

I'm not sure that's a proven model. It's a proposed model, for sure. Since you can't protect memory from runtime access, you can't really protect state, so it's a matter of convention which Python cleverly baked in (_privatevar access).

Re: Why OO Sucks by Joe Armstrong (2000)

#343

Post by jstimpfle » Mon, Apr 22, 2019, 6:54 PM UTC

Const-me wrote: post #270

andy_ppp wrote: post #187

Earlier quoted context omitted.

Nobody is saying don’t have any abstractions, just that your program hiding state in layers of objects is often counterproductive.

Another example why hiding state can be a good thing. Consider following code: void* ptr = malloc( 32 ); No OOP is involved here, yet the malloc function operates on a critically important piece of mutable global state. The state is quite complex due to numerous reasons: performance, fragmentation, multithreading & deadlocks, alignment… Just look at ptmalloc (linux) or jemalloc (BSD). I think it’s undocumented on Win…

Absolutely should you wrap malloc in any moderately sized project! But clearly that's not OOP. We need to differentiate between abstract data types (method dispatch, which I would normally count as OOP) and just making functions to "reuse" code. In the latter case, there is only one possible implementation, and the implementation can expose as much or as little implementation details as is appropriate -- and in general, there won't be any abstraction leaks.

Re: Why OO Sucks by Joe Armstrong (2000)

#344

Post by alankay » Mon, Apr 22, 2019, 7:02 PM UTC

DonaldPShimoda wrote: post #333

IOT_Apprentice wrote: post #332

Earlier quoted context omitted.

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

An interesting and unfortunately true commentary on the lack of civilized behavior using technology that actually required a fair amount of effort -- and civilized behavior -- to invent in the first place.

Re: Why OO Sucks by Joe Armstrong (2000)

#345

Post by hota_mazi » Mon, Apr 22, 2019, 7:25 PM UTC

jhomedall wrote: post #307

hota_mazi wrote: post #262

Earlier quoted context omitted.

Scala failed because it's the opposite of pragmatic. If you're looking for pragmatic, take a look at Kotlin. As for Scala 3, it's still years away, if it ever comes out. And when it does, there's little reason to think its goals will be different from what Scala 2 was (an academic language) since it's the same team as Scala 2 writing it.

In what way is Scala not pragmatic?

It's a language that's aimed more at research, producing papers for conferences, and financing the EPFL and its PhD students than at users in the real world.

There's absolutely nothing wrong with that, by the way, I love studying all the advanced concepts that Scala has pioneered over the years.

But it's also the reason why it's largely in decline and why Kotlin has taken the industrial world by storm: because it is a pragmatic language.

Re: Why OO Sucks by Joe Armstrong (2000)

#346

Post by Gibbon1 » Mon, Apr 22, 2019, 7:29 PM UTC

pjmlp wrote: post #237

Gibbon1 wrote: post #215

Earlier quoted context omitted.

> Python doesn't: o.x does not necessarily mean accessing an x slot C# also 'fixes' that. o.x could be a slot or it could be a getter/setter.

Initially seen in languages like Eiffel and Delphi.

I have basically no experience with Java. But in C# I think the above is whats behind stuff like

fooobj.events += my_eventhandler;

Re: Why OO Sucks by Joe Armstrong (2000)

#347

Post by alankay » Mon, Apr 22, 2019, 7:50 PM UTC

davidrupp wrote: post #298

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…

I think the inspiration from Simula I is something a lot of folks either don't know about, or maybe they know about it but don't recognize its significance. Objects with encapsulated state that respond to well-defined messages are a useful level of abstraction for writing simulations of the sort Simula was built for. They're just not automatically a particularly wieldy abstraction for systems that aren't specifically…

It's out of the context of this thread, but we were quite sure that "simulation-style" systems design would be a much more powerful and comprehensive way to create most things on a computer, and most especially for personal computers.

At Parc, I think we were able to make our point. Around 2014 or so we brought back to life the NoteTaker Smalltalk from 1978, and I used it to make my visual material for a tribute to Ted Nelson. See what you think. https://www.youtube.com/watch?v=AnrlSqtpOkw&t=135s

This system --including everything -- "OS", SDK, Media, GUI, Tools, and the content -- is about 10,000 lines of Smalltalk-78 code sitting on top of about 6K bytes of machine code (the latter was emulated to get the whole system going).

I think what happened is that the early styles of programming, especially "data structures, procedures, imperative munging, etc." were clung to, in part because this was what was taught, and the more design-intensive but also more compact styles developed at Parc seemed very foreign. So when C++, Java, etc. came along the old styles were retained, and classes were relegated to creating abstract data types with getters and setters that could be munged from the outside.

Note that this is also "simulation style programming" but simulating data structures is a very weak approach to design for power and scaling.

I think the idea that all entities could be protected processes (and protected in both directions) that could be used as communicating modules for building systems got both missed and rejected.

Of course, much more can and should be done today more than 40 years after Parc. Massive scaling of every kind of resource requires even stronger systems designs, especially with regard to how resources can be found and offered.

Re: Why OO Sucks by Joe Armstrong (2000)

#348

Post by AnimalMuppet » Mon, Apr 22, 2019, 8:32 PM UTC

ganonm wrote: post #43

I think this article is quite old, so I can forgive the author for being out of touch with modern OO language practices. Nonetheless, I find myself disagreeing with almost all of his arguments. When he talks about state for example, I assume he means mutable state. Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to…

> He also rails against private state specifically. I assume again that he means private mutable state. This is generally a bad idea and is accepted pretty uncontroversially as a bad idea.

Here's a program that has some mutable state. Do you want that mutable state to be private or public? Do you want anybody to be able to change it, or do you want all changes to have to go through public methods?

Given that there are programs that necessarily have mutable state, why in the world would you not want that state to be private?

Re: Why OO Sucks by Joe Armstrong (2000)

#349

Post by pjmlp » Mon, Apr 22, 2019, 8:57 PM UTC

Gibbon1 wrote: post #346

pjmlp wrote: post #237

Earlier quoted context omitted.

Initially seen in languages like Eiffel and Delphi.

I have basically no experience with Java. But in C# I think the above is whats behind stuff like fooobj.events += my_eventhandler;

It is, but those languages did it about 6 years before C# came into existence.

Which isn't surprising, given that Delphi took the idea from Eiffel, which share the same Pascal influence, and was designed by Anders.

Re: Why OO Sucks by Joe Armstrong (2000)

#350

Post by blub » Mon, Apr 22, 2019, 9:11 PM UTC

tombert wrote: post #292

blub wrote: post #247

Earlier quoted context omitted.

Functional programming has no relevance to the correctness of code. You'll notice that it's virtually unheard of to use any FP languages in critical software. Instead they use languages that lend themselves well to code reviews, static and dynamic analysis, model-based design and proofs, etc. Like C, Ada and some domain-specific stuff. The kind of "correctness in the small" offered by Haskel through its type system c…

>You'll notice that it's virtually unheard of to use any FP languages in critical software. Erlang powers around 40% of the world's phone networks; and if it's not mission-critical I'm not entirely sure what is. For that matter, Whatsapp is also written in Erlang and Jane Street does trading applications in OCaml. Without making a judgement on whether or not they should , both Whatsapp and Jane Street create very lar…

TLA+, SPARK, Frama-C, PROMELA, Astree, even plain C or C++ and a heavily safety-oriented process are used when correctness is important more than any of the FP languages you've mentioned.

In fact, by mentioning Erlang and Ericsson, you exhausted the only case supporting your point. Maybe if you tried hard, you could come up with a couple more. Now let's do the same exercise for the languages and tools I enumerated and it will take a long time until one runs out of examples.

WhatsApp is another perennial example in these discussions. I can accept it although there's nothing critical about a chat app - and once again it's rather an exception instead of the rule. Most chat applications are written in "not FP" programming languages and work just as reliably as WhatsApp.

In case it's not yet clear from the above, I believe that only tools which are used heavily in the industry deserve our attention, not obscure languages which haven't been put to the test and one off projects. The oldest trick in the FP argument book is finding some minor FP language to match any requirements put together by critics. So yes, I've heard of Idris and Agda - on HN - because barely anyone else uses them or talks about them. Coq is perhaps the outlier, because it was used to verify CompCert, but then again CompCert itself is used to implement a lot more things.

But Coq, Idris, Agda and so on are actually red herrings, because when people praise FP's correctness benefits, they refer to standard languages like Haskell, F# or OCaml for which there is in fact little proof that they have a significant effect on program correctness. Obsessively encoding information in the type system will reduce or eliminate some types of errors, but that's far from proving a program correct and really not that far at all from what's available in other standard, mainstream languages, for less effort, better support and a great ecosystem.