3 ms·
Macros provide abstractions that often make programs easier to understand. I myself have dozens of the usepackage macro in my Emacs configuration, they hide and
by todd8 4y ago
Macros provide abstractions that often make programs easier to understand. I myself have dozens of the usepackage macro in my Emacs configuration, they hide and standardize the boilerplate that I could use instead. Nevertheless, I have serious reservations about macros in programming.
Taking a code base and expanding the macros to see whether that is more or less readable is a bit like expanding a C++ class hierarchy into assembly language and concluding that this program’s object oriented design is great because it is more readable than the resulting assembly language.
The real question is whether or not there are better alternatives than macros or metaprogramming in the first place. Functions, especially as found in modern languages[1], have proven to be very useful abstraction mechanisms and can often mitigate the lack of fancy macros.
I don’t want macros banned from Lisp, but I don’t miss them in other programming languages. Over exuberant use of fancy macros in Knuth’s brilliant TeX, in my opinion, contributes to the glacial pace of LaTeX development.
[1] By this I mean functions with circumscribed access to non local variables, provisions for choices of ownership of parameters, static scoping, first class functions, closures, and recursion.
- packetlost 4y agoAgreed. Metaprogramming does have it's place in languages like Lisp where it removes boilerplate or hides details that other programmers likely don't need/want to think about. However it's easy to go too far, which is really what I'm talking about. I think as long as you have first-class and variadic functions you can probably live without macros for like 98% of cases without compromising on readability (as is the case with Python). Alternatively, if you have an easy way to, at develop/compile time, identify exactly what a macro/metaprogram is doing I think it's ok, but that is subject to tooling.
- kazinator 4y agoPython acquires new macros in its parser. For instance, it now has pattern-matching macros which weren't there before. A few years ago it got a f'...' reader macro which wasn't there before.
- packetlost 4y agoSure, but Python doesn't let users write their own macros
- kazinator 4y agoSo if you're on an older Python, you can't backport the new syntax; you're forced to upgrade if you have some code which depends on it. In Lisp, if some code we would like to use depends on some newer macros offered by the Lisp dialect we are using, but we cannot move to a newer installation yet, we may be able to backport just the macros into our program. You're stuck with the ill-designed crap that Python puts out. For instance, I don't agree with pattern matching that assigns to existing variables; from where I'm sitting, it looks like an incompetent clusterfuck. If someone did that in one Lisp program, the entire language would be blamed for allowing that sort of "curse".
- kazinator 4y ago> The real question is whether or not there are better alternatives than macros or metaprogramming in the first place. Functions, especially as found in modern languages[1], have proven to be very useful abstraction mechanisms and can often mitigate the lack of fancy macros. The only relevant "better" in this debate is whether that would be more readable in those specific cases. People still make macros over functional solutions; e.g. the trick where a macro expands into just a function call to one or more generated lambdas which hold argument material. All macros expand to nothing but functions and special forms. TeX macros are just preprocessor cruft that is more closely related to C macros than Lisp macros. TeX and LaTeX are fragile mainly because of the semantically impoverished target language which just has global variables and conditionals. LaTeX macros are leaky; use them in the wrong place and they misbehave.