The only thing Lisp fails at

There's this post by Loper OS, "Where Lisp Fails". The general point of it is that less powerful languages are popular among management because it lowers the technical knowledge and skill bar for being able to use the language, meaning programmers are more replaceable and easier to hire, and it also vastly decreases the leverage any individual programmer can have, because the language is just so verbose and unproductive that it takes a lot of time and effort to get anything done. The idea is that this is done to reduce the power of programmers as labor and skilled artisans.

The problem with this for me is that I don't think we should be guaranteeing our irreplaceability as skilled artisans at the language level. The idea that we become irreplaceable by just using really complex abstractions (reflection, macros, etc) and languages with very high skill floors and ceilings, is intuitively distasteful to me: ultimately the brevity with which you express a problem or something is secondary to getting something that works well and does what the people who depend on it need it to do; not only is it secondary, it's also kind of orthogonal! So it feels like unnecessary gatekeeping of the profession, in a way that doesn't actually make what the profession produces any better, to try to make it seem like that's the important thing.

Obviously, if you're using Java circa 2009, you're not just losing out on brevity, you're losing out on the ability to even express a massive range of concepts without insane convolutions; and if you're using C or C++, as the quote from "The Bipolar Lisp Programmer" points out, you're dealing with much harder problems thanks to pointers and manual memory management than you would be solving the same core problem otherwise.

But most languages aren't like that now. Even Go has generics, structs, methods, structurally-typed typeclass-alikes (that work with generics, and are recursive), composition-as-multiple-inheritance, first class higher order functions, and an amazingly powerful concurrency model deeply inspired by a powerful mathematical formalism (Hoare's CSP). Java has essentially ADTs, pattern matching, functional programming primitives, and higher order functions as well. They both have reflection for when you really need it. They both have VMs and excellent cross platform runtimes that abstract a lot more concerns from you than even Lisp can. So it's not even clear to me that modern languages actually fall much meaningfully short, in terms of how much leverage they give you, an individual person, compared to Lisp — especially since the vast majority of the leverage you can gain from a language is in terms of toolchain, runtime, and library ecosystem, not in the language's capacity for metaprogramming or abstraction. An individual lone wolf programmer with access to a few Python libraries will be able to do many more heroic feats of engineering than someone writing it all from scratch in Common Lisp.

Moreover, there's a sense in which it's not clear to me that using non-Lisps really does meaningfully decrease developer leverage. Yes, it lets you write less text to achieve the same results, but it usually doesn't enable truly new concepts, and using a simpler language allows us to work more often, even when we're not at the top of our game for whatever reason, and more easily understand what we've written; all these "powerful abstractions" use up mental complexity budget and cognitive load. For instance, Go's philosophy of there only every being one way to do anything, minimal featureset, extremely explicit error handling and control flow, minimal abstraction, and straight to the point code makes programmers even more productive: because it's much harder to confuse yourself or get lost, or spend time bikeshedding. And it increases your leverage, as well, as an individual programmer, because it means you can jump literally anywhere, into any Go codebase — even that of the runtime — and run into minimal barriers understanding what's going on and how to modify it. The only thing you're really losing out with a less powerful language than Lisp, for the most part, at this point, is purely brevity: it might take a bit more typing. And even that's not really a live issue anymore.

It's also just not clear to me that Lisp can result in that much of a productivity difference compared to other languages, especially at this point in language development: I've tried to get started writing a fair few Lisp projects in my time, as well as written a lot of Emacs Lisp, and it really didn't feel more productive than any other language I've used, because the majority of the complexity is either essential, or the kind of only semi-rote complexity — involving looking up a lot of documentation, iterating with the compiler, doing refactors, etc — that even Lisp macros aren't going to help you with.

Most of all, though, this feels like it's myopically focusing on something totally unimportant when it comes to the power of professional programmer labor — in actuality there's plenty of irreplaceability and skilled craftsmanship to be found, and the vast majority of it is not adolescent language wars and Lisp-weenieship, but at the level of understanding domains and situated systems, having a lot of experience, having excellent systems thinking, software architecture instincts, and data structure and algorithms knowledge. Things that come from your experience and efforts at the craft, and your actual usefulness to the people around you, not what language you use.