Lispers rightly tout the malleability of the syntax as a killer feature. The big problem is that any language you build in lisp is still pretty much lisp. If you're not already sold on s-expr syntax, and a lot of programmers, rightly or wrongly, don't like it, the fact that you can replace one s-expr syntax with another just isn't that convincing.<p>The irony here is that lisp's syntax will probably keep it from ever falling into obsolescence because it can adapt to any new <i>general</i> task but it will also prevent it from ever really breaking into the mainstream because for any <i>particular</i> task it's a non-optimal syntax and a steady procession of more specialized alternatives suit most people's needs better.
I think the spirit of the post is right on, but I'm not a fan of the example given. That's the kind of code that scares people away from lisp. Which isn't to say it's bad code, but it's not nearly intuitive enough to use as an example.
Great article. Probably no coincidence that Nathan uses SQL as a straw-man since he is interested in data oriented languages and wrote the nifty Cascalog DSL (which, BTW, I am evaluating for use at work).<p>I share his interest in Clojure, but some little things like poor stack traces still keep the experience of using Clojure from being totally fun. I use Clojure for work, but I am still mostly using Ruby for my own projects (with some Clojure).
I think most of what is good/unique about clojure doesn't come from being lisp though. For example - its concurrency constructs, seq/lazy-seq abstraction, persistent data structures that work with seq, java interop, etc.<p>Being a lisp doesn't hurt it, especially in the context of DSLs mentioned, but I don't think it defines it either.
Nit: the technical term for "integrated language" mentioned here is domain-specific language. People spin off DSLs from Ruby all the time.<p>Incidentally, one could argue that SQL is the most widespread DSL there is.<p>Edit: The author mentions this is basically a DSL in his post, which I missed the first time around. Not sure why he didn't just stay with that nomenclature though.
<i>There have been many attempts to articulate the benefits of Lisp-based languages before, but most of these attempts seem to end in futility.</i><p>Really? I think someone even wrote a whole book that's mostly about macros, embedded languages and so on.<p><a href="http://www.paulgraham.com/onlisp.html" rel="nofollow">http://www.paulgraham.com/onlisp.html</a>
I'm very much looking forward to seeing Nathan talk about Clojure and Cascalog at the Strange Loop conference in October! <a href="http://strangeloop2010.com/talks/14487" rel="nofollow">http://strangeloop2010.com/talks/14487</a>
"There's one huge difference between Cascalog and Linq: Linq is part of C#. You can't define Linq in terms of regular C#"<p>So, the code snippets in this article aren't written in Clojure, but instead in some other custom language? I dont know Clojure, but those examples look very much like that crazy foreign Lisp 'nested parenthesis talk' to me.
I feel like I'm nitpicking but I couldn't let it go, and yes its already been mentioned once but I feel that argument offered by confuzatron was lacking. I'm referencing to your characterization of Linq in C# as something inextricably linked to the language, how you cant even begin to separate it from the language.<p>Straight off the bat the most glaring problem with that statement is that Linq is not part of C# in any way shape or form since all C# code is compiled to bytecode, it would be literally impossible for C# to have Linq and for it to not be available for the rest of the languages supported by dotNet. The funny part is the expressive form of Linq that reads like a sentence is not even fully supported by C#! Only VB.Net has fully implemented Linq expressiveness.<p>There are many more reasons that argument is wrong, but I feel just pointing out that one above shows how far off it is.<p>In my experience its almost always best to shy away from hyping your idea of better by knocking the competition, your article stands well on its own and C# has so many obvious flaws that theres no need to add to it. Stick to whats good about X, not whats crappy about alternative Y.<p>Again all in all an interesting read since im not familiar with Clojure, but I just had to nitpick.