4 ms·

Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's

by zach 14y ago

Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change. I have to think that this is a minor repartee between Apple and Google language groups. Google did something clever that breaks with tradition, and now Apple is doing something similarly clever yet backwards-compatible. I like this dynamic. I certainly appreciate this move as a OS X/iOS programmer, since getting a functional version of Go on iOS is a pipe dream for strategy tax reasons.

kibwen 14y ago
I don't intend to downplay the importance of Go (it's definitely helped people realize how nice fast compiles can be when you don't have to fight the language to get it), but Clang (whose leaders are making the proposal here) has had an explicit focus on fast compile times since the very beginning: http://clang.llvm.org/features.html#performance http://clang.llvm.org/features.html#performance Note that "Fast compiles and Low Memory Use" is listed more prominently than any other feature (in primary position, with more text and pretty graphics).
coliveira 14y ago
Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.
- rossjudson 14y ago
  Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
  - coliveira 14y ago
    Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.
    - rikthevik 14y ago
      If I remember correctly, it's a single pass parser, which is why you generally write get to your code upside down.
    - pjmlp 14y ago
      The main advantage was still the possibility of having binary modules, without parsing the same imports multiple times during "make world" compilation. Just as input, the ISO Pascal eventually got the changes that were available in Turbo Pascal and Mac Pascal (known as ISO Extended Pascal), but by then most people considered Turbo Pascal the _de facto_ standard.
  - masklinn 14y ago
    Also due to the java compiler doing very little work (it's a really dumb compiler)
    - pkolaczk 14y ago
      It does all the same work as a C++ compiler, except optimization phase. Yet any C++ compiler with optimization turned off is still order of magnitude slower. The key differences are: - Java has a much simpler grammar to parse. - Everything is compiled at most once. - Encapsulation is stronger: private class members are not exposed in public class ABI and external code doesn't depend on them (this also extremely improves recompilation times - no need to compile half of the project because you changed a private method).
pjmlp 14y ago
> Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change. Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's. Modula-2, Turbo Pascal, just to name two of many.
- wladimir 14y ago
  Yes, the idea of using modules is nothing new. It's old-school and well-proven. Many people have argued about adding pascal-like module support to C at some point or another at the coffee machine. But having enough (political) momentum to actually change C(++), and overcome extreme inertia and calcification is new. LLVM is the greatest thing to happen to compilers in a long time, it really opened up compiler development like GCC somehow never did (see http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 http://www.drdobbs.com/architecture-and-design/the-design-of... for a likely explanation). And having a giant like Apple behind it helps, of course.
  - pjmlp 14y ago
    Oh yes, I am all for having modules in C and C++. I was just calling the attention that some Go devotees seem to think their compile times are something new.

by zach 14y ago

kibwen 14y ago

I don't intend to downplay the importance of Go (it's definitely helped people realize how nice fast compiles can be when you don't have to fight the language to get it), but Clang (whose leaders are making the proposal here) has had an explicit focus on fast compile times since the very beginning: http://clang.llvm.org/features.html#performance http://clang.llvm.org/features.html#performance Note that "Fast compiles and Low Memory Use" is listed more prominently than any other feature (in primary position, with more text and pretty graphics).

coliveira 14y ago

Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.

rossjudson 14y ago
Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
- coliveira 14y ago
  Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.
  - rikthevik 14y ago
    If I remember correctly, it's a single pass parser, which is why you generally write get to your code upside down.
  - pjmlp 14y ago
    The main advantage was still the possibility of having binary modules, without parsing the same imports multiple times during "make world" compilation. Just as input, the ISO Pascal eventually got the changes that were available in Turbo Pascal and Mac Pascal (known as ISO Extended Pascal), but by then most people considered Turbo Pascal the _de facto_ standard.
- masklinn 14y ago
  Also due to the java compiler doing very little work (it's a really dumb compiler)
  - pkolaczk 14y ago
    It does all the same work as a C++ compiler, except optimization phase. Yet any C++ compiler with optimization turned off is still order of magnitude slower. The key differences are: - Java has a much simpler grammar to parse. - Everything is compiled at most once. - Encapsulation is stronger: private class members are not exposed in public class ABI and external code doesn't depend on them (this also extremely improves recompilation times - no need to compile half of the project because you changed a private method).

pjmlp 14y ago

> Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change. Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's. Modula-2, Turbo Pascal, just to name two of many.

wladimir 14y ago
Yes, the idea of using modules is nothing new. It's old-school and well-proven. Many people have argued about adding pascal-like module support to C at some point or another at the coffee machine. But having enough (political) momentum to actually change C(++), and overcome extreme inertia and calcification is new. LLVM is the greatest thing to happen to compilers in a long time, it really opened up compiler development like GCC somehow never did (see http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 http://www.drdobbs.com/architecture-and-design/the-design-of... for a likely explanation). And having a giant like Apple behind it helps, of course.
- pjmlp 14y ago
  Oh yes, I am all for having modules in C and C++. I was just calling the attention that some Go devotees seem to think their compile times are something new.