Writing compilers is actually rather easy. The hard part is dealing with other programs. For example, last week I finally tracked a bug down to the documentation on how the function ABI worked was simply wrong.
Writing a compiler is easy. Optimizing one, not so much, but setting "writing a compiler" as some kind of difficult thing that requires arcane magic irritates me.
Are you talking about compilers, or just ("dumb") interpreters? To me, the hardest part of writing a compiler is the middle part that you totally neglected to mention: the static analysis & optimization. Not the parsing or the codegen.
"What makes compilers hard to write, for someone who has never done it before, is the scope of the problem you're trying to solve. Writing a compiler, to spec, for a non-trivial language takes a lot of WORK."
I think it is useful to distinguish work from difficulty. IMO, on current hardware, writing a compiler is easy and, for most languages, not too much work.
However, if the language spec states what a compiler must do when given invalid programs, this can get much harder.
Writing a runtime increases both the amount of work, too, and, depending on the runtime, can make it much harder.
Finally, if you want your compiler to produce decent code and/or decent error messages, things get harder, too.
Summary: IMO, writing a compiler is easy, writing a good one is hard and a lot of work.
I learned compilers this way and yes, it's extremely hard. Things got so high-level that I forgot what the real problem was and kept wondering why the algorithm I wrote isn't working.
None of what you ssid means writing compilers is hard: just that the first ones or techniques are hard to do. Once it's done, it's another building block that can be chained together to solve similar problems. Using a ML or LISP with right primitives makes that even easier. Designing the right language and implementing modularly makes that easier.
So, I'd say the industrial ones are as tough as they are because they support hard-to-compile languages with many dark corners while bring implemented in the same languages themselves. Make problem hard for yourself then it's hard. Make it easier then it's... still work but only a tiny fraction of what you alluded to.
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.
compilers are really complicated pieces of software. There's a lot of complexity even in small routines. I would expect to encounter complicated types in there, they capture (while complex) intent and meaning.
It's not the frontend glue-code kind of code. The inherently hard problem makes is fun for people who like to solve small puzzles.
Allison's point is instead that the combination of the perception that compilers are difficult and the relative paucity of tools to make writing compilers easier is a vicious cycle which writing better tools might fix.
Compiler writing does involve a fair amount of tedium. I don't think it has anything to do with experience, either. It's why tools like Yacc, Lemon, or ANTLR exist.
reply