Wandering Thoughts archives

2008-08-20

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

programming/SyntacticSugarMatters written at 01:32:24; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.