4 ms·

> Simplicity can hurt readability, for example, by utilizing too few distinctive visual patterns - fewer than human brain can easily distinguish while scanning

> Simplicity can hurt readability, for example, by utilizing too few distinctive visual patterns - fewer than human brain can easily distinguish while scanning code There's a bit of a tradeoff. I tend to agree with you that there is at least an initial readability hit when looking at most Lisp code. However, that's something that can be managed with a bit of experience reading/writing the syntax and some care taken with the way you write the code. The benefit of the Lisp syntax comes in that its regularity makes it easier to make tools that manipulate it in higher order fashions. (Paredit mode and macros being two examples that immediately come to mind.) Not only does the syntax make it easier to write those tools, the syntax makes it easier for developers in the moment to understand what those tools actually mean and how they operate on code. The trouble with all this for Lisp is that the costs are immediately evident, but the benefits all accrue on a longer time scale. It's a style of language that rewards patience and long term investment in a world that does not necessarily favor either.

int_19h 9y ago
IMO, the ease of manipulating Lisp code comes from that code being internally represented as a tree. But that doesn't mean that the syntactic representation has to be so closely mapped to that underlying tree. Syntactic sugar is good! In fact, it's so good that even Lisp has some - you still write '(1 2), even though your macro will see (quote 1 2). My point is, essentially, that raw S-exprs, or even S-exprs with the usual Lisp extensions, are too "bitter" - there's not enough syntactic sugar there to have them go down smoothly. For a very extreme opposite example, consider R. Under the hood, any R program is represented as S-expr style tree (the corresponding data type is "call" - but it's basically just a linked list of arbitrary objects, including other call objects, and its interpretation is exactly like a Lisp S-expr - first item is what we're invoking, the rest are arguments). Then on top of that they have created a C-style syntax. But that syntax is pure syntactic sugar - there's an exact one-way mapping from it to the actual call tree, and there's a canonical back-mapping as well. And you can skip the syntax and write everything in pure calls if you really wanted to. Now, I'm not claiming that this is the sweet spot. But I'm pretty sure that S-exprs aren't it, either. It feels like there can be some middle ground, where the original tree structure is still fairly recognizable, but also with enough sugar that common patterns (e.g. variable bindings, function definitions, conditionals etc) are easy to parse visually.
- lispm 9y ago
  > '(1 2), even though your macro will see (quote 1 2). '(1 2) is (quote (1 2)), not (quote 1 2) > that common patterns (e.g. variable bindings, function definitions, conditionals etc) are easy to parse visually. Actually those Lisp patterns are not difficult to parse for humans. It's just that it looks a bit unfamiliar for non-Lisp users. The human visual system is capable to deal with that quite easily, it just might take learning. Humans can for example read book pages very fast even though there are very little visual clues in long sequences of text. It's just that humans have read a lot of those books... The visual pattern for variable binding in Lisp is: LET var value var value var value expression expression expression That pattern is easy to spot visually. In actual Lisp code it is: (let ((var value) (var value) (var value)) expression expression expression) The top-left item defines the structure of the rest. That item is easy to find. Here it is LET. All you need to know is what item has what pattern. There are a few basic patterns and combination of those. Once you learn about 10 - 20 of those patterns and understand that something like `WITH-FOO` will give you a clue what pattern to expect, then it is fairly easy to read Lisp. Typical patterns: function call sequence binding list with scope tree if function calls property list association list conditional expression and some more...
  - int_19h 9y ago
    At this point we're basically both making unsubstantiated assertions. Anecdotally, I know that I was able to learn to read C, Pascal, BASIC etc fast much easier than I was able to learn to read Scheme fast. I've asked this question to other people, and it seems to be a common thing. From this I conclude that visually parsing Lisp is more taxing. Yes, you may train yourself to do so fast - but you end up spending more time and effort on that. Again, this is anecdotal. A proper way to resolve this question would be to have a controlled study where a bunch of people not previously exposed to any language is given a crash course in, say, S-exprs and JSON, and then asked various data retrieval tasks on input of increasing complexity.
    - lispm 9y ago

int_19h 9y ago

IMO, the ease of manipulating Lisp code comes from that code being internally represented as a tree. But that doesn't mean that the syntactic representation has to be so closely mapped to that underlying tree. Syntactic sugar is good! In fact, it's so good that even Lisp has some - you still write '(1 2), even though your macro will see (quote 1 2). My point is, essentially, that raw S-exprs, or even S-exprs with the usual Lisp extensions, are too "bitter" - there's not enough syntactic sugar there to have them go down smoothly. For a very extreme opposite example, consider R. Under the hood, any R program is represented as S-expr style tree (the corresponding data type is "call" - but it's basically just a linked list of arbitrary objects, including other call objects, and its interpretation is exactly like a Lisp S-expr - first item is what we're invoking, the rest are arguments). Then on top of that they have created a C-style syntax. But that syntax is pure syntactic sugar - there's an exact one-way mapping from it to the actual call tree, and there's a canonical back-mapping as well. And you can skip the syntax and write everything in pure calls if you really wanted to. Now, I'm not claiming that this is the sweet spot. But I'm pretty sure that S-exprs aren't it, either. It feels like there can be some middle ground, where the original tree structure is still fairly recognizable, but also with enough sugar that common patterns (e.g. variable bindings, function definitions, conditionals etc) are easy to parse visually.

lispm 9y ago
> '(1 2), even though your macro will see (quote 1 2). '(1 2) is (quote (1 2)), not (quote 1 2) > that common patterns (e.g. variable bindings, function definitions, conditionals etc) are easy to parse visually. Actually those Lisp patterns are not difficult to parse for humans. It's just that it looks a bit unfamiliar for non-Lisp users. The human visual system is capable to deal with that quite easily, it just might take learning. Humans can for example read book pages very fast even though there are very little visual clues in long sequences of text. It's just that humans have read a lot of those books... The visual pattern for variable binding in Lisp is: LET var value var value var value expression expression expression That pattern is easy to spot visually. In actual Lisp code it is: (let ((var value) (var value) (var value)) expression expression expression) The top-left item defines the structure of the rest. That item is easy to find. Here it is LET. All you need to know is what item has what pattern. There are a few basic patterns and combination of those. Once you learn about 10 - 20 of those patterns and understand that something like `WITH-FOO` will give you a clue what pattern to expect, then it is fairly easy to read Lisp. Typical patterns: function call sequence binding list with scope tree if function calls property list association list conditional expression and some more...
- int_19h 9y ago
  At this point we're basically both making unsubstantiated assertions. Anecdotally, I know that I was able to learn to read C, Pascal, BASIC etc fast much easier than I was able to learn to read Scheme fast. I've asked this question to other people, and it seems to be a common thing. From this I conclude that visually parsing Lisp is more taxing. Yes, you may train yourself to do so fast - but you end up spending more time and effort on that. Again, this is anecdotal. A proper way to resolve this question would be to have a controlled study where a bunch of people not previously exposed to any language is given a crash course in, say, S-exprs and JSON, and then asked various data retrieval tasks on input of increasing complexity.
  - lispm 9y ago