|
|
|
|
|
by judk
4321 days ago
|
|
Informally, dynamically types languages are chosen when the programmer prefers to get something running before getting something running correctly. Why would we assume then that once a program is running, the programmer would "find religion" and do the extra work to write a comprehensive test suite? If the programmer is willing to do work in an effort to prove correctness, the programmer would choose the far more efficient technique of rewriting the program in a statically typed language. A dynamically typed program by its very nature a prototype, a program that is expected to fail when exposed to a non-trivial input. In many cases, that is fine, just not when correctness over many invocations actually matters. |
|
I don't think that's at all true. I think that a major motive for choosing dynamic programming languages is that programmers want to get things running correctly and spend more time on the logic and less on making ritual invocations to the type system that are redundant with other elements of the code. (Haskell and other similar languages with very strong type inference are making this a less compelling reason to choose a dynamic language, but I think it remains an important one for many real decisions, as Haskell hasn't yet acheived the ecosystem and mind-share where its always likely to be considered as an alternative, and not rejected for reasons other than its type system.)
I think people who choose static languages do so because of concerns for correctness, but I think it is a mistake to reverse that to conclude that those who choose dynamic languages do so because they aren't concerned with correctness; many do so because the hoops you need to jump through in mainstream static languages are perceived as being a too-expensive way to get the (often very limited, given the lack of expressiveness in the type systems in many popular static languages) help in correctness that the static nature of the language provides.