Hacker News Reader

Comment by didibus | Hacker News Reader

After learning s-expression based syntax, I am just baffled why we even bother with anything else.

When you play around with different Lisps, the syntax is always the same, the language differences becomes the semantics only.

Other languages put too much emphasis on the syntax in my opinion. And while I understand the "popularity" appeal. I've almost never seen someone learning the s-expression syntax and afterwards not liking it.

Basically I think it be worth it to push people to learn the s-expression syntax just so we can stop wasting our time with syntax afterwards.

Also if I recall, without user macros, I think s-expression syntax is context free no?

View on HN

> I've almost never seen someone learning the s-expression syntax and afterwards not liking it.

I don't particularly like s-expression syntax - I think s-expressions suit the computer at the expense of the programmer, which I think is backwards. I think they're verbose and noisy and that obscures the meaning I want to see in the text as a person. Yes they're easier to parse, but I want to make my life easier, not the computers. And yes they're convenient for metaprogramming but I don't want to optimise for the meta case.

A concrete example - I'm very happy working with precedence. I've been doing it since I started school. My five-year-old can understand precedence. Using precedence I can reduce ceremony and noise in my code and allows me to more naturally look at an expression and take in its meaning. But s-expressions don't like using precedence.

> s-expressions don't like using precedence

I'd rather say that in s-expressions, precedence is regular and explicit. To me that's a strong argument in favor of it being more widely accepted as the standard.

With infix notation, operators have implicit precedences, which feel natural to us only because it's what we were taught from an early age.

I'm with the parent comment, that s-expressions ought to be advocated and evangelized (haha), as a foundational approach - even with arithmetic in basic school. If we had started thinking with it as a child, or at least later able to shed the legacy of infix notation, s-expressions are objectively simpler to understand, with fewer things to keep in mind.

Well, that sounds stronger than I meant to. I mostly write in infix-style languages, and they flow fine. But I ideologically align with Lisps - there's a conceptual simplicity and beauty that really should have been the mainstream, and still may in the future.

You might argue that s-expression syntax is "worse is better" but I'd argue that more complex syntaxes are "accidental complexity." You need a parser, you need a more complex prettyprinter.

Without s-expressions you also lose programmer access to the parse tree.

For the usual arithmetic operators I've never had any problem, but I was once caught out when programming in C by getting the precedence of << and >> wrong (at least to me, it's counterintuitive), and it took a few hours to find the bug, because my code looked correct. Had I just parenthesized everything, that bug wouldn't have happened.

Do you mean precedence or infix?

The choice of infix vs prefix vs postfix is semantic. What s-expression syntax imposes is to have everything balanced between brackets. For example, nothing prevents an S-expression based language to allow:

(2 + 3)

The only thing is there are no precedence rules, you must have parenthesis always:

((3 * 2) + 5)

Why are you trying to explain s-expressions to me like I’ve never heard of them when I’m already in a thread debating their pros and cons for language design and implementation?

I'm sorry that you are getting defensive and feeling like I'm attacking your expertise. But there's all kind of people with different experience levels on HN, so I prefer asking for clarification when I can instead of assuming things and talking over each other.

If you truly meant precedence, well, I guess I disagree with you. Even in math, I prefer explicit parenthesised expressions for readability.

If you meant infix, that's not a concern of s-expression so it's irrelevant to the syntax question.

I know that personal preference is basically the reason for various syntaxes off course. But I think similar to how there's a movement that a common standard code formatting is better than everyone having their own custom formats, you could argue that having a common syntax which I think s-expression would make a great common syntax, could also yield an overall better outcome. And that's my argument here.

Most languages have a: here's an s-expression based version of it. Like Python has Hy, Lua has Fennel, etc. So you already see a trend in how s-expression could easily cover all those languages, which is normal since they get closer to the parse tree anyways.

This reminds me of the debates in college (late 1970's) of RPN calculators vs Infix calculators.

RPN's big advantage was reduced number of keystrokes, which is important with a calculator. But when dealing with formulas where you can actually type with a keyboard the number of keystrokes is not important, readability is much more important, and infix wins.

> I've almost never seen someone learning the s-expression syntax and afterwards not liking it.

I'm a counterexample. Sorry :-)

It's whatever you're used to, but using sexprs means you don't need to write parsers because you have the read function. In Lisp, it's important to give the user access to the parse tree.

Since the S-expression syntax for Lisp was chosen, there have been at least three documented attempts to replace it: Lisp 2, CGOL, and Dylan. Lisp 2 syntax wasn't implemented and was only ever used in textbooks, and CGOL and Dylan were never popular and are no longer used. All Lisps today use S-expressions (but Clojure has [] and {} as well as ()), as do some Prologs, as well as a few other languages such as CLIPS. Readability is taken care of by the prettyprinter.

For arithmetic expressions, I agree infix is easier to read because that's what maths uses. For complex formulae, I wrote a Lisp macro which accepts infix notation and I'm sure other Lispers have done likewise.

> I'm a counterexample. Sorry :-)

Haha, fair enough, I did say "almost" ;)

That said, I should have specified, that spent enough time. Like there is a certain amount of time needed to get your brain to really adapt, and generally it's after that period that I've rarely seen anyone not like it. But I admit this might suffer from selection bias, the only people who stick with it long enough for their brain to adapt might be the people who like it.

It's simple, but it's fundamentally reductionist. You can ease the cognitive load by making certain programming structures first-class citizens in the language.

> You can ease the cognitive load by making certain programming structures first-class citizens in the language.

Which, in every s-expression based language I'm aware of, can be achieved using macros.

Isn't that the point - s-expressions aren't good enough so people work around them by writing more conventional languages and parsers (the reader macros) to avoid having to write in them.

I don't think that comment was about reader macros. I don't see reader macros used much, while normal macros are frequently used to create new control structures.

Yes but now you have to worry about parentheses and at what nesting level certain constructs should live.

An adequate editor with autoindent and paren matching solves those problems completely.

FWIW, I've learned s-expressions and never particularly liked them either. I like their elegance, sure, but I found working with them to be cumbersome in practice.

Reply on news.ycombinator.com