4 ms·

But testing ensures no such thing, considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases. Par

But testing ensures no such thing, considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases. Part of the usefulness of static typing is to prevent us from having to negotiate that state space explosion head on by a priori ruling out vast swaths of potential inputs. I think static typing and testing are much more complementary than you're giving them credit for.

mpweiher 11y ago
> But testing ensures no such thing Yes it does. Empirically. >considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases Fortunately, it is also not necessary, as numerous studies have found. >I think static typing and testing are much more complementary than you're giving them credit for. I totally agree that they are complementary. I find static typing to be most useful as checked documentation (for which, unlike the safety aspects, there is actual empirical evidence). Also, it makes various optimizations easy/cheap/predictable, which I find highly valuable. Finally, it does help a little bit with correctness, though far less than what many people claim. However, it also has costs that are not insignificant, in slowing down exploratory programming, compile-time costs, brittleness of designs and often code expansion / productivity. More importantly, it appears to harm compositionality/reuse, at least at our current level of understanding. Both Unix Pipes and Filters and the Web, arguably the most successful reuse mechanisms in the history of software, are dynamically and somewhat loosely typed. In addition, personal computing was invented in around 20KLOC using Smalltalk, a dynamically typed OO language.
- AnimalMuppet 11y ago
  > > But testing ensures no such thing > Yes it does. Empirically. Your claim was "Testing ensures that the knowledge is checked." And, yes, testing ensures that the knowledge is checked - by the test. mrbrowning's claim is that "Static typing ensures that some sliver of that knowledge is explicit and checked." That's also true (despite your reply of "No"). And note mrbrowning's use of the word "explicit". Type knowledge is more explicit than a test. It ensures that this data structure is an instance of the specified type. A test proves that in this set of circumstances this data structure behaves the way we expect, which is a weaker proof.
  - isolate 11y ago
    > It ensures that this data structure is an instance of the specified type. But downcasts are unsafe.
- kazinator 11y ago
  > >considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases > > Fortunately, it is also not necessary, as numerous studies have found. If you know something about how some function or module works and you check the right corner cases, the only way a bug could be hiding in some of the other input combinations is if it were deliberately planted in the form of extra code, like "if the inputs are specifically x, y and z, then misbehave such and such". For instance if we know that a 32 bit adder is made up of bunch of full adders, there are certain bit patterns we can use which tell us that the adders are working properly individually, and that they are hooked up together right. We don't have to test every A + B = C triplet, blackbox style.

mpweiher 11y ago

> But testing ensures no such thing Yes it does. Empirically. >considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases Fortunately, it is also not necessary, as numerous studies have found. >I think static typing and testing are much more complementary than you're giving them credit for. I totally agree that they are complementary. I find static typing to be most useful as checked documentation (for which, unlike the safety aspects, there is actual empirical evidence). Also, it makes various optimizations easy/cheap/predictable, which I find highly valuable. Finally, it does help a little bit with correctness, though far less than what many people claim. However, it also has costs that are not insignificant, in slowing down exploratory programming, compile-time costs, brittleness of designs and often code expansion / productivity. More importantly, it appears to harm compositionality/reuse, at least at our current level of understanding. Both Unix Pipes and Filters and the Web, arguably the most successful reuse mechanisms in the history of software, are dynamically and somewhat loosely typed. In addition, personal computing was invented in around 20KLOC using Smalltalk, a dynamically typed OO language.

AnimalMuppet 11y ago
> > But testing ensures no such thing > Yes it does. Empirically. Your claim was "Testing ensures that the knowledge is checked." And, yes, testing ensures that the knowledge is checked - by the test. mrbrowning's claim is that "Static typing ensures that some sliver of that knowledge is explicit and checked." That's also true (despite your reply of "No"). And note mrbrowning's use of the word "explicit". Type knowledge is more explicit than a test. It ensures that this data structure is an instance of the specified type. A test proves that in this set of circumstances this data structure behaves the way we expect, which is a weaker proof.
- isolate 11y ago
  > It ensures that this data structure is an instance of the specified type. But downcasts are unsafe.
kazinator 11y ago
> >considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases > > Fortunately, it is also not necessary, as numerous studies have found. If you know something about how some function or module works and you check the right corner cases, the only way a bug could be hiding in some of the other input combinations is if it were deliberately planted in the form of extra code, like "if the inputs are specifically x, y and z, then misbehave such and such". For instance if we know that a 32 bit adder is made up of bunch of full adders, there are certain bit patterns we can use which tell us that the adders are working properly individually, and that they are hooked up together right. We don't have to test every A + B = C triplet, blackbox style.