←back to thread

Writing a Game Boy Emulator in OCaml

(linoscope.github.io)
202 points ibobev | 4 comments | 04 Jul 25 09:34 UTC | HN request time: 0.946s | source
Show context
derefr ◴[04 Jul 25 15:59 UTC] No.44465643[source]▶
Would anyone here assert that there's any particular programming language that's better for writing emulators, virtual machines, bytecode interpreters, etc?

Where, when I say "better", I'm not so much talking about getting results that are particularly efficient/performant; nor in making fewer implementation errors... but more in terms of the experience of implementing an emulator in this particular language, being more rewarding, intuitive, and/or teaching you more about both emulators and the language.

I ask because I know that this sort of language exists in other domains. Erlang, for example, is particularly rewarding to implement a "soft-realtime nine-nines-of-uptime distributed system" in. The language, its execution semantics, its runtime, and its core libraries, were all co-designed to address this particular problem domain. Using Erlang "for what it's for" can thus teach you a lot about distributed systems (due to the language/runtime/etc guiding your hand toward its own idiomatic answers to distributed-systems problems — which usually are "best practice" solutions in theory as well); and can lead you to a much-deeper understanding of Erlang (exploring all its corners, discovering all the places where the language designers considered the problems you'd be having and set you up for success) than you'd get by trying to use it to solve problems in some other domain.

Is there a language like that... but where the "problem domain" that the language's designers were targeting, was "describing machines in code"?

replies(10): >>44465651 #>>44465842 #>>44465906 #>>44465934 #>>44466249 #>>44466377 #>>44466464 #>>44466501 #>>44467885 #>>44468314 #
johnnyjeans ◴[04 Jul 25 16:25 UTC] No.44465842[source]▶
sml, specifically the MLTon dialect. It's good for all the same reasons ocaml is good, it's just a much better version of the ML-language in my opinion.

I think the only thing that ocaml has that I miss in sml is applicative functors, but in the end that just translates to slightly different module styles.

replies(2): >>44466166 #>>44467643 #
1. wk_end ◴[04 Jul 25 17:07 UTC] No.44466166[source]▶
Can you expand on what makes SML better, in your eyes, than OCaml?

IMO: it's certainly "simpler" and "cleaner" (although it's been a while but IIRC the treatment of things like equality and arithmetic is hacky in its own way), which I think causes some people to prefer SML over aesthetics, but TBH I feel like many of OCaml's features missing in SML are quite useful. You mentioned applicative functors, but there's also things like labelled arguments, polymorphic variants, GADTs, even the much-maligned object system that have their place. Is there anything SML really brings to the table besides the omission of features like this?

replies(1): >>44466611 #
2. johnnyjeans ◴[04 Jul 25 18:02 UTC] No.44466611[source]▶
> the treatment of things like equality and arithmetic is hacky in its own way

mlton allows you to use a keyword to get the same facility for function overloading that is used for addition and equality. it's disabled by default for hygienic reasons, function overloading shouldn't be abused.

https://baturin.org/code/mlton-overload/

> labelled arguments

generally speaking if my functions are large enough for this to matter, i'd rather be passing around refs to structures so refactoring is easier.

> polymorphic variants

haven't really missed them.

> GADTs

afaik being able to store functors inside of modules would fix this (and I think sml/nj supports this), but SML's type system is more than capable of expressing virtual machines in a comfortable way with normal ADTs. if i wanted to get that cute with the type system, i'd probably go the whole country mile and reach for idris.

> even the much-maligned object system that have their place

never used it.

> Is there anything SML really brings to the table besides the omission of features like this?

mlton is whole-program optimizing (and very good at it)[1], has a much better FFI[2][3], is much less opinionated as a language, and the parallelism is about 30 years ahead[4]. the most important feature to me is that sml is more comfortable to use over ocaml. being nicer syntactically matters, and that increases in proportion with the amount of code you have to read and write. you dont go hiking in flip flops. as a knock-on effect, that simplicitly in sml ends up with a language that allows for a lot more mechanical sympathy.

all of these things combine for me, as an engineer, to what's fundamentally a more pragmatic language. the french have peculiar taste in programming languages, marseille prolog is also kind of weird. ocaml feels quirky in the same way as a french car, and i don't necessarily want that from a tool.

[1] - http://www.mlton.org/Performance

[2] - http://www.mlton.org/ForeignFunctionInterface

[3] - http://www.mlton.org/MLNLFFIGen

[4] - https://sss.cs.purdue.edu/projects/multiMLton/mML/Documentat...

replies(1): >>44466827 #
3. vkazanov ◴[04 Jul 25 18:32 UTC] No.44466827[source]▶
I love, love, love StandardML.

I respect the sheer power of what mlton does. The language itself is clean, easy to understand, reads better than anything else out there, and is also well-formalised. I read (enjoyed!) the tiger book before I knew anything about SML.

Sadly, this purism (not as in Haskell but as a vision) is what probably killed it. MLTon or not, the language needed to evolve, expand, rework the stdlib, etc.

But authors were just not interested in the boring part of language maintenance.

replies(1): >>44466951 #
4. johnnyjeans ◴[04 Jul 25 18:51 UTC] No.44466951{3}[source]▶
What are your thoughts on basis[1] and successorml[2]?

[1] - http://www.mlton.org/MLBasis

[2] - https://smlfamily.github.io/successor-ml/