Object-oriented oblivion

crypto.stanford.edu/~blynn/c/object.html

Object-oriented programming languages are a major misstep; a tortuous detour that

computer scientists should never have taken.

The limited one-size-fits-all philosophy of some object-oriented languages makes coding

cumbersome. I’m annoyed at myself because I was a crusader for the object-oriented
empire for years; I thought all data could be forced into an elegant hierarchy if I had
sufficient skill, and everybody not using objects was creating unnecessary disorder. One
only has to read about the circle-ellipse "problem" to see through this deception.

Besides the strait-jacket type system, my other big complaint is the second-class status of
functions. Have language designers learnt nothing from functional programming? Good
notation for functions and closures allows otherwise clumsy code to be expressed clearly
and concisely.

When I must use a object-oriented language, I shun inheritance, which even gets object
initialization wrong, and struggle to obtain the equivalent of simple C constructs such as
function pointers. Although I can work around most of the deficiencies, I feel like I’m fighting
bureaucracy and wrestling with red tape. Instead of conversing with the machine and fellow
programmers, I’m filling in forms the compiler gives me.

Hackery or quackery?
Programming is hard. Brian Kernighan said: “Controlling complexity is the essence of
computer programming.” This was probably known even before computers were invented.

I theorize that over-enthusiastic researchers spread a rumour that object-oriented design

would simplify programming around the 1980s. It must have been easy to believe, because
anyone would want a magic pill to soothe their complexity pains. They promised you could
clean up systems by reorganizing them into class hierarchies. If not, then you’re just looking
at the problem incorrectly: try shuffling around the classes. Or apply a cool design pattern
with a cool name.

Many were caught in the madness. Suddenly, printf("0x%08x\n", x) is less clear than:

std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl;

(from the C++ FQA). Functional programming is obsolete. In fact, functions are obsolete: at
most, you can have a class with a single method. Prolixity is praiseworthy. Beautiful gems
like this Haskell line to compute the Fibonacci numbers:
1/4
fib = (fibs !!) where fibs = 0 : scanl (+) 1 fibs

(from Wikipedia) are too hard to understand. Instead, students are taught:

public class Fibonacci {

public static long fib(int n) {
if (n <= 1) return n;
else return fib(n-1) + fib(n-2);
}
public static void main(String[] args) {
int N = Integer.parseInt(args[0]);
for (int i = 1; i <= N; i++)
System.out.println(i + ": " + fib(i));
}
}

New programming languages must be object-oriented, or at least pretend to be, in order to

be taken seriously. Even Guy Steele joined the dark side.

Some saw through the ruse:

Rob Pike observed “object-oriented design is the roman numerals of computing” and
C function pointers yield the same supposed benefits, except in a more flexible
manner.

Edsger Dijkstra joked that “object-oriented programming is an exceptionally bad idea

which could only have originated in California.” He also wrote an impassioned plea
urging his university to stay away from the temptation of teaching Java (or C++).

Linus Torvalds stuck to plain C, which “means that you get a lot of programmers that
do actually understand low-level issues and don’t screw things up with any idiotic
"object model" crap.”

Richard P. Gabriel explained why objects have failed.

though their admonitions mostly fell on deaf ears. The Wikipedia article on object-oriented
programming concludes with numerous similar quotes. See Object Oriented Programming
Oversold! for more. My favourite criticism from this comprehensive site is that proponents
claim OOP better fits the way people think, while simultaneously claiming it takes years of
study to develop proficiency. How can it take years of study to think naturally?

A return to normalcy
Ultimately, reality triumphed. Some programmers who were taught object-oriented
languages were best nevertheless spent most of their time in “fun” languages like Perl or
Python. After all, who enjoys the boilerplate and verbosity of Java?
2/4
As the ideology aged, it lost its novelty. I bet that many who invested heavily in objects failed
to see the promised returns, and are now skeptical. Conditions are at last ripe for an escape
from the Dark Ages. Perhaps it’s confirmation bias, but I see signs of Enlightenment
approaching.

New languages like Erlang and Go have become popular despite not being object-oriented.
Conversely, object-oriented languages are gaining features from functional programming.
Already in the late 1990s, Java 1.1 supported anonymous inline classes, which makes
functional programming almost bearable. Years later, Scala, with significant support for
functional programming was built on top of Java infrastructure. C++11 supports lambda
functions, and in 2014, even Java 8 finally added lambdas.

Google’s MapReduce framework has been battle-tested and acquired fame. Its name and
design was inspired by functional programming constructs: see "Why Functional
Programming Matters". This may encourage programmers to learn about them.

The tide may be turning in academia. Robert Dewar, a former computer science professor
at New York University laments the lower quality of degrees after they started emphasising
Java. More recently, Carnegie Mellon University eliminated object-oriented programming
from the introductory computer science curriculum, because it is intrinsically anti-modular
and anti-parallel.

Class struggle
Inheritance. In one word, we’ve summed up the trouble with object-oriented programming.
This cursed concept is responsible for everything from meaningless debates about is-a
versus has-a, to problems such as the inheritance anomaly.

Inheritance initially appears to ingeniously facilitate code reuse. With a single declaration,
we avoid duplicating a bunch of member and method definitions. However, it’s like lighting
a furnace to burn a hair. On closer examination, inheritance is copy-and-paste: blunt, crude,
and rarely desirable. How do we reuse code from more than one source? What if we only
want to reuse certain bits? Will my changes to a class wreck a subclass?

Abstract art
My misadventure with object-oriented programming was not entirely fruitless. I learned
about pure abstract base classes. Over time I saw how they dissolved away many problems
I encountered with inheritance.

In pure abstract classes we declare only the public methods, so we limit the damage that
inheritance can do, as it cannot duplicate any implementation details. In this context,
inheritance actually becomes useful.
3/4
So why not make pure abstract classes the only kind available? Java almost does: its
interfaces are pure abstract classes. Unfortunately, every class is allowed to sin once: you
get one free evil inheritance.

Other languages have succeeded, permitting one fewer inheritance per class than Java. For
example, pure abstract classes resemble Go interfaces and Haskell type classes, and in
these languages, there is no object-oriented-style inheritance.

Ben Lynn blynn@cs.stanford.edu

4/4