3 ms·
Well, the costs are once per every build, which can take many hours, as the author describes it, even be only available on the next day. Static typechecking is
by _ph_ 7y ago
Well, the costs are once per every build, which can take many hours, as the author describes it, even be only available on the next day. Static typechecking is a valuable tool, but it shouldn't be as the solution for all correctness problems. Testing is another. And when the build times become too large, testing suffers. Finally, it is absoultely possible to have dynamic languages with type declarations which can be automatically checked.
- scarface74 7y agoSo now you trade reduced build times for increase in the amount of developer time for creating extra tests that check for type correctness and you increase the “build” time by having your build system run more tests? And once you have type declaration that can “automatically” be checked - something has to run against the same code base to check the correctness of your code and you’re back to increasing your build time?
- _ph_ 7y agoNo. With dynamic languages, one gets not only "reduced" build times, they are instant. Testing for correctness needs to be done with any kind of language. Type checking is not a replacement for that. But you can add the necessary type declarations to dynamic language to facilitate static type checking if desired. These checks don't influence the build time significantly. As written in my first post, using dynamic languages is only one way of improving development times. The other of course is, use languages which allow for fast compilation.
- enigmo 7y ago> But you can add the necessary type declarations to dynamic language to facilitate static type checking if desired. These checks don't influence the build time significantly. Indeed, type checking is rarely the slowest compilation stage for most languages.