Generalized Macros
This post persuaded me to not take much of a look at Janet. This is also related to why I think that Lisps haven&#x27;t become the most widely-used programming languages.<p>Lisp enthusiasts like to point out the power of macros, and macros are the raison d&#x27;être for Lisp&#x27;s homogeneous s-expression syntax. Most other features in Lisp (such as first-class closures and higher-order functions) can exist without s-expressions, but the powerful thing about s-expressions is that they enable Lisp macros.<p>But with great power comes great responsibility. When I&#x27;m writing a program I want as little responsibility as possible while still being able to solve the problem at hand. I don&#x27;t want to be responsible for memory management and bounds checking, and I don&#x27;t want to be responsible for the hygiene of my macros at both the definition and the call site.<p>With C, the responsibility of memory management and bounds checking comes with a power that people actually need to solve problems. For me these problems usually come up in the context of writing my own hobbyist interpreters&#x2F;compilers, but there are a lot of real world cases where these come up. But often you <i>don&#x27;t</i> need the capabilities of C, and I&#x27;d argue as a result that there are a lot of cases where using C is a bad idea because it&#x27;s not the best way to solve your problem.<p>And here&#x27;s the hot take: the power of Lisp macros isn&#x27;t actually ever worth the responsibility in my experience. The problem Lisp macros solve is &quot;this code is more verbose&#x2F;ugly&#x2F;boilerplate-y&#x2F;etc. than I want it to be&quot;, which just isn&#x27;t the problem you&#x27;re writing the program to solve. Whenever you reach for a macro, there&#x27;s another tool you could be reaching for to solve the actual problem at hand. At the very least, you can just write the code the macro would expand into. There&#x27;s inherently never a case where the macro is the only way to solve the problem.<p>If you&#x27;re good at writing macros, you won&#x27;t always get burned by them, but nobody is ever perfect at writing macros, so everyone gets burned sometimes. If you&#x27;re writing software that you actually need to work, the risk is rarely worth it.<p>When I have written production code in a Lisp (mostly Clojure) I&#x27;ve rarely reached for macros, and often bugfixes have been removing a macro that was of the &quot;so preoccupied with whether or not they could, that they didn&#x27;t stop to think if they should&quot; variety. And if you spend enough time avoiding and removing macros, you start to wonder why you&#x27;re destroying your eyesight trying to match parentheses, when the entire reason for the parentheses is to enable something you have to avoid and remove.<p>And don&#x27;t get me wrong: macros are <i>cool</i>. &quot;Because I like them&quot; is a totally valid reason to write macros and Lisp.