General purpose, in my view, is an overstatement.

OO is appropriate when the least complicated way of modelling a problem is in terms of agents with internal states communicating. In other…

General purpose, in my view, is an overstatement. (That said, maybe I work with an atypical set of problems.)

OO is appropriate when the least complicated way of modelling a problem is in terms of agents with internal states communicating. In other words, something like a physics engine is a natural fit for OO.

I mostly work with processing large amounts of text data between formats, occasionally doing analysis. (This is, as far as I can tell, a pretty typical programming job.) This kind of work lends itself well to multiple parallel stages with relatively little state, much of which is short-lived. In other words, it fits well with the UNIX pipeline model, and both OO and FP would be a poor fit. (I’ve had to work with other people’s attempts to shoehorn this kind of process into an OO framework; when I can get away with it, I replace a few thousand lines of Java with two or three lines of shell.) In other words, this is the ‘general case’ for my line of work.

I occasionally come across a circumstance where OO makes sense. I wrote an OS in D, and because D’s object system is similar to C’s structs and unlike C++’s objects, I was able to make excellent use of inheritance & polymorphism for wrapping abstraction around memory-mapped devices like VGA memory; I also made heavy use of object orientation when modeling some novel data structures for Project Xanadu. However, in none of these cases was it convenient or sensible to go full-OO — all of these cases were ‘mixed paradigm’ with a lot of procedural and functional code, and even when I wrote OO, I violated encapsulation whenever I needed to & barely took advantage of inheritance.

I understand why pedagogy around OO is so popular. After all, human beings deal with objects with internal state in real life all the time, so these concepts are familiar to non-programmers. Likewise, inheritance hierarchies mimic the form that every naive cataloguer produces. But, like John Wilkins in his Essay Towards a Real Character and the imaginary Chinese philosopher in Borges’ Celestial Emporium, we quickly find that reality doesn’t neatly conform to either a hierarchy of relation or a conception of objects with attributes.

In other words, OO is a convenient stepping stone to other paradigms, and is useful in of itself when a mapping of the problem space to a set of objects is either immediately obvious or (in the case of physics engines) provided in the literature, but its most useful attribute is the way in which it demonstrates its own limits. Despite this, because most formally trained software engineers have only ever had serious experience with so-called OO languages & with material that promotes OO to the exclusion of other paradigms, there is the (false, but widespread) belief that the problems introduced by trying to shoehorn the wrong problems into OO are problems of programming in general and are irreducible. The idea that there is such a thing as a general purpose programming paradigm that is ‘good enough’ for anything, while convenient for casual developers who would like to avoid learning more than the basics of a single language, supports this essentially artificial set of problems.

The current boom in interest in functional programming is hardly unexpected: you teach people that the one true paradigm is a bastard mix of OO and procedural programming for twenty years and that it’s the end of history, and as soon as they are exposed to an alternative they’ll jump all over it: most problems introduced by OO are artifacts of OO and dissolve as soon as you break out of it, but FP has similar artifacts.

Poor CS pedagogy is a bit of a hobby horse for me. OO is as it is, and I don’t have anything against it as such, but the idea that OO is generally applicable (or, more generally applicable than some other given paradigm) is getting in the way of professors and authors realizing that all serious developers need to have a full toolbox. The current miserable state of the development world is a result of every developer having a pair of vice grips & nothing else — and while you can solve pretty much any problem after a fashion with a pair of vice grips and a few hours of fiddling, you end up with a lot of mangled screws and bloodied fingernails.

By John Ohno on July 25, 2016.

[Canonical link](https://medium.com/@enkiv2/general-purpose-in-my-view-is-an- overstatement-422d7a8d58e1)

Exported from Medium on September 18, 2020.