4 ms·

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.

• jjnoakes 9y ago
  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.
  • xfer 9y ago
    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?
    • jjnoakes 9y ago
      > 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.
  • pdkl95 9y ago
    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 https://github.com/Fanael/rainbow-delimiters [3] http://i.imgur.com/xS4y6rT.png http://i.imgur.com/xS4y6rT.png
    • steinuil 9y ago
      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.
      • soegaard 9y ago
        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])))
• dTal 9y ago
  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-like-scheme.html http://arcanesentiment.blogspot.co.uk/2015/01/if-scheme-were...
  • xfer 9y ago
    > 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)".
    • dTal 9y ago
      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.