[avianlyric]

Most real world problems don’t fit into neatly into hierarchical structures. OOP pushes you towards trying to model everything in the world an objects with strictly defined operations that can be performed on, where those actions are determined by the data type itself.

You end up being forced to co-mingle your data structure design, with your data processing design. Which tends to be rather unhelpful.

Keeping your data structures fairly separate from the processes/functions that operate on them makes it much easier to build composable software. Data structures tend to be very hard to change over time, because the migration process is always tricky. Any structure that’s exposed outside your programs address space, whether that be via an API, storage on disk or in a DB, needs a migration path so new code can deal with old structures correctly. On the other hand, algorithms operating on that data are trivial to change, there’s no migration risk, and indeed we should expect those algorithms to change often, as the requirements of the software change.

In an OOP world, because you’re strongly encouraged to tightly bind your data structures to the algorithms that operate on them. You quickly end up in a horrible situation where changing your algorithms is very difficult without also being forced to change your data structures. Suddenly what should be a simple and easy change (introducing a new way of processing data), becomes difficult because coupling created by objects makes it hard to change the processing without also changing the data structures.

In a simple “write-once” world, OOP is fine. But once you want to write software that’s expected to evolve and adapt over years, as business requirements change, OOP quickly becomes more a hinderance than help.

[arein3]

In OOP you can have data structures and algorithms separated. You can use composition over inheritance without issues.

The fact that a language is strong typed and you get compilation errors if you forgot something is a big plus.

OOP is fundamentally about no static variables.

[anon291]

> The fact that a language is strong typed and you get compilation errors if you forgot something is a big plus.

That is not at all unique to OOP, and in fact OOP makes the problem undecidable due to ad-hoc subtyping. More structured languages like ML, Haskell, and Rust are much easier to reason about and have much stronger type systems.

[mcguire]

That, as I have been told, is "object-based programming", not object-oriented programming.

[gryn]

don't conflate 'Objects' with 'Object Oriented Design', if you split your data Structures from you algos then your just using an OOP-language to do programming not doing OOP.

strong typing has nothing to do with OOP. static variable are replaced by singletons and other similar in spirit objects.

OOP today is a 'No true Scotsman' concept much like communism, agile, and other vague by design terms. You can't argue against it because every individual has at least one definition in his head and it shifts through the conversation toward the one that's not refuted by the claims.

the intent of such concepts is to hit you in the feels and trigger some ideals inside you, so that you associate the positive feelings you have toward those ideals to the concept.

if you argue about it as it is used in practice you will inevitably have someone bring up that java style OOP is not true OOP and that you should look intro Smalltalk or some other language that implement "Real OOP".

since arguing about specifics is a losing battle, lets argue about the bigger picture, if we take the goals of alain kay like he talked about in many of his talks his goals was to make systems more like biogology, but as a system designer the last thing you want to do is that. we don't know much about biology, people in that field a still reverse engineering pre-existing designs to this day and not designing much of their own from scratch. If you design a system you want to have the most control and foresight in the dynamics of your systems, uncontrolled & unintended emergent effects are your source of problems.

entangling data and behavior make your conceptual design state-space size explode, when you go full OOP you become an ontologist philosophizing about what is an X and what is an X-manager, X-Provider, ... and less of a system designer trying to make sure your system does not land in the wrong states.

[DrScientist]

Aren't you then just attacking a programming style that nobody actually uses or advocates?

One of the most influential books about OOP - "Design Patterns: Elements of Reusable Object-Oriented Software" - talks about composition, separating interface from implementation etc - not about hierarchies ( other than to prefer composition ).

[adrian_b]

Composition and "separating interface from implementation" are not specific to OOP languages.

Composition has been used since LISP I and ALGOL 60 in almost all programming languages.

"Separating interface from implementation" is also the main feature of the programming languages based on abstract types, starting with Alphard and CLU, which are not OOP languages and which predate the time when Smalltalk has become known to the public, launching the OOP fashion.

An abstract type is defined by an interface, i.e. by a set of functions that have arguments of that type and this is a programming language feature that is completely independent of the OOP features like member functions, virtual functions and inheritance.

All OOP languages have some kind of abstract types, though with a different point of view on the relationships between individual objects and types a.k.a. classes and the functions that operate on them, but there have been many languages with abstract data types without the OOP features.

Moreover "separating interface from implementation" has also been the main feature of all programming languages based on modules, starting with Mesa, Modula and Ada.

The features that identify an OOP language are the idea that the functions belong to individual objects, not to types, hence the member functions, the substitution of the union types (of the right kind, like in Algol 68, not of the pathetic kinds encountered in Pascal and C and derived languages) with virtual functions (to provide an alternative form of dynamic polymorphism, which is preferable for closed-source software, by allowing changes without recompilation, unlike with tagged unions where there are select/case/switch statements that must be recompiled when the union is extended), and the inheritance in a class hierarchy.

There are many languages that are multi-paradigm, like C++ or D, where you can choose whether to write a program in an OOP style or in a totally different style, but there are also languages where it is difficult to avoid using the OOP features, or even impossible, because all the available data types may be derived from some base "object" type, inheriting its properties.

[mcguire]

Much of the Design Patterns phenomenon involves convincing Java to do things that are idiomatic in other languages.

[DrScientist]

I think the main problem with OOP is that the classic animal/cat/dog type class hierarchy examples that are used in teaching are in fact hardly ever used in the real world - giving a very misleading view of how it's actually used in practice.

Most people using OOP languages prefer composition over hierarchies and I almost never see those complex class structures modelled on data ( for some of the reasons you give ).

In terms of evolvability - encapsulation - a key feature of OOP - is a key tool in enabling that.

[microtherion]

You're right that animal/cat/dog hierarchies are hardly ever used, but exposing students too early to DogFactoryFactorySingleton might cause lasting mental damage.

[koonsolo]

So can you tell me which programming paradigm actually solves these problems that OOP has?

And also, can you give me a huge non-OOP codebase that shows in practice how it is better than the potential OOP implementation?

[skydhash]

Paradigms don’t solve each other’s problems. They’re just another approach that may be better in specific contexts and you can even mix them. Although today, some languages is veering towards using structs and the like for data models and classes as logic containers (swift, kotlin).

As for huge codebases, everyone knows that line of codes does not equal quality.

[koonsolo]

So basically, OOP is still the best for big iterative projects?