Emerging Languages: A Look at The Last Five Years

| by Sergio De Simone Follow 21 Followers on Oct 02, 2014. Estimated reading time: 4 minutes |

In a recent article, Alex Payne, organizer of the Emerging Languages Camp, provides insight on how the language landscape has changed in the last five years and how it might change in future. InfoQ has talked with him.

From his vantage viewpoint, Alex identifies three main criteria that help tell the recent story of language evolution and understand their future:

  • The importance of tooling.
  • Using virtual machines as "implementation strategy".
  • Language polyglotism.

As Alex recounts, when Go co-creator Rob Pike wrapped up his Emerging Languages talk in 2010, he was asked why he had shipped a language that "seemingly ignored the last 30+ years of programming language theory research." Sure enough, Go conservative character has not prevented its wide adoption, says Alex. At the other extreme, Scala "has struggled with tooling from its inception," thus making many Scala developers "swim back to the familiar shores of Java" or alternately to Clojure, Go, and Rust.

How do you explain that language adoption does not follow from its feature set?

I guess a succinct way of putting this is, “it doesn’t matter how feature-rich your language is if programming in it is unapproachable.” A number of my industry friends work in Clojure and ClojureScript. Clojure has a reputation for being a throughly modern language: functional, high-performance immutable data structures, support for “gradual typing” via core.typed, logic programming via core.logic, etc. It’s also notoriously difficult just get a working Clojure development environment up and running, and all the more so if you’re using ClojureScript. People have bundled up their Emacs configurations, written tutorials, offered project templates for the Leiningen build tool, developed IDE plugins, and more. Still, because the tooling around Clojure is largely community-provided, it’s a constant moving target, and last month’s build setup is unlikely to be working today if you’re keeping up with the latest libraries.
By contrast, the Go team ships practically all the tooling necessary to use the language productively, leaving the easier and less error-prone work of integration with specific tools up to the community. This means that it’s easier to gain actual experience in Go. Clojure is both harder to get set up with *and* likely unfamiliar in terms of language semantics and programming paradigms. Clojure has more to offer the programmer, but it’s hard to get productive with.

Why is tooling a weak point for many otherwise advanced languages?

Certainly, the more complicated the language, the harder it is to develop tools for. Tooling is also an afterthought for most language designers, though that seems to be changing. Really, I think it’s an issue of stewardship. As above, most languages leave their tools (editor support, package managers, linters, etc.) up to the community. Some third-party language tools will be good, and some will be bad; either way, they’re not held to any standard of quality or completeness by the language authors themselves. This lack of central planning also leads to poor coordination between the various projects necessary to provide a good developer experience.

Do we understand the value of tooling better today than we did five years ago?

I’m not sure. Microsoft and Apple have understood this perfectly well for many years now, and while the tools they provide aren’t perfect, they’ve clearly enabled a proliferation of software for their respective platforms.

This year's Emerging Languages Camp has broadened its focus on tooling. How did this work out?

Under the umbrella topic of "the future of programming," we encouraged presenters to submit talks about projects that improve the programming process at any level. We ended up with a number of tooling-related talks, including a Photoshop-like application for designing 3D shaders and a brilliant Eclipse plugin that offers code completion via dynamic analysis.
We’re not yet sure if we’ll maintain the same focus next year, but the event went well and attendees seemed to appreciate the tooling-oriented presentations.

What has been the value of using VMs as an “implementation strategy” for languages, as you say, and why this might not fit the bill anymore?

Back in 2008, I made a prediction that "VMs designed for high-level languages (ex: Java, Erlang, and JavaScript) were going to flourish as host platforms for higher-level languages." This prediction has been confirmed by the birth and success of languages such as Clojure, CoffeeScript, and Scala, but the VM as implementation strategy is starting to show its limits. This can be seen in the diminishing interest in CoffeeScript, as well as in Scala being set aside for Java, and even in Clojure community periodic noises of longing regarding a port to LLVM.
If I’m being held to another prediction, it’s that the languages five years from now will be untethered by a host VM, like Rust, Julia, and Go are. The low-power, high-connectivity Internet of Things world we’re moving towards leaves far less room for fat VMs.

You wrote that it is now almost common sense to assume a certain degree of polyglotism in professional developers. Why is this important?

As long as we have heterogenous networked systems, we’ll have programming language polyglotism. Most software developed today interacts with a network. That typically entails a client/server architecture. Differing technologies have “won” the client and server, respectively (with the tenuous exception of JavaScript). This necessitates some degree of polyglotism.
Even modern front-end web development can be a polyglot affair, meshing markup, templating, and styling languages with multiple dialects of JavaScript. There have been attempts to unify all this, but most developers seem content to work in several specialized languages.

Since 2010, the Emerging Languages Camp has aimed at bringing together programming language creators, researchers, and enthusiasts aiming at advancing the state of the art in programming languages. This year's conference took place on September 17, 2014 in St. Louis.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

clojure tooling by h w

Cursive Clojure for Intellij is a leap forwards in tooling in many ways but especially for people coming from Java. For my work an IDE that also has great Java support is a must because we still have a lot of that around... which is why we havent looked at Light-table too much. Although for other Clojure users that is also a serious alternative to Emacs. Not that Emacs is lacking or as unstable as the article suggests, but for people coming to the language and who dont know Emacs already, it is another hurdle.

Not great by N T

This article is kind of shallow. When you read that Scala "has no tooling", when it is the most contributed to language in Github, Stackoverflow, etc. with IDE support in Eclipse, Netbeans, IntelliJ, SublimeText, etc. well what can I say. And so many people abandoning it, oh dear, the only reference being 1 (one!) article from 2011. And FTSE 50 companies now are using it but the article says disgruntled developers switch "to Clojure and Go", well yeah, right!!!!

It’s also notoriously difficult just get a working Clojure development environment up and running by Dmitri Sotnikov

That's certainly not the case in 2014. You need to install Leiningen to create and build projects, and all you need to get a Clojure development environment running is to download Light Table and open a project created with Leiningen. Light Table also provides a ClojureScript REPL, so there's no additional work required there either.

Alternatively, you can grab IntelliJ and the Cursive plugin. You can now open any project created with Leiningen, and everything works out of the box including some support for core.typed. Eclipse Users can use the Counterclockwise plugin to setup their Clojure development environment.

Both IntelliJ and Eclipse have full Leiningen integration and will automatically resolve dependencies and project setting from the project.clj file.

The idea that you have to use Emacs to develop Clojure is simply false.

Re: Not great by Sergio De Simone

You are certainly right in saying that Scala tooling has improved over the years and that Scala is still a great and thriving language. On the other hand, it was not the purpose of this article to bash on Scala or define its value as a development environment. Simply put, one of the interviewee's arguments is that tooling is important for a language success. The fact that a few years ago, when Scala tooling was possibly not that good, some developers were reportedly going back to Java is simply a point in case, not to be taken as a critique to where the language stands now or will stand in the near future. Thanks for your comment anyway.

Re: It’s also notoriously difficult just get a working Clojure development by Sergio De Simone

Hi Dmitri, thanks for your comments. As far as I understand Alex's comment on Clojure, he is not saying that tooling is not available: he mentions Emacs, but also "tutorials, [offered] project templates for the Leiningen build tool, developed IDE plugins, and more." So, this is not the trouble. Alex's point is that a setup can be easily broken (what could be fixed by updating your plugins or scripts or whatever) "if you’re keeping up with the latest libraries." This could even be no issue at all in many cases, still I think Alex's view should be seen in its positive aspect of remarking the importance and the necessity of tooling providing some examples to make the concept clearer. Thanks for your contribution anyway, it will help anyone that is left with the idea that no tooling is there for Clojure to investigate IntelliJ and the Cursive plugin and the rest of things you mentioned.

Re: It’s also notoriously difficult just get a working Clojure development by Dmitri Sotnikov

I very much disagree that there is anything fragile about Clojure tooling. In fact, my experience is that Clojure has a far better story than most languages I've worked with in this department.

Since the community has converged on Leiningen as the de facto build tool every Clojure editor is built around it. This provides a consistent experience in terms of managing the project lifecycle regardless of the editor you're using.

This also makes it much easier to work with different projects since they all use the same build environment. On the other hand if you're working with a language like Java you might have to deal with Maven, Ivy, Gradle, Ant and so on depending on a project.

While Alex has a valid point regarding the importance of tooling, his comments regarding Clojure tooling are flat out wrong.

Re: It’s also notoriously difficult just get a working Clojure development by David Smith

I have to agree with Dmitri on this, Clojure is definitely the easiest development environment to get up and running that I have used. Leiningen is definitely the best build tool I've used. I've also never previously heard or read anyone saying that it is hard to get up and running. I have only been using it for the last year so I can only presume that in 2010 it was "notoriously difficult just get a working Clojure development environment up and running".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss