I’m going to try blogging about technical matters now, but in a way which my non-technical readers might be able to understand. This may well end up pleasing nobody.
Most of my work is done in Perl, a programming language which divides people. To outsiders, Perl is ugly, hairy, inelegant, badly-specified and generally crappy. It lends itself to bodgy jobs, to a slovenly approach to coding, and to messy, unreadable code that’s impossible to maintain.
There are a couple of ways in which a Perl programmer can respond to this. The first is to half-jokingly argue that Perl is indeed bodgy, and that bodgy jobs are its ecological niche. The second is to point to the design goals of the language, which were to make life easy for the programmer, not for the computer which is running the program.
This last argument is, in a sense, an evasion of the criticism about being badly specified. Perl is, in fact, badly specified. In general, a programming language will be defined by a rigorous grammar. This is something like the grammar of a language like English. I’m not a fan of the analogy between what IT people call ‘natural languages’ and programming languages, but I’ll spare you that for now: I’ll just say that programming language grammars defined the language in a way that is formally precise. The grammar allows any statement or set of statements in the language to be separated into words and parsed into a logical structure: this logical structure is then translated into a set of low-level instructions which the computer executes when it runs the program.
Except that Perl doesn’t really have a rigorous grammar. Perl is full of cheats and niggles which allow it to second-guess the programmer’s intentions, usually in ways which make it a very convenient language in which to write code; they also make it formally intractable. It’s an old Perl joke that “the language specification is the interpreter” – meaning that there’s no formal definition of the language apart from what Perl does when you feed it code: but this is no joke. It’s literally, mathematically true, and here is a fairly rigorous proof that Perl 5 can’t be parsed.
The standard Perl hacker’s response to such things is to laugh. In theory, a badly defined computer language could be dangerous, because you can’t predict with 100% certainty what will happen when your code is compiled and executed. In practice, the number of times I’ve created a bug which arose from Perl’s muddle-headedness – that is, a program malfunctioned because of an ambiguous code construct which Perl took the wrong way – is vanishingly small. Almost all of my bugs were the consequence of bad design, muddled thinking on my part, typos, losing my way, and all the various other kinds of human error. One of the best arguments in Perl’s defense is that the extra levels of convenience it gives you enable you to avoid many of these bugs, and that this more than makes up for the danger of the language’s sloppiness.
However, formal language definitions have another use besides writing compilers: they are highly useful for programming tools, which become considerably more powerful if they can be given access to your code’s structure. Perl’s programming tool support is a long way behind that of languages like Java, because writing tools to support Perl in this way is devilishly hard. It was instructive at OSDC last year to hear Adam Kennedy talking about the lag in the Perl toolchain, compared with what Java programmers get to play with. The Perl hacker’s response to this kind of talk is often to act all tough, as if refactoring tools and class browsers are for wusses, and then go back to our text editors where even syntax highlighting can still be kind of broken: this is not really good enough.
Seen in this light, the Perl design tradeoff – loosening formal language design in exchange for programmer comfort – is not really a tradeoff between formalism and pragmatism; it’s a tradeoff between two different kinds of pragmatism.
Perl 6 is expected to have A Grammar, but the grammar will be modifiable from within the language: a very Perl answer to the problem, but one that has its own dangers.