This is second post in a series of three; if you haven’t read it, you may want to back and read part 1.
In the introduction to the previous post, I claimed that (along with “functional” and “systems”), “object oriented” was non-communicative in the context of programming languages.
I am now in the somewhat awkward position of having spent a bunch of time trying to articulate why this is in the case of “object oriented,” and having come to the conclusion that it isn’t – I take it back, “object oriented” is as coherent an idea as most anything borne of rough human intuition. It’s not a technically precise term, there are a few different interpretations capable of causing confusion, but that’s not particularly damning, as things go.
I have realized that the problem isn’t that the term is incoherent or otherwise non-communicative. The problem is that it represents a horribly muddled way of thinking about programming languages, so even when the meaning gets across perfectly, the conversation tends to land in the conceptual toilet anyway.
The problem notion is that of a “paradigm.” Roughly speaking, “object oriented” programming is this ball of ideas:
- Dynamic dispatch/late binding
- Open recursion
- Abstract data types
Unlike the imposing katamari that “functional” is becoming, I haven’t seen this ball grow much lately – OO isn’t the thing all the cool kids are doing anymore, and so I think its meaning has become less of a moving target. But you’re still left talking about a ball of features as if there was anything particularly fundamental about their combination, which there very much isn’t.
This is ultimately what a paradigm is – a particular combination of features. They tend to go together because they’re ideas that are popular in particular traditions or communities. “Functional” programming is a paradigm in the same way, and while I said last time that these days it seems to basically mean “like Haskell,” it seems better to describe it as the stuff a particular group of academics is doing.
For reference, here’s the ball of features that I put under the heading of “functional” last time:
- Immutable data structures
- Controlled side effects
- Static types
- Pattern matching
- Algebraic data types
- Type inference
Plus, of course, first class functions.
Just one example of something that the notion of paradigms will generally preclude from one’s thoughts: prototypes look a lot less dumb when you combine them with immutability. If you look around the net, you’ll find plenty of bloggers making a fuss about how “object oriented” and “functional” programming aren’t mutually exclusive, and they’re totally right. But the more interesting thing to me is that “object oriented” and “functional” programming aren’t terribly important concepts in the first place. I’ve given two lists of concepts above that are actually meaty and worth understanding. But their division is arbitrary and mostly a question of which communities they’re popular in.
It absolutely is relevant to study how these ideas interact. For example, the combination of parametric polymorphism (generics, for the Java folks in the room), subtyping, and type inference seems to largely be one of those “pick two” situations. But if we’re trying to think about the technology, we do ourselves a disservice by basing our thought process around paradigms.