3 ms·

Absolutely. One of the things I hate most is this thinking "run-time is more important than compile-time". Well the compiler and the IDE are runtimes too, we d

by mojuba 7y ago

Absolutely. One of the things I hate most is this thinking "run-time is more important than compile-time". Well the compiler and the IDE are runtimes too, we developers are users too, we sometimes work on our laptops unplugged and we do want our software to be fast and efficient!

skohan 7y ago
> "run-time is more important than compile-time" This is a pitfall of Rust as well. I suppose there will always be a tradeoff between stronger static analysis and compilation time, and I'm firmly in the camp that I want my compiler to catch more issues so I don't have unexpected runtime failures, but iteration time matters too, and I'm hopeful improvements can be made in this area.
- mojuba 7y ago
  Sometimes you introduce certain restrictions in the language just for the sake of simplifying the compiler. This is allowed, valid and will be understood by the developers. For example, for decades most static languages required a symbol to be defined before its first usage. Removing this restiction seemed like a nice little cute convenience but the outcome of it is this horrific slowdown of the build process. Personally I would agree to the restriction if I knew the compiler could be 5x faster which is pretty realistic to achieve, it seems.
  - skohan 7y ago
    Those kinds of restrictions can have their own productivity pitfalls. For instance, it might be the case that requiring declaration prior to usage explicitly will speed up the compiler, but it might also mean that you can't move blocks of code around without paying careful attention to the order of declaration. I think having a permissive compiler, but also being able to profile the compilation process is a reasonable compromise.
    - mojuba 7y ago
      Possibly, but there are other kinds of compromises such as allowing arbitrary order only within a class, the C++ way. Or another one: the first (quick) pass treats all function and reference type definitions as forward declarations and skips the details. This way the compiler might be able to do more permissive compilation though not 100% accurate like Swift currently does.
ajconway 7y ago
But run-time is more important, isn't that why we compile stuff with optimizations that take ages to process when building products for the end users? Compilers are hard, compiler bugs can have a devastating effect on one's software, so it's understandable that developers may prefer to take things slow but safe.
- skohan 7y ago
  I guess ideally this should be a tradeoff in the hands of the developer right? I should be able to produce debug builds quickly so that I can iterate quickly, and if I want a super-optimal release build it's fine if it takes longer.
- Gibbon1 7y ago
  My half joke is the optimizations slow down compilers. So people then try to make the compilers faster by increasing the levels of optimization. Which means they have to work harder. So they are slower.

by mojuba 7y ago

skohan 7y ago

> "run-time is more important than compile-time" This is a pitfall of Rust as well. I suppose there will always be a tradeoff between stronger static analysis and compilation time, and I'm firmly in the camp that I want my compiler to catch more issues so I don't have unexpected runtime failures, but iteration time matters too, and I'm hopeful improvements can be made in this area.

mojuba 7y ago
Sometimes you introduce certain restrictions in the language just for the sake of simplifying the compiler. This is allowed, valid and will be understood by the developers. For example, for decades most static languages required a symbol to be defined before its first usage. Removing this restiction seemed like a nice little cute convenience but the outcome of it is this horrific slowdown of the build process. Personally I would agree to the restriction if I knew the compiler could be 5x faster which is pretty realistic to achieve, it seems.
- skohan 7y ago
  Those kinds of restrictions can have their own productivity pitfalls. For instance, it might be the case that requiring declaration prior to usage explicitly will speed up the compiler, but it might also mean that you can't move blocks of code around without paying careful attention to the order of declaration. I think having a permissive compiler, but also being able to profile the compilation process is a reasonable compromise.
  - mojuba 7y ago
    Possibly, but there are other kinds of compromises such as allowing arbitrary order only within a class, the C++ way. Or another one: the first (quick) pass treats all function and reference type definitions as forward declarations and skips the details. This way the compiler might be able to do more permissive compilation though not 100% accurate like Swift currently does.

ajconway 7y ago

But run-time is more important, isn't that why we compile stuff with optimizations that take ages to process when building products for the end users? Compilers are hard, compiler bugs can have a devastating effect on one's software, so it's understandable that developers may prefer to take things slow but safe.

skohan 7y ago
I guess ideally this should be a tradeoff in the hands of the developer right? I should be able to produce debug builds quickly so that I can iterate quickly, and if I want a super-optimal release build it's fine if it takes longer.
Gibbon1 7y ago
My half joke is the optimizations slow down compilers. So people then try to make the compilers faster by increasing the levels of optimization. Which means they have to work harder. So they are slower.