Parsing signals from the Emerging Languages Camp

From concurrency to communications: A look at the concepts shaping new programming languages.

The two-day “Emerging Languages Camp,” held in a side room away from the main conference rooms of OSCON, was a surprisingly diplomatic and cooperative meeting of the minds. In all, more than 25 languages — plus ancillary topics — were presented by their respective designers. Although I was mentally saturated by the end of the camp (I seemed to have lost the ability to speak clearly or spell!), I was pleased to see so much progress in the field of computer languages, and I was motivated to experiment with some of the implementations that grabbed me.

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:

tags: , , ,

Get the O’Reilly Programming Newsletter

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

  • Greg Wilson

    What’s missing from your list, but desperately needed, is systematic evaluation of languages’ strengths, weaknesses, usability, and actual (as opposed to touted) impact on performance. Despite some prejudices to the contrary, it is possible to do this—see for example Prechelt’s recent Plat_Forms paper (Communications of the ACM, August 2010, http://doi.acm.org/10.1145/1787234.1787271), or the PLATEAU workshop series (http://ecs.victoria.ac.nz/Events/PLATEAU/WebHome). I’d personally like a moratorium on hype about new languages until their creators agree on ways for the rest of us to tell whether they’re actually making things better or not…

  • Sam Penrose

    “Syntax is only the skin” would be news to Guido van Rossum, who credits usability testing for much of Python’s success. Also to Larry Wall, for very different reasons.

  • John Labovitz

    Thanks for your comments.

    @Greg: I agree that performance is important. But sometimes focusing on usability and expressiveness leads to new platforms, which leads to new uses of technology that sometimes can’t be seen from where we were before. For example, the Ruby on Rails project pushed web application development, and therefore websites themselves, into a new realm. Although Ruby/Rails got a lot of flack for being “slow,” those issues have been solved in different ways.

    @Sam: Sorry for being flippant about the “skin” metaphor. I didn’t mean that syntax wasn’t important. My point was that even with the most appropriate syntax, if the language’s runtime is primitive or inflexible, all the benefits of good syntax won’t help. This is an issue with the ‘safe’ computing models I mentioned in my second article: a compiler can only catch certain errors; others need to be guarded against in the language’s runtime.

    –John

  • Greg Wilson

    @John By “impact on performance” I meant “impact on *programmer* performance”, not raw machine performance—that’s what the paper and workshop I referenced are talking about.

  • Dean Wampler

    Concerning C and C++ as influences, four of the “systems” languages (Rob Pike’s term) that were discussed, Go, BitC, D, and ooc, were inspired by C and C++, but they also try to fix the perceived problems in those languages as much as leverage their strengths. Since most of the world’s software is embedded/systems code, the potential impact of these C/C++ replacements could be great, and also greatly needed.

  • http://z-bo.tumblr.com John "Z-Bo" Zabroski

    This is an interesting write-up in that you give a high-level overview of the EL camp. But, where are your examples to backup your generalities for those of us who were not there? e.g. what languages best demonstrated each of the themes. This would then encourage us to view the videos online in a different order than the ones they were presented in, by grouping ideas together that we are intersted in.

    I am just saying.