3 ms·

You're right that it has a cost (although type inference can significantly reduce that cost). But... From TFA: "They write test cases for every identifier ev

You're right that it has a cost (although type inference can significantly reduce that cost). But... From TFA: "They write test cases for every identifier ever used in the program. In a world where misspellings are silently ignored, this is necessary. This is a cost." So in a dynamic language the cost is still there. In fact, it's probably higher than in a static language because you have to build at least some of the infrastructure yourself. Well, I imagine some people would argue that in a dynamic language the cost is optional. And again, I point to type inference where sophisticated static languages achieve the same thing.

andybak 13y ago
> In a world where misspellings are silently ignored, this is necessary. How does "dynamic typing"="misspellings are silently ignored"? Maybe in some languages but that's not a corollary of dynamic typing. Disclaimer: Haven't read TFA so shoot me down if the context makes this clear
- mightybyte 13y ago
  TFA was talking specifically about Javascript there. But I think the overall point about the cost of testing applies to dynamic typing across the board.
  - nailer 13y ago
    How would one consider JS to silently ignore misspellings?
marcosdumay 13y ago
Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs. And yes, you'll need to do a little bit of infrastructure on the test cases, but you'll gain the extra power that comes with dynamic types, that makes everything (even writting tests) much easier. And, of course, your codebase can be much less "huge" with that extra power. Anyway, all that thing is a big red herring. Nobody decides to create a huge codebase.
- mightybyte 13y ago
  > but you'll gain the extra power that comes with dynamic types What "extra power" are we talking about here? If we're talking about the power to pretend a bool is a string or vice versa, then no thanks, I'll pass. I suspect that a number of the things you are referring to that give you "extra power" are actually things that don't have anything to do with the type system like first class functions, tuples, etc. Static languages can have those things too, you know.
  - awj 13y ago
    > If we're talking about the power to pretend a bool is a string or vice versa, then no thanks That's weak typing. JavaScript does this, Python and Ruby don't. Typically when people bring up the power of dynamic languages it's in the ability to alter definitions. The ability to extend existing classes/objects is pretty powerful, and isn't always trivially duplicated in static languages. Many concepts that can be painful in statically typed languages (creating/programming against new interfaces to existing types, reflection, delegation, etc) are easy as breathing with dynamic types. It's not a matter of can vs. can't so much as easy vs hard.
    - mightybyte 13y ago
      Oh right, my mistake. s/pretend a bool is a string or vice versa/not know whether an object even has a certain method because it isn't added until runtime/ I'll grant you that this type of thing is more difficult in static languages. But in my experience, the need for this kind of dynamic behavior is quite rare in terms of lines of code. So I'll trade it away any day of the week for the ability to reason about my code with more guarantees. At their core, all bugs are situations where the programmer's expectations didn't match reality. In my experience programmers who are good at debugging are good at being able to question as much of what could be going wrong as possible. Strong static types are about reducing the amount of things we have to question.
- dllthomas 13y ago
  "Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs." Agda is offended.

andybak 13y ago

> In a world where misspellings are silently ignored, this is necessary. How does "dynamic typing"="misspellings are silently ignored"? Maybe in some languages but that's not a corollary of dynamic typing. Disclaimer: Haven't read TFA so shoot me down if the context makes this clear

mightybyte 13y ago
TFA was talking specifically about Javascript there. But I think the overall point about the cost of testing applies to dynamic typing across the board.
- nailer 13y ago
  How would one consider JS to silently ignore misspellings?

marcosdumay 13y ago

Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs. And yes, you'll need to do a little bit of infrastructure on the test cases, but you'll gain the extra power that comes with dynamic types, that makes everything (even writting tests) much easier. And, of course, your codebase can be much less "huge" with that extra power. Anyway, all that thing is a big red herring. Nobody decides to create a huge codebase.

mightybyte 13y ago
> but you'll gain the extra power that comes with dynamic types What "extra power" are we talking about here? If we're talking about the power to pretend a bool is a string or vice versa, then no thanks, I'll pass. I suspect that a number of the things you are referring to that give you "extra power" are actually things that don't have anything to do with the type system like first class functions, tuples, etc. Static languages can have those things too, you know.
- awj 13y ago
  > If we're talking about the power to pretend a bool is a string or vice versa, then no thanks That's weak typing. JavaScript does this, Python and Ruby don't. Typically when people bring up the power of dynamic languages it's in the ability to alter definitions. The ability to extend existing classes/objects is pretty powerful, and isn't always trivially duplicated in static languages. Many concepts that can be painful in statically typed languages (creating/programming against new interfaces to existing types, reflection, delegation, etc) are easy as breathing with dynamic types. It's not a matter of can vs. can't so much as easy vs hard.
  - mightybyte 13y ago
    Oh right, my mistake. s/pretend a bool is a string or vice versa/not know whether an object even has a certain method because it isn't added until runtime/ I'll grant you that this type of thing is more difficult in static languages. But in my experience, the need for this kind of dynamic behavior is quite rare in terms of lines of code. So I'll trade it away any day of the week for the ability to reason about my code with more guarantees. At their core, all bugs are situations where the programmer's expectations didn't match reality. In my experience programmers who are good at debugging are good at being able to question as much of what could be going wrong as possible. Strong static types are about reducing the amount of things we have to question.
dllthomas 13y ago
"Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs." Agda is offended.