> Doubling the time to compile a project can quadruple the time to solve problems, in my experience.
My experience has been somewhat opposite.
Long compile times lead you to put more thought into your program, roughly (obviously I'm way over generalizing here, it's actually the language itself that causes this but I'm waving my hands and positing that there's a rough correlation between compile speeds and language formality). Slow compile times mean you're not thinking about how your problem is modeled formally and just kinda gluing things together and seeing what happens at runtime.
While quick compile times may get you a system that kinda works more quickly than a language with slow compile times, in my experience you have to iterate much much before the problem is truly solved. When I user slower languages I find myself iterating fewer times before the problem is usefully solved. Not to mention I spend far less time fixing bugs.
Maybe it's all a wash, but slow languages definitely do not result in a quadratic slowdown in productivity...
I dunno. I don't think this should be down-voted into the ground. But I think it's more nuanced.
Quick compile times may in some circumstances enable a sort of mentality of trial-and-error that I think is relatively common, but I don't think is a good approach to software development.
On the other hand, I don't think slow compile times are necessary to prevent this. Slow builds arguably more often lead to frustration and context switching. That isn't good either.
I think the best option is to have fast builds but also have enough discipline to not write code by trial and error.
The trade off here assumes a “barely working prototype” is undesirable and only the bug free end result is the goal.
Most projects I’ve worked on though, especially in their first few 100k lines of code didn’t really know exactly what problem are they trying to solve. Having something that kinda works in front if stakeholders / customers has been invaluable in actually getting the feedback and not wasting dev cycles on features nobody actually wanted.
Though granted “going back and doing things properly” has been as hard to achieve as “have complete requirements upfront”, so what do I know :-D
You joke, but bugs in your punchcard program were a royal PITA, so people spent more time making sure they were correct before going through the work of punching them out. I've heard this from a first hand source.
My experience has been somewhat opposite.
Long compile times lead you to put more thought into your program, roughly (obviously I'm way over generalizing here, it's actually the language itself that causes this but I'm waving my hands and positing that there's a rough correlation between compile speeds and language formality). Slow compile times mean you're not thinking about how your problem is modeled formally and just kinda gluing things together and seeing what happens at runtime.
While quick compile times may get you a system that kinda works more quickly than a language with slow compile times, in my experience you have to iterate much much before the problem is truly solved. When I user slower languages I find myself iterating fewer times before the problem is usefully solved. Not to mention I spend far less time fixing bugs.
Maybe it's all a wash, but slow languages definitely do not result in a quadratic slowdown in productivity...