Wandering Thoughts archives

What is guaranteed in languages in practice

In theory, what is guaranteed in a language is the things that are in its (official) specification; if the specification is silent or says that something is not guaranteed, it isn't, regardless of how implementations behave.

More and more I have come to believe that this is mistaken, and that in practice what is guaranteed in a language is what programmers code to, regardless of what the specification says. This is because of simple pragmatics: a new implementation that does not run most of the existing code is generally pretty useless to people. Thus, a new implementation that breaks from established practice does not get much traction and adoption, even if its differences are blessed by the specifications.

(Or in short, people don't care why it doesn't run their old code, they just care that it doesn't.)

You can change this state of affairs, but it takes a long time and the new implementations have to have something desirable that will get people to overcome their inertia and actually change their code instead of just sticking with the existing, working implementation. Of course you can try to give people no choice, for example by no longer selling the old implementation, but this can backfire on you in various ways.

(There are many examples of such slow changes; consider how long it took to get C programs to be 64-bit clean and large file aware, and note how it only really started happening once there was 64-bit hardware out there.)

The corollary to this pragmatic view is that if you want people to stick to what is documented, you need to get them coding to it from the start. I can think of two ways to encourage this:

• make your first implementation enforce the specification, especially the things the specification says that programmers can't count on.
• have multiple implementations from the start, ideally ones with useful differences, so that people are pushed towards coding to the documented subset.

  (For this to work you need people to be interested in moving their code between the implementations.)

Unfortunately both are easier said than done.

One thing that I dislike about typical debuggers

One of the things that I hate about typical debuggers is that they want me to hold their hand all the time. Okay, this is not entirely fair; they default to having me hold their hand, and generally don't do a really good job of supporting hands-off operation.

This is not really their fault, because debuggers have a different view of how they're going to be used than I do. A classical debugger (like gdb) expects to be used by people who are carefully narrowing in on the bug, taking cautious step after cautious step, and for this of course you want to interact with the debugger all the time (because ultimately you are looking for an anomaly, which requires a human's eye).

I don't use debuggers that way. Instead, I use them to extract a bunch of information from the program which I will then stare at for a while, so I want to set things up (simply, please) and then fire off a run without further intervention. The last thing I want to do is to slow down the process by having to interact with the debugger all the time.

Modern debuggers sort of support this; you can write command sets for breakpoints and so on that automatically dump information and then continue. But my impression is that both the command language and the interface is awkward, and in practice when I've tried to use gdb for this sort of thing I've wound up getting lost in the complexity of managing all of the breakpoints and so on by hand. I would actually rather have a script-driven debugger where I had to edit a file and then reload it to change what I was monitoring, because that's easier to keep track of and to modify.

(Having to keep changing a file and reloading it would of course be intolerable for the step by step 'narrowing in' style of debugging, which is why I don't expect debuggers to support it any time soon.)

A (D)VCS feature that I'd really like

Here's something that I want: I want a version control system (ideally a distributed one) that can preserve file timestamps. I'm looking for such a weird feature because I happen to have created something that I want to put under version control where (some of the) file timestamps are significant and need to be preserved.

(This is yet another hazard of using files as entries, albeit in a slightly different form.)

This is an uncommon feature in version control systems at the best of times, partly because actually doing this can muck up source builds when you revert to older versions of files (with older timestamps). I know that neither Mercurial nor Git have this, and while I haven't looked into the 'secondary' DVCSes (such as bzr) very much, my impression is that none of them do it either.

(File timestamps don't have to be first class version controlled data; I'd be happy if the file timestamp was only recorded when some other change to the file was committed, as opposed to causing commits every time it was the only thing that changed.)

I suspect that most practical workaround is a program to save and restore the file timestamps for a directory hierarchy, and then making the file of timestamp data (and possibly the program) part of what's under version control. This requires an extra step on checkouts and especially commits, and if I ever do much branching I'll probably get merge conflicts all the time on the file of timestamp data, but at least it preserves the data.