A favorite conundrum of many Lisp aficionados is why the language appears to languish in disuse. Talk of cultural problems, “the library question” (which usually boils down to nonsensical circular reasoning), too many parentheses, and other absurdities simply dances around the blindingly obvious explanation – one which is able to make sense not only of the obscurity of Lisp, but of many other conceptual breakthroughs (such as reflectivity) which threaten to give developers’ minds a “lever to move the whole world.”
Employers much prefer that workers be fungible, rather than maximally productive.
Yes, this holds true even at that most beloved megacorporation citadel of angels:
“One of the reasons I stayed at JPL for twelve years was that I was appalled at what the software industry had become. The management world has tried to develop software engineering processes that allow people to be plugged into them like interchangeable components. The “interface specification” for these “components” usually involves a list of tools in which an engineer has received “training.” (I really detest the use of the word “training” in relation to professional activities. Training is what you do to dogs. What you should be doing with people is educating them, not training them. There is a big, big difference.) To my mind, the hallmark of the interchangeable component model of software engineers is Java. Without going into too many details, I’ll just say that having programmed in Lisp the shortcomings of Java are glaringly obvious, and programming in Java means a life of continual and unremitting pain. So I vowed I would never be a Java programmer, which pretty much shut me out of 90% of all software engineering jobs in the late 90’s. This was OK since I was managing to put together a reasonably successful career as a researcher. But after Remote Agent I found myself more and more frustrated, and the opportunity to work at Google just happened to coincide with a local frustration maximum. One of the reasons I decided to go work for Google was that they were not using Java. So of course you can guess what my first assignment was: lead the inaugural Java development at the company… The interchangeable component model of software engineers seemed to work reasonably well there. It’s just not a business model in which I wish to be involved, at least not on the component-provider side.”
Erann Gat, “Lisping at JPL”
It amazes me just how blindly complacent programmers have been in the face of the ongoing and very successful deskilling of their profession. Instead of rebellion, we see mass Stockholm Syndrome. There is no shortage of pundits ready to bloviate at nauseating length on nearly every – even the most trifling – perceived shortcoming of Lisp , other than this one. Once in a very long while, some daring soul will call out the “elephant in the kitchen” openly and directly:
“…in contrast, the C/C++ approach is quite different. It’s so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you’re liable to need help in any C project of significant size; so you’re liable to be social and work with others. You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one) in the not unlikely event that he will, at some time, go down without being rebootable.”
Mark Tarver, “The Bipolar Lisp Programmer”
I predict that no tool of any kind which too greatly amplifies the productivity of an individual will ever be permitted to most developers. In this they shall follow in the maximally deskilled assembly-line footsteps of their grandparents. “They’ll time your every breath.” As for the “free software” world, it eagerly opposes industrial dogmas in rhetoric but not at all in practice. No concept shunned by cube farm hells has ever gained real traction among the amateur masses. 
 Ever wonder why it is customary to speak of the wildly different Common Lisp, Scheme, ZetaLisp, Emacs Lisp, etc. as though they were a single language? I would like to suggest that we start referring to C/C++, Java, Python, etc as ALGOL.
 Consider Linux: the poster child of successful free software. It is a knockoff of a 1970s operating system well past its sell-by date. This is because a herd simply cannot innovate, whether for fun or for profit. Every innovative work of mankind has been the product of one – sometimes two, rarely three – minds. And never the work of a herd. No mathematical theorem, no enjoyable novel, no work of art of any importance, have ever been produced by a herd. I fail to see why innovative software ought to play by a different set of rules.