He means he once read an article written by a web developer with no Lisp development experience called "The Lisp Curse", and that's his entire Lisp development experience.
Right, yeah, seems likely. Such comparisons are usually pretty weird, putting non-hygienic macros against ordinary programming in some other language, rather than macros against the metaprogramming used there.
Experience with macros and their footguns arguably prepared me pretty well for using JAXB and reflection professionally.
Lisp Macros are encouraged. In most other language you can't even write syntactical extensions. Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.
Google Lisp style guide: Use macros when appropriate, which is often. Define macros when appropriate, which is seldom.
Heinrich Taube's "Lisp Style Tips for the Beginner": Beware of macros. They are a very important feature of Lisp but a poorly implemented macro can cause bugs that are very difficult for a beginner to solve. Avoid writing macros until you understand how the Lisp reader and evaluator work. Never write a macro to make things "more efficient".
Guy Steele and Kent Pitman, "Tutorial on Good Lisp Programming Style" [1993]: Decide if a macro is really necessary. [...] Don't use a macro where a function would suffice.*
Carnegie-Mellon Lisp FAQ: Never use a macro instead of a function for efficiency reasons. [...] Don't define a macro where a function definition will work just as well -- remember, you can FUNCALL or MAPCAR a function but not a macro.
I've never seen a book, tutorial or style guide document saying that Lisp coders should be writing lots of macros, and constantly looking for any excuse to write another macro or some such advice.
> In most other language you can't even write syntactical extensions.
C? C++? Rust? Erlang? Scala? Julia? R?
> Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.
Macros actually are widely used to improve readability. In Lisp that's one of its main purposes. It leads to more compact, declarative, domain specific code. Large programs usually benefit the most. Programs can be much short and more readable.
Take for example in Common Lisp the Common Lisp Object System. It has three layers: an object-layer at the bottom, then a functional layer and on the top is the macro layer. The macro layer is what the typical developer uses, which is compact and which shields the developer from the details of the lower layers.
The Common Lisp Object System blends seamlessly into the rest of the language and the usual basics can be easily learned.
If you disagree that Lisp has a tendency to become unreadable then maybe the typical developer might have a "neurodevelopmental deficit" compared to you. bindings don't change the language that's executing. That's the entire point why Macros can quickly make code unreadable.
Macros do not change the language that is executing (as in self-modifying code).
Self-modifying code is possible to express by other means in traditional Lisps that have a quote operator.
In Common Lisp, it is undefined behavior to modify a quoted part of the program.
E.g. this wold be undefined:
(defun counter () (inc (car '(1))))
The function is referring to a piece of its own syntax (1) which initially holds the integer 1 and incrementing that. This may have the expected effect under some circumstances. Or it could have the expected effect, plus some unexpected effect, or not have the expected effect at all. It may signal an error, also.
