
Anthropomorphism Gone Wrong: OOP - StylifyYourBlog
http://loup-vaillant.fr/articles/anthropomorphism-and-oop
======
JamesBarney
"It is not simpler. Just organised in a more systematic way."

This is the kicker. In most large projects(100k-million+ loc) the largest
issue is complexity. Object oriented programming is just systematic way to
organize that complexity.

The OP says that "In production code, I would split it in several files as
appropriate. Or not. It doesn't really matter. What does matter is that we can
easily find those procedures whenever we want to inspect or modify them."

It 100% does matter, and having all procedures that operate on and change the
state of an object in the same file is super helpful. Being able to make
guarantees that certain state cannot be changes outside of the organization
unit of the class(encapsulation) is super helpful. Being able to abstract over
certain related but non identical functions without having to resort to switch
statements is super helpful.(polymorphism) And the ability to reuse code when
different pieces of data share some identical features and we want to abstract
over a portion of those features is useful(inheritance).

OOP doesn't give you any abilities you didn't have before, and you can write
great readable structured procedural code. But it does give you more tools in
your tool box that when used correctly can help structure your code in a way
that limits the burden of the software's complexity.

~~~
sago
> having all procedures that operate on and change the state of an object in
> the same file is super helpful.

How many OOP programs do you know that have achieved this? None that I know.
Perhaps utility libraries can get close, but no software actually solving
domain-specific problems. Objects don't live on their own, in a typical OOP
program there are bits of code all over the place that operate on your data
objects. Finding all the ways that a personel record is modified can be a
tricky problem. More so because the object is likely to be a bastardized
combination of personel data and software engineering level-of-abstraction
(see below).

> Being able to make guarantees that certain state cannot be changes outside
> of the organization unit of the class(encapsulation) is super helpful

Agreed, but woefully limited. The idea that a _class_ should be the unit of
encapsulation leads to all kinds of horrible programming idioms, leaked
abstractions and interface complexities. A better solution would be to erect
encapsulation barriers explicitly, rather than tying them to an unrelated
domain-modelling semantic.

> Being able to abstract over certain related but non identical functions
> without having to resort to switch statements is super
> helpful.(polymorphism)

Or just polymorphic dispatch, which if you're going that way, you can add
multiple dispatch and get much more power, security and expressivity.

> And the ability to reuse code when different pieces of data share some
> identical features and we want to abstract over a portion of those features
> is useful(inheritance).

Except that again, OOP encourages programmers to think of code reuse in terms
of an unrelated domain-concept, which leads to class design that is motivated
by functional needs, rather than domain needs. Which is again a bane of real
OOP systems.

> OOP doesn't give you any abilities you didn't have before, and you can write
> great readable structured procedural code.

Agreed. You can write OO procedural code. I've written quite a lot of OO C,
for example.

> But it does give you more tools in your tool box that when used correctly
> can help structure your code in a way that limits the burden of the
> software's complexity.

I'm skeptical that 'when used correctly' is anything but a no-true-scotsman
fallacy. In practice, the way OOP pushes together concerns of domain,
semantics and syntax seems to encourage code that lacks the kind of
encapsulation, reuse and separability that OOP-devotees claim is the _raison d
'etre_ of their paradigm.

I bought OOP in a big way through the 90s and into the early 2000s. I'm sorry
to say I think the emperor has very few clothes. The realities of the big
software systems you cite seem to be very different from the clean simple
benefits demonstrated on toy problems in CS classes.

Three issues I've hit time and time again, in the millions of lines of OOP
I've written and maintained: one is the expression problem, a second is the
fragile base class, and a third is the metaclass problem (where the domain
requires three levels of modelling, but the language provides two, or provides
metaclasses with semantics that 'break' the principles of OOP you mention).

~~~
ww520
> Objects don't live on their own, in a typical OOP program there are bits of
> code all over the place that operate on your data objects. Finding all the
> ways that a personel record is modified can be a tricky problem.

Searching for all the code that touch an Employee record class is much easier
than searching for all the code that touch a generic hashmap that supposes to
contain the employee data.

~~~
alloyed
This a property of static typing, not object oriented design. Take for example
Typed Clojure, where you could define an Employee as a hashmap with a set of
static constraints which can then be analyzed for, without having to invoke
any of its proper OO constructs.

------
steego
The biggest problem I see with this article is the author is comparing Simula
style OOP (Prevalent in C++, Java, C#, etc.) with procedural style programming
and concludes anthropomorphism is at fault.

When your objects act more like very lightweight processes ala Smalltalk or
Erlang model that communicate with each other via messaging, OOP becomes a lot
more than a "coat of syntax sugar over the procedural cake" and
anthropomorphism sudden works very well. If you see objects as data structures
with methods rather than isolated processes with message based interfaces
(think actor model), it's not all that surprising anthropomorphisms don't add
much value. However, when your conceptual model of objects implies each object
is a concurrent and isolated process, anthropomorphisms make sense. I
sometimes even give them names and imagine them as employees in an
organization. Asynchronous communications can be conceptualized as inboxes and
outboxes of messages and synchronous communications can be thought of one
employee getting into a queue himself to personally deliver the message.

Sometimes metaphors translate surprisingly when you become a stickler for
making sure all aspects of a metaphor are accounted.

~~~
rdtsc
According to Alan Kay:

[http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...](http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

\---

OOP to me means only messaging, local retention and protection and hiding of
state-process, and extreme late-binding of all things. It can be done in
Smalltalk and in LISP. There are possibly other systems in which this is
possible, but I'm not aware of them.

\---

I think over the years OO just ended up meaning "whatever C++, Java and C#"
implemented. But you are right, if you go back to its original design Erlang
is probably more OO than any of those languages. I believe this was Joe
Armstrong's tongue-in-cheek observation a while back as well.

~~~
pmahoney
Maybe concede the term OOP to Java, C++, et. al. and call message passing
among processes service-oriented programming or something.

~~~
steego
...and give up the opportunity to remind programmers their OOP is the inferior
OOP? :)

------
mc808
Like many people I went through an "objectify all the things!" phase, but now
I find myself moving more and more to stateless service layers, which ends up
looking like old-fashioned procedural code coated with a sugary OOP shell.

Encapsulation and inheritance and stateful objects have their place, but the
"object" metaphor can really lead down the wrong path when taken too literally
(as it is in practically every course that starts with "animal" or "shape" or
"car" examples).

~~~
haberman
Could not agree more.

I've heard of interviewers who say to candidates: "I have a bookshelf. Design
me an OO interface." They want the candidate to create objects for Shelf,
Book, etc. without knowing anything at all about what the software system is
supposed to do! This is so backwards IMO that I cringe just to tell this
story.

~~~
empthought
The intent of that type of question is to see what questions the candidate
asks in order to elucidate an appropriate design.

That being said, I can easily imagine it being misused by bad interviewers.

------
murbard2
Regarding Dijkstra's quote: our brains are wired to model people with internal
desires... sometimes it can lead to some errors, like animism, but if used
correctly, it can be a powerful technique.

I've designed concurrent systems with many processes talking to each other.
Each process has a name that describes a profession, owns certain parts of a
shared database and transacts with other processes.

Sure that analogy can break down in the limits, but thinking like this allows
me to get a much clearer mental picture of what's happening.

------
danbruc
One obvious problem with that comparison - it is a toy example.

It is really not about anthropomorphizing objects, it is about where the state
is kept and who can modify it how. And the right or at least the best choice
heavily depends on the problem you are modeling. If you are primarily tracking
the whereabouts of students it is probably a good choice that students keep
track of that information and provide an interface to update it. If you are
primarily interested in rooms and who is inside, it may be better to make the
rooms responsible and provide an interface like classroom.enter(student).

------
olavk
It is really hard to decide on the best way to model, since it doesn't
resemble any real-world programming problem.

But OO culture has an unfortunate tradition of using bad examples by using
physical objects as analogies for objects in code. Cars, fruits, students,
teachers, whatever. Problem is, objects in code rarely correspond to physical
objects. In the cases where physical objects are represented, it is most often
in the form of database entities, which are typically treated like data-
objects, which makes the discussion in the example moot.

~~~
adwn
You hit the nail on the head. Objects in OO shouldn't be a projection of the
problem domain, they're a way to structure the program (there's some overlap,
of course).

Many people seem to get this wrong, probably in part due to introductory
examples doing it wrong.

~~~
platz
I suppose you disagree with Eric Evans method of Domain Driven Design (DDD -
[http://domainlanguage.com/](http://domainlanguage.com/))

Don't people who practice DDD, including Martin Fowler, commonly talk about
the benefits of some of it's concepts, while modeling the Domain using
Aggregrate Roots, Bounded Contexts, etc?

~~~
huherto
Martin Folwer talks about several approaches for handling domain logic.
Transaction Script, Domain Model, Table Module, and Service Logic. He explains
the trade offs of each on the Patterns of Enterprise Application Architecture
book.

~~~
platz
Since then he has also written a lot more as well, for example
[http://martinfowler.com/tags/domain%20driven%20design.html](http://martinfowler.com/tags/domain%20driven%20design.html)
.

While less a direct connection, folks who use DDD a lot also find CQRS
(command query responsibility separation) a natural fit and are often seen
being used together.

~~~
huherto
Yeah, that makes sense. It simplifies both.

------
mrcwinn
I was disappointed by this article in the end. I was ready for a good old
fashioned OOP bash, supported by strong opinions and examples. We should
always remain open to new (or old, in this case!) patterns. Instead we get a
"tie" given a very simple (not real world) example.

In the end I'm left with the same conclusion. Given that there is no obvious
performance gain from a procedural approach, I would opt for a design pattern
that is friendlier to the programmer (the human being). It's helpful to model
things this way as an organizing approach. And there are obvious benefits to
maintaining state within their respective concerns.

It isn't to say OOP is the only and best answer. It very much depends on the
program, but I was hoping for a more obvious win on the procedural side here.

~~~
basaah
I was also disappointed by the atricle's end: Pretty much only the Dijksta
quote was worth reading. The title promised to backup the claim with a real-
world experience of OOP, but alas, it did not deliver such.

OOP is better where you code more readably(in comparison with procedural) and
where it makes you enjoy coding more. The conditions for when it does that
differ from persons to person and from project to project.

I personally like OOP because it helps me focus on different abstraction
levels at the same time, and it helps me stay in the flow.

~~~
Sirenos
I don't think procedural programming itself makes code unreadable. For
example, take a look at the redis source code. It's clean and approachable.

~~~
basaah
I do not find procedural code unreadable, nor is that what I meant to say.
Rather the contrary: I said that OOP is only better if the same problem solved
in OOP is more readable, which holds only true for a subset of problems.

Regarding the _redis source code_ : Beautiful, truly. I wish more code was
that clearly and extensively documented.

------
Zibulon
The author is missing maybe the following point: when there will be multiple
objects that need to move, and some of the move methods will require state,
then it will be nice to encapsulate the state within objects, rather than
having messy global state and methods that access a global state... which can
lead to coupling between methods, if not concurrency issues, and before you
know it, you end up with hard to understand, non-maintainable, non-
refactorable spaghetti code.

------
edderly
The article resonates with me.

I’ve spent quite a few years coaching and dealing with developers with a heavy
electronics background work in OO/C++ environments and I came to the
conclusion that they would be more comfortable and competent in C. All smart
people but the bells and whistles of C++ AND OOP just was confusing.

I’m surprised at some comments here claiming that OO is ‘friendlier to the
programmer’, I would put money on the average developer being able to work
their way around even the Linux kernel quicker than a comparably sized C++
code base with all it’s OO goodness.

What OOP was trying to solve back in the day was and still is a real problem
but it annoys me how many additional problems ‘full blown’ OOP introduces.

------
lobster_johnson
The article isn't wrong, per se, but it offers a terrible strawman example. It
is an example of OO done wrong, not a criticism of OO.

The example offers a flawed data model. Each student is in a classroom, but it
doesn't make sense to model the location as an attribute of the student --
unless it is actually a coordinate position. If it's a symbolic location (a
classroom), it is much more logical to treat the classroom as a container;
therefore it is the responsibility of the containers to move stuff around.

OO tends to make much more sense once you analyze where the encapsulation
should be.

------
ww520
Is this a joke or something? The arguments simply don't hold water. OOP will
make the program run faster? Was running faster than whatever is a promise of
OOP? Walking each student while the others wait in the main hall would take
forever? So we are talking about parallelism with the actor model. How would
procedural help that?

"[OOP] just organized in a more systematic way." Managing complexity and
abstraction is a main function of programming. How is having a simple,
consistent, systematic way to organize complexity not an advantage?

------
asveikau
Using the article's example, maybe if you break the abstraction of the
iterator, you realize that moving students to classrooms might just be a
single pointer assignment, which can be done in a few instructions. In other
words, maybe the classes blind you to the fact that the students don't need to
be iterated.

I feel like this is one of my bigger gripes with OOP code bases: overemphasis
on abstraction sometimes makes simple and efficient solutions harder to come
by.

------
gfour
This confuses OOP/procedural semantics with low-level "CPU" work. The argument
seems to be that the programming model of a language does not always expose
the efficiency of the underlying implementation. And this is also true for
"anthropomorphic" models.

------
nathanvanfleet
Not really a great example, really a straw man argument because the code is so
shallow. It's really about having relevant code in the relevant place. So yes
the student object could have that code placed in it's class. That would be
truly effective if you had, say, two kinds of students. Like one in a
wheelchair and one that can walk. They'd both implement the function to move
to the classroom, but internally one would walk() and the other would roll().
That's polymorphism. In the procedural case you'd have to check
if(student.inWheelChair == YES) and it would get complex.

------
ronbo
still i would like to see a concrete example where OOP is better. I thought
that OOP had advantages in larger projects with many kinds of data where it
helped organize the code to make it more readable and editable. At that point
you need to be careful how you use it to make it manageable. Not sure how
small an example would could be before it started to show some benefits.

~~~
alkonaut
The encapsulation that guarantees invariants is the greatest benefit. This can
be Done in another way by immutable structures and Functional programming.
This way is in many ways better than OO but _both_ are vastly superior to
having publicly mutable structures modified by procedures.

Semantic organization where methods are defined near the data (the recepie is
on the flour package) is a benefit for sure, but it's just a preference.

------
moron4hire
Bad programmers write bad programs. It's not methodology. Good programmers
have successfully written a lot of software in an OO design. That doesn't mean
OO is the best solution for _you_ , it just means that you can't judge a book
by its cover, and in this industry, we're covered in bad programmers.

~~~
olavk
Disagree! If a programmer is good or bad is not a quality separate from how
they actually develop programs! A good programmer is good because they choose
appropriate tools and methodology etc.

~~~
moron4hire
That is not at the granularity of "OO vs. FP". Again, plenty of people have
very successfully built projects with the OO methodology. That doesn't mean
you have to. That doesn't mean it's what is best for you. But articles like
this ignore fundamental, empirical proof: OO has worked. There will be
hundreds, maybe thousands, of projects started this year in an OO methodology,
and they will live or die not because the developers chose OO, but because of
generally more basic issues of competency.

I interview developers for positions all the time. Out of every 10 I
interview, one can't write a basic "Hello, world" program that actually
compiles, in the languages they list in their resume, on their own computers.
About 7 or 8 more can't even close a database connection or file handle
correctly. I can go a year and meet one, maybe two developers I would trust to
write code in _any_ methodology, in _any_ programming language. And they
usually have jobs they like and don't want to leave.

Projects don't fail because someone chose OO. They fail because most people
claiming to be developers suck.

~~~
w0utert
Very much agreed, the point you're making is exactly why I hate languages that
try to hide the fact that programming is difficult, to make the life of the
developer easy. This almost inevitably encourages bad programming practices,
and does not do anything to improve code quality produced by incapable
developers. It's why I dislike Java so much and prefer C++, even though both
have their strong and weak points, and both can be used to create great
software.

That said, I've stopped taking 'OO is bad' articles seriously long ago. Over
15 years of professional software development have sufficiently proven for me
that there are many problems that fit the OO model perfectly, and would not
benefit in any way from switching paradigms. Just like some (but decidedly
less) other problems are a perfect fit for functional programming or
procedural programming. There is no silver bullet in programming, what works
best is entirely dictated by the problem, and problems come in infinite
varieties.

------
imsofuture
Completely disagree with the Dijkstra quote. Mentally modelling command flow
as a 'person' makes total sense, as long as you keep in mind the
abilities/limitations of the 'person' you're talking about.

That said, I agree that OOP is anthropomorphism gone crazy.

------
stelund
I think the procedural option is better. It is just so much less code.

~~~
vinceguidry
It does until it doesn't. Let's say you only want to move the bad students to
the principal. Then you want to model pop quizzes. Students who score 1/5 on
three or more per month go to the principal. Or call their parents, whatever.

After a while you realize that you're doing all this stuff to 'bad' students.
This is where you really start to want some way to organize all the stuff
you're doing to these bad students, as all the code you have dealing with them
is sprinkled liberally through the codebase in conditionals in your
procedures.

You'll start pulling out logic and things will start breaking. What you
thought was less code is just crazy to manage.

The Gilded Rose kata illustrates the dangers of procedural code excellently.

[http://craftsmanship.sv.cmu.edu/exercises/gilded-rose-
kata](http://craftsmanship.sv.cmu.edu/exercises/gilded-rose-kata)

Sandi Metz has an excellent discussion on using OOP to improve the design of a
codebase.

[http://www.confreaks.com/videos/3358-railsconf-all-the-
littl...](http://www.confreaks.com/videos/3358-railsconf-all-the-little-
things)

------
programminggeek
I find myself not wanting to use or focus on objects at all. I am more
interested in message passing and protocols. Seem like a big blind spot.

------
amelius
This part of the article really says it all:

> There is just one little snag… The limits of analogies …When pushed too far,
> analogies break down.

