Live data from Hacker News

Joe Armstrong: Why OO Sucks

harmful.cat-v.org

191–200 of 267 posts

Re: Joe Armstrong: Why OO Sucks

#191

Earlier quoted context omitted.

"People should be required to learn the basics of programming first. They should start with immutable data objects" Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming". The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to p…

There's no need to redefine programming. There are essentially two fundamental ways to approach a program: what it does (coming from EE) and what it means (coming from math). If you're coming from the first perspective, than mutation is fundamental. Registers are always changing in value and everybody likes self-modifying assembly. However, if you're coming from the second direction--which is at least as fundamental…

Programming is about writing some code that does useful work. Okay?

When you argue that programming is something else, you're doing just that: redefining.

Because from the first days programming meant building computational devices or programming programmable devices. And those have changing state, and then they have machine code, which mutates state. It's how it always was and now some people want to redefine it but I say no to them. Programming is not CS. Programming is about producing programs. Historically and statistically programs are written to work by mutating their state.

Re: Joe Armstrong: Why OO Sucks

#192
post #54

Wow, I am genuinely shocked by the comments in this thread. I didn't realise that so many people held the polar opposite view to me. It's a bit like suddenly finding out that all your friends are racist. I love object oriented programming. For me it aligns perfectly with the way I think - it allows me to produce a system of interrelated 'things' where each thing (or group of things) has a well-defined role and can hi…

So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.si…

PropertySale is a thing. It should be modeled. You'll probably want to store some state with it (when the sale happened, to whom, the price, etc etc).

Re: Joe Armstrong: Why OO Sucks

#193
post #172

data structures and functions are very much related and connected. In fact, all data structures are invented to perform certain specific functions. OO is not the answer to all things, but it provides a natural way to fuse data structures and its associated functions together.

In this case, "function" means mathematical function rather than purpose.

Of course, if you want to take a somewhat reductionist approach, you could argue that data structures are functions. After all, in the lambda calculus, all you have are functions and you can use them represent numbers, pairs, lists, booleans, conditionals--basically whatever you want.

Re: Joe Armstrong: Why OO Sucks

#194
post #16

What about the benefits of abstraction? I'm not going to introduce hyperbole on how I think this article is overstated, and instead I'm going to ask HN members who have more experience with functional programming how they leverage concepts similar to abstraction with Haskell, clojure, or erlang, etc?

It's funny you should mention that--it seems Haskell usually gets accused of being too abstract. In Haskell, it's actually common to write very abstract code.

In fact, I think that is one reason why Haskell is tricky to pick up at first. OO "abstraction" is never that abstract--you can always tie it down to some concrete thing or idea. An iterable is obviously something you can iterate over, and that's about as abstract as you get.

Haskell, instead, finds its core abstractions in math. It uses ideas from abstract algebra and category theory that are more general than anything I've seen in OO. The core abstractions like the infamous monads, functors, monoids, arrows and so on are not easy to tie down to anything concrete at all.

For example, the standard functions that work on monads (like foldM) can work on a dizzying array of different types: functions, lists, nullables, continuations, errors, parsers, ASTs. Any given function like this does the same thing parametrized by the behavior of the type in question: so foldM always does a fold, but the exact behavior depends on the exact monad being used to do the folding. And there is no obvious relationship between the different behaviors that can be modelled this way.

In short: Haskell uses ideas from math to get very abstract code, for better or worse. These mathematical concepts can model a gigantic amount of different things which, intuitively, may not seem related at first.

Re: Joe Armstrong: Why OO Sucks

#195
post #183

Earlier quoted context omitted.

> Just because it is Functional Programming it does not mean to "throw away encapsulation". Surely not, as even Clojure has support for OO programming. But Rich Hickey says that 90% of the time that encapsulation is used by OO programmers, it shouldn't have been. Instead, they should have just used a map or a list, etc. So, does something as complex as representing a book fall into the 90% case or the 10% case? Or ma…

Even more - encapsulation is not always mean OOP. Erlang have encapsulation more strong than in any OOP language - all you have is server process and messages thrown to it.

How is that not OO then? OO is not defined by Java. The first OO languages and systems were descended from Lisp or built within Lisp, a functional programming language.

OO without inheritance is still OO. OO with immutability is sill OO. Encapsulation is the heart of OO. Polymorphism is also quite important. Inheritance is a distant third property of OO, but it is one common aspect of OO that is highly over-used. Most OO "best practices" gurus discourage rampant use of inheritance these days and say to prefer composition.

Back to the whole point of this thread, Rich Hickey says specifically NOT to use encapsulation (90% of the time). That would then not be OO. No encapsulation, no OO.

Re: Joe Armstrong: Why OO Sucks

#196
post #50

I can express my OO ideas in erlang with no problem (objects become processes). I cannot express my concurrency ideas-- that erlang makes super easy-- in the OO languages. Maybe Go changes this but I haven't used Go yet.

Agreed that processes in Erlang is even better objects than objects in OOP.

>>I cannot express my concurrency ideas-- that erlang makes super easy-- in the OO languages.

In fact main Erlang ideas are many times "stolen". I discover Erlang in: Scala (obvious), F# (also obvious), D (also obvious).

Actors + messaging = "DIY Erlang".

Although I do not know a language that makes code hotswapping as fundamental feature.

Re: Joe Armstrong: Why OO Sucks

#197
post #145
post #74

Earlier quoted context omitted.

Instead of giving you an example that anybody actually uses, I'm going to tell you about a cool idea I've been reading about that hasn't gotten much actual use. The basic idea is to use a generalization of pattern matching. Languages like ML and Haskell support pattern matching, but in rather limited ways. Crucially, patterns are not first-class citizens of the language. (For Haskell, at least, there are some librari…

TBH, looks like the only hard bit here is fiting static typing into your system. I believe the dynamic languages with pattern matching facilities (erlang, echeme) should already be able to pass any symbol they want for the constructor name.

Yes, they can use any symbol. But I don't think they can match against a constructor (that is, write a pattern like (x y) where x can match any constructor).

Also, I don't think they can have dynamic patterns. That is, you can't take part of a pattern, pass it into another pattern and use the resulting combination of patterns to match against some value.

These two things are the interesting generalization of pattern matching that I was talking about.

Re: Joe Armstrong: Why OO Sucks

#198
post #9

I don't get it. If people don't like OO, why don't they just not use it. Just use your favorite methodology to get the job done. Why do they have to bad mouth it?

OOP as collection of some practical principles to structure code - is good.

But mandatory OOP and OOP as religion is something unforgivable for me.

Re: Joe Armstrong: Why OO Sucks

#199

Earlier quoted context omitted.

There's no need to redefine programming. There are essentially two fundamental ways to approach a program: what it does (coming from EE) and what it means (coming from math). If you're coming from the first perspective, than mutation is fundamental. Registers are always changing in value and everybody likes self-modifying assembly. However, if you're coming from the second direction--which is at least as fundamental…

Programming is about writing some code that does useful work. Okay? When you argue that programming is something else, you're doing just that: redefining. Because from the first days programming meant building computational devices or programming programmable devices. And those have changing state, and then they have machine code, which mutates state. It's how it always was and now some people want to redefine it but…

Turing machines have mutable state. The lambda calculus does not. Yet any algorithm which can be expressed by one can also be expressed by the other. We have proof that state is merely an implementation detail, which happens to be widespread in today's hardware because we figured out how to implement it at scale.

Programmers need to understand the difference between the abstract algorithm they're trying to express and the representation they've chosen (and the ones they didn't) inside the computers they're using, just as astronomers need to distinguish between the stars they study and the measurements coming out of the various telescopes they can choose.

Re: Joe Armstrong: Why OO Sucks

#200

The people who originally came up with OOP knew what they were doing. The inspiration was the cell, which hides immense mechanical complexity behind a simpler interface of electrical and chemical signals. When interfaces are simple, it limits the unexpected dependencies that can exist between software modules. Alan Kay wasn't saying, "Go off and write bloated objects" but, "When software must be complex, strive to pr…

"People should be required to learn the basics of programming first. They should start with immutable data objects" Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming". The whole text you just wrote is full with dumb self-praise and deprecation of others; based on worship of principles that were never proven to p…

>Immutable data objects and all the stuff are not the basics of programming. They never were. Unless you single-handedly redefine the meaning of "programming".

Immutability was considered to be more fundamental when I took my first programming course at MIT. I received a very good education.

We, of course, eventually moved onto objects with mutable, but they were definitely considered to be more dangerous and less fundamental.

Post reply on HN