
All evidence points to OOP being bullshit (2013) - bontoJR
http://blog.pivotal.io/labs/labs/all-evidence-points-to-oop-being-bullshit
======
bhaak
> Extremist languages like Java force you to think of everything in terms of
> objects.

Erm, Java is by far not the most OO programming language there is.

For example, primitive types are not objects (no, auto-boxing doesn't make
them objects).

> But is Object Orientation (OO) a good idea?

Probably as good as any other programming paradigma out there.

> Does it have problems?

Sure, like every other language as well.

> Is it the right tool for everything?

No, like every other language isn't as well.

> Let’s explore some of these questions in a slightly tongue in cheek and
> cathartic rant.

And here I stopped reading. If you need to rant, do it over coffee and don't
waste my time when even your introduction is not witty enough to keep my
interest.

~~~
Loque
My sentiments exactly, kinda surprised this title made it so high up!

OOP has some fantastic applications and may have been oversold to the author
for a project he worked on. OOP(s)!

~~~
sklogic
> OOP has some fantastic applications

Yes, OOP is great for agent-based simulations. Only. This is a fantastic,
exciting area, but it is extremely niche and tiny.

Anywhere else, OOP is nothing but an obstacle.

~~~
tim333
It's kind handy for using other peoples code. Like if you want a couple of
Google maps on your page you can create a couple of map objects and set their
location, colouring, add and remove markers etc. I'm not sure how you'd do
that neatly without objects. Beyond that I'm happy without it.

~~~
muzmath
I don't think anyone is saying don't use objects, it's the OOP paradigm that
is being critiqued.

------
d--b
Can someone make a chrome extension to filter out the OOP vs FP articles on
hacker news? I mean, how many more articles do we need? Is there anything new?
Yes, FP is cleaner. Yes, OOP is useful for things like plugins. Yes, favor
composition over inheritance. Yes, FP is impossible to read. Yes, immutability
has its limits. Yes, Yes, Yes. Enough already.

~~~
brudgers
The filter exists. It is community + flag. It works in all browsers.

------
hacker_9
Compare the DirectX XNA OOP library to the OpenGL procedural library, and you
will quickly see that when OOP is done right it makes code fun and easy to
work with again.

In my my mind OOP is the next logical step after procedural programming
(simply packaging up a set of procedures into an object, and adding a few new
ideas like inheritance and so on). Functional programming though is not the
next logical step; it is a total paradigm shift. The main argument is that you
get rid of state etc which means you can parallelize better - but why are no
cutting edge games made in an FP language I wonder? Surely they would want to
distribute all the physics collision rendering and so on to multiple cores?

It's because functional programming as a separate language makes no sense, you
lose too much. But incorporating FP style into OOP languages (such as with the
new C++ constexpr, C# linq, and Java lambda), and giving the programmer the
_choice_ to use it when it makes sense is a far more powerful option.

~~~
LoSboccacc
OOP is about information hiding and providing well defined state transitions.

objects are used to hold a state and to act as gateway for valid transitions.

most complaints I see come from people using OO programming languages badly,
leaking abstractions all over the place and making it so you have to mentally
take care of the state of everything instead of trusting your objects to take
care of themselves, and thus you get the worst of both world: rigidity coupled
with complexity

I need information hiding because my brain is only so big, so I cannot
possibly have in mind the whole application state and all it's permutation at
all time while programming.

functional languages work similarly in a sense: you avoid thinking about state
transitions because the only things you have to take care of is each function
input and output

in a broader sense, programming becomes way way simpler if you think of your
functions as having 4 well defined input output: the inputs, the return
values, data from a persistent store and a state.

And with experience you start noticing that it is much much more simple and
productive if in any of your method at a given time you only reduce the 4 io
ports in 2: on one side you have functional languages, only ever working with
inputs and returns, on the other you have OO languages, which focus so much on
the input, state and state, return couples.

mastering the ability of using both styles where appropriate is the key here.
but people get dragged into name specific too much, forgetting that these
pattern emerged from coding and not the other way around.

~~~
mercer
Very well put. I've found that in some cases objects make a lot of sense, and
the more functional approach would really end up emulating objects through
closures and whatnot.

That said, especially for a lot of the typical web-related work I do, I find
that I'm generally better off leaning towards a more functional approach, as
most of what I do boils down to transforming database values to html in 'one
pass'. I'd say many of the typical functional programming approaches are
excellent for that. Avoiding mutable state has been a wonderful lesson, for
example.

------
zamalek
OOP, as defined as a set of principles, is a complete load of horse shit.
There are many more reasons other than what the article states as to why it
doesn't deal with realities of software (e.g. data oriented programming solves
some of them). OOP principles are likely one of the reasons it takes so long
to train fresh-out-of-college employees, as they first need to learn how to
forget that utter bullshit.

However, that does not mean that OOP languages are a bust. It is only the OOP
_principles_ that are a problem.

So far my experience goes, I've learned to mostly stop creating analogues of
real-world things (as OOP principles would have it), except where it makes
sense to, and instead use OOP features to create distinct _responsibilities._
Turns out OOP languages are identical to, let's say, "responsibility oriented
programming" languages.

OOP languages can also be used for other things, as previously mentioned: data
oriented programming. DOP is used widely in gamedev. Gamedev also happens to
be an industry that heavily uses an OOP language: C++.

Hate the principles, not the languages. There's a big difference.

~~~
lunz
> stop creating analogues of real-world things

I agree. Almost everything useful around us is the product of ideas with our
needs in mind, there was no TV and TV remote control in nature, no vacuum
cleaner, clothes, watches... if ever, nature inspired us. We create
_artitifical_ things that make us more efficient and effective than it would
be by just dealing with raw stones and sticks as they are found in nature.
When it comes to today OOP we have to deal with stones and sticks again
instead of thinking about a new aritifical thing that directly satisfies our
needs (you call it 'responsibility').

~~~
zamalek
> you call it 'responsibility'

That was simply the closest word I could come up with. You've described what I
was trying to say in significantly more detail (thanks!).

------
anon4
To me, as a C++ programmer, none of this really matters. I'm working on a very
compute-intensive program with a lot of modules, used in professional
settings. It _has_ to go fast. If using C++ means we can go faster than
someone using whatever else, at the expense of needing five times the people
and six times the development effort, we'll pick C++. We're interested in the
maximum performance achievable with the language, not the average use-case.

Someone would ask "why not assembly/plain C/Fortran/etc.". The answer is that
C++ gives you a lot of good ways to structure your code semantically, while
still letting you produce tight machine code. That's the real kicker here - I
need to reason about my program as an engineering construct running on real
hardware, not as an expression of Computer Science algorithms.

In a nutshell, for a new programming language to be a viable way to build our
core product, it has to

1\. Go Fast and let us Go Faster Than Everyone Else, preferably letting me
write platform-specific assembly when I need to

2\. Interoperate with C++

I've seen a few recent languages attempt to cover 1., e.g. Go, Rust, Julia,
for some use cases. However, I have never seen a language attempt to tackle 2.
Not even for the case when you have vanilla classes with virtual functions and
a few sane templates.

~~~
tadlan
Check out Julia ' s Cxx.jl. it's probably the best c++ FFI in any language.
You can even evaluation and call cpp code on the fly from the repl

------
radu_floricica
Depends on how you use it, of course. Libraries make wonderful showcases for
OOP strengths - I always like to give Java Collections as an example. But if
you actually build your application code as OOP... well, I might privately
think you deserve everything that happens to you because of that.

I think education carries most of the guilt for this. The typical examples
given in OOS classes are stuff like Car is an ancestor of Truck and SportsCar.
Which led to Beans and Entreprise Java. You never want this kind of shit with
your data. Much better to use plain old maps to carry content the way God
intended, and to put your effort in creating flexible and reusable methods.

~~~
sz4kerto
> But if you actually build your application code as OOP

> Beans and Entreprise Java

I don't know. Netflix is built on Java, using OOP. It works well for them.
Windows is built on OOP, quite a big application and works.

J2EE has its problems, but it also gives you a lot of functionality. Reusing
methods is nice, but developers on projects with very complex business rules
(does not equal simple, but large scale projects!) don't worry that much about
flexible methods as they're experienced enough. Distributed transactions,
session replication, etc. are slightly more important. J2EE gives you all that
by default.

(And I really don't like EJBs and this kind of stuff, but don't mix up two
very different levels of problems.)

~~~
radu_floricica
> J2EE has its problems, but it also gives you a lot of functionality

I did have that in the back of my head when I wrote the comment. And speaking
of, I'm also aware that OOP was very popular, and I don't feel completely
comfortable when I criticize successful stuff - it must have worked for a
reason. But still, that's as far as my brain can take me by itself: OOP should
be used sparingly and EJB should not exist.

(For the record I code mostly in Java, though as lisp-like as I can)

------
sedlich
What probably scares me most is, that managers think OO is in general a
wonderful best practice you need to have in the company...

~~~
PythonicAlpha
Managers who think, there is a silver bullet, always scare me!

~~~
Retr0spectrum
Your use of commas has changed the meaning of your sentence. They look like
parenthetical commas [0] to me, so the sentence reads as "Managers who think
(there is a silver bullet) always scare me!".

[0]
[http://www.bristol.ac.uk/arts/exercises/grammar/grammar_tuto...](http://www.bristol.ac.uk/arts/exercises/grammar/grammar_tutorial/page_06.htm)

~~~
PythonicAlpha
Thank you. I am sorry, I am no native speaker!

Unfortunately, I can not change the post any more.

------
dmvaldman
[Shameless plug] For a philosophical interpretation on the differences between
OOP and FP, you may enjoy my gist: Descartes, Berkeley and Functional Reactive
Programming

[https://gist.github.com/dmvaldman/f957dd9a8ed3f6edf35d](https://gist.github.com/dmvaldman/f957dd9a8ed3f6edf35d)

~~~
n0us
It's actually a common misquote of Descartes to say "I think therefore I am."
A more proper translation is "I think, I am" which has significant
implications for his philosophy.

~~~
chucksmash
It is not a misquotation. In Meditations on First Philosophy what he says
translates to "I think, I am" but he'd used "Cogito ergo sum" (I think,
therefore I am) in previous works.

Subtlely different meanings to be parsed...

------
gutnor
This article is just pointing at the flaws, not really offering any
alternative. It is just as GP said, a rant better kept for the water cooler
area.

You can guess that functional programming is going to be his response I
suppose considering this page is the second part of a functional programming
article. (the first part being missing)

If you want to analyse, you would need to also talk about what OOP is good at
and how that translate in whatever other paradigm. This article only concludes
with a "I do think it is a valuable mechanism for developing software", but
there is absolutely no backing for that statement anywhere in the article.

I tend to agree with GP. At the end of the day, for general programming, any
paradigm is going to end up producing similar quality of code. Developer
competence, motivation and budget are going to be #1 factors that determine
code quality.

Google, OSS, Modern IDE, Engineering practices like Continuous
Integration/Deployment, TDD/BDD are all having a much bigger impact on the
code quality than the specific languages or paradigms.

~~~
radu_floricica
> At the end of the day, for general programming, any paradigm is going to end
> up producing similar quality of code. Developer competence

I'd say that "pure" paradigms tend to be almost equally bad (tried functional
programming in production code, wasn't all it's advertised to be). But this
actually leaves you with more freedom, because you have to pick pieces and
create your own style. So it turns out to be more important, not less, that
you understand the how and why of each paradigm.

As for how good this particular article was - well, I agree with the premise
and it gives links to sources. May not be the Mona Lisa of articles, but it
got my upvote. I'm not a regular HN reader so it's the first article on this
topic I've seen in a while.

------
malux85
"All evidence" [https://xkcd.com/605/](https://xkcd.com/605/)

------
nailer
I appreciate there's something I'm missing, but:

I use closures to hold state all the time in node, I still don't understand
why state in a closure is better than state in an object.

If someone could explain this I'd be grateful: articles like this just seem to
say 'state is bad' and ignore that it still exists in functional scopes.

~~~
seabee
State in a closure is equally as bad as state in an object. The difference is
FP gives you ways to manage and isolate state that simply don't exist in OOP.

------
PythonicAlpha
"All evidence" seems to me a real gross overstatement here. The author
collected some topics, where he means that OOP is bad and sticks some (partly
related) statements of other people to it and wants to convince with that,
even when he makes some valid points here [1].

I do not buy that.

The reality is, that when OOP is correctly executed (and there is the real
culprit, since few people have really understand it!) it really can help you
to lower the complexity of programs -- and that is decisive, not some halve-
religious statements.

[1] One example: Inheritance vs. Composition -- even OOP people have seen the
problem that overuse of inheritance is bad. But they don't throw the whole
thing out of the window, but tell where to use it or restrict its usage. Don't
just find the problems and fanatically throw all (even the good stuff) out of
the window!

~~~
sklogic
> it really can help you to lower the complexity of programs

Yet to be proven. I _never_ seen a single example of OOP bringing anything but
more unnecessary complexity.

~~~
PythonicAlpha
Than you might not have seen good OOP designs. My experience is different --
when you really apply good OOP design to software, you can reduce complexity
and come to a clearer overall design. But of course the typical 5 day Java or
C++ course will _not_ get you there. You must learn to think in OOP -- and
that is a process that might take years.

~~~
sklogic
Could you please point to a classic example of a good OOP design, where it is
clear that OOP made it simpler.

------
mtrn
Zed Shaw talked about experiences teaching programming in this LXTHW series. I
cannot cite the exact source right now, but in essence he said, that novices
grasp all concepts up to OOP, where there is no more analogy in computer
architecture and people seem to get stuck.

------
nly
Seems as good a thread as any to drop this

Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP
2015

[https://www.youtube.com/watch?v=xcpSLRpOMJM](https://www.youtube.com/watch?v=xcpSLRpOMJM)

------
danmaz74
Does anybody know of any language that supports OO, but that lets you declare
pure functions/methods - enforcing that those pure functions/methods only use
other pure functions, don't use global objects, etc? Lately we're adopting
Redux [1] together with React and the idea of being able to mix functional and
OO in a better way looks more and more interesting to me.

[1] [https://github.com/rackt/redux](https://github.com/rackt/redux)

~~~
AlexeyBrin
_Does anybody know of any language that supports OO, but that lets you declare
pure functions /methods - enforcing that those pure functions/methods only use
other pure functions, don't use global objects, etc?_

Well, turns out that one of the oldest programming languages in existence,
Fortran lets you do OOP, it also has _pure_ functions and subroutines. I'm
talking about about Fortran 95/2003/2008:

[http://h21007.www2.hp.com/portal/download/files/unprot/fortr...](http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0157.htm)

~~~
danmaz74
I would never have guessed. I wonder why this didn't spread more - it looks
like a great way to mix FP and OOP.

------
Delmania
As a comment indicates, all evidence points to this article being a load of
bullshit. There's not a single concrete example in it that proves anything of
the author's claim. To counter, I think this will do nicely:
[http://www.johndcook.com/blog/2015/07/31/the-success-of-
oop/](http://www.johndcook.com/blog/2015/07/31/the-success-of-oop/)

------
k__
I really like many points of FP. I like to stick to immutability, map-reduce
and expecially Redux.

But after I saw a comparison of OOP and FP [0] I had to laugh a bit. What
about monads and category theory? I also didn't fully grasp FRP with all its
streams and lifting.

[0]
[https://pbs.twimg.com/media/CNPKc6xU8AApYPy.jpg](https://pbs.twimg.com/media/CNPKc6xU8AApYPy.jpg)

------
chmike
This argumentation is compilation of unjustified and demonstrated claims. It
really doesn't help in understanding the author's point.

------
billsix
I found it ironic that he used a quote from Alan Kay to attempt further his
point that "object-oriented programming is bullshit"

~~~
dang
Yes, and the 'quote' from Dijkstra, who would certainly have known about OO's
Norwegian roots, sounds bogus as well. Wikiquote lists it as unsourced.

A bit of Googling yields no source for the alleged Alan Kay quote either.

------
asgard1024
I believe OOP gained such a foothold in programming world because it was (and
still is) very useful for building GUIs on the PC. Since PCs have taken over
the world, so had the OOP. But in other areas the OOP model is questionable.
For example, you have transaction processing applications that have been built
for years on mainframes with different models.

------
MrDosu
I agree with Carmack on:

"'good C++' is better than 'good C'"

OOP has some brilliant patterns. It is also very hard to do correctly.

~~~
sklogic
Good C++ is a generic C++. And generic programming is incompatible with OOP.
Those who do not agree with this statement should stop using STL.

------
randomsearch
A little off-topic, but do people think that mainstream software development
will ever be mainly functional, or more likely to be an OO-Functional hybrid
like OCaml, Scala, or F#? Just wondering what to learn next.

------
xamuel
The best way to see through language paradigm war propaganda is to look at
pseudocode. Scientists, mathematicians, logicians write tons of pseudocode and
it's almost entirely procedural.

~~~
AnonymousPlanet
As one of those people who have used pseudocode in papers, I have to disagree.
In a scientific paper, you describe what you have in mind using mathematical
definitions. This makes it easier to reason about (proofs) and to describe it
in an unambiguous way to other people (papers). Pseudocode is used to describe
an algorithm following those mathematical definitions. In your paper, you
might use sets. A set is defined by what it contains or does not contain.
Never by how the elements found their way into the set. Including that kind of
implementation detail is considered bad form (cf. forest and trees). If you
wish to implement it using purely procedural code, FP, or OOP is up to you.
Don't think scientists shun any kind of method just because they rarely talk
about it. And for the record, I remember a number of papers that used
pseudocode that could have been directly translated to working code using an
OOP paradigm.

~~~
xamuel
The algorithm might take set(s) as input, sure. If that's inherently OOP then
C structs are OOP. In any case, what actually happens to those sets once
they're declared, will probably be procedural. "Let I be the intersection of A
and B." "Let Restriction be those elements of S which are positive." Etc.
You'll rarely ever see factories, managers, private variables, explicit
inheritance, or any other flagship OO mechanisms in pseudocode.

~~~
AnonymousPlanet
> You'll rarely ever see factories, managers, private variables, explicit
> inheritance, or any other flagship OO mechanisms in pseudocode.

Because they are implementation details that have no place in pseudocode.
Their absence there does not say anything about their usefulness in general.
You can't point at some observation about pseudocode and say "See, they don't
use it so it must be rubbish." Exceptions, handling of error variables,
monads, unsigned ints are also absent from typical pseudocode (unless the
context is _about_ those concepts). Does that make them useless concepts
aswell?

------
chmike
This argumentation is a compilation of unjustified and demonstrated claims. It
really doesn't help in understanding the author's point.

------
baxter001
Wow, so many people commenting in the thread below that article seem to have
swallowed tiny uncle bobs.

------
stonemetal
For an article with evidence in the title, it is sorely lacking. Pretty words
are proof of nothing.

------
anta40
Wonder why the author doesn't mention Smalltalk. Or Ruby...

------
armitron
Entirely content-free bullshit article.

------
JumpJumpJump
With billions and billions of wealth created by SaaS companies that base their
platforms and websites on OOP.

~~~
max-a
>With billions and billions of wealth created by SaaS companies that base
their platforms and websites on software.

FTFY

~~~
JumpJumpJump
Your data points may differ, but eBay makes profits of 1B on mainly a Java
platform. Other large companies use Ruby, PHP, Python and Java which all are
based on OOP.

But I would be interested in your arguments.

------
JupiterMoon
Humanity has to accept that half of any population (including the team in our
current workplace) is less intelligent than the other half. Then when we
address a problem we have to accept that both halves will have to touch the
problem at some stage in a project. Following this we need to aim for
simplicity rather than complexity. With this in mind I think that both FP and
OOP _can_ be used to build simpler programs but that OOP has in the past
failed in doing this.

Basically I think we need to use tooling (in which I include languages and
paradigms) that aim to come with less foot-guns and more safety rails.

~~~
JupiterMoon
Just wondering why people don't like this post? Anyone care to explain why I'm
wrong or maybe discuss?

