Ten years from now we’ll be flooded with takes that FP is wildly overrated and the One True Way To Program is to use… I dunno, zarbomographic programming. And people will have to write “The case against FP is wildly overstated”. The pendulum swings eternal.

The gap between theory and practice has fueled the interest in design patterns. As OOP became more popular, programmers looked to them for help with their achitecture. Unfortunately, design patterns can easily become a way to smuggle in overly complex OOP design under a veneer of respectability.

People conflate design patterns with OOP, but every paradigm has design patterns. Should you use free monads or monad transformer stacks?

Requires a sign-in to read. Unread.

The case against OOP is not that it is impossible to write good OO code, but that OOP encourages people to abuse bad design and bad patterns, which the author seems to concede. The article makes an argument similar to someone who says it’s possible to write eg Ruby without type errors: of course it’s possible, but the language makes it harder than other languages, which is the whole brunt of the criticism.

The differences between functional and OO might not be as big as you think. My favourite object-oriented language is Erlang. It’s not OO, you say? Processes encapsulate state and work through message passing; that’s basically an actor system. (Indeed, a lot of OO languages are essentially architecting distributed systems without the distributed…)

Just gonna take one potshot at the new merged article:

Are you sure about polymorphism? First of all you took it from type theory and that’s itself getting popular featuring stable forms of parametric polymorphism, while your version of polymorphism is shifting shape like crazy.

You have it backwards. ML cited CLU’s type system as inspiration, which cited SIMULA as inspiration. Parametric polymorphism may be more elegant in typed FP, but from a historical engineering perspective it migrated from OOP to FP.

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing - is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil - objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

My take is that the claimed advantages are not really delivered by OOP. From the website:

• Encapsulation: Most OOP languages leak trivially avoidable implementation details to the caller (like whether some member is a field or a no-arg method).
• Inheritance: Usually not that useful.
• Polymorphism: Parametric polymorphism is often superior to OOP’s subtype polymorphism.

I don’t have anything against OOP, but it is definitely oversold.

In the end, just stop making everything mutable, and I can largely live with it.

I’d be curious what you think of this talk.

It includes clips of interviews from decades ago from some of the originators of OOP as we know it today, talking about what their goals were and how they aimed to achieve them.

https://youtu.be/6YbK8o9rZfI

This is a defense of OOP by redefining OOP, essentially “Yes, inheritance and trying to model the world with classes are bad, but that’s not what OOP means, OOP means DRY and YAGNI and the law of demeter continuous refactoring and valuing simplicity above all else” seems like sophistry to me. The OOP moniker has no claim to DRY and YAGNI and refactoring and simplicity above any other paradigm.

Very good article. I agree with the “original sin” of trying to model the real world. That may work in some particular cases (CAD programs), but doesn’t apply to most of code I’ve seen and worked with.

Roughly, I think about writing the most straightforward procedural code, and then refactoring it so state and I/O are explicit (dependency inversion). That naturally creates good class boundaries for the code.

In systems code, distinguishing between I/O and computation, and code and data, is very important. For one, parallelism essentially forces you to distinguish code and data (to prevent races). Instrumenting systems code often means instrumenting I/O.

This part:

An object is a programming construct that lets you pack together data and functionality in a somewhat reusable package. Some objects may be structs by another name. Other objects may simply be libraries of related functionality.

echoes something I’ve said and I haven’t heard anywhere else:

https://lobste.rs/s/lwopua/functional_code_is_honest_code (Functional Code is Honest Code)

I use “functions and data” (a la Rich Hickey).

Except my functions and data are both CLASSES. Data objects are basically structs, except they can do things like print themselves …

Function objects are simply classes with configuration passed to constructors.

Java also has some particular deficiencies that have been cleaned up by newer languages:

• Kotlin adds “data class”, which are values (equality, hashing, printing)
• I think Scala case classes are pretty similar
• Python also added dataclass late in its life. This was also a deficiency, but Python at least has tuples and dicts, and free functions, so you weren’t forced to put everything in a class. Java didn’t have this.
• Java lacks free functions. It confuses classes and namespaces, which is extremely miseadling and leads to bad design (which I’ve seen many times in real life). In the way I use Python and C++, classes and namespaces are very much distinct and orthogonal.

So as the article says, there are lots of real problems with OO, but people are learning.

The situation is analogous to Evolution of a Haskell Programmer – within the same language / paradigm there are dozens of ways to express yourself, some good and some bad. (Which the article also says)

Yah I just think it gets used in a lot of places where the code should be polymorphic instead.

I think a bit problem with OOP is that it’s very vague. Either you have that box of things that relate to OOP (the four pillars from the article) when you come out of school. Or you have more a Smalltalk style understanding of OOP or it’s about concepts and use object oriented approaches to solve problems in languages that are not labeled object oriented, for example regular C.

So in discussions people end up meaning different things.

Another more generic problem that is not at all only true for OOP, but pretty much for all instances of trying to define “good code” is that people will simply make use of things like language features or blindly making everything a singleton, huge class hierarchies, etc. So even when there is a well-intended suggestion by an experienced developer or some blog article it can result in over-use and hard to read, maintain and debug code.

Other examples of this are blindly following code linter output, working around them in non-idiomatic ways and not fixing underlying and systemic issues that might even lead to the linter output. Or overusing, potentially misusing language features, gorutines in Go, lambdas in every language getting them or promises in JS for non-async code or very complex iterative .map()-calls relying on side effects for example.

I think a reason for this being such a big topic in the case of OOP is that it is taught in universities, often as one of the first things and frequently using Java (and sometimes Python). Nearly everyone who went through some kind computer science class will have been through this, even if they end up in a different field or in a very specific subset of the field.

In the end it will be the thing people will agree on, because that was what they did back in school. And programming at university of course has a tendency to focus on something that makes it easy to check if certain, individual concepts have been understood. Depending on where you head after that initial contact, that might even out, but that’s certainly not everyone.

After all designing and implementing software is a challenge and when the target might be moving or not clear at all one clings to those easy rules that even when they apply in many or even the majority of cases might be the very wrong path for the particular case and especially when there is time pressure, no prototyping and the problem is not well understood even the best programmers and even whole groups of them might end up making big design mistakes early on.

Maybe OOP (and individual parts) should be taught later and/or there should be more explanation of it being a tool in a large set of tools. Also it might be a good idea to point out there have been quite a lot of studies about how different programming paradigms (and languages btw.) don’t appear to have significant differences in quality - by various definitions of quality.

Is it just me or are this and the article this replies to, essentially arguing for the opposite nor that their titles claim?

Previous discussion of The Case Against OOP is Wildly Overstated on Lobsters: https://lobste.rs/s/bmzgvz/case_against_oop_is_wildly_overstated. It looks like the posting of another response article, Case against OOP is understated, not overstated, was merged into that Lobsters story as well.