Wandering Thoughts archives

An illustration of why syntactic sugar matters

Consider a couple of imaginary languages with different approaches to handling simple structured data:

• in the first language, anonymous structured objects are created with obj = {'field1': value1, 'field2': value2} and then accessed with obj['field1'].

• in the second language, anonymous structured objects are created with obj = {:field1 = value1, :field2 = value2} and then accessed with obj.field1.

(Both languages also support the usual lists and so on.)

Which language is going to see more use of structured data in practice, instead of programmers just throwing things in lists? My personal belief is the second language, because I think that it makes it enough easier that people will find it worthwhile to go to the effort.

The second language doesn't have any more advanced features (in fact it is less powerful than the first language, since the field names are implicitly restricted to being valid identifiers). What it has going for it is syntactic sugar; it has come up with a more convenient notation for this idiom.

Syntactic sugar matters because good syntactic support for an idiom encourages people to use the idiom; it makes the idiom obvious and the path of least resistance, the easiest way to get that particular job done. So if you have an idiom that you think is important, you should try to have your syntax make it easy.

(And to a significant extent, what languages make easy or hard is what differentiates them from each other. You can argue that Python and Ruby are mostly equivalent in terms of language features; however, they have very different characters because Python makes hard some things that Ruby makes easy and vice versa.)

The pragmatics of language changes

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.)