Comment by taeric | Hacker News Reader

Comment by taeric | Hacker News Reader

Parent Full thread

  This is a weak argument. Practically all languages 
  compound symbols made from multiple characters, such as
  >=; there is no shortage of symbols. Also, nearly all
  programming languages have a function-call notation, but
  only Lisp-based languages choose s-expressions to notate
  it, so saying “we need function call notation” do not
  excuse s-expressions.

I'm ironically going to complain that this is a weak rebuttal.

For one thing, I find it hilarious to see how well this predicted the explosion of silly operators in some of the current languages. (Haskel and Scala, I'm looking in your general directions...)

Second, the point is that all function calls now look the same. Both in serialized form and in parsed form. That is, the homoiconic nature is the point, no? To treat that as a somewhat byproduct is somewhat odd.

They then go on to posit the use of meaningful whitespace. Something that is quite disgusting to me. It is dreadfully easy to mistakenly read whitespace. To the point that I do think programs are textual art, and care should be used to structure them in a pleasant and easy to read way. However, I cannot bring myself to like meaningful whitespace. YAML has given me enough headaches in life in a scant year, that I am pretty firmly on the opposite side of that fence now.

> They then go on to posit the use of meaningful whitespace. Something that is quite disgusting to me.

Clearly not everyone agrees with this viewpoint, since Python depends on it and is extremely popular.

But if you don't want meaningful whitespace, that's fine. We actually devised three notations, each one a superset of the previous ones:

* curly-infix-expressions (c-expressions)

* Neoteric-expressions (n-expressions)

* Sweet-expressions (t-expressions)

Only the last one (sweet-expressions) is whitespace-sensitive.

More info here: https://readable.sourceforge.io/

This looks really nice! Are there any largish examples written with sweet-expressions? (Seeing large chunks of code could help with forming a gestalt impression)'

Edit: found one - https://sourceforge.net/p/readable/code/ci/master/tree/src/s...

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

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.

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

>However, I cannot bring myself to like meaningful whitespace. YAML has given me enough headaches in life in a scant year, that I am pretty firmly on the opposite side of that fence now.

The only time YAML gives me a headache with respect to whitespace is when I'm using block literals which have trailing whitespace. I don't think any other serialization format really deals with that problem well though - either you have a long, nicely readable block of text that looks ambiguous with trailing whitespace or you have a nasty escaped "long string with \n\n \n\'s" everywhere.

  Block literals: |
    are a killer feature, too.
    They are so damn useful when you have strings
    spanning multiple lines.

Meaningful whitespace means that syntactic clutter can be removed. That makes the markup much more readable because there's less distracting syntactic noise. YAML diffs are very readable, for instance, but JSON diffs (as well as diffs for every other kind of serialization format without meaningful whitespace), are very much not.

I can't remember the parts that pained me most. Some were in somewhat odd sounding "lists of single items" versus "list of single dict items" and such. In particular, the vast difference between:

  baz:
  bat: 
    - foo: bar

and

  baz:
    bat: 
    - foo: bar

is not at all obvious at a glance to me. If I convinced everyone to move to 4 or 8 character indents, it would stick out a little more, but I don't see myself winning that fight.

Worst of all, this mistake happened when I was moving some template from one place to another in a different file. Should be easy. Copy, paste, fix whitespace. The problem is that "fix whitespace" has to know about the copy/paste. You can't just reformat after the fact. Yes, tooling could "paste with indentation for current cursor" but you literally cannot "paste, then fix whitespace." It is like the worst of outlooks "paste with formatting".

I actually wrote a YAML parser that closed this loophole by raising an exception on YAML files that have inconsistent indents. Somebody reported exactly that as an issue on my issue tracker:

https://github.com/crdoconnor/strictyaml/issues/23

I'm aware that there are a bunch of annoyances like that, but I'm still convinced the core is good and making a new standard which is stricter solves most of these issues.

FWIW, I haven't run into this problem personally but it's pretty obvious that it is a problem.

Reply on news.ycombinator.com