HtDP was written to address difficulties with learning from SICP https://cs.brown.edu/~sk/Publications/Papers/Published/fffk-...

I have gotten much farther (and accordingly learned more from HtDP). It is accurate to think of it as an on ramp for SICP.

As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup

How would you write this in Lisp without introducing a bunch of parens? `if (0 <= x + m && x + m <= n) {…}`

I’m not a Lisp hater, but there’s a reason people make this criticism. I think most people find the infix version easier to read.

It is only function calling that needs (,); in C and () in Lisp. Which is half as many characters, but much much much noisy since:

    - it is used everywhere
    - carries very little information

    - in Janet nearly every line starts and ends with ( and ), which is just noise
    - in Janet there are several ))))
    - in Janet there is no special syntax for: function definition, variable definition, collections, statements
    - while Python is the opposite, it reads like a mix of English and Mathematics. Also it has special syntax for the ~5 things that you can do with the language, so you can just look at the Python code from far, don't read it, and you'll have a clue what's going on. It is also helpful when you search for something with your eyes. Also nested parentheses are different shaped parentheses, so you know which ones match.

[0] : https://news.ycombinator.com/item?id=34846516

Plus, don't forget the secret sauce of Lisp syntax: same number of parentheses, with none of the commas. Nor the semicolons. Nor the brackets. Nor the braces.

[dead]

> I just don't understand the fixation with REPL

Perhaps because maybe you just haven't used one? I'm not talking about "a REPL" in langs like Python, where you typically have to type stuff into it. Lisp REPLs allow evaluating code directly in the source buffer, by sending it into the REPL. That REPL can be remote. Like seriously remote - NASA once did it on a spacecraft 150 million miles away from Earth. We run ours in a kubernetes cluster. Lisp REPL allows you to evaluate specific expressions, functions, or regions directly from where you are. Without saving, linting, linking, compiling, etc.

> because you don't understand it by yourself.

REPL is not about "understanding your code", it's about interactive development and exploration - it allows you to test your ideas and assumptions in real-time. Imagine being able to send http request, pull some good chunk of data, and then sort it, group it, slice it, dice it, filter it, visualize it - do whatever you want to do with it, directly from your editor. It's incredibly empowering and extremely liberating.

The only downsides - after getting used to that, using non-lispy languages sucks all the joy out of programming and you also have to explain to people what it is like.

It's like moving to an island where people have never discovered salt, pepper, and other spices, and though their cuisine looks beautiful - you just can't describe to them what they all are missing. Some even may say - "Hey, I've tried pepper once - but I don't understand your fixation with it" and you'd be like: "have you ever tried putting it into your food?"

> It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.

That doesn't even make any remote sense. "I don't get the fixation with the JVM. It sounds like you write code as a black box, then compile and run it to see what it does because you don't understand it by yourself."

> I don’t understand why representing data in an s-expression is better than representing it as nested arrays (lists of lists) and hashtables/dictionaries.

An s-expression is a list. An s-expression like (list (list 1 2) (list 3 4) (list 5 6)) is a list of lists. An s-expression like (hash "a" 1 "b" 2) is as hash table/dictionary.

> I also don’t see why representing data in a language’s data structure is inherently better than representing it in a language-agnostic format like JSON

You don't see why having a language data structure like Date is better than having a date-string stored in a JSON value that you need to provide parsing and other functions for? If you have a language data structure like Date, you can add days to a date, extract the month, convert it to a DateTime, etc. If you just have a JSON value, you either need to provide those functions or convert your JSON value to the Date language data structure. It seems like you see the value in using the language's data structure because you then say:

> having libraries to parse and convert data from that format into a language data structure

Also, JSON is just as "language agnostic" as s-expressions. JSON happens to be a first class component of JavaScript, as s-expressions are a first class component of Lisp; if libraries exist to help you deal with JSON in other languages, so, too, can libraries exist to help you deal with s-expressions.

> I’m struggling to understand what the tangible benefits are.

I think you understand the tangible benefits of JSON? It is a human readable/writable data serialization format. It is integrated in JavaScript in such a way that you can easily serialize, parse, and extract data from it without reaching for a library. S-expressions within Lisp do that, but they don't limit you to strings, floats, arrays, and unsorted maps. You don't need to write conversion functions or use them from a library because reading and writing s-expressions are core parts of Lisp.

Hash tables or dictionaries can be S-expressions.

Some Lisp dialects do not have printed-representations for these; that is a bug, and needs no further discussion.

Common Lisp and Scheme have vectors: they are notated as #(...). That is an S-expression.

CLISP has a #<N>A(...) notation for multidimensional arrays, which it can print and read:

  [8]> (make-array '(2 2) :initial-element 0)
  #2A((0 0) (0 0))

  [2]> (let ((x 42)) `#2A((,x 0) (0 ,x)))
  *** - READ: unquotes may not occur in arrays

  [11]> (let ((x 42)) `#(0 ,x 0))
  #(0 42 0)

Hash literals look like this in TXR Lisp:

  1> #H(() (a 1) (b 2) (c 3))
  #H(() (a 1) (c 3) (b 2))

Binary search trees are likewise printable. The #T notation gives a tree (concealing the nodes). The #N notation for individual tree nodes:

  1> (tree)
  #T(())
  2> (tree-insert *1 1)  ; *1 means value from repl line 1
  #N(1 nil nil)
  3> (tree-insert *1 3)
  #N(3 nil nil)
  4> (tree-insert *1 7)
  #N(7 nil nil)
  5> (tree-insert *1 4)
  #N(4 nil nil)
  6> (tree-insert *1 2)
  #N(2 nil nil)
  7> (tree-insert *1 8)
  #N(8 nil nil)
  8> (tree-insert *1 0)
  #N(0 nil nil)
  9> *1
  #T(() 0 1 2 3 4 7 8)
  10> (tree-root *1)
  #N(3 #N(1 #N(0 nil nil) #N(2 nil nil)) #N(7 #N(4 nil nil) #N(8 nil nil)))

  11> #T(() 3 2 1)
  #T(() 1 2 3)

  12> (tree-root *11)
  #N(2 #N(1 nil nil) #N(3 nil nil))

The printed notation of any object in a Lisp is a S-expression. S-expression syntax usually strives for print-read consistency: when an object's printed notation is read by the machine, a similar object is recovere. (In some cases, the original object itself, as with interned symbols).

It wouldn't. The consumer would need to know to expect a date as a string and parse it.