4 ms·

My windmill is simply I still can't think in prefix for math. It's trivial for me to write x = (-b + sqrt(b^2 + 4 * a * c)) / (2 * a). But writing (setf x (/

My windmill is simply I still can't think in prefix for math. It's trivial for me to write x = (-b + sqrt(b^2 + 4 * a * c)) / (2 * a). But writing (setf x (/ (+ (- b) (sqrt (+ (* 4 a c) (* b b)))) (* 2 a))). That's a mind bender. Were this my source code, I'd probably put the (* 2 a) on the next line (properly indented) so it stood out as the divisor. All that said, honestly, the physical task of writing Lisp code is just so much better than anything else. There's something satisfying closing up all of the parens. And I just love using-hyphens-for-identifiers vs CamelCase or using_underscores.

Jach 4y ago
Fortunately doing infix math in CL has since the 90s been one small library include away: https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix
- jstimpfle 4y ago
  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
And if you're really desperate to write infix notation in Lisp, you can use CMU-INFIX [1]: #I( (-b + sqrt(b^^2 - 4*a*c))/(2*a) ) That is completely valid Lisp if you need it. In fact, you can change your editor to highlight #I(...) if you want it to stick out a little more since it's "different" than usual prefix notation. Suffice it to say, a binary expression like (+ b (* m x)) probably doesn't warrant bringing in a library, but if you're calculating orbital dynamics of the solar system, then perhaps having the above library would be useful. [1] https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix
tl 4y ago
> Were this my source code, I'd probably put the (* 2 a) on the next line (properly indented) so it stood out as the divisor. And that's exactly how written math does it (big bar for division of complex terms). Infix code notation has an extra set of '() around the numerator and denominator which helps in this specific case.
wwweston 4y ago
This is a really interesting point. What I'm seeing is that infix lends itself to chunking subterm "nouns" of the whole expression, where prefix/function is "verb oriented" and feels more like trying to remembering a series of dance steps rattled off by an instructor who knows them and can't remember what it's like to be a newbie. I don't know how much of this is not being used to "dancing" but being entirely used to dealing trees of infix terms.
medo-bear 4y ago
starting from infix equation a*x^2 + b*x + c = 0 x = (-b + sqrt(b^2 + 4*a*c)) / (2*a) is obviously conceptually clearer than (setf x (/ (+ (- b) (sqrt (+ (* 4 a c) (* b b)))) (* 2 a))) i however think the latter is computationally clearer. also i think the difference is most striking when we use well known infix formulas such as the quadratic formula. you would not have this effect with the cubic equation for example - https://en.wikipedia.org/wiki/Cubic_equation#Cardano.27s_method https://en.wikipedia.org/wiki/Cubic_equation#Cardano.27s_met...

Jach 4y ago

Fortunately doing infix math in CL has since the 90s been one small library include away: https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix

jstimpfle 4y ago
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

And if you're really desperate to write infix notation in Lisp, you can use CMU-INFIX [1]: #I( (-b + sqrt(b^^2 - 4*a*c))/(2*a) ) That is completely valid Lisp if you need it. In fact, you can change your editor to highlight #I(...) if you want it to stick out a little more since it's "different" than usual prefix notation. Suffice it to say, a binary expression like (+ b (* m x)) probably doesn't warrant bringing in a library, but if you're calculating orbital dynamics of the solar system, then perhaps having the above library would be useful. [1] https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix

tl 4y ago

> Were this my source code, I'd probably put the (* 2 a) on the next line (properly indented) so it stood out as the divisor. And that's exactly how written math does it (big bar for division of complex terms). Infix code notation has an extra set of '() around the numerator and denominator which helps in this specific case.

wwweston 4y ago

This is a really interesting point. What I'm seeing is that infix lends itself to chunking subterm "nouns" of the whole expression, where prefix/function is "verb oriented" and feels more like trying to remembering a series of dance steps rattled off by an instructor who knows them and can't remember what it's like to be a newbie. I don't know how much of this is not being used to "dancing" but being entirely used to dealing trees of infix terms.

medo-bear 4y ago

starting from infix equation a*x^2 + b*x + c = 0 x = (-b + sqrt(b^2 + 4*a*c)) / (2*a) is obviously conceptually clearer than (setf x (/ (+ (- b) (sqrt (+ (* 4 a c) (* b b)))) (* 2 a))) i however think the latter is computationally clearer. also i think the difference is most striking when we use well known infix formulas such as the quadratic formula. you would not have this effect with the cubic equation for example - https://en.wikipedia.org/wiki/Cubic_equation#Cardano.27s_method https://en.wikipedia.org/wiki/Cubic_equation#Cardano.27s_met...