An illustration of why syntactic sugar matters

August 20, 2008

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


Comments on this page:

From 98.207.106.89 at 2008-08-31 04:54:20:

This is a good point! I've seen people try to get around this dichotomy in Python programs through the use of object-access/dict-access mashups, but the point that the literal syntax doesn't support the idiom still remains.

Of course, if you don't need type information (as you want here) you can instantiate object and set attributes on it, but it's a hack. :)

- Chris Leary

From 98.207.106.89 at 2008-09-05 21:15:32:

I thought of this post when I read about the new 2.6 feature: http://docs.python.org/dev/library/collections.html#collections.namedtuple

I believe this solves the Python structured data syntax issues.

- Chris Leary

Written on 20 August 2008.
« The problem with using tuples and lists to hold structures
What you select for when you make something harder »

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

Last modified: Wed Aug 20 01:32:24 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.