Scheme Programming Lessons from Tarot | Hacker News Reader

Scheme Programming Lessons from Tarot

rain-1.github.io

64 pointsmabynogy18 comments

When I read the headline I had hoped this would be about esoteric but useful programming lessons learnt from Tarot deck divination.

Part two: https://rain-1.github.io/scheme-2

Part three: https://rain-1.github.io/scheme-3

This uses a difference list data structure, which, when I learned it in Prolog, requires lazy evaluation of the tail of the list.

Erlang doesn't seem to allow lazy evaluation; am I wrong about that? Is there some way to do difference lists in Erlang?

Correction: it needs unbound variables, not lazy evaluation. Erlang doesn't have unbound variables; I suspect one would have to implement some form of that before implementing difference lists.

Scheme syntax is so arcane that it appears divination by tarot cards is a viable option to understanding it.

Like numerology and magic number'd Clang ;)

We get it. Y'all don't like the parens and long function names.

Yet 98% (prior knowledge pulled out of my posterior) of lisp haters never spent more than zero seconds actually trying to figure it out.

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.

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.

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])))

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.

Scheme's syntax is really easy to parse/generate programatically, so there's no need to read/write it by hand if there's some other syntax you prefer.

Reply on news.ycombinator.com