Comment by taeric | Hacker News Reader

Comment by taeric | Hacker News Reader

Parent Full thread

I'd be surprised if python is winning folks over because of the significant whitespace. More that it just is not a deciding factor. (Note, I'm specifically not saying it is popular despite the whitespace.)

That is to say, yes, I recognize my opinion as just an opinion. Most of it is colored by bad experiences with large YAML files, I confess.

My problem with the code is precisely that it tears down my notion of the code being nothing more than a list of data. As an example, in:

  (define (factorial n)
    (if (<= n 1)
      1
      (* n (factorial (- n 1)))))

Everything that goes together is in the same list. Some things branch off of because they are part of another list. But all subexpressions are easily visible as just lists. I can take one out and try it somewhere else. How do I know they are lists? Because they look like every other list in the program. Begin and end with a paren.

The "improved one":

  define factorial(n)
    if {n <= 1}
      1
      {n * factorial{n - 1}}

How do I know it is over? How do I trace back to what part of the code is finished when I evaluated {n * factorial{n - 1}}? Hopefully, the code is short enough that these are obviously answered. However, I am well aware that sometimes this doesn't work. And, quite frankly, the brain power to find the matched paren is much less than the brain power to determine what lexical unit the compiler would have been in, and to scan up for the matching lexical unit.

Then there is the contrarian in me that is probably just getting annoyed that they labeled the proposal as the "improved" piece of code. :D

> How do I know it is over?

In an indentation sensitive syntax, you simply look at the next line and see if it has more or less or equal indentation. Then you're done. That turns out to be extremely fast, because the eye/brain combination is exceedingly good at determining if something is left or right or something else.

In traditional s expressions, to match things up you have to count the parentheses, which the brain is extremely bad at. In practice, the brain is so bad at this that we have to depend on complicated tooling to do the formatting for us. In a typical editor, that means that we depend on things like left-right distance anyway. Since people depend on indentation in the first place, making it syntactically relevant simply applies what people already do to the syntax itself.

You somewhat skip my point. You agree that you know it was over by parsing the structure. Which you have to do in both cases. In one, though, the parser rules are more than, scan for last paren. Gets more complicated once you have stuff like the <* symbols resetting indentation and blank line rules. Or the $.

Not to say it can't be done. But I could easily argue the brain is bad at juggling rules. The more rules, the more likely mistakes. Since I am typically building rules in the logic, having extra rules in parsing seems to require more of where I will likely make mistakes.

To be clear, I am presenting my preference. I am not trying to claim superiority.

> But I could easily argue the brain is bad at juggling rules. The more rules, the more likely mistakes.

The brain isn't great at LEARNING rules, but the vast majority of programming languages use more rules than Lisp, and since most people use those other languages instead, it's clearly possible to learn more rules than the ones Lisp provides. Indeed, Lisp's syntax currently insists that you not use infix notation, which means in practice people have to learn a new syntax. Practically every other language (with the exception of Forth) supports infix notation.

The "$" has essentially the same meaning as Haskell, so if you know Haskell's rule, you already know it. The "blank line ends the block" is what most people would assume anyway. The <* ... *> ones are unusual, but they don't take long to learn or master, and counter a complaint about indentation ("stuff marches off to the right").

It's hard to argue preferences. Ideally we'd have some scientific studies really examine these kinds of issues! Sadly, those kinds of studies are in short supply.

Thanks for the commentary.

> Then there is the contrarian in me that is probably just getting annoyed that they labeled the proposal as the "improved" piece of code. :D

Well, we think it's improved. Of course, what matters is "how you measure improvement" :-). Like anything else in engineering, there are always trade-offs, and you have to figure out what you value in the trade.

That said, here are a few ways I'd argue it is better: 1. It uses standard infix notation, instead of non-standard prefix notation. The standard worldwide notation for mathematics uses infix, as do practically all programming languages. That means practically all math books use infix, and most adults have over a decade of training in infix. The majority of programmers are never going to switch to a language that doesn't support infix notation. 2. Similarly, it uses a more-standard notation for function calls, e.g., "factorial(n)" instead of "(factorial n)". I don't think that's as big a deal, but it helps. It doesn't use "," for parameter separation (it could, but the extra commas are unnecessary and dangerously hide other uses of ","). 3. You don't need to figure out "did I match all the parens" when reading the code - instead, the visual layout tells you everything. Many developers don't like all the parens and find them to be an impediment to understanding (Google "Lots of Irritating Silly Parentheses"). If you don't like the whitespace layout, fine, you can use n-expressions instead of sweet-expressions.

The broad impact of these changes is that these notations retain all of Lisp's power (macros, quasiquoting, etc.), but look much more like a modern programming language. That matters, because software development today is normally done in groups - anything that makes code harder to read is a serious problem.

I agree in general that sexps provide the best editing experience currently, but that's just a matter of tooling, it's not an inherent property of sexps vs infix or whitespace-dependent syntax.

Check out [0], a structured editing mode for Haskell, a whitespace-sensitive language.

Incidentally, while I have no problem with Lisps (I've used Clojure for about a year), I do prefer infix notation, precisely because it's not homogeneous.

[0] https://github.com/chrisdone/structured-haskell-mode

You likely prefer infix because it is familiar. It is amazing how much familiarity influences preference.

And yes, tooling can help. For either case. I'm leaning towards simpler tooling, which means me towards s-exps. Mainly because a lot of time has passed, and evidence is structured editing just doesn't take off in other languages. And I don't see requiring tooling as an improvement.

Yes, familiarity influences preference, and infix is familiar.

Almost all adults who develop software have had 12 to 20 years of practice using infix notation as a standard part of mathematics, and it's also a standard part of practically all programming languages except Lisp and Forth. It's possible to notate calculations without infix (obviously!), but that doesn't mean that people WANT to do it. It's absurd to fight against the worldwide standard of infix notation for standard math operations like "+".

For most people, {2 * {3 + 4}} is easier to understand than (* 2 (+ 3 4)). If a Lisp reader simply treats {...} as a list, where the operator is the even positions, then you have the best of both worlds: standard infix notation combined with Lisp's ability to do quasiquoting, macros, etc.

Reply on news.ycombinator.com