Abstruse nomenclature by Mark Seemann
Some thoughts on programming terminology.
Functional programming has a reputation for abstruse nomenclature:
I've already discussed when x, y, and z are great variable names, and I don't intend to say more about that sort of naming here. (And to be clear, zygohistomorphic prepromorphisms are a joke.)"Functional programmer: (noun) One who names variables "x", names functions "f", and names code patterns "zygohistomorphic prepromorphism""
What I would like to talk about is the contrast to the impenetrable jargon of functional programming: the crystal-clear vocabulary of object-oriented design. Particularly, I'd like to talk about polymorphism.
Etymology #
As Wikipedia puts it (retrieved 2021-06-04), polymorphism is the provision of a single interface to entities of different types. This doesn't quite fit with the actual meaning of the word, though.
The word polymorphism is derived from Greek. Poly means many, and morphism stems from μορφή (morphḗ), which means shape. Putting all of this together, polymorphism means many-shape.
How does that fit with the idea of having a single interface? Not very well, I think.
A matter of perspective? #
I suppose that if you view the idea of object-oriented polymorphism from the implementer's perspective, talking about many shapes makes marginal sense. Consider, for example, two classes from a recent article. Imagine, for example, that we replace every character in the Advantage
code with an x
:
xxxxxx xxxxxx xxxxxxxxx x xxxxxx x xxxxxx xxxxxxxxxxxxxxxx xxxxxxx x xxxxxx x xxxxxxx x xxxxxx xxxxxx xxxxxx x xxxx xxxx x xxxxxx xxxx xxxxxxxxxxxxx xxxxxxx xxxx xxxxx x xx xxxxxxx xx xxxxxxx xxxxxxxxxx x xxx xxxxxxxxxxxxxxxxxxxxxx xxxx xxxxxxxxxx x xxxxxxxxxxxxxxx x x
This trick of replacing all characters with x
to see the shape of code is one I picked up from Kevlin Henney. Try to do the same with the Deuce
struct from the same article:
xxxxxx xxxxxx xxxxx x xxxxxx x xxxxxx xxxxxxxx xxxxxx xxxxxx xxxxxxxx x xxx xxxxxxxx xxxxxx xxxx xxxxxxxxxxxxx xxxxxxx xxxx xxxxx x xxxxxxxxxx x xxx xxxxxxxxxxxxxxxxxx x x
Clearly, these two classes have different shapes.
You could argue that all classes have different shapes, but what unites Advantage
with Deuce
(and three other classes) is that they implement a common interface called IScore
. In a sense you can view an IScore
object as an object that can have multiple shapes; i.e. a polymorphism.
While there's some soundness to this view, as terminology goes, the most important part is only implicitly understood. Yes, all objects have different shapes (poly-morphic), but in order to be a polymorphism, they must present as one.
In practice, most of us understand what the other means if one of us says polymorphism, but this is only because we've learned what the word means in the context of object-oriented programming. It's not because the word itself is particularly communicative, even if you pick up the Greek roots.
Common interface #
The above outline doesn't present how I usually think about polymorphism. I've deliberately tried to steelman it.
When I think of polymorphism, I usually focus on what two or more classes may have in common. Instead of replacing every character with an x
, try instead to reduce the Advantage
and Deuce
structs to their public interfaces. First, Advantage
:
public struct Advantage : IScore { public Advantage(Player player) public Player Player { get; } public void BallTo(Player winner, Game game) }
Now do the same with Deuce
:
public struct Deuce : IScore { public readonly static IScore Instance public void BallTo(Player winner, Game game) }
These two APIs are clearly different, yet they have something in common: the BallTo
method. In fact, you can draw a Venn diagram of the public members of all five IScore
classes:
Incidentally, three of the five classes (Forty
, Advantage
, and CompletedGame
) also share a Player
property, but all five share the BallTo
method. Singling out that method yields the IScore
interface:
public interface IScore { void BallTo(Player winner, Game game); }
Such a (statically-typed) common API is what I usually think of when I think of polymorphism. It's the shape that all five classes have in common. When viewed through the lens of the IScore
interface, all five classes have the same form!
The term polymorphism (many shapes) makes little sense in this light. Really, it ought to have been called isomorphism (equal shape), but unfortunately, that word already means something else.
Sometimes, when you discover that the Greek word for a term is already taken, you can use Latin instead. Let's see, what would one shape be in Latin? Uniform? Yeah, that's also taken.
Okay, I'm cheating by deliberately picking words that are already taken. Perhaps a better option might be idiomorphism, from Greek, ἴδιος (idios, “own, personal, distinct”).
Opacity #
The point of all of this really isn't to harp on polymorphism in particular. This term is well understood in our industry, so there's no pragmatic reason to change it.
Rather, I wish to point out the following:
- Object-oriented design also includes Greek terms
- Even if you can decipher a Greek term, the name may not be helpful
- In fact, the name may be outright misleading
This is true also in programming. Without a context, polymorphism can mean many things. In biology, for example, it means the occurrence of two or more clearly different forms within a species, for example light and black jaguars (the animal, not the car - another example that a word belongs in a context).
This type of polymorphism in biology reminds me more of role interfaces, where a single class can implement several interfaces, but perhaps that's just me.
Ultimately, industry terminology is opaque until you learn it. Some words may be easier to learn than others, but looks can be deceiving. Inheritance may sound straightforward, but in object-oriented design, inheritance doesn't entail the death of someone else. Additionally, in programming languages with single inheritance, descendants can only inherit once. As a metaphor, inheritance is mediocre at best.
Another friendly-sounding piece of terminology is encapsulation - despite the fact that it's essentially Latin, just warped by two millennia of slight linguistic drift. Even so, this most fundamental concept of object-oriented design is also the most misunderstood. The word itself doesn't much help communicating the concept.
Finally, I wish to remind my English-speaking readers that not all programmers have English as their native language. For many programmers, words like class, object, or encapsulation may be words that they only know via programming. These could be words that have no prior, intrinsic meaning to a speaker of Hungarian or Japanese.
Functional programming terminology #
Is functional programming terminology harder than object-oriented jargon? I don't think so.
A nice little word like monoid, for example, is Greek for one-like. Again, it's not self-explanatory, but once the concept of a monoid is explained, it makes sense: it's an abstraction that enables you to treat many things as though they are a single thing (with possible loss of fidelity, though). As names go, I find this more accurate than polymorphism.
Granted, there's more Greek in functional programming than in object-oriented design, but (Latin) English is still present: recursion, fold, and traversal are common terms.
And then there's the occasional nonsense word, like functor. Despite some of digging, I've only managed to learn that functor is a compaction of function and factor - that is, a function factor, but what does that tell you?
In many ways, I prefer nonsense words like functor, because at least, they aren't misleading. When you learn that word, you have no preconception that you think you already know what it means. Michael Feathers is experimenting with a similar idea, but in another context, inventing words like exot, lavin, endot, parzo, duon, and tojon.
Conclusion #
It's easy to dismiss the alien as incomprehensible. This often happens in programming. New ideas are dismissed as non-idiomatic. Alternative paradigms like functional programming are rejected because some words aren't immediately forthcoming.
This, to me, says more about the person spurning new knowledge than it says about the ideas themselves.