
Object Oriented Programming Oversold (2001) - blowski
http://web.archive.org/web/20010310074457/http://www.geocities.com/tablizer/oopbad.htm
======
svdree
I like the "split ends" analogy. A lot of developers seem to worry too much
about issues that aren't actual problems, other than that something is "not
OO".

An actual example of this I saw recently, was when I got into an argument with
someone over the use of standalone functions in C++. Apparently, these are
evil, and functions should always be part of a class.

Of course, a class with only static functions is basically a namespace. No
problem, apparently statics are also evil. So let's not make these functions
static, even though they're not accessing any member data.

But now, when we want to use these functions, we need to instantiate an
object, which is a bit silly. No problem, we'll just make it a singleton.

I shit you not, this actually happened.

~~~
spion
My theory is that we focus too much on the final points of "best practice
advice" and very little on the reasoning behind it.

As programmers, we need to start demanding that logical explanations always
accompany best practices or dismiss them as bullshit.

~~~
tmuir
I tried this for over two years at a job, which inevitably resulted in "well,
John has 25 years of experience, and you have 5".

~~~
spion
You might be able to reframe it as a "why" question. Then you're no longer
questioning the experience, but the ability to impart that knowledge to
others.

~~~
arethuza
When someone quotes something as a "best practice" I usually take it that they
aren't actually interested in the "why" and probably have no idea of what the
underlying justification is.

~~~
dalore
What's wrong with quoting best practice and pointing the why in your framework
of choice documentation that explains the best practice and the why?

------
shabbyrobe
The section on "Cult Oriented Programming" is also still very relevant today.
You could substitute "Smalltalk" for "React" and it still mostly makes sense.

> ...a programmer's personal preference is more important to getting results
> than the language or paradigm itself. In other-words, if a programmer can
> work with the tools and languages that he or she most prefers, then
> productivity and quality may be much higher than from passing down edicts
> based on a blanket choice of tool, language, or paradigm.

This backs up a lot of what I've seen over the years and I consider it
wasteful in the extreme. Maintainable, functional applications are constantly
thrown out because programmers don't want to use things they consider "dirty".
"Eww, I don't want to go anywhere _near_ that. It's (procedural|PHP|got 'goto'
statements|VBA|not the cool thing that everyone's talking about)."

Yeah, but this thing works just fine as it is. Your job is to improve it
without making it worse for the next person, not Reactify it until you've
exhausted somebody else's supply of money on a hunt for unicorns.

~~~
jacquesm
Funny you should write that. One company I looked at was on their _fourth_
rewrite of the system powering their main revenue stream. Every rewrite (by
the usual suspects, proponents of some technology with a good babble but less
than stellar tech chops) led to a reduction of that income stream, users
leaving and so on.

My first piece of advice was to ditch the current system and revert to the
old. This had been _purposefully_ sabotaged by the suppliers of the new
system. The only way out was then to go forward and this nearly killed the
company.

~~~
arethuza
A previous employer had an application that was very successful (from a
business perspective) because it _wasn 't_ flexible - they did a lot of
acquisitions (one a month at one stage) and if there were any questions around
their internal systems they got this application inflicted on them. At first I
was horrified (it was ancient, user hostile, completely inflexible) but I
actually saw that it worked - the companies being acquired were all in the
same industry and their core processes were all pretty much identical (even if
the terminology was all different) - so they could all adapt to the new
application and it actually ended up working pretty well.

More "modern" flexible applications ended up having multi-month/multi-year
"implementation" phases as teams tried to change their new application to
their existing processes when it was actually easier to standardise the
processes around a fixed application.

~~~
jacquesm
Airline companies typically have ancient stuff running but from a productivity
point of view that old stuff beats the 'new' stuff hands down. It just works,
has 0 overhead in terms of eye candy and so on. Ok, you can't play minecraft
or solitaire on those machines but that's probably a benefit.

~~~
mipmap04
Also, on those old systems running IBM RPG and other "green-screen" UIs, it's
really impressive how fast users can navigate the system via keyboard commands
when they are forced to not have a mouse.

~~~
acveilleux
I remember working in a bank in late 90s and while GUI apps were starting to
replace the 3270s, completely non-technical "lifers" had just fully
assimilated the old mainframe app.

Getting an account balance for example was a "Question 8" if I remember right,
that is, the PF8 key on the keyboard. Routine banking operations were maybe a
couple dozen keystrokes and mostly all the same pattern but different function
key with paper overlays taped to keyboards to "name" the PF keys.

It wasn't pretty and the learning slope was steep but the same people who
wrote their emails in Lotus Notes in All Caps and scanned word doc printouts
into new word docs had no problem memorizing all the obscure operations they
had to do every day.

~~~
jacquesm
One person I knew had a particular system down so well that they could fill
the type-ahead buffer for several screens ahead of the mainframes response,
the screens flashed by too fast to read.

------
exDM69
Random quote from the article:

> I will eat a week's pay if OOP is still in vogue in 2015.

So, is it time to make the OP eat a week's pay or not? I'd say no.

~~~
w0utert
I'd say yes. Even though I agree with many of the points the article makes,
OOP is still very pervasive, and I'm pretty sure it's still by far the most
used development paradigm for most types of software. OOP may not be ideal or
perfect, but OOP languages can be used to shoehorn almost any kind of problem
into, which is exactly what people are still doing today. Often times
producing a terrible mess that hardly works, but that's besides the point for
his challenge ;-)

Anyway, he makes many valid points, like other articles about the
disadvantages of OOP, but none of these every draws any convincing conclusions
why OOP is 'bad' and why something else would be 'better'. In programming
there is no paradigm that fits every application, OOP is just one of many ways
to solve problems, and one that has proven that (if used pragmatically) works
very well for a very broad range of problems.

~~~
exDM69
Yes, I'm going to have to agree with this. OOP is just one paradigm.

But what has changed from the years this article was written is that OOP is
not touted a panacea. Back when I learned to code, OOP was a synonym for
"good".

That's why I'm saying no. OOP is no longer the hyped as it once was.

------
petke
Thankfully the pendulum has swung back since the 90s.

Stepanov, the inventor of STL (The C++ Standard Template Library) was the
pioneer in avoidance of OO. It was truly revolutionary, and had such a huge
influence on library design that today most modern C++ libraries are designed
the same way.

"STL is not object oriented. I think that object orientedness is [...] a hoax.
I have yet to see an interesting piece of code that comes from these OO
people. [...] I find OOP technically unsound. [...] I find OOP philosophically
unsound. "

[http://www.stlport.org/resources/StepanovUSA.html](http://www.stlport.org/resources/StepanovUSA.html)

------
pcunite
I paraphrased one of his statements under the "Split Ends" heading:
_Advertisers take a small or imagined problem and magnify them to the point of
irrational paranoia._

Well said. And that is what is happening today in many forms. I'm under the
impression that hiring managers (kids in their 30's) are totally irrational
about skillsets because others don't know _exactly_ what they think they
should. There is paranoia about making a wrong hire to such a degree that they
will most likely make the wrong hire!

 _What you stare at, you steer for_ \- Bob Goodnough

------
kabdib
I like to tell people about the UCO or "Unencapsulated Composite Operation".
It tends to win arguments over "global functions are evil".

Say you have two classes, A and B. You have an operation that uses _both_ of
them. You can declare A::func(B) or B::func(A) but this couples the classes
together. Yuckko.

So you just make a global function, func(A, B). The function gets its job done
using public methods, and the classes remain unaware of each other.

That's the foot in the door. Then you whip multidispatch and CLOS on 'em and
watch their eyes get real wide :-)

~~~
lackbeard
Isn't coupling both A and B to the global func(A, B) just as bad as coupling B
to A in A::func(B) or A to B B::func(A)?

The thing you're trying to avoid with coupling is that when the dependency
changes you might have to change the thing that depends on it, right? Isn't
global func going to change with the same likelihood as A::func or B::func?

I'm not sure if this is a relevant or not, (but since it relates to your
post,) I do often find myself wishing I had multiple dispatch and/or some way
to extend interfaces to existing types when programming in a language without
those features.

~~~
kabdib
Not the same; you can use A independent of B, they are not coupled and you
don't even need them both in the product. You're free to change the global
func independent of the classes.

------
krylon
I like OOP, basically. But as with all things in life, if one takes it too
far, it quickly stops being fun.

To think that a) all problems can and should be solved via OOP and that b) it
is superior to other techniques (as if it was a competition or a fight) is
foolish. To think that some program, that is designed in an object-oriented
way, is inherently better than some other program that isn't, is - to a degree
- like saying some athlete is better than another one because one wears yellow
shoes and the other wears green shoes.

------
hacker_9
How is this article front page HN news??

The GUI Link

People think of gui elements as seperate objects (scrollbar, list, tree,
textbox etc), so why is it a bad thing that the software also reasons about
them as objects? Author just seems to want to hate OOP but offers no
alternative: _" There is more proof to the existence of UFO's than to OOP
being the best way to do GUI's or any other programming topic."_ ???

Bait-and-Switch

Author says here that training examples lure people into this idea of a
perfect world that can be modeled easily with separate objects, but in real
life projects this is not the case. But how is this any different from any
language / paradigm we have today? Angular is often berated for example for
being easy to get going with, but a PITA once the project becomes too big.
It's a good thing examples introduce you to the strengths of the language, and
then later you try to to fit the problem to those strengths.

Land of Confusion

 _" It has almost become like Particle Physics, in which only a small elite
group appears to understand it properly, and everybody else needs years of
meditation and practice."_ This is silly. Everything has a learning curve, but
once you understand that everything exists inside an object you are good to
go. The rest is just design patterns that are proven to make your life easier!

Not Table-Friendly

 _" OOP often does not map well to relational databases"_

Entity Framework for C# is used by businesses all over and shows this is
possible, and easy to do. There are many other solutions to this as well.

Melding Can Be Hazardous

 _" How many times do different programming languages and systems have to
share data? Very often in the real world. Thus, it is usually safer to keep
large data pools separate from methods"_

What?? This makes no sense. If you need to share your data structures, then
serialize your data to a text format and document it, for the next program to
read. You could even provide an API.

IDE support

Well I've stopped reading by this point, but the author doesn't mention any
advantages gained in the IDE. Specifically by using objects, the computer has
more understanding of what I am doing, and can provide me: contextual
autocomplete of members, and contextual documentation. Both invaluable for
quickly getting up to speed with a new API, and making programming _fun_.

~~~
fsloth
"This is silly. Everything has a learning curve, but once you understand that
everything exists inside an object you are good to go. The rest is just design
patterns that are proven to make your life easier!"

Maybe it's just me but this is my main gripe with OO. I sometimes need to
write involved data processing tasks and it's much simpler if I first think in
graphs or through a relational model. The objects are light and either a way
to encapsulate state (as in parser), a simple structure (as in a vector xyz)
or a container.

Complex data lives in relationships between the data - as opposed to
'encapsulating into an object' \- this keeps the system small, easy to
understand and modify.

Sure, objects are a nice way to offer an interface to something but I've found
the statement 'objects all the way down' usually means poor design.

This gripe is of course mainly pedagogical - students (like I was, once) are
exposed to a subotimal abstraction of software composition when objects are
introduced as _the way_ to design and implement software.

Sure, they are nice in some places, I don't deny that.

------
mitsoz
The article is pretty bad.

~~~
GalacticDomin8r
Remember, you can only say nice things on HN. Blind agreement is ok, blind
disagreement isn't.

