Pyramid[1] was based on the last chapter of SICP, was executable after a couple weeks, and I had never written any lisp before(outside of a couple hours playing

Pyramid[1] was based on the last chapter of SICP, was executable after a couple weeks, and I had never written any lisp before(outside of a couple hours playing with Scheme once). Most of that time was the code generator. An interpreter is much simpler and you could have something similar in a couple hours. Especially if you use a JSON parser to start, and switch to S-expressions once you get everything working. Or use an existing Lisp with a (read) primitive that knows the syntax. As for "why Lisp?", it's a bit like how you never need to read the JSON spec to write JSON in practice, because they unified the syntax into a few core datatypes(primitives, arrays, objects). Besides the simple syntax, they also include a symbol table core concept that tells you how to interpret the minimal syntax. In most languages, it's a lot of work adding a new feature to the language: Lexer to recognize token, backtracking parser, adding a new internal type, etc. In a Lisp interpreter, you just edit the symbol table to know about a new form and you're done. Despite the core being simple, a practical Lisp environment is going to have thousands of primitives with a variety of effects on the runtime, and you'll need to look them up. Racket has about 1700[2] implemented in Chez Scheme, for example. But at least they're "only primitives", so there's uniformity in how they're used. Nothing like "What's the syntax for an anonymous function that takes 1 callback as argument that captures a local by reference and 3 other variables by value?" [1] https://www.michaelburge.us/2017/11/28/write-your-next-ethereum-contract-in-pyramid-scheme.html https://www.michaelburge.us/2017/11/28/write-your-next-ether... [2] https://github.com/racket/racket/blob/master/racket/src/cs/primitive/kernel.ss https://github.com/racket/racket/blob/master/racket/src/cs/p...