New languages get pragmatic

Safety and reliability are hallmarks of many upstart programming languages.

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.

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:

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • David Emery

    Designing new languages is fun, but it seems we should start with some assessment of what’s wrong with our existing set of languages.

    There are a lot of less popular languages that address these kinds of concerns very well. It would be interesting to see what’s deficient with languages like Eiffel or Ada95/Ada05, if nothing else to understand where we’ve been.

    And this discussion should include the ability to produce correct and optimizing compilers, as well as human usability.

    Just to put a stake in the ground, I think that C syntax should -finally- be abandoned for something less human-hostile/error prone.

  • John Labovitz

    Thanks for your comment, David.

    I should point out that most language designers who presented at the camp actually did state why they had felt that creating a new language was better than using an existing one. They weren’t (mostly) just doing it for “fun.” The majority of the presenters seemed to have a good grasp of language history. And much like a “musician’s musician,” there were definitely influential languages that are fairly obscure outside of the language-designers camp. (In fact, I think Eiffel came up a couple of times.)

    Regarding compilers: The designer of the D language (which I mentioned briefly) apparently has a great deal of experience writing fast and optimizing compilers, and did express that a good compiler was an essential part of a language.

  • http://www.dynamicalsoftware.com Glenn

    I’m surprised that you missed the third category for emerging languages that could easily have the most promise to it. Embedding domain specific programming languages in other applications is an easy way to enable new work flows and expand the usefulness of just about any application. Technologies such as ANTLR ( see my review of this parser generator over at http://www.dynamicalsoftware.com/java/server/antlr ) go a long way towards making the benefits of compiler theory accessible to just about any coder.