At any rate, that’s not really the case when building an emulator or bytecode interpreter. And Haskell ends up being mostly a liability here, because most work is just going to be imperatively modifying your virtual machine’s state.
At any rate, that’s not really the case when building an emulator or bytecode interpreter. And Haskell ends up being mostly a liability here, because most work is just going to be imperatively modifying your virtual machine’s state.
That sounds odd to me. Haskell is great for managing state, since it makes it possible to do so in a much more controlled manner than non-pure languages.
Not that you'd need a monad for something like this anyway.
C++: game.level.unit[10].position += 5;
Haskell: way too much code here (unless you use lenses of course but then you are effectively turning Haskell into an imperative language).
https://www.microsoft.com/en-us/research/wp-content/uploads/...
Also when people say Lisp in 2025, usually we can assume Common Lisp, which is far beyond the Lisp 1.5 reference manual in capabilities.
In fact, back when I was in the university, Caml Light was still recent, Miranda was still part of programming language lectures, the languages forbidden on compiler development assignments were Lisp and Prolog, as they would make it supper easy assignment.
I believe those two languages themselves self-host. So not saying it’s impossible. And I have no clue about the technical merits.
But if you look around programming forums, there’s this ideas that”Ocaml is one of the leading languages for compiler writers”, which seems to be a completely made up statistic.
Also, Haskell has parsers for all major languages. You can find them on Hackage with the `language-` prefix: language-python, language-rust, language,javascript, etc.
But I would call Rust, Haxe and Hack production compilers. (As mentioned by sibling, Rust bootstraps itself since its early days. But that doesn't diminish that OCaml was the choice before bootstrapping.)
RAII, iterators, templates, object encapsulation, smart pointers, data ownership, etc are entrenched in C++; while C is still raw pointers, no generics (no _Generic doesn’t count), procedural, void* casting, manual malloc/free, etc.
I code in both, and enjoy each (generally for different use cases), but certainly they are significantly differing experiences.
It is like adopting Typescript, but the only thing they do is renaming the file extension for better VScode analysis.
Another one is C++ "libraries" that are plain C with extern "C" blocks.
> Another one is C++ "libraries" that are plain C with extern "C" blocks.
Sure, and you also see "C Libraries" that are the exact same. I don't usually judge the communities on their exceptions or extremists.