Hacker News new | ask | show | jobs
by cat199 2233 days ago
> syntactic malleability

this is the key point - not quasi/proto FP

most comments I see that are skeptical of the 'lisp as magic' claim seem to focus on the quasi-FP-ability of lisp, leave out the fact that the lisp family is pretty much unique when it comes to symbolic programming, and then optionally go on to talk about how some typed functional non-symbolic language is a better functional language.

this is ignoring the 'too many parens', 'no market share', and 'doesnt work well in my editor' people.

1 comments

Syntactic malleability is actually a red herring. The key insight of Lisp is: Lisp code is not text. Lisp code can be serialized as text, and it can be parsed from text, but it is not text, it is S-expressions, and S-expressions are not text, they are data structures, specifically, they are trees of cons cells. And because they are trees of cons cells you can construct them without ever constructing any text, i.e. without any parsing.

Syntactic malleability is a consequence of this property of the language. It is not in and of itself the central idea.

good point..

though arguably if code is data we are somewhat saying the same thing :)

in any event, this unique overall property/combination of properties is often overlooked in these discussions

The "code is data" slogan also misses the point. Text is data, so all code is data, whether or not it's Lisp code. (The only code that isn't data is code that has been compiled down to hardware. In the olden days computers were programmed by plugging wires into plugboards. That code wasn't data. But any code that is rendered in the same medium as the data it processes is data, and nowadays that includes all code.)

What matters is that text is structured fundamentally differently from trees of cons cells. Text is a vector of characters. It is a fundamentally flat data structure. It is well suited for humans to read and write with pencil and paper, or chisels and stone tablets. It is not natively suited for describing hierarchies of abstractions, which, it turns out, is what you want when you're writing code.