Well, yes, Python can sure feel pretty fucking awkward from both perspectives. It started as fully dynamic, then added type hints, but that's not the main problem with it, in my opinion, the problem that you're still passing around opaque objects, not transparent data.
Compare it with Clojure (and to certain extent Elixir as well). From their view, static typing often feels like wearing a suit of armor to do yoga - it protects against the wrong things while making the important movements harder.
- Most bugs aren't type errors - they're logic errors
- Data is just data - maps, vectors, sets - not opaque objects
- You can literally see your data structure: {:name "Alice" :age 30}
- The interesting constraints (like "end-date > start-date") are semantic, not structural and most static type systems excel at structural checking but struggle with semantic rules - e.g., "Is this user authorized to perform this action?" is nearly impossible to verify with static type systems.
What static types typically struggle with:
- Business rules and invariants
- Relationships between values
- Runtime-dependent constraints
- The actual "correctness" that matters
Static type systems end up creating complex type hierarchies to model what Clojure does with simple predicates. You need dependent types or refinement types to express what clojure.spec handles naturally.
Elixir also uses transparent data structures - maps, tuples, lists, and structs are just maps. It has powerful pattern matching machinery over type hierarchies - you match on shape, not class. Elixir thinks in terms of messages between processes and type safety matters less when processes are isolated.
Python's type hints do help with IDE support and catching basic errors, yet, they don't help with the semantic constraints that matter. They add ceremony without data transparency. You still need runtime validation for real invariants.
So Python gets some static analysis benefits but never gains a truly powerful type system like Haskell's, while also never getting "it's just data" simplicity. So yes, in that sense, Python kinda gets "meh" from both camps.
Well, yes, Python can sure feel pretty fucking awkward from both perspectives. It started as fully dynamic, then added type hints, but that's not the main problem with it, in my opinion, the problem that you're still passing around opaque objects, not transparent data.
Compare it with Clojure (and to certain extent Elixir as well). From their view, static typing often feels like wearing a suit of armor to do yoga - it protects against the wrong things while making the important movements harder.
- Most bugs aren't type errors - they're logic errors
- Data is just data - maps, vectors, sets - not opaque objects
- You can literally see your data structure: {:name "Alice" :age 30}
- The interesting constraints (like "end-date > start-date") are semantic, not structural and most static type systems excel at structural checking but struggle with semantic rules - e.g., "Is this user authorized to perform this action?" is nearly impossible to verify with static type systems.
What static types typically struggle with:
- Business rules and invariants
- Relationships between values
- Runtime-dependent constraints
- The actual "correctness" that matters
Static type systems end up creating complex type hierarchies to model what Clojure does with simple predicates. You need dependent types or refinement types to express what clojure.spec handles naturally.
Elixir also uses transparent data structures - maps, tuples, lists, and structs are just maps. It has powerful pattern matching machinery over type hierarchies - you match on shape, not class. Elixir thinks in terms of messages between processes and type safety matters less when processes are isolated.
Python's type hints do help with IDE support and catching basic errors, yet, they don't help with the semantic constraints that matter. They add ceremony without data transparency. You still need runtime validation for real invariants.
So Python gets some static analysis benefits but never gains a truly powerful type system like Haskell's, while also never getting "it's just data" simplicity. So yes, in that sense, Python kinda gets "meh" from both camps.