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 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.
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.
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.
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.
18 comments
[ 2.4 ms ] story [ 35.5 ms ] threadhttp://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...
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.
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.
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.
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n334...
I hope it gets accepted.
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.
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.
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".
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.
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.
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