

Is the supremacy of object oriented programming coming to a close? - codeodor
http://blog.objectmentor.com/articles/2009/04/20/is-the-supremacy-of-object-oriented-programming-over

======
jimbokun
"The ceremony of object wrappers doesn’t carry its weight."

This nails it. I find so much of my programming now is shoving data into
objects, only to almost immediately pull it out again into JSON, XML, HTML
templates, or relational databases (in both directions). Most of the code in
these "objects" are just getters, setters and member declarations, with very
little in the way of actual logic. There is little point in having objects at
all for this kind of programming, as opposed to a map, struct, or type class
of some sort.

~~~
modoc
If you're just working by yourself, then by all means use whatever you want.
If you're working on a multi-developer team, or someone else might have to
work on or try to fix your code later, please use structured objects, not
Maps.

The point of having named and typed member variables is that I actually know
what's in there. I know that a User object has a displayName property, so I
can use that. I know that the address property is actually a List of Address
objects, not a string, and not a Map. And I can know this instantly using my
IDE's auto-complete and tool-tips. It's also exposed via Javadoc, which means
if your front-end team is writing the JSPs, they can just look at the Javadoc
to know what they have access to, without bugging me every 10 seconds.

Not only do I know, but the compiler knows, and can let me know if I'm trying
to access something that doesn't exist, or I typo'ed the name, or if I'm
trying to treat a String like a Date.

If you're using a good IDE, creating the members and even getters and setters
shouldn't take you much time at all, and will be well worth it in
maintainability, compile-time checking, debugging, extensibility, etc...

~~~
jimbokun
"If you're using a good IDE, creating the members and even getters and setters
shouldn't take you much time at all"

I don't totally disagree with what you say, but having your IDE auto-generate
lots of code automatically for you gives me the heebie-jeebies.

The problem is that with a language as verbose as Java, you quickly have a
bajillion files filled with far more characters than it should take just to
define some property names and their types. Especially considering how having
a public field in an object is a Java Mortal Sin.

I could go on, but Yegge has summed up the problems with generating mountains
of code with an IDE, that then requires an IDE to move around, here:

<http://steve-yegge.blogspot.com/2007_12_01_archive.html>

------
jballanc
I largely agree with the author, but I think the reason for the "failure" of
the object oriented model has more to do with the promises it made. Object
Oriented Programing was supposed to make programming more understandable to
the average human brain. In this respect, it's largely failed.

If functional programming is thriving, I feel that it's only because FP has
been more honest with its goals, and has done a better job achieving them. FP
is _supposed_ to be mathematical in nature. It's uncomfortable to learn, but
once you do, FP languages, for the most part, live up to their billing.

What is really needed is a new paradigm that is what OOP was supposed to be:
programming that matches the patterns of human thought. In this respect, I
think the author's suggestion of OOP-style modularization with FP-style
pattern matching and function mapping is the future of programming.

~~~
allertonm
While I'll concede that OOP is not the be-all-and-end-all of programming
paradigms, I have a hard time thinking of it as a failure.

It seems to me that since the advent of OOP hitting the mainstream, the world
has seen more and better software than ever before, written by more people. So
in what way is this a failure?

------
j_baker
I don't think OOP is at an end. In fact, I think newer functional languages
are giving it new life (and giving us alternative ways to use OOP). Consider
clojure. It's fully object-oriented, but not in the traditional way (although
you can still use Java objects).

------
geebee
Object oriented programming has been a success, it's just not where people are
looking for answers any more. The lifecycle for modestly successful
technologies often goes like:

nobody understands it -> everybody scrambles to use it -> people start to get
some benefit from it -> people overuse it -> people hate it and say it's dead
-> people retreat to where it makes sense.

Objects are as dead as methods or loops. They're not super interesting
anymore, they're just fixtures.

I agree that functional programming (while hardly new) will probably start to
gain traction, similar to the cycle above. I think FP will also be a
successful technology, eventually becoming a fixture in mainstream languages.

------
phugoid
You mean that real programmers have coded an Account class with a Withdraw
method and a Balance property, like in OO for Dummies? Sure glad I'm not a
real programmer then.

I wrote my first object oriented program a few years ago, and it seemed
obvious that database fields would keep getting added, deleted and changed. My
goal was to isolate this stuff from the rest of my program, not try to
hardcode it everywhere.

I got a bit lost in all the buzzwords, but if that what his point, I agree.

------
extension
Objects as a language feature aren't going anywhere, nor should they. Like
functions, they are simple, fundamental, versatile and work well with nearly
every other language feature.

Object Oriented Programming, as an all-encompassing paradigm that will solve
all your problems if you faithfully and blindly devote yourself to applying
it, and only it, anywhere and everywhere that you possibly can, is dying.

Hopefully, the notion that such a paradigm can ever exist will die with it.

~~~
stcredzero
"X Uber Alles" Meta-Notion Considered Harmful!

(Also "X Considered Harmful" Considered Harmful!)

------
neilo
FP plus lighter and more dynamic objects doesn't sound like the end of OOP
supremacy, but rather another stage of it. I'm curious to see where it leads /
what comes out of it.

~~~
MoeDrippins
Also curious. Horizontal scaling, distribution, concurrency; that's where I
see the tech heading. I think whatever will make those easier to deal with
will have a huge advantage going forward.

------
octane
The worst thing in the world is working with code written by an inexperienced
programmer who thinks he has to use OO _everywhere_ for _everything_.

Same goes for table normalization.

One of the greatest things about experience is that you know when you should
use the "proper" way of doing things and when you should make things work
faster/better/more directly.

~~~
stcredzero
Funny that. If you use OO for everything in Smalltalk, often it's pretty. If
you use OO for everything in, say, Perl 5, it feels quite cumbersome to me.
(Ever meet one of those guys who uses one instance of polymorphism in their
whole project and talks as if they've mastered OO?)

Look inside the Smalltalk image sometime. There is a clear attempt at OO
_everywhere_ for _everything_ and it feels natural and unforced. (Well, it's
about 70%, to be completely accurate, because there's also some functional and
some OO newbie code in there.)

"proper" is all about cost/benefit tradeoffs, and it's very context-dependent.
Expressing things polymorphically in an environment like Smalltalk, Python, or
Ruby has low coding overhead.

Sometimes, it is just better to crank out an old-fashioned procedural routine
and be done with it.

One of the key tradeoffs: Am I trapped, or will I be able to change my mind?
So long as you can keep yourself from getting trapped, you're mostly safe.

------
banned_man
The answer to this question depends on how you define OOP and FP. I think the
answer is "sort of".

The problem with OOP is that it encourages the proliferation of mutable state.
If each object has mutable state, then a large object-oriented program has
distributed mutable state, potentially in hundreds of different silos.
Problems like concurrency become impossible to reason about.

FP encourages the careful sequestration of mutable state. It's false to say
that FP outlaws it entirely, since it's hard to do anything useful without
side effects. However, functional style limits and sequesters mutable state to
such a degree that it's usually easy to reason about what side effects are
happening.

~~~
jerf
"The problem with OOP is that it encourages the proliferation of mutable
state."

It should be pointed out that this is a characteristic of the languages and
not actually OOP. The original insight, something like "Hey, let's bundle
together data structures and their methods into one unit, and communicate with
them via messages!" (which got turned into "method calls") actually has
nothing to say about mutability. You can and people have build object systems
based on immutable objects.

The implications of doing that are deep and profound and color the rest of the
system and are beyond the scope of this posting, but it can be done.

~~~
banned_man
This is a great point. Given how I tend to get annoyed when people reflexively
associate static typing with Java, I shouldn't be so quick to make the leap
from OOP to mutable state. Many OOP concents (e.g. inheritance) are
mutability-agnostic.

