Live data from Hacker News

Joe Is Wrong (2009)

goran.krampe.se

21–30 of 86 posts

Re: Joe Is Wrong (2009)

#21
post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

A paricular point people don't get is that Java joined functional programming instead of beating it.

The Hotspot compiler was based on a research runtime for a functional language. Type inference is basically the same as ML family languages. With heavy use of Lambdas and higher-order functions some of my Java looks like ML. If i want to have functions like

   maybe(x, f1, f2, ...)
that works (emphasis) like the maybe monad my codegen writes the boilerplate out to arity 30. (Funny the codegen lets you write Java in a Java DSL that looks like typed S-expressions.)

Re: Joe Is Wrong (2009)

#22
Imagine being a Smalltalker and still missing the underlying context of Joe's article - specifically, around the actor model (as used extensively in Erlang) being substantially closer to OOP as intended by e.g. Smalltalk than to the popularized inheritance-heavy brand of "OOP".

You can see this in the objections:

> Objection 1 - Data structure and functions should not be bound together

...and yet the usual way to store data in Erlang is to make it an argument of a function repeatedly and recursively calling itself.

> Objection 2 - Everything has to be an object.

...which is the case in Erlang/OTP, when you consider that everything is a process a.k.a. actor a.k.a. object. And just like with Smalltalk, these objects communicate via messages.

> Objection 3 - In an OOPL data type definitions are spread out all over the place.

...as they are in Erlang, because (barring some bolted-on approaches like records) data type definitions exist entirely as patterns to be matched.

> Objection 4 - Objects have private state.

...as do Erlang's processes.

That is, while maybe Joe didn't pick up on it at the time (per comments on that article: https://news.ycombinator.com/item?id=26586829), it's clear that said article was more a complaint against OOP as popularly envisioned, with all its classes and inheritance and such - not against the notion of object orientation entirely, which Erlang happens to implement, even if it might've been by accident.

Re: Joe Is Wrong (2009)

#23

The thing I find interesting about revisiting these old pieces is that the debate about the merits of OOP is effectively stymied. This post and the article it replied to posted yesterday ( https://news.ycombinator.com/item?id=26586829 ) could effectively have been written today. And the debate in the comments tends to be pretty formulaic as well. It's one of those perennial topics that generates a lot of heat from re…

> you see the same four or five topics come up repeatedly with nothing new or interesting said on them. Thousands of humans are born every day, and by the time they get to be programmers they must have learned about all these topics. "Coming up repeatedly to them" is necessary for that. Education is one of most fundamental activities of mankind, and it is based on having the same discussions again, and again, and aga…

I don't think criticizing the repetitive nature is absurd but maybe it's fruitless. My meta point isn't really to make people feel bad about taking part in these debates but to question whether we can get more out of them.

And whilst I agree that new people learning about things can be an effective trigger for rehashing these arguments I don't think all the people who so happily engage in them are new to the argument. In fact I think the constant rehashing of them is mostly the cause of new people learning about the argument in the first place. So in that sense they could be useful (if the argument is actually useful).

Re: Joe Is Wrong (2009)

#24

The thing I find interesting about revisiting these old pieces is that the debate about the merits of OOP is effectively stymied. This post and the article it replied to posted yesterday ( https://news.ycombinator.com/item?id=26586829 ) could effectively have been written today. And the debate in the comments tends to be pretty formulaic as well. It's one of those perennial topics that generates a lot of heat from re…

Why would you want to revisit these debates, having progressed beyond them? :) Instead of rehashing "Is OOP good, actually?", we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. If we get inspired, maybe come up with som…

> Why would you want to revisit these debates, having progressed beyond them? :)

A moment of zen like grumpiness where I was motivated to complain about it.

And yeah I totally agree that the PL grudge match is better solved by experimenting with paradigms than drawing battle lines on a forum. I was aiming at being even more meta though.

Re: Joe Is Wrong (2009)

#25
post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

An entire generation of programmers were brought up on languages which took an orthodox view on this (Java, C#, though they're both better at it now).

Add to this all the books and seminars or OOP, patterns, etc. and in some circles it's impossible not to code in the strict "break everything apart" OOP style

Re: Joe Is Wrong (2009)

#26
There's a fundamental problem with this kind of debates. Because we don't have a lot of empirical data and because human interaction is complex and often unintuitive, we don't have a good theoretical model of how the development and maintenance process actually works, the arguments tend to be based, in the best case, on unrepresentative and biased samples, and in the worst case, on personal aesthetic preference. And when we look at empirical data in the field, obviously whichever the dominant paradigm is, it will show the actual effect of programmers and shops at wildly different skill levels using it, while the non-dominant paradigm won't be able to show success at doing things better because, well, it doesn't have enough people at different skill levels using it.

Re: Joe Is Wrong (2009)

#27
post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

I love this take. Programming techniques are that, tools on our belt. One should neither fall in love with a particular one, nor try to use it exclusively. Either it fits, meaning it provides advantages that outweigh the added complexity, or it doesn't.

Re: Joe Is Wrong (2009)

#28
post #7

Much of the debate or criticism of OO have been targetted at the theoretical side of object orientation, and perhaps less towards the practical implementations, which allows for some flexibility in the programmers approach to objects. I would like to see someone do a language that enforces all of the OO paradigms and best practices on the programmer, just to see what the resulting code would look like and behave. For…

The problem is that the "OO paradigms and best practices" are not formally defined, so the program that would enforce them on you cannot be written. OOP was unfortunately never defined formally enough to be amenable to this approach. (For example there are different interpretations of Liskov substitution principle.)

There are strongly-typed functional languages that are based on a consistent formal foundation, like Haskell, so you can look into these. But there are still some "escape hatches", because sometimes you just need them.

Re: Joe Is Wrong (2009)

#29
Good quote by Pike (2004):

The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. “Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?” Great, nice chair. But will you notice the grain when you’re sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood.

Re: Joe Is Wrong (2009)

#30

The thing I find interesting about revisiting these old pieces is that the debate about the merits of OOP is effectively stymied. This post and the article it replied to posted yesterday ( https://news.ycombinator.com/item?id=26586829 ) could effectively have been written today. And the debate in the comments tends to be pretty formulaic as well. It's one of those perennial topics that generates a lot of heat from re…

I think the core issue is that OO is one of the first “solve everything” paradigms most programmers learn. Lots of good programmers I know (myself included) have spent a year or two of our careers convinced OO is the solution to every programming problem ever, because it feels so powerful. Some programmers never grow out of that phase.

And that means there’s an OO shaped standing wave in the pool of programmers. Each year the OO wave is made up of different people, but the wave itself is always there because there’s always a new generation of programmers going through their baptism of classes. We have to keep reposting Joe Armstrong’s rant because the sooner people learn non-OO paradigms, the better our field is for everyone.

These debates only feel like zombies to some of us because we’re old, and we’ve yelled at the kids for overusing classes on our lawns plenty of times already. There are some other interesting conversations - like, where is the line between when you would use OO or bare structs or FP? But those conversations are fuzzy and nuanced, and hard to have without real code examples.

Post reply on HN