> Any reasonably complete smoke or integration testing regime should expose this problem But that's not without cost. At least in the Ruby world (and Bernhardt

> Any reasonably complete smoke or integration testing regime should expose this problem But that's not without cost. At least in the Ruby world (and Bernhardt holds/held this view) integrated tests are to be avoided where possible because it creates a negative feedback loop of slow tests and an exponential number of tests that need to be written to achieve equivalent coverage. > but more immediately I think developers should be actively testing the thing they are changing while they are changing it This smells like the age-old discipline/rigour/professionalism platitude often trotted out by proponents of Software Craftsmanship. I'd rather embrace the fact that humans make mistakes and optimise for that, rather than hold people to unreasonable standards. Furthermore, while I agree that people should be testing the thing they are changing while they are changing it, you appear to be implying that only one form of testing is acceptable here. Why not test the type signature? Why not a formal proof of correctness? Why not a property-based test? There are many ways to improve the chances of a piece of software to work. Restricting ourselves to only one of those ways is, quite frankly, dumb. > Personally I dislike compilers and restrictive type systems in large part because they _inhibit_ this sort of rapid, iterative testing and fixing. That's a fine opinion to have, but that's all it is. I've worked professionally with dynamic languages, and I hold the opposite view. I work with a few projects totalling about 60,000 lines of Haskell, and I feel the language enables rapid, iterative testing much more than Ruby ever did for me. Of course I can't prove this empirically, which is why my opinion will only ever be as good as yours, and vice versa. > Partially functional dynamically typed code is far more useful to me as I work through a series of related changes than statically typed code that requires I fix all the issues it perceives as important before I can keep going on what really matters. I'm sorry, but this is plainly incorrect. The ability to defer type errors to runtime certainly exists in Haskell, and I expect not exclusively.