3 ms·

That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis, and if you double check everything with static ana

That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis, and if you double check everything with static analysis, you might as well only do the static analysis in the first place. (Static analysis won't always give you an answer, but it won't ever give you a wrong answer.) I am reminded of the folks who optimized .kkrieger, which is a 95 kB first-person shooter. See "Metaprogramming for Madmen": http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-madmen/ http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-... Some highlights: during the test run, the player never pressed the up arrow key in the menu, so that functionality was removed by their tools. Enemies at the beginning never hit the player, so the code which handles damage was compiled out. And the system used a certain brand of graphics card, so code necessary for other graphics cards was compiled out. The lesson is: don't let tools change code semantics based only on black-box testing.

stcredzero 13y ago
> That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis You are right from a theoretical standpoint, but I'm not so sure this fits with how web applications are known to run and the patterns development usually follows. Developers who shove an object of one type in an instance or temporary variable one time, and a different one another time are usually doing something bad, even in dynamic environments -- unless there is a specific interface involved. Just because "duck typing" is fast, doesn't mean that it has to be loose. The point, actually, is to discover where types are being misused as much as to discover what the types are. > The lesson is: don't let tools change code semantics based only on black-box testing. I'm also advocating this. However, it seems like you're mainly familiar with dealing with types in statically typed environments. In dynamic environments, the developers still need to know the types. Often, there are hard and fast rules only enforced by convention. This is indeed a source of errors, but by and large, programmers are very good at managing this. In other words, very often, the programmers will know. I see environments like Dart as a way to eliminate such conventions, but still enable very fast prototyping in the beginning. (Ultimately, static types are better for maintenance.)

stcredzero 13y ago

> That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis You are right from a theoretical standpoint, but I'm not so sure this fits with how web applications are known to run and the patterns development usually follows. Developers who shove an object of one type in an instance or temporary variable one time, and a different one another time are usually doing something bad, even in dynamic environments -- unless there is a specific interface involved. Just because "duck typing" is fast, doesn't mean that it has to be loose. The point, actually, is to discover where types are being misused as much as to discover what the types are. > The lesson is: don't let tools change code semantics based only on black-box testing. I'm also advocating this. However, it seems like you're mainly familiar with dealing with types in statically typed environments. In dynamic environments, the developers still need to know the types. Often, there are hard and fast rules only enforced by convention. This is indeed a source of errors, but by and large, programmers are very good at managing this. In other words, very often, the programmers will know. I see environments like Dart as a way to eliminate such conventions, but still enable very fast prototyping in the beginning. (Ultimately, static types are better for maintenance.)