The Erlang Paradox

There has been a nice series of interviews with the creators of various programming languages. In this one, it’s Joe Armstrong‘s turn. The creator of Erlang, he’s a very bright guy and well worth reading. One thing that has always struck me as interesting about Erlang, as compared to most of the “open source” style languages I’ve tended to use, is how it was incubated for a long time within Ericsson. It spent years there, and millions of lines of code were put into production use, prior to being open sourced, and certainly before the world at large took much notice of it.

This has been both good and bad for the language. The obvious upside is that a lot of smart people were paid to work on and improve it. Many new languages don’t really get that opportunity, unless they come out of an academic environment. Rather than being a spare time project, or something that slowly builds up speed over the years, Erlang, as far as the rest of the world was concerned, burst forth from Joe’s forehead, fully formed. This is not something like Ruby, where the early adapters were small companies like 37 signals, willing to live on the edge and not follow the pack. Quite the contrary, Erlang was backed by a huge, established player in the telecom market, focused particularly on applications where reliability is paramount. Certainly not a language you can call a ‘toy’!

The downside to all this, though, is that, esentially, they can’t really change the language much without being very, very careful. Here’s what Joe says about what he might have done differently:

Looking back, is there anything you would change in the language’s development?

Removing stuff turns out to be painfully difficult. It’s really easy to add features to a language, but almost impossibly difficult to remove things. In the early days we would happily add things to the language and remove them if they were a bad idea. Now removing things is almost impossible.

The main problem here is testing, we have systems with literally millions of lines of code and testing them takes a long time, so we can only make backwards compatible changes.

Some things we added to the language were with hindsight not so brilliant. I’d happily remove macros, include files, and the way we handle records. I’d also add mechanism to allow the language itself to evolve.

Which is an interesting contrast to more “traditional” open source languages like Ruby and Python, which, over the years, have from time to time bitten the bullet and unloaded stuff they don’t like. On the other hand, Erlang is solid code that you can count on if you do need to write systems with little to no downtime.

What do you think of the two approaches?

Swap Desktops

This weekend’s hacking efforts:

What it does:

I like to have my “workspace” in virtual desktop 1, where I have 3 emacs windows, and 4 urxvt windows (bash shells). Sometimes, however, it’s a bit of a pain to swap back and forth between client work and DedaSys work. One obvious approach is to replicate the window setup in a different virtual desktop. However, I’m used to having everything “just so”, so that I can quickly move to the desktop south of the main one to have my browser, east to get to the shells that connect to host things run on, and so on. And if I put my ‘local’ workspace on a different virtual desktop, it would screw all that up, so I wrote the above code. It utilizes the wmctl program to swap virtual desktop N with virtual desktop M, meaning it takes all windows from N, and puts them on M, and all the windows from M and puts them on N. If I have a bit more time, perhaps I’ll take a stab at the C code in wmctl and add a new option to swap virtual desktops.

Android Scripting

This is cool to see, even though it will doubtless take away some market share from Hecl:

http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html

Importantly, I think it helps to establish that Android is the phone OS for those who want to be able to hack on stuff. With the Apple phones, you’re not supposed to even run interpreters on them. Yuck.

In any case, I think that it still leaves some space for Hecl:

  • Their system uses natively compiled languages that use a JSON RPC system to talk. This makes managing them a bit trickier – Hecl is written entirely in Java and compiled as a ‘native’ Android application.

  • Hecl is very easy to embed, and doesn’t carry around a lot of baggage.

  • Hecl is small – apparently this system clocks in at something like 12 megs! Hecl is something like 500K.

Another cool thing is that this is, like most everything that Google has done with Android, open source under the Apache license (the same one as Hecl), which means that if I get a free moment, I’ll try grabbing some of their console code and integrating it to make a nice Hecl console for Android.