Wandering Thoughts archives

The aesthetics of syntactic sugar

The Unix test program makes for a great illustration of the aesthetic importance of syntactic sugar, to go along with its pragmatic effects. Consider the following two shell script lines:

if test -f /some/file; then ...

if [ -f /some/file ]; then ...

In any Bourne shell environment worth its name, these two have exactly the same results and in fact run exactly the same program (or an imitation of it), because [ is just another name for test. But at least to me, they read significantly differently, and I find that the second one looks better and reads more clearly.

(I think the problem with the first one is that everything looks the same, because it's all words and switches. In the second one, the [ and ] stand out visually and so act as useful punctuation.)

To go out on a limb, I think that this is one of the drawbacks of languages like Lisp. By having no syntax they also have no syntactic aesthetics, whether bad (all too common) or good; instead, everything disappears into an even flow of words and parentheses. There are virtues to this regularity, but I can't help but think that such languages are missing something too.

(Possibly the answer for syntax-less languages are IDEs that add in 'punctuation' in the form of colour, different fonts, and so on.)

How we lie to our Makefiles

I spent part of today updating the system that generates data files for our mail system to add a new computed data file. This system is built around a Makefile, and so I added a new rule, which looks like this:

$(CL): $(DL) $(AUXFILE)
    crunch-dl $(DL) $(AUXFILE) >$(CL).new
    mv -f $(CL).new $(CL)

(The rule is done in two stages so that we don't update the $(CL) file if the crunch-dl script fails. If we just wrote directly to $(CL), we could be left with an incomplete or empty $(CL) that make thinks is up to date because it has a current timestamp.)

Those dependencies are a lie. Well, a lie by omission. The generated file doesn't just depend on the data files, it also depends on the crunch-dl script that processes the data files; change the script and you may well change the generated output. (You may not, but this is true of changing any dependency.)

I commit this lie regularly, even routinely, although I am not sure why. Partly I think that it is a mindset; I think of Makefile rules in general as declaring the inputs that are turned into the output, and the script is not an 'input' as such so it gets left out. Partly I think that it is convention and habit, how I've always done things and seen them done, and thus that it would simply feel (and look) wrong to add the script as a dependency (especially because it isn't in the current directory).

(Of course, my conventions are mostly formed by reading and writing Makefiles for C programs, which have relatively little call for explicitly depending on the compiler. And once you start thinking about depending on the compiler, you also have to think about depending on important compiler flags, and most people don't want to go there.)

Some thoughts on improving current thread-based programming

However much I would like it to, it does not seem that the thread and shared memory based model of programming concurrency is going to go away any time soon. So here is a theory on how to improve it.

I will start with a premise: the reason locking is such a problem in thread programming is because so much of it is implicit, and humans do a horrible job at remembering implicit things (especially implicit things at a distance). Thus to improve the situation, we need to make as much locking as possible explicit, and further, we need to do it in a non-annoying manner.

The best place for this is in the IDE, because the IDE has the best interface for telling you things (which is what's necessary to make locking explicit). To do this, the IDE needs to keep track of locks that are taken by code paths and locks that are required for access to specific objects; if done cleverly this doesn't need language changes, and the IDE can work out a lot of this by itself (probably with some annotations added by the programmer when the IDE falls down). While this is a bunch of parsing and code analysis, my impression is that powerful IDEs are already doing a lot of that as it is (at least in languages that are static enough to be amenable to it) and, for that matter, the IDE need not restrict itself to static analysis; in the same way that people profile code for performance, the IDE could profile the code for locking.

(One advantage of doing this in the IDE instead of the language is that IDEs are allowed to be incomplete and not entirely accurate, as long as they warn you about it. And you can turn the IDE's helpful information displays off if they turn out to be useless for your particular project.)

Once the IDE has this information, there's all sorts of things it can do with it. The simple thing is to colour or otherwise note the locks that are held when the code you're working on is run, and to similarly colour objects that you access and work with. Beyond that I'm sure there's a pile of visualization that can be done to give you a higher level view of your program's locking; if nothing else, Venn diagrams of lock overlap should be interesting in any decent-sized code base.

(Disclaimer: I can't be the first person to have this idea, and I wouldn't be surprised to find out that there are already IDEs that do this.)