A Forgotten Principle of Compiler Design | Hacker News Reader

A Forgotten Principle of Compiler Design

prog21.dadgum.com

52 pointscpeterso16 comments

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.

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.

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.

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

I believe that the Go creators have embraced this principle.

http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...

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

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.

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.

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

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

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

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.

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

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.

Speak of the devil.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n334...

First it needs to get approved and eventually implemented.

I hope it gets accepted.

Reply on news.ycombinator.com