3 ms·

The cost of strong typing is increased compilation time, increased memory use during compilation, and increased complexity in learning the language. Time spent

The cost of strong typing is increased compilation time, increased memory use during compilation, and increased complexity in learning the language. Time spent resolving type issues during development is time spent testing and debugging shifted left, and generally faster than chasing down bugs. I can recall times when I've neglected a special case to write a one-time script faster, but they were always external to the type system. Eg, "this regex is pretty sketchy, but I know it will work with this particular set of logs." So I'm confused on this point, am I missing something? All programs need to be type checked, even one-off scripts written in dynamic languages, to ensure that they function. The difference is whether the process is manual or automated. The computer is going to do it better and faster than I can, and that will free up mental bandwidth that I can apply to the problem at hand.

scott_w 2y ago
Example: Optional types in a type system require you to handle the null case. Plenty of times you know null isn’t possible (just the interface requires it) so you ignore handling assume it’s never null. In a statically typed language you’ll get an error in the compiler. In Python it’ll run. Reading a file can be similar. These small frictions add up when I’m just trying to make a simple script work by experimentation.
- deleted 2y ago
  [deleted]
- maxbond 2y ago
  At the risk of repeating myself, that sounds like insufficient tooling to me. Are you only seeing these issues when you explicitly compile? And then you have to fix a bunch of them? Because I see them in my editor in real time, and often clean them up with code completion. When I'm writing a one-file script, it's probably going to compile and run the first time.
  - scott_w 2y ago
    My problem is I don’t want to waste my time fixing them at all. I just want to run/debug the code and move on with my life to the next thing. At the risk of repeating myself: I think typing is a powerful tool but to pretend it has no trade-offs is 100% disingenuous or naive. If it didn’t, dynamic or untyped languages simply would never exist!
    - maxbond 2y ago
      That's understandable. Personally after embracing strong typing I find it hard to go back, and I feel like my time and energy is wasted without good feedback from the LSP and reliably understanding what types I'm dealing with or what errors may occur. Dynamic typing isn't free either. As far as the origins of dynamic typing goes, the amount of compute we can dedicate to tooling today, and the development of language servers in particular, radically changes the tradeoffs we can make. Strongly typed languages are better positioned to leverage tooling, and in my view this has completely upended the landscape of language ergonomics. Strong typing might not be free, but it does buy you a lot. Does that view really make me naive or disingenuous? Perhaps we've just had different experiences. To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction.
      - scott_w 2y ago
        > To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction. So you're telling me that the following: data = requests.get(some_link).json()['the_field_i_care_about'] do_something_with(data) is just as much effort as defining the types and dealing with the error case (depending on the language). You're either vastly more intelligent—and a faster typist—than pretty much every human being I've ever interacted with or, more likely, you're lying to me and/or yourself.
        maxbond 2y ago
        I'm sorry that I made you feel disrespected. That wasn't my intention. I'm not any more intelligent or a faster a typist than the next guy. Which is why I place such an emphasis on tooling (like code completion). If you haven't given VSCode or another editor with LSP capabilities a try, you won't regret it.

scott_w 2y ago

Example: Optional types in a type system require you to handle the null case. Plenty of times you know null isn’t possible (just the interface requires it) so you ignore handling assume it’s never null. In a statically typed language you’ll get an error in the compiler. In Python it’ll run. Reading a file can be similar. These small frictions add up when I’m just trying to make a simple script work by experimentation.

deleted 2y ago
[deleted]
maxbond 2y ago
At the risk of repeating myself, that sounds like insufficient tooling to me. Are you only seeing these issues when you explicitly compile? And then you have to fix a bunch of them? Because I see them in my editor in real time, and often clean them up with code completion. When I'm writing a one-file script, it's probably going to compile and run the first time.
- scott_w 2y ago
  My problem is I don’t want to waste my time fixing them at all. I just want to run/debug the code and move on with my life to the next thing. At the risk of repeating myself: I think typing is a powerful tool but to pretend it has no trade-offs is 100% disingenuous or naive. If it didn’t, dynamic or untyped languages simply would never exist!
  - maxbond 2y ago
    That's understandable. Personally after embracing strong typing I find it hard to go back, and I feel like my time and energy is wasted without good feedback from the LSP and reliably understanding what types I'm dealing with or what errors may occur. Dynamic typing isn't free either. As far as the origins of dynamic typing goes, the amount of compute we can dedicate to tooling today, and the development of language servers in particular, radically changes the tradeoffs we can make. Strongly typed languages are better positioned to leverage tooling, and in my view this has completely upended the landscape of language ergonomics. Strong typing might not be free, but it does buy you a lot. Does that view really make me naive or disingenuous? Perhaps we've just had different experiences. To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction.
    - scott_w 2y ago
      > To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction. So you're telling me that the following: data = requests.get(some_link).json()['the_field_i_care_about'] do_something_with(data) is just as much effort as defining the types and dealing with the error case (depending on the language). You're either vastly more intelligent—and a faster typist—than pretty much every human being I've ever interacted with or, more likely, you're lying to me and/or yourself.
      - maxbond 2y ago
        I'm sorry that I made you feel disrespected. That wasn't my intention. I'm not any more intelligent or a faster a typist than the next guy. Which is why I place such an emphasis on tooling (like code completion). If you haven't given VSCode or another editor with LSP capabilities a try, you won't regret it.