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

Counterintuitive, it was the "elitist" lower numbers involved in some languages (not just Lisp) that were found to be advantageous by some companies in hiring. Essentially, it selected out people with lower experience and those not willing to learn a new language. An example I was given was that choosing Common Lisp and combining it with globally remote hiring greatly increased the quality of incoming applicants - and that had they went with the popular option (Python in their case) they'd have to deal with deluge of fresh bootcamp grads of which many had unwarranted high opinion of themselves.

Both Kina Knowledge and ITA Software (and from what I heard but can't cite now, other companies as well), teaching people Common Lisp on the job apparently tends to work pretty well, and willingness to master a new language correlates much better with good skills. It does have the disadvantage of not being able to throw a new hire directly tickets to solve, but the timeframes I was given were essentially "it takes around a month for new hire to go from zero to productive lisp programmer".

But do you use this weapon?

1. https://docs.racket-lang.org/gui/

2. https://github.com/Metaxal/MrEd-Designer

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.

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 guarantee you that a highly opinionated language like Go scales horizontally better* than a totally unopinionated language like Common Lisp. It's literally why Google spent a bunch of resources developing it.

It's also why Lispers tend to despise Golang, or deride it as a simple language for average developers.

*Requires fewer resources to get a new hire up and running on prod code

It's often not even deliberate. No one sits down and says, "This language or tool kit requires a higher headcount, so I'll select it for my project". But they aren't motivated to find a more efficient approach that results in them being put in charge of a smaller team (because this would cost them and not reward them).

EDIT: Some grammar things.

Not that middle management bloat isn't a thing...it definitely is. But I don't think it's as black-and-white as it's made out here.

The classic "we have niche languages" solution to that is to enable on-the-job learning of those, and not just doing simple fact checking on whether someone honestly claimed to have learnt Popular Language X as claimed on their CV.

In practice, it doesn't work. For any given product there's still always a small/solo core team.

Don't optimise your business for mediocrity.