3 ms·
It's a bit like claiming that riding a bicycle is hard because steering, moving forward and keeping balance at the same time is too difficult. Yet, people learn
by lispm 8y ago
It's a bit like claiming that riding a bicycle is hard because steering, moving forward and keeping balance at the same time is too difficult. Yet, people learn it and do it just fine. They just don't think consciously about it. Riding a bicycle takes a bit of training but after that the body movements are virtually effortless.
Lisp is slightly more difficult than some other languages because lists/symbols are both used in code and data, because there are a bunch of different types of lists, and because code is a token tree.
(defun silly (a b c) (let ((my-sum (+ a b c))) (* my-sum (+ 1 my-sum))))
Now what's wrong with that? Nothing. But people don't write that.
Lisp is written like that:
(defun silly (a b c)
(let ((my-sum (+ a b c)))
(* my-sum (+ 1 my-sum))))
There are a limited amount of tokens on a line. Syntactic constructs are not one line.
Any definition has this pattern:
(DEFsomething name ...)
Oh, it begins with DEF, then it is a macro, followed by the name.
Function definitions have this pattern:
(DEFun name arglist body)
The code layout is:
(defun name arglist
body
...)
A method defintion:
(DEFmethod name arglist
body
...)
The difference between a function and a method is in the arglist.
LET is:
(LET binding-list
body
...)
Now you need to know what a binding list is:
((arg0 value0)
(arg1 value1)
...
(arg2 value3))
Such a binding list is used in other places, too.
If you give shortcuts to it:
df function definition
bl binding list
nm name
bd body
al arglist
DEFUN:
df nm al
bd
LET
LET bl
bd
PROG
prog bl
bd
lambda
LAMBDA al
bd
DESTRUCTURING-BIND
DESTRUCTURING-BIND al
form
bd
BLOCK
BLOCK nm
bd
CATCH
CATCH nm
bd
etc.
Basically much of Lisp consists of a small number of basic patterns which are being combined. lists, assoc lists, property lists, arglists, binding lists, body, ...
You've learned then a new alphabet of visual/structural patterns. Beyond that, code reading gets intuitive. Names give a clue what kind of pattern combination follows.
The IDE can then help with syntax highlighting, syntax documentation display, etc.
Lisp can even show you useful code layout:
CL-USER 68 > (let ((*PRINT-RIGHT-MARGIN* 30))
(pprint '(defun silly (a b c) (let ((my-sum (+ a b c))) (* my-sum (+ 1 my-sum))))))
(DEFUN SILLY (A B C)
(LET ((MY-SUM (+ A B C)))
(* MY-SUM (+ 1 MY-SUM))))
- heinrichhartman 8y agoThanks for this elaboration! Obviously there is lot of community know-how, that I am not aware of. Thanks for explaining them in detail. Learning to spot all those pattern is crucial if you want to be come effective at reading lisp. For the untrained eye lisp code often looks horrid. I don't think we disagree, though. All I am saying is that: "Riding the Lisp bicycle has been difficult for me. Here one thing I struggled with a lot." Maybe other people have the same difficulty and find this helpful.
- lispm 8y agoRight, you need to train yourself with these visual/structural tree patterns. The code does no longer look horrid and the parentheses will go away. You were not knowing that there is actual structure and thus you could not see the forest through the trees.
- kazinator 8y agoThis is subjective. I came to Lisp with a background in C, C++ and numerous other things, none of them like Lisp. Lisp looked very good and highly readable; I liked it very much right away and was able to hit the ground running.