The Tao Algebra of Programming

I think it's possible to break a programming language into a set of communicating algebras. There's a procedure algebra which encompases the control structures we commonly think of, as well as exception handling. There's a mathematical algebra, which evaluates expressions in a referentially transparent manner, and there's a storage algebra, which handles data structures and value assignment.

Your typical OO language will try to cram custom data structure operations into the mathematical/function algebra, but really they belong in the algebra of storage and assignment. That's why you can access Java arrays with the square brackets, but you have to call an object method to read an element of a binary tree, and another method to write one.

C++ tries to improve on this by making it possible to override operators, but in my opinion it's terribly clumsy for the person who's doing it, and it doesn't really let you define your own new algebra, but only try to map your operations onto an algebra that C++ already has. This isn't always desirable, because things can get rather confusing. Consider, for example, a vector and matrix manipulation package. You'd like a "dot-product" operator, and a "cross-product" operator. Additionally, you would like the orthography to resemble what mathematicians use. C++ won't let you do that. APL and J are built around a matrix algebra, so they have less trouble in that particular regard, but this is supposed to be a comparison of principles.

Perl additionally provides an algebra of regular expressions, and an algebra of here-documents, and interpolated strings of text, and so on. I firmly believe that it's access to these additional algebras that makes Perl a more expressive language than many others.

Python lacks a true algebra of regexes, and delegates the processing of regexes to an element of something it does have: Classes and objects. So Python is good because its object algebra is well-developed, and leaves Perl in the dust. Furthermore, Python's control algebra happens to be much prettier and less error-prone than the control algebras of the curly-brace languages.

You're less likely to make a mistake when communicating an idea if the idea fits naturally within an algebra of your language than if you must first cast the algebra of the concept into a form acceptable to some other algebra. You can also read the result more easily if you don't have to do the reverse transformation.

Until now, I think most programming language developers have focused most of their attention on getting the best set of algebras. Lisp seems to have only a one algebra: that of the lambda calculus. That makes Lisp programmers few, proud, and illegible. Forth posesses only the algebra of the stack machine and the input stream. That makes Forth programmers fanatical but few in number, and it makes their programs both agile and fragile.

In fact, Lisp and Forth are both very powerful languages, and largely for the same reason: They offer programatic access to the input stream. In Lisp, you get it pre-parsed into list format, while in Forth, you get the actual non-terminal symbols in a sequence. Both of these facilities enable the programmer to create arbitrarily powerful metawords in these languages. On the opposide extreme, C++ now has templates, and C++ templates are Turing-complete. With effort, you can create amazingly powerful metawords in C++ with highly magical properties. See, for example, the book "Template Metaprogramming in C++" for a taste.

Yet, for all this power, none of these languages offer the true ability to extend their algebras. No matter how many macros you write, you'll not write matrix algebra in Lisp, C++, or Forth.

That programming language will ultimately be successful which finds a way to allow custom algebras to be written to plug together in semantically meaningful ways.



Peace be upon you.