"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."
If you're interested in "getting" Lisp here is an interesting attempt to describe it in terms of XML. Not a bad read.
If that piques your interest there is always Practical Common Lisp, a copy of which is sitting on my bookshelf unopened in New York awaiting a particularly long rainy weekend this fall . . .
I was just looking through a slide deck primarily about Language Oriented Programming (see my last article) and it included the following fluent snippet:
I agree that it is an engineering marvel that they've managed to write a DSL in Ruby to parse what sounds like an English statement (I hope it wasn't on a paying customers dime!) and I'm sure that if you learnt the entire API you'd be able to do some cool things, but really, what percentage of your code is dealing with those kind of time intervals and how much time do you want to put into learning what is clearly a non-trivial API? I'd take a simpler API that is readable but not fluent.
As a recent posting mentioned (sorry - I didn't save the link), programs may be primarily for humans to read and only secondarily for computers to parse, but they don't need to be written in fluent English to be readable and it seems to me that fluent programming comes at the cost of discoverability and comprehensibility. Lets say the above statement was off by an hour, exactly where in the code base would I go to find the algorithm to fix the bug?
This is the obvious next step in the distinction between languages (CF, Python, Ruby) and the platforms they run on (CLR and JVM). Of course we will continue to see stand alone deployments of languages, but it will be interesting to see over time if more people move to a Java or .net deployment runtime and then just run the appropriate port of their chosen language.
Obviously performance and library compatibility will be huge issues, but this is definitely a space to watch.
Here is the architectural overview.
And I thought *I* was crazy. This is too cool :->
Note to self: added class_eval to ColdFusion wishlist :->
From the way Graham tells it, Lisp is the language Ruby would like to be when it grows up (he argues that Lisp Macros are more powerful than Rubys metaprogramming capabilities).
Imagine most of the benefits (not all, but most) of Ruby or Python, with native support for Java objects and (most importantly) using Java influenced syntax so you don't have to "get" Ruby or Python syntax. Extremely concise, fairly powerful, and easy to integrate in a Java shop. It doesn't compete with CF directly, but it'll be interesting to see if it can take some wind out of Ruby's sails. With the number of Java developers out there looking to have a dynamic scripting alternative, it seems an interesting approach.
Of course, there is some argument to using Ruby or Python for scripting as you will soon be able to deploy both on Java and .NET frameworks (which seem to be the two default deployment options for most firms) and Groovy is young and immature, but it should be interesting to see what comes of this . . .
Here is a very old tutorial which is still a pretty good, simple introduction to the language.
Any input/ideas/opinions much appreciated!