4 ms·

> It makes it hard to find the right solution through experimentation. To me this suggests the tooling was insufficient. One of the things I value about type s

> It makes it hard to find the right solution through experimentation. To me this suggests the tooling was insufficient. One of the things I value about type systems is being in a tight feedback loop with the compiler. Strong typing helps me run more experiments and to run them from within my editor. But without a good LSP and such, it would be miserable.

scott_w 2y ago
> To me this suggests the tooling was insufficient. Perhaps but I find that type systems usually introduce friction to getting things working that, for some types of projects, can be worthwhile and, for others, not worth the overhead.
- maxbond 2y ago
  I think what you perceive as "friction" I perceive as "feedback," and it helps me work faster while writing code that's as good or better. When I interact with unfamiliar untyped code, it takes me longer to find my footing. So I don't find that there's overhead. I'm not dogmatic, type systems aren't the end all. But I think a lot of the trouble people have with them comes from using the approaches they've developed in untyped systems and saying, "this is the same, I just get more warnings and errors." But the opportunity is in developing new approaches and habits that leverage the type system. For me the "aha" moment was watching Jon Gjenset's YouTube videos, and seeing him intentionally write code with type errors in order to figure out what the type of something was. This helped me make the switch from thinking of errors as drudgery to be avoided to errors as feedback I may want to elicit. Now I'm able to answer lots of questions within my editor that I'd previously need to use a REPL or consult the docs to answer. It's like I'm able to query my codebase, but the query language is just the language I'm already working in. The magic of strong typing is good tooling.
  - scott_w 2y ago
    If it’s not clear: I like working with typed Python code. It absolutely solves a lot of issues that would require a stupid amount of testing and manual checking otherwise (dict-passing is a personal “favourite” I’ve seen). We shouldn’t pretend that it’s free. The fact is, sometimes running some code that I know works despite what the type system is telling me is very useful. Comparing to, say, Go, where I need to deal with everything (even if it’s incidental to the actual problem) adds friction. Sometimes I don’t want to deal with edge cases because this code will never leave my machine!
    - maxbond 2y ago
      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

scott_w 2y ago

> To me this suggests the tooling was insufficient. Perhaps but I find that type systems usually introduce friction to getting things working that, for some types of projects, can be worthwhile and, for others, not worth the overhead.

maxbond 2y ago
I think what you perceive as "friction" I perceive as "feedback," and it helps me work faster while writing code that's as good or better. When I interact with unfamiliar untyped code, it takes me longer to find my footing. So I don't find that there's overhead. I'm not dogmatic, type systems aren't the end all. But I think a lot of the trouble people have with them comes from using the approaches they've developed in untyped systems and saying, "this is the same, I just get more warnings and errors." But the opportunity is in developing new approaches and habits that leverage the type system. For me the "aha" moment was watching Jon Gjenset's YouTube videos, and seeing him intentionally write code with type errors in order to figure out what the type of something was. This helped me make the switch from thinking of errors as drudgery to be avoided to errors as feedback I may want to elicit. Now I'm able to answer lots of questions within my editor that I'd previously need to use a REPL or consult the docs to answer. It's like I'm able to query my codebase, but the query language is just the language I'm already working in. The magic of strong typing is good tooling.
- scott_w 2y ago
  If it’s not clear: I like working with typed Python code. It absolutely solves a lot of issues that would require a stupid amount of testing and manual checking otherwise (dict-passing is a personal “favourite” I’ve seen). We shouldn’t pretend that it’s free. The fact is, sometimes running some code that I know works despite what the type system is telling me is very useful. Comparing to, say, Go, where I need to deal with everything (even if it’s incidental to the actual problem) adds friction. Sometimes I don’t want to deal with edge cases because this code will never leave my machine!
  - maxbond 2y ago
    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