Static typing will not save us from broken software
-
People keep claiming that is because of bad choices of language, but it’s mostly not and static typing will not even slightly help fix it.
dim Discuss as new Flamebait()
-
People keep claiming that is because of bad choices of language, but it’s mostly not and static typing will not even slightly help fix it.
dim Discuss as new Flamebait()
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 outweight 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. In other words, duck-typed languages are like pr0n instead of the real thing. [edit] Most existing static type systems also come with a build time cost that makes testing in general more expensive. :laugh: 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. [/edit] Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to
-
People keep claiming that is because of bad choices of language, but it’s mostly not and static typing will not even slightly help fix it.
dim Discuss as new Flamebait()
The fact that we have === says it all.
cheers Chris Maunder
-
People keep claiming that is because of bad choices of language, but it’s mostly not and static typing will not even slightly help fix it.
dim Discuss as new Flamebait()
Though David is right when he says that "Static typing will not save us from broken software", I mostly disagree with him. Static typing must be done correctly. Many developers don't understand that - see also my post to the Weird and Wonderful: I don't see sharp anymore, ...[^]. And the next level of typing are semantic types, as Marc suggested (and also Simonyi when he introduced Hungarian notation). We need developers who actually understand what they do.
-
The fact that we have === says it all.
cheers Chris Maunder
The funny operator of js. :-\