> I would say that if the compiler got 100% slower, that would be a failure.
Still a weird thing to care about. If the compiler were 100x slower, that would still be faster than continually handling boilerplate with human brains.
Still a weird thing to care about. If the compiler were 100x slower, that would still be faster than continually handling boilerplate with human brains.
If not, don't speak so hastily about compiler speed not being important.
Slow compilations means work arounds like batching changes together for tests on commits, which means doing binary searches across commits to find out who broke the tests, or just reverting everyone's commit and telling people to resubmit and hope it goes through next time.
Ever waited a week trying to get a single change committed because you kept getting batched with other people's broken code?
Slow compilation times matter, a lot. C++ is the nightmare case scenario for this, I've seen templates that take 10 minutes to compile, and once a team gets sizable, build queues became a thing, and they slow development to a crawl.
A 100x slower compiler has a huge impact on productivity. Copy and pasting code for those instances where you need to use template/generic programming is a huge win over waiting days for any and all changes to compile.
FWIW typically in these situations local rebuilds are faster, from 10 - 30 minutes in my experience, but I've only had the pleasure of working on code bases of such size twice, so who knows how bad it can get.
Slow (or flaky) build processes create gamblers. You don't want people gambling with prod.
When it's expensive (time or attention) to verify your work, people start lying to themselves. They tell themselves they've done enough, or that red test or wrong data on the screen is "just a glitch", and you know they do this because when they get caught breaking stuff they will tell you the same thing they told themselves.
The progression that works is this:
You make the tool.
You make the tool reliable.
You make the tool straightforward.
You make the tool cheap.
You make the tool mandatory.
People keep skipping step 4 and thinking rhetoric (even verbal abuse) will save them. If you meet idiots all day...
2. Microsoft Office.
Windows Mobile was pre-ssd, but we were surprised when we did get the first generation of SSDs and they weren't an order of magnitude reduction in compile times. (They helped but not as much as we hoped for!)
I worked on a c# project in 2011 that had 18 hour builds.
Very true, but the article didn't mention a 100x slower compiler, they mentioned 100% (2x) slower one.
Technically that's a quantitative difference of degree, but it's so big as to be talking about qualitatively different developer experiences.
Even at 2x, you can only 2x compile times so many times until things get unmanageable!
You deal with boilerplate using either interfaces or code generation. It's not as pleasant as first-class generics, but it's not completely awful either.
Other equally expressive languages have multiple implementations, including REPLs, with Go like compilation speeds.
So Swift and Rust just need equally LLVM fat free implementations for the developer loop, leaving the LLVM backend for the blazing execution release builds.
[1]: http://gistpreview.github.io/?74d799739504232991c49607d5ce74...