In my experience packaging, TDD and images have nothing to do with the problems that Common Lisp had (has?).
I tried to use Common Lisp for all my "home" projects between 2005 and 2006 and eventually gave up.
My conclusion was that the problem of Common Lisp was a combination of:
a) the standard is outdated, on one end it lacks many features that we now see as indispensable, due to not existing when the standard was ratified (unicode, networkings), not being commonly part of standard libraries at the time (modern packaging, regexps, C bindings) or simply were forgotten (parsing floating point numbers), on the other hand many features were specified in byzantine ways for compatiblity with systems that do not exist anymore (file system access, character encodings)
b) there were 5 major implementations, 2 of which commercial with expensive licences.
c) the community was small as much as that of any language that isn't C-like or PHP, Perl, Python or Ruby.
None of this was a problem in itself but, in one sentence, the community was too small and fragmented to bridge the gap between an old standard and practicality.
As a result even doing something as simple as a web scraper supposed to work on both OSX and Linux required major library juggling.
This doesn't happen in other languages not because of some psychological attraction of biploar minds to lisp but because other languages often have either a single implementation or a lot of modern features in the standard library or both. Or they have enough users that something like boost eventually gains traction.
I really hope quicklisp fixes this but it isn't simple.
"I really hope quicklisp fixes this but it isn't simple."
Clojure fixed (a) and (b) by taking most of the good ideas and repackaging them in a fresh design, and fixed (c) by building on top of Java's virtual machine and libraries. Come on in - the water's nice!
The author of Worse is Better wrote papers attacking and defending WiB, even under a playful pseudonym. A decade after writing it, he still didn't settle on a side. So citing "Worse is Better" doesn't end the discussion right there.
I can't speak about 2005/6, but as a CL apologist in 2011:
My dad was doing TDD in common lisp in the 80s. Back then he just called it programming.
A. The major releases support things like unicode, networking, packaging, threading, cbindings. There are also 'standard' libraries for things like regexps, cross implementation threading, stuff like that. The Common lisp asni standard covers a areas that would be part of the libraries for most languages.
(Parsing a floating point number is easy once you have regexps by the way; confirm it is in the right format then do a read-from-string).
I don't know your point about character encoding or file system access? (with-open-file (stream #p"/path/to/directory"... ) ...) seems pretty easy to me. There is a lot of pathname stuff in the spec, that could be mastered, but as far as the basics, you can get by simply by having knowledge of a couple of key functions and the file-system that you are using.
b.) I don't know of any commercial PHP, Python, Perl, or Ruby implementations. I also don't recall professional C development environments having particularly cheap licenses either. (How much for a copy of visual studio? I think the cheap version is $800. How about the Intel C and Fortran compiler suites? They're at least as much as Lisp Works or Allegro).
In terms of free implementations, just pick one. I like SBCL myself, as it is fast, mature and has a lot of low level features (A+++++ great, would code with again).
No one is kept up late at night in a quandry over the choice between cython, jython and unladen swallow! Why should it be so for CL? And languages like python and ruby change in major ways every few years! Do i want ruby 1.8 or ruby 1.9.2 or python 2.6 or python 3.0? OH GOD!
And unfortunately the languages that near CL's flexibility are invariably slow.
c.) How does the size of the community really effect what I'm going to make in the language? (Here's a link to a web client btw http://weitz.de/drakma/ Weitzware rocks). There's a plethora of libraries, and now with quicklisp, someone is actually curating them so you have a good idea of which libraries will work pretty well.
After the initial learning curve, making things in common lisp really is easier than making things in a lot of other languages.
The problem is that there is a fairly large initial learning curve. even in 2011 it is very different from a lot of languages that people are already comfortable with.
The standard covers a huge range of ways of thinking about writing computer programs. (You can feasibly combine ideas from functional, imperative, OO, and DSL based programming, all within a few lines of code.
You can even do C 'bit-bashing' types of programming, if you really want to (and it can be pretty darn fast).
I guess my basic thesis is that Common Lisp doesn't suck.
Learning it (completely) sucks, because it involves learning a large number of the disparate things are done with a computer, which is a daunting task.
> The major releases support things like unicode, networking, packaging, threading, cbindings.
But every implementation does it differently.
> No one is kept up late at night in a quandry over the choice between cython, jython and unladen swallow!
And that's because Unladen Swallow is mostly dead, most libraries are written for CPython first, and if you happen to choose Jython you can always pick a library from the vast pool of Java libraries.
With Common Lisp it used to be that every library supported a different subsection of the implementation x operating systems matrix.
> I don't know your point about character encoding or file system access?
Read the standard on pathnames. Versioned filesystems are a blast from the past.
First time I used it I had problems convincing it to use the right character encoding when downloading pages. The second time I tried it wouldn't compile on SBCL on Mac OS X.
> I guess my basic thesis is that Common Lisp doesn't suck.
>Read the standard on pathnames. Versioned filesystems are a blast from the past.
I have, what is your point?
Most languages use string concatenation for file-system access.
How is CL a step backwards from that?
>It doesn't, I never said it did.
It was an allusion to a fairly well known post entitled 'why common lisp sucks', which is basically what Dr. Taver is describing.
a) the standard is outdated, on one end it lacks many features that we now see as indispensable, due to not existing when the standard was ratified (unicode, networkings), not being commonly part of standard libraries at the time (modern packaging, regexps, C bindings) or simply were forgotten (parsing floating point numbers), on the other hand many features were specified in byzantine ways for compatiblity with systems that do not exist anymore (file system access, character encodings)
b) there were 5 major implementations, 2 of which commercial with expensive licences.
c) the community was small as much as that of any language that isn't C-like or PHP, Perl, Python or Ruby.
None of this was a problem in itself but, in one sentence, the community was too small and fragmented to bridge the gap between an old standard and practicality. As a result even doing something as simple as a web scraper supposed to work on both OSX and Linux required major library juggling.
This doesn't happen in other languages not because of some psychological attraction of biploar minds to lisp but because other languages often have either a single implementation or a lot of modern features in the standard library or both. Or they have enough users that something like boost eventually gains traction.
I really hope quicklisp fixes this but it isn't simple.