Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Breakdown of a new NES game written in Lisp

dustmop.io

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Technical Breakdown of a new NES game written in Lisp

#11

Post by savolai »

scrollaway wrote: post #9
ninkendo wrote: post #4

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

Also choosing a good wordpress theme helps a lot. :)

Re: Technical Breakdown of a new NES game written in Lisp

#12

Post by agentultra »

TurboHaskal wrote: post #8
nudpiedo wrote: post #6

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

Purity isn't in contrast with pragmatism; what Haskellers refer to as purity is referential transparency.

You can still do this kind of work in Haskell as well. It is a great imperative language.

Though as someone who has written assembler compilers in Common Lisp... it's felt relatively easy to do in CL. I've only heard people talk about writing control software for drones from Haskell. I have no idea how one would do that in practice though.

Re: Technical Breakdown of a new NES game written in Lisp

#13

Post by reikonomusha »

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.

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.

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.

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.

[0] http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pd...

Re: Technical Breakdown of a new NES game written in Lisp

#14

Post by zozbot234 »

reikonomusha wrote: post #13

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

If you aren't going to have a GC, "rich" runtime or lambda support, what does LISP really bring you over FORTH? And implementations of the latter on 6502 have been commonplace since the 1980s...

Re: Technical Breakdown of a new NES game written in Lisp

#16

Post by drcode »

I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#.

I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#.

Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I can then link to from clojurescript so that all unit tests and 90% of all QA testing can be done via clojurescript tooling, without any C# in sight.

This allows me to deploy a commercial game in "native" C# without any performance penalty, but with as few lines of C# as humanly possible.

Re: Technical Breakdown of a new NES game written in Lisp

#17

Post by shantly »

scrollaway wrote: post #9
ninkendo wrote: post #4

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

> The other side of that coin is that on mobile the article is painful to read and the layout is horrible.

Looks reader-mode-compatible in Safari, which solves the problem for any site that's mostly content.

Re: Technical Breakdown of a new NES game written in Lisp

#19

Post by mikepurvis »

drcode wrote: post #16

I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#. I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#. Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I ca…

This seems really complicated, relative to using the Clojure CLR port. Is it just not mature enough, or were there other advantages to going via JS?

Re: Technical Breakdown of a new NES game written in Lisp

#20

Post by drcode »

mikepurvis wrote: post #19
drcode wrote: post #16

I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#. I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#. Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I ca…

This seems really complicated, relative to using the Clojure CLR port. Is it just not mature enough, or were there other advantages to going via JS?

Using Clojure CLR would make the build process simple, at the cost of some complexity and likely a performance penalty in the deployed application.

On the other hand, my strategy makes the final deployed application dead simple and fast, but leads to a build process that's complex and messy.

It seems objectively true that the latter approach is going to be less risky, because if the final deployed game doesn't work well, the whole project is f###ed.

The only way to mitigate this risk and still stay with 100% Lisp is to create your own Lisp compiler, which is exactly what OP did... but that way lies insanity :)

Post reply on HN