7 ms·

It’s not “actually” a worse situation except in some pathological academic sense. The point of a macro is to make some idea clearer to understand by way of synt

It’s not “actually” a worse situation except in some pathological academic sense. The point of a macro is to make some idea clearer to understand by way of syntax. If it’s not doing that, it’s probably a bad macro.

lmm 5y ago
If you restrict yourself to a reasonable-to-understand subset of possible macros - such as those that could be expressed as monads in Haskell - then a reader that knows that you've so restricted yourself can work in your codebase without understanding all your macros (as long as you don't have any bugs in your macro implementations). But in that case why use a language with macros?
- aidenn0 5y ago
  You can teach someone to use the built-in loop macro without using the term "macro." It's far more hairy and complicated then any non built-in macro you will encounter in the wild. Literally the only time I worry about macro vs special operator vs function is when doing higher order programming, which is less common in lisp than Haskell
  - lmm 5y ago
    You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?
    - aidenn0 5y ago
      > You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? Because sometimes writing a simple macro makes it easier to write (and read) other code. > If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system? There's a lot to unpack here. A good lisp developer will very rarely need to write a macro that approaches the complexity of the loop macro. Firstly, that's not never. Being able to write a hairy macro is more like an air-bag than power windows. You're glad to have it when you need it, but you mostly forget its there the rest of the time. Secondly the same macro system that lets you write something like loop also lets you write simpler macros that make code both easier to read and harder to write incorrectly. Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system. There are also plenty of people who think loop is too complicated and too inflexible and so avoid it. Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators? I don't actually see the extensibility of lisp as its "killer feature" but I definitely see it as a net positive, while a lot of people seem to see it as a net negative. I blame books like "Let Over Lambda" which are more to be seen as examples of what you can do rather than what you should do. There's lots of things to hate about C, but the fact that you can do: enum { TRUE = 0, FALSE=1 }; is not one of them. There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them.
      - lmm 5y ago
        > Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators? IMO the essence of good language design is balancing expressiveness with enough constraint to make code understandable. I agree that printf is a mistake (string interpolation is enough of a special case that it's better as a language-level builtin). As for itertools I'd say that I do write code that's just as complex as the itertools builtins, but also that the itertools builtins don't hurt code readability so much because they're all (more or less) legitimate functions that can be reasoned about compositionally. Code that contains a call to a complex itertools builtin is not particularly hard to understand, because even the most complex itertools builtin returns a plain(ish) value that obeys simple rules. Not so for code that contains a call to a complex macro. > Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system. "complex macro" system rather than complex "macro system", but yeah, I expressed myself badly. The problem isn't complexity per se (and as you say, the actual system is very simple) but that it's an unconstrained one where a macro can do almost anything. > There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them. I disagree. In my experience the main reason people give for moving away from lisp on any given project is "maintainability", and if you dig a little deeper that usually boils down to "we wrote too many bad macros". And a lot of the "limited tooling" complaints boil down to the effectiveness of IDEs etc. being limited by the presence of macros.
        kazinator 5y ago
        > a macro can do almost anything A program can do almost anything; that's the result of internal Turing completeness, plus unfettered external platform access. Macros do not cause this. A program can do anything using nothing but functions. Macros are supposed to be used when they organize some particular anything in a way that makes it easier to understand and maintain (or even more performant) compared to the best available macro-free approach. Everything can be abused: control structures, data structures, functions, variables, ...
    - deleted 5y ago
      [deleted]
Zababa 5y ago
> The point of a macro is to make some idea clearer to understand by way of syntax. The question I think is clearer for who? Macros, as all abstractions, seem to be a way to make the expert faster at the expense of the beginner. Lisp is probably better at avoiding accidental complexity coming with it, but I don't think it avoids complexity entirely.
- kazinator 5y ago
  The way to settle this, at least for a given macro or macros, is to bring the expert and beginner together, and have both of them examine the macro calls, their documentation, and a version of the code in which the macro calls have been replaced by their hand-written expansions.

lmm 5y ago

If you restrict yourself to a reasonable-to-understand subset of possible macros - such as those that could be expressed as monads in Haskell - then a reader that knows that you've so restricted yourself can work in your codebase without understanding all your macros (as long as you don't have any bugs in your macro implementations). But in that case why use a language with macros?

aidenn0 5y ago
You can teach someone to use the built-in loop macro without using the term "macro." It's far more hairy and complicated then any non built-in macro you will encounter in the wild. Literally the only time I worry about macro vs special operator vs function is when doing higher order programming, which is less common in lisp than Haskell
- lmm 5y ago
  You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?
  - aidenn0 5y ago
    > You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? Because sometimes writing a simple macro makes it easier to write (and read) other code. > If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system? There's a lot to unpack here. A good lisp developer will very rarely need to write a macro that approaches the complexity of the loop macro. Firstly, that's not never. Being able to write a hairy macro is more like an air-bag than power windows. You're glad to have it when you need it, but you mostly forget its there the rest of the time. Secondly the same macro system that lets you write something like loop also lets you write simpler macros that make code both easier to read and harder to write incorrectly. Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system. There are also plenty of people who think loop is too complicated and too inflexible and so avoid it. Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators? I don't actually see the extensibility of lisp as its "killer feature" but I definitely see it as a net positive, while a lot of people seem to see it as a net negative. I blame books like "Let Over Lambda" which are more to be seen as examples of what you can do rather than what you should do. There's lots of things to hate about C, but the fact that you can do: enum { TRUE = 0, FALSE=1 }; is not one of them. There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them.
    - lmm 5y ago
      > Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators? IMO the essence of good language design is balancing expressiveness with enough constraint to make code understandable. I agree that printf is a mistake (string interpolation is enough of a special case that it's better as a language-level builtin). As for itertools I'd say that I do write code that's just as complex as the itertools builtins, but also that the itertools builtins don't hurt code readability so much because they're all (more or less) legitimate functions that can be reasoned about compositionally. Code that contains a call to a complex itertools builtin is not particularly hard to understand, because even the most complex itertools builtin returns a plain(ish) value that obeys simple rules. Not so for code that contains a call to a complex macro. > Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system. "complex macro" system rather than complex "macro system", but yeah, I expressed myself badly. The problem isn't complexity per se (and as you say, the actual system is very simple) but that it's an unconstrained one where a macro can do almost anything. > There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them. I disagree. In my experience the main reason people give for moving away from lisp on any given project is "maintainability", and if you dig a little deeper that usually boils down to "we wrote too many bad macros". And a lot of the "limited tooling" complaints boil down to the effectiveness of IDEs etc. being limited by the presence of macros.
      - kazinator 5y ago
        > a macro can do almost anything A program can do almost anything; that's the result of internal Turing completeness, plus unfettered external platform access. Macros do not cause this. A program can do anything using nothing but functions. Macros are supposed to be used when they organize some particular anything in a way that makes it easier to understand and maintain (or even more performant) compared to the best available macro-free approach. Everything can be abused: control structures, data structures, functions, variables, ...
  - deleted 5y ago
    [deleted]

Zababa 5y ago

> The point of a macro is to make some idea clearer to understand by way of syntax. The question I think is clearer for who? Macros, as all abstractions, seem to be a way to make the expert faster at the expense of the beginner. Lisp is probably better at avoiding accidental complexity coming with it, but I don't think it avoids complexity entirely.

kazinator 5y ago
The way to settle this, at least for a given macro or macros, is to bring the expert and beginner together, and have both of them examine the macro calls, their documentation, and a version of the code in which the macro calls have been replaced by their hand-written expansions.