Technical Breakdown of a new NES game written in Lisp
This was an incredibly enjoyable read. A lesson to take away is that many of the ideas of Lisp can be taken advantage of without reeling in the entirety of an existing stack.<p>Writing a Lisp parser is easy. Walking Lisp code is easy. Serializing Lisp code is easy. Adding a new primitive is easy. Adding very basic syntax transforming macros is easy. All of these are virtually trivial if your host language is a Lisp, as was the case with Co2.<p>What they didn’t do is what many people might think are table stakes with Lisp: writing a garbage collector, writing a runtime, supporting lambdas, and so on. Those are unreasonable asks for 2K RAM on a 6502. I wouldn’t say they wrote a bonafide Lisp, but they made use of many ideas of Lisp successfully to write a game that is very surprisingly readable while not being too abstract over assembly.<p>Since Lisp began in the 1950s, it has always needed to stay tied to the low level. Even today, with SBCL or CCL, you can write your own assembly code. One relevant thing to the article is Baker’s COMFY 6502 language for writing assembly code [0]. A few implementations can be found on GitHub.<p>[0] <a href="http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pdf" rel="nofollow">http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pd...</a>