4 ms·

> then they don’t deserve code that is prove I don't get it. Types are a way to write code. Nothing to do with how fast/much the code changes.

• scotty79 10mo ago
  Typed code is significantly more cumbersome to change (because there's more code to change). At least until you reach a certain size of your spaghetti bowl. Then both typed and untyped are cumbersome and people endlessly discuss which one is more.
  • skydhash 10mo ago
    I don’t think so. With a good editor, you change the type and run the compiler which will warn you with all the locations you’ll need to edit. Then you can quickly navigate to those locations.
    • scotty79 10mo ago
      Yeah, tooling for strongly typed languages is way better than 20 years ago. They are getting very being usable.
    • embedding-shape 10mo ago
      > which will warn you with all the locations you’ll need to edit This is true, but with a program built with a dynamic language, taking advantage of the fact that it's written in a dynamic language, doesn't need to make those changes at all. I'm fan of static typing in many situations, but it's hard to deny it doesn't lead to more changes as you need to properly propagate changes.
      • ARandumGuy 10mo ago
        I don't find that dynamic typing reduces the number of places I need to update stuff. It just changes when the error occurs. If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.
        • embedding-shape 10mo ago
          Just one simple and contrived example I could come up with the five minutes I had available: JavaScript: // rename host -> hostname, update ONE place function connect(opts) { const host = opts.hostname ?? opts.host; // compat shim return `tcp://${host}:${opts.port}`; } // old call sites keep working connect({ host: "db", port: 5432 }); connect({ host: "cache", port: 6379 }); // new call sites also work connect({ hostname: "db", port: 5432 }); TypeScript: // same compat goal, but types force propagation unless you widen them type Opts = { port: number } & ({ host: string } | { hostname: string }); function connect(opts: Opts) { const host = "hostname" in opts ? opts.hostname : opts.host; return `tcp://${host}:${opts.port}`; } // If instead you "just rename" the type to {hostname; port}, // EVERY call site using {host; port} becomes a compile error. Again, this is just a simple example. But multiply 100x + way messier codebases where everything are static types and intrinsically linked with each other, and every change becomes "change -> compile and see next spot to change -> change" until you've worked through 10s of files, instead of just changing it in one place. Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.
          • ARandumGuy 10mo ago
            In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames, a process that takes like 2 seconds. You might have problems if the change exists at a service boundry, but in that case I'd just put the transformation at the service boundry, and keep everything the same internally. > Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing. I'd argue static typing makes this much easier, because I know any input types (or output types from other components) will be enforced by the type system. So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected". The type system handles all of that, which eliminated a lot of tedious boilerplate tests.
• jama211 10mo ago
  It’s more work, if it wasn’t there’d be no debate.