Ask HN: What Is the Lisp “Enlightment”?

#1

Post by armchairguy » Mon, Aug 08, 2022, 8:53 AM UTC

Every time I read about Lisp I hear about the _enlightment_ phase, but what is it?

I checked Lisp and what stands out most for me is the syntax and the powerful REPL but aside from that, why is it so praised compared to modern languages? I don't see many projects using it either aside from certain exceptions.

Apologies for my ignorance _in advance_

Re: Ask HN: What Is the Lisp “Enlightment”?

#2

Post by scrapheap » Mon, Aug 08, 2022, 9:36 AM UTC

I think that the enlightenment phase of Lisp is different for everyone, so you're going to get some varied responses.

Learning Lisp certainly improved the way I write code in other languages and moved me to a more functional style of programming. So while I don't regularly code in Lisp, I do use a lot of concepts that can be traced back to Lisp.

Re: Ask HN: What Is the Lisp “Enlightment”?

#3

Post by whent » Mon, Aug 08, 2022, 9:41 AM UTC

For me Lisp enlightenment was when I realized everything is lambda all the way down (except of course for lists and atoms). I mean we don't really need all the various fancy let, let*, defun expressions to do programming. let, defun are all just abstractions on top of LAMBDA expressions. That means that we don't need some 30 odd keywords to bootstrap a language like we do in C. We can bootstrap a language implementation with some 8 or so special forms and everything else can be defined in terms of those. Isn't that beautiful?

Re: Ask HN: What Is the Lisp “Enlightment”?

#4

Post by dusted » Mon, Aug 08, 2022, 9:42 AM UTC

For me, it was the realization that with LISP, you don't really build much of anything because you're caught in the blinding light of beauty, and the perfect program is the one that never gets written.

Re: Ask HN: What Is the Lisp “Enlightment”?

#5

Post by xyzzy123 » Mon, Aug 08, 2022, 9:52 AM UTC

That code is just data.

In lispalikes, code has the same "shape" as any other data.

The compiler / language environment and the runtime environment are "blended" in a much more natural way than is usual.

Re: Ask HN: What Is the Lisp “Enlightment”?

#6

Post by lordwarnut » Mon, Aug 08, 2022, 10:02 AM UTC

dusted wrote: post #4

For me, it was the realization that with LISP, you don't really build much of anything because you're caught in the blinding light of beauty, and the perfect program is the one that never gets written.

The program that can be written is not the eternal program. The script which can be run is not the eternal script.

Re: Ask HN: What Is the Lisp “Enlightment”?

#7

Post by freemint » Mon, Aug 08, 2022, 10:03 AM UTC

Thinking about ASSERTS FILL-IN-THE-BLANKS requires more meditation.

You have not yet reached enlightenment.

    A koan is incomplete.

Please meditate on the following code:

    File "koans/asserts.lisp"

    Koan "FILL-IN-THE-BLANKS"

    Current koan assert status is "(INCOMPLETE INCOMPLETE INCOMPLETE)"

You are now 0/198 koans and 0/31 lessons closer to reaching enlightenment.

Re: Ask HN: What Is the Lisp “Enlightment”?

#8

Post by [deleted] » Mon, Aug 08, 2022, 10:20 AM UTC

[deleted]

Re: Ask HN: What Is the Lisp “Enlightment”?

#9

Post by tromp » Mon, Aug 08, 2022, 10:30 AM UTC

whent wrote: post #3

For me Lisp enlightenment was when I realized everything is lambda all the way down (except of course for lists and atoms). I mean we don't really need all the various fancy let, let*, defun expressions to do programming. let, defun are all just abstractions on top of LAMBDA expressions. That means that we don't need some 30 odd keywords to bootstrap a language like we do in C. We can bootstrap a language implementat…

> lambda all the way down (except of course for lists and atoms)

List and atoms can be defined in terms of lambdas as well (see e.g. [1]).

You don't need any special forms at all. Perhaps we should talk about Lambda Enlightenment?

[1] https://www.ioccc.org/2012/tromp/hint.html

Re: Ask HN: What Is the Lisp “Enlightment”?

#10

Post by erik_seaberg » Mon, Aug 08, 2022, 10:32 AM UTC

Lisp is 64 years old. In some ways its reputation is oversold. A lot of features (GC, varargs, lexical scope, closures, higher-order functions, dynamic method dispatch, reflection) first gained prominence in Lisp, despite being extravagantly expensive. Some optimizations were found, computers became vastly more powerful, and now those innovations are merely table stakes for any modern language.

IMHO the biggest exception is macros. Lisp isn’t the only language that has them, but it’s still the easiest by far if you ever want a domain-specific language to concisely express some problem. The grammar of its special forms is simple enough that we can easily use the symbol and linked-list builtins to generate boilerplate expressions or functions for the compiler without fighting with in-memory parse tree nodes or generating entire files of syntactically valid source.