
It’s time to move on from OOP? - nnx
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-%EF%B8%8F-92a4b666c7c7
======
ggambetta
I've been around long enough to remember when OOP was the savior who would
free us from the previous generation of trillion-dollar disasters (spaghetti
code, CASE tools, DFDs), and I'm sure someone will be writing _" Functional
Programming - The Trillion Dollar Disaster"_ in 10-20 years.

In other words, I don't do hype or fads anymore.

~~~
danielscrubs
Depends on what you mean with Functional Programming. Do you think we will
ever see: "Math - The Trillion Dollar Disaster"?

Because we really ought to go that way (more proofs like Idris/Agda).

> “Simplicity is a great virtue but it requires hard work to achieve it and
> education to > appreciate it. And to make matters worse: complexity sells
> better.” > ― Edsger Wybe Dijkstra

~~~
GuiA
Unless the tooling makes it trivial - which is still a long, long time away,
if possible - I’m not sure there is a world where the increased cost of formal
verification (mostly in terms of engineers who know what they’re doing) makes
sense for things like line of business PHP/node.js websites, internal python
apps, bash scripts, etc.

~~~
danielscrubs
100% agree, but I'm hopeful.

------
mathw
I broadly agree, but this article is really poorly written. It takes every
downside of OOP to extremes which make it really hard to take the author
seriously. Yes there are problems with mutable state, even if you think you've
encapsulated it. Yes there are problems with dependencies, dependency
injection and the associated boilerplate. Yes there are hideous issues with
concurrency.

I don't think OOP as we see it in most languages today is particularly
helpful. I do increasingly feel that data structures and operations should not
be muddled together, and the polymorphism strategy should be something more
like Haskell's typeclasses/Rust's traits or Go's idea of interfaces.

I'm also sure that using those for a few decades would show us plenty of
things wrong, and lead to something else.

We are still children in this world. There are no correct answers - but there
are definitely some wrong ones, and the increasing realisation of that is
evident in the popularity of languages like Go and Rust, and the development
of C# is also interesting - increasingly new language features are FP
features, not OOP features, and the language becomes increasingly hybrid. It
will always be limited by being built on a fundamentally OO runtime, but it's
interesting how things are changing.

~~~
0815test
This article is just not very good, the author keeps talking about a zillion
different things without really focusing on the actual, underlying issues. But
one thing it does say right away is that mutable state is not a problem as far
as it goes, what's problematic is _mutability_ plus _promiscuous sharing_.
This is what makes it unfeasible to reason about what the code is doing.

Similarly, encapsulation (bundling code and data) definitely has its uses - in
preserving class-wide invariants, or in providing a "common" interface that
makes it possible to disregard the inner workings of some data structure, and
interact with it in a way that's not dependent on the implementation. But in
practice, implementation inheritance in OOP often encourages what amounts to
breaking encapsulation and making it possible to violate class invariants, all
in search of some dubious "code reuse". If you can't express your desired code
reuse pattern via some combination of simple interface inheritance, delegation
and dispatch over "sealed", non-extensible variants (the mechanisms that plain
old composition/FP gives you) there are _probably_ some underlying problems
with it that you haven't thought through.

Of course the standards of programming improve continuously over time. Even FP
and broadly "FP-like" programming is not what it was in the 1980s, and some of
that progress was brought (if perhaps incidentally!) by OOP languages. This is
to be expected!

------
CyberFonic
No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the
hands of competent programmers. Personally I don't particularly like C++, C#
or even Java. I have seen way too many dreadfully implemented systems in those
languages. BUT it is not the fault of the languages. Bad programmers can shoot
themselves in the foot with any language, it's just a bit harder with some but
not impossible.

In my experience, business applications are all about state. The state of an
account, a customer contact, an invoice. Changing state is what messages /
methods do. In a well designed and implemented system minimal inheritance gets
the job done. And bypassing encapsulation is a big no-no. Polymorphism reduces
cognitive load. A toString method should return a meaningful representation of
the state of all objects in a well designed system, etc.

But fear not, the majority of banks, insurance companies, big business still
use COBOL on mainframes. No danger of OOP there. It's all 1960s & 1970s
programming with GOTOs and spaghetti code. And yes, those are the systems that
manage trillions of "REAL" dollars everyday.

~~~
jddj
Completely agree.

Some of the most literate, easy to comprehend and maintain, stateful, Gui-
heavy desktop apps I've written / worked on have been detailed models of
interactive objects, because it was _appropriate for the problem_.

In other problems (the classic web, data processing), it doesn't make as much
sense to hydrate this huge, complex ecosystem of objects over and over just to
throw it away again, or to end up with functions which are nonsensically bound
to what is really just a data structure. Other operations are particularly
recursive or parallel by nature and lend themselves to FP at least in part
because of the work done in the FP community to handle those paradigms
extremely well.

------
tehlike
C++, java and other oop languages have been battle tested, and enabled a
trillion dollar economy.

Sure, others could do the same, but they didnt.

Google, msft uses c++, c# and a bunch of others and they are probably the most
complex software developers in the world.

It works.

Can it be better? Sure. Rust brings safety guarantees, f# enables functional
programming mindset, julia is good for data processing. But oop did bring a
lot of to market. We are evolving, and our languages will also evolve.

~~~
pmorais
I’d argue that until C++11 C++ was /objectively/ a terrible language and the
only reason people used it (and continue to use it) is because it’s nearly 40
years old and therefore ubiquitous. C++ is a language that is literally famous
for being famous. I know I certainly wouldn’t be using it if I had any other
viable (high performance) language with the same ecosystem, support and
tooling. It’s not “battle tested” it’s just too big to fail, and therefore a
lot of smart people have dedicated a lot of effort to developing tools and
standards that make it just barely passable for enterprise use.

~~~
GuiA
_> literally famous for being famous [...] not battle tested_

 _> “[no other] viable high performance language with the same ecosystem,
support and tooling”_

This comment strikes me as deeply contradictory. I have qualms with C++ as any
other C++ programmer, but saying it’s famous for being famous is just
ridiculous.

C++ has been used to operate nuclear submarines, airplanes, pacemakers,
financial systems, ... over the last few decades. I’d like to know what you
consider “battle tested”.

~~~
sgt101
Ada

------
pjmlp
Sure, as if sucessful FP languages weren't hybrid ones with support for OOP
programming as well.

The future is neither pure OOP, nor pure FP, it is multi-paradigm.

And with nice libraries, IDE and GUI tooling as well.

Comparing languages based purely on grammar and semantics doesn't help much.

~~~
smitty1e
Can anyone point to an IDE or GUI programmed from the ground up in an FP
style?

The declarative simplicity of FP makes it a joy, but I find myself skeptical
that flattening the OOP hierarchy into what would be a right jolly long list
of pure functions will prove practical.

~~~
pjmlp
Not really.

Common Lisp ones make use of CLOS or similar concepts.

For Haskell you have Leksah, but it uses Gtk and Typeclasses which allow for
polymorphism, a basic OOP principle.

~~~
sixbrx
I'd call type classes a non-OO form of polymorphism, it doesn't become OO just
because you have polymorphism (if that's what you're implying). I think of OO
as late-as possible dispatch, whereas type classes are compile time only in
most implementations.

------
thelazydogsback
Smalltalk (which was a revelation to me when I played with it on Tektronics
and Lisa) which the author mentions as a "real" OOP language, is actually a
good example of a code maintenance nightmare as a is one of those languages
that promotes "image saving"-based incremental development in the context of
some unreproducable soup of classes. Also its single-dispatch nature (copied
by most non-Lisp OOP systems) makes the intended receiver (and dynamic casting
semantics) rather arbitrary.

Any extremeism/fundamentalism taken too far tends not to work - and oop got
just ridiculous at one point. It's also not just the idea, but how it is
expressed and the level of abstraction that can be brought to bear.
Unfortunately, Java, being a "class-orientated language" rather than an
object-oriented one (not my original observation/coinage) and not supporting
lambda/closures, etc., was both the reason and solution that we needed these
baroque oop patterns in the fist place. (Even C# 1.0 had delegates before
proper lambdas and didn't require realized nested inner classes to represent
event handlers, etc.) Java's verbose solution to the simplest problems was
(is?) frustrating, and is only matched by C++'s complex semantics of
copy/assignment/... ctors and value/reference semantics which is more clearly
make explicit rather than implicit in a vanilla C program.

------
millstone
So much to critique in this article, but I decided to pick on this:

"THE codebase becomes impossible to maintain" "THE codebase becomes too
complex and unmaintainable" "What makes THE codebase complex?"

I count fifteen references to "the codebase." THE codebase. THE.

Well your program consists of more than one codebase! What then?

Here's some code that ran on the linked site:

    
    
        window.webpackJsonp = window.webpackJsonp || []).push([[8], {
            "./config/polyfills.js": function(e, t, n) {
    

Medium (codebase A) dynamically interrogates the API provided by my browser
(codebase B) as influenced by plugins (codebase C) linking the UI framework of
my OS (codebase D) and then loads some polyfills provided by Babel (codebase
E)... Which one is "the codebase?"

Your runtime environment is multiple components, each evolving independently!
How do you write reliable software here? You can use static types but can't
_trust_ them, they can't predict the future and don't know the past. You want
runtime interrogation and reflection. You want graceful degradation and
dynamic polyfills. You need late bound interfaces. You need objects, not ADTs.

This I think is the heart of the OOP idea: software components realized in
classes/objects/messages which can evolve truly independently. Drop the "THE
codebase" assumption and some of OOP's strengths will appear.

~~~
drainyard
Are you essentially saying that because you are using libraries you need OOP?

If that is what you are saying, that is nonsense.

------
madiathomas
First I was programming in C and I was told C is bad and I must move to a
better C -> C++. I listened and moved to C++. Then I was told C++ is horrible
and I must switch to modern OOP langauges like Java and C#. I moved more than
15 years ago and I am now very productive when delivering solutions using C#
and Java.

15 years later, I am now being told to dump my decade and a half knowledge and
competitive advantage and learn a new programming paradigm? Miss me on this
one. This time around, I will stick to what I know best. OOP has 80% of what I
need and I know ways to deal with 20% of the problems. I will stick to it.

It took me only 2-3 days to learn F# but I feel I will be doing my clients a
disservice if I have to start from scratch and start delivering solutions to
their problems using a programming paradigm that I have little experience
with.

No. Thank you. I will stick to delivering solutions to my clients using what I
know best.

~~~
eska
Congrats, you're old now :)

I think as developers we should constantly learn about new approaches. Doesn't
mean we need to use them blindly and follow the herd. Sometimes it's also
useful to learn something to realize why one should not use it, and how the
current approach is actually better.

~~~
madiathomas
That's why I learnt F#. Just to see how functional programming is going to
help me deliver solutions faster to my penny-pinching clients. It was an eye-
opener but I will still stick to functional programming until FP catches on.
If it happens.

At age 37, I feel young and really wish that I will still be able to program
at age of 50 and beyond.

~~~
eska
You're definitely still young, just kidding :-)

I've heard good things about F# for business logic, but haven't used it myself
yet.

~~~
madiathomas
I want to try F# on my next side project and see how it goes. I hope I will
get help from F# online community when I get stuck.

------
trilila
I dream of a future where instead of following messianic paradigms, developers
follow the mantra of “the most suitable tool or practice for the task at
hand”.

~~~
julius_set
I dream of a world where instead of finding the most suitable tool or practice
for the task at hand, developers follow the mantra of questioning those most
suitable tools or practices without blindly adopting them

~~~
trilila
Also that.

------
dandare
> Real-world Example, Please!

> Real-world example, please!

> Real-world example, please!

Would it be too much to ask for a REAL real-world example? Unless you are
already an expert in both paradigms you (I) have no idea what is the author
talking about.

How is nullability supuerir in Functional?

How is error handling superir in Functional?

What is really meant by shared mutable state? (The example with a piece of
papaer is equally useless as the explanation that "state is any temporary data
stored in memory")

How are "erroneous abstractions" promoted by OOP?

What is the "low signal-to-noise ratio"

How is the state NOT promiscously scatered between objects in Functional
programming?

How do you make "core parts of your application be stateless and pure" in
Functional programming?

How is global state "the root of all evil"?

Could someone point me to a literature that can explains these questions to
someone who don't know the answers already?

~~~
eska
This may be a useful example for a different approach:
[http://www.dataorienteddesign.com/dodbook/](http://www.dataorienteddesign.com/dodbook/)

Particularly the chapter "Relational Databases" which compares to programming
with sets in databases. This book doesn't tell you to program as if you worked
with SQL, but draws inspiration from it and makes a comparison.

------
fetbaffe
This article is just someone’s frustrated rant, poorly written.

Definition of OOP has changed over the years, early on it was a lot of focus
on inheritance & polymorphism, but today it is mostly about composition, which
is basically what you do in FP as well.

New inventive ideas like Go's & Typescript's interfaces flips the relationship
between the caller & the callee. Or Rust's traits where you can expand your
existing types with new behavior.

There is criticism about OOP to be said, but using Java as your strawman to
invalidate OOP is not really a good argument, it is just one implementation of
many.

Edit: removed the word dynamically from description about Rust traits.

~~~
0815test
I'm not going to defend the article's writing style, but Rust is effectively a
functional language with _controlled_ use of procedural-programming features.
Not _that_ much different from how Haskell places safeguards on the very same
things. (No, I'm not saying Rust today is _just as safe_ or _just as elegant_
as Haskell - far from it! But it can get there with some work.) Even FP is not
what it was back in the 1980s and 1990s!

~~~
millstone
What does functional language mean here?

Rust is not referentially transparent, does not model effects (any function
can rm -Rf your drive), permits shared mutable state (RefCell, etc) includes
statements not just expressions (break, return). Its most important safeguard
is its affine type system, which is absent from Haskell.

~~~
steveklabnik
Break and return are both expressions in Rust.

Item declarations, let statements, expression statements, and macro invocation
statements are the four kinds of statements in Rust.

------
boringisnormal
I would love to see atleast a few large projects implemented with Haskell/FP
before making such tall claims. Large here means few millions of lines of
source code and more than 50 engineers working on the same project, a monolith
such as a database or a message broker.

~~~
danielscrubs
“Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.” ― Bill Gates

BTW: Are you considering Go to be OOP? Like it always is in the programming
world everything is ill defined. Go has no inheritance from what I've read.

~~~
boringisnormal
The quote is fantastic and it does bring out an interesting dimension. Not all
parts of the code base are equally important. That is for another day. I
believe you are missing the context. Allow me to explain.

Source lines of code is a proxy to the complexity of the problem in hand. With
the assumption that the engineers will not unnecessarily write code just to
fill up the code base or pass time, we can safely say that the number of lines
of code for a database will be significantly higher than say a networking
library. To write more lines of code, we need more engineers. And with more
engineers, we uncover a variety of problems.

No accomplished Haskell programmer will agree that Go is a functional
language. At least the ones that I know don't. I think FP programmers are not
in agreement as to what constitutes a functional language, example Haskell vs
Clojure vs Elixir.

~~~
danielscrubs
Simplicity is a great virtue but it requires hard work to achieve it and
education to appreciate it. And to make matters worse: complexity sells
better. \- Dijkstra

My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current conventional
wisdom is so foolish as to book that count on the wrong side of the ledger. \-
Dijkstra

The required techniques of effective reasoning are pretty formal, but as long
as programming is done by people that don't master them, the software crisis
will remain with us and will be considered an incurable disease. And you know
what incurable diseases do: they invite the quacks and charlatans in, who in
this case take the form of Software Engineering gurus. \- Dijkstra

~~~
boringisnormal
Different times, different people.

Do you have anything original to add?

------
jayd16
>functions provide a level of code modularity and reusability never seen in
OOP.

Its like this guy has never used an OO language or at least tried to use some
FP paradigms in one.

------
teekert
I learned Python about 5 years ago, just for context, I know a bit of bash,
some html/css etc. I don't really understand this piece. I use Classes in
Python, put them in a module, I also put functions there. Some things are nice
as a class, some things are nice as general functions. I like inheritance,
otherwise I repeat things. Maybe I need to grow my project and run into
limitation before I understand the viewpoints. Maybe anyone has to go through
this? Should I feel bad about using classes/objects?

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

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

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

------
koonsolo
I'm getting sick an tired of all these OOP bashing articles.

X is terrible, Y is super! Fact is that everything has benefits and drawbacks,
and so does OOP, Functional programming or whatever.

The strength about OOP is that it's practically the best to program most
software. If you look for example at the SDL library written in C, it uses an
OOP interface with handles to keep things nice and simple. Yeah that's right,
OOP in C, why would anyone do that? Because it has benefits, that's why.

So why is most software nowadays written in OOP? Because it has the most
benefits. You can sure find examples where functional programming would be
better, but they are a minority.

So yeah, next time I would expect an article to properly make a comparison
between benefits and drawbacks of _both_ things that are compared. Not the
usual "all drawbacks of X, but look at all benefits of Y". This kind of thing
screams "Junior alert" to me.

Meantime, I'm developing my apps and games and applications in OOP, and
absolutely loving it. Wouldn't trade it for anything else in the world.

~~~
drainyard
SDL having an interface with handles has nothing to do with OOP and is simply
the concept of opaque handles. This is often seen in data-oriented code bases
where a system behind the scenes is dealing with transforming data in a
hardware-oriented and cache optimized manner.

Sure the article isn't super well-written, but it raises a fair point and
shouldn't just be thrown away. Just because something is the most used or
standard does not mean it is the best solution. Eating junk food is very
common, but you would hardly argue that it is the best way for a human to get
nutrients.

You can use OOP all you want, and it's fair to say that the article should
have been less biased (though he has a disclaimer that says he is biased), but
there is nothing suggesting that OOP is practically the best paradigm to
program most software other than the fact that it is the most used.

~~~
koonsolo
There is no doubt that using handles like that takes concepts the same like
OOP, such as constructor, encapsulation, object methods, etc. Therefore moving
this API interface to OOP would mean a straightforward 1-on-1 mapping.
Claiming this has no relation to an OOP setup is therefore not correct. It
would have had the exact same interface if it was written in OOP.

Maybe we are talking next to each other about what a good programming language
is. For me as a professional programmer, it means to sell value. This implies
that the companies I work for can make the most amount of revenue. Thanks to
free market forces, we can assume that the most "optimal" programming
languages survive. Remark that "optimal" is not expressed in terms of
aesthetics or whatever, but is purely the productivity of generating money.

You can indeed claim that fast food is not healthy, but from a business
perspective, it is a success story, and therefore also popular. I don't know
how "healthy" OOP is, but it is hard to argue that it is not a business
success story. And that is exactly what I offer to my clients.

Edit: And to be honest, I would have no clue how I could make the business
case for any of the projects I ever worked on for not using OOP. These include
games, consumer mobile apps, robotics and various business applications (smart
client-server, etc).

~~~
drainyard
Fair enough with that argument you can say it has a relation. I think what I
was trying to say was that I don't necessarily think the authors of SDL were
inspired by OOP when designing this type of interface.

 _Maybe we are talking next to each other about what a good programming
language is._

Yes, I think we are at least in a sense. If we are speaking about programming
languages from a business perspective we can agree that the language leading
to the most productivity will - in a business sense - be the most optimal. I
think my point is we have been productive in spite of OOP and not because of
it. OOP here meaning the way it has been since Java and not Alan Kay's
original ideas. When something like OOP becomes ingrained in an industry like
it has been in software development in both the business and in academia, I'm
not sure just waiting on the free market is going to do us any good if we
(i.e. me) want to change it. Personally I am vastly more productive in the
non-OOP code-bases I have worked in as opposed to the opposite. This is a
personal bias, but I am no the only one and there is a growing movement of
moving away from it and often already completely gone away from it. So it's
not just a case of the grass being greener.

I assume you are more senior than me, since I am not particularly senior, so
you can again write it off as me being a junior. But it's a growing paradigm
shift, especially in game and game engine development, which is what I do for
a living.

~~~
koonsolo
Senior also means that I built up a certain way of reasoning and avoiding or
working around common problems. So I might not be the best person to push a
new paradigm shift ;).

You got me intrigued about being less productive in OOP. Can you share what
exactly you are working on? My first guess would be that it has something to
do with concurrency or parallelism? It especially interests me since it's game
development :).

~~~
drainyard
_Senior also means that I built up a certain way of reasoning and avoiding or
working around common problems_

I see this in my current senior colleagues, who may be very OOP-oriented but
they are incredibly productive because they are super experienced in their
field and in the code-base. I 100% respect that type of seniority of course,
because I have learned a lot from my seniors.

Regarding my productivity I think it is first and foremost related to how my
brain solves problems. I especially like the idea of Data-Oriented Design,
because I think of solving programming problems as three simple steps: 1\.
Some data comes in 2\. Data needs to be transformed into something else (based
on some business rules) 3\. Data needs to be presented

So when I want to solve a problem I first define my data, then I define my
transformation functions and then where they are used afterwards. It's not
necessarily a purely functional approach, since they do change state as
opposed to returning new state, but it has very little overhead in my brain.
And as you mention concurrency, it simplifies it vastly because you usually
know exactly who is using which data where.

I work mostly on engine development, so there's a lot of room for optimization
and understanding how a lot of data is transformed every frame, which makes
performance a super interesting topic for me. I can reason much more easily
about performance in a procedural code-base than in an OOP code-base, so that
might be part of my bias. :)

------
cty277
Written by someone who... “Guides teams to building reliable software.
JS/Node/React.”

Enough said

~~~
michaelmrose
Not really enough. Facile witty criticism doesn't add much to the discussion
and lowers the level of discourse.

The same thought expressed with enough meat to chew on might provide a
worthwhile addition to the conversation but such venears once pierced are
often as solid as movie sets.

Think more deeply and take time to share.

------
danielscrubs
"OOP is considered by many a crown jewel of computer science".

No it's not. It's a crown jewel of programming.

What do proper CS-researchers have to do to not be grouped together with pixel
pushers? Slap Theoretical on every paper?

------
kazinator
> _[OOP] never came out of a proper research institution (in contrast with
> Haskell /FP)._

"Out with systems; in with formal languages!"

[https://www.dreamsongs.com/Files/Incommensurability.pdf](https://www.dreamsongs.com/Files/Incommensurability.pdf)

> _I do not consider Xerox or another enterprise to be a “proper research
> institution”._

"Also, I don't consider a paper on systems to be publishable!"

------
jcelerier
> There’s no objective and open evidence that OOP is better than plain
> procedural programming.

Really depends on what is your definition of "OOP" here

> Both Smalltalk and Erlang make use of OOP the way it was originally intended
> by its inventor, Alan Kay.

ah, the bad definition of OOP then.

Hint : most C apis that look like

    
    
        foo* foo_create(void);
        int foo_get_bananas(foo*);
        void foo_print(foo*, int, int);
        void foo_free(foo**);
    

are OOP, not procedural. They just lack the syntax sugar.

> Linus Torvalds is widely known for his open criticism of C++ and OOP.

yet he went on doing C++ for user-space code :
[https://www.youtube.com/watch?v=ON0A1dsQOV0](https://www.youtube.com/watch?v=ON0A1dsQOV0)

> Some might disagree with me, but the truth is that modern OOP has never been
> properly designed. It never came out of a proper research institution

as someone who did a phd in a "proper research institution", that's a
completely bullshit criterion.

> OOP doesn’t have decades of rigorous scientific research to back it up

oh come on

[https://scholar.google.com/scholar?q=object-
oriented](https://scholar.google.com/scholar?q=object-oriented)

~~~
eska
> Really depends on what is your definition of "OOP" here

I smell a no-true-scotsman incoming..

>> Both Smalltalk and Erlang make use of OOP the way it was originally
intended by its inventor, Alan Kay.

> ah, the bad definition of OOP then.

Message-based OOP is usually considered to be superior to inheritance by even
OOP advocates, and even composition-based OOP by many. I don't see your
evidence for "bad definition of OOP".

>Hint : most C apis that look like

> foo* foo_create(void);

> int foo_get_bananas(foo _);

> void foo_print(foo_, int, int);

> void foo_free(foo __);

>

> are OOP, not procedural. They just lack the syntax sugar.

Not every API that uses a struct is OOP. If your foos use inheritance, virtual
dispatch etc, then yes it's OOP. But usually it's just something like a struct
to store state instead of having globals or multiple parameters even.

>> Linus Torvalds is widely known for his open criticism of C++ and OOP.

> yet he went on doing C++ for user-space code :
> [https://www.youtube.com/watch?v=ON0A1dsQOV0](https://www.youtube.com/watch?v=ON0A1dsQOV0)

He's a pragmatist first and foremost, and the GUI libraries he uses (Qt) and
the programmers that work on GUI code use C++, he said. I doubt he would write
his own GUI framework in C++.

------
thelazydogsback
Two other random thoughts...

It amazes me that despite the long-ago realization to favor composition over
inheritance, that major oop langs only provide direct support for
(implementation) inheritance of methods and not _delegation_. I suppose
"delegation in context" has become be purview of DI/IoC add-ons - but direct
language support would be nice.

While confounded with OOP by many, Generics are probably best treated as
orthogonal -- if they had been the primary focus (including higher-kinded
types/modules) rather than inheritance, that would have been nice...

------
blodovnik
So if oo uis so bad, exactly what is better?

What should I be programming with?

~~~
StreamBright
I usually just keep it very lean group a bunch of functions into logical
groups and KISS it.

~~~
trilila
In OOP those groups are called classes, and the fun is that you can
instantiate them and call them objects. And within those objects you can set a
state, so those functions operate against it. A nice feat of OOP is that you
can also inherit logic and expand it.

~~~
blodovnik
Sounds disastrous.

~~~
trilila
In the wrong hands, it does. Easy to tangle OOP. But the point is each of the
two paradigms has its own benefits, and should be used when best for the task
at hand.

~~~
pjmlp
Somehow it seems hard to grasp that at their core classes are basically
extensible modules.

~~~
mikekchar
The key to understanding classes, IMHO is that you are grouping functionality
to make the code more cohesive. The style of grouping is to group the
functions based on the program state where these functions make sense.

Often people go the other way around and write entity relation diagrams. They
write classes to encode the data that they want to work with and put the
functions that interact with the data into those classes. This actually leads
to code that isn't OO (again IMHO). It actually more closely resembles modular
programming. You have areas where you say, "I'm dealing with that data here".
All of your instance variables are essentially global to that module.
Especially when the classes become large, this becomes mostly
indistinguishable from imperative code with global variables.

Instead, consider the parameters that the methods on your class use. Imagine
that you had no instance variables and that you had to pass all of the
parameters to your functions. Now group all of the functions that use mostly
the same parameters. That's a class. The instance variables represent some
state of the program and the methods work on that state. _Afterwards_ you can
make diagrams to see how these objects interact with each other, but it
usually doesn't make sense to do it before hand (because otherwise you end up
with bags of data and functions that act on that data as if they were global
variables).

Or, more concisely: An class is not a table in a DB and you shouldn't model it
the same way ;-)

------
teekert
It's blocked for me, I have had 2 free reads... Any tips? I'd actually like to
read these, the previous 2 were a let down and I never finished them even.

I don't understand, I actually though medium was sort of free (as in beer),
who is getting this money?

~~~
stevula
I was able to bypass by opening in incognito mode as a logged out user.

------
lincpa
Data dominates. the programming moves toward the data. from initial state to
final state, the shortest linear distance between two points. Simplicity is
the root of fast, stable and reliable.

`The Pure Function Pipeline Data Flow`, based on the philosophy of `Taoism`
and `the Great Unification Theory`, In the computer field, for the first time,
it was realized that the unification of hardware engineering and software
engineering on the logical model. It has been extended from `Lisp language-
level code and data unification` to `system engineering-level software and
hardware unification`.

Whether it is the appearance of the code or the runtime mechanism, it is
highly consistent with the integrated circuit system.

Using the input and output characteristics of pure functions, pure functions
are used as pipelines. Dataflow is formed by a series of pure functions in
series. A dataflow code block as a function, equivalent to an integrated
circuit element (or board)。 A complete integrated system is formed by serial
or parallel dataflow.

It has also been widely unified with other disciplines (such as management,
large industrial assembly lines, water conservancy projects, power
engineering, etc.). It's also very simple and clear, and the support for
concurrency, parallelism, and distribution is simple and natural.

There are only five basic components:

1\. Pipeline (pure function)

2\. Branch

3\. Reflow (feedback, whirlpool, recursion)

4\. Shunt (concurrent, parallel)

5\. Confluence.

The whole system consists of five basic components. It perfectly achieves
unity and simplicity. It must be the ultimate programming methodology.

This method has been applied to 100,000 lines of code-level pure Clojure
project, which can prove the practicability of this method.

[The Pure Function Pipeline Data
Flow]([https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow))

------
dgellow
Abstractions and design patterns aren’t what object oriented programming is
about, you can change the paradigm and you will still have these (though you
will maybe name them differently).

