[reikonomusha]

I think it is a silver bullet of enlightenment of a certain understanding of what programming languages are. It is not a silver bullet for all of your programming tasks or problems.

Most people I know who cast off Lisp are people who read the Wikipedia page, didn’t feel enlightened, then began to complain online about how they were disappointed by their Lisp experience. Or perhaps they went a tad further, got upset by Emacs being unfriendly to setup, and proceeded accordingly.

In the Modern Age (TM), programming Lisp is unlikely to convince you to change your usual dev stack to it. But if learned properly, it will enlighten you on the structure of a language and how syntactic malleability is a powerful abstraction for solving many kinds of problems.

Enlightenment usually comes from realizing that it’s not a feature bolted onto Lisp, but an exposed interplay between many otherwise ordinary aspects of programming languages: syntax, semantics, interpretation, and the runtime. At this point one typically “sees” how this interplay could (and perhaps even opaquely does) play out with other, non-Lisp languages.

These kinds of things could in principle be learned in a compiler course, but compiler courses tend to be extraordinarily opaque as to how such a course would help your day-to-day coding. Lisp provides a visceral, hands-on experience of many (though certainly not all) of the same principles.

If you happen to be the kind of programmer who likes absolute control over your environment, because that helps you work through gnarly problems more efficiently than duct taping a bunch of dependencies together, then you may actually end up switching to Lisp.

[cat199]

> 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.

[lisper]

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.

[cat199]

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

[lisper]

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.