
Object Oriented Programming is Inherently Harmful - idoco
http://harmful.cat-v.org/software/OO_programming/
======
captainmuon
At some point I realized I don't really need OOP itself, but I like a couple
of bits it provides. Mostly:

\- The syntax. I like to be able to say thing.doSomething(). It doesn't always
make sense, but sometimes subject-verb syntax is more natural than a function
call.

\- Polymorphic dispatch (is that the term?) to replace if blocks. Instead of
`if (thing is Car) thing.drive() else if (thing is Boat) thing.swim()` its
just thing.move(). Pattern matching in functional languages solves this in a
different way.

\- Interfaces are nice.

I guess I could be happy in a language that just has structs and functions,
and some help in form of pattern matching, multimethods and so on.

~~~
thisjepisje
Regarding your second point, what would be the functional equivalent?

~~~
Ixiaus
He means pattern matching functions, which are idiomatic in Erlang but "dirty"
in Haskell (where you would want to solve it better with a type class, or
something else more general).

 _Erlang_

    
    
        myfun({duck, "My Duck's Name"}) ->
            dosomething;
        myfun({dog,  "My Dog's Name"})  ->
            dosomething;
        myfun({cat,  "My Cat's Name"})  ->
            dosomething.
    

Erlang also has arity matching (this function is different than the one above
it):

    
    
        myfun({cat,  "My Cat's Name"}, cage) ->
            dosomething. 
    

Case statements are one way of doing that but those are considered a messy
style in Erlang because they end up nesting so deeply - keeping it all out in
small little functions and using pattern and arity matching is the "right"
way.

You can do the same (except for arity matching) in Haskell with function arg
pattern matching and Haskell also has some very nice _projection_ tools for it
too:

 _Haskell_

    
    
        newtype Name = Name { unwrapName :: String }
        data Animal = Cat | Dog | Duck deriving (Eq, Show, Ord)
    
        myfun :: Maybe Animal -> Name -> String
        myfun (Just a) (unwrapName -> name) = (show a) ++ "'s name is: " ++ name
        myfun Nothing _                     = "No animal given!"
    
        > let n = Name "Fido"
        > myfun (Maybe Cat) n
        > "Cat's name is: Fido"
        >
        > myfun Nothing n
        > "No animal given!"
    

There are many problems with that function and I could probably eliminate the
multiple function clauses and reduce it to one clause by getting rid of the
pattern matching and using the _maybe_ function:

    
    
        myfun :: Maybe Animal -> Name -> String
        myfun a (unwrapName -> n) = maybe default formatAnimal a
          where
            default = "No animal given!"
            formatAnimal t = printf "%s's name is: %s" (show t) n
    

That would be the more idiomatic way I would do it - pattern matching isn't
"bad" in Haskell and you'll see it used quite often in utilities and
libraries. It's considered good form to move stuff like that into a utility
and give it a clear name (like the _maybe_ function above that takes our
_formatAnimal_ function) then use that in your application code so it becomes
obvious what's going on.

Pattern matching, deeply nested ifs and cases, etc... are somewhat hard to
parse for the eye.

~~~
codygman
What is concept is the:

    
    
        newtype Name = Name { unwrapName :: String }
       (unwrapName -> name)
    

I'm not familiar with this, are you pattern matching on a function type?

~~~
dezgeg
It's the View Patterns extension:
[https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns](https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns)

------
lmorris84
I'm a Java programmer so work with OOP every day. I think it has it's pro's
and con's like everything else.

My pet hate is how dogmatic some people get to the point where they get angry
over the use of if/switch statements. "It's not good OOP, use polymorphism",
well the goal isn't to pass an OOP exam, but rather to write clean
maintainable code where possible. If an if/switch saves me writing 6 classes
with 3 lines in each of them, then that's what I'll do.

~~~
goalieca
My pet peeve is how these brilliant architects end up writing so much code
that does nothing. These 1 line functions just end up calling another 1 line
function. At some point someone actually has to write the code. You know, that
thing that actually does the work.

I always figured OOP programmers actually hate coding because they try so hard
to avoid actually writing code that does work.

~~~
nickbauman
I would consider myself lucky that someone with the word 'architect' in their
job title on my team wrote code that did nothing. Careful what you wish for.

~~~
slowmovintarget
There are Marchitects, Tarchitects, and Farchitects (Market-oriented,
Technology-oriented, and umm... "freaking" architects).

Sounds like you have a team of Farchitects.

I have the title "architect", and I write code. It's usually code that lets
the other thirty programmers write one or two lines of code instead of 200
lines, 30 times, in 17 different ways.

Because it is framework code, I'm often providing them the Lego blocks to
build the rest of their system in... With unit tests... and examples... and at
least one real implementation... and a Wiki page explaining it... and a
Powerpoint session teaching them how I expect them to use it.

I do get the occasional grumble ("Uhh... Can't I just use Doohickey V
directly?" "Sure, take a look at the interface, and don't forget the
externalized configuration." "Oh.")

Just sayin'. There are architects and there are Architects.

------
al2o3cr
Guest post from the future - here's a quote from a similar page on cat-v.org
in 2024:

"FO is the “structured programming” snake oil of the 10s. Useful at times, but
hardly the “end all” programing paradigm some like to make out of it.

And, at least in it’s most popular forms, it’s can be extremely harmful and
dramatically increase complexity."

~~~
TheOtherHobbes
Indeed.

It's much easier to be a web contrarian than to build widely-used solutions
that don't have limitations, drawbacks, inconsistencies, or other issues.

~~~
imanaccount247
It is a list of quotes from people who have in fact built such "widely-used
solutions". How is that being a "web contrarian"? Do you really think Rob Pike
has never written any code? How did go happen then? You don't think Carmack
has maybe a little bit of experience with large, complex software projects?

------
eudox
I was briefly part of the "OOP is overrated, functional programming is in"
camp. OOP is enterprise, functional programming is "simple" because it's just
functions and data, you know, all the usual party lines.

Well, turns out CLOS is so good it's hard to stay away from it. You don't
struggle to force something into an inappropriate object-oriented paradigm,
rather, object-oriented solutions just flow naturally from the problem. And
it's a pleasure to use.

~~~
jerf
I'm reasonably convinced that inheritance is a bad default/privileged operator
for a language. Composition is a better default.

I often find myself suspecting that the hate OO gets is primarily a result of
this early error.

The remainder is of course the way OO was promised to be the end-all of
programming paradigms, which has not happened. Backlash is fully justified for
that.

------
kul_
I really find Carmack and Armstrong's quotes very appropriate. The root
problem seems to be trying to do _eveything_ the OO way when all you need is a
function. Java for e.g. is plagued by this problem. Why would I want to write
a class/object when all i need is print "Hello World". That being said there
are problem where it fits really nicely e.g. Implementing user roles.

~~~
klibertp
> Why would I want to write a class/object when all i need is print "Hello
> World".

There is a huge gap between what OO could/was meant to be and how it is seen
nowadays. I prefer thinking of OO as it's implemented in Smalltalk or Io
instead of in C++ or Java.

To be more specific, in Smalltalk your hello world would look like this:

    
    
        Transcript show: 'Hello world'
    

and in Io:

    
    
        "Hello world" println
    

No class/object declaration in sight, right?

And then this:

> The root problem seems to be trying to do eveything the OO way when all you
> need is a function

is a wrong question altogether - there is nothing stopping you from writing a
function in OO (other than broken and dumbed down implementations in major
languages, that is). In Smalltalk:

    
    
        my_func := [ 'Look, I'm a function!' ].
        "There's this slightly unusual way of calling the function though:"
        my_func value. "returns 'Look, I'm a function!'"
    

similarly in Io:

    
    
        my_func := block( "Look, I'm a function!" )
        my_func call # same as above
    

So, to make my point clear: there is NOTHING in OOP itself which REQUIRES
verbosity and over-abstraction. On the contrary: going "full OO" makes it
easier to write short, readable, to-the-point code. It also makes it easy to
use FP patterns should you want it.

What you're arguing against are the currently popular implementations of OO,
which are just bad. And before I forget: Erlang (and I program in it quite a
bit) is one of the best Object Oriented languages I worked with.

~~~
mikkom
I'm not sure if you are trolling or not but erlang is not an object oriented
language. Joe Armstrong said it quite clearly in the article where his quote
was taken

> As Erlang became popular we were often asked “Is Erlang OO” - well, of
> course the true answer was “No of course not” - but we didn’t to say this
> out loud - so we invented a serious of ingenious ways of answering the
> question that were designed to give the impression that Erlang was (sort of)
> OO (If you waved your hands a lot) but not really (If you listened to what
> we actually said, and read the small print carefully).

[http://harmful.cat-v.org/software/OO_programming/why_oo_suck...](http://harmful.cat-v.org/software/OO_programming/why_oo_sucks)

~~~
klibertp
I'm not trolling; of course whether Erlang is OOP depends on a definition of
OOP you consider "real". If you think of OOP as Java-style programming, then
of course, Erlang has very little in common with it.

On the other hand, if you go back to what Alan Kay had in mind when he
invented OO, namely objects as "black boxes, similar to computers in
miniature" and "message passing as the only way of doing something" then
Erlang is very, very much OO. Its processes are objects, and sending
(asynchronous!) messages is built into the language. Then you get
encapsulation, data hiding and interfaces with module exports and behaviours.
That doesn't stop Erlang from being FP, too.

Really, there are many different paradigms and many implementations of each
one, it benefits no one to only consider one particular implementation as
representative for a whole paradigm.

Footnote: Alan Kay post on a similar topic:
[http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-...](http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-October/017019.html)

------
sly010
Complaints agains oop often arrive from the fact that the programmer starts
with an idea of the instance method "do()" and tries to build a class
hierarchy under this idea. When the programmer fails, obviously the paradigm
is wrong because the idea can't be, right?

As for functional vs oop, I am on the opinion that just because the haskell
type system is awesome, and the java typesystem is traditionally unflexible,
it doesn't mean functional > OOP. Language features like objects, static
checking, first class functions are typically very orthogonal, hence you
should be combining the features, so they match your domain.

I figure as code evolves, it generally takes 3-4 rewrites to get class
hierarchies to a point where it matches your domain and more often than not
the solution involves shallow trees and the use of traits or mixins which is
something traditional oop languages don't all support well.

The only harmful paradigm is "write only programming", everything else is
negotiable.

~~~
moonchrome
Functional vs OOP isn't really about the type system - Clojure is a functional
language and it's dynamically typed.

The main value of functional programming is working with values and isolating
mutation. When you deal with just immutable values your code maps to
distributed systems naturally which is why functional programming is becoming
more popular with the advent of cloud and distributed computing.

~~~
seanmcdirmid
> When you deal with just immutable values your code maps to distributed
> systems naturally which is why functional programming is becoming more
> popular with the advent of cloud and distributed computing.

I work with hardcore distributed systems people (the ones that attend SOSP and
OSDI). And the penetration of functional programming in distributed systems is
about 0%. Sure, immutable state is easy to not share, but sharing of mutable
state is inevitable, and you gotta deal with it, not try to wish it away.

The only people who seem to think functional programming is great for
distributed systems seems to be people who don't really do distributed
systems, or at least ones where scalability, performance, and fault tolerance
are critical.

~~~
judk
Shared mutable state tends to be only in a core data store or scheduler/thread
manager, a small part of a distributed system.

~~~
seanmcdirmid
Ya...no. Maybe toy distributed systems, but not the larger ones industry works
with. Let's put it this way: if you have no shared distributed mutable state
to worry about, it's not really a distributed system, it's probably doing
parallel computation or something similar (like via map reduce).

------
Aqueous
"Inherently harmful" is a bit vitriolic. If not a majority then a huge
percentage of the world's systems are based around OOP and for the most part
they function just fine. When people say these things I wonder what bubble
they are living in where something is either the best thing ever or shit. The
world doesn't work like that.

That said, I prefer a hybrid approach which is why I use Scala. It's not an
either/or (or, if you prefer, an Option monad :-)

~~~
rrradical
Sure, but sometimes strong opinions are necessary to make progress. If
Dijkstra hadn't written "Go To Statement Considered Harmful", would we still
be using them today? Probably not, but it probably helped bring quicker
progress.

Just because you can build a house with a rock doesn't make it the best tool
for the job, and it's in the interest of the carpenters to figure out what is
the best tool for the job.

------
vardump
I often dislike C++ and Java (note: did not say object oriented programming),
because the logic tends to be distributed in so many different files and
locations. The abstractions, which should be beneficial, to decrease mental
load, have the opposite effect over a longer time. To understand what just one
overloaded method call does, I have to often read through a dozen of different
files. Context sensitive IDEs don't make it much easier. Simply grepping files
at command line is often the fastest way!

Combine that with object mutable state. And that with multi-threading
(surprise state changes). Add exceptions on top (surprise hidden gotos,
especially annoying in C++). The end result is often nearly impossible to
fully understand.

However, this is not anti-OOP rant really. I recognize OOP has its uses.

The bigger issue is almost always when there's a discussion whether X is
better than Y, some people seem to forget often both X and Y have their place
in the toolbox. They're often complementary. When you like technology X,
technology Y is not a threat to you, but an opportunity to learn something
new. In the same way, criticism against X can be an opportunity to learn and
improve. Not hostility against people who like or are used to technology X. No
matter how much you like hammer doesn't make a saw a bad tool.

~~~
jimmaswell
>To understand what just one overloaded method call does, I have to often read
through a dozen of different files. Context sensitive IDEs don't make it much
easier. Simply grepping files at command line is often the fastest way!

Right click -> Find all references / go to definition don't do that faster
than typing out the grep command?

You said mutable state makes it harder to understand, and you said exceptions
make it harder to understand because they're hidden gotos (which if statements
and while loops are too), but didn't explain either. In my experience,
exceptions have been a very simple, helpful, intuitive component of control
flow.

~~~
vardump
> Right click -> Find all references doesn't do that faster than typing out
> the grep command?

Yes, IDE is not generally faster. Find all references is not faster for me in
most real life scenarios. Typing grep command is just arrow up, ctrl-something
to get the cursor to right position, type something, hit enter. Piped to less,
I hit / to search within the results. Done right, results from grep appear
pretty much instantly, no waiting. Some operating systems are much better for
this technique than others, due to cost of dealing with small files.

> You said mutable state makes it harder to understand, and you said
> exceptions make it harder to understand because they're hidden gotos (which
> if statements and while loops are too), but didn't explain either. In my
> experience, exceptions have been a very simple, helpful, intuitive component
> of control flow.

Whenever you call some method (or overloaded operator), it can throw. The fact
is completely hidden from the context in front of you in C++.

In Java, you do know what might throw, because you have to declare it. On the
other hand, the cost is high when anything you call changes the exceptions it
throws. Or more like, it's set in stone.

~~~
jimmaswell
That still sounds like more work than the way I do the same process in Visual
Studio, which uses the AST or something around that level to search the code
instead of just a text search, so it doesn't find irrelevant results. I guess
it depends on your environment.

It is better when it's specified exactly what exceptions can be thrown by a
method, yes. One of the only things I prefer in Java over C#.

~~~
vardump
If only Visual Studio/C++ used AST! At least in Visual Studio 2012/C++,
context sensitive search doesn't often work at all. Try to get context for
something common like ".create". You get a lot of non-context hits, even
thousands. Maybe I'm doing something wrong? Maybe this doesn't happen in
VS2013? In most other IDEs context sensitivity is better, but I still fall
back to command line in Linux. It's just so much faster (for me). I get what I
want in about 0.1 to 3 seconds and can _easily_ search near (grep -A and -B
switches) these context hits with '/' in "less".

Git grep is great too.

Regardless, if it works for you, great. We should all use what works and
disregard needless debate and politics.

~~~
jimmaswell
I haven't used it for C++, only C# and VB.NET. It's integrated more with
those, probably not with C++

------
nickbauman
OOP and FP are not in opposition to each other. FP considers objects to be at
different granularity than your typical OO language does. So the real problem
stems from the fixed granularity of the objectionable (heh) of typical OO
languages leads to mutable state, which leads to unnecessary complexity.

In the end, typical OO leads to type systems which lead to noun discrimination
which are ontologies, which reflect world-views. You don't want to get any of
that on you. The more successful type systems stop at grouping aggregatable
functions. Look at Go. Or Clojure. Those type systems are as good as it gets
to me but I've never written a line of Smalltalk or Haskel, so someone set me
straight on that.

~~~
aikah
> OOP and FP are not in opposition to each other. FP considers objects to be
> at different granularity than your typical OO language does.

well FP purists would argue that objects(a unit that has properties and
methods, and can pass messages to collaborators)have states.AFAIK "pure FP" is
about getting rid of states,using immutable datastructures, and describing
operations on stateless units,rather than writing imperative code.

I personally believe that being a FP purist or OOP purist doesnt make
sense.Both paradigms can work together thus be orthogonal and not in
opposition.

~~~
klibertp
> AFAIK "pure FP" is about getting rid of states

Of course not. It's about making state be always explicit and about carefully
controlling side-effects. Some state is going to be there always.

------
tptacek
In the quixotic hope of heading off a pointless argument: the opposite of OOP
is not functional programming.

~~~
jonsen
"... a computer model should be structured along three dimensions: data,
functionality and events":

[https://news.ycombinator.com/item?id=475241](https://news.ycombinator.com/item?id=475241)

~~~
DenisM
Y'know, I spent half a day today thinking about it, and your post gave me a
nice, fresh angle at the problem. Thanks for that. So here's what I came up
with (still work-in-progress):

The most simple program is easily done in assembly- or basic-style program -
straight sequence of control instructions. The program starts with a set of
data, constructs an intermediate data structure, a state graph, iterates on
that graph in a simple sequence of commands, mutating it, collects output from
the graph and then terminates.

When a program gets more complicated, we break sequence of commands into
subsequences (subroutines/functions/etc). Each subroutine can be understood in
isolation from others, which is a great win, but it still interacts directly
with various pieces of the state graph, which limits our ability to reason
about its effects.

Next we carve out individual pieces of the application state graph, and
proclaim that each such piece can only be directly accessed by a small amount
of code married to that piece of data. Such code and data married together are
called an "object", and the entire approach is "object-oriented". Thus to
reason about a subroutine we only need to look at its code in terms of its
interaction with the "object" abstractions, rather than with the raw state
graph data. Since abstractions are simpler than their implementations, it
gives us extra ability to understand and thus create larger programs.

Implicit in the last two approaches is mutability - as the graph state
changes, the same pieces of code continue to have access to it, and thus are
expected to accomodate the drifting state. That is, the same chunks of code
are expected to operate with a number of different states of the graph,
corresponding to different stages in the lifecycle of the data.

An alternative way to cut down on complexity is "pure functional". In this
approach each piece of code operates directly on the entire data graph, but
only at a single stage of the lifecycle - it would iterate over an input
readonly graph, then produce a new output readonly graph as a result, to be
fed into the next stage of the pipeline.

So we have two dimensions - data and time. If we narrow down the data
dimension, we end up with object-oriented approach. If we squish the time
dimensions to a single point, we end up with pure-functional approach. The
third dimensions - sequence of commands, is split up into smaller chunks in
either of the two approaches.

~~~
jonsen
Interesting thoughts. Now you set me off for at least half a day of thinking
further. By the way, your sibling question already set me off studying
reactive programming which I didn't know much about. It seems like reactive
programming is lifting the time aspect of programming to a more prominent
position. So functional-reactive coordinates functionality with timing. Will
be interesting to see how the data dimension fits in then...

------
electrograv
You are using "object oriented programming" by definition, the moment you
formulate an "object" in code with interactions on that object (regardless of
what language you're using)!

I completely agree with the arguments showing how harmful OOP abuse is
(especially branching inheritance trees!), just like abusing pointers, or
structs, or error codes, or _abusing_ <insert_language_feature_here> is
harmful. But what does that have to do with OOP inherently?

Let's look at historical crashes, glitches, and hopelessly messy code and try
to count their actual source. I bet you'll find sloppy programmers as the #1
root cause (maybe null-able pointers and/or weak typing as #2). OOP isn't bad
because it's OOP, it's bad because hordes of bad programmers use it at big
companies who don't care about code quality.

Beautiful functional code is beautiful.

Beautiful procedural code is beautiful.

Beautiful object oriented code is beautiful.

...

Spend more time writing beautiful code that draws its elegance from the rich
set of paradigms and tools we have; spend less time participating in fad
paradigm-ocide movements :)

~~~
jokoon
Containers are a particular case. almost nobody re implements a container. and
you're talking and template, not OOP.

> How would you do this without some kind of "object orientation"?

Variables. Variables are not "objects". What is an "object" anyway ? It's a
shallow abstract concept which is impractical.

> The moment you formulate an "object" in code with interactions on that
> object

No that's not what the article is trying to talk about.

What people argue against OOP is how it's applied to anything for any case.
Creating new classes/type/abstract concept each time you want to realize
something can often lead to code bloat. How many classes named "XXX_manager"
can one encounter ?

> Sorry for shattering everyone's hopes and dreams of coding pure OOPless.

OOP tends to have state, which doesn't bode well will multithreading, which
tend to favor functional programming. I don't know if the future is going to
be massively multithreaded, but I just think that OOP is just another way to
structure a program, nothing more. Processes and threads already are objects.
Functions too. So why tell students to create new types all the time ?

------
guard-of-terra
I wonder if there are GUI widget systems not based on deep inheritance trees.

It seems to me that GUI and OO are deeply synergetic.

~~~
kps
It's only slightly oversimplifying to say that OO was invented for a GUI,
namely Ivan Sutherland's _Sketchpad_ in the early '60s, and then developed
with direct correspondence to physical objects in mind ( _Simula 67_ )

\-
[http://en.wikipedia.org/wiki/Sketchpad](http://en.wikipedia.org/wiki/Sketchpad)

\-
[https://www.youtube.com/watch?v=USyoT_Ha_bA](https://www.youtube.com/watch?v=USyoT_Ha_bA)

\- [http://en.wikipedia.org/wiki/Simula](http://en.wikipedia.org/wiki/Simula)

\- _The Development of the Simula Languages_ in HOPL I if you can get it, else
[http://phobos.ramapo.edu/~ldant/datascope/simula%20history.p...](http://phobos.ramapo.edu/~ldant/datascope/simula%20history.pdf)

~~~
seanmcdirmid
Sketchpad was prototype based, simula was early class based (though they
didn't use those terms yet). It's likely they were developed mostly
independently; OO just arises naturally when design is based on linguistic
concepts like subjects, nouns, and things they can do.

What we know of UI today is more an artifact of smalltalk (both the first GUIs
and smaltalk came out of parc and were related).

------
ap22213
OO just helps me understand the code (assuming that it is well-written, which
isn't always the case). I don't understand the hate.

I have always imagined that it was just a natural progression from procedural
code:

1\. Put a bunch of functions in a file.

2\. Ok, now we have too many functions to keep track of, so let's put
functions in separate files.

3\. That worked for a while, but now too much repeated code, let's put some
functions into modules.

4\. Now, we have all of these variables to keep track of, so let's hide some
of them to lessen any confusion.

5\. Etc. Etc. Etc.

6\. Wow, now we have a complex language with all sorts of patterns that
perhaps confuses things more than intended.

That's why I like languages that are lean and have pragmatic features. OO,
functions, whatever works to make my life easier.

------
GFK_of_xmaspast
One thing in that article stands out:

"OO is the “structured programming” snake oil of the 90' Useful at times, but
hardly the “end all” programing paradigm some like to make out of it."

In 2014, I think it's important to remember that "structured programming" was,
basically, "hey let's use FOR and WHILE loops, and subroutines, instead of a
big pile of GOTOs", and think about what that says about any author who
describes it as "useful at times" and "snake oil."

------
vinkelhake
Catchy and content-free soundbites that do nothing to further a discussion.

One of the big problems with discussions around OOP is that people have wildly
different opinions on what OOP is. Whatever it turns out to be, it'll be a
tool like any else that can be used efficiently or poorly.

~~~
bkeroack
Click the first link:
[http://harmful.cat-v.org/software/OO_programming/why_oo_suck...](http://harmful.cat-v.org/software/OO_programming/why_oo_sucks)

~~~
vinkelhake
I've read it before. It's a fluff piece for Erlang. You can tell that it's not
a serious argument since he doesn't acknowledge _why_ things are done a
certain way in OOP and what the advantages are. He obviously things the cons
outweigh the pros, but Armstrong doesn't have to feign ignorance on the
matter.

------
tormeh
I think inheritance is a really good idea, and that most problems with it
result from people forcing inheritance onto problems not benefiting from it.

Can we all just make a resolution not to use any technique (no matter how
fashionable, not even FP) on a problem unless it is a natural fit?

------
lentil_soup
In this CppCon keynote, Mike Acton explains some of the problems with OOP and
the benefits of data driven design. Really worth a watch:
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)

------
rrradical
I am a big proponent of functional programming, but there are situations where
it would be veeerrryy convenient to have open types and inheritance, which is
forbidden in a language like Haskell.

Modelling something like a GUI toolkit is very difficult in Haskell, because
each widget has a different clump of data associated with it. Functional
programming works well when the data is uniform, or at least known ahead of
time. It's very difficult to add new data structures into the system in a
dependent module, like if you want to add a custom widget type. In OO, this is
trivial.

I'm not sure what the best solution is. People are researching alternative
solutions (namely FRP), but it's too bad it's necessary in the first place.

~~~
codygman
> like if you want to add a custom widget type

Add a custom widget from a gui program itself? So it's a gui program that has
a widget builder then? Why not have an abstract data type which lets you
encode the properties of both of those?

~~~
rrradical
I'm talking about supplementing a toolkit. Like, in iOS or gtk or QT or
whatever, there are stock widgets (buttons, sliders, text boxes), but you can
also add your own widgets, like a date picker. A date picker would be modeled
completely differently from those other widgets, and so it needs a completely
different data structure. This requires supplementing the existing types,
which isn't possible in Haskell.

~~~
codygman
That date picker inherits from something though right?

~~~
rrradical
Right. In OO, you can inherit, but in Haskell, you can't.

~~~
codygman
Also, I'm not sure why you'd need to inherit to provide this functionality.
The user could just provide a monadic type the function to run the gui is
expecting and extend it however they wish.

~~~
rrradical
I won't claim to be an expert on this stuff-- I've only recently been studying
this. But, from my understanding, if you have a tree of GUI elements, each of
those elements needs to have the same type, and that type needs to be known
ahead of time. It's possible I don't understand your comment. Would you mind
pointing me to some sample code or blog post or something?

------
seivan
I've been working on leaving OO recently. This is my current API. No deep
nested hierarchies of classes anymore!

    
    
      self.player.addComponent(Controller())
      self.player.addComponent(Shooter())
      self.player.addComponent(Jumper())
      self.player.addComponent(Life())
      self.player.addComponent(CharacterPhysics())
    
    
    

People who generally code applications could learn a lot from game developers
and game engines. I took inspiration from Stencil and HaXe (but using Swift
and SpriteKit) [http://www.stencyl.com](http://www.stencyl.com)

~~~
jschwartzi
That's an excellent use of Composition. Most people think inheritance
hierarchies are necessary for OO, but composition/aggregation is a much better
way to do things.

A lot of the complaints I've read about OO center around people doing stuff
that they later determine they didn't need to do, and then being stuck with it
because it's in the middle of an inheritance hierarchy. Modern OO design would
center around decomposing each class in the inheritance hierarchy such that
the decomposition produces small subsets of shared behavior, and then
composing those together to create the actual object. As a bonus you can still
produce run-time polymorphism without crawling an inheritance hierarchy.

Composition in an OO system is very much like composition in mathematics. Two
objects are combined to produce the desired behavior.

A lot of people crap on the GOF book because the patterns in it are either
obvious or useless, but reading it does teach you some useful concepts, and
for many people it will be their first direct exposure to something other than
inheritance. Composition/Aggregation are great takeaways from that text.

As an example of a crappy inheritance hierarchy, a developer 20 years my
senior had this four-layer inheritance hierarchy to represent 3 different data
types. After he gave it to me I spent 15% of my time convincing him to let me
eliminate half the classes he wrote. The worst part was that he was inheriting
and then in the subclass he was writing functions that were semantically
identical to superclass or cousin-class functions, but with different names.
After I eliminated all that I was able to use templates to hide a lot of the
mess.

OO design should be done according to the YAGNI principle--You Aren't Going To
Need It--and its corrolary--do it as soon as you need it.

~~~
seivan
Hey, thanks!

Yeah, that's the impression I get. The ability to add functionality to an
object in small modules (Components/Behaviours)

However this only works if there is a inherent structure and ability to use
components. Most frameworks and libraries I have worked with don't really have
that structure.

For instance, SpriteKit (Apples 2d framework) lacks a structure for building
components. So most SpriteKit examples tend to have deep hierarchies of class
inheritance.

If you'd want to take a look I wrote this
[https://github.com/seivan/SpriteKitComposition](https://github.com/seivan/SpriteKitComposition)

Documentation is still lacking as I am playing around with function names but
it has a test suites that demonstrates usage.

------
sinofsky
These are some great quotes. Caveat: I am old. Programming methodology debates
wear me out as quickly as language or commenting convention debates :)

I certainly remember many of the quotes when they first came about. I’m a
product of the object-oriented wave. At the time I felt I had all the
arguments as to why things were so much better with (or so much worse without)
OO. In many cases, looking back I realized I was basically arguing for better
tools and/or slightly better adherence to a few conventions.

My lessons from going through each “language” transition from debates over
“assembler is the only way” through today’s DSLs and more:

1\. OO wasn’t good or bad intrinsically. The principles, however, can easily
lead to more manageable or coherent code _over time_. By and large,
inheritance, polymorphism, encapsulation, abstraction all form the foundation
of large scale systems.

2\. Languages can do a great deal of harm, not concepts. Far too often,
engineers dive into a new language or paradigm and assume all the code needs
to exhibit all the properties of the new religion. In the early days of C++
programming, the saying we had on our projects was “a framework is not a
compiler test suite”. I think in all languages, especially today, the risk is
that you more harm than benefit when you try to do everything in some fancy
new way. Maybe there is a role of operator overloading or templates in C++ but
I never really found it. But I am pretty certain nearly every framework
employed these techniques. You can’t blame the language because every language
has stuff you can abuse. You can blame the zealots or evangelists which often
cause the most challenges.

3\. Language and paradigm innovation benefits rarely scale in very large
systems, but small systems early on exhibit amazing benefits. Most engineers
are seduced by new languages and paradigms (OO was just the one that came
after structured programming and before functional and others). In the
beginning, the new language or approach is amazing. Always amazing. Over time
the real world shows up and every new engineer feels that the code is bloated
and needs a rewrite when they join a project. Efficiency declines. The magic
fades as reality dominates. With more than a few engineers the complexity of
interconnection between parts of the code base trumps the simplicity and
elegance within one part of the architecture. Expressing those in paradigm or
language elegant ways approaches a very high degree of difficulty over time.
At one extreme we see competitions of “hello world” or the most basic app all
being amazingly simple. At the other extreme we see a constant breakdown in
even the most basic methodological approaches. Even “Goto” was hard to do
without and certainly in OO maintaining a pure inheritance model,
public/private data, or more become as close to impossible.

4\. In algorithmic complexity terms, a language or paradigm is at best a
constant factor improvement over any other choice. The age-old rule of thumb
is that programmer productivity is language independent. While I have no doubt
that one could not spin up a new social network in assembler, one would be
equally hard pressed to write a device driver or graphics runtime in Ruby or
Python. Part of why methodologies gain attention is because the
runtimes/libraries/frameworks that come with them do the things that need to
be done the way that people want them to work _today_ \---that’s what gives
the appearance of improved productivity. The right libraries in C can serve a
great purpose. We see this when a language gets a new library that seems to
bring renewed interest to it.

5\. Tools are everything. What makes or breaks a paradigm/language are tools.
You can take a simple language or paradigm and have great tools and become
much more productive than a “better” paradigm with poor or ill-suited tools.
One way that this surfaced over time was with tools that generated the right
code—interface builders for example. Then using complex, archaic, or intensely
manual approaches lacking formal foundations would become much easier. Plus
the bonus of transparency of code generation really helped because other tools
could easily integrate (having access to a whole tool system is also more
productive than any one methodology+tool).

Ultimately, I think OO is perfectly good and most all modern systems make use
of the 4 basic pillars of the paradigm. I don’t think it ever became the
answer to code reuse or code quality that proponents claimed. Ultimately the
methodology is going to be trumped by scale and age of code and system. Any
success means your ability to start over is reduced and so the best bet is to
focus on knowing what principles your project is being created and run with.

~~~
radicalbyte
> The principles, however, can easily lead to more manageable or coherent code
> over time.

This. 1000 times over. This is why well factored code bases can often seem to
have lots of redundant classes and interfaces to inexperienced developers.
It's all about maintainability over time, building bulkheads around change.

> tools that generated the right code—interface builders for example

The irony is that these tools often fail when the benefit is considered over
time. This comes through a lack of tools - their code works badly with SCM (no
domain-specific diff tools). They throw away everything we've learnt about
software engineering just to win the marketing demo's.

~~~
codygman
How do redundant classes and interfaces improve maintainability over time?

~~~
muhuk
Because they improve maintainability, they are not redundant.

~~~
codygman
I asked _how_ redundant classes and interfaces improve maintainability over
time.

I'll narrow down my question some more:

How does duplicated code improve maintainability over time?

~~~
hakunin
Author stated that classes and interfaces _seem_ redundant, not actually
redundant. Repeated code could improve maintainability because it may actually
have different reasons to change, and only look similar on the surface. I've
seen this often missed by inexperienced devs who get overzealous trying to DRY
up everything.

------
jokoon
I'm in some programming class in france. The teacher argued that OOP and
encapsulation makes programs more secure. It really felt like a political
statement.

The day I understood that class and struct are merely the same thing, I
questionned the purpose of private: and public:.

To be honest, I think the sole purpose of those construct is just to hide
proprietary code when you sell libraries and deliver a set of binaries and
headers, to force the compiler to forbid you from writing to, or using
protected member. It's really moot. It's just a coding practice, it's not some
grand way to think and construct applications.

OOP is nice if you want to create some non standard simple type, like Vec3, or
when you want to use an interface for something quite complex. Templates are a
good extension of OOP, but it's not used that much, even while the STL
justifies the existence of templates. But other than that, when you want to
make an end-user application which is not a library, I think OOP is not that
much useful. Too few programmers write libraries, most just write
applications, and applications don't need OOP.

If you use OOP to pretend that your code is reusable, please, first check if
what you're making really is worth reusing, chances are it's not.

TL;DR: OOP is good to design bricks. Most coders are not brick designers, thus
most programmers should not touch OOP that much.

~~~
alkonaut
Public and private has nothing at all to do with hiding proprietary code.
Encapsulation is important regardless of whether you use OOP or not. Even if
you program something alone that will never be derived/re-used, you should
strive to have clean boundaries between subsystems. You also want to make
things read-only unless they should change (most things should not)

If you make everything public and writable you have to spend a lot of thought
on things that a compiler could help you with so you can focus on solving the
problem. Much like using a type system.

------
princepajero
Object Oriented paradigm started when procedural was the most popular way to
code. There were problems with procedural approach that made understanding and
working in large applications very tough. Before OOPs came around, coders
tried encapsulating their code by separating them into separate files. This
however solved only one problem and that too only partially.

Coders also tried revolving their procedures (casually called functions)
around their objects - get_student_name(struct student _),
calculate_ranks(struct student_list_ ) and so on.

It was necessary to have a paradigm that represented code very close to how we
see this world. OOPs just had to happen.. it was not avoidable.

Now, the challenge lies in the fact that with everything powerful, one can go
ahead and use it incorrectly. There comes the harm. But then there are better
ways to learn the concept. I wrote a blog about OOPs recently. Read it here
[http://wp.me/p5jxzK-1b](http://wp.me/p5jxzK-1b)

Go ahead and use it, OOPs isnt going anywhere soon and it aint that harmful :)

[http://kossip.ameyo.com/2014/11/25/the-unusual-approach-
to-o...](http://kossip.ameyo.com/2014/11/25/the-unusual-approach-to-object-
oriented-programming/)

------
graycat
I am using _object-oriented_ programming (OOP) and like it! I'm using OOP via
Microsoft's Visual Basic .NET, the .NET Framework, ASP.NET, ADO.NET, etc.

For inheritance, I've never tried to understand it or use it. Yes, the .NET
Framework apparently uses inheritance, but there as far as I can see mostly
the _inheritance_ is mostly just imaginary, mostly just a means of
documentation. E.g., I can have a variable X of type byte, integer, float,
GUID, etc. and write X.ToString, that is, pass (it really is essentially call-
return semantics) the _method_ ToString _inherited_ from somewhere, some
_abstract class_ or some such, but I don't believe that there is actually any
real _inheriting_ going on. Maybe there is some _overloading_ , but then the
spelling 'ToString' is just a convenience for documentation and usage. Or,
just as easily it could be that in case the type of X was integer, then I
could write X.ToStringInt where the method ToStringInt was for converting
integers to strings. Fine with me. I know; I know: If I can write X.ToString
when the type of X is an integer, then where X is declared I can change its
type to, say, GUID and keep the code X.ToString and, thus, get _code rewuse_ ,
but I'd nearly never do that! Instead I'd want to check over my code to be
sure the code still did what I wanted it to do.

Mostly I look at instances of classes much like in PL/I where there were data
structures like

    
    
         Declare
            n_points   Integer,
            1 A        Based,
              2 Coordinates( n_points ),
                2 X  Float,
                2 Y  Float,
              2 Lengths (n_points) Float;
    

So, in Visual Basic .NET could write

------
mpweiher
OO has been tremendously successful, it has allowed us to build systems that
we wouldn't have dreamed of before. The Web was invented on a NeXT in
Objective-C.

Reuse in UI frameworks has been great, and I've had similar success with
custom frameworks.

However, success invariably contains the seeds of failure, because success
means that we are taken to the limits of applicability. To me, those limits
were visible in the 90ies when I wrote my Master Thesis[1], issues like the
non-composability of frameworks, the runtime/compile-time,
composition/inheritance dichotomies, architectural mismatch etc.

Alas, nothing really happened, and IMHO, things actually got worse. At the
time, I had two candidates for "the future", one being AOP and the other
software architecture. AOP was a dud, but I am very hopeful about better
linguistic support for software architecture, so much that I am creating a
programming language that has software architecture as its organizing
principle, deriving other paradigms such as OO from this base [2].

Having been exposed to FP early on, I have to admit I don't understand the
current hype, because it seems to primarily address issues of "programming in
the small" (tight coupling), although some of the lessons (communicate using
simple data) are applicable elsewhere, and have been discovered elsewhere. I
don't see a large-scale distributed system like the WWW built in the FP-
paradigm, but happy to be corrected!

[1]
[http://www.metaobject.com/papers/Diplomarbeit.pdf](http://www.metaobject.com/papers/Diplomarbeit.pdf)

[2] [http://objective.st/](http://objective.st/)

~~~
judk
AOP isn't a dud. Google Guice is AOP.

~~~
mpweiher
Really?

Taking the definitions from "Software Architecture: Perspectives on an
Emerging Discipline" [1], you have the following:

\- components

\- connectors

\- configurations (systems)

Guice (and other dependency injection frameworks) clearly address the third
part: configurations. AOP is, at best, an implementation technique.

[1] [http://www.amazon.com/Software-Architecture-Perspectives-
Eme...](http://www.amazon.com/Software-Architecture-Perspectives-Emerging-
Discipline/dp/0131829572)

------
Energy1
According to these guys, everything complex is harmful and everything simple
is great. I want to start learning Assembly to finally understand the whys of
programming on a hardware level. Is Assembly harmful? Any simpler and thus
better alts? Or is Assembly a simpler version of some other ugly, threatening
monster? Oh, btw, where's the best place to learn it?

~~~
mansr
Congratulations, you just discovered the great RISC vs CISC debate.

------
mpdehaan2
Separation of concerns, reuse, and modularity are the key principles here.

I'm a fan of hybrid OO/functional approaches, use classes but minimize side
effects. Return new objects when relevant, etc.

It's a mistake to misjudge OO based on some over-bloated java-design _or_ some
underdesigned implication.

The phrase "everything in moderation" largely applies.

Given, if you are doing things in C, and passing a structure as a first
argument, you are getting _most_ of the way there.

I think inheritance is frequently over-applied, interfaces are a great idea
(or even just duck typing), but not everything is an inheritance hierachy.

Rather, encapsulation is the most powerful concept.

Much of what gives OO a good or bad name is in the hands of who is doing the
architecture - abstracting things too early leads people to occasionally go to
the extreme other side of the fence.

There's a balance to be had, and advantage to learning from multiple schools
of thought.

------
ChuckMcM
I really liked this link:
[http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal...](http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)
from the server. It is from 2009 so a bit dated, but it shows something which
is prevalent today, objects obscure what they are doing, and they mix code and
data, but data access is a lot slower than it used to be so data optimization
is more important than ever.

That has only gotten more true with DDR3 and DDR4 memory and giant caches. It
is significant enough that it would behoove compiler optimizers to pause
trying to do things with fewer instructions and start looking at better data
organization.

------
yawz
I love the banana analogy :).

“The problem with object-oriented languages is they’ve got all this implicit
environment that they carry around with them. You wanted a banana but what you
got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong

------
kentbrew
OOP has the same relationship to programming that formalist literary critique
does to writing: the willful denial of connection to reality. When you're
solving a problem that's connected to the real world--perhaps you have a
deadline, or a live human being will use your program at some point--it's
often better to just go ahead and build something that works and can be easily
explained to the person who will maintain it in the future.

As with formalism you should know how OOP works and how seriously others take
it, so you don't get into fights with your relatives at Thanskgiving.

~~~
pjmlp
And first of all, learn (in general, not you) that OOP doesn't mean the same
to all programming languages, before complaining about OOP in general.

------
sudioStudio64
The thing that I learned from SICP isn't that functional is greater than OO,
but that functional and OO are both design strategies that can assist you in
designing a solution to a problem.

------
sbmassey
The problem with OO - and this applies to Smalltalk too - is that class
hierarchies are a bad fit for a changing business environment, being hard to
refactor when previous assumptions change: inevitably some new case will come
along which requires changes to the structures that were originally defined,
and OO is harder to deal with in that context.

That said, I do think OO is good for problem areas that actually have fairly
static interfaces, like GUI libraries, for instance

------
williamcotton
Object-oriented programming is a product of personal computing systems like
Smalltalk and Self.

This approach begins to suffer when application state is mixed between a
remote server and a local client. Further, the physical metaphors of OOP
suffer when removed from Smalltalk-like systems.

The rise of functional programming has as much to do with the rise of
networked computing and shared data than anything else.

------
mattxxx
Err... OOP isn't better/worse than any other approach, but there are some
criticisms that I can't disagree with... but I like having objects when work
requires some book-keeping

Programming is like kung-fu. You gotta pick and choose the best of each style,
when they are relevant.

------
GFK_of_xmaspast
Who is this "cat -v" guy anyway, they have a lot of badly written bad opinions
on a lot of stuff.

(
[http://harmful.cat-v.org/society/gay_marriage](http://harmful.cat-v.org/society/gay_marriage)
[http://harmful.cat-v.org/political-correctness/girls-in-
CS](http://harmful.cat-v.org/political-correctness/girls-in-CS)
[http://harmful.cat-v.org/economics/fair_trade](http://harmful.cat-v.org/economics/fair_trade)
)

~~~
codygman
"I treat my female coworkers with respect, I politely discuss technical stuff
with them if they feel like. I do make sexist jokes if I was able to get to
know them sufficiently before, like any healthy male."[0]

Wow. Any health male makes sexist jokes to women if he gets to know them? I
guess I'm just not very healthy then.

"My wife’s male coworkers behave the same way and I have no problem with
that."[0]

Easy to say you don't have a problem with something that doesn't affect you!

0: [http://harmful.cat-v.org/political-correctness/girls-in-
CS](http://harmful.cat-v.org/political-correctness/girls-in-CS)

------
graycat
I'm using _object-oriented programming_ (OOP) and like it. For the problems
described in the OP, I'm not encountering those!

I want to write relatively simple code, thus, want to avoid tricky features of
the software tools I use, and so far have been successful. But this desire
means that I don't have deep experience with tricky aspects of OOP. So, YMMV.

So far mostly my code looks just like it would have before OOP; I've created
only a few OOP _classes_ ; and all of those are simple. I write a lot of
functions but not many classes.

Some things I do like:

(1) Can have an array of classes and, then, can sort the array with whatever
class _properties_ want to use as the sorting keys.

(2) Can _serialize_ an instance of a class to a byte array, send the byte
array via TCP/IP, and deserialize the result.

Well, the OP notes some of the dangers of _inheritance_. I agree and saw the
danger right away and, thus, in the code I write try not to use inheritance
and so far have been fully successful.

But, I can think of situations where inheritance could be useful and keep the
work better organized than not using inheritance.

But, I'd say: The main issue is just having humans understand the code, and
for that, using inheritance or not, the main solution is just to document what
is going on.

Or, if the way around using inheritance is just having multiple copies of the
same source code, then just document this fact so that when want to change one
of the copies, likely change all the others, also. And, of course, generally
should know all the places in the _code base_ where that code, or some
modification of it, is being used. Can solve such an issue with just
documentation.

Or we don't want to look to programming language syntax and features to solve
all problems of _meaning_ in that software, meaning better communicated with
documentation.

Gee, so far this is a _polymorphic_ post since I didn't way what OOP language
I'm using! So, I'm writing in Microsoft's Visual Basic .NET with their .NET
Framework, ASP.NET (for Web pages), and ADO.NET (for using SQL Server). That
Microsoft software is awash in classes, and that _architecture_ seems to be
working well.

Yes, that Microsoft code is awash in inheritance, but mostly I just ignore
that fact and regard it as more just documentation than actual software. I get
by mostly ignoring inheritance because I don't use it directly in my code.

In my project, the hard technical work was the applied math; it turns out,
given the math, the corresponding code is simple.

------
visarga
OOP is still good for gaming and simulations in general.

------
nly
This old bag again.

------
edw519
I've always had a problem with object orientation and have never embraced it.

But none of these quotes (and most dev thinking) seems to share my reasoning.

My problem: almost every argument for or against object orientation is about
_us_ , the developers. I rarely hear any arguments that consider our users or
customers. Oh sure the usual (and lame), "It helps us serve them better."

I long ago lost track of all the lame bullshit (far too many to mention, but
you know the culprits) that was supposed to revolutionize the way we build
things without ever taking our users into consideration. Most of it was to
make developers who couldn't build what was really needed appear as if they
could. This has helped consulting firms and enterprise I.T. departments
justify their rates and schedules, but has added little to the customers'
benefit.

If the people who dream this shit up would stop focusing on what _we_ need for
5 minutes and consider what _they_ need, we'd all be way better off.

How has object orientation helped my customers? Frankly, I can't think of a
thing. Add that quote to this list.

~~~
thewarrior
I feel that OO imposes some semblance of structure using an intuitive
semantics most "average" developers can grok (Not crazy stuff like Monads) ,
thereby allowing Pointy Haired Bosses to treat devs as commodities to be
replaced at will.

Java is a language right at the sweet spot on that continuum. Just advanced
enough to prevent most stupid bugs but also mediocre enough that most devs can
grok it.

In the words of one of its creators :

"We managed to drag them half way to Lisp"

And how would you program an enterprise Java App without object orientation ?

~~~
codygman
> (Not crazy stuff like Monads)

Read this and tell me that "crazy stuff like Monads" is an accurate statement:

[http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...](http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf)

