Do you mean the first question literally? My salary has never been well correlated with my productivity.

Figuratively, in the sense of "if Lisp allows you to be so concise, why aren't your programs small?", I can report that in every case where I ported a program to or from Lisp, the Lisp version was significantly shorter than the non-Lisp implementation. So I'd say, "it is".

As for whether I'm just an amazing programmer, I don't think so. (I don't think I've ever been accused of that!) I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it.

I find C (and imperative languages in general) harder to write and debug. Am I "doing it wrong"? I've found C hard to work with since around 1990 when I first tried to learn it.

Re: "My salary has never been well correlated with my productivity."

I'm thinking more from the owner's perspective. If they hired a bunch of Lisp programmers, then they'd produce more software with fewer programmers (if the productivity claims were correct). They'd then get rich and expand, and other companies would take notice and copy.

Re: "I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it."

There seem to be niches were it works out well, but it has stayed niches since the invention of Lisp. After 50+ years of not catching on in the mainstream, you have to wonder about real-world market fit.

Re: "I find C (and imperative languages in general) harder to write and debug."

C is a relatively low-level language, mostly designed for hardware speed instead of programmer speed. Thus, it's not the best specimen of imperative languages to compare with.

But in general such seems to be subjective: people give widely varying anecdotes. Those who like Lisp dialects gravitate toward them and those who don't go elsewhere.

One of the reasons I hover in the space of semi-functonal languages like Groovy and Scala. Because as much as I love concisely expressing a piece of complex logic as a composition of reduces, folds, maps etc., being able to easily and naturally break out of that to execute a piece of imperative code in the middle of it is still regularly a life saver to me and often an order of magnitude clearer than the pure functional solution to a reader.

I lot of the time it seems programmers are just avoiding using SQL to do query-centric processing (slicing and dicing lists). Aside from performance problems, another downside is that one reinvents query language idioms in each programming language. It increases the learning curve and is anti-standardization.