3 ms·
Good question. The point is that "early LISP" was royally screwed in some important aspects. If you repeat these errors, then that may be harmful, and you're mi
by pwpwp 16y ago
Good question. The point is that "early LISP" was royally screwed in some important aspects. If you repeat these errors, then that may be harmful, and you're missing out on learning "how to do it right". Which is why I wrote the post.
- motxilo 16y agoI never underestimate the value of repeating well-known errors as a learning experience. Sometimes, a useful way to sink a new concept in is to address the original problem by yourself in the wrong way, and later apply the right techniques that were developed in order to solve it better. Design patterns come to mind.
- pohl 16y agoI grant that early LISPs were royally screwed. The main question in my mind is whether or not the cognitive footprint of the sort of language you are advocating is small enough to retain the same scope and approachability of the traditional ur-lisp exercise, even within an order of magnitude. By "cognitive footprint", of course, I'm including all of the research language esoterica you're saying that a fledgling language designer should understand before they crank out an ur-lisp. Have you considered quickly knocking one out for us so that we can all see what a minimally-viable language that includes all of your essential features looks like? I confess you have piqued my curiosity, and I'd love to see a model to emulate. Just so we're clear: I enjoy your writings on this subject. You rarely fail to expand my thinking.
- pwpwp 16y agoSee http://github.com/manuel/cyberlisp http://github.com/manuel/cyberlisp and http://github.com/manuel/ell http://github.com/manuel/ell for my takes on the subject. Judging from my experience, a full - but slow - Lisp compiler+runtime that does most of the stuff I wrote about should take about 5 KLOC.