Causerie Begins With...

Previously: Adventures in Computer Linguistics

On reaching the conclusion that writing a computer programming language is the only thing left to do, the next logical question is: where to begin?

Is and Isn't

Well, think about it: what is a computer language? What is a program? From the computer's point of view, a program is simply a sequence of modulated voltages. At a slightly higher level, these are the 1s and 0s that make up the binary code which the processors use to execute instructions. It is undoubtedly possible to program a processor using differential voltages, but it is slightly easier (for a twenty-first century human) to send it a sequence of 1s and 0s -- and even easier to represent those 1s and 0s as something with which the human is familiar, such as English (or Spanish, or Portuguese, or whatever language you happen to speak). It gets even easier if the syntax of that language -- the rules about how it should be written -- more closely match the syntax of the language that the programmer writes (and speaks, one would presume).

There are, in fact, computer languages out there that attempt to closely match the grammar of the English language; two notable examples that come to mind are HyperTalk and to a lesser extent its successor, AppleScript. The advantages of such an approach are easy to see: anyone with a grasp of English can quickly pick up and use the language to make the computer do things. However, as anyone who has tried to do it knows, teaching a computer to parse the complexities and paradoxes of human writing is a complicated task; moreover, the more complex the task, the longer such a program must be. Take a look at the examples for AppleScript to see what I mean. The majority of programming languages opt for a compromise, and so will we. We are not attempting to match the intricacies and vagaries of the English language; we only want a syntax that is simple, elegant, and powerful.

This is not a goal that has sprung from the void. I have already outlined some of my problems with other programming languages, and the chief problem I have with many of them is their syntax: some are too verbose, some are too rooted in symbols, some are too forgiving of sloppy code. Far too often the object-oriented features are laid clumsily atop the older syntax. All of them helped to determine what I did not want the language to be.

Of course, such judgments are based solely on my own opinions. All of the languages I've tried are serviceable, and they are all popular for a reason: C has portability; C++ has power; Objective C makes C a viable object-oriented programming language without diluting its power; Pascal has elegance and enough type safety to keep programmers from doing accidental damage; Python has a large library and quick development times. In fact, Python's library and quick development times are the chief reasons we will be using it to create the first iteration of this new computer language. But none of the languages that I've tried seem to be designed for simplicity and elegance -- save one.

Smalltalk

My euphoria at discovering Objective C drove me to learn more about it, and that is how I discovered Smalltalk. Much of the syntax used in Objective C, particularly when passing messages to classes, is borrowed from Smalltalk. The more I learned about Smalltalk, the more I became convinced that it was the language I sought. It was simple -- everything in the language is an object -- and it was elegant -- every statement proceeds from the idea that you are sending a message to an object (calling a method of an object, if you'd prefer more traditional verbiage). Although the conditional "statements" required some acclimation, they flow naturally from the syntax of the language and are beautifully consistent with it. The number of keywords is small because there is no need for more; virtually every statement begins the same way: with an object that is to receive and act on a message. It is, to my mind, almost the perfect computer language.

Almost. Despite repeated searches, I was only able to find Smalltalk interpreters. There appear to be no Smalltalk compilers (none that Google knows about, at any rate). For someone looking to write a game engine, this can be a problem, because even JIT compilers cannot execute as quickly as natively-compiled code without more overhead. Even more unusual, to my mind, the interpreters that I found were designed to be stateful virtual machines. This is a side effect of Smalltalk's "everything is an object" idea: even the interpreter is an object, and it can be manipulated by a running program at will. The virtual machine, which is represented by the interpreter, can be saved to disk and recalled, meaning the next time you load it, it will pick up from where you left off last time. There are advantages to such an approach, such as the convenience of loading a virtual machine that is already pre-configured with all of the libraries you may need, but for writing a game engine, it is hardly necessary.

Despite these setbacks, the syntax of Smalltalk meets two of the three criteria specified above: it is both simple and elegant. Can it be powerful? I believe so, if it is expanded beyond a virtual machine to a real one. There is enough potential to make the attempt worthwhile.

Causerie

And that is the origin of this new language; one that we will call causerie (more background) in honor of its Smalltalk heritage and in recognition of the idea that code written in the language should be short, informal, and decidedly to the point -- simple and powerful -- while having at the same time a style all of its own -- elegance.

Next: Causerie: A Wishlist