3 ms·
> '(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 defi
by 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 agoAt 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 agoMost people don't put much effort into it. Since you learned C, Pascal, Basic, ... you already had expectations how a program looks like, how it works and how to develop code. People also hear that Lisp is difficult to learn and exotic, this creates another negative bias. The next problem when learning Lisp is that the whole combination of syntax, semantics and pragmatics is new. Thus people might be able to read the code, but they have difficulties understanding the meaning, given that prior exposure to other programming language might not help here. They also may not be familiar with he particular interactive style of development and not see the advantages of working with code as data. The typical old saying is that everybody can learn the basics of Lisp in a day, unless one already knows FORTRAN, then it takes three day. The best way to get over these hurdles is to read and write a substantial amount of code. Luckily Lisp has some great books to learn from.
- kazinator 9y agoA page of C that conforms to common coding conventions does next to nothing. I can read it fast: "oh this is yet another reinvention of getting a line of arbitrary length from a FILE stream". Look; there is the realloc, the getc, the doubling in size of the buffer. There, I read it in 3 seconds! Three weeks later, I spot the failure to null-terminate the line in a corner case ...