Live data from Hacker News

Joe Is Wrong (2009)

goran.krampe.se

1–10 of 86 posts

Re: Joe Is Wrong (2009)

#2
What I've found with all these "paradigms" is that they're only beneficial some of the time, usually not most of the time, never all of the time. It takes some experience and and an anti-dogmatic attitude to judge, for example, when a black box is a good choice and when plain old data is a good choice. Woe to those who attempt to shoehorn their idea of purity unto every application domain they encounter.

Re: Joe Is Wrong (2009)

#3
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 rehashing tired arguments without generating much light in terms of new thoughts.

There are a bunch of topics like this, in my own area you see the same four or five topics come up repeatedly with nothing new or interesting said on them.

I'm kind of intrigued if anyone has any thoughts on how to shock life back into these zombie debates?

Re: Joe Is Wrong (2009)

#4
In my experience, when you have a field with two popular but different options and a lot of strong opinions about which is good and which is crap, neither side is right. Both sides have merit, otherwise they wouldn’t have a following. Examples: functional vs object-oriented programming, Ruby vs Python, Mac vs Windows, AC vs DC, rock vs pointy stick.

Re: Joe Is Wrong (2009)

#5
Here's a Jan 2008 archive link for the article being responded to: https://web.archive.org/web/20080112111747/http://www.sics.s...

I'm surprised that the original anti-Object Oriented Programming article says "data structures and functions should not be bound together" since in functional programming (if we take that as the extreme opposite of OO) they are still kinda bound together. Like if you have a JS array ['cricket', 'football', 'badminton'] it is both data and almost like a function at the same time, since you can iterate through the items and make code execute for each

For example in a webpage if there is a div id=football then you can select it using:

['cricket', 'football', 'badminton'].forEach(function (i) { document.getElementById(i); } );

In my mind this type of code really blurs the line between variables and functions

Re: Joe Is Wrong (2009)

#6
I think the conversation around OO suffers from the same problem that any major engineering trend suffers from: namely that eventually, the concept gets conflated with the way that enterprise software and overpaid consultants completely fudge the implementation of the concepts. Consultants get paid big bucks trying to convince your company that you need to be doing microservices or OO or nosql or whatever the latest fad is and that you need them to help you implement it. It’s not based on any real technical need. It’s just institutional FOMO.

OO has it’s place in the space of possible patterns to choose from based on the kind of solution you need. I think these overarching claims of superiority are missing the point completely. I personally like a combination of function and OO concepts that can work synergistically together and play the kind of role that they excel in individually.

Re: Joe Is Wrong (2009)

#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 instance, I'd love to see a compiler than throws a error if you violate the single responsibility principle. Much of the OO spaghetti code I've seen have been because objects are basically just structs with methods and 10 different ways and object could change state.

For practical purposes I doubt I'd ever use such a strict language, but it would be interesting to see if the result is safer and clear code. I suspect it's more code though.

Re: Joe Is Wrong (2009)

#8
Joe's original rant can be found here: http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

I can see that Erlang and Joe's (RIP) insights about OO might conflict with your view of the world, but IMHO that's just because of the OO indoctrination people grew up with.

Recommend learning key concepts of OTP/Erlang/Elixir first, and then revisit your initial opinions.

You might even conclude Joe Was Right

Re: Joe Is Wrong (2009)

#9

What I've found with all these "paradigms" is that they're only beneficial some of the time, usually not most of the time, never all of the time. It takes some experience and and an anti-dogmatic attitude to judge, for example, when a black box is a good choice and when plain old data is a good choice. Woe to those who attempt to shoehorn their idea of purity unto every application domain they encounter.

This is what I wanted to write. There's a bunch of tools in programming, as in any field. There's no tool that's right for every job or wrong for every job.

Sounds boring, but judgement is what the work is about. When you're talking about a specific system you can say "I think we should use OO for this" because so-and-so. But each system needs its own explanation.

Re: Joe Is Wrong (2009)

#10

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 some new pattern or language affordance that's similarly groundbreaking to functions, objects, classes, message-passing, threads, or whatever. Maybe the obviously-better development paradigm of 2050 hasn't been articulated, yet.

Post reply on HN