4 ms·
This person wants compilers to be interactively fast and believes that the outcome will be developers empowered to create fast programs. But I think the key set
by abeppu 7y ago
This person wants compilers to be interactively fast and believes that the outcome will be developers empowered to create fast programs. But I think the key set up during the intro is assuming that a) the compiler runs your tests and b) that test performance is a good proxy for real performance.
The counterexample to this in my daily life is working with an IDE that does a pretty good job of interactively invoking the complier as I change code. However, my tests aren't invoked with each compile pass, and the work they do doesn't look like a long running live service, or a giant spark job, or whatever. They're mostly aimed at checking correctness, and spend at least as much time creating and checking values as invoking my real code. If my real program is going to use many threads, do a lot of io and waiting for other services to respond, or decompress and deserialize big chunks of data, it's hard to see how a very fast local test ever could be a close proxy for that performance.
- openfuture 7y agoIf you want your tests to run on compile time then what you want is static typing.
- bluGill 7y agoStatic types are very useful, but they do not catch all problems.
- mring33621 7y agoBut they catch many more problems than dynamic typing.
- fao_ 7y agoThat's a bit of a domain error. Nobody said that static types don't catch problems, and nobody brought up dynamic typing (until you). The parent poster tried to make a false equivalence between proper tests, and static typing. The former is a category that includes the latter.
- erik_seaberg 7y agoThis. Integration and load tests do so much work that the compiler is lost in the noise. Running forty (hopefully) concurrent requests through a 200 OPS service does not tell me whether it's going to make prod flaky or more expensive.