The pragmatics of language changes

August 7, 2008

There is a certain view, one that is easy for people to fall into, to the effect that while backwards compatibility in new versions of languages is important and should be given due weight, sometimes the language designers can, do, and should decide that the change is important enough so that it should be made. Let us call this the language designer view of language changes.

The problem for this view and for the decisions that come from it is simple:

Programmers do not have to accept what you give them.

The view that language authors can ignore backwards compatibility as inconvenient or not important enough and force people to accept incompatible language changes ignores this fundamental reality. Programmers are not passive objects that have to accept whatever changes you make; if you push them too far, they will revolt and ignore your new version of the language in one way or another. And revolts do happen; look at what happened with PHP4 versus PHP5.

(I'm sure that the causes were complex, but the ultimate upshot is that PHP5 experienced what could politely be called a 'slow uptake'.)

So the real question a language designer faces is not whether their changes are necessary or important enough to justify breaking backwards compatibility (although they should be); it is whether the changes are drastic enough to provoke significant user revolt. If the changes will provoke too much user revolt it doesn't really matter how important they are, because on a practical level they're impossible (you can change your version of the language, but not the version that programmers actually use).

Or in other words: significant language changes are at least as much a social problem as they are a technical one, and language designers need to deal with them as such.

(This is sort of amplifying on something I wrote in passing in PracticalLanguageGuarantees.)

Comments on this page:

From at 2008-08-07 19:11:06:

If you consider the large bodies of production code, then it's a practical problem as well, not just social or technically. If you have a million-line application, and a change would require you rewrite most of it, that's a massive one-time cost.

The harm of total rewrites is well demonstrated:

If you add a new feature, and slowly depreciate the old one, this gives a lot of time for people to switch over.. there are psychological factors as well, like making sure the old version is gone before they need to stop using it, but it's the best way we have to keep evolving while minimizing disruption.

Written on 07 August 2008.
« More on the funding capture problem
A workaround for the Python module search path issue on Unix »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Aug 7 00:34:19 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.