Express yourself: to the compiler and to your fellow developer.

The keynote speaker at CGO 2012 (Chris Lattner, LLVM) put some crazy thoughts into my head.

Want compiler to know about:

• memory disjointness
• aliasing
• Usage of data structures (array of struct vs struct of arrays)
• whether arithmetic is done on a pointer (and the bounds)
• invariants (in loops and between methods)

A language needs to be able to express some of these concerns. Not just because the analysis within the compiler benefits from having the data, but that programmers themselves should be documenting these properties. A great programmer knows about the analysis the compiler can perform. A great programmer knows about the assumptions that such analysis requires. And a great language supports the great programmer by allowing her to express these properties within the code itself.

Creating a language that supports these higher-level descriptions allows other programmers to see why a certain portion of code is structured the way that it is. It helps them from innocently re-structuring the code so that the compiler’s analysis fails (and performance is lost). It makes more clear what you shouldn’t say as a programmer.

I’m not familiar with Eiffel, so I may be completely out of place with this example. But, it seems to me that Eiffel’s choice to allow the programmer to express explicitly, in source the invariants of their programs has two distinct benefits: (1) the compiler has more information to work with during program analysis, (2) the programmers are encouraged to think more deeply about their code’s structure. Much compiler research has tried to investigate “How much can we do this automatically (so that we don’t have to change existing code and so that programmers don’t have to learn anything new)?” I’m using Eiffel as an example of why these objectives are actually harmful. In my experience as a programmer, knowing more has always helped. I desire a language that encourages me to know more, and the best encouragement is to have linguistic support for describing higher-level properties. In Eiffel’s case it’s program invariants, but why not include also some of those things in the list above?

The compiler shouldn’t be a magic black box! It should be a tool that yields increasing benefit the more a programmer devotes to learning how to use it. The benefits should build on each other incrementally, so that even though complete mastery takes 10 years, each incremental step is worth taking.