Granted, I borrowed that image from here, where the author views people like me as “unhappy dogmatists who can’t bring themselves to leave the kiddie pool of strong typing.” Yes, I am rather dogmatic about strong typing! But to the point…
David R. Maclver wrote an interesting post “Static typing will not save us from broken software.”
davidMacIver = HesGotSomeGoodPoints()
davidMacIver = ButHesAlsoWrong()
Make it more expensive to write broken software – write in a non-static typed language
Make it cheaper to write correct software – write in a static typed language
But because these bugs [those that happen in production] are relatively minor
Now that’s where I totally disagree. If a true static typed language had been used, or had been used properly (ie, semantically, which is the next level of strong typing), this case in point[^]
due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed.
would not have cost the taxpayers $327.6 million
Dealing with type errors in a non-static language is not cheaper. I spend time writing unit tests and verifying the runtime by hand to ensure type correctness that I do NOT spend with static typed languages. Running an app only to discover I’m using a duck-typed variable before I’ve assigned something to it is a time waster. The benefits of static typing far outweigh the benefits of non-static typed languages, and I’m sorry David, that’s not opinion, but measurable fact.
Can duck-typed languages save time? Sure! I can replace a class instance that interfaces with hardware with a class instance that mocks the hardware as simply as the code above. I can add fields to a class outside of the class simply by making an assignment.
All of which are cheats and laziness, break the “code as documentation” fallback, and make duck-typed code more error prone and difficult to maintain.
Most existing static type systems also come with a build time cost that makes testing in general more expensive.
And the unit tests that duck-typed languages require often (in my experience with a small Ruby on Rails web app) take longer to run than compiling much more complex web sites.