3 ms·

There's a copious buttload of "understand foo" in this post. Is the author really recommending that a fledgling language developer should wait until they under

by pohl 16y ago

There's a copious buttload of "understand foo" in this post. Is the author really recommending that a fledgling language developer should wait until they understand all of those things before they initiate a lisp language development exercise? It feels like putting the pedagogical cart before the horse to me. Let's take languages, and therefore religion, out of the picture. Suppose someone was interested in text compression. Would it not be a good first exercise to write a Huffman compressor, even though the state of the art has moved on since? I just went through this exercise and found it to be very rewarding, despite the fact that I've understood the technique for decades. So what if some blowhard arithmetic compression fanatic on the Internet thinks I'm stupid for wasting fractional bits. Screw him. It's my exercise.

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 ago
  I 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 ago
  I 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 ago
    See 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.

by pohl 16y ago

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 ago
I 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 ago
I 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 ago
  See 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.