I understand this isn't the point of the article, but the leading remark is fairly unreasonable.
The lack of a clean module system in C++ is fairly directly a result of it's decent from C, a language designed earlier than Modula-2 and thus unable to learn from it. It would have been very difficult to add such a thing in the intervening time to the language given the required constraints of compatibility.
The principle is "compiler optimizations should pay for themselves."
This principle may seem deep because there is an element of self-reference in it, but it is really totally stupid. It's nothing but an arbitrary benchmark that will reject lots of useful optimizations. It's not "forgotten" wisdom from the golden ages; nobody ever abided by anything like it.
It's cool that the optimizing Oberon compiler did manage to make its own object code smaller than that of the non-optimizing compiler, but I'll eat my hat if they started out by stating this "principle", rather than just noticing after the fact that it had happened.
The Go compiler is largely implemented in C. However, unlike most modern languages, Go has explicitly been designed to be easy to compile into fast code.
I don't think this is really a good principal. Some optimizations work really well for some programs - should they not be implemented just because the compiler isn't one of those programs? Say the compiler gets no benefit from object-size improvements - does that mean no embedded software will get to benefit from those improvements?
Here's a principal I learned from a fairly awesome compiler writer, Mike Hind of Jikes RVM (paraphrasing):
"Students often ask me how much speed improvement an optimization should provide to be publishable. If it speeds programs up by 10%, but will take six months to implement, that's not a good result. But if it can be done in a day, and improves performance by 0.5%, that's a great result".
The author of this post is trying to emphasize that _language_ simplicity should be near the top of a PL-and-compiler-dude's priority list. I agree with this point, but I don't think he supports it effectively by confounding it with _implementation_ simplicity. The jewel of the post is: ``With Oberon, Wirth removed features from Modula-2 while making a few careful additions.''
Language simplicity is important. In some cases it's taken too far (e.g., the tiny nearly-self-bootstrapping dialects of Lisp), but a few outliers shouldn't discourage us from removing from our language(s) those non-essential elements of its syntax and semantics.
Oberon was a great pastime of mine during university.
I learned a lot about compiler design by playing around in Native Oberon OS, while trying to implement an Oberon compiler.
Everyone that thinks it is not possible to implement operating systems in GC enabled, safe languages, that compile straight to native code, should have a look at the Native Oberon OS.
Excepting the extreme minimalism of Forth, this is the first language I'm aware of where simplicity of the implementation was a concern.
Actually (and I don't have a reference now, but) Guido van Rossum specifically rejects certain speed or other improvements to CPython because they add more complexity than they're worth to the interpreter/compiler.
The lack of a clean module system in C++ is fairly directly a result of it's decent from C, a language designed earlier than Modula-2 and thus unable to learn from it. It would have been very difficult to add such a thing in the intervening time to the language given the required constraints of compatibility.