Well, the unique bit is images and homoiconic metaprogramming, not just metaprogramming. You can get that unsafely (code generation scripts) or safely (program extraction from a proof language) a lot of other places.

But the main argument is that Lisp is hyperproductive if you’re an individual brain genius who’s memorized every emacs key combo. And my point is that it doesn’t matter if you can produce something fast if you can’t know if that thing actually works.

This is the traditional “static vs dynamic typing” argument but you know, a lot of new languages have new kinds of safety features going beyond “static typing”.

And of course Lisp does make unusual decisions affecting safety. Making all numbers bignums means math is more likely to be correct since it won’t overflow, but untrusted user input can pretty easily DoS you.

>> it doesn’t matter if you can produce something fast if you can’t know if that thing actually works

In reality things that are hopelessly broken and released quickly win market share all the time which is in contradiction to your statement.

The old Tony Hoare quote seems apt: "There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors."

Macros do reduce the surface area for mistakes, by removing redundant expressions that can be typoed. Say, you cannot forget to close a file if you use WITH-OPEN-FILE, but you can if you call OPEN and CLOSE yourself. There are other ways to not leak resources, but macros are just another way to not repeat oneself.

> But the main argument is that Lisp is hyperproductive if you’re an individual brain genius who’s memorized every emacs key combo.

I certainly haven't, though I suspect this is a bit of an exaggeration.

And in my little experience, homoiconicity also reduce the surface since you deal with sexp/ast in the same world as you code, there's no external dsl/lib to master.