Andrej Bauer on Language Design

| by Jonathan Allen Follow 576 Followers on Apr 15, 2009. Estimated reading time: 3 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you