6 ms·

I know no developers using dynamically and statically typed languages that would deny the benefits of static typing per se. I guess technically you're right he

I know no developers using dynamically and statically typed languages that would deny the benefits of static typing per se. I guess technically you're right here, because what I would do is deny that you have the ability to define "static typing" (or "dynamic typing") in a meaningful way. It's just a matter of fact that you get rid of a certain class of bugs that you have to otherwise cover with (unit) testing. Well, I do occasionally see static-type refugees coming to Python and writing code littered with "assert isinstance(..." checks and the like. But sooner or later they either learn to stop doing that, or go back to their safe space with horror stories about how they had to do all that manual checking. People who stick around have learned you don't need to do that stuff, and I can't think of any code I've personally written in, say, the past five years which used tests or runtime type checks to try to catch type-related bugs. In fact over the past ten years I can only think of one time when a static type checker would've caught a bug that got as far as being committed.

dllthomas 10y ago
"I can't think of any code I've personally written in, say, the past five years which used tests or runtime type checks to try to catch type-related bugs. In fact over the past ten years I can only think of one time when a static type checker would've caught a bug that got as far as being committed." This is clearly a case of "you don't know what you don't know." I strongly suspect that there are many things you deem "not something static typing would catch" that I have been catching with static typing. From the trivial (passing bid price where ask is expected) to the simple (keeping track of which array this index is supposed to point into) to the tricky (restricting certain behaviors to certain threads). And those three examples were from my last big C project - no esoteric type system (some of which make it even more powerful and even more convenient). I won't go so far as to argue that extensive use of static checking is always a win, but it is a tool I find very effective. And it looks very little like "assert isinstance" strung about a Python codebase.
danbruc 10y ago
I guess technically you're right here, because what I would do is deny that you have the ability to define "static typing" (or "dynamic typing") in a meaningful way. A statically typed language is a language where the compiler uses type information about expressions at compile-time to check the validity of a program, otherwise it is a dynamically typed language.
- sklogic 10y ago
  This is exactly the fallacy that dynamic proponents are constantly running into. Do not help them by reinforcing such claims. Static typing bears important semantics far beyond a mere "validity checking" and compile time optimisations. And this fact is overlooked far too often.
  - danbruc 10y ago
    What then would be a better definition in your oppinion?
    - sklogic 10y ago
      In a static type system, all of the expressions and expression-like constructs of your language may have a constraint attached to them, which guarantees that a value this expression yields have certain properties; In a static type system there is a well defined set of rules, describing how such constraints are transformed when expressions are combined in a certain way. In a dynamic type system, no such constraints exist (besides for the constant literals, of course) and there are no rules for combining the constraints. These definitions should cover all the spectrum.
      - ubernostrum 10y ago
        These definitions should cover all the spectrum. This gets close but I think it doesn't yield a conclusion that Java is statically typed, and I think most people want a definition that concludes Java is statically typed. (unless you allow only fairly trivial "constraints" in which case you're no longer distinguishing between categories of languages, since essentially any language can satisfy a trivial-enough constraint on its expressions)
        dllthomas 10y ago
        I think it's reasonable to draw the line somewhere between Java and, say, Python in the kind of constraints that a type system can enforce. Java does not have a particularly sophisticated type system, but I wouldn't be surprised if I could get some reasonable help from it (I haven't written any Java in years, much Java in longer...).
dragonwriter 10y ago
> I can't think of any code I've personally written in, say, the past five years which used tests or runtime type checks to try to catch type-related bugs. All bugs are type-related, with a sufficiently advanced type system.
- ubernostrum 10y ago
  Sure, with certain type systems you can write an "add" function and describe its type such that you can verify it really does return the sum of its arguments. But all you've really accomplished is to move the potential bug to a different layer; before it was possible to write incorrect logic in the function and have a bug, now it's possible to write an incorrect type specification and have a bug. So now you need a type system to let you describe the behavior of your type system (and it has to be a separate thing from the type system). And then you're back where you started, just now with an extra layer of architecture.
tome 10y ago
> In fact over the past ten years I can only think of one time when a static type checker would've caught a bug that got as far as being committed. Then you really don't know how static types can help you.

dllthomas 10y ago

"I can't think of any code I've personally written in, say, the past five years which used tests or runtime type checks to try to catch type-related bugs. In fact over the past ten years I can only think of one time when a static type checker would've caught a bug that got as far as being committed." This is clearly a case of "you don't know what you don't know." I strongly suspect that there are many things you deem "not something static typing would catch" that I have been catching with static typing. From the trivial (passing bid price where ask is expected) to the simple (keeping track of which array this index is supposed to point into) to the tricky (restricting certain behaviors to certain threads). And those three examples were from my last big C project - no esoteric type system (some of which make it even more powerful and even more convenient). I won't go so far as to argue that extensive use of static checking is always a win, but it is a tool I find very effective. And it looks very little like "assert isinstance" strung about a Python codebase.

danbruc 10y ago

I guess technically you're right here, because what I would do is deny that you have the ability to define "static typing" (or "dynamic typing") in a meaningful way. A statically typed language is a language where the compiler uses type information about expressions at compile-time to check the validity of a program, otherwise it is a dynamically typed language.

sklogic 10y ago
This is exactly the fallacy that dynamic proponents are constantly running into. Do not help them by reinforcing such claims. Static typing bears important semantics far beyond a mere "validity checking" and compile time optimisations. And this fact is overlooked far too often.
- danbruc 10y ago
  What then would be a better definition in your oppinion?
  - sklogic 10y ago
    In a static type system, all of the expressions and expression-like constructs of your language may have a constraint attached to them, which guarantees that a value this expression yields have certain properties; In a static type system there is a well defined set of rules, describing how such constraints are transformed when expressions are combined in a certain way. In a dynamic type system, no such constraints exist (besides for the constant literals, of course) and there are no rules for combining the constraints. These definitions should cover all the spectrum.
    - ubernostrum 10y ago
      These definitions should cover all the spectrum. This gets close but I think it doesn't yield a conclusion that Java is statically typed, and I think most people want a definition that concludes Java is statically typed. (unless you allow only fairly trivial "constraints" in which case you're no longer distinguishing between categories of languages, since essentially any language can satisfy a trivial-enough constraint on its expressions)
      - dllthomas 10y ago
        I think it's reasonable to draw the line somewhere between Java and, say, Python in the kind of constraints that a type system can enforce. Java does not have a particularly sophisticated type system, but I wouldn't be surprised if I could get some reasonable help from it (I haven't written any Java in years, much Java in longer...).

dragonwriter 10y ago

> I can't think of any code I've personally written in, say, the past five years which used tests or runtime type checks to try to catch type-related bugs. All bugs are type-related, with a sufficiently advanced type system.

ubernostrum 10y ago
Sure, with certain type systems you can write an "add" function and describe its type such that you can verify it really does return the sum of its arguments. But all you've really accomplished is to move the potential bug to a different layer; before it was possible to write incorrect logic in the function and have a bug, now it's possible to write an incorrect type specification and have a bug. So now you need a type system to let you describe the behavior of your type system (and it has to be a separate thing from the type system). And then you're back where you started, just now with an extra layer of architecture.

tome 10y ago

> In fact over the past ten years I can only think of one time when a static type checker would've caught a bug that got as far as being committed. Then you really don't know how static types can help you.