
A Forgotten Principle of Compiler Design - cpeterso
http://prog21.dadgum.com/136.html
======
Negitivefrags
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.

~~~
pjmlp
Not really.

For example, the way Objective-C uses #import, is a bit like poor man's
solution, but it already makes a difference in compile times.

There is no reason why a module system won't be possible to add in C++. That
is why they are finally doing it.

Even C could benefit from one. The thing is, that most likely no one would use
it, as many C developers are not used to module systems.

------
ssp
_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.

~~~
batista
_> It's not "forgotten" wisdom from the golden ages; nobody ever abided by
anything like it._

Unless you count Niclaus Wirth as a nobody, this isn't true.

And in general what you wrote is not true --the gist is to be pragmatic about
optimizations.

>* 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.*

Well, eat your hat then, because Wirth was quite aggressive on following that
route and he did state it from the beggining.

------
sambeau
I believe that the Go creators have embraced this principle.

[http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...](http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project)

~~~
primecommenter
I don't see the connection. Is Go even bootstrapped?

~~~
JoachimSchipper
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.

~~~
pjmlp
This tends to be Go PR.

Any language with modules has fast compilation times. Turbo Pascal was just
one of many languages already doing it in the mid 80's.

The only developers that can believe on this assertion, have only experience
with C and C++ compilation times.

------
pbiggar
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".

~~~
ntoshev
It's "principle", "principal" means something else.

~~~
pbiggar
Indeed. Seems too late to change it now, so this will be my lesson for
commenting when I'm really tired.

------
acuozzo
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.

------
pjmlp
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.

More information available here, <http://www.ethoberon.ethz.ch/books.html>

------
benhoyt
_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.

------
pkmays
Speak of the devil.

[http://www.open-
std.org/JTC1/SC22/WG21/docs/papers/2012/n334...](http://www.open-
std.org/JTC1/SC22/WG21/docs/papers/2012/n3347.pdf)

~~~
pjmlp
First it needs to get approved and eventually implemented.

I hope it gets accepted.

