3 ms·

That's nice but we can all agree that it's not the same thing as a standard builtin syntax that everyone knows and is forced to use.

reikonomusha 4y ago
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.
Jach 4y ago
I can agree it's not the same, but what's the point? A more interesting disagreement is that I wouldn't say it's a downside (though yes, there are tradeoffs). Especially in Current Year when open source is fashionable and pretty much every language has a package manager to make pulling in or swapping out dependencies pretty easy, I don't see the issue. It's also interesting to note that of all the things Clojure did to "fix" shortcomings of past languages with a more opinionated (and often more correct I'll admit) design philosophy that users are forced to use (even when it's not more correct), infix-math-out-of-the-box wasn't one of them. I don't think that specifically really hurt Clojure adoption. (But of course Clojure is reasonably extensible too so it also has a library to get the functionality, though it's more fragile especially around needing spaces because it's not done with reader macros.) I've brought the library up many times because CL, unlike so many other languages, really lets you extend it. Want a static type system? https://github.com/coalton-lang/coalton/ https://github.com/coalton-lang/coalton/ Want pattern matching? No need to wait for PEP 636, https://github.com/guicho271828/trivia/ https://github.com/guicho271828/trivia/ If all that keeps someone from trying CL, or from enjoying it as much as they could because of some frustration or another, due to lacking <insert feature here> out of the box, chances are it is available through a library. (Or heck, even just tooling setup. Tab completion for symbols and jumping to function definitions are just two great things modern programmers enjoy in all sorts of languages, CL too, if someone doesn't have that setup I wonder if they must enjoy pain.)

reikonomusha 4y ago

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.

Jach 4y ago

I can agree it's not the same, but what's the point? A more interesting disagreement is that I wouldn't say it's a downside (though yes, there are tradeoffs). Especially in Current Year when open source is fashionable and pretty much every language has a package manager to make pulling in or swapping out dependencies pretty easy, I don't see the issue. It's also interesting to note that of all the things Clojure did to "fix" shortcomings of past languages with a more opinionated (and often more correct I'll admit) design philosophy that users are forced to use (even when it's not more correct), infix-math-out-of-the-box wasn't one of them. I don't think that specifically really hurt Clojure adoption. (But of course Clojure is reasonably extensible too so it also has a library to get the functionality, though it's more fragile especially around needing spaces because it's not done with reader macros.) I've brought the library up many times because CL, unlike so many other languages, really lets you extend it. Want a static type system? https://github.com/coalton-lang/coalton/ https://github.com/coalton-lang/coalton/ Want pattern matching? No need to wait for PEP 636, https://github.com/guicho271828/trivia/ https://github.com/guicho271828/trivia/ If all that keeps someone from trying CL, or from enjoying it as much as they could because of some frustration or another, due to lacking <insert feature here> out of the box, chances are it is available through a library. (Or heck, even just tooling setup. Tab completion for symbols and jumping to function definitions are just two great things modern programmers enjoy in all sorts of languages, CL too, if someone doesn't have that setup I wonder if they must enjoy pain.)