This reads like a Chinese government strategy document: "the world thinks we suck. How do we convince everyone we're vibrant and fun-loving?"
I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.)
Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL.
And this is why Lisp is unpopular.
The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped.
I hope the Clojure guys change things. They seem to have the right approach.
Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ appears to redirect to the ALU homepage.
In many ways, Clojure seems like a deliberate response to each of the common complaints against Lisp.
Lisp is old and moldy. It must be primitive by today's standards.
Hard to call Clojure "old" when it's only been around a couple years.
The exciting languages to learn now are Python, Ruby, Groovy, etc.
Clojure has been very successful at building nerd "street cred." It has latched onto the fascination with functional programming for parallel applications, for one. It also makes use of concise syntax for data structure literals, like Python and Ruby, too. Dynamic, etc. etc.
Lisp is only for artificial intelligence.
Don't think Clojure has this problem.
Lisp is interpreted and slow.
Lisp programs page heavily, so they're even slower.
Clojure gets the performance benefits of running on the highly tuned JVM, with tricks like type hints to get close to Java speeds for critical portions of code. Worst case, you can always drop into Java as your "assembly" language.
The parentheses look weird and hard to manage.
Clojure mixes up () with [] {} to make code easier to mentally parse.
Lisp uses prefix notation for things that every other popular language
does with infix notation, which is just very weird. (And it leads to
more parentheses.)
No change here.
Lisp is too big.
Lisp is too hard to learn.
Clojure is pretty small and doesn't take much time to get started.
Lisp is all about lists and recursion; that's all you do with it.
Some might start to think "Clojure is all about functional programming." Don't know if that's good or bad.
I don't know which implementation to use.
There's only one Clojure implementation.
It isn't "batteries included" (that is, it's not easy to get set up with all the tools and libraries you need).
You get all the libraries written for Java.
I don't like Emacs, and you can't use Lisp without Emacs.
I use Emacs, which is also great for Clojure, so I can't judge how easy it is to program in Clojure without Emacs.
Lisp isn't useful for my career; few potential employers want it.
You might be able to sneak Clojure into a Java shop.
No offense but I don't think you get the concept of batteries included. Python has batteries included, Clojure has batteries available.
Even the clojure contrib jar is not included by default and has to be downloaded separately and then clojure needs to be launched with extra command line arguments to setup the classpath properly (or you need to fiddle with the classpath from within clojure), the same goes for any Java library that you want to use.
Except for the classes in the JDK. That gives you networking, file I/O, string processing, regex, Swing GUIs, JDBC, ZIP compression, some XML processing, among other things.
Even by itself, that is better than most Lisps out there, if not enough to make a Pythonista happy. The problem with this stuff is usually the painful verbosity of Java necessary to use it, but you can wrap away that pain very quickly with Clojure.
I do take the point about needing to fiddle with the classpath for any other Java code you want to use. But for me the Java classpath system holds up better than most other software deployment mechanisms. Usually, you just download a jar file, drop it on your classpath, and it just works. I think jar files are an unappreciated success story of the Java ecosystem. Clojure has functions to easily add jars to the classpath at runtime, which is even better, but I find it does not always work seamlessly for me.
I kind of like Clojure but several things I find a bit disturbing:
1. A very subjective one - not enough parenthesis - take fo example "cond" operator - it accepts pairs condition-operation without extra parens around each pair. Well, it looks nice for small "cond"'s but for bigger ones it is both inconvenient and error prone - if off by 2 exprssion, fo some reason - yo'll get completely crewed up behavior. There several other syntactical things I find artistically impressive but technologi cally justified.
2. Another thing - I miss "setf" - in somke places mutability can be a way for smaller code especially in case
of VM without tail-recursion.
3. It is way biased towarda concurency, it was in fact engineered for concurency - well I sometimes a lot more dirtiy but fasterr solutions.
4. I think that great attractivenes of Lisp's is that you can craft your own in less then a month. No pain with lex/yacc, antlr etc. Just make a simple reader and focu on semantics.
"the world thinks we suck. How do we convince everyone we're vibrant and fun-loving?"
The only response that wasn't along those lines (or the old "Lisp is just too awesome for lame modern coders" shtick) was Ian Eslick's long one "A Coherent Portal into the Lisp World"; he actually seemed aware of why it was hard for new folks to get into Lisp and had suggestions about direction.
For pc: I asked the ALU webmaster about the fate of the CLRFI site. He said: "The CLRFI has been (successfully, imo) superseded by the Common Lisp Document Repository <http://cdr.eurolisp.org/>. So when we had to rebuild the server last year we decided to stop posting the bytes."
I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs.
I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.
Well, I'm not thrilled about it. But getting something out the door is the key. Enjoying the development experience is #2. I can live with a 6% vig for the Cincom guys.
Out of curiosity, have you checked out Pharo? It just seems nuts to me to agree to give away such a huge percentage of revenue just for your development stack.
This article links to another one which lists and describes actual issues with the core language. I don't think that it's quite as bad as you make it out to be.
I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.)
Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL.
And this is why Lisp is unpopular.
The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped.
I hope the Clojure guys change things. They seem to have the right approach.
Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ appears to redirect to the ALU homepage.