> > The problems I have had are: as I make changes, I often > > don't realize that I have made some trivial error until > 5 > > minutes into the test, when that code is first hit. > This > > is slow. Most of the time these are things that would > > have been immediately flagged in a static language. > > Most probably it would not happen, and the reason is > simple: in this day and age where most computer languages > involve subtyping (i.e. inheritance from you OO folks), > trivial errors can easily pass through through the > subtyping mechanism. A static type system is almost > useless in this case. > Programming usually goes down two routes: > > 1) the problem at hand is trivial. In this case, a static > type system won't help because the problem is trivial. > > 2) the problem at hand is quite complex. In this case, a > static type won't help as well, because the code will > usually involve lots of subclasses and interfaces.
I think you underestimate the penchant we mortals have for making stupid mistakes. Here's a common one (in rough Python):
<code> #setup connection and execute query... row = cursor.fetchone() #row is a tuple... myObj.cost = row #should be row[0] to reference the first element of the tuple </code>
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.
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.
Previous Topic
