Andrej Bauer on Language Design

Posted by Jonathan Allen on Apr 15, 2009

Sections

Development,

Architecture & Design

Topics

.NET ,

Programming

Andrej Bauer starts essay, On programming language design, with a simple premise, “Programmers are just humans: forgetful, lazy, and make every mistake imaginable.”

Therefore, it is the task of the designer to make a programming language which counters these deficiencies. A language must not be too complex, lest the programmer forget half of it. A language must support the programmer’s laziness by providing lots of useful libraries, and by making it possible to express ideas directly and succinctly. The language must allow good organization of source code, otherwise the programmer will use the copy-paste method. The language must try really hard to catch programming mistakes, especially the mundane ones that happen to everyone all the time. When it finds a mistake, it must point to the true reason for it, preferably with an error message that humans understand.

The first section he applies this theory to is unknowns. He writes,

The principle tells us that it is a bad idea to allow invalid references because programmers will create them. Indeed, most recently designed languages, say Java and Python, do not allow you to write obviously risky things, such as

int *p = (int *)0xabcdef;

Unfortunately, many designers have still not learnt that the special NULL pointer or null object is an equally bad idea.

This is especially true in .NET programming. Not only does it have the same “null reference exception” that Java had, with generics we also were given the problems with Nullable value types. There is hope here with Code Contracts, but that technology is still far from being production ready.

After a discussion about strongly typed objects versus list-based data structures, Andrej moves on to definitions verses variables. He raises some interesting points on the issue that could be applied to .NET programming.

If you observe how variables are typically used, you will see several distinct uses:

• often a variable is only assigned to once and is used as an (immutable) definition
• a variable in a loop or list comprehension ranges over the elements of a list, or a collection of objects
• a variable stores the current state and is genuinely mutable

Should loop counters be mutable? I think not. Code that changes the loop counter in the body of the loop is confusing and error prone. If you want to fiddle with counters, use the while loop instead. So in two out of three cases we want our variables to be immutable, but the popular programming languages only give us variables. That’s silly. We should design the language so that the default case is an immutable value. If the programmer wants a mutable value, he should say so explicitly.

Could this be done in C# or VB? Certainly, and it wouldn’t be hard either.

For assign-once variables, we can leverage the existing type inference. For C# you would write “def x = …” instead of “var x = …”. Or perhaps we could simply reuse the existing keyword “Const”. That would certainly fit with VB’s “do what I mean, not what I say” philosophy towards other issues like early vs. late binding. The important thing is that the keyword is short; if you use something long like “readonly”, developers will tend to avoid it.

The next one is even easier. One simply has to emit a compiler warning when a loop variable is being changed.

The final option, the one using legitimately mutable variables, should then become a rarity. Not entirely disallowed of course, but simply not used unless actually needed.

The other issues such as compile-time vs runtime checking and undefined identifiers don’t really apply to mainstream .NET programmers. But if you are looking to pick up IronPython or IronRuby, you would do well to familiarize yourself with some of the issues that arise from them.

All in all, Andrej Bauer’s On programming language design is a good introduction to the kinds of problems the next generation of programming languages should seek to address.

• Older >