There's a lot of material about Lisp online, especially covering major dialects like Common Lisp and Scheme. Since Nu isn't based on either, we have to go back to the roots of Lisp for inspiration.
(By the way, did you know that by the time Common Lisp was standardized, Objective-C had been around for 8 years?)
Here are the online resources that I find most useful.
Paul Graham on What Makes Lisp Different. Nu probably has too much C in it for Paul's tastes, but by his definition, it's still a dialect of Lisp. With the exception of garbage collection, Nu has every feature on his list.
One of my first goals in bootstrapping Nu was to get it to run a Lisp interpreter as Paul described it in his Roots of Lisp article.
John McCarthy's History of Lisp is informative and inspiring. Considering the resources available in Lisp's early days vs. now, McCarthy's achievement is both brilliant and compelling.
Of all the dialects I've encountered, Alexander Burger's Pico Lisp is the most inspiring to me, because he took McCarthy's implicit challenge and built his own personal Lisp, which he has used successfully for nearly 20 years. Pico Lisp is also much like Nu in its pragmatic orientation towards C.
Last August, Perry Metzger announced another new Lisp dialect that he calls Otter. He described it at the New York City Lisp Users Group. No release is available yet. From what I've seen, it's a lot different from Nu, but he looks like a fun neighbor.
Along with Alexander Burger, another winner in the "at least he released it" category is Lutz Mueller's newLISP. I've only looked at it a little, but it looks like it's been around a while and has grown quite stable. Lisp purists don't seem to like it, but they probably won't like Nu either. newLISP has a lot of useful libraries: PCRE for regular expressions, networking, XML parsing, and database support. That's really cool, but I think recycling is better: I got all of that for free by building Nu on Objective-C.
Paul Graham has a high-profile dialect called Arc. A preliminary version was released in early 2008. It appears to be aimed at web applications and language aesthetes. Although a foreign function interface is in the works for Arc, its use seems to be an option of last resort. That won't be a problem as soon as enough operating systems, databases, application frameworks, device drivers, network interfaces, and graphics libraries are rewritten in Arc. Until then, I think that a good FFI should be a top priority (are you getting tired of "C over lambda"?).
Here is another lightweight Lisp interpreter in Objective-C by David Phillip Oster. His implementation is very clear and light; in several ways, it looks a lot like early versions of Nu.
Clojure is a Lisp written on the JVM by Rich Hickey. Like Nu, Clojure combines the high-level power of Lisp with the low-level practicality of a system programming language. Clojure is dynamically compiled to JVM bytecode and as Rich explains:
bq. Clojure is well integrated with Java. Clojure functions can be called from Java, with f.invoke(args), just like any Java code. All Clojure data types are defined in terms of Java interfaces, and implement the corresponding standard Java interface where available, i.e. Clojure collections implement java.util.Collection, and thus can be passed directly to Java methods without conversion. You can implement Java interfaces from Clojure.
Clojure's emphasis is on functional programming, so it is not as tightly integrated with the Java object model as Nu is with that of Objective-C. Messages to Java classes require a special operator, and there doesn't seem to be a way to subclass Java objects or implement their methods directly in Clojure.
But Clojure comes with a lot of other interesting features: a sophisticated macro system, optional static typing, and special constructs for multithreaded evaluation. There's always more to learn, and besides being a great tool for JVM users, Clojure is a rich (Rich?) source of ideas for improvements to Nu.
Why Lisp? Why Nu?
- A friend recently pointed me to Carl de Marcken's notes about the use of Lisp to run Orbitz. They give an interesting picture of a pragmatic mixture of Lisp and C++ that builds on the strengths of both. Notably, this advanced use of Lisp eschews many advanced Lisp features. Instead, the Orbitz software was built on a simple and easily characterizable subset that integrated well with C++ and that could be easily controlled by the Orbitz developers. Here are two key quotes. First, "We disassemble most every Lisp function looking for inefficiencies and have had both CMUCL and Franz enhanced to compile our code better." In other words, a serious use of Lisp requires a detailed control of what that Lisp is doing. Second, on the same topic:
We've had very little trouble getting non-Lisp programmers to read and understand and extend our Lisp code. The only real problem is that the training most programmers have in Lisp has taught them to code very inefficiently, without paying any attention to the compiler. Of course, with things like STL and Java, I think programmers of other languages are also becoming pretty ignorant.