Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect. Especially - why would you choose lisp over a specialised solution - static type safety, multiprocessing, oo being the main areas discussed. I don't claim to be an expert in lisp, as I mentioned before. What I wrote is based more on what I see, rather than what I work with every day and I appreciate other views even if don't agree :)

> Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect

They aren't necessarily incorrect, they're just meaningless: I don't start a program and say what this program needs is static type safety, multiprocessing and object oriented designs. I start at a much higher level than that: What should the program ultimately do?

A number of years ago, I made survey kiosks that ran on OpenMCL on G3 macs. They had to ask some prearranged questions, with some potential branching and "please specify" type answers, and they could give different questions based on previous answers. On the way, a number of interesting things happened:

1. The original plan was to use xulrunner and aserve on top of an X server (no WM). xulrunner was simply too slow, so with only two weeks left it was ripped out and replaced with checkboxes, buttons, images, "textareas" and radio buttons on SDL. All of the generic functions which used to emit html, now tracked dynamic variables for a "cursor" and made a drawlist.

2. The survey stations updated their code using multicast pings. Basically they had a directory of source files, and a version tag that would automatically be pushed to any nearby station. When I decided I needed a database, I simply stored the answers in that directory, using the mac address of the ethernet device as the file "name", and the contents simply as lisp forms. The result was that all the answers collected by a machine were shared with every other nearby station. On two occasions a machine died in the field, but no questions were lost. They also shared their source code similarly, so I could push out updates very easily.

3. I was out of the state at a wedding on their first deployment, and there was a problem: One of the machines was acting really funky. Using two cell phones, emacs and slime, I was able to connect into the machine remotely and repair it on the live system. Once it was repaired, I saved the file and it automatically copied all over the campus.

4. One of the major focuses was media awareness. The user was asked to enter in all of the advertisements they were aware of. This was completely freeform, but we needed to collect the results, correct misspellings, cluster them, and make graphs in real time as the event proceeded. These reports were used in justification to the event promoters.

5. At our second install, they had no ethernet deployment. Instead they promised someone could walk a USB key between the machines. A udev rule to detect insert copied all the database files from that synchronization directory to the usb stick, and a trigger replaced any local files if they were newer.

From prototype to delivery was about two months, and we used multiprocessing, a distributed system, and object oriented programming.

Could it have been done in Python? Sure, but had I used python I probably would've used one of the web frameworks, and once I decided I needed to draw the screen myself, things would've gotten pretty messy.

Could it have been done in Erlang? Sure (I can use the process dictionary for dynamic variables), but when I build the database synchronization system using Erlang primitives, I lose the ability to add the easy USB support.

Could it have been done in Haskell? Absolutely, but only if I got it right the first time: I wouldn't have been able to update the code while I was at a wedding.

Ultimately, had I a clear idea of what was needed before I started, any one of those languages could've been made to work, and they all have lots of library code I could've lifted, which is your point.

However my point is that I didn't have a clear idea what was needed, and replacing the libraries would've required either a significant shift in complexity, or a paradigm that the "best" language simply didn't have.

I don't always use lisp, because the practical access to libraries and efforts is important, however there are times where not having access to libraries and efforts is more important: When I don't know what a program will need, locking myself into a module or a framework is the last thing I want to do.