The problem with dynamic typing is that it has a much higher chance of having a subtle error creep into your code that can go undetected for a long period of time. A strong type system forces the code to fail early where it's easier to track down and fix the problem, rather than trying to perform debugging on the fly in a production system. This has an added advantage for compiled languages in that for many non-trivial applications the time to build and deploy a new instance of the program, even in the development environment is often substantial, and the more trivial errors are discovered at compile time, the less time is wasted on builds.
For small code bases the time spent tracking down a error at runtime might be less than the time spent making your code conform to strict type requirements, but for larger code bases the amount of time necessary to track down such errors greatly out weighs the amount of time needed to make your code well typed. To look at the flip side of your statistics: Compiler says my code is right => My code is actually wrong -- 40% Compiler says my code is wrong => My code is actually right -- 5% I'd argue this is provably wrong, as correct code by definition would compile. The fact that it doesn't is proof enough that there's a problem with it even if that problem is simply that the types you're using aren't exactly correct. Further, I'd argue that in the first instance with a non-strict type system, the instance of wrong code that compiles would be higher. The only argument to support non-strict typing would be if you could show that it takes less time to track down runtime bugs than it does to fix compile time type errors, and any such claim I'd be highly skeptical of. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Mon, May 3, 2010 at 12:00, Luke Palmer <lrpal...@gmail.com> wrote: > On Mon, May 3, 2010 at 9:34 AM, Casey Hawthorne <cas...@istar.ca> wrote: > >>Strict type system allows for a maximum number of programming errors to > be caught at compile time. > > > > I keep hearing this statement but others would argue that programming > > errors caught at compile time only form a minor subset of all errors > > caught. > > > > So, in functional programming languages with a strict type system, > > e.g. Haskell, do typing errors from a larger subset of all programming > > errors. > > Absolutely! Haskell developers trade debugging time for time arguing > with the compiler about the correctness of their code. > > I'll give this meaningless anecdotal statistic: > > Compiler says my code is right => My code is actually right -- 60% > Compiler says my code is wrong => My code is actually wrong -- 95% > > Haskell has a particular reputation for the former. > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
