In my last post, I posited that emerging languages 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 cover the practical side of things in this post. Beauty and expression will be addressed later this week.
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.
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.