Hacker News Reader

Comment by xfer | Hacker News Reader

yeah, s-exprs are very hard, right? compared to bazillion new keywords that can't be used by user programs and various kinds of brackets for different purposes.

View on HN

Nobody mentioned s-expressions, and there's more to lisp syntax than that. The s-expressions have to mean something, and it is at this level that usability is made or broken.

Scheme is beautiful, but it sacrifices usability for purity. Common Lisp, on the other hand, is usually held to be both "ugly" and "better for real work(tm)".

Here's a nice blog post that highlights the practicality issue with Scheme's design.

http://arcanesentiment.blogspot.co.uk/2015/01/if-scheme-were...

> Here's a nice blog post that highlights the practicality issue with Scheme's design.

That post complains about numerical tower not belonging to some library and being more generic. I don't understand how that is more/less practical.

Common-lisp also has a numerical tower afaik. I don't understand how does that make it "better for real work(tm)".

Dude, you completely missed the point of that post. It literally says in the second sentence that Scheme's numeric tower was borrowed from Common Lisp. The point is that if Scheme's numbers were like the rest of Scheme, they would be horribly impractical.

Some people find s-expressions hard to read because they are almost too uniform. Having different brackets and braces mean different things can aid those folks.

There are languages that allow user-defined syntax and aren't only parenthesis/s-expressions, so arguing one requires the other is a false dichotomy.

Did i claim that one requires the other?

Some people also find it very hard to memorize bazillion syntax rules.

Comparing understanding scheme is equivalent to "divination by tarot cards" is a bit ridiculous, don't you think?

> Did i claim that one requires the other?

Sure sounded like it:

"compared to bazillion new keywords that can't be used by user programs"

> Comparing understanding scheme is equivalent to "divination by tarot cards" is a bit ridiculous, don't you think?

I never said otherwise.

Often the information that different brackets and braces would represented in other languages becomes the shape of the s-expressions. I find that easier to parse than most[1] languages. With rainbow-delimiters[2] (example[3]), parsing nested parens becomes far easier.

[1] Ruby is a rare exception.

[2] https://github.com/Fanael/rainbow-delimiters

[3] http://i.imgur.com/xS4y6rT.png

In Racket and other Schemes parens and square brackets are interchangeable. The Racket style guide suggests to use square brackets in let- or cond-like expression, or generally any expression with a list of lists of fixed length that are not supposed to be evaluated. The expression you posted would become like this:

    (do ([i 1 (+ i 1)])
        ((> i 100))
      (display
        (cond [(= 0 (modulo i 15)) "FizzBuzz"]
              [(= 0 (modulo i 3))  "Fizz"]
              [(= 0 (modulo i 5))  "Buzz"]
              [else                i]))
      (newline))

I personally think this helps a lot with the problem of parsing s-expressions visually.

Also: It is rare to use `do`.

    #lang racket
    (require math)

    (for ([i 100])
      (displayln
       (cond [(divides? 15 i) "FizzBuzz"]
             [(divides?  3 i) "Fizz"]
             [(divides?  5 i) "Buzz"]
             [else            i])))

Reply on news.ycombinator.com