Hacker News Reader

Comment by Oreb | Hacker News Reader

Like any language, Lisp has readability issues when you’re not familiar with it. You find it hard to read because it’s alien to you. To my eyes – because Lisp is what I’m used to – every non-Lisp language has readability issues. These days I do a significant amount of work in Python, Rust and Julia, and although there are things I love in all of these languages, I always miss s-expression syntax when using them.

View on HN

Infix notation can be useful for arithmetic; as a "Lisp person" I acknowledge that.

S-exps can be good for arithmetic too though.

S-expressions allow n-ary operators:

  (+ (* 3 x y) (* a b z w) (* r s t u v))

There is a systematic way to break up large expressions across multiple lines, which helps readability. Infix doesn't have a satisfactory way to do this:

  (+ (* 3 x y)
     (* a b z w)
     (* r s t  
        u v))

We see just from from the

   +  *
      *
      *

pattern that we have a sum of three products.

S-exps are unambiguous. You never misread an arithmetic (or any other) S-exp due to precedence, unless it's a macro that has created precedence rules among its arguments (vanishingly rare).

N-ary math functions associate left to right in Common LIsp: (+ a b c d) means we add (a b) first, then c, and d. This makes a difference when you have mixed types, which have to undergo conversions, and when you have non-associative types like floating-point.

If I'm cribbing some numeric calculation to use in my code (whether that code is Lisp or not), and have examples in half a dozen languages, none of which I use, I will crib it from that one that is a Lisp dialect, just because of the vanishingly small opportunity for getting it wrong due to some ambiguity issue.

This is a comment that I like, acknowledging the obvious unsophisticated but no less reasonable objection from the bystanders, and offering them an alternate viewpoint.

My reservation would be that most applications of arithmetic operators are binary and not ternary. A typical expression in one of my C programs at least has some function call, some subscript, some member access, some addition / subtraction / multiplication / division. But very few have more than one of each. Overall arithmetic is actually quite rare by itself in most code.

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.

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

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.

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.

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).

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.

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.

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/ Want pattern matching? No need to wait for PEP 636, 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.)

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

> 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.

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.

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_met...

"alien to you" Nope, but I do classify lisp/scheme next to Haskell, Icon/Unicon, and snowball... as ivory-tower languages. However, you wouldn't be the first person to spend 3 years of their lives failing to prove the assertion false.

Is there utility assuming everyone who doesn't share your opinion is an Alien? I find it just causes the 103rd purple proboscis to itch. ;)

Reply on news.ycombinator.com