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:

• New languages get pragmatic
• Parsing signals from the Emerging Languages Camp
• The next wave of programming languages
• Rob Pike on how and why Google’s new Go language was developed.
• Alex Payne on Scala and emerging languages

As any programmer knows, all software has bugs. With design flaws, interface misunderstandings, inefficiencies, or typos, we put our software out in the world knowing that it will someday fail. Improving our engineering methodologies helps (for example, unit testing). However, often the core problem is not in how we architect or implement a system, but rather the quality of our tools. A language — its syntax/grammar, compiler, and associated runtime — that minimizes or avoids errors is seen as a significant benefit, and so research into safety and reliability is a major effort in emerging languages.

In emphasizing the “safety” of a language, common qualities are described: secure, strict, predictable, guaranteed, reliable, correct, performant. There is a sensibility of pragmatism and tradition, a working style midway between a mechanic and an academic. Jonathan Shapiro, in his Emerging Languages Camp talk on BitC, described the “human comprehension zone,” beyond which languages and code become difficult to understand, and therefore more likely to contain errors.

Through occasional unification of earlier systems, gathered complexity is sloughed off, leading (in theory) to a simpler and therefore safer system. The Io, Ioke, and Trylon languages replace the usual built-in keywords, statements, and expressions with a very simple message-passing mechanism. Everything else is built above that. Interestingly, simplicity also comes up as a major value in expressive languages.

One area under great consideration in language circles is the general interaction of code and data. While encapsulation and similar concepts have helped structure the interaction of objects in a process, errors can still easily occur. The last wave of dynamic languages popularized open class systems, metaprogramming, and reflection. Ironically, these are now seen as potential problems by those concerned with safety and security.

The concepts of “type safety” (in Ioke among others) and “object capabilities” guarantee that one object cannot sabotage another. In order to limit an object to reach only what it’s given access to, several languages have renounced global variables. Some even restrict access to a class hierarchy, preferring prototypes or factory methods on allowed objects.

Newspeak lacks both traditional references or pointers, instead using names to resolve related objects only when needed. Through “mirrors,” Newspeak allows an object to specify what other objects can see from the outside. At the camp, Jonathan Edwards presented a fascinating glimpse at a possible future with his ideas on “declarative objects”: objects not all piled together in a heap of memory, but carefully contained and accessible only within other related objects, or through model-view data flows. Ur/Web is a domain-specific language for web programming that isolates interacting modules, avoiding many common errors. Even within web scripting environments there is progress. The Caja language implements the object capability security architecture as a layer over JavaScript.

Another area of development is a reconsideration of concurrency. Rob Pike lauded Communicating Sequential Processes (CSP), a model of concurrency invented in 1978. CSP is somewhat like Unix pipes, but formalized into a language that avoids memory sharing, threads, and mutexes. Go implements the principles of CSP as co-routines that communicate by sending objects over channels. Stratified JavaScript implements a similar model by extending JavaScript, avoiding synchronization problems in web programming.

Functional languages have long been considered relatively “safe,” and that field’s concepts have been borrowed by several emerging languages. In Seph, everything is immutable. In D, an imperative OO-based language for systems programming, data can be declared as immutable, while functions declared as “pure” can only access immutable data, and have no side effects. One of the more interesting presentations was the persistent data structures of Clojure, in which values are not traditional variables but rather states over time of a versioned tree structure.

Safety means predictability and reliability. As one of the more extreme examples, the BitC language is for writing critical code in resource-constrained systems that are designed to work for decades: a pacemaker, for example. Traditional embedded languages like C are unsuitable for their lack of safety features, as are modern mechanisms like JIT (just-in-time) compiling that introduce unpredictability. In a different domain, AmbientTalk is designed for implementing applications on mobile ad hoc networks. Because mobile devices often lose connectivity, the language assumes failures are common, and avoids blocking or exceptions.

Even basic data structures are reconsidered. Both Ioke and Frink criticized the common floating-point types misused by many programmers, instead preferring either arbitrary-precision floating point provided by “big decimals,” or rational numbers. Frink’s designer, Alan Eliasen, additionally gave an overview of intervals, a number representing a range of values, and the arithmetic that can be done with them.

Finally, some presenters positioned their languages as a possible base for higher-level expressive languages. By building expressiveness on top of safety, the best of both worlds might be attained. Although Go is a language in its own standing, its designer expressed interest in having the language used as a safe and powerful runtime. The Parrot VM (now being redesigned as Lorito) is specifically targeted toward dynamic languages like Perl, Python, and Ruby.

In the next post, I’ll cover the expressive side of the language spectrum.

Related:

• Parsing signals from the Emerging Languages Camp
• The next wave of programming languages
• Rob Pike on how and why Google’s new Go language was developed.
• Alex Payne on Scala and emerging languages

Over the course of this week, I’ll be examining the camp’s larger themes and trends.

Steps to language evolution

The differences between computer languages are often seen from the view of syntax and form. Yet syntax is only the skin of a language. Today’s programmers build their software on an evolutionary ladder of concepts whose steps were radical only a decade or two ago: garbage collection instead of manual memory management, object-oriented (OO) programming instead of procedural programming, and virtual machines instead of CPU-specific executable code.

The last wave of new languages popularized concepts that are still being integrated: interpreted code (vs. compiled), functional style (vs. imperative), dynamic typing (vs. static), Unicode support, closures (aka continuations, anonymous functions, lambdas), and list comprehension.

The important factor in this evolution is not the invention of a concept, nor its implementation as a library or freely available source code, but rather that the concept has been built into the language as a first-class citizen — both runtime and syntax.

Emerging languages are looking farther into the future. Most languages presented during the camp integrated all of the above concepts. But new concepts appear regularly in the languages, and I reckon their repeated presence indicates their likelihood of being taken for granted in a decade or so.

Oft-noted concepts addressed at the camp included:

• Map/reduce — Taking a set of data, possibly transforming it (the map step), and finally computing a summarized result (the reduce step). Often applied to in-memory lists of data, but can be applied to objects residing in a database or even distributed among several computers.
• Concurrency — Fundamentally, doing more than one thing at once. Difficult to make work reliably in an ad-hoc manner, resulting in many solutions over the years (for example, Pthreads). New languages are going back to basics and implementing mathematically provable concurrency models.
• Communications — With nearly every application being network-aware, building communication methods into a language leads to easier programming, better reliability, and implementation of other emerging concepts like concurrency.
• Reordering the object universe — Although the object-oriented style has clearly proved popular, its potential complexity and fragility has caused some to reconsider its openness. Architectural models are being developed to control access and change of objects, even within a single process.
• Code reloading — A movement away from the current monolithic model where a change in a program requires a complete shutdown and reload of code, state, and data. Dynamic reloading would allow small changes to be loaded into running programs.
• Program structure/execution visualization — Moving beyond the traditional debugging model, into real-time inspection of stacks and data structures.
• Language extension — The ability to extend a language not just by adding classes/methods or functions, but through adding new keywords or operators. Domain-specific languages are a related concept.

Legacy of languages: influence over application

In the long view, a language may turn out to be important not for its particular application, but for its influence. Many of the camp presenters were quick to point out their influences and inspirations.

One might assume a single progenitor at the top of this tree, but it turns out to be a sort of holy trinity of computer languages: Lisp, ALGOL/Simula, and Smalltalk. The particular ancestor depended on the particular emerging language. Lisp-inspired languages in the functional style; Smalltalk in the OO style; and while Algol/Simula were actually not mentioned by name, I argue that Java (and Pascal and C++ before it) is the contemporary descendent of those 1960s-era languages.

Smalltalk was a direct influence on several languages that took its method-passing syntax quite literally, sometimes updating it with Erlang’s messaging/concurrency model.

Interestingly, C and C++ rarely appeared as an influence in any of the emerging languages. The lack of C’s influence was less surprising than C++. After all, it has been many years since C was a high-level language, and its elder years has found it as the language of choice for bare-metal applications like device drivers, kernels, and embedded systems. In these applications, C++ may fill in for a slightly higher-level systems programming language — but its influence is clearing waning, with its place taken firmly by Java.

Java seems influential primarily for its context and conventions. Many programmers learned Java as the default language in school, and now work in environments where Java is the primary (and sometimes only) language. A language designer who is trying to better Java must realize that the way to the Java programmer’s (and committee’s) heart is not through radical syntax, incompatible libraries, or novel runtimes, but through comfort and familiarity.

Ruby was mentioned surprisingly often during the camp. It may end up a part of the language canon not because it is perfect or particularly innovative, but because it is both expressive and useful.

More to come

When viewed from a high enough level, the emerging languages presented during the camp fell generally into two categories: the languages that solve problems of reliability, safety, and correctness, and the languages that enable beauty and expressiveness. I’ll discuss these themes in two upcoming posts later this week.

Related:

• The next wave of programming languages
• Rob Pike on how and why Google’s new Go language was developed.
• Alex Payne on Scala and emerging languages