Don't Build Your Own Lisp
gist.github.comI wrote a Lisp in C and it worked out fine. It was pretty slow but had precise GC and was easy to extend. It was embedded in a commercial product that did ok.
I don't remember whether that was before or after I started absent-mindedly writing yet a different Lisp in C while hanging around RMS. He looked over my shoulder and asked what I was doing. I said writing a Lisp. He asked why I was doing that and I said everybody ought to write a Lisp. He thought about that for a few seconds, said "you should write it in assembler", and walked away.
The "Don't build your own Lisp" article seems reasonable to me and the book it negatively reviews ("Build your own Lisp", I guess) does sound bad.
> The author states, on how to engineer software:
It requires faith and intuition. Faith is required to believe that if the stars align, and every incantation is correctly performed for this magical machine, the right thing will really happen. And intuition is required to work out what has gone wrong, and how to fix things when they don’t go as planned.
Unfortunately these can’t be taught directly…
Sounds like the sqlite development method. Faith and tests. No architectural planning, and lots of desastrous FTS attempts.
Is it too much to ask that when giving a book review, a link to the actual book title, and possibly a listing on a website, should be prominently given?
The idea was probably that anyone reading the review would already be familiar with Build Your Own Lisp (<https://www.buildyourownlisp.com/>).
Fair enough for the original author, but if I'd been submitting this to HN, I would probably have included this information in the text field or something.
I feel like third or so of this critique could be subtitled "have I mentioned that I don't like C?".
there is that. but the more detailed points are pretty spot on. the overall picture I'm left with is that if you follow these instructions you're left with a much larger, more fragile, and semantically ambiguous lisp that if you had striven for parsimony.
fwiw I think C isn't a bad source language to make a toy tiny lisp. not because any of the things the author says aren't true, but part of the lesson (or joy) here is building semantic towers. there is a kind of mystery around HLLs, where things like memory management and function application are really magical. writing a lisp is Haskell isn't pointless, but at the same time you're kind of just decorating the cake instead of baking it. doing this in C lets you know that you can build heavyweight abstractions from effectively nothing.
but the right approach is probably to abuse C to make it take the shape of a lisp rather than build out a whole C-like intermediate to bridge the gap. and it should be less than 1k lines unless you're actually trying to build something useful.
Sure, I agree with you (and, for 2/3 of it, I don't much disagree with the OG). I just don't think articles like this hits as hard as it could when a significant portion of it is "now lemme talk about this pet peeve of mine, which I'm very committed to, even though it is at best tangential to purported topic I'm writing about". C may (or may not) be the worst of all possible languages to write a Lisp in (not touching that one :-)), but if you're gonna lecture me about writing a HLL, talk about the language, not dump a bunch of venom into an implementation detail. Or at least be up front and title it "Don't build your own Lisp in a language I hate" or something.
Well there's Make a Lisp [0]. And Lispy [1] and Lispy2 and Lisp.py [3].
[0] https://github.com/kanaka/mal [1] https://norvig.com/lispy.html [2] https://norvig.com/lispy2.html [3] https://khamidou.com/compilers/lisp.py
The dig at Kernel is kind of depressing. It's probably an evolutionary dead end, but god damn it, the world is better when people try things. Dismissing them doesn't make you cool.
I don't see any comments on Kernel in the post. I didn't waste my time reading the book, but the post criticizes unhygiene F-expr, which is known to be awful and is exactly what Kernel aims to solve and supersede (via hygiene F-expr).
“Functions use dynamic scoping. This is categorically a mistake, and one which ironically has been suggested to seriously mess up fexprs.” (links to Kernel)
It’s possible my interpretation wasn’t correct and the author was citing Kernel’s approach as sanity. That would make sense technically.
> It’s possible my interpretation wasn’t correct and the author was citing Kernel’s approach as sanity. That would make sense technically.
That's indeed what I meant, I meant the opposite of taking a dig at Kernel. My understanding is Shutt thought fexprs got a bad wrap because of dynamic scoping; quoth the Kernel website:
> they made a mess out of the language semantics because they were non-orthogonal to the ordinary variety of procedures constructed via lambda — and, more insidiously, because at that time the mainstream Lisps were dynamically scoped (a language feature that causes more problems for fexprs than it does for the less powerful macros).
My belated apologies for the ambiguity.
My belated apologies for the misunderstanding. The irony of me coming here and throwing shade on your work as a result is not lost on me.
That's what the author means. She know what she's talking about.
I never doubted that. It’s clear the author knows their shit.
What if its really fun though
I think I’ll make a Lisp that fits in just a single sector of a floppy disk. Oh wait …