lispy

This is what happens when a mediocre programmer reads too many Paul Graham essays, hacks his way through a couple of sections of SICP, and shamelessly rips off Peter Norvig's code in chapter 2 of PAIP.

Kids these days.... ;)

...But more than likely just reinvent something that Guy Steele wrote a paper on in the seventies. ^_^

This is an exercise that's being done just for the fun of it to explore what (for me) were cryptic remarks from people like Graham and Norvig.

I wanted to work on something that would force me to write macros. Obviously, to make the code for "classes" that construct object generating functions like the one in the example will be written by... macros. So I successfully put myself in a situation where macros were the natural answer... and saw what I needed to do. My getting to that particular ah-ha moment was the real message of the post. I can now begin to understand what the experts are talking about.

So I can now use closures and macros to make lisp just as crappy as other programming languages... or I can use this knowledge to learn more about doing things "the lispy way." Trust me when I say that the latter option is my preference.

I'm just an amateur that's excited about these ideas... and that you _can_ do this sort of thing. I'm not saying that you _should_.

Yes, the its the feature of closures that is important, and so much not the particular language that it's implemented in. (As Mark Jason Dominus said, "In another thirty years people will laugh at anyone who tries to invent a language without closures, just as they'll laugh now at anyone who tries to invent a language without recursion.")

A hash table in a closure can do a lot of things that OOP does with very little work-- but I wouldn't necessarily do things that way except for the fun of it. There are certainly much more interesting/subtle/powerful things that can be done with closures.