3 ms·

This is obviously false, it’s just too general a statement. Type errors are such a small time loss as a developer - when i think of the things that lose me time

This is obviously false, it’s just too general a statement. Type errors are such a small time loss as a developer - when i think of the things that lose me time, it’s things like domain complexity, misunderstood requirements, not “ooops i passed a string instead of list of string”. I wondered if there are any studies that support your assertion? The first few results in Google all refute your idea though, e.g. https://www.researchgate.net/publication/259634489_An_empirical_study_on_the_impact_of_static_typing_on_software_maintainability https://www.researchgate.net/publication/259634489_An_empiri... Or https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hanenberg.pdf https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane... And that intuitively makes sense. When i’m adopting types, time saving isn’t really what i’m buying. It’s the opposite - i’m saying “hey, i want to invest more time into this to help ensure correctness” - i.e. i am happy to wrestle with the type system if it means the delegation frees my brain for solving the problem. And this comes back to what i mentioned earlier about domain complexity - you can use types to help make that easier to manage, often though, it’s better to push harder to eliminate complexity in the first place. Occasionally that’s just not possible, it’s a complex problem domain not another CRUD webapp, in those cases types are fantastic.

skohan 6y ago
> Type errors are such a small time loss as a developer It's not about the errors themselves, it's about the way that having a strong type system improves quality of life in general. For instance, in a duck-typed language, you may have code which runs correctly 99/100 times, but with one specific case it fails due to type issues. These kinds of issues are incredibly frustrating and time-consuming to debug. Also requiring type designations in function signatures makes code self-documenting. You can just look at the code which someone else wrote, and know exactly what the inputs and outputs are. In a dynamically typed setting, there's often guess work involved in exactly what's accepted by a function, and unless it's very well documented you might have to go into the implementation to see exactly what is happening. I didn't read the articles you linked in detail, but at least the first I would take with a grain of salt since they use Java as the exemplar for typed programming. Java is notorious for having a cumbersome type system. In my experience, without types you might get a slightly faster time to first result - but in the long term, once a codebase gets to even medium size, types save you much more time than they cost. Especially since they become automatic after a bit of experience and you don't even think about it anymore. There's a reason Python and Javascript are trying to add types, and why none of the most interesting languages of the past decade have been weekly typed.
- CraigJPerry 6y ago
  I think you might have missed my point, it’s not a binary good/bad - both approaches have a useful place.
  - skohan 6y ago
    I think we just disagree. I understand your point, but I think that the benefits of having strong types outweigh any drawbacks in almost all cases. The benefits are huge once you get past a very small program (100 lines was a little flippant on my part) and the drawbacks rapidly approach zero for any sufficiently well-designed type-system
    - CraigJPerry 6y ago
      :-) FWIW, through my career i changed my views on this topic. I started off loving dynamic, then i spent years preferring static. Nowadays i don’t actually have too strong an opinion on types (despite what this thread might suggest!), both approaches have value. These days i place value in something else - less lines of code. Expressive languages like Python & Clojure, these make a lot of sense to me because in my experience nothing correlates stronger with bugs than too many lines of code. By this logic i should be writing in APL but i suspect that goes too far the other direction!

skohan 6y ago

> Type errors are such a small time loss as a developer It's not about the errors themselves, it's about the way that having a strong type system improves quality of life in general. For instance, in a duck-typed language, you may have code which runs correctly 99/100 times, but with one specific case it fails due to type issues. These kinds of issues are incredibly frustrating and time-consuming to debug. Also requiring type designations in function signatures makes code self-documenting. You can just look at the code which someone else wrote, and know exactly what the inputs and outputs are. In a dynamically typed setting, there's often guess work involved in exactly what's accepted by a function, and unless it's very well documented you might have to go into the implementation to see exactly what is happening. I didn't read the articles you linked in detail, but at least the first I would take with a grain of salt since they use Java as the exemplar for typed programming. Java is notorious for having a cumbersome type system. In my experience, without types you might get a slightly faster time to first result - but in the long term, once a codebase gets to even medium size, types save you much more time than they cost. Especially since they become automatic after a bit of experience and you don't even think about it anymore. There's a reason Python and Javascript are trying to add types, and why none of the most interesting languages of the past decade have been weekly typed.

CraigJPerry 6y ago
I think you might have missed my point, it’s not a binary good/bad - both approaches have a useful place.
- skohan 6y ago
  I think we just disagree. I understand your point, but I think that the benefits of having strong types outweigh any drawbacks in almost all cases. The benefits are huge once you get past a very small program (100 lines was a little flippant on my part) and the drawbacks rapidly approach zero for any sufficiently well-designed type-system
  - CraigJPerry 6y ago
    :-) FWIW, through my career i changed my views on this topic. I started off loving dynamic, then i spent years preferring static. Nowadays i don’t actually have too strong an opinion on types (despite what this thread might suggest!), both approaches have value. These days i place value in something else - less lines of code. Expressive languages like Python & Clojure, these make a lot of sense to me because in my experience nothing correlates stronger with bugs than too many lines of code. By this logic i should be writing in APL but i suspect that goes too far the other direction!