Building a debugger and profiler is quite an advanced task compared to building an assembler though ^^

Also much of that work is heavily dependent on the used operating system.

Nevertheless, I'm wishing you all the best on your journey!

Really? You can get quite far just with ptrace() on Linux... and maybe something like system("nm xxxx > file") for the symbols.

This has nothing to do with the post?

I mean, we _are_ talking about a book which invites you to build your own toy C compiler ^^

Nevertheless, OCaml is very strong in compiler design. For example Rust and Hack were written in OCaml initially.

Nevertheless you are not wrong that compilers needing the very last bit of performance like the JVM and LLVM tend to be written in C++

But the barrier is quite a lot more tending to high performance/very high performance and not toy/production

Java and Python are suitable for implementing a toy Compiler and the auther invites you to use any language you like. Just the reference implementation is using OCaml

I would however argue that using C++ is quite advanced since it does not have pattern matching and using C is just masochm. You will be fighting against the language to do even trivial things instead of fighting the actual problem at hand

I totally agree that OCaml is a great language to write a compiler. I’ve used Rust and Haskell, and loved them both.

I was more so pushing back on the the implication that if it’s not OCaml, it’s not the right tool for the job.

Like, I honestly can’t think of a mainstream language in which it would be hard to implement a C compiler in.

I do not agree in the general case. There are very useful DSL compilers which do not consider performance at all, but just compile to a target which does the optimization for them (JVM, LLVM IR or even just C)

Yes but those are called transpilers, right?

There is no fundamental difference between a compiler, transpiler and interpreter.

The techniques employed are very similar