Zimbu: Designing a Programming Language From Experience
Programmers have been creating code for a long time now. We have learned what
works well and what leads to doom. With this knowledge we can design a
programming language that helps programmers do their work productively.
Choices can be made from experience, instead of using some academic theory or
the hot fashion of the year.
Even though many programming languages already exist, it's hard to make a
choice for something like creating a text editor. Adding up all the
requirements, there really is not one language that fulfills them all. So
let's make one!
This talk takes a list of important observations from the daily work of
programmers and discusses what that means for the choices made in designing a
programming language. Many alternative solutions can be found in existing
languages, some old and some new. It is mainly a matter of evaluating these
alternatives and picking the right solution using our collective experience.
But in some cases we just can't find the right solution and have to invent
For example, one important choice is how to structure code, how to keep code
that belongs together in once place. An observation is that we will always
want to add new features on top of existing code. There must be a good way to
extend what is already there, without rewriting it for every new feature. The
mechanism of inheritance in object-oriented programming solves this partly.
We have learned that multiple inheritance is too complex. But single
inheritance doesn't cover what we need. The solution lies in mixins: blocks
of functionality that can be used and re-used. This gives the programmer the
choice to use inheritance where that makes sense, and mixin code blocks where
that works well.
Another observation, which is rather obvious: Code is read ten times more
often than it is written. Being able to write quickly is not all that
important, being able to read and understand it easily is essential. Many
languages have made the mistake to make code easy to write but hard to read.
Others require that variable types are specified in great detail, making it
difficult to see what the code is actually doing. It is possible to find a
balance between the two, there are a few new languages that have solutions in
An example of where no existing language offers a good solution is supporting
code generation. This is possible, of course, but requires writing a Makefile
and/or scripts in some other language, which often end up not being portable
and require installing a wild variety of other tools. We can observe this
causing serious maintenance problems. The solution comes not from existing
programming languages, but from applications: plugins. Compiler plugins,
written in the same language as the program itself, can be used to generate
code. An import statement can define the input and the plugin used to
process it. This is easy to understand and avoids maintenance problems.
Plugins can be distributed by themselves and re-used, just like one would
distribute a library.
The talk will go into a variety of these observations and their implications
for choices in programming language design. Illustrated with the current
state of the Zimbu language, see www.zimbu.org. The best check that a new
language works well is writing programs in it. Therefore the Zimbu compiler
was written in Zimbu. The talk will also explain how that is possible.