Choosing a new programming language

Last year I released LambdaBeans 1.0RC, an IDE for the Scheme programming language based on the NetBeans Platform.

During this last year I have been silently working on an implementation of Scheme hosted on the Java Virtual Machine, based on a simple Tail Recursive SECD Machine (yes, I admit a CEK Machine would be a better choice, but I do like the SECD machine instead). My intent was to create a Scheme implementation that I could understand fully, and that I could integrate with the LambdaBeans IDE to perform things such as step-by-step debugging (which is currently difficult in many Scheme implementations) and profiling running code (which is impossible in many Scheme implementations).

This internal project of mine has been lots of fun, as I've gained a deeper understanding of closures, I've appreciated the full benefits of tail recursion and I've understood what continuations really mean (and how they relate to the J Combinator).

I've also learned about continuation passing style (which I don't like, by the way), denotational, operational and axiomatic semantics.

So to summarize: I've learned lots of new things about programming language features, and I've enjoyed myself a lot during this last year.

On the future of Scheme

As you may know the Scheme programming language is standardized by a commitee of experts. The last formal standard of Scheme is The Revised^6 Report on the Algorithmic Language Scheme. It seems R6RS gained little adoption and fragmented the Scheme community, so the Scheme Committee revamped a new standardization effort to produce a new version of the report. There're two working groups doing that. The first working group is working to produce a smaller Scheme standard, focused in the core of the programming language. You can go read what they're up to here.

The goals of the working group are to define a new standard based on the different implementations of Scheme available out there. This is all great and whatever, but there's no room for improvement. No room for new ideas and no room for improvement. This is not a fault of the working group, of course, but an inherent consequence of the goals of standardization.

The problem with this approach, as I see it, is that the standard is fuelled by the number of existing implementations, and the lower the number of implementations becomes the smaller the standard gets. As a Scheme user I'm comdemned to a smaller standard, unless someone builds a Scheme implementation that breaks the existing status quo, including features such as first class environments, as proposed by Tom Lord that then was invited to quit the working group.

And, you know what? Enough is enough: I won't spend any more time creating a Scheme implementation on top of the JVM. All I can say is that I wish Scheme a great future, I appreciate all I've learned with it but I fear I should move somewhere else. It's 2010, and parallel execution, multicore, and embedded devices are targets too difficult to tackle with Scheme.

So it's time to move somewhere else. It's time to discover the joy of Scheme in another programming language. So, what are the choices?

On Clojure

The Clojure programming language seems a great choice indeed for moving away from Scheme. It's syntax is quite similar, and it's very fast and has lots of cool features I miss in Scheme, including immutability (a great feature if you plan to run in parallel), software transactional memory support, metadata and a huge library (as you can access all Java libraries out there).

The only problems I can see with Clojure is that it doesn't support tail call optimization (well, not at least fully) and that it's hosted in the JVM, so embedding in small devices is a problem.

Another problem I see with it is that it's not GPL compatible, so I can't bundle it with my GPL source code (and so I'd had to make my users download and install it separately).

On Lua

I've also considered the Lua Programming Language. After some research it seems to me that Lua is a great choice. Here're some reasons why:

  • It's very small. The whole codebase is around 200Kb. Lua VM is about 1Mb.
  • It's included in the package repository of my favourite operating system.
  • It's embeddable, so I can build applications for Nokia or Palm devices, for instance. (See a list of examples).
  • No problems with tail recursion.
  • First class functions.
  • Has full access to C level, so I won't have to fight Java's IEEE-754 floating point implementation, wich is completely broken (as it doesn't support custom round modes and so makes implementing interval arithmetic either impossible or a pain in the neck using BigDecimals).
  • Tables: a great way to define prototypes (aka classes) quickly. Similar to JavaScript stuff.
  • Runs as a very tiny register based machine.
  • Has a spiffy Just in Time Compiler.
  • Has a great community!
  • Has a GPL compatible license.
  • Has a very simple syntax.
  • Can be accessed from Java

Enough for me. From now on I'll be learning Lua and, of course, I'll be building a full fledged Lua IDE on top of the NetBeans Platform.

So expect to see lua-specific entries more often here, as I learn the language, and also more entries about Lua and the NetBeans Platform.

Happy Lua-ing meanwhile,


blog comments powered by Disqus