[pebblexe]

The only thing you need to do to understand lisp's entrancement is to write an interpreter for it, and in doing so you'll see why it's easier to write a lisp interpreter than it is for any other language. All you need to understand the appeal is a look at https://github.com/kanaka/mal.

Personally I learned the appeal of lisp while following this tutorial on writing a scheme in Haskell: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_.... There's a reason there'll never be a tutorial like that for a toy Haskell interpreter.

[kazinator]

That whole argument "you have to write your own Lisp and then you will see the light" is completely wrongheaded and should be retired. Any computing person with two brain cells to rub together sees red flags in it. Did you build your own bicycle from scratch before understanding the wonder of riding a bicycle? The way Lisp is taught is wrong too; students in some courses are given too many exercises involving hypothetical scenarios in which some half of Lisp is missing and they have to put it back.

A Scheme that someone wrote in 48 hours following a tutorial isn't something I'd want to use in production. It's missing the whole angle of Lisp being a feature-rich, mature language suitable for production use.

A Lisp is valuable because of what you don't have to write in it to get the job done.

[wtbob]

You're arguing against the concept that writing one's own Lisp is necessary, and you're right: it's not necessary to implement Lisp to appreciate it.

The post you replied to, OTOH, was arguing that writing one's own Lisp is sufficient, and I think it's right: if one implements Lisp from scratch, one will end up appreciating Lisp. Outside of half-assed homework assignments, anyway.

[kazinator]

What people need isn't sufficient so much as efficient.

To appreciate Lisp (or anything) is really to appreciate the underlying requirements (and that they are done).

Some people absorb requirements very well (and then appreciate them) if they force themselves to implement the requirements, which is fine. Even those people can't just confine their appreciation to that which they're able to implement, because then the scope of their appreciation will be rather small.

I really appreciate John Carmack's approach to determining shadow maps for a scene: the clever "cast a ray from a point on the surface to infinity and determine whether it intersects a shadow volume boundary an even or odd number of times" so then you know whether it's in the shadow volume (w.r.t a light source) or not. So we go backwards from a pixel on the screen, to some point on an object's surface. For each such point (consequently pixel) we can determine whether it's in shadow; and we can reduce that to a 2D shadow map in pixel space. Terrific, right? And about the shadow volumes, they are basically just conical shapes made using the 2D contour of the objects as seen from the POV of the light source, and capped at the end somewhere so they are finite. I'm not going to sit here and implement it all though. It's not that I couldn't find the time but that it's out of scope. I can play it out in my head though and see it working which is a good enough facsimile.

[pebblexe]

I don't mean to imply that I've done this (aside from copypasting from that wikibook). I just think that understanding why it's easy to do this for lisp is important.

[tdeck]

Interestingly this is also true of FORTH, which is why we have hundreds of poorly documented FORTH compiler/interpreters and almost no decent libraries or actual programs written in FORTH.

[pebblexe]

I agree entirely with that.