Poetry of code

New expressive languages pursue simplicity, consistency and play.

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.

The formal influence of Lisp and Ruby (and Smalltalk and Python to a smaller degree) was clearly seen at the Emerging Languages Camp. Many of the languages do away with the excessive punctuation of languages like C++, Java, and Perl, opting instead for minimal syntax and keywords, valuing whitespace, and using punctuation only when needed. CoffeeScript was one of the more impressive examples, wrapping the often-verbose JavaScript in a simplified, terse yet understandable syntax.

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.)

Instead of the strict tradition of object-oriented languages with their careful hierarchy of abstract classes, many expressive languages discussed at the camp adopted the model of prototypes, first developed in Self. Prototypes tend to lead to a flatter, almost peer-to-peer world of objects. CoffeeScript adds prototypes to JavaScript, while Finch, Io, Ioke, and Trylon are more general-purpose prototype-based languages.

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.

Related:

tags: , , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Paul Topping

    You mentioned that the implementation of a domain–specific Language (DSL) might return a tree of internal syntax. This reminded me of the Parrot project (www.parrot.org) which describes itself as:

    Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages.

    It contains tools that support this approach. One can define a DSL that produces an intermediate form that is pretty much a parse tree and from there into instructions for a virtual machine. This allows the DSL designer to take advantage of modern interpreter techniques for good performance with a minimum of effort.

    I am not a Parrot person so others may do a better job than I of describing this.

  • Nathan Youngman

    Thanks for the excellent review of OSCON/Emerging Languages Camp (for those of us who didn’t make it out).

    One errata of note: JavaScript already has prototypes, yes? Though CoffeeScript definitely looks impressive.

  • bowerbird

    observe yet another occasion where “poetry” is used to signify
    grace and beauty as an adjective that’s applied to other things,
    even though poetry _itself_ still garners very little respect…

    -bowerbird