2022-04-10
Suppose you have a steel rod, 2.5 meters long.
It's useful. You can use it as a barbell, or as a lever, or to smash something.
Then someone comes and asks: what if we put a joint in the middle? It'd be much more useful! You could easily get it through a door frame, or put it in your car. No more accidentally smashed things when carrying it over the shoulder!
So they put a joint in the middle. Much better! The word gets around — joints are useful! Soon there are good proposals for more joints.
Time passes.
Until one day, you see that the rod has become nothing but joints. It's thrice as heavy, takes forever to assemble, and its structural integrity is ruined.
At some point, people started thinking of joints as inherently good, or applied them without considering the wider context. They went past the point where new joints added negative utility, and to the point where they could not add another joint, because it was ridiculous even to them.
It's not so much Java-the-language that bothers me, but the culture, the approach that comes with it: more joints is always better.
Remember that old rant blogpost by Steve Yegge?
Or the "Enterprise Java FizzBuzz" joke?
It's not the noun-centricness that makes them comical.
It's the absurd number of needless joints.
By joint, I mean any point of flexibility — an indirection which allows you to vary the behaviour of the program more easily. For example:
Joints make programming practical. But they are not inherently good: their utility comes from their context. And they're not free: each joint is overhead, which must be justified by its utility.