Exactly this. When speaking about static or dynamic type systems, you can't discuss them in isolation, you need to specify because the holistic experience of ty

Exactly this. When speaking about static or dynamic type systems, you can't discuss them in isolation, you need to specify because the holistic experience of types in JS, Python, Clojure, Elixir, Haskell, Rust, etc. will differ, sometimes drastically. Leaning too much to any side is perilous; it may create a false narrative in your head about what types fundamentally mean and how they should be used. Camping too long on either side may create wrong assumptions like that all/most problems are type problems; make you conflate implementation with concepts and make you miss the real tradeoffs; you'd start ignoring context and scale. Static types aren't always about "safety vs. flexibility" - sometimes they're about tooling, refactoring confidence, or documentation. Dynamic types aren't always about "rapid prototyping" - sometimes they enable architectural patterns that are genuinely difficult to express statically. One really needs to see how Rust's ownership system or Haskell's type inference offers completely different experiences, or how Clojure's emphasis on immutability changes the dynamic typing game entirely.