Live data from Hacker News

I built a Game Boy emulator in F#

nickkossolapov.github.io

21–30 of 84 posts

Re: I built a Game Boy emulator in F#

#21
post #17

Finally someone putting in actual human effort to learn something, and not a LLM helped me build X in Y minutes. There is some hope for humanity after all I suppose.

It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.

Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good functional designs is that they are declarative, not imperative, so in some sense you're really just stating what you want, at finer and finer granularities, until what you want is trivial.

Even when I want code written in a different language (e.g., C/C++), I often still start by making a prototype in F#. This helps me nail down the logic without having to worry about things like allocation or layouts. Perhaps I could ask an AI to do this second step for me, and then use the F# implementation as an oracle. Anyway.

Re: I built a Game Boy emulator in F#

#22
post #21
post #17

Earlier quoted context omitted.

It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.

Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good fun…

I'm of the mindset that you can use AI however you want to get the speed improvements you're looking for. Personally, I use Agile methods to incrementally implement manually testable features, refine and debug, then commit. Then I use another chat/agent to keep tabs of the overall progress (giving it a summary from the agent that did the work), and then move to the next task by asking the coordinator to draft a prompt for the next bit of work I describe.

Re: I built a Game Boy emulator in F#

#23

mildy related but wasn't there an emulator (maybe not GB but NES or SNES?) which had a visual panel showing each CPU cycle step by step? afaik it was very slow but the 1000% accuracy was the goal not playability.

My guess is you're thinking of no$gmb, a very early Game Boy emulator:

https://gbatemp.net/threads/no-gmb-2-5-dos-full-version.6039...

I've got fond memories of using this to get a preview of Pokemon Gold before it was released in NA!

Re: I built a Game Boy emulator in F#

#25
post #4

That's so cool! I love F#, but I wrote a little Smalltalk interpreter in it and I can confirm it isn't exactly a speed demon for that kind of thing if you use it as intended lol

Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a tail call throws a compiler error so you can't accidentally screw that up).

Re: I built a Game Boy emulator in F#

#27
post #18
post #6

Earlier quoted context omitted.

I've found that with F#, I get better performance if I do dumb imperative stuff, but keep the side effects within a function. At that point, the functions can basically be "pure" but you can get decent speed. For example, I usually like using the `Map` data structure, and that's a pretty neat immutable structure and is usually fine for most stuff, but when performance becomes critical, it's easy enough to break into…

Yes! That's exactly how you should do it while working with a language that doesn't have a compiler that will aggressively analyze, and rewrite and optimize your code for you. (So, most languages with "heavy runtimes" that support a bunch of dynamic stuff and JITs) There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable s…

Yeah, and even if you need concurrency/parallelism within the function, it can be forgivable to use ConcurrentDictionary or ConcurrentBag or one of the many, many other thread safe mutable data structures built directly into .NET.

I will personally almost always prefer the pretty functional versions of things, and that's almost always what I start with. I like immutable data structures, and they are usually more than fast enough. Occasionally, though, you hit a bottleneck of some kind (usually in some form of loop), and you have to avoid all the beautiful functional stuff and go back to sad imperative stuff. When I do that, I usually try and keep it scoped to one function. Even within one function, I do find the persistent structures easier to reason about, but as you stated it's a small enough surface area to not be too irritating.

There are exceptions to this, of course. Sometimes for caching/memoizing I will make a global ConcurrentDictionary, and I'll use the interlocked thing to do global counters sometimes.

Re: I built a Game Boy emulator in F#

#29
post #17

Finally someone putting in actual human effort to learn something, and not a LLM helped me build X in Y minutes. There is some hope for humanity after all I suppose.

It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.

But it already has a name; this noble art is called "programming", or better yet: "hacking".

Re: I built a Game Boy emulator in F#

#30
post #17

Earlier quoted context omitted.

It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.

But it already has a name; this noble art is called "programming", or better yet: "hacking".

Languages evolve
Post reply on HN