Kina Knowledge, using Common Lisp extensively in their document processing stack

This only applies if the language implementation is complex, the language syntax is unlike anything in existence, and the language creator does not pick good names for functions and variables nor write any documentation, manuals, or papers to explain things nor he/she is available for any questions.

I can't be similarly productive in a language that doesn't have a simple syntax (easy to write) and doesn't allow you to do meaningful live programming.

By the time you've got a major headcount, organizational bottlenecks will render the individual velocity of programming tools irrelevant. Lisp will scale poorly because every language does. It's hard to justify unusual technical choices if there's no benefit. It makes perfect sense that a large organization would eventually drop Lisp.

Every startup is in the game of leverage and thus should keep the team as small as possible. Lisp helps you do that. Once you're over a certain size you WILL pay a huge organizational overhead and there's nothing you can do about it. The more logically monolithic your tech/system is the bigger the price. A lot of work just cannot be parallelized. Most of the things startups are working on tend to be that way.

and truly static executables are coming: https://www.timmons.dev/posts/static-executables-with-sbcl-v...

I'm a Lisper by preference, with almost thirty-five years of experience in the market. Because Lisp is a niche language, I've also had to be competent working with other languages, too, so I have at least some basis for comparison. My impression is that Lisp and Smalltalk do offer real productivity advantages. Don't misinterpret me: I'm not saying there are no disadvantages. I am saying that the advantages are real, though.

A lot of the productivity advantages are development-environment features, rather than language features, but the language features make the development-environment features easier to build and nicer in practice. As a simple example, it's both easier and faster to look up definitions if they're already easily accessible in memory than if you need to write a separate tool to index the source files.

Are Lispers generally 10x programmers? I doubt it, but the language and the best development environments for it do offer some real leverage, and programmers accustomed to them can get a lot of productivity out of them. I've actually been one of those 10x programmers a few times now, as measured by vcs statistics, or feature-delivery times, or client expectations. In each case that it happened it wasn't because I was so much smarter than everyone else; it was because I was permitted to use tools that I knew would give me a lot of leverage, and I already knew how to use them.

Is Lisp bad for team environments? Not that I've seen. The smallest team I've experienced is just me. The biggest was about 50 or 60 people. I've seen teams of Lispers at various sizes that had good discipline, structure, and productivity.

I have noticed remarks from some programmers that they've seen big, messy Lisp codebases, and I don't doubt it. Common Lisp, at least, is pretty unopinionated. You can pretty much do whatever you want with it. It doesn't prevent you from setting up good project structure, and if you want tools to help with that, Common Lisp makes it pretty easy to create them, but it doesn't guide you much out of the box, and if you proceed with no plan or structure, it doesn't prevent you from making a mess. If you want good structure, you have to deliberately create it. I guess I'd say it's not a good language for a bunch of people with no experience in it and no good guidance.

I don't really agree with your point C; Common Lisp is a general-purpose language. I've used it productively for quite a large variety of purposes, from system programming to document processing to compilers to Desktop GUI apps to network-security apps to webapps to Good Old-Fashioned AI, and I haven't found it dramatically stronger or weaker in any specific areas.

There's some truth to what you're saying, but I think it has more to do with the availability of supporting code than with the nature of the language. Some things will be easier to do than others because it'll be easier to find working code of good quality.

That's not a function of the language so much as it's a function of where open-source contributors have chosen to spend their efforts. That's where the relatively small size of the global Lisp community works against Lispers: there just aren't enough open-source Lisp contributors to make all the supporting code that we might like to have available.

A secret weapon? Yeah, sometimes it is. I've surprised folks a couple of times with how much I could get working quickly, and that's generally been to my advantage.

It can also work against you, most especially when you encounter a decision maker who really dislikes Lisp for whatever reason. I've encountered them a few times. For example, I knocked out a working solution to a problem for a bid before anyone else, and got an immediate enthusiastic response. The enthusiasm lasted until the client found out I used Lisp, at which point they ghosted me.

On the other hand, not long ago I was involved in a proof-of-concept that got funded, and one of the evaluators who supported us said in the review that the only reason he thought we could make it work was that we were doing it in Common Lisp. So people's preferences don't always work against you.

Blaze/Bazel rules for Lisp support building fully static SBCL binaries (except possibly for grabbing dynamic stuff that is forced by glibc). ECL also supports static linking.