4 ms·

I think you're writing it off as not actually being valuable in practice, which I don't think is fair. Should we consider Python's NumPy as not a feature of Py

I think you're writing it off as not actually being valuable in practice, which I don't think is fair. Should we consider Python's NumPy as not a feature of Python because it's not a built-in library? A commenter says they prefer to write infix math. Lisp has a completely ordinary, stable, well-known, 30-year-old library to do it. Thus the commenter's concerns are largely allayed. Not having it in the standard library means people have a choice to use it or not, and it also means one can't expect all Lisp code which has infix math to use it, but it certainly does not means the commenter will be perpetually hamstrung in reading and writing complicated math formulas.

lmm 4y ago
Macros are a cure that's worse than the disease. Unless everyone agrees on which set of macros you're using, you can't trust any code to mean what it looks like it means. (And if you could agree on which set of macros you were using, or what sanity-preserving restrictions you'd put on your macros, surely you'd just build those into your language).
- reikonomusha 4y ago
  In my experience, this is hyperbolic and not reflective of actual Lisp code people write or read. A lot of code is pretty straightforward: functions and classes. Some domains (like quantum computing) benefit from macros that introduce syntax that is broadly known to that domain's community, and would otherwise be opaque and inscrutable were it not for macros. Have people written bad, useless, nearly antagonistic macros? Sure, but that happens with any abstraction in any language, including humble functions.
  - lmm 4y ago
    Sure, because people have an intuition for what a macro should or shouldn't do. In practice you end up with an ad-hoc, informally specified, etc. implementation of half of a domain-appropriate language. Actually even (especially?) the general-purpose parts end up the same. Functions (at least in languages where they really are functions) are a lot safer; they're inherently compositional, and they follow the rules of the language. Most people have an intuition for what a macro should and shouldn't do, but there are very few guardrails that actually make that concrete, and often different team members will disagree about where the boundary between "sensible syntax sugar" and "inscrutable" lies.

lmm 4y ago

Macros are a cure that's worse than the disease. Unless everyone agrees on which set of macros you're using, you can't trust any code to mean what it looks like it means. (And if you could agree on which set of macros you were using, or what sanity-preserving restrictions you'd put on your macros, surely you'd just build those into your language).

reikonomusha 4y ago
In my experience, this is hyperbolic and not reflective of actual Lisp code people write or read. A lot of code is pretty straightforward: functions and classes. Some domains (like quantum computing) benefit from macros that introduce syntax that is broadly known to that domain's community, and would otherwise be opaque and inscrutable were it not for macros. Have people written bad, useless, nearly antagonistic macros? Sure, but that happens with any abstraction in any language, including humble functions.
- lmm 4y ago
  Sure, because people have an intuition for what a macro should or shouldn't do. In practice you end up with an ad-hoc, informally specified, etc. implementation of half of a domain-appropriate language. Actually even (especially?) the general-purpose parts end up the same. Functions (at least in languages where they really are functions) are a lot safer; they're inherently compositional, and they follow the rules of the language. Most people have an intuition for what a macro should and shouldn't do, but there are very few guardrails that actually make that concrete, and often different team members will disagree about where the boundary between "sensible syntax sugar" and "inscrutable" lies.