In my last article, I wrote about safety in the emerging computer languages presented at OSCON — how some languages focus on reducing failures by tightening up a language, restricting or regulating how code interfaces with other code, with data, and with system and network resources.
On the other side of the spectrum, we have languages that still function as useful tools, but encourage programmer productivity and expression. Like beauty, expressiveness is in the eye of the beholder. Generally, the languages that call themselves ‘expressive’ place a value on simplicity and consistency, allowing programmers to translate high-level concepts into code without being distracted by syntax or convention. They let a programmer do bigger things with less effort. And they often encourage an openness, a sense of play, a pleasure of work, a poetry of code.
In the expressive languages, the concept of a rigid syntax seems to be far less important than in conventional languages. Perhaps that’s the influx of metaprogramming in languages like Ruby that encourage domain-specific mini-languages, or a general rebellion against committee-driven over-specification. In several of the emerging languages, there was a willingness by the designer to let the language evolve. CoffeeScript, again, was an example of incrementally improving an otherwise static language. Unlike most languages that have a public external representation and a private internal parse tree, Ioke welcomes the utility of different representations. It supports a ‘sugared’, Ruby-like syntax, a canonical/‘desugared’ representation, as well as an internal syntax. All can be used by a programmer, depending on need — for example, the implementation of a DSL might return a tree of internal syntax.
Most designers of expressive languages seem to want people to not only understand how to use their language, but understand how the language itself works. Sometimes this is done by unifying and simplifying the architecture. Io and Ioke avoid built-in keywords in favor of implementing everything as objects communicating via messages. Other languages emphasize the openness of the implementation itself: the websites for both Finch and Fancy explicitly state that the underlying code is intended to be understood. (Although not presented at the conference, Rubinius, too, shares this goal by reimplementing most of Ruby’s core in Ruby itself.)
Pushing the boundaries with visual languages
After so many decades of purely textual languages, you might think that new language attempts might seek to pull themselves up from the soup of words, and attempt to express themselves as pictures. But while IDEs and other development interfaces have made some progress, most languages are still inherently textual. Only two languages presented were primarily in the visual vein.
While the language base for Thyrd is a textual, stack-oriented, postfix notation like Forth, an integrated graphical runtime provides visualization of execution, as well as far more intuitive debugging. Thyrd emphasizes programming via direct manipulation. Its data lives in ‘Thyrdspace,’ a spreadsheet-like hierarchy of grids and cells. Higher-level structures like arrays and dictionaries are implemented in terms of various kinds of grids, and cells can be bound together to express relationships and formulas.
Kodu, a game-programming environment for the Xbox 360, does away entirely with a textual language, expressing conditionals, loops, and other actions as sequences of icons that can be created and moved around to create precedence and sequence. Kodu attempts to integrate ‘play mode’ with ‘programming mode.’ It’s an impressive project.
Circa, while not a particularly inventive language, was interesting in its support for dynamically reloading of code as it was changed by the programmer. Through a combination of code analysis and built-in mechanisms for saving and restoring state, it attempts to be a fluid environment for designing games.
Wheeler was certainly the strangest language presented at the conference. More easily demonstrated than explained, it is quite unlike most programming languages. In Wheeler, objects become related to each other basically through proximity — if they are mentioned together, they become automatically related into ‘categories.’ No hierarchy exists, nor is order important: interactions are (in theory) simultaneous. When categories interact, they cause transitions. That could be something like addition, or it could be sending a value to the console. Wheeler may not be the future of languages, but if you’re interested in the edge of computer languages, you might want to try to wrap your head around it.
Where to next?
I hope this series of articles has given you an entertaining and educational glimpse of the possible future of computer languages. Although it’s unlikely any of the languages featured at the camp will soon supplant mainstream programming languages, their concepts may indeed gradually be integrated. Perhaps one of these fledgling languages may be perfect for your next project. Whether your goal is security and reliability, expressiveness and poetry, or somewhere in between, there are many paths to choose.