I see what you're saying, but respectfully I disagree. The importance of parsers and run-time systems in compilers really depends on the language you are compil

I see what you're saying, but respectfully I disagree. The importance of parsers and run-time systems in compilers really depends on the language you are compiling. There's a big spectrum there. For runtime systems, on one hand you have languages where they are very important, such as runtime garbage collectors in Lisp, Java, and similar languages, Prolog's runtime logic backtracking, runtime exception support for C++ but no garbage collection, down to languages like C with no garbage collection and minimal runtime. Forth is certainly on the lower end of the compiler runtime implementation spectrum. For parsing, there's a similar spectrum. There's languages with hideously complicated grammars, like C++, less complex ones like Lisp, and probably again on the simplest end of the spectrum is Forth. So the requirement of needing to learn to write complex parsers and runtime systems is dependant on the language. I'd certainly classify a C compiler author as a "wizard" even though they wouldn't have to write a garbage collector for their C compiler, and a Lisp compiler author as a "wizard" even though their parser is much less difficult to create than a C++ language parser. Of course, it's not like wizard is an exact term or anything. If you're saying a "compiler wizard" should be able to understand how to implement any language, then of course you need to have in-depth knowledge of parsers and run-time systems. Me personally, I'd say if you can write a compiler for any language you're somewhere on the compiler magician spectrum. Maybe not full wizard, but at least a compiler warlock or enchanter or something (this is getting silly now, I don't really want to argue about the semantics of the term wizard applied to compilers).