2 ms·

> There are studies that estimate that the kind of bugs shipped to production that strong static types help prevent account for only 2% of defects. The rest are

> There are studies that estimate that the kind of bugs shipped to production that strong static types help prevent account for only 2% of defects. The rest are things like off-by-one errors, design errors, and incorrect logic. If you've got a reference, I'd be interested. (Not saying you're wrong...) > The other thing a static type system can help you with is reading code. But it's primarily an aid to people unfamiliar with the language, or put in more popular parlance a "skills issue." It's an aid to people who are unfamiliar with the program, who have no idea what the shape of "that thing" is. (Especially, what is the shape of the thing that this function gets called with? For all possible callers?) I've been hired to start working on code bases that have existed for a decade or two. Static, stated types are a life saver. Sure, they may slow you down while you're creating the code. It's easier to not have to explain everything that's in your brain. But when you and your brain leave, and I'm left with a bunch of variables that I have no idea what type they are - what are the maximum set of types that they can be for all paths through all callers - then I really need static types to help me figure out what's going on.

slowmovintarget 2y ago
Or you need a REPL that lets you poke at the living code. It's just different.
- Capricorn2481 2y ago
  I think their point is, even with the REPL, it takes time to track down every spot that function might be called and figure out what was passed to it. A type is very easy to see localized on the function.
  - iLemming 2y ago
    > A type is very easy to see localized on the function. "You Keep Using That Word, I Do Not Think It Means What You Think It Means"... When you say "types," can you please give a concrete example of what languages you're talking about? Whenever someone talks about Clojure from type theory talking points, they make it sound like it's completely untyped or weakly typed. Clojure has its own type systems, and you can express things in them that are far more difficult to do in some other languages, even with static types. It is also a strongly typed language, and in practice, I feel far more confident about our Clojure code than anything written in TS or Java. Sure, static type systems have their value, and some of them are really nice. In practice though, whenever I have to jump in to deal with Java, Typescript, or even Rust code - there's so much seemingly unnecessary fluff, and I don't feel the practical worth of dealing with types - it almost always feels taxing. Haskell/OCaml is a different story - I can buy that one. But realistically, getting to the point of writing practical software in Haskell is an incredibly bumpy road, and (relatively) few programmers successfully achieve good milestones on it.
    - Capricorn2481 2y ago
      I use Clojure. I'm aware it's strongly typed. I never said it wasn't, actually. You might want to reread my comment. But I can't expect most codebases to use spec or malli. The comment I replied to said that's what the REPL is for. A REPL, while helpful for a lot of things, will not tell you about an argument faster than a type annotation.
slowmovintarget 2y ago
On the studies, I believe the results were drawn from this [1] study and followed up here [2]. I seem to recall reading a blog post based on these results, but I could be mistaken. [1]: A Large-scale Study of Programming Languages and Code Quality in GitHub https://dl.acm.org/doi/10.1145/3126905 https://dl.acm.org/doi/10.1145/3126905 [2]: On the Impact of Programming Languages on Code Quality: A Reproduction Study https://dl.acm.org/doi/fullHtml/10.1145/3340571 https://dl.acm.org/doi/fullHtml/10.1145/3340571

slowmovintarget 2y ago

Or you need a REPL that lets you poke at the living code. It's just different.

Capricorn2481 2y ago
I think their point is, even with the REPL, it takes time to track down every spot that function might be called and figure out what was passed to it. A type is very easy to see localized on the function.
- iLemming 2y ago
  > A type is very easy to see localized on the function. "You Keep Using That Word, I Do Not Think It Means What You Think It Means"... When you say "types," can you please give a concrete example of what languages you're talking about? Whenever someone talks about Clojure from type theory talking points, they make it sound like it's completely untyped or weakly typed. Clojure has its own type systems, and you can express things in them that are far more difficult to do in some other languages, even with static types. It is also a strongly typed language, and in practice, I feel far more confident about our Clojure code than anything written in TS or Java. Sure, static type systems have their value, and some of them are really nice. In practice though, whenever I have to jump in to deal with Java, Typescript, or even Rust code - there's so much seemingly unnecessary fluff, and I don't feel the practical worth of dealing with types - it almost always feels taxing. Haskell/OCaml is a different story - I can buy that one. But realistically, getting to the point of writing practical software in Haskell is an incredibly bumpy road, and (relatively) few programmers successfully achieve good milestones on it.
  - Capricorn2481 2y ago
    I use Clojure. I'm aware it's strongly typed. I never said it wasn't, actually. You might want to reread my comment. But I can't expect most codebases to use spec or malli. The comment I replied to said that's what the REPL is for. A REPL, while helpful for a lot of things, will not tell you about an argument faster than a type annotation.

slowmovintarget 2y ago

On the studies, I believe the results were drawn from this [1] study and followed up here [2]. I seem to recall reading a blog post based on these results, but I could be mistaken. [1]: A Large-scale Study of Programming Languages and Code Quality in GitHub https://dl.acm.org/doi/10.1145/3126905 https://dl.acm.org/doi/10.1145/3126905 [2]: On the Impact of Programming Languages on Code Quality: A Reproduction Study https://dl.acm.org/doi/fullHtml/10.1145/3340571 https://dl.acm.org/doi/fullHtml/10.1145/3340571