> The ones on the main paths of the code get weeded out > quickly enough to not be too big of an issue.
I guess my point was that there's this assumption that developing in a dynamic language is inherently faster. I'm disputing that. As long as the scope of the program is small, I think this is definitely the case. But as the program becomes more complex, the information provided by the static typing becomes more useful. I think this can be mitigated by increasing documentation but this is as costly (if not more) as the adding the type declarations to the code.
> 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...
Just covering all code paths isn't really enough but I'm sure you know that.
> 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.
In my case, I am just trying to automate some tedious work. I'm not writing an 'application' per se. The problem I think is that I underestimated the complexity of the task. I might have tried this with Scala had I known.
Previous Topic
