Comment by Someone | Hacker News Reader

Comment by Someone | Hacker News Reader

I sort-of disagree. Compilers that produce small and/or fast code and good error messages for complex languages are hard, but simple ones for simple languages aren’t.

Also, creating a toy one for a simple language is a fun educational exercise. We shouldn’t deter people from having a go at that by making them think “compilers are hard”.

For many simple languages (e.g. a language doesn’t need to have strings, multiple numeric types, operator precedence, or even have expressions containing multiple operators), writing a one pass compiler that always spills back operation results to memory isn’t too hard. Its assembly output can fairly easily be matched to the source, and it will provide a decent speed-up compared to a naive interpreter.

From there, the first few steps (peephole optimizations to remove store-load pairs, then a slightly more advanced register allocator) aren’t too difficult, either, and bring nice speed ups.

‘Real’ compilers are ‘just’ thousands more of such steps, each either extending the language or improving code generation, up from there. And yes, things do become very hairy somewhere along that route.

> e.g. a language doesn’t need to have strings, multiple numeric types, operator precedence, or even have expressions containing multiple operators

Can't you make anything look easy by reducing it to an unrealistically limited example?

Building an F1 car is hard. Building a soap box car is easy.

Building Google is hard. Building a simple web scraper and grep is easy.

Seems like a redundant thing to point out. When people say something is hard they obviously mean 'for a useful actual application I care about'.

Some things are irreducibly difficult. Writing a compiler isn't one of them.

Writing a c 89 compiler is something you could do in under a year of evenings and weekends.

Maybe that's overly reduced, but at least it's more like a model T than a soap box car?

The thing that's nice about compilers is that they're hard for reasons that actually make sense, e.g. trying to apply an optimization for a particular case where you have to precisely prove that it results in the correct behavior. Or figuring out which instructions are most appropriate given various constraints.

This is a different kind of hard than, say, the makework that dominates other domains: "oh I haven't touched this project in a month and it now is somewhat broken because dependencies have subtly changed in ways that I have to spend hours debugging."

I'm convinced some devs love the pain imposed by the former, while others can better tolerate the pain of the latter without issue.

For added easiness, outputting high-level language code instead of machine code is a "cheat" that is often good enough, and you can typically borrow a lot of the high level features with relatively little effort. Say you want to run a domain specific language in your program? Include V8, and write a compiler that turns the DSL into JavaScript. You get much better performance than a simple interpreter, sandboxing, and somewhat useful error messages.

I agree with you. In fact I would say understanding compilers is really pretty easy. They are some of the most well researched and documented subjects (in CS) out there. Almost all compilers are going to follow a similar structure of lex -> parse -> pass0 -> passN -> generation.

The challenge these days seems to be in the passes which can become numerous and complex.

> They are some of the most well researched and documented subjects (in CS) out there.

Hmm this is the first time I've ever seen someone say this! I would say compilers are famously badly documented part of computer science, with many essential techniques basically not written down anywhere but buried in code, and passed through oral history from senior to intern over the years! It's a real problem.

I'd say both sides are true. The theoretical aspects of compilers are quite well-understood, and for pretty much every pass or analysis in the compiler, I could go and rustle up a citation of a paper or a talk or a book or what have you that explains the theory of the algorithm. On the other hand, actual code brings up issues that aren't easily handled in the theoretical framework, and the adjustments necessary to make it work well in practice generally are in the vein of the-code-is-the-documentation.

That's not quite the whole picture. Several industrial compilers for languages used by people for work are made by people who recognize that tooling is important. So the compiler is also a service or set of services with (depending on how you think about it) a database of information to query. It significantly increases the scope of the compiler and adds another dimension of performance and reliability to the system. For example, it may be a good idea to allocate a bunch of memory up front as a part of batch compilation to process some stuff. In a tooling scenario that can be a bad idea unless that large allocation routine is done in a way that the memory is pooled for the many, many requests it's going to get over its lifetime.

The hardest thing about compilers is that they are expected to be nearly perfect.

A typical user spends hours every day actively using the compiler and if they manage to observe even one bug every five years, that's probably considered a low quality compiler.

In that case clang, gcc and msvc would be considered low quality conpilers.

I get the sentiment: compiler bugs have a cascading effect, especially miscompiles (looking at you, clang). Crashed while compiling (looking at you, msvc) are also bad, but less serious.

In any case, you'd be surprised how many bugs a useful compiler may have.

For the record, I consider the three compilers I mentioned, having observed all sorts of bugs in then almost yearly, very high quality compilers.

We can mostly just work together to add to the mountain of regression tests that safeguard our open source compilers.

Maybe formal verification will some day produce bug-free toolchains, but we are not there yet for the production grade optimizing compiler.

Reply on news.ycombinator.com