It would be noteworthy if any evangelist for any programming language that is not PHP said something like this.

I've been saying this for a long time and I really believe it. At least borderline evil. It seems to me there's nothing doing more damage to (web) technology than Google hording many (most?) of the world's greatest hackers and severely under utilizing their abilities.

I agree that this is impressive, but remember that you get to cheat: You build the thing, measure how far off you are, and stick delay lines in the short branches until everything lines up. Admittedly, if you're off by a hundred meters the required delays would be embarrassingly large, and the architect would get teased a lot, but even then I don't think it would pose an insurmountable problem.

Meanwhile, if the essence of your argument is that Lisp was used by mainframe guys and wasn't pushed hard enough in the microcomputer world, I can't help but agree. God, if only I could travel back in time and replace all those useless Pascal books I read as a teenager with Lisp books...

Hofstadter's Law: "It always takes longer than you expect, even when you take Hofstadter's Law into account."

These guys followed through and the result is amazing. Their reasons for using the tools that they chose are exactly why it was so goddamned hard for me to do what I wanted to do with gmaps, but at the same time, I didn't have the spare cycles to do it with Ka-Map! or similar.

Brilliant execution.

Ralphc's point wasn't about there being a clear winner in the dynamic language space, but that each of the languages mentioned had one canonical interpreter.

   common lisp: (lambda (x) (+ x 1))
   C#3        : x=> x + 1
   ruby       : { |x| x + 1 }
   python     : lambda x: x + 1
   Haskell    : \x -> x + 1
   

No, the problem with trying to get a lisp under your belt has alredy been mentioned. Compared to the alternatives;

- choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr)

I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark.

Another barrier is having to learn emacs/SLIME to have a decent development environment. That is a big piece of yak shaving for the average developer. Hopefully Cusp in Eclipse or something else will help.

they call that Agile Microwave Engineering

oh, and you must have two microwave engineers working on each delay line.

Another thing you'll find is that for trivial problems, Lisp might take a few extra characters, but it scales much better. Try making your Python lambda print the value of x first. Try telling your Ruby lambda that x (and x+1) fits in a machine word so it can compile the function into only a couple of CPU instructions. Try writing a metacircular evaluator in C#. :-)

When you're just getting started, in any language, it doesn't really matter which implementation you pick. (FWIW, CLISP is byte-compiled, SBCL is a native compiler, and Allegro costs $600. Not unique to Lisp: you can find expensive proprietary C++ compilers, too.)

As a Lisp and Ruby programmer, I disagree that Lisp's documentation is weak. I would be very happy if Ruby's docs were even half as good as Lisp's.

I type "sudo apt-get install library-name" for both Lisp and Python libraries, so no difference there. (Ruby gems are less frequently packaged, and aren't compatible with the FHS, so they're a little harder.)

Lisp examples seem to be more often found in (dead tree) books, while Ruby and Python examples are more often found on the web. Since Ruby and Python libraries (and even syntax) are still in flux, and Lisp predates the web, this kind of makes sense. If you can't buy a couple books, it can be rough, though some good Lisp books are becoming available on the web for free.

Those symbols you picked are a little weird, but when's the last time you actually saw a cdadr? It is at least consistent (which is more than can be said for some languages!). I don't find "unshift" or "__gt__" any better.

I don't want to sound like a pure apologist. I admit that Slime is an investment (if you don't already know Emacs). Apparently there is a Lisp plugin for Eclipse, but I know nothing about it. It is a shame more IDEs don't support Lisp well, though I can see why they don't.

Finally, it could be simply that Lisp doesn't map well to your mind. (I don't mean this as an insult -- everybody's different. Maybe Smalltalk or Prolog or Sisal is your cup of tea.) I don't think Ruby maps well to mine, though I know some people who seem like Matz reincarnate -- which could explain why the docs are so sparse! The core of programming, to me, is having fun building good abstractions, and if Lisp isn't doing it for you, by all means, find (or invent!) something that does. Cheers!

You're different from a lot of hackers I know.

Seriously, though, you probably will eventually rewrite most of it if you turn it into a startup. And often when people rewrite things they're glad afterwards. It will probably take less time than working out a deal with the university, and be much more interesting for you.

My hypothesis is that Lisp is unpopular for the exact same reason some of us love it: concise code. Everybody praises concise code, but humans love looking at things that have repeated patterns. The more you compress information, the fewer repeated patterns there are to look at.

I wish PG well with Arc, but I don't think popularity will come from fixing anything that's wrong with Lisp. By my hypothesis, Lisp only becomes popular by fixing what's right with it.