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.
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.