4 ms·

If you limit the model to source code diagnostics, you have a good point. But statically typed languages also use the types for other things: optimization, gen

If you limit the model to source code diagnostics, you have a good point. But statically typed languages also use the types for other things: optimization, generic code instantiation, symbol resolution, and even certain kinds of metaprogramming. Optional type checking is a nice way to reduce certain kinds of errors and tighten up some underspecified designs, but it falls very much short of actual static type checking. That being said, most of the unique things static typing provides aren't needed for typical CRUD apps and glue logic, so type annotated python isn't a bad choice.

ehsankia 7y ago
The way Python's type checking is implemented (it's literally just annotations) it can be used for all of the above. There are already libraries that existed before where you can accelerate specific functions, like Numba. Those libraries could switch to using type annotations instead. Similarly, IDEs are already use type annotations to enhance their symbol resolution and so on. Lastly, I'm not sure what you mean by "falls very much short of actual static type checking". With mypy and PyType, you can already catch many bugs that you wouldn't have otherwise, without running the code. That's the definition of static type checking. It may not do as much as c++, but it still catches significantly more than most other pure dynamic languages with no type.
- humanrebar 7y ago
  There are other implications, but binary linking is fraught. Minor errors corrupt entire executables, systems, and data stores, including entirely unrelated subsystems. Often statically typed systems use (at the binary level!) type information to trade off defensiveness (checking that array indexing is in bounds, maybe) for other things (latency, throughput, etc.). Point being, the type information is used for more things than just telling coders about API mismatches. Maybe some libraries could use type information to dynamically use better code paths, but statically typed languages use this information far before that... when the equivalent of a wheel is created, for instance.

ehsankia 7y ago

The way Python's type checking is implemented (it's literally just annotations) it can be used for all of the above. There are already libraries that existed before where you can accelerate specific functions, like Numba. Those libraries could switch to using type annotations instead. Similarly, IDEs are already use type annotations to enhance their symbol resolution and so on. Lastly, I'm not sure what you mean by "falls very much short of actual static type checking". With mypy and PyType, you can already catch many bugs that you wouldn't have otherwise, without running the code. That's the definition of static type checking. It may not do as much as c++, but it still catches significantly more than most other pure dynamic languages with no type.

humanrebar 7y ago
There are other implications, but binary linking is fraught. Minor errors corrupt entire executables, systems, and data stores, including entirely unrelated subsystems. Often statically typed systems use (at the binary level!) type information to trade off defensiveness (checking that array indexing is in bounds, maybe) for other things (latency, throughput, etc.). Point being, the type information is used for more things than just telling coders about API mismatches. Maybe some libraries could use type information to dynamically use better code paths, but statically typed languages use this information far before that... when the equivalent of a wheel is created, for instance.