Wandering Thoughts archives

Computing has two versions of 'necessary'

In various fields of computing we often wind up either saying that something is necessary or arguing about whether it is necessary. One of the things that complicates these discussions is that in computing we have two versions or meanings of 'necessary', the mathematic and the pragmatic.

The mathematical version of necessary is minimalism. At its strongest, the mathematical 'necessary' means that this feature or thing is essential, that you have to have it, that things do not work without it. The pragmatic version of necessary is what I'll call economy of effort, the idea that something is necessary when it is the best way to achieve something. The pragmatic version of necessary is a humanist vision.

A mathematically necessary feature can also be pragmatically necessary; it is great when this happens because both sides get to agree. However it's common for pragmatically necessary things to not be mathematically necessary (at which point they often get called unneeded) and sometimes for the mathematically necessary things to not be pragmatically necessary (at which point they can get called too low-level).

A strong adherence to the mathematical version of necessary drives a lot of what I consider pathologies in computing. But a strong adherence to the pragmatic version of necessary also has its downsides, including clutter and incoherence when carried to extremes (which it often has been). And in general adherents of each side not infrequently wind up talking past each other.

PS: I suspect that you can come up with some examples of the mathematical necessary and the pragmatic necessary on your own, so I'm not going to fan the flames of argument by picking out ones here. There are some very obvious suspects among, eg, computer languages.

(I've touched on this idea before back here, among other entries.)

The power of meaningless identifiers

In computing we have a strong tendency to create meaningful identifiers for things. There are any number of sensible reasons for this and any number of things you get from using meaningful identifiers (including that people can remember them), but there is a pair of drawbacks to it. The large one is that almost anything with meaning can have that meaning change over time; the smaller one is that almost anything with meaning can be misspelled or mistyped when initially created. Both of these lead you to really want to change those identifiers, which often leads to heartburn since many things don't cope very well with theoretically constant identifiers changing.

The power of meaningless identifiers is that this doesn't happen. Precisely because they don't mean anything, they never have to change and it doesn't matter if you made a mistake in their initial creation. This means that they can be genuinely constant things (and it's easy to keep promises about this).

This conflict between meaningful identifiers and constant identifiers and the power of meaningless identifiers to cut through the Gordian knot comes up repeatedly in different contexts. You have the cool URL problem, the login problem, the temptation to use real database fields as foreign keys, and many more. Using meaningless identifiers instead is often either completely problem free or at most slightly more ugly (when the meaningless identifier must be visible to people, for example in URLs).

Note that a truly meaningless identifier shouldn't just merely be empty of planned meaning, it should be structured so that no meaning can be read into it later no matter what its value is, whether this is by users or possible third parties. Random numbers are better than sequential or semi-sequential numbers, for example.

(And while we're at it, remember that 'randomly generated' doesn't necessarily give you things without meaning.)