Because there are many low skill, poorly-informed people who write code still believe these things. In particular that "OOP" is automatically equivalent to "better quality code." It’s a sort of cargo cultism that is present in a few places.
Quality in practical outcomes for building projects, that is, not code asthetics.
The problem is that 'functional code' means 'spagetti code' for many 'low skill' people, and 'write once maintain never' perl style code for many other 'smart' people.
Both are rubbish, terrible low quality useless code outcomes.
OOP doesn't fix everything, but its a great lowest common demoninator for code that does the job. Its not exciting. It has stateful bugs. ...but anyone can do it and it gets the job done at scale; orders of magnitude better than any other coding paradigm I'm aware of.
You want a hard problem to solve?
Go figure out a way to make functional programming scale the same way, you'll start a revolution.
...but in my experience, its the frustrated 'smart' folk who want to write their maintain-never code who push FP as a replacement for OOP.
I don't see how that is the case. Even in the most poorly written function you have code that's working mostly on it's arguments (and maybe some global or something, since it is poorly written) and then returns a value. How is this function connected to the surrounding code? We know the answer, it's called in a single expression and given arguments. You have a single isolated call for a single run of the function.
In OOP you have to both instantiate a class and then call it's methods. By simple line count it is twice as complicated to call as a function, and it is twice as coupled to the code that calls it.
When I look into the internals of functional code I often find myself in a single isolated function and the functions tend to be on the short side. When I look into the internals of OOP code I often find myself in a large method that is part of a class in an inheritance hierarchy and the method uses a bunch of globals (err, I mean "object variables") and I have to read several other methods to understand what's happening, because the method I'm interested in depends on the state left over from other method calls.
In short, objects are a lot more powerful than functions, and thus "low skill" developers have a lot more rope to make spaghetti with.
In OOP you have to both instantiate a class and then call
it's methods. By simple line count it is twice as
complicated to call as a function, and it is twice as
coupled to the code that calls it.
> a single isolated function and the functions tend to be on the short side
I can almost guarantee that code was not written by an inexperienced or low skill coder.
If it was, you'd have a large complex function that took large complex state as its input, and probably maintained some kind of hidden internal state in some kind of async deferred loop after it returned or some combination of the above.
Have you worked with inexperienced FP programmers?
It's not fun.
Inexperienced OOP is a lot easier to deal with, because the entity level API validation is all you care about; you don't care about how hideously the internals were implemented as long as the tests pass. There can be any number of bugs and spaghetti inside the object, but you don't care, because you don't see it (until it manifests as bugs; but then you just add more tests and make them go away until all the tests pass).
I think there's a pragmatic aspect to OOP that involves large scale organizations collaborating on projects that you're not taking into account.
You could argue that a test suite for FP does the same job, and maybe it does... but the point here is that someone has to define the module level interface, and how it behaves as a state machine (regardless of if the state comes in 'pure' and is passed around or is encapsulated internally); and that's OOP, not an inheritance hierarchy.
No pure FP language will allow you to do that without the function's type signature reflecting that - it would need to return its value in some kind of state/async monad.
Now, if you're talking about FP in a traditionally OOP language, then I agree with you, but that's an apples to oranges comparison.
> Inexperienced OOP is a lot easier to deal with, because the entity level API validation is all you care about; you don't care about how hideously the internals were implemented as long as the tests pass. There can be any number of bugs and spaghetti inside the object, but you don't care, because you don't see it (until it manifests as bugs; but then you just add more tests and make them go away until all the tests pass).
This approach doesn't work for things that are difficult to test. e.g. you can only ensure your types are thread safe by reasoning about their use of locks, volatile, etc., because any attempt to test this is dependent on the implementation details of your runtime (e.g. the JVM) and the amount of load its under. Best case you get a flaky test, worst case you miss a bug that blows up in production.
But this is a tangent, because TDD is not specific to OOP - it works just as well with FP.
> but the point here is that someone has to define the module level interface, and how it behaves as a state machine (regardless of if the state comes in 'pure' and is passed around or is encapsulated internally); and that's OOP, not an inheritance hierarchy.
Pure state is an oxymoron. The idea is not that you pass a mutable argument in, but that you don't have the ability to mutate data at all. At best, you can return some instructions on how to mutate (e.g. the state monad), but its the consumer of your code who decides what to do with that, which prevents you from hiding side-effects, and simplifies testing.
Defining a module level interface and behaviour is just API design, not OOP.
It's dogma either way. There is no single true religion just advantages and disadvantages
This about sums up my experience with these discussions, too. I know a lot of people who are absolutely convinced that C++ "is better" than C because you can write object-oriented code in it -- you have native support for "classes and stuff".
The whole "is better than" thing is a little childish to begin with, but this argument is on the thin and confusing border between "meaningless" and "but why?"
That's a module. This scope creep is part of the problem with OOP, as it slowly encompasses features that are orthogonal to their main purpose.
OOP is mainly about procedural abstraction: any type implementing a protocol (set of methods) should be indistinguishable from any other type that implements that same protocol. This enables the open extension that characterizes OOP.
So amending your statement to make it truly about objects, "here's all the stuff you can do with String-like values".
Naturally you can do the same in FP with modules, but honestly, how different it is from OOP then (considering that you can use some form of polymorphism)?
For me OOP and FP stand for abstract concepts, not as specific languages.
This is not a defining feature of OOP, because it's a characteristic of abstract data types which predate OO. William Cook managed to distill the essence quite clearly I think [1].
Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better.
Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it is really a must.
That's because there are no decent OO based web UIs, because the web development experience and stack is a total mess to begin with.
You can see the disastrous implications of this feature with the ID mangling needed for Asp.net webforms, and the utterly miserable workflow that creates.
The worst part is that everything else about the original ASP.Net was mostly really good ... but Web Controls completely destroyed it's reputation.
I am now learning Rust, and for this purpose I am trying to implement a small TUI (Text User Interface) framework. In order to get some ideas, I dug in my library and found the Turbo Vision User's Manual that was bundled with Borland Pascal 7.0 [1]. Reading it after so many years made me wonder how could they create such a complex and well-thought framework that was truly usable for your own stuff, given the technology and knowledge available 30 years ago. The text often underlines that a lot of features were possible thanks to the OOP constructs implemented in Turbo Pascal, and I believe them. I think that OOP importance might have faded today, but its historical significance for the development of GUIs and TUIs should not be underestimated.
P.S. I am trying to implement my library in Rust, which is not an OOP language, and so far have found no blocking point: traits and containers are more than adequate replacements for the kind of polymorphism and inheritance used in libraries like Turbo Vision. But my point still stands: once we learned that polymorphism and inheritance were useful to solve some specific problems, we have derived better ways to achieve the same purpose.
[1] https://archive.org/details/bitsavers_borlandTurrogrammingGu...
Its gotten so bad that I feel strongly about killing the browser-based ideology and just returning to native clients for everything .. I mean, its really not an easy decision to "do the whole GUI in Web", even though by now it should be. It just seems like such a mess by comparison with where we should be by now, given the work done decades ago ..
OOP is also a tool that others have used to build things that many of us use all the time (I'm looking at you DOM API and CSS) so it's difficult to truly escape from OOP. You may never like it, but learning it will deepen your understanding of many other tools.
Well, that's what the OP in OOP means. It means you are oriented towards objects, and away from everything else.
What's the difference between writing a test and doing TDD? In TDD the tests are the center of your universe.
Plus there's the fact that "Everything is an Object" was a very common slogan for OOP.
Of course you can write non-objects in your object oriented code... An object is made of non-objects! But OOP means when you are asking architecture questions you sort out your names and your methods first, and functions fill in the gaps.
Compare to (old school) JavaScript where everything is a function to start, and you add prototypes and methods only when you really need them. (RIP JavaScript, long live OOP/ES6)
OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with uses at various times.
So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." And if your language is dynamic enough, you can add functionality to all Strings, not just your String subclass.
I don't typically find OOP useful for processing many records of data. Perhaps I might compose an object from a record of data so that a user might edit their profile in a GUI, but batch processing doesn't usually lend itself to OOP. But that's my experience and opinion; I bet someone has a good use case for using OOP while dealing with copious amounts of data.
Back to the topic at hand: Was OOP a failure? No more than lathes are failures. Not every handyman needs a lathe; not every programmer needs OOP. But when you do need it, it's a useful tool.