That's the problem with Lisp features - you don't get to appreciate how powerful they are until you are way deep in the woods, at which point you are now another 'convert' trying to convince others to follow.
I like Scheme but having seen what the condition system could do on Lisp Machines decades ago makes me feel like we are currently living in a computing dark ages.
This is exactly the issue. Growing appreciation for this kind of stuff often requires a level of understanding that a lot of the people in the industry lack. You can't miss what you don't know about.
I'll give some examples:
You cannot appreciate the extreme simplicity of Pascal or other Wirthian languages if you never wrote your own compiler. For the average developer, it is just a procedural language with weird excessive syntax, annoying separation between interface and implementation and way too picky about where you declare your variables.
You cannot appreciate Forth if you don't know how the machine works and see the beauty of threaded code. Forth then just becomes this reverse Polish notation thing that some crazy people love. They really must be nuts, as I'm solving my problems with C and JavaScript just fine. Why do they like RPN so much and why can't they just shut up about it?
So the same goes for Lisp and Smalltalk. These are not regular languages, they have operating system aspirations. What a small group of people were doing with Lisp Machines when everyone else were using line editors is completely unknown for the average developer, they just see the parenthesis and run away.
As you mention it is also the reason why I'm partial to Common Lisp over something like Scheme and Clojure. I mean, I like those a lot as well, but they don't offer me much over plain JavaScript and I'd rather use APL :)
> You cannot appreciate the extreme simplicity of Pascal or other Wirthian languages if you never wrote your own compiler. For the average developer, it is just a procedural language with weird excessive syntax, annoying separation between interface and implementation and way too picky about where you declare your variables.
You don't need to have written a compiler. Just have wanted real modularity. You can get it with some popular and mainstream OO languages (Java, C#), but it's horribly broken in many other mainstream languages (C++).
Separating interface from implementation shines when dealing with larger teams, and can really be nice for compile times which improves feedback loops.
I agree that Lisp offers a fast feedback loop, and I have programmed in it (though not professionally) for about 14 years now.
Regarding '"interface vs implementation" nonsense', that's kind of nonsense to call it nonsense. Most of us don't (professionally) get to work in Lisp or other non-batch compiled languages. In those cases, the separation (in sane language implementations) can lead to much faster compilation time. But they also help to work with teams at scale, and make it easier to substitute implementations without having to recompile the entire thing (though you'll still usually have to relink it).
Languages first need to be practical. Allow me to make productive desktop, mobile and web-apps with Common Lisp with minimal setup and headache and I'll become a Common lisp fanatic the next day.
I have been doing desktop applications using Qtools[0] which is relatively pleasant to work with. I have prepared a hello-world kind of Qtools project[1] that is automatically built and released into ZIP files using Travis CI. (I haven't looked at it for a while and it seems that the configuration for one of the OSes needs a bit of an update due to a change in the directory structure of SBCL releases there, but the rest works.)
I don't have much experience with web applications in Lisp, but there's some substantial tooling there and I know of people who have done that before, both client- and server-wise.
I have no experience whatsoever about Common Lisp on mobile.
Web is a solved issue in most programming languages and Common Lisp is not the exception here.
The situation with desktop apps is pretty good. You have two commercial solutions and the usual open source bindings to popular libraries to choose from. There's also McCLIM if you fancy doing some archeology. https://github.com/CodyReichert/awesome-cl#gui
Concerning mobile, there is a LispWorks runtime, a subset of Common Lisp called mocl and there's also the option to use ECL. These need a bit of tinkering, as is usual for non platform languages.
McCLIM is not a domain of archaeology anymore; it has been seeing lots of development recently[0].
As for demonstrating it, two of the recent Online Lisp Meeting[1] videos utilize McCLIM: one of them describes Clouseau, an inspector application written in McCLIM[2] (running on the Mezzano OS as well[3], since McCLIM runs there too!) and the other utilizes McCLIM to visualize the functioning of Eclector, a portable and conforming implementation of the Common Lisp reader[4].
I sincerely hope that my book aids this problem that you are speaking of - both by allowing programmers and implementers of other languages use the techniques that originate in Lisp, and to try and bash at the Lisp-as-a-meme prejudice that I've seen in many places by showing what the condition system is actually useful for.
I like Scheme but having seen what the condition system could do on Lisp Machines decades ago makes me feel like we are currently living in a computing dark ages.