Why OO Sucks by Joe Armstrong (2000) (cs.otago.ac.nz)

I think it's the particular combination of only having nominal typing, only allowing the oo-flavor of data abstraction, and encouraging programming with state and using inheritance for code reuse that leads to the object-spaghetti nonsense in heavily-oo Java/C++ codebases.

I swear C++ gets a bad rap because most people have only seen a gross mixture of C++98 and C in their codebases

A fully modern C++11 codebase is a beautiful thing

Are you trying to imply that whoever dies with the biggest exception stack trace does NOT win?

I fear I've slipped somewhat into OO habits by using Go interfaces.

> Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls with an if statement.

You could do this but that's not idiomatic.

What you would preferably do is have a function that takes a read function as a parameter. This is essentially the same thing as what OO languages implicitly do.

For an example of generic functions you can take a look at map or fold/reduce. You'll see they don't need to use if statements in the way you described.

A good language for functional programming provides parametric polymorphism via traits or typeclasses:

    pub trait Read {
      fn read(&mut self, buf: &mut [u8]) -> io::Result<usize>;
    }
    impl Read for std::fs::File { /* ... */ }
    impl Read for String { /* ... */ }

    pub fn read_kilobyte<R>(r: R) -> io::Result<Vec<u8>>
        where R: std::io::Read {
      let mut buf = vec![0u8; 1024]; // vector of 1024 0s
      let nbytes = r.read(&mut buf[..])?;
      buf.truncate(nbytes);
      Ok(buf)
    }

    let kb1 = read_kilobyte(File::open(...)?)?;
    let kb2 = read_kilobyte("foo bar baz quux".to_string())?;

It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time.

On the other hand, it seems to me that the core principles of functional programming (immutability, functional purity, construction via composition, and declarative programming) serve as a check that prevents things from getting out of control.

That being said, I think it's worth considering that all of the "core principles" of FP that I mentioned could be incorporated into OO. It also seems like FP can be more prone to out of control syntax (e.g. unwise use of point free style).

Very true. It's a practical solution to a complex problem. However, when systems get complex, it becomes very hard to find the right object / type to bottle up logic. Perhaps, then, a mix of OO and functional is the solution.

Without OOP, we have the ugly organization of writing N functions that each dispatch M cases of code by pattern matching or switching on a numeric type field or whatever.

OOP lets us break these pieces of logic into separate methods. And then in the physical organizationof the program, we can group those methods by type. For any given type, we have N methods: each one implements one of those N functions just for that type.

This is a better organization because if we change some aspect of a type, all the changes are done in one place: the implementation file or section of file for that type. Or if a new type is added, we just add N methods in a new file or section; we don't have to change the code of numerous functions to introduce new cases into them.

Those who write articles opposing OOP never seem to constructively propose an attractive alternative for this situation.

It is this attractive program organization which swayed developers toward OOP, or even full blown OOP evangelism. It's not because it was hyped. OOP has concrete benefits that are readily demonstrable and applicable.

OOP is what allows your operating system to support different kinds of file systems, network adapters, network protocols, I/O devices and so on.

It's unimaginable that the read() system call in your kernel would contain a giant switch() on device type leading to device-specific code, which has to be maintained each time a new driver is added.

The problem is that OOP is a slate of something like 18 characteristics and no language ever picks the same choices.

That having been said, the big problem with (especially early) OOP is that "Is"/"IsA" (aka structural inheritance) is the primary abstraction. Unfortunately, "Is"/"IsA" is a particularly lousy choice--practically anything ("Contains" or "Accesses" or ...) is better.

Most of the modern languages designed in the past 10-20 years reflect this--"Traits"/"Interfaces" seems to be what everybody has settled around.

How many of us actually get a choice in this...?

Understanding the objections to various programming paradigms can help improve how you use them, by having an awareness of what others consider potential minefields. (And who knows, maybe the arguments will change your mind. You shouldn't be so quick to prejudge the material.)

>>Clearly OOP works for a lot of people.

Something can work for a lot of people, and still suck.

>> If it doesn't work for you, don't use it.

Language and tool choices in our industry are made by a tiny minority. In fact, sometimes the people making those decisions are not even developers themselves! From that perspective alone, articles like this one are valuable.

Aside from that though, the question isn't whether OOP "works" or not. Rather, it is when it works, and for how long, until you run into a myriad of problems, such as leaky abstractions or inheritance hell. These are worth discussing. If you disagree, you can move on. No need to voice your misgivings.

In the programming work you do regularly, do you think there is a way you could structure your code which would allow you to do 60% less work, without sacrificing readability? If there is, would you know? The answer was clearly yes in the web world when jquery was king. Or cgi-bin on Apache. Is it still true today? Can we do better still?

If there is, it would probably demand a critical look at the way we approach our problems, and how we structure logic and data. The value in articles like this is to point at that question. For what it’s worth, I agree with Joe Armstrong and others who have been heavily critical of OO. Software which goes all-in on OO’s ideas of inheritance and encapsulation seems to consistently spend 2-3x as many lines of code to get anything done, compared with other approaches. (Looking at you, enterprise java.)

You’re right - the problem should proceed the solution. But our tools are the medium through which we think of that solution. They matter deeply.

Most of us work in teams. If people I work with believe something that's not true, then it directly effects my work. If the majority of the profession believes something, it significantly effects my entire career. I don't actually hate OOP, although I have criticisms, but the attitude of "if you don't like it go somewhere else" is missing the point. Criticism isn't meant to be mean or nasty, it's meant to point out bad thinking for the benefit of us all. What bothers ME is the positivity police on hacker news that thinks that "if you don't have anything nice to say don't say anything at all" applies to all of life.

>> Reason 2. It was thought to make code reuse easier. > I would like an evidence that it's not.

Mainstream OOP approaches achieve better cohesion by coupling data structures to functions. In the worst case you end up with essentially modules that contain "global variables" local to that module. In other words the only reason to have your instance variables is to remove the need to pass those variable to the functions as parameters.

This hurts the ability to write generic code. In fact you see this problem all the time in OO code. You have a base class and a bunch of basically unrelated child classes. It's not so much that the child ISA base, it's more that the child ACTS_AS_A base. But then, you run into all sorts of problems because one child (because it is using very different data structures) requires specialised code.

There are ways of getting around this, but often those ways end up encouraging you to implement an alphabet soup of design patterns that interact with each other -- causing more coupling rather than less. All for the want of a generic function.

IMHO OO is actually a poor vehicle for achieving code reuse. In fact, aiming towards this goal is usually one of the root causes I find in really poor OO designs. What OO is really good at is separating concerns and building highly cohesive code. This sometimes comes at the cost of increased coupling which inherently reduces reusability. I don't actually think that's a bad thing when used appropriately, but the old school "OO creates reusable code" is just a bad idea IMHO. It's the kind of thing that several of us threw out the window in the 90's along with large inheritance hierarchies -- nice idea, but didn't work out in practice.

And the world is not so neatly divided between things that just are (data structures) and thing that do things (functions). Take a date for example. The fact that it is a Wednesday is a "just is" sort of thing but is typically implemented as a function.

> Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to binding the functions and the types...

There is a key distinction: If I have two subsystems that use the same data in different ways, I can keep those concerns separate by putting the functions for each concern into a different module. Binding all the functions to the type mixes the concerns together and creates objects with way too much surface area.

Also, most OO langs make a big ceremony out of each new type: create the class file, create the test file, blah blah blah. I want types to be cheap so I can make them easily and capture more meaning with less work.

Wouldn't this violate the "encapsulation" pillar of OOP? As far as I know, it's always taught with encapsulation, inheritance, polymorphism being its three pillars.

> How has OOP created a software industry that would not have existed if functional programing had "won the fight"?

I'm not sure functional programming has lost yet. I haven't worked with it personally, and so can't speak to its merits or demerits, but have heard a lot of buzz around it recently. As you said, people tend to hype everything; some stay and some go. It might be the next big thing in programming, or it might be hipster tech. Or, like most things, it might have some good applications, but not be applicable to everything. That's basically my argument for OOP.

That seems to be the crux of it - I remember reading a post by Paul Graham where he said something similar about object oriented programming. His core thesis seemed to be that functional programming does a better job of organizing things than object-oriented programming does, and once you have the core of functional programming in place (closures, first-class functions, whatever the hell a "monad" is), you don't need object orientation any more. I've never gotten deep enough into pure functional programming to really see things this way, but I've gotten deep enough to at least understand why these pure FP guys might think that.

...& if you don't want the stateful gorilla?

So, functional programming?

> guarantees some sort of basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity.

Isn't that terrible? You want to provide a generic interface to calculate a hash or perform comparison: Now the thing has to be an object! If it's a primitive type, you better wrap it in an object now. If it's an existing class, you have to extend it. It becomes an object of a different class.

Or, instead, you could just have type classes to let the same apply to anything whatsoever, as long as it's a type, without the need for it to be an object. Heck, in some cases, the type could be a function instead.

Well, clearly not everyone knows it.

My biggest complaint about languages that incorporate functional features is that immutability is most useful when it’s the 99% use case.

When it’s a special tag that may or may not be used within the library/code base you’re using, you don’t get the cognitive advantage of feeling confident you can judge the output of a function by reasoning about its input.

My brain is small. I need all the crutches I can get, and referential transparency is a huge advantage.

What do you do with values that can't be meaningfully hashed/compared? Java is the only place I've come across this odd idea that everything is hashable, and I've never thought of it as a positive thing.

Here's a program that has some mutable state. Do you want that mutable state to be private or public? Do you want anybody to be able to change it, or do you want all changes to have to go through public methods?

Given that there are programs that necessarily have mutable state, why in the world would you not want that state to be private?

I mean, sure, Java taught bad OOP to millions of developers in the 90s, early 00s, and even today. Sure, the legacy of bad OOP lives on today.

That doesn't say anything about the principles of OOP when applied properly, when done in languages that avoid the pitfalls of bad OOP, and when the developer avoids the very patterns that tend to fall into criticism.

(incoming FP advocate to call my statement a strawman argument in 3, 2, 1…)

“Passing state as parameters” is what solved the “everything operating on global state” problem. Binding functions and state permitted polymorphism/abstraction.

> Multiple inheritance is seldom worth the headaches.

Single inheritance is never worth the headaches. :)

> Objects are probably more useful than some of the things invented to replace objects, like "traits".

Traits don’t replace objects; they are interfaces with static dispatch semantics.

... These things are unrelated. Just write functions that don't operate on global exposed data? You know, like, function arguments.

The only thing that strikes me as specific to OO is implementation inheritance, and that has been an unmitigated disaster.

I'm saying it is a way, and a sometimes useful one. Certainly when I'm thinking about a SQL schema, I'm often thinking about it using OO design principles, even though SQL is functional.

As soon as you start modeling real world situations (like bill being an employee but at the same time working a late shift as a contractor), then you're in the world of complex stuff that single inheritance, multiple inheritance, or anything less than insanely complex relationships requiring tens or hundreds of underlying entities to enact just can't handle.

IMO one reason for these fruitlesd ideological arguments -is OO good? Is it bad? - is that OO was originally sold using these real world examples. Which anyone who's worked on a real world system knows is BS.

Also outside of numerical work and some set stuff there's not really that many times you actually need to overload operators.. And you can easily extend languages without objects (Lisp)

Really there’s an easy conclusion to this — allowing and preferring user defined operators or operator overloads is a hotly debated topic and one where there appears to be no right answer — about the only conclusion you can draw then, is that operator overload is not exclusive to OOP: https://softwareengineering.stackexchange.com/questions/1809...

I’d also suggest that with functional programs, there are limits to how much you should cram in to one program, and that a smart way to modularize your code would be to, for example, follow the Redux reducer pattern and build or compose larger state objects and operations from functions that operate on just parts of the state object—this way you isolate written changes in a similar way to private OOP variables, where it’s just not expected (or even “in scope”) to modify other parts of the global state. Additionally, you can as in OOP control access to state by encouraging the use of “selector functions” or not directly accessing state. You could make your functions take smaller typed structs of state, really, functional programming is at least as expressive as OOP programming. I’ll say that both allow you to make mistakes like mix concerns, or use lots of globals, perform magic with meta-programming or overloading, or not be expressive enough to create your own DSL in—OOP or Functional, these concerns are in my experience shared by basically any language.