8 ms·

The conclusion I mead from that summary is not about the value of static typing one way or another but just that the empirical evidence on the matter is unclear

by tikhonj 10y ago

The conclusion I mead from that summary is not about the value of static typing one way or another but just that the empirical evidence on the matter is unclear and uniformly weak. Perhaps this is just a matter of will and funding, but I suspect it's because the underlying question is poorly specified and—like most human issues—extremely hard to study. To me, it's not obvious that asking about static typing in isolation from other parts of language design is meaningful at all.

danbruc 10y ago
It is of course only anecdotal evidence but I know no developers using dynamically and statically typed languages that would deny the benefits of static typing per se. 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. There are of course drawbacks. If your language of choice does not offer type inference you have to write some additional boilerplate code but that may be countered to some extend by good tools with autocomplete and the like. You usually also get better refactoring tools with static typing. Then again it is sometimes harder to make something work because the type system is to restrictive and some duck typing would be really handy. It is a bit of a trade-off, some bugs go away, some code is harder to write. I guess that is what you are hinting at with looking at static typing in isolation. Nonetheless I still have to see a developer who confidently and unconditionally prefers dynamic typing over static typing, but maybe that is just some bias because of the places I work.
- ubernostrum 10y ago
  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?
- mattmcknight 10y ago
  Hi, I confidentally and unconditionally prefer dynamic typing. Just to let you know we exist. Please don't forget that static typing introduces the possibility of compile time defects. Even statically typed languages often support reflection, which is another way of getting the benefits dynamic types. The easier metaprogramming is, the happier I am.
  - tamana 10y ago
    Are you claiming that compile time defects are a flaw in the programming experience? Because running buggy code is a feature?
    - mattmcknight 10y ago
      No, I am pointing out that compile time defects count as a type of defect- see for example the accounting in the CMU SEI PSP: http://www.sei.cmu.edu/reports/00tr022.pdf http://www.sei.cmu.edu/reports/00tr022.pdf
  - sklogic 10y ago
    Compile time reflection have absolutely nothing to do with dynamic typing.
    - mattmcknight 10y ago
      Compile time reflection? Reflection as implemented in most languages allows you to determine the type of an object at runtime.

by tikhonj 10y ago

danbruc 10y ago

It is of course only anecdotal evidence but I know no developers using dynamically and statically typed languages that would deny the benefits of static typing per se. 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. There are of course drawbacks. If your language of choice does not offer type inference you have to write some additional boilerplate code but that may be countered to some extend by good tools with autocomplete and the like. You usually also get better refactoring tools with static typing. Then again it is sometimes harder to make something work because the type system is to restrictive and some duck typing would be really handy. It is a bit of a trade-off, some bugs go away, some code is harder to write. I guess that is what you are hinting at with looking at static typing in isolation. Nonetheless I still have to see a developer who confidently and unconditionally prefers dynamic typing over static typing, but maybe that is just some bias because of the places I work.

ubernostrum 10y ago
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?
mattmcknight 10y ago
Hi, I confidentally and unconditionally prefer dynamic typing. Just to let you know we exist. Please don't forget that static typing introduces the possibility of compile time defects. Even statically typed languages often support reflection, which is another way of getting the benefits dynamic types. The easier metaprogramming is, the happier I am.
- tamana 10y ago
  Are you claiming that compile time defects are a flaw in the programming experience? Because running buggy code is a feature?
  - mattmcknight 10y ago
    No, I am pointing out that compile time defects count as a type of defect- see for example the accounting in the CMU SEI PSP: http://www.sei.cmu.edu/reports/00tr022.pdf http://www.sei.cmu.edu/reports/00tr022.pdf
- sklogic 10y ago
  Compile time reflection have absolutely nothing to do with dynamic typing.
  - mattmcknight 10y ago
    Compile time reflection? Reflection as implemented in most languages allows you to determine the type of an object at runtime.