The problem with scratch is that code visualization kinda dies on the vine for procedural programs.
For pure functional languages, each chunk of code is a world unto itself, and one can exploit this to make "visual proximity" correlate with "causal proximity". This is good for our eyes and brains because we don't have to look far to understand what is going in a certain part of a program.
The underlying reason this can work is that functional languages tightly couple syntactical proximity and causal proximity by design.
Because of hidden state, procedural languages can't. Instead, they have a tight mapping between syntactical proximity and temporal proximity (think back to BASIC and its line-numbers, which almost look like time-stamps).
Now, flat text source files aren't bad at preserving causal locality for functional languages. But because an intervening sub-expression can cause two parts of the same s-expression to be really far apart in a source file, they aren't great either.
We use indenting and code folding as a cue to mitigate this problem, but these techniques are really just telling us that flat text is the wrong medium to represent ASTs. Serializing a syntax tree to a string of characters will always spoil the party.
In theory, graphical code presentations can do better because they have an extra dimension to play with, so they can achieve the mapping from syntactical proximity to visual proximity more faithfully.
However, this 'pretty lisp' project doesn't do that. It's just another form of indenting. In a sense it is still stuck in the flat-text mindset.
I should mention I've done a bit of playing around of my own, though I haven't seriously tried to solve the graphical-AST challenge yet:
For pure functional languages, each chunk of code is a world unto itself, and one can exploit this to make "visual proximity" correlate with "causal proximity". This is good for our eyes and brains because we don't have to look far to understand what is going in a certain part of a program.
The underlying reason this can work is that functional languages tightly couple syntactical proximity and causal proximity by design.
Because of hidden state, procedural languages can't. Instead, they have a tight mapping between syntactical proximity and temporal proximity (think back to BASIC and its line-numbers, which almost look like time-stamps).
Now, flat text source files aren't bad at preserving causal locality for functional languages. But because an intervening sub-expression can cause two parts of the same s-expression to be really far apart in a source file, they aren't great either.
We use indenting and code folding as a cue to mitigate this problem, but these techniques are really just telling us that flat text is the wrong medium to represent ASTs. Serializing a syntax tree to a string of characters will always spoil the party.
In theory, graphical code presentations can do better because they have an extra dimension to play with, so they can achieve the mapping from syntactical proximity to visual proximity more faithfully.
However, this 'pretty lisp' project doesn't do that. It's just another form of indenting. In a sense it is still stuck in the flat-text mindset.
I should mention I've done a bit of playing around of my own, though I haven't seriously tried to solve the graphical-AST challenge yet:
http://taliesinb.net/the-structure-of-a-mathematica-package http://taliesinb.net/quicksort-in-61-characters