It’s a great time to be a language buff

I make no secret of the fact that I have a very strong interest in programming languages. So I was naturally very interested when news of the Go Programming Language hit the intertubes. Go is an interesting language. It pulls together some very powerful features with a familiar, but clean syntax and has lightning fast compile times. It certainly takes a place on my to-learn list along with Haskell and Scala. But even as Go becomes the latest hot piece of language news, it dawned on me that over the past few years we’ve seen a slew of interesting languages offering compelling alternatives to the industry “mainstream”.

I guess it all started with the rise of scripting languages like Python, PHP, Ruby and the poster boy of scripting: Perl. Personally, these languages with their dynamic typing, “batteries included” design and interesting syntax provided a breath of fresh air from the likes of C++ and Java. Not that C++ and Java are necessarily bad languages, but they aren’t the most interesting of modern languages. In the early years of this decade computers were just getting fast enough to write large scale software in scripting languages. Things have changed a lot since then.

Dynamic languages aren’t just reserved for small scripts. Software like Ruby on Rails has proved that you can write really robust back end infrastructure with them. The languages for their part have kept on growing, adding features and making changes that keep them interesting and downright fun to use. Python 3.0 was a brave decision to make a break from backwards compatibility in order to do interesting things and it goes to show that these languages are far from ossifying or degrading.

Then there is JavaScript which was supposed to die a slow death by attrition as web programmers moved to Flash or Silverlight. But we all know that didn’t happen. JavaScript has stayed in the background since the rise of Netscape, but it’s only recently with advances in browser technology and growing standards support that it has really come into its own. I’ve only played with it a little, but it’s a fun little language which makes me feel a lot of the same emotions I felt when discovering Python for the first time. Thanks to efforts like Rhino, you can even use JavaScript on the client side for non-web related programming.

Of course, if you want to do really interesting things with these languages, then performance is not optional. Within the last year or two there’s been a strong push in both academia and industry to find ways to make these languages faster and safer. Google in particular seems to be in the thick of it. Chrome’s V8 JavaScript engine is probably the fastest client side JavaScript environment and their still experimental Unladen Swallow project has already made headway in improving Python performance. V8 has already enabled some amazing projects and I’m waiting to see what Unladen Swallow will do.

While we’re on the topic of performance, mentioning the Java Virtual Machine isĀ  a must. The language itself seems to have fallen from grace lately, but the JVM is home to some of the most powerful compiler technology on the planet. It’s no wonder then that the JVM has become the target for a bunch of interesting languages. There are the ports of popular languages — JRuby, Jython and Rhino. But the more interesting ones are the JVM-centric ones. Scala is really interesting in that it was born of an academic research project but is becoming the strongest contender to Java’s position of premier JVM language. Clojure is another language that I don’t think many people saw coming. It brings the power of LISP to a modern JVM unleashing a wide range of possibilities. It has it’s detractors, but it’s certainly done a fair bit to make Lisp a well known name again.

Academia has always been a hot bed when it comes to language design. It’s produced wonders like Lisp and Prolog and is making waves again with creations like Haskell (whose goal is ostensibly to avoid popularity at all costs) and the ML group of languages. These powerful functional languages with wonderful type inference are a language aficionado’s dream come true in many ways and they still have years of innovation ahead of them.

Almost as a corollary to the theoretically grounded functional languages, systems languages have been getting some love too. D and now Go are both languages that acknowledge that C and C++ have both had their heyday and it’s time to realize that systems programming does not have to be synonymous with bit twiddling. D has gotten some flak recently for not evolving very cleanly over the last few years, but something is better than nothing. Also a real shift towards eliminating manual memory management is a welcome addition.

As someone who intends to seriously study language design and the related concepts in the years to come, it’s a really great time to be in getting involved in learning about languages. At the moment I’m trying to teach myself Common Lisp and I have a Scala book sitting on the shelf too. One fo these days, I plan on sitting down and making a little toy language to get used to the idea of creating a language. Till then, it’s going to be really interesting just watching how things work out in an increasingly multilingual world.

Is Bespin the 21st century text editor?

Integrated Development Environments are one of the primary tools of our trade. But personally I think an IDE can only be a good product if it has a robust text editing component. The king of text editors is Emacs. No offense to Vi users, but the Emacs + Elisp combo is unbeatable in my opinion, for a number of different reasons, programmability being the main one. Of course Emacs does have its problems. Steve Yegge discusses these problems quite thoroughly in his post on XEmacs. What’s interesting is that he claims that if Emacs doesn’t get its act together and fix its problems, it won’t be long before a browser sprouts enough editing capabilities to eclipse Emacs. I think that time is close at hand.

Enter Bespin. It’s a Mozilla project that is still under heavy development, but there’s a public demo already available. Bespin is an online text-editing environment written entirely in open source JavaScript. It’s provides syntaz highlighting and some project management and looks really slick by making use of the HTML5 canvas element. The best way to understand what Bespin can do would be to watch their introductory video:

It may not be immediately obvious what all the fuss is about if you’re used to using a modern IDE like Eclipse. After all, it’s just a text editor, right? Yes, it is just a text editor and that’s where the beauty of it lies. Firstly, t’s programmable in the Emacs tradition. That means that you are allowed and encouraged to write your own bits of JavaScript to adapt it to work the way you want to. Secondly, it’s sports an open server API which means that you could potentially use Bespin as an editor-like interface to anything you want. This has already led to Bespin running on top of the Eclipse IDE. Eclipse acts as the server and Bespin acts as the editor interface to it. Here’s a screenshot of Bespin+Eclipse in action showing Eclipse communicating errors in the Java code that Bespin is editing.

Keep in mind that Bespin is still in a very experimental stage. However, the example above is clear evidence that Bespin is going to be a force to reckon with in the IDE sphere soon enough. I think that bringing a client-server model to IDEs is going to offer a significant productivity improvement to programmers especially as developers and companies have to wrangle increasingly complex, heavy weight codebases.

Development machines need to be real monsters nowadays to efficiently handle the demands of the software being developed. Using Bespin, developers could invest in industrial strength servers which serve as both code repositories and build farms. The developer’s machine then act simply as terminals or can run local lightweight server instances for the Bespin frontends to connect to. This means that developers can afford having cheaper machines themselves, but don’t need to wait for long compile times as they’re being outsourced to the powerful servers. Code is also centrally stored meaning that it can be pulled up a moment’s notice and worked on collaboratively. This could mean more efficient workflows for software companies.

But the biggest win would be for the developers themselves. Here is how I can see myself using Bespin: I’d have a machine sitting in a safe, well connected location running a Bespin server. This would be my main development machine so I’d trick it out with as much RAM and processor speed as I could afford. The server itself might be some form of headless Eclipse or something equivalent for whatever language I happen to be progamming in. The cool thing is that since there is an implementation agnostic server API, I could even write my own server that lashes together compilers and build tools for whatever language I happen to be using and displays results via Bespin. The server would also use a version control system like Git seamlessly as part of the storage infrastructure. I could then connect to this server either from any modern browser meaning that I wouldn’t have to drag a machine with me to write some code. Anywhere hacking would be a boon for open source developers and students. I can also imagine a Github-like service that hosts both files and their development tools so that developers can avoid even running their own Bespin servers.

So is the age of always-available, online IDEs upon us? I think not quite yet. It’s still untested territory to a large degree. Bespin itself is coming along quite nicely and is implementing some very interesting ideas. But a lot is going to depend on how well the Bespin servers work. Headless Eclipse is fine for Java, but there needs to be similarly capable systems evolving for other languages and platforms as well. The API does a good job of keeping things minimal and implementation agnostic, but it also puts the onus on server developers to make quality systems targeting their respective platforms. I’m looking forward to some good work coming out of the Bespin and related projects in the near future. I’m even seriously considering learning some JavaScript so that I can better understand how the whole thing works. For the time being though I’ll stick to Emacs, though I’ll certainly keep an eye on the Bespin mailing list.