3 ms·

Nicely argued. I do agree that the compile times in Julia are annoying, and the debugger sucks, but I’ve come to think of them as features rather than bugs; rem

Nicely argued. I do agree that the compile times in Julia are annoying, and the debugger sucks, but I’ve come to think of them as features rather than bugs; reminders to, as you say in your note, stop and take a breath, a reminder that computers are actually very very slow and you should strive to emulate them by slowing down and stopping to skim HN while the operator puts your punch cards in the card reader and your output will show up on the line printer in a half hour or so, then you can go back to the keypunch and fix the typo and recurse.

wudangmonk 4y ago
To me compilation speed is right up there with runtime speed in terms of importance. I do not like this trend where we sacrifice compilation speed to have "correct" code and give up because computers are so slow when in fact computers are incredibly fast and its this attitude of not caring about compilation speed that makes them seem so slow. All these typed languages have to balance how much static analysis they do anyways, I just think they should dial it back and settle for the middle ground between analysis and compilation speed as the default. You can have options to increase it just as you have options for optimization levels. The default should never be having to wait half and hour to fix a typo. That seems crazy to me but that is exactly what we have with some of these languages.
- aidenn0 4y ago
  I have a strong preference for fast compilation, but the trade-off with analysis is not so straightforward. Just finishing compilation is not sufficient to find problems, testing is needed too; if compilation and analysis can be done faster than compilation and testing, then you can still come out ahead. I think SBCL shows that there's a decent amount of low hanging fruit for analysis; it catches a surprising number of errors with reasonably fast compilation (incremental compilation of dozens of functions feels instant), and notes places where the code could be restructured to allow for better analysis.
deleted 4y ago
[deleted]

wudangmonk 4y ago

To me compilation speed is right up there with runtime speed in terms of importance. I do not like this trend where we sacrifice compilation speed to have "correct" code and give up because computers are so slow when in fact computers are incredibly fast and its this attitude of not caring about compilation speed that makes them seem so slow. All these typed languages have to balance how much static analysis they do anyways, I just think they should dial it back and settle for the middle ground between analysis and compilation speed as the default. You can have options to increase it just as you have options for optimization levels. The default should never be having to wait half and hour to fix a typo. That seems crazy to me but that is exactly what we have with some of these languages.

aidenn0 4y ago
I have a strong preference for fast compilation, but the trade-off with analysis is not so straightforward. Just finishing compilation is not sufficient to find problems, testing is needed too; if compilation and analysis can be done faster than compilation and testing, then you can still come out ahead. I think SBCL shows that there's a decent amount of low hanging fruit for analysis; it catches a surprising number of errors with reasonably fast compilation (incremental compilation of dozens of functions feels instant), and notes places where the code could be restructured to allow for better analysis.

deleted 4y ago

[deleted]