As a hiring manager, who has managed and fired lisp people, I sort of see both sides of this. If the problem domain fits lisp, yup, no argument, lisp rocks. I

As a hiring manager, who has managed and fired lisp people, I sort of see both sides of this. If the problem domain fits lisp, yup, no argument, lisp rocks. I used the Xerox lisp machines and it was really cool in the sense that there was no user land or kernel, it was all one thing. Cool for debugging, cool for performance, very cool when it is a fit. On the other hand, many problem domains are not a good lisp fit. In fact, most fall into that category, in my not so humble opinion. As a manager, I look at the technology used to produce a product, I think about development costs (a little) and support costs (a lot). One hot shot lisp hacker that can do whatever is cool, but that's in the "little" category. The "lot" is about support and the hotshots aren't that excited about support, it's boring. There are other threads all over the intertubes about reading and supporting code and the funny thing is that very few, if any, talk about lisp. All the lisp ones are about "how I can do this cool shit really fast and it makes me feel oh so powerful". Yeah, whatever. I'm happy you are happy. But what I, as a manager, need is the ability to take your cool shit and ship it and debug it and support it for the next decade or two and do all that when you, the studly lisp hacker, have moved on. Not really liking the prospect of doing that with a big steaming pile of lisp.