Warning: hairy high falutin' answer... The "what can lisp do that other languages can't" is, I think, a bit of a red herring...or rather, depends on what probl

Warning: hairy high falutin' answer... The "what can lisp do that other languages can't" is, I think, a bit of a red herring...or rather, depends on what problems you face and in what context we're discussing the issue. The short answer is of course: nothing. And if most of the problems you face are defined by by working on a particular technology (database tables/javascript), in a particular social concept (say a corporate workplace), or a problem that isn't LISP based, then the answer is probably "REALLY NOTHING...and possibly less". But if your problem doesn't currently have a technology acceptably applied to it, or you think the current offerings fail in some way, or you're finding the load of trying to smoosh things together because in your head the expression is crystal clear, but your language can't express it easily... The longer answer: Apart from a genuinely "linguistic" analysis of the language itself, I think "a good computer language" is one that minimises, in the abstract, some distance function between the programmer's mental models, the machine's mechanical implementation, the problem's domain, and the aesthetic simplification of the source code. Now, no language can minimise that equation in the absolute for all possible problems, if not because several of those things are often fixed absolutely or practically. And if you're working in a domain that you feel has already gotten it pretty damn good/close. Some languages trade-offs of maximizing certain aspects to the detriment of others, but it doesn't matter because it fits their "biological niche" as it were. So what is LISP (i'm talking Common Lisp here in my own personal experience) biological niche, or what does it offer that others don't? I think my answer is that its a fantastic flexible generalist that allows you to minimise the aesthetics/complexity of your code across multiple domains. - It lets you get pretty low level like C, but gets you a cheap move to a high level language like python to trade off convenience against efficiency. You get high level, like python/perl, but can drop down to far more performant code while minimising the cognitive load by staying in the same language. - SBCL, at least, mixes some of the benefits of strongly typed and highly dynamic languages (static compiler checks and fully dynamic code in the same place) - Macros allow computation and expression on the language itself more easily than in other languages, allowing you to move your language closer to your problem scope and to the programmers mind and aesthetic expression of source code. - Deals quite nicely with functions, objects and imperative programming all in the one place, allowing you to move the language closer to the programmer's mind/problem scope/aesthetic expression of source code. - And there's the whole dynamic interaction with your program, rather than an explicit code/compile/run cycle. So in short, use it where you need to care about those things seriously, which in my land is really: - Cross domain problems where the clash between the two tools/paradigms are too great - Problems where you disagree with some of the trade-offs made with the tools/languages that have come to dominate a specific area - Problems where there isn't a dominant/well-fitting tool currently (of course, for those problems, community/social/library issues isn't really an issue because there isn't one/aren't any...) - Problems where you honestly don't know what the solution is going to look like yet and no one, to your knowledge, has gotten there before you. I generally say that LISP is the second-best solution to a lot of solved problems, but perhaps the best solution to multiple-solved problems and unsolved problems for now. And that's what I think LISP gets you...the shortest distance between disparate optimisations. Now...I personally accept that 95% of programming these days ISN'T that...