Here's my story: In middle school I was given my first computer. I wanted to learn how to program it, someone pointed me toward C++. Fast forward to grad sch

Here's my story: In middle school I was given my first computer. I wanted to learn how to program it, someone pointed me toward C++. Fast forward to grad school, where I was working on a big project using C++. We nearly missed our deadline because we were all so busy trying to get C++ code to work. We worked hard to squeeze out performance, yet we were still barely able to get the results we published, and we missed some of our goals. The next iteration of the project called for high-level changes that promised much better performance, but which required a far more complicated program. C++ would have been a nightmare, so I took a risk and switched languages (a big risk in retrospect, since it meant rewriting much of the C++ code). Here is what I was looking for: * A short learning process, at least to learn enough to start writing real code * Reasonable performance * Well-developed tools and documentation I stumbled across Common Lisp, and it basically met these criteria. SBCL and CMUCL are very mature compilers, Emacs+SLIME is fantastic as an IDE, and CL's documentation is easy to find. The syntax of Lisp is dead simple which makes the learning curve very easy; you can bootstrap enough knowledge of the language to write real applications in a week or so (and more advanced features can be found as you dive deeper). Early on I noticed that I was spending almost all of my mental effort on the logic of my program, not on low-level mechanics -- even while I was debugging, and even when confronted with hard-to-identify problems, I was spending all my time thinking about logic (as opposed to C++, where I spent about 50% of my time debugging low-level issues that had nothing to do with logic errors). One very nice property of Lisp is that the default behavior is to be safe, and you can override this as an optimization (and you must be rather explicit about it). Since then the project has gone through yet another iteration and another rewrite, which met even greater success as I was far more comfortable and capable with the language. We have sent this code to others, and the majority of bug reports we have received have been about missing features rather than program crashes. Now, Lisp is by no means perfect. At the high-level, there are few standard data structures; these are not hard to write, but why reinvent the wheel or be forced to pull in third party code? There is also no standard support for things like sockets, and only minimal support for binary data formats (which sometimes one must deal with). For low-level code, things are not easy; neither SBCL nor CMUCL make debugging across the FFI boundary easy, and there is a serious performance hit that the FFI imposes. It would also be nice to have an optional static type system, though type hints are often good enough (SBCL and CMUCL can do a fair bit of static type checking), and for the metaobject protocol to be standardized.