Don't Build Your Own Lisp
6 hours ago
- #C Programming
- #Lisp Critique
- #Interpreter Design
- The book has a flawed premise, advising first-time interpreter writers to use C, which is error-prone and unsuitable for language development.
- The book's implementation decisions produce a Lisp dialect that is poorly defined, making it impossible to write correct programs or form a mental model of the language.
- Parsing is made unnecessarily complex by using a parser generator instead of a simple recursive descent parser, which is more appropriate for Lisp's minimal syntax.
- Error handling in C is inadequately addressed, and the book fails to teach robust error reporting, leaving programs prone to crashes without useful diagnostics.
- The interpreter uses dynamic scoping, which is a significant design flaw that breaks lexical scoping and leads to unpredictable behavior and poor encapsulation.
- The object representation is inefficient, with each Lisp object consuming at least 88 bytes, negatively impacting performance due to cache ineffectiveness.
- The book confuses the semantics of the language with the interpreter's implementation, conflating features like parsing and data types unnecessarily.
- The use of q-expressions as an alternative to macros is criticized for complicating syntax and breaking the principle of code as data in Lisp.
- Advice on software engineering, such as relying on faith and intuition over testing, is deemed unhelpful and contradictory to modern practices.
- The book contains misinformation about garbage collection and allocators, with poor benchmarks that misrepresent performance comparisons.