Technical Breakdown of a new NES game written in Lisp
1–10 of 71 posts
Re: Technical Breakdown of a new NES game written in Lisp
#2One of the advantages of lisp is REPL-driven development. I imagine you can't just edit a fn, eval it and then see the changes immediately. What is the workflow like when creating a NES game using co2?
Re: Technical Breakdown of a new NES game written in Lisp
#3This is impressive. I appreciate you documenting the development of it and giving an overview of what's going on inside. I wish there were more blog posts like this. Have you reached out to the Racket community about the game and co2? Also, would you say this Lisp is geared more toward people who already know 6502 assembly, and not toward people who just want to write a NES game in a Lisp?
Re: Technical Breakdown of a new NES game written in Lisp
#4I know it's off-topic but I appreciate so much when somebody hosts their own blog rather than using Medium or some nag-ware hosting service.
I didn't get any pop-up "pardon[ing] the interruption" or asking me to join a mailing list, or anything! To think this used to be the normal way of doing things on the web.
Re: Technical Breakdown of a new NES game written in Lisp
#5I know it's off-topic but I appreciate so much when somebody hosts their own blog rather than using Medium or some nag-ware hosting service. I didn't get any pop-up "pardon[ing] the interruption" or asking me to join a mailing list, or anything! To think this used to be the normal way of doing things on the web.
[deleted]
Re: Technical Breakdown of a new NES game written in Lisp
#6This is a complete and absolute hack and I love it. When reading the README file of their github it is possible to see how "impure" pragmatic decisions were made like for loops and not supporting proper recursion. I wish there would be more projects like this one porting lisp runtimes to more and more hardware.
In the other hand the racket lisp behind the scenes _generates_ the assembly code based on some of the scheme primitives rather than porting its whole Racket runtime there, which in spite of not being the same as running a lisp in the NES hardware is still impressive.
Re: Technical Breakdown of a new NES game written in Lisp
#7I’d like to hear more about the compiled stack.
In extremely latency sensitive applications, the mix of stack and instruction cacheline faults can cause significant overhead.
Re: Technical Breakdown of a new NES game written in Lisp
#8This is a complete and absolute hack and I love it. When reading the README file of their github it is possible to see how "impure" pragmatic decisions were made like for loops and not supporting proper recursion. I wish there would be more projects like this one porting lisp runtimes to more and more hardware. In the other hand the racket lisp behind the scenes _generates_ the assembly code based on some of the sche…
Most Lispers and some Schemers are quite pragmatic in that regard. With the former favouring OOP and looping over recursion and the latter using imperative code when it matters.
With developer mindshare flocking to the Haskell view of FP, for the Lisp family, only the Clojure users seem to still hold purity in high regard.
Re: Technical Breakdown of a new NES game written in Lisp
#9I know it's off-topic but I appreciate so much when somebody hosts their own blog rather than using Medium or some nag-ware hosting service. I didn't get any pop-up "pardon[ing] the interruption" or asking me to join a mailing list, or anything! To think this used to be the normal way of doing things on the web.
The other side of that coin is that on mobile the article is painful to read and the layout is horrible.
For what it's worth I hate medium as well. But I would recommend ghost.org if you want to go with self hosting.
Re: Technical Breakdown of a new NES game written in Lisp
#10This is a complete and absolute hack and I love it. When reading the README file of their github it is possible to see how "impure" pragmatic decisions were made like for loops and not supporting proper recursion. I wish there would be more projects like this one porting lisp runtimes to more and more hardware. In the other hand the racket lisp behind the scenes _generates_ the assembly code based on some of the sche…
This reminds me of when the Infocom folks moved from the functional MDL to the micro-friendly ZIL, while keeping much of the syntax of the former: http://blog.zarfhome.com/2019/04/what-is-zil-anyway.html