Programming Language Simplicity
Simple Rules
One of the things I like about the Go boardgame is that it has so few rules. You can place your stones anywhere on the board so long as they are not surrounded on all sides by your opponent’s stones. You capture territory (and/or enemy stones) by surrounding them.
There are a couple additional rules to account for edge-case scenarios, but even these are quite simple. You can learn to play the game in about five to ten minutes.
Everything else, a whole bestiary of named patterns and strategies, is derived from the basic rules. It is one of the most wonderful examples of "easy to learn, a lifetime to master".
Another example of glorious complexity emerging from simple rules is Conway’s Game of Life. Four simple rules about "living" and "dead" cells produces a diverse catalog of "creatures".
Perhaps the most basic toolkit for making complicated systems from simple rules is the cellular automaton (CA), of which the Game of Life is one example.
It’s interesting to compare and contrast Go with a CA. It’s rules are simple in the exact same way that the Game of Life’s rules are simple. Yet the game does not play itself, nor are "generations" (turns) of the game derived from the game’s rules. Instead, the players cause all new pieces to be placed. Only the removal of captured pieces could be said to be "automatic".
What is a simple programming language?
What’s the Go or CA of programming?
Arguably a hyper minimalistic Forth, Scheme (or lambda calculus), or perhaps the most CA-like: Brainfuck (hereafter "BF").
These actual seem like pretty great matches: the rules are few and simple to learn - but actually creating a big, complex program (like, say, a flight simulator) with them would fall under that "lifetime to master" thing.
So what’s intersting is that subjectively:
-
Go is fun to play just like it is - mastering what can be done within the confines of the simple rules is part of the fun.
-
Conway’s Game of Life is fun to play with - but only with a computer performing the actual generations (turns) - I don’t think most of us would want to work out the motion of something big like a puffer train on sheets of graph paper.
-
Writing big software with BF is a task for masochists or those who take great pleasure in overcoming the hardest of puzzles.
Why are the primitives of a boardgame or CA simulation fun and satisfying while the primitives of computing are not?
Well, now, actually… It depends on what you’re trying to accomplish. If you want to mess around with bits and bytes of memory and the elements of computing themselves are your playthings, then Forth, Scheme, and BF are excellent rulesets for play and exploration!
But if you sit a bunch of people down in front of a computer, they’re likely going to want very different things from their programs:
-
The small child might want to make colors and sounds and movement.
-
The older child might be interested in crafting word-based and storytelling games.
-
Older people still might wish to sort a list or find the average of a series of numbers.
-
And the most sophisticated, of course, will wish to create their own programming language even better suited to their increasingly specialized interests.
The "primitives" of the language best suited to each of these tasks is necessarily different.
The programming language that makes colors, sounds, and movement easy is likely very different from the language that makes making other languages easy. (Note the word "easy" here rather than "simple".)
And yet. And yet. Aren’t all languages equally "powerful" under the Church-Turing thesis and computational universality.
And so my question is: despite the different needs of the different problem domains, is there, in fact, a set of universal "simple rules" that all of these languages could have entirely in common if we were enlightened enough to see them?
…to be continued…
Antonym: big-complexity
Back to pl-design