I see your claim repeated often on HN, but I think it's disingenuous.
I see your claim repeated often on HN, but I think it's disingenuous.
One would expect that a system to transform a simple high level language into a complicated low level language would would grow proportional to how simple and high level the source language is. Thus, a very simple, high-level language ought to have a larger compiler than a more complicated, lower-level language.
Indeed, we see this in real life. Writing a haskell compiler is a fairly big undertaking whereas a C compiler could be written in a few days. This is because C is complicated, but low-level, and Haskell is simple, but high-level.
Let's not confuse the simplicity of translation with the simplicity of semantics.
What makes Haskell higher-level than C? Garbage collection does not really complicate the compiler if you just use BoehmGC.
You can use a simple subset of assembly instead of the full complicated set. Toy C compilers do this, e.g. by treating x86 as a stack machine.
- lazy evaluation
- type inference
- ridiculous amounts of programmer tools (it *derives* type classes for you!!!)
- lots of experimental ideas that are in the compiler but that people don't really use (it's a research tool after all).
The language is simple from a conceptual standpoint. Not every thing in the compiler is there simply to support expression of an idea. Quite a lot of it is there to help the programmer.I think there is something to be said for the idea of writing a similar language which has a less monolithic set of tools (although, to be fair, I have not look at the architecture of GHC at all, so maybe it is really beautiful under the hood). The point is that I don't think that you can necessarily equate the simplicity of expression with the complexity of the tools.
It also implements a huge number of optional language extensions.