[meheleventyone]

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?

[josephg]

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.

[dmux]

>...those conversations are fuzzy and nuanced, and hard to have without real code examples.

This rings true to me. I've dabbled in several languages but started out with Java and for the longest time its style of OOP was how I approached building systems.

In the last 2 years though, I've had the opportunity to work with Typescript and it's been really nice choosing what approach you want to take (structs, functions, or objects). I've found that starting off with plain structs and functions has let our systems grow in a way that would have been constrained by Classifying things up front -- you really _do_ learn more about your application as you're writing them, so why paint yourself into a corner by dictating what data and operations have to go hand in hand upfront?

[enriquto]

> 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 again. You are not supposed to participate on all these instances of the same discussion, but criticizing them for being repetitive is absurd. Most of the time there is really nothing new to say.

[meheleventyone]

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

[BeefWellington]

IMO this is an example where both parties can be right and wrong at the same time. "Correctness superposition" if you will. I have come to think of programming languages themselves a bit like art. Take fiction for example; Arguing about the "provably best way" the thing the programmer is typing should look is a bit like arguing which writer is the greatest. Everyone's going to have an opinion and the only thing the majority will agree about is when an author is really terrible.

When I started out programming it was all straightforward procedural languages, working up to C eventually. It took me a bit to figure out why OO was this big new shiny thing everyone loved when I first started to learn C++ and Java. Eventually I understood that the strength was around having functions that manipulate the state tied directly to the struct carrying that state was handy and saved a lot of type checks and variable passing for the programmer.

Java and C# are good examples of languages where there's a straightforward admission that everything can't be OO. Static methods are pretty non-OO in their conception but even if you wanted to argue they fit, how many projects eventually wind up with a `public static class Utils` or end up shoveling in extension methods in C# to accomplish some common task that in C would just be an include and then calling the function directly.

[randallsquared]

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.

[meheleventyone]

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

[jt2190]

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

JavaScript? ;-)

[randallsquared]

I can neither confirm nor deny that I had any particular languages in mind... but, yeah, having slightly or wildly different takes on various patterns can help us explore the practical consequences. I would suggest that the history of JS is good evidence that prototypes are harder to use and reason about than classes.

[meheleventyone]

You joke but I think TypeScript's structural typing is really cool and has a lot of neat advantages of nominal typing.