OOP is not that bad

https://osa1.net/posts/2024-10-09-oop-good.html

by thunderbong • 2 years ago

143 288 2 years ago

dboreham• 2 years ago

Although short, this article is quite interesting because it presents code examples from "both sides" and the author seems to have a good understanding of both.

sbergot• 2 years ago

Except it is biased in its conclusion:

However, unlike our OOP example, existing code that uses the Logger type and log function cannot work with this new type. There needs to be some refactoring, and how the user code will need to be refactored depends on how we want to expose this new type to the users.

It is super simple to create a Logger from a FileLogger an pass that to old code. In OOP you also need to refactor code when you are changing base types, and you need to think about what to expose to client code.

To me option 1 is the correct simple approach, but the author dissmisses it for unclear reasons.

bhouston5• 2 years ago

I changed my mine on this. I did OOP since the mid-1990s when I learned it in high school up until about 10 years ago. I find OOP works best when you have a single coder who can store the model of the system in this mind and work out how to design the base and abstract classes well. And they also have freedom to refactor THE WHOLE CODEBASE when they get it wrong (probably multiple times.) Then you can make these webs of elegant ontologies work.

But in real life, when there is a team, you run into the fragile base class [1] constantly and changing that base class causes horrible issues across your code base.

I have found that OOP with inheritance is actually a form of tight coupling and that it is best to not use class hierarchies.

I agree with encapsulation and modularity and well defined interfaces (typed function signatures are amazing.) I just completely disagree with inheritance in all forms.

There are no benefits to it (besides feeling smart because you've made an elegant but ultimately brittle ontology of objects and methods), just a ton of downsides.

[1] https://en.wikipedia.org/wiki/Fragile_base_class#:~:text=The....

piva00• 2 years ago

Similar thinking, I've been through much pain from a class hierarchy degrading into an unusable mess, also done a lot of rework refactoring those and it doesn't pay off.

Instead of inheritance I much rather prefer the composition approach, not extending classes but defining interfaces for the API, using other classes in the composition of an object rather than relying on overrides/implementations from a base class. It's much clearer to reason about (no more 3-4 layers of indirection), easier to refactor as well.

000ooo000• 2 years ago

I have found that OOP with inheritance is actually a form of tight coupling and that it is best to not use class hierarchies [..] I just completely disagree with inheritance in all forms

This is pretty common advice (at least IME), usually distilled into the form "prefer composition to inheritance".

bhouston5• 2 years ago

This is pretty common advice (at least IME), usually distilled into the form "prefer composition to inheritance".

I think this is why in the current JavaScript era, it is rare to find a popular library that makes significant use of inheritance (as opposed to just supporting interfaces) even though it is supported in the language.

ThreeJS is one of those exceptions, but they are few and far between.

arresin• 2 years ago

Exactly my thoughts. When I started really getting functional programming it was a breath of fresh air. For me the test is not just how fast someone else can pick up the codebase but how fast I can remember how it all works in n years.

ninetyninenine22• 2 years ago

I have found that OOP with inheritance is actually a form of tight coupling and that it is best to not use class hierarchies.

Tight coupling is the basis of oop. A method is tied to an instance. Methods cannot be composed with other methods or functions without instantiating state. Methods cannot be moved into other scope.

The literal definition of an object is a tightly bound set of methods that cannot ever be used without instantiating state.

the_af7• 2 years ago

I don't think a method being tied to an instance is the best case for calling it "tight coupling".

OOP can be used to design relatively uncoupled systems.

One of the lessons learned in all these decades is what the grandparent post alludes to, which is distilled into "prefer composition over inheritance". Implementation inheritance (as opposed to interface inheritance) indeed introduces coupling and is therefore discouraged in current advice.

chucksmash• 2 years ago

Tight coupling is the basis of oop.

This is not what OOP people are talking about when they talk about tight or loose coupling though.

They are talking about the relationship between classes.

echelon• 2 years ago

Coupling behaviors to types is not a problem. Class inheritance and multi-inheritance with their weird taxonomical trees are the problem.

There's little practical reason to build a family tree of supertypes and subtypes outside of building GUIs, yet this is how class-based OOP is designed and taught.

Trait-based OOP gets this right. The hierarchy is completely flat. You simply implement the behaviors for the types you want and don't have to think about grandparent behavior and final interfaces.

nsonha6• 2 years ago

obviously when they refer to loose coupling, they're refer to that between interface and hidden states/implementation of object.

It's very easy to deliberately miss the point and complain about the "tight coupling" that, by design, prevents messages to be sent to/called upon invalid states, which functional programming also has, albeit with different a approach using static type inference & pattern matching.

DeathArrow16• 2 years ago

Tight coupling is the basis of oop.

But then we invented inversion of control principle to remove that tight coupling. :)

moffkalast• 2 years ago

My thoughts as well. Inheritance forces you into spaghettification sooner or later if you didn't consider everything you'll ever need from the start to the end of the universe. Even if you're working on it by yourself the refactors become frequent and take too much time for little gain.

Self contained encapsulated parts with an eventbus for entirely decoupled data propagation are much easier to manage and edit. Just duplicate a bit more than you think would be best to reuse, disk space is cheap and if you get that part wrong you're screwed and will need another rewrite.

And it's probably more performant too with newer hardware since you can usually just spin out any self contained part as its own thread if need be, often with almost zero changes.

bluGill3• 2 years ago

I have found that OOP with inheritance is actually a form of tight coupling

You are not the only one. Prefer composition to inheritance is a saying for a reason. Inheritance is powerful and useful for small problems, but as you say it introduces tight coupling and so should only be used where that is intended. Tight coupling isn't always bad, but it is bad often enough to avoid it.

ajuc9• 2 years ago

I find OOP works best when you have a single coder who can store the model of the system in this mind and work how out to design the base and abstract classes well.

When all the states of the program and all the transitions between them fit into one programmer's head - every programming paradigm works well.

bhouston5• 2 years ago

Good observation. That makes my statement is an even worse condemnation of OOP that I thought.

ravenstine• 2 years ago

I totally agree that class hierarchies are mostly a trap, especially when there's more than one developer on a project.

What I don't understand is why many programmers still use classes even when they plan on avoiding inheritance. I've seen this sort of thing on the past few major projects I've been involved with; initial creators heavily relied on inheritance, future developers realize that was a mistake, then said future developers continue using the class construct of whatever given language.

At that point, why not just use functions and regular objects? Without inheritance, classes tend to have these other rules and complications that don't seem to really add anything when there is no hierarchy.

bhouston5• 2 years ago

At that point, why not just use functions and regular objects? Without inheritance, classes tend to have these other rules and complications that don't seem to really add anything when there is no hierarchy.

I have done this myself. In TypeScript I would write a class that supports an interface. There is no hierarchy, but writing as a class gives it structure, a clear name, you know how to instantiate it, what it supports, private methods, private state, static functions, etc. So I find that classes still do great encapsulation for mutable objects.

AnimalMuppet5• 2 years ago

OO was created for a reason.

Before OO, you had these data structures, and they got passed around between functions. Well-designed data structures were not just a random collection of items - they had a relationship between the elements. And you kept finding structures that were in an invalid state - the relationship among the elements had been broken. Well, who did that? You couldn't tell. It could have been any function anywhere in the code that took the structure.

With OO, you could have a very small set of functions that could change the structure. If the constraints got broken, you had a very small footprint to look at to see how it could have happened. That was the OO advantage.

And this advantage did not go away with multiple programmers. In fact, it increased. If you had a class that you "owned", some other new (or incompetent) programmer could not break your code without changing that class's code. You didn't have to rely on everyone else always doing the right thing with your structure.

Note that this advantage is orthogonal to inheritance vs. non-inheritance.

globular-toast• 2 years ago

A useful rule is not to extend a class you don't own. This is usually taken to mean don't extend a class from a third party library. But it should also mean classes that are shared by multiple developers. In that case, compose, don't inherit.

DeathArrow16• 2 years ago

But in real life, when there is a team, you run into the fragile base class [1] constantly and changing that base class causes horrible issues across your code base.

And then you start writing unit tests for everything and wait 10 hours for building and deployment, which is a good thing because your employer will need more people to do the work. Or you can't fix a bug without creating other 10 new bugs, which is a good thing because your employer will need you to solve that 10 new bugs.

OOP keeps people employed. :)

whobre• 2 years ago

It’s pretty bad, actually. Especially the Smalltalk/Objective-C flavor with its late binding and messages

ildon• 2 years ago

I noticed there's an entire paragraph explaining what OOP is, but it might be helpful to clarify that OOP stands for Object-Oriented Programming. Even though it's a well-known acronym, adding that explanation could benefit readers who are new to the concept.

Tempest1981• 2 years ago

I remember the early days of HTML, when people excitedly used hyperlinks to define acronyms.

userbinator• 2 years ago

In moderation, yes. The problem with OOP, like all other paradigms that came before, is applying it dogmatically and excessively, which always happens when there's a lot of hype, novelty, and $$$ to be made.

hk1337• 2 years ago

I agree but "moderation" isn't the best word. OOP is good when used appropriately and not when you fixate that everything has to be within the OOP structure.

It's the same thing with languages, IMO. People try to shoehorn tasks into a language when it would be better off in another language.

loup-vaillant9• 2 years ago

OOP is good when used appropriately

What are its appropriate uses? The more I program the fewer I see.

faizshah• 2 years ago

I think bad OOP is still better than bad functional code. Having seen what happens when a React codebase reaches >100k LOC are we really any better off than a class hierarchy?

The OOP model fits nicely into most people’s heads because of the analogy to the real world and OOP implementations generally seem to give better signals when you are doing something wrong. Rather than functional implementations which mainly rely on human expert code reviewers and linters to give negative signals instead of say exception hierarchies.

A lot of the time you don’t realize your codebase is bad until “it’s just a button how hard can it be” somehow takes 3 months and 4 rollbacks.

At least this is what I have observed working on large codebases.

veidelis• 2 years ago

I assume you're talking React's hooks. That is not functional programming.

gorjusborg3• 2 years ago

The OOP model fits nicely into most people’s heads because of the analogy to the real world

It also has been the default programing language paradigm for a while now, which I think explains why experienced programmers can cling to it despite its drawbacks. Try to teach object oriented programming to a beginner and it becomes clear that it isn't as natural as you are suggesting.

generally seem to give better signals when you are doing something wrong.

Better than what? Functional programming is a far simpler abstraction: a function. Data in, data out. That's about as simple as it gets. Also, culturally, functional programmers generally understand the downside of distributed state, and actively try to minimize it. That's a good thing.

Bad code is bad code, but OOP gives you unique weapons to hurt yourself with. Inheritance allows one to change an unbounded number of objects without you even knowing. Modeling everything as a collection of objects with state tends to lead to programs that need to synchronize distributed state rather than a central state that is easier to keep consistent.

Fire-Dragon-DoL• 2 years ago

That's because the programming language used is not FP, even if people pretend to.

Js is still stateful everywhere, even where you don't want it to be

wiseowise• 2 years ago

Having seen what happens when a React codebase reaches >100k LOC are we really any better off than a class hierarchy?

I’m not sure if you correctly understand what functional programming is.

Check out Grokking simplicity, great book.

DeathArrow16• 2 years ago

The OOP model fits nicely into most people’s heads because of the analogy to the real world

Nothing in real world resembles OOP.

kerand• 2 years ago

The GoF book did a lot of damage. I've finally read it and was amazed that the entire book is in fact about writing GUIs, which is just one tiny part of programming.

Several patterns are trivial, others are very similar and are just a linked list of objects that are searched for performing some action.

The composition over inheritance meme in the book does not make things easier (there is no "composition" going on anyway, it is just delegation).

Objects themselves for resource cleanup like RAII are fine of course.

rileymat2• 2 years ago

Some people will say that the book is not a training guide but a naming guide for patterns (or antipatterns) people already were using with success.

coliveira3• 2 years ago

Agreed, OOP became 10 times worse after the GoF book. People started to see these patterns everywhere, and mutated fine looking code to conform to that expectation. Just compare Java classes and interfaces when the language was created (most of that based on previous experience with Smalltalk) and the hot mess that was invented after GoF was released.

marcosdumay3• 2 years ago

OOP is entirely about writing GUIs. (Well, the C++ idea of OOP.)

It's a much larger part of programing than most people give credit, but yeah, it's only a part.

Anyway, the GoF book is about getting good abstractions from the 90s limitations in OOP languages. Nobody should read them now, except for historical reference.

AnimalMuppet5• 2 years ago

OOP is entirely about writing GUIs. (Well, the C++ idea of OOP.)

Nope.

One thing I like to do in C++ is, on an embedded system, wrap an object around a hardware resource. It means that no other code needs to know about the details of talking to that hardware. Also, if there are multithreading concerns, it leaves a very small set of places to worry about mutexes.

pjmlp2• 2 years ago

Not at all.

C++ was originally designed as Bjarne Stroustrup was in the process to create distributed applications in UNIX at Bell Labs, and after his downgrade experience from Simula to BCPL he wasn't touching raw C for such purpose, thus C with Classes was born.

There were zero GUIs in the early days of CFront.

whstl9• 2 years ago

Not disagreeing with your comment, but IMO this is just another historical accident.

GUI programming exploded together with OOP, and a lot of libraries/toolkits were made when using OOP was almost mandatory.

As much as frontend programming gets a lot of flack, functional reactive is a much better paradigm. One can however argue it's just lacking better implementations for non-web applications.

masfoobar2• 2 years ago

The evolution of OOP gives me fond memories.

I feel very lucky (in many ways) that I started with VB5 and Turbo C/Pascal. Sure, you can do OOP in VB6 but the books I read did not touch this area.

Then I tried Java. I hated it! This would have been around 1998.

The Java books I was reading were huge and half of it was not entirely about Java the language.. but OOP concepts. Some of it was inheritence hell! I remember looking at code that was just a bloat.. when in C it could be a couple of structs and 10 functions.

Then "Design Patterns" was thrown around in Job adverts. I had to bite the bullet and learn it to get my foot in the door. I was 18 at the time.

Once I got my foot in the door and gained the experience needed to get good as a developer, you soon get a handle of what works and what doesn't. Am I suggesting OOP is bad? No.. it has its place. I found the GoF is not as serious as it is pushed.

It was not long before I went full circle, coding more away from typical OOP mindset. I felt like the odd one out when I tried to explain this to co-workers but once we reached 2010's with the coined "Data Oriented Design" I realised my mindset is shared by many.

Personally -- and.. yes.. this is controversial.. I think OOP set us back 10 years of programming progress. Not because of OOP itself, but how large companies jumped on the bandwagon and encouraged developers that "this is the right direection" so much effort was there, creating large.. bloated.. monolothic code.

I felt like Dlang was an interesting step forward but, sadly, it is a language that tries to be everything. Now with Rust, Zig and Odin, I do believe that OOP will slowly lose in popularity but it will be a very, very slow decline.

freilanzer5• 2 years ago

These so-called 'patterns' are just language features in many languages, which makes it sad I had to learn them in university. Optional/default parameters, higher order functions, closures, ... The 'patterns' only make sense in Java because the language itself is so limited.

jerf3• 2 years ago

Having chewed on this for a while now, my personal synthesis is this: The problem with OO is actually a problem with "inheritance" as the default tool you reach for. Get rid of that and you have what is effectively a different paradigm, with its own cost/benefit tradeoffs.

Inheritance's problem is not that it is "intrinsically" bad, but that it is too big. It is the primary tool for "code reuse" in an inheritance-based language, and it is also the primary tool for "enforcing interfaces" in an inheritance-based language.

However, these two things have no business being bound together like that. Not only do I quite often just want one but not the other, a criticism far more potent than the size of the text in this post making it indicates (this is a huge problem), the binding introduces its own brand new problem, the Liskov Substitution Principle, which in a nutshell is that any subclass must be able to be be fully substituted into any place where the superclass appears and not only "function correctly" but continue to maintain all properties of the superclass. This turns out to be vastly more limiting than most OO programmers realize, and they break it quite casually. And this is unfortunately one of those pernicious errors that doesn't immediately crash the program and blow up, but corrodes not only the code base, but the architecture as you scale up. The architecture tends to develop such that it creates situations where LSP violations are forced. A simple example would be that you need to provide some instance of a deeply-inherited class in order to do some operation, but you need that functionality in a context that can not provide all the promises necessary to have an LSP-compliant class. As a simple example of that, imagine the class requires having some logging functionality but you can't provide it for some reason, but you have to jam it in anyhow.

It is far better to uncouple these two things. Use interfaces/traits/whatever your language calls them that anything can conform to, and use functions for code reuse. Become comfortable with the idea that you may have to provide a "default method" implementation that other implementers may have to explicitly pick up once per data type rather than get "automatically" through a subclass inheritance. In my experience this turns out to happen a lot less than you'd think anyhow, but still, in general, I really suggest being comfortable with the idea that you can provide a lot of functionality through functions and composed objects and don't strain to save users of that code one line of invocation or whatever.

Plus, getting rid of inheritance gets rid of the LSP, which turns out to be a really good thing since almost nobody is thinking about it or honoring it anyhow. I don't mean that as a criticism against programmers, either; it's honestly a rather twitchy principle in real life and in my opinion ignoring it is generally the right answer anyhow, for most people most of the time. But that becomes problematic when you're working in a language that technically, secretly, without most people realizing it, actually requires it for scaling up.

chuckadams• 2 years ago

Plus, getting rid of inheritance gets rid of the LSP

No it doesn't. Interfaces need to follow substitutability rules too. Any type you substitute for another does, and that includes things like functions too.

jerf3• 2 years ago

It does, because it is no longer a matter of substitutability. You are not intrinsically taking an X and modifying it to become a Y while also being an X. You are now just providing an X, and another X, and another X, and another X over there. You need to maintain the constraints of the one interface you are satisfying, but you are not also maintaining the constraints of the superclass, and all of its superclasses. You only have the interface to worry about, only the one dimension, not two (or more, depending on how you count in multiple inheritance languages).

You also can do things like take a subset of the interface and have things that implement just that. You can't do that to a class hierarchy; once a method is put in the hierarchy, it must be implemented by all children. (Note that if you're jumping up to say "But I can just implement an interface in Java or whatever if I want to do that", you're agreeing with me, not disagreeing. That's not a legal move in inheritance, though. Languages have been very, very slowly but very surely moving away from pure inheritance for a long time now.)

Having interfaces separated from reusability means you don't have to worry about all these things at once, just the interface.

mrkeen4• 2 years ago

It is much harder to violate LSP by writing new code which simply adheres to an interface, than it is to violate by writing new code which is run instead of the old code (and all the old code's side effects)

nashashmi3• 2 years ago

Subtyping, where if a type B implements the public interface of type A, values of type B can be passed as A.

I am confused by this statement or it is going against what I understand.

If you have created a Type B variable, and you also have a new interface called A, and B implements A, then why would Type B variable's values be passed to A's values. 'A' is only an interface.

mrkeen4• 2 years ago

Passed 'as' A, not passed 'to' A.

nashashmi3• 2 years ago

That clears it up!

Shywim• 2 years ago

It says "values of type B", as in "instance of type B", can be passed as if they are "instance of type A" (which they are actually).

But yes, values inside B specific to type B will not be able to be accessed when manipulating the type A.

nashashmi3• 2 years ago

Thank you. :)

amluto• 2 years ago

This article describes the OOP approach of changing, say, a Logger to an abstract class with a default implementation, without needing to modify code that uses it, and also describes this as something that could be done in C++. But this doesn’t work at all in C++ if there is ever a Logger on the stack!

    Logger l;

That’s a Logger, and it will not magically become a subclass.

And changing this to go through pointers everywhere and to use virtual functions, in C++, is not very performant. A good JIT compiler may be able to effectively devirtualize it, but C++ compilers are unlikely to be able to do this effectively.

MathMonkeyMan• 2 years ago

In the case of a Logger, though, it is likely passed around by reference or pointer. So users of the Logger (reference/pointer) do not have to change if its definition changes to that of an interface.

The "Server" class, or whatever instantiates the Logger, will have to change, but that might not be such a big deal.

So yes, the author was wrong about not having to modify any code, but likely you won't have to modify most code.

whizzter4• 2 years ago

The author brings up the basically the canonical example of where OOP style design shines, and where functional programming will falter.

The simple truth however is that overly going into either functional or OOP camp will hurt because strict adherence becomes subscribing to a silver-bullet.

The middle road is simply a better engineering option, use a practical language that supports both paradigms.

Keep data transforms and algorithmic calculations in functional style because those tend to become hot messes if you rely overly on mutation (even if there is performance gains, correctness is far far easier to get right and write tests for with a functional approach), then there are other concerns where an OOP derived system with inheritance abstractions will make things easier.

throwawaymaths3• 2 years ago

How do functional styles falter? Erlang's telemetry/logger systems are absolutely fantastic.

whizzter4• 2 years ago

While Erlang itself is pure, in practice it seems like a lot of practical mutation and state issues are tucked in other processes. Nothing wrong with it and it sidesteps the purity issues that the Haskell example in the article presents.

mrkeen4• 2 years ago

Semi-mutable, semi-private, semi-nullable, semi-determistic, and semi-statically-typed. Best of both camps.

pseudonamed• 2 years ago

The middle of the road option in a language like Clojure is almost always functional with a small amount of mutable state.

Programming styles are just that, style; Language =/= style.

heresie-dabord• 2 years ago

Language and "style" can be hard to disassociate, though. Unless that kind of flexibility is part of the design ethos of the language.

The word "style" generally means a superficial characteristic of appearance, but "style" in a discussion of programming languages could mean the appearance of the language, the loop/state paradigm, or the design ethos of the language itself.

For example, the design ethos of Java is entirely bound to OOP. Python on the other hand has a celebrated syntactic style, an OOP foundation, and a flexible loop/state paradigm.

Python has flaws, of course. But its development community has paid attention to syntactic style and to the loop/state paradigm. Java became a successful corporate language; Python entered the corporation because it has become a popular language.

mattgreenrocks2• 2 years ago

I'm less an OOP fan and more an extreme late-binding fan. It is a really nice lever to use when you need it. You don't necessarily need a language built for it if you have sufficient infrastructure in place (such as dependency injection).

That said, FP is a great default for most code, and I try not to write any new code in languages that don't support algebraic data types. You can express things much more precisely with them.

Languages that let you use both styles (Kotlin/Swift) are probably my favorite, despite using Haskell in production at work. Haskell punishes needing to use mutability too harshly IMO.

bitwize• 2 years ago

"Late bind all the things" is pretty much what Alan Kay's idea of OO was. In particular it means that methods are invoked by name and selected based on message name by the receiving object. Any object can be sent any message; how that message is handled is determined by the object at invocation time. No vtbls or other such mechanisms used by statically typed OO languages are involved.

Kay has spoken positively, for instance, of Erlang, which has nothing like Smalltalk's OO model.

bob1029• 2 years ago

The middle road is simply a better engineering option, use a practical language that supports both paradigms.

Agreed - I would get more specific with this too. Which arrangement makes more sense:

1. A solution that has an OOP outer shell hosting an FP inner core

2. A solution that has an FP outer shell hosting an OOP inner core

I argue that 1 makes way more sense - I look at the OOP/procedural code as the foundation layer upon which the FP code can be executed. This firewalls the messy outside world from the pure maths. For me this would be entry points like BusinessLogic.ExecuteRules() after having externally prepared all of the data contexts for execution. The results of this are then processed again by the external OOP code for downstream handling (writing to database, responding to web client, etc).

The other way around feels nonsensical to me.

zelphirkalt6• 2 years ago

Mutation is infectious. It will take great care to have an OOP core and outer FP shell. The OOP core might have to become completely threadsafe and use mutexes and such, to be reliable. This might be more painful than sticking to either one paradigm.

TeMPOraL4• 2 years ago

The other way around feels nonsensical to me.

Wonder if that's because you've learned the pattern - "functional core, imperative shell"? I feel it's not a coincidence you used the terms "shell" and "core" in your comment :).

Myself, I'm very much in favor on a theoretical basis. In practice, I've got bitten by this a couple times - keeping a purely functional core didn't play nice with the modularization and testing setup we had, using C++17 with CMake and GTest/GMock. I blame this on my inexperience, filing off sharp corners as I go along. I'd sure could use a detailed study of how to apply this pattern in modern C++, on an application scale, taking account the real tradeoffs - like how to "firewall" the core from outside mess, and allow tests to poke through that firewall, and not end up in weird linking hell, and not blow a single module into 10 tiny ones, and keep the whole thing debuggable in practice[0].

One thing I occasionally do even in the "FP inner core" is apply the idea I picked up from Clojure's "transient" data structures: there is no difference between purely-functional, immutable, referentially transparent code, and imperative code carrying mutable state, if no one on the outside can tell. Sometimes it's just easier to make a typical imperative procedural or OOP solution and isolate it in a functional interface.

[0] - I used to like point-free coding; especially with functional style, it makes for nice, readable, highly-expressive one-liners. But each time I had to debug such code, I ended up regretting it. Now I'm starting to favor more explicit steps with intermediary variables storing results, simply to have good targets for potential breakpoints/tracepoints, and because such code is more convenient to step through. You could say I'm only doing it because the tools I use are limited, but frankly, almost all of "readable code" principles and even the shape of modern languages are driven by limitations of the tools we use, so ¯\_(ツ)_/¯.

cesaref• 2 years ago

Unless you are on a greenfield project, you don't get to make these decisions like that. You start with a jumble of libraries and helper classes, or a complete app which needs its functionality amending. The right choice will alter depending on where you start if you see what I mean.

And yes, i'm an advocate for the mix and match approach.

neonsunset2• 2 years ago

C# and F#, imperative shell, functional core :)

ajuc9• 2 years ago

You could argue frameworks like Spring Integration or Apache Camel are FP outside + OO inside, but the key is that they allow side-effect channels for passing data ignoring the functional interconnections.

Without that you would need to refactor the functional part every time any OO node wants to access any new data.

valcron1000• 2 years ago

The middle road is simply a better engineering option, use a practical language that supports both paradigms.

I recommend reading "The curse of the excluded middle" paper by Erik Meijer on why this approach does not work.

red_admiral• 2 years ago

Functional programming has found its way into Java, where it works ok for some tasks; scheme/kotlin might advertise themselves as FP in the sense of "even more FP-ish than Java" but they're really mixed paradigm too, and not just because of backwards compatibility with other JVM libraries.

We've made the middle road work. It is not the magical 10x speed upgrade that some managers hoped for if you just sprinkle some FP on top of the project like icing, but it works quite well in practice because you have the right tools for dealing with different kinds of subproblems.

Meijer's paper is what I would call "FP maximalist". (Or "Haskell maximalist", as even OcaML manages without hiding all IO away in monads.) It's a defensible opinion to have, but doesn't have anything to do with the work environments that I have experience with.

raincole3• 2 years ago

It was from 2014.

In the past decade, we've seen "the middle way" has won.

- Every mainstream OOP languages now support passing functions as parameters.

- Optional type annotation became mainstream, e.g. Typescript and modern Python.

whizzter4• 2 years ago

Most of the "horrible" examples in that paper are uncommon/unrealistic constructs to prove a point, yes there are real footguns in that are analogous to them but even with junior developers around I've yet to see many in practice.

ndriscoll3• 2 years ago

The example is a single-abstract-method class, i.e. a lambda function. You can define it as

  `type Logger = (String, Severity) => IO ()`

  `def empty: Logger = (_, _) => IO.unit`

  `def aboveSeverity(l: Logger)(minsev: Severity): Logger = (s, sev) => if sev >= minsev l(s, sev) else IO.unit`

Or Curried if you like. In Scala, you might put these on a companion object so that you can give Logger.empty to your tests, etc. You don't need the type to remember which type of logger you had. The only thing you care about is that you can call it.

tome4• 2 years ago

This is strange to me because I don't see FP faltering here at all. I suppose it depends on precisely what you mean by "OOP" and "FP". Below is an example implementation in my Haskell effect system Bluefin. It defines a Logger interface (that can log a message with severity) and then instantiates it with two implementations

https://hackage.haskell.org/package/bluefin

1. a logger that logs to stdout

2. a logger that logs to a file

The file logger also brackets the opening of the file so that if abnormal termination is encountered then the file handle is guaranteed to be cleaned up. This is similar to RAII.

I really like this solution! It's just programming against an interface, and then instantiating the interface in different ways. I think an solution using inheritance would be worse, because it would use a special language concept (inheritance) rather than a standard one (function definition).

Perhaps this is "OOP" and not "FP"? That's fine by me! But in that case I conclude Haskell is an excellent OOP language. (I already conclude that it's an excellent imperative language.)

    {-# LANGUAGE GHC2021 #-}
    
    import Bluefin.Compound
    import Bluefin.Eff
    import Bluefin.IO
    import System.IO
    import Prelude hiding (log)
    
    newtype Logger e =
        -- Log a message with a severity
        MkLogger {log :: String -> Int -> Eff e ()}
    
    withStdoutLogger ::
      (e1 :> es) =>
      IOE e1 ->
      (forall e. Logger e -> Eff (e :& es) r) ->
      Eff es r
    withStdoutLogger io k =
      useImplIn
        k
        MkLogger
          { log =
              \msg sev ->
                effIO io (putStrLn (show sev ++ ": " ++ msg))
          }
    
    withFileLogger ::
      (e1 :> es) =>
      FilePath ->
      IOE e1 ->
      (forall e. Logger e -> Eff (e :& es) r) ->
      Eff es r
    withFileLogger fp io k =
      bracket
        (effIO io (openFile fp ReadMode))
        (effIO io . hClose)
        ( \handle -> do
            useImplIn
              k
              MkLogger
                { log =
                    \msg sev ->
                      effIO io (hPutStr handle (show sev ++ ": " ++ msg))
                }
        )

throwawaymaths3• 2 years ago

That's fine, but suppose you wanted to swap out loggers (or add an extra logger target) at runtime. Maybe someone wants transiently hooks in an observer by logging into a webpage that shoots the logs at that users browser. I don't know enough Haskell (and it's hard enough to read) that I can't tell if this code can deal with that case.

librasteve2• 2 years ago

https://raku.org is a great language if you want all the paradigms in a smooth way

kamaal• 2 years ago

How is Perl 6/Rakudo coming along these days?

I mean in terms of overall spec compliance and production use cases.

Im guessing larger adoption would still be low unless Rakudo can run CPAN modules as is.

Nathanael_M• 2 years ago

Would you have any advice or resources for learning paradigms and practical paradigm usage?

piyush_soni4• 2 years ago

Keep data transforms and algorithmic calculations in functional style

What annoys me greatly though is kids coding various 'fancy' functional paradigms for data transformation without realizing their performance implications, still thinking they've actually done the 'smarter' thing by transforming it multiple times and changing a simple loop to three or four loops. Example : Array.map.filter.map.reduce. Also when talked about it, they have learned to respond with another fancy term : "that would be premature optimization". :|

Gunax• 2 years ago

Aren't those all linear operations?

kosmozaut• 2 years ago

Why would your example be O(n³)?

eigenspace2• 2 years ago

This is just an unfortunate consequence of how map and filter are implemented via iterators.

Of you work with transducers, the map filter map reduce is still just one single loop.

davedx2• 2 years ago

That kind of thing really depends on the language. Some of the stronger functional languages like Haskell have lazy evaluation, so that operation won't be as bad as it looks. But then you really need to fully understand the tradeoffs of lazy evaluation too.

DeathArrow16• 2 years ago

I don't know how things are implemented in other languages but in C# 9, these operations are optimized.

bluGill3• 2 years ago

That is premature pessimization. They have no idea what premature optimization is as nobody has done that optimization at all since 1990 or so. Premature optimiiation is about manually unrolling loops or doing inline assembly - things any modern compiler can do for you automatically.

throwaway20372• 2 years ago

I like your post. There is a long YouTube video of a dev doing a long breakdown about why FP "lost" to OOP. In reality, it didn't lose...or rather, it won by using the backdoor. OOP integrated many FP features into their own languages. As a result, you can do lots of FPish coding in modern OOP languages.

davedx2• 2 years ago

How on Earth did FP "lose"? Most systems I work on these days use TypeScript, it's taken over huge parts of the industry, and OOP in TS is like an after thought that most people forget is even there at all. All the TS codebases I work on are 99% functional, with most JS/TS devs leaning into it more rather than less.

the_gipsy4• 2 years ago

Elm has taught me that pure FP can work beautifully. But it didn't quite catch on, which says something (but not necessarily that this approach is wrong), and it's also clealry not suited for every type of programming (e.g. systems programming or other low level stuff).

Pure OOP aka Java has been a mistake, even though it's probably the most popular.

Nursie3• 2 years ago

Pure OOP aka Java has been a mistake, even though it's probably the most popular.

I mean, Java is hardly 'pure' OOP and these days contains a lot of functional type features.

I've come to the opinion that sticking to paradigms over practicality is often the problem, and a language that helps you get things done regardless is preferable

pjmlp2• 2 years ago

Pure OOP were Smalltalk and Eiffel, before Java was even an idea.

ryandv4• 2 years ago

The characterization of FP-style approaches to the problem makes me question that it is a canonical example at all; rather I would regard it as a strawman of FP style, or otherwise not idiomatic or awkwardly designed. If Haskell is indeed unergonomic for the purpose of supplying multiple different logger implementations, it would seem that it would also be unergonomic for the purpose of supplying multiple different exception/error handling implementations.

But... it's not? See `catchE` [0] from Control.Monad.Trans.Except:

    catchE :: Monad m => ExceptT e m a -> (e -> ExceptT e' m a) -> ExceptT e' m a

... where the callsite-provided exception handler is the second parameter to the function, which can do basically anything (especially if the monad m is MonadIO). Hardly unergonomic or overcomplicated in my view, and no effects algebras or even type declarations in sight.

There is already a canonical example and it is the "Expression Problem," [1], where in FP "you optimize for extensibility of the number of operations in your model, at the cost of reduced developer ergonomics when attempting to extend the number of types you can operate upon. In the latter, object-oriented approach, you have the inverse tradeoff." [2]

[0] https://hackage.haskell.org/package/transformers-0.6.1.2/doc...

[1] https://wiki.c2.com/?ExpressionProblem

[2] https://news.ycombinator.com/item?id=41450851

epolanski2• 2 years ago

I still feel like one missing crucial point is that you can mix both styles effectively.

Scala, Elixir and some lisps are languages that make this nice.

TypeScript has libraries like effect-ts where you can leverage OOP where it makes sense too.

f1shy• 2 years ago

For me is hard to understand the opposition of OOP to functional. They are just not exclusive one of each other, neither is exclusive with all other paradigms.

mejutoco• 2 years ago

OOP puts state and behaviour togethet (tightly coupled) in objects. FP, in a language with expressive types, has well-defined data-only structures (types) and functions that operate on those structures, so state representation and behavior are separated.

For me, OOP can be done right, but FP is intrinsically better for correctness (it incentivizes correctness)

baranul• 2 years ago

Problem seems to come more from languages that force OOP usage and force their libraries to use it, versus it being really optional. Every solution doesn't require a class and everything in existence should not be defined as an object.

carapace• 2 years ago

I sure am glad that, when I was twelve and learning Pascal at middle school, my teacher took pains to point out that OOP is just a way of arranging code, it doesn't change the code semantically, it's just topological. You avoid a lot of noise and nonsense if you just keep that simple idea in mind: OOP is a style of arrangement, not semantics.

It's especially odd to compare and contrast OOP style with Functional Programming paradigm because these things are orthogonal.

coliveira3• 2 years ago

My view of OOP is that is a way for people to replicate in code the experience of "bullet lists". In other words, create a hierarchy by a particular method of code engineering that conforms to traditional techniques that many people (specially in management) already use. The disadvantages come exactly from the fact that not everything in math, science and engineering can be easily modeled using bullet lists.

graypegg• 2 years ago

I think that might come from OOP's middle-era in xtreme-programming and early agile. A lot of focus on mapping user stories to classes/CRC diagrams, which eventually get mapped to some specific file/bytes on disk. Pretty explicitly modelling the code after bullet lists of messages that need to be passed around.

http://www.agile-process.org/model.html

https://agilemodeling.com/artifacts/crcmodel.htm

d_burfoot• 2 years ago

One very important issue in OOP is packaging together variable names. You can see the issue by looking at this atrocious function signature from the Python Pandas library:

pandas.read_csv(filepath_or_buffer, *, sep=<no_default>, delimiter=None, header='infer', names=<no_default>, index_col=None, usecols=None, dtype=None, engine=None, converters=None, true_values=None, false_values=None, skipinitialspace=False, skiprows=None, skipfooter=0, nrows=None, na_values=None, keep_default_na=True, na_filter=True, verbose=<no_default>, skip_blank_lines=True, parse_dates=None, infer_datetime_format=<no_default>, keep_date_col=<no_default>, date_parser=<no_default>, date_format=None, dayfirst=False, cache_dates=True, iterator=False, chunksize=None, compression='infer', thousands=None, decimal='.', lineterminator=None, quotechar='"', quoting=0, doublequote=True, escapechar=None, comment=None, encoding=None, encoding_errors='strict', dialect=None, on_bad_lines='error', delim_whitespace=<no_default>, low_memory=True, memory_map=False, float_precision=None, storage_options=None, dtype_backend=<no_default>)

An OOP approach would define a Reader object that has many methods supporting various configuration options (setSkipRows(..), setNaFilter(...), etc), perhaps using a fluent style. Finally you call a read() method that returns the DataFrame.

coliveira3• 2 years ago

While this signature really looks atrocious, it doesn't make the programmer experience bad at all, because all these parameters have default values. So it basically works as an interface with many options with convenient standard values and you can change only what you need.

hombre_fatal• 2 years ago

This seems like a trivial example though.

    read_csv(options: Options)

All you've shown is that Options has a lot of configurability, but you'd have the same problem if you posted the whole class with all of its fluent API methods; it would be even more characters.

Also, you can use built-in control flow logic to modify options before passing them into the function rather than depend on a developer to implement a fluent API for every class.

But this isn't an example of FP vs OOP. Just replace `read_csv(options)` with `constructor(options)`.

lucianbr• 2 years ago

a Reader object that has many methods supporting various configuration options (setSkipRows(..), setNaFilter(...), etc), perhaps using a fluent style

I don't understand what that would bring as opposed to the current situation you mention, where you just call read_csv and name each parameter you want with the value you want.

If anything, I'd say the builder pattern is a crutch for languages that don't have named parameters.

lyu072822• 2 years ago

A much better example for the issue with OOP gone wrong is the Spring framework:

https://docs.spring.io/spring-framework/docs/current/javadoc...

o_nate• 2 years ago

I think its important to be aware of functional style and the weaknesses of OOP, so you can write OOP code that avoids the worst pitfalls. Classes still remain a nice way to organize code, but you should try to make them immutable if you can.

DeathArrow16• 2 years ago

Classes still remain a nice way to organize code

Using classes as code containers doesn't make your code OOP. I use C# which demands most code being put inside classes, but my code isn't OOP because I seldom use inheritance, encapsulation or method overriding.

freilanzer5• 2 years ago

Classes still remain a nice way to organize code, but you should try to make them immutable if you can.

So, modules in functional languages?

kwar13• 2 years ago

Going from C++ to Rust, I now really love how Rust implements "OOP". I highly suggest reading this chapter even if you don't care about Rust.

https://doc.rust-lang.org/book/ch17-00-oop.html

raincole3• 2 years ago

OOP is not fundamentally bad or good. But I had some first-hand experience about how it's taught "wrong".

The following might sound ridiculous, but I swear I'm not making them up:

- In my highschool, students on their "Computer & Information 101" class were asked to answer what polymorphism is. Most of the said students had zero programming experienece at the time.

- In my sophomore year (CS major), students were asked to finish a mini game "with design patterns" and explain what design patterns they used. For most of the said students, that was the first time they wrote a program with more than 300 LoC. Before that, all the assignments they had seen are "leetcode-like", like implementing Sieve of Eratosthenes in C.

whstl9• 2 years ago

Yes. OOP pedagogy is completely messed up.

First, examples are often unpractical and divorced from reality. The canonical meme examples of “Dog and Cat inherit from Animal” or “Car inherits from Vehicle” are not really applicable to Veterinary Clinic Software or Self Driving Cars. People use those kinds of examples to say that OOP is good at modeling reality, but business software is 90% of the time better served by a different level of abstraction.

Second, a lot of descriptive information is passed as prescriptive. Patterns are a good example of how shoehorning concepts in a piece of software without having the knowledge to come up with it by yourself can make it worse, and yet teachers spend whole semesters dedicated to it.

Third, inheritance is still being taught as a fundamental part of OOP from the beginning in every curriculum I have seen, only to have pretty much everyone else saying “prefer composition” down the line, after the damage is already done.

superxpro12• 2 years ago

I feel like if these classes focused on where objects can shine, like with dependency injection, we'd feel alot different about things. But instead we focus on modelling the problem, without demonstrating how to solve practical issues, and now we're left with this tool that noones knows how to use much beyond a CS203 exam.

mike_hearn8• 2 years ago

It's pretty good at modelling reality and such hierarchies are useful. Look at the code of software that models reality:

https://dev.epicgames.com/documentation/en-us/unreal-engine/...

The reason we don't tend to see such hierarchies used in clinic software is that RDBMS engines aren't OOP and don't model inheritance hierarchies well.

Self driving cars are big piles of C++ so probably have plenty of OOP, albeit given the ML bent probably more for dealing with UI and sensors than modelling the nearby landscape.

Inheritance is taught because most real OOP codebases use it extensively and it works OK. If you don't understand inheritance you can't understand the standard libraries of most OO languages, most UI toolkits etc.

simulo• 2 years ago

These examples (dogs,cars...) are badly used in most programming books, but they can make sense if you show them in context of a small game or whatever else actually draws you an (inter) active virtual car or animal (which made OOP click for me, using processing). Printing "meow" and "woof" in the terminal, however, only makes sense as a demonstration if you already know what it should demonstrate.

odyssey73• 2 years ago

It’s possible that OOP is taught in universities because professors who grew up with it already know how to fill a semester with this sort of content. The tail inheriting the dog.

Of all the topics that CS programs teach, it makes intuitive sense that the practical ones in software engineering are the ones most likely to be taught in a way which is irrelevant or backwards. Academia is good at academic things, but its members are typically there in part because they do not have a calling towards practice.

Perhaps the practical courses shouldn’t exist at all, but it’s tempting to marry the department with industry in some way. We don’t require philosophy majors to take courses in legal practice or whatever job they might take after graduation, because education is one thing and a career is another.

mike_hearn8• 2 years ago

The first isn't necessarily related to OOP. My first CS class at university gave everyone a programming quiz, in the very first lecture. The goal was to identify self-taught students so they could be made to help others in group work.

kjs3• 2 years ago

You had bad teachers which says nothing about the paradigm or how it's taught generally.

When I did my CS classes (at the beginning of the 'OOP will solve all the problems' era), we had excellent introductions to encapsulation and polymorphism and the rest with detailed examples in (early, cfront) C++ and Modula-2 & Ada. But then we had FP with SML & Hope and a couple of others that were poorly taught and most of us thought "this functional stuff is awful". YMMV.

dkarl• 2 years ago

I think this is really comparing programming without effects to programming with effects. If you want the benefits of using an effects system, you'll have to work a little harder for them. If those benefits don't matter to you, then the extra work is for nothing. The article assumes the second case, and doesn't present it as a trade-off, but only as extra work for the same result, which is misleading.

So how could we compare OOP to FP in a way that evens out this difference? It depends on how you define FP.

You can (like this article seem to) restrict the definition of FP to only purely functional programming, in which a program cannot directly execute side effects, and must return a value representing the effects that the runtime system will then execute. Then an apples-to-apples comparison would compare the FP program with an OOP program that uses an effects system to manage its effects.

How do we do that? Well, if we define FP in a way that forces us to use effects, then the definition excludes a language like Scala, which is essentially a side-effecting OO imperative language that has features that enable FP-style programming. Scala isn't FP by the article's definition, because you can write impure code, but it does let you write programs that manage effects using an effects system. So you can do a reasonably fair comparison that way. I think you would discover that the pain of using effects is the same, if not greater, in an OO language where they have to be added as a framework.

Or you could define FP more broadly to include side-effecting languages like Clojure and F#, and you could compare a side-effecting OO program to a side-effecting FP program. This would be tricky because it would be very difficult to draw a style line between OOP and FP. Would you allow the FP program use OO constructs and the OO program to use FP constructs? If so, you might end up comparing two identical Scala programs. Would you ban the FP program from using OO constructs and ban the OO program from using FP constructs? In that case, you would get an OO program in the style of the 1990s or 2000s, which wouldn't be fair to modern OOP.

I don't think either choice really leads to a meaningful comparison between OOP and FP. I think comparisons have to be more specific to be meaningful, and they have to be in the context of a particular application, so you can fairly compare programs that use effects systems with ones that don't. You can compare Java with Haskell for a particular application. You can compare C# with F# for a particular application. You can compare Scala with an effects system like Cats Effect to Scala without an effects system, again for a particular application. These comparisons are more realistic because you can take into account the pros and cons of using an effects system versus not for the given application.

pull_my_finger• 2 years ago

Old school OO languages where they had to use classes and objects to patch missing language features probably did suck. OOP as an abstraction API on a modern, type annotated language is really nice and intuitive. Anyone in doubt, but open-minded should be encouraged to checkout a language like Pony[1]. Although it _would_ be nice to have first-class functions instead of the lambda objects they have it's otherwise really nice. No inheritance, real type interfaces and traits instead of "abstract classes". Combine a modern language like Pony with (mostly) sane modern OO advice like in Elegant Objects[2] and you're finally cooking with grease.

[1] https://tutorial.ponylang.io/types/classes

[2] https://www.elegantobjects.org/

mekoka• 2 years ago

Every code base that I've read that made faithful use of OOP artifacts such as inheritance (in all its forms) has been made more difficult to understand because of it, rarely despite it.

OOP certainly has good features (e.g. encapsulation of state), but I think it tends to shine best when programmers are really aware of the trade-offs. Most aren't. The same person that agrees that mixins are a bad idea in React, will then turn around and happily organize their logic as class-based views in Django.

And due to sunk cost, it's nearly impossible to convince someone who's invested time in this paradigm that the acrobatics are often probably unnecessary.

In my opinion, newer languages expose programmers to better mental models than "the class hierarchy" to solve code organizational problems. Work with Go or Elixir for a while and see your Java and Python improve.

pyrale• 2 years ago

The post's conclusion looks like the author has an axe to grind:

I think it would be beneficial for the functional programming community to stop dismissing OOP’s successes in the industry as an accident of history and try to understand what OOP does well.

But the author has spent enough time in the haskell ecosystem, and probably has some cause for this statement. I would personally have liked to hear more about that cause, and the perceived issues in the community, rather than code examples.

jauntywundrkind• 2 years ago

Dark Side has such powerful allure, such temptation; they are strong emotions that leave such indelible marks.

And I feel like code culture is one place in need of some checks, on it's checking. There's so many wide-ranging beers out there, prejudices. Some have fought those battles & have real experience, speak from the heart. But I feel like over time the tribalisms that form, of passed down old biases, are usually more successful & better magnets when they are anti- a thing than pro a thing.

JavaScript, PHP, Ruby, rust. Systemd, PipeWire, Wayland. Kubernetes. OOP, CORBA, SOAP. These are examples topics are all magnets for very strong disdain, that in various circles are accepted as bad.

It's usually pretty easy to identify the darksiders. Theres almost never any principle of charity; they rarely see in greys, rarely even substantiate or enumerate their complaints at all. I've been struggling to find words, good words, for the disdain which doesn't justify itself, which accepts it's own premise, but the callous disregard & trampling over a topic is something I would like very much to be a faux pas. Say what you mean, clearly, with arguments. Manage your emotional reactions. Don't try to stir up antagonism. If you can, cultivate within yourself a sense of possibility & appreciation, even if only for what might be. Principles of Charity. https://en.wikipedia.org/wiki/Principle_of_charity

I'm forgetting what else to link, but around the aughts this anti- anti-social behavior has a bit of a boom. Two examples, https://marco.org/2008/05/21/jeff-atwood-who-knows-nothing-a... https://steveklabnik.com/writing/matz-is-nice-so-we-are-nice...

(And those on the pro side need to also have charity too.)

The idea of the Speaker For The Dead, someone who tries to paint clearly both upsides and downsides of a thing, is one I respect a lot & want to see. A thing I wish we saw more of.

(I feel like I have a decent ability to see up and down sides to a lot of the techs I listed. One I'd like better illumination on, a speaker for the dead on: CORBA.)

throwitaway11232• 2 years ago

I agree with the general sentiment of your comment and I think there are several factors at play here.

* The human brain is not capable of evaluating and re-evaluating every possible option amongst the plethora of technical choices developers are faced with. This forces us to develop certain coarse grained mental heuristics (prejudices and biases) to navigate technology, and even if these broad generalizations are roughly true initially, we tend not to re-evaluate them over time. This leads to stale biases (e.g. some library/language was missing an API 10 years ago, and someone formed an immutable opinion on it).

* These broad generalizations lack nuance. I watched a talk recently by Dan Abramov where he calls these heuristics (I'm paraphrasing) a form of information compression [1]. That compression is lossy — it doesn't preserve the original context in which the heuristic was formed.

* There's also some insecurity at play here too. Developers want to believe that they've chosen The One True Solution, and harshly invalidating the alternatives is one way to reenforce that fantasy.

* And of course, social media has exacerbated this problem by rewarding inflammatory hot takes. You won't get nearly as many views/upvotes/likes for a sober take that says "technology X is well suited for this narrow use case" as you will for a hot take that says "why technology X failed", or "why everyone hates technology X".

You might enjoy this link: https://blog.aurynn.com/2015/12/16-contempt-culture

[1] https://www.youtube.com/watch?v=17KCHwOwgms

throwawayie6• 2 years ago

I think a general lack of criticism also plays a part. When someone has decided that X is the best approach, they tend to point to blog articles that favour their point of view as "proof", while dismissing other point of views as "uninformed".

A typical example are all those "We rewrote our service from X to Y and got huge benefits" articles.

- They are ignoring the fact that the new version has the benefit of years of experience with the actual problem domain and can be optimized

- They also tend to use a different stack such as a more specialized database, async processing using message queues etc. that provides huge benefits.

Someone will always cherry pick some aspect of that article (language or choice of database) as proof that their point of view is correct, while ignoring the fact that they are not comparing an apple with an apple.

To get a real comparison they should have written a third system using their new architecture and the old langauge, but that would of course be hard to justify outside of academic research. The developers probably wouldn't do it anyway, because if the old language proved just as effective it would be harder to justify why they chose a new language. Resumé Driven Development is unfortunately a real thing.

lyu072822• 2 years ago

I was such a darksider once, definitely not any more, I don't think there was anything other than gaining broad experience that changed me. I can see how specialization and too narrow focused experience would've resulted in me never changing. In conclusion, the wisdom is just to understand that opinions (including your own) are worthless, there is no real way to tell the objective difference between a good one and a bad one.

You can know the good and the bad, specifically about something, and that's very useful, but even that list is always going to be incomplete and possibly cherry picked.

Hashex129542• 2 years ago

I was actually fan of OOP languages particularly C++ & Java but no improvements so far on the main stream programming languages. Still there are lot of improvements need to do. Still C occupies the first place.

PS: I really hate python style paradigm & declarative programmings. Rust is top of my ignore list.

DeathArrow16• 2 years ago

Eric Lippert, one of the designers of C# language, wrote a series of articles about object oriented design problems.

Here's the first article in the series: https://ericlippert.com/2015/04/27/wizards-and-warriors-part...

n_plus_1_acc• 2 years ago

I consider the point of this article moot. The Problem with generics is easily solved in languages with associated types like Rust and scala.

brewmarche• 2 years ago

Love this series. In OOP always ask what should be the object when modelling the domain: often it's not an object like dog or cat but something like a rule or relation, to use the same example it could be a PlayRule (is this dog allowed to play with this cat, do they get along?), or whatever your problem demands (it's also interesting to observe that the terms dogs and cats are pretty vague, we could be talking about software for a vet or a shelter or a taxonomist, once you talk about the relation it seems to become more specific)

sirwhinesalot2• 2 years ago

Meanwhile us procedural folk think you're all silly.

DeathArrow16• 2 years ago

GoF patterns, Martin Fowler books and Uncle Bob books had the same impact to programming as the invention of null.

jy14898• 2 years ago

However, unlike our OOP example, existing code that uses the Logger type and log function cannot work with this new type. There needs to be some refactoring, and how the user code will need to be refactored depends on how we want to expose this new type to the users.

This is odd to me. There are solutions to make data types extensible in haskell, but for example in purescript you'd just use a record. But more importantly, why would you want existing functions to use the new type? Why not just pass the _logger from FileLogger in? The existing functions can't use the _flush ability anyway (in both OOP and FP cases)

DeathArrow16• 2 years ago

For me, the the antidote to OOP everything isn't pure functional programming, but data oriented programming, where your data and the code that performs operations on it are separated.

ThinkBeat• 2 years ago

It is all just fashion and fads. Use whatever you like best (if the situation permits) otherwise use whatever you are told to use.

"It is not difficult to keep a functional aspect in OO."

"It is not that difficult to do OO in Pascal or similar" (quote from Wirth)

Several functional programming languages includes an OO or OO like feature.

Nothing will fit every situation better than anything else.

epolanski2• 2 years ago

The latest state of successful FP projects can be found not in Haskell (which, for all its hype has still to post one killer software when even PHP has many) but in effect systems ala effect-ts or ZIO.

OP's example is trivially solved by services in both, because both treat dependencies as first class constructs and types.

enugu• 2 years ago

This post doesn't seem like a criticism of FP so much as the module system in Haskell, ML has a more powerful module system.

On r/haskell, user mutantmell gave a implementation of the code (assuming such a module system) closely following the Dart code given in the original post.

https://gist.github.com/mutantmell/c3e53c27b7645a9abad7ef132...

https://www.reddit.com/r/haskell/comments/1fzy3fa/oop_is_not...

(Java-style) OOP offers a solution for this: you can code against the abstract type for code that doesn't care about the particular instance, and you can use instance-specific methods for code that does. Importantly, you can mix and match this single instance of the datatype in both cases, which I believe to be a superior coding experience than having two separate datatypes used in separate parts of your code.
"Proper" module systems (ocaml, backpack, etc) offer a better solution that either of these: when you write a module that depends on a signature, you can only use things provided by that signature. When you import that module (and therefore provide a concrete instance of the signature), the types become fully specified and you can freely mix (Logger -> Logger) and (SpecificLogger -> SpecificLogger) functions. This has the advantage of working very well with immutable, strongly-typed functional code, unlike the OOP solutions.
This is in essence the same argument for row-polymorphism, just for modules rather than records. It can be better to code against abstract structure in part of your code, and a particular concrete instance that adheres to that structure in other parts.

odyssey73• 2 years ago

Two words which might change your life: equational reasoning.

kreyenborgi2• 2 years ago

The r/haskell comments show some simple alternative Haskell implementations of OP's OOP logger, e.g. https://old.reddit.com/r/haskell/comments/1fzy3fa/oop_is_not... and https://old.reddit.com/r/haskell/comments/1fzy3fa/oop_is_not..., I'm wondering if the post author just did not realize you could use a partially applied function; I still don't see what value OOP gives here.

2OEH8eoCRo0• 2 years ago

Working in the kernel or with drivers I see a lot of "object-oriented" finagling in C where there will be structs of function pointers alongside pointers to data to operate on. Isn't this the best argument for something like OOP? You're basically creating an object at that point. Am I missing something?

Rayhem• 2 years ago

I've come to understand that software has two axes: the problem domain and the software domain.

The problem domain is things like your physical model. Your 3d mesh. Financial transactions. All things that need to be represented in software.

The software domain is things like components and queries. Things you can build in-software to realize your problem domain on a computer.

Defining a component and the behaviors of a component has nothing at all to do with the problem domain; it's purely an artifact of software to make your system more extensible/reliable/faster/whatever. But this is the part that's OOP excels at because you get to write the rules of your component taxonomy in its entirety. You have a ThingDoer class that can accept any number of Components to give it the behaviors you need, and then you start writing out components to model your problem domain. The objects and their behaviors remain at the level of "how do I put these pieces together". OOP sucks for the problem domain, though, because you're always stuck trying to munge some limited inheritance tree (animal <- dog <- wolf) onto the Real World and it's always going to miss something. Far better to build atomic building blocks that are expressive enough to compose into whatever you need.

stonethrowaway• 2 years ago

C# is Pragmatic [0].

[0] https://news.ycombinator.com/item?id=41761346

OOP is not that bad

Related Stories