> > I make those mistakes a lot. Maybe it comes from having > a > > compiler yell at me for them, and having IDEs underline > > them, so I'm just sloppy in my typing. > > You are going to run that code once, aren't you?
Yes, and the code takes hours to run. It's not fun when something is attacking item 99 million out of 100 million and blows up on a stupid typo because it just happens to hit a codepath that the first 98,999,999 items didn't hit.
> > > > The ones on the main paths of the code get weeded out > > quickly enough to not be too big of an issue. In that > > case unit testing is a reasonable substitute for static > > typing. But mistakes tend to linger in codepaths that > you > > haven't tested. Ok, maybe tests should cover all code > > paths...but sometimes that takes too much time to do > when > > the code is in a high state of flux and you don't know > if > > it will ever really be used. > > I never ever release code with an untested part. Even in > ADA, there can be bugs in untested code, not caught by the > type checker. I always run everything at least once. So in > this case, static typing is more of an obstacle than help.
Who said anything about releasing code without testing it? I have a big heaping pile of data that looks meaningless but someone thinks there's gold buried in it. So I need to come up with an algorithm to find the gold and refine it into a nice shiny piece of information jewelry.
I may to try a whole slew of algorithms. I may never "productionize" the code for general use, because maybe the gold is really just copper so no one cares. Or maybe it's just dirt. But then maybe it does need to eventually be productionized. It's hard to tell at the start.
The point is I usually need to be able to try things fast. I usually use Python, but that's because of the APIs and ability to build abstractions, not because of dynamic typing. Experience has made be scatter runtime type-checks all over my code, despite the fact that it is "un-Pythonic" and lessens flexibility. But that MORE work that specifying static types, and it incurs a performance penalty.
If the code gets productionized, then yeah, it needs thorough testing. But developing a slew of tests for something you may throw away in the morning doesn't seem very productive, especially when a static type checker could catch 90% of the errors because they are just typos.
Previous Topic
