7 ms·

It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is

by sumy23 4y ago

It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is some reason that including type information increases bugs, the existence of a single example where type information catches a bug would prove that overall type information reduces total bug count.

thom 4y ago
One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.
- mdtusz 4y ago
  This is true in a local context, but entirely breaks down when a codebase becomes larger than a single person can fit into their brain-RAM. Not arguing or saying you're wrong - just presenting the very quickly reached boundary where the argument breaks down.
  - BlargMcLarg 4y ago
    It's not just local context. Reading a dense book is still more difficult than reading a less dense book, given a fairly similar amount of information and style in conveying that information. Larger codebases suffer the same problem you mention in a different way, and cargocults in most static languages tend to advocate very verbose writing styles. Where this falls apart, the more verbose writing style hasn't been proven to convey more information or in a better way. That's an assumption still tossed around.
    - kangda123 4y ago
      It is just a fair bit harder to figure out the types as program grows.
      - falcolas 4y ago
        Not in my experience. Language engines are good enough to help most of the time, And typed or untyped, you’re only ever reasoning about the types in the context you’re working in, not the entire program.
        kangda123 4y ago
        Can you actually determine things like that with an engine? A Python function can be called from within or from outside of your codebase with different callsites passing different types.
- tharkun__ 4y ago
  I would even argue that shorter can do the opposite. You can squeeze an awful lot of information into a tight space in dynamically typed languages that allow functional programming and especially with terse syntax for often used constructs. This can make it much harder to actually reason about the code, while making it seem easier to reason about. Most people would agree w/ your reasoning on a short piece of logic, which then at runtime spectacularly fails because the inputs don't adhere to the types you expected. In a statically typed language you would not even have gotten it to compile and while it might not feel like a bug is being prevented and actually feel tedious, every time your IDE (or compiler) tells you that the type on something is wrong, you've prevented a potential bug.
  - ncmncm 4y ago
    Yes. Shorter means less to compare against for consistency.
    - tharkun__ 4y ago
      My point is exactly the opposite. Shorter does not always equals easier, less to do etc. Let's say we compare Javascript and Typescript (as they're so close but one has static typing. const myFunc = (param) => { doSomethingWith(param?.property); } Easy, right? Well, does param actually have `property`? No idea. What type is `property`? Does the function `doSomethingWith` take that kind of input? No idea. Now I have to check that function, which might be coming from I don't know where, I might not even have an IDE that can reliably determine where `doSomethingWith` is coming from exactly. Even if I can navigate there now I have to check that piece of code and any other code it calls with `property`. Maybe `property` itself is an object and `doSomethingWith` assumes it has yet another property. This can easily go quite deep and I will not be able to easily reason about this at all. You can't tell me that someone can have all possible runtime combinations of this in his head for any reasonably sized program. Now let's take something that is almost equal but slightly longer to read and write, same thing in Typescript. I've had to define the types of these things somewhere once. Big deal. const myFunc = (param: SomeType) => { doSomethingWith(param.property); } Notice how this is really not much of a difference. Just a type declaration and it gives me a lot of safety. Let's assume SomeType defined `property` as non-null, so no `?` needed, I know my inputs have already been checked. `doSomethingWith` also defines its parameter type correctly and we know what `property` is or isn't. No need to know anything from the top of my head or spend time digging through code myself. The compiler knows that I am passing the correct type of object along and I won't get a runtime error (well, OK, it's Typescript, so let's also assume I'm not in a mixed TS/JS code base where I might very easily get `any` kind of object. Now syntax will be a little bit different, but I would argue the exact same thing in say Java or Kotlin is equivalently short and readable (yes even in Java!) while benefiting from even more type safety: public myFunc(SomeType param) { doSomethingWith(param.getProperty()); } Didn't really hurt much, did it? But these are super simple example. It get can arbitrarily complex.
- therealdrag0 4y ago
  Shorter how? The typing can often be implicit in many languages like Scala which makes it pretty short compared to something like Java. While there is a bit of explicit typing, I think it’s well into diminishing returns to force even shorter code.
- ebingdom 4y ago
  As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose. I associate verbosity with object-oriented programming, whether statically typed or not.
  - danieltanfh95 4y ago
    As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain
    - ebingdom 4y ago
      > static typing is less expressive than dynamic typing Here's something I can express with static typing that I can't express with dynamic typing: "this function returns a function which returns an integer for every input". There's no test you could write to verify this property. So I'm inclined to say that static typing is more expressive, since it gives me a way to express and verify properties like this.
      - blain_the_train 4y ago
        clojure spec will do this in the way you're asking.
    - ncmncm 4y ago
      Not even wrong. Without compile-time types, you are not equipped to express serious compile-time work.
drujensen 4y ago
This reminds me of the studies done related to traffic lights and stop signs. Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert. Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax with testing things related to types. When you develop in non-typed languages like Ruby, you tend to write more tests and not trust your compiler (because you don't have one). This is why you will find most Ruby developers are really good at writing tests and embracing TDD.
- deleted 4y ago
  [deleted]
- kevinmchugh 4y ago
  I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.
  - siwatanejo 4y ago
    > A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.
    - creakingstairs 4y ago
      They all have nulls but a static lang will warn you that the value can be null.
      - tene 4y ago
        This is false. There are plenty of languages without pervasive implicit nullability. Check out Haskell and Rust and Ocaml.
jacobsenscott 4y ago
It is not evident to me. Having used both statically typed and dynamically typed languages my experience is that I can't remember ever seeing a bug in our fairly large rails app that a type system would catch. Nobody's passing strings where hashes are expected, or Widget instances where User instances are expected. The thing to pass to the function is nearly always self evident. If you did it would immediately be caught when a test runs anyway. However, refactoring code in C# is much easier than refactoring ruby because you can lean on the type system there. However writing new code in C# is often much harder to do in C# because of the constraints of the type system. So really, it ends up being a wash for me.
- unethical_ban 4y ago
  >Nobody's passing strings where hashes are expected See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.
- imiric 4y ago
  > If you did it would immediately be caught when a test runs anyway. That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.
  - tene 4y ago
    With static types, every function signature implicitly comes with built-in tests for free.
    - jacobsenscott 4y ago
      Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.
YetAnotherNick 4y ago
Static typing doesn't mean type information being available. Most statically typed language allow some version of `let x = 5`. Similarly static types doesn't mean unsafe casting are not performed. Also in the opposite direction, many dynamically typed language allows specifying types if you want to including python.
- the_only_law 4y ago
  > let x = 5 x still has static type, the compiler just infers it based on the assignment, the type information is still there. Agree that implicit/unsafe casting is still and issue in some languages though.
falcolas 4y ago
> It’s basically self-evident that static analysis reduces bugs. And yet, per TFA, it’s not; at a minimum it’s clearly not “self evident”. Why do we developers value our personal experience above studies, while dunking on average citizens for doing the same? Guess we’re just as human as the rest of humanity; subject to the same urge to trust our own beliefs over contrary evidence.
- ncmncm 4y ago
  Because the studies are constructed by equally fallible humans, and almost always badly. Cold shower attempted, but the plumbing was busted? Such studies invariably wholly miss the point: when you have a language with powerful type support, error checking is the least valuable work you get out of them. Types do serious heavy lifting expressing semantics.
- srer 4y ago
  As a general rule for dev work, trying to make evidence based decisions is fairly difficult. There's just not that much evidence around yet that can make it obvious as to if in your particular situation what the best choice might be. And at the end of the day you have to contend with being in a work environment where politics and personalities rule, not science (or engineering). That said I do wish more devs would take an interest in the available quality literature. Unfortunately I'm far more likely at work to run into an Uncle Bob recommendation at work, than a recommendation of ACM's Digital Library.

by sumy23 4y ago

thom 4y ago

One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.

mdtusz 4y ago
This is true in a local context, but entirely breaks down when a codebase becomes larger than a single person can fit into their brain-RAM. Not arguing or saying you're wrong - just presenting the very quickly reached boundary where the argument breaks down.
- BlargMcLarg 4y ago
  It's not just local context. Reading a dense book is still more difficult than reading a less dense book, given a fairly similar amount of information and style in conveying that information. Larger codebases suffer the same problem you mention in a different way, and cargocults in most static languages tend to advocate very verbose writing styles. Where this falls apart, the more verbose writing style hasn't been proven to convey more information or in a better way. That's an assumption still tossed around.
  - kangda123 4y ago
    It is just a fair bit harder to figure out the types as program grows.
    - falcolas 4y ago
      Not in my experience. Language engines are good enough to help most of the time, And typed or untyped, you’re only ever reasoning about the types in the context you’re working in, not the entire program.
      - kangda123 4y ago
        Can you actually determine things like that with an engine? A Python function can be called from within or from outside of your codebase with different callsites passing different types.
tharkun__ 4y ago
I would even argue that shorter can do the opposite. You can squeeze an awful lot of information into a tight space in dynamically typed languages that allow functional programming and especially with terse syntax for often used constructs. This can make it much harder to actually reason about the code, while making it seem easier to reason about. Most people would agree w/ your reasoning on a short piece of logic, which then at runtime spectacularly fails because the inputs don't adhere to the types you expected. In a statically typed language you would not even have gotten it to compile and while it might not feel like a bug is being prevented and actually feel tedious, every time your IDE (or compiler) tells you that the type on something is wrong, you've prevented a potential bug.
- ncmncm 4y ago
  Yes. Shorter means less to compare against for consistency.
  - tharkun__ 4y ago
    My point is exactly the opposite. Shorter does not always equals easier, less to do etc. Let's say we compare Javascript and Typescript (as they're so close but one has static typing. const myFunc = (param) => { doSomethingWith(param?.property); } Easy, right? Well, does param actually have `property`? No idea. What type is `property`? Does the function `doSomethingWith` take that kind of input? No idea. Now I have to check that function, which might be coming from I don't know where, I might not even have an IDE that can reliably determine where `doSomethingWith` is coming from exactly. Even if I can navigate there now I have to check that piece of code and any other code it calls with `property`. Maybe `property` itself is an object and `doSomethingWith` assumes it has yet another property. This can easily go quite deep and I will not be able to easily reason about this at all. You can't tell me that someone can have all possible runtime combinations of this in his head for any reasonably sized program. Now let's take something that is almost equal but slightly longer to read and write, same thing in Typescript. I've had to define the types of these things somewhere once. Big deal. const myFunc = (param: SomeType) => { doSomethingWith(param.property); } Notice how this is really not much of a difference. Just a type declaration and it gives me a lot of safety. Let's assume SomeType defined `property` as non-null, so no `?` needed, I know my inputs have already been checked. `doSomethingWith` also defines its parameter type correctly and we know what `property` is or isn't. No need to know anything from the top of my head or spend time digging through code myself. The compiler knows that I am passing the correct type of object along and I won't get a runtime error (well, OK, it's Typescript, so let's also assume I'm not in a mixed TS/JS code base where I might very easily get `any` kind of object. Now syntax will be a little bit different, but I would argue the exact same thing in say Java or Kotlin is equivalently short and readable (yes even in Java!) while benefiting from even more type safety: public myFunc(SomeType param) { doSomethingWith(param.getProperty()); } Didn't really hurt much, did it? But these are super simple example. It get can arbitrarily complex.
therealdrag0 4y ago
Shorter how? The typing can often be implicit in many languages like Scala which makes it pretty short compared to something like Java. While there is a bit of explicit typing, I think it’s well into diminishing returns to force even shorter code.
ebingdom 4y ago
As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose. I associate verbosity with object-oriented programming, whether statically typed or not.
- danieltanfh95 4y ago
  As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain
  - ebingdom 4y ago
    > static typing is less expressive than dynamic typing Here's something I can express with static typing that I can't express with dynamic typing: "this function returns a function which returns an integer for every input". There's no test you could write to verify this property. So I'm inclined to say that static typing is more expressive, since it gives me a way to express and verify properties like this.
    - blain_the_train 4y ago
      clojure spec will do this in the way you're asking.
  - ncmncm 4y ago
    Not even wrong. Without compile-time types, you are not equipped to express serious compile-time work.

drujensen 4y ago

This reminds me of the studies done related to traffic lights and stop signs. Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert. Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax with testing things related to types. When you develop in non-typed languages like Ruby, you tend to write more tests and not trust your compiler (because you don't have one). This is why you will find most Ruby developers are really good at writing tests and embracing TDD.

deleted 4y ago
[deleted]
kevinmchugh 4y ago
I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks. A type system can keep you from having to write those tests.
- siwatanejo 4y ago
  > A type system can keep you from having to write those tests. Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.
  - creakingstairs 4y ago
    They all have nulls but a static lang will warn you that the value can be null.
    - tene 4y ago
      This is false. There are plenty of languages without pervasive implicit nullability. Check out Haskell and Rust and Ocaml.

jacobsenscott 4y ago

It is not evident to me. Having used both statically typed and dynamically typed languages my experience is that I can't remember ever seeing a bug in our fairly large rails app that a type system would catch. Nobody's passing strings where hashes are expected, or Widget instances where User instances are expected. The thing to pass to the function is nearly always self evident. If you did it would immediately be caught when a test runs anyway. However, refactoring code in C# is much easier than refactoring ruby because you can lean on the type system there. However writing new code in C# is often much harder to do in C# because of the constraints of the type system. So really, it ends up being a wash for me.

unethical_ban 4y ago
>Nobody's passing strings where hashes are expected See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.
imiric 4y ago
> If you did it would immediately be caught when a test runs anyway. That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.
- tene 4y ago
  With static types, every function signature implicitly comes with built-in tests for free.
  - jacobsenscott 4y ago
    Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.

YetAnotherNick 4y ago

Static typing doesn't mean type information being available. Most statically typed language allow some version of `let x = 5`. Similarly static types doesn't mean unsafe casting are not performed. Also in the opposite direction, many dynamically typed language allows specifying types if you want to including python.

the_only_law 4y ago
> let x = 5 x still has static type, the compiler just infers it based on the assignment, the type information is still there. Agree that implicit/unsafe casting is still and issue in some languages though.

falcolas 4y ago

> It’s basically self-evident that static analysis reduces bugs. And yet, per TFA, it’s not; at a minimum it’s clearly not “self evident”. Why do we developers value our personal experience above studies, while dunking on average citizens for doing the same? Guess we’re just as human as the rest of humanity; subject to the same urge to trust our own beliefs over contrary evidence.

ncmncm 4y ago
Because the studies are constructed by equally fallible humans, and almost always badly. Cold shower attempted, but the plumbing was busted? Such studies invariably wholly miss the point: when you have a language with powerful type support, error checking is the least valuable work you get out of them. Types do serious heavy lifting expressing semantics.
srer 4y ago
As a general rule for dev work, trying to make evidence based decisions is fairly difficult. There's just not that much evidence around yet that can make it obvious as to if in your particular situation what the best choice might be. And at the end of the day you have to contend with being in a work environment where politics and personalities rule, not science (or engineering). That said I do wish more devs would take an interest in the available quality literature. Unfortunately I'm far more likely at work to run into an Uncle Bob recommendation at work, than a recommendation of ACM's Digital Library.