Nu, Clojure and the future of Mac Development
Clojure is a lisp like language built on top of the Java virtual machine. It lets you interact with and use existing Java libraries. Nu is a lisp like language built on top of the Objective-C runtime, which gives easy interaction with the Cocoa libraries. On the surface it then seem very similar. However they are radically different. Mostly because their goal and reason for existance is radically different.
Clojure is an attempt at creating a modern new language with emphasis on concurrent programming, functional programming and ability to use the vast selection of Java libraries. It is supposed to be able to stand on its own feet. It is efficient enought to write large programs entierly in it.
Nu on the other hand is a fairly slow interpreted language. There is no special emphasis on things like concurrency or functional programming. On the face of it Nu then sounds inferior and quite worthless. But concluding that means misunderstanding its intentions. Nu is meant to help you write Objective-C programs. It is a glue and prototyping language. The idea is that you prototype a program in it or glue together different Objective-C components to create a program. This is the reason why Nu is not as much like lisp as Clojure. It is a lot closer to scripting languages like ruby. Where Nu shines compared to traditional scripting languages like perl, python and ruby is that integration with C libraries is trivial. All you have to do is to provide a Objective-C wrapper around your C library, which is easy, because Objective-C mixes freely with C. Nu uses the same object model and runtime as Objective-C so it can instantly interact with Objective-C objects.
Nu can use a tool called nubake which will translate Nu code into Objective-C. This allows you to quickly start rewriting Nu code into Objective-C code. Generated Objective-C code is obviously not very efficient, so you will have to do some hand coding, but it does away with a lot of tedious translation work. This way you can start writing a program in Nu and then use nubake to translate and optimize portions of your code into Objective-C where it is slow. So while Clojure is meant to be used for the whole program, Nu is always meant to be used in tandem with Objective-C. That is why performance is not so critical for Nu.
Nu in the grand scheme of things
Nu reminds me of the Genie and Vala programming languages targeting the GNOME object model. Rather than binding Python and C# to Gtk+ directly they have chosen to create to language that look like Python and C# but which integrated tightly with the Gnome object model and compiles to C code rather than bytecode. Because Objective-C is dynamic unlike C, Nu can run directly without compiling to C or Objective-C. It just needs to send messages to the Objective-C runtime. But all 3 languages represent and alternative to using a Virtual Machine or Common Language Runtime. I think this is the only path that Apple can go down with its development environment. Creating something similar to .NET is unthinkable. It is a huge undertaking and Apple is too far behind to compete with established platforms like Java and .NET. But Cocoa is a very well designed framework and the Objective-C runtime allows fairly easy interaction with other dynamic languages. Microsoft was never in such a fortunate position. Creating a COM object was far more complicated than creating an Objective-C class. That made .NET more of a necessity.
Apple is more likely to build on the Objective-C runtime in similar fashion to Nu and MacRuby. MacRuby is built on top of the Objective-C runtime but uses LLVM to generate code. So it can be precompiled or JITed unlike Nu. My prediction is that if Apple has a new more modern language in the works for rapid application development on Mac, it will be based on LLVM and the Objective-C runtime like MacRuby, but will take the same approach as Nu in that it will be designed from the groundup to work with Objective-C and complement it. Here are some things I think will be features in such a language:
- It will basically be dynamic like Objective-C but with better support for static typing when desired.
- Strong support for concurrency programming like Go, Erlang and Clojure but built on top of Grand Cental Dispatch.
- JITed on LLVM
- Type inference when using static typing
- Native support for Closures, based on blocks as used in Grand Cental Dispatch
- Smalltalk or Objective-C like syntax in that arguments will be named. The reason being interaction with the Cocoa API which is awkward without similar syntax.
- Garbage collection as standard, not as an option
- The beginnings of some higher level abstraction on top of LLVM to allow interaction between multiple languages built on top of that abstraction beyond message passing compatible with the Objective-C runtime.
I don’t think it will contain any revolutionary new features we haven’t seen before but it will follow the general software trend towards concurrency, more functional programming and ability to write shorter more succint code as we have seen in script languages like Ruby and Python an which has recently been copied by Go. There isn’t really any reason why Nu couldn’t morph into something like this but I think Apple will go for a more traditional syntax and more ephasis on static typing to cater more towards what the majority of programmers seem to want.
I think if Apple does this, they wont be in a disadvantage compared to Microsoft with respect to development environment. And they should to this while people are willing to learn Apple technologies to get onto iPhone development.