On 17/02/2018 14:30, Steven D'Aprano wrote:
And ironically, in a *modern* statically typed language, you may not even need the type declarations. After all, in a modern type-checker, the compiler can infer that since foo returns 'hello world', it must return a string; it can probably even infer the type of the input.
At the call-site, it would need to see the function definition, or some declaration (with static types) that the compiler has generated from the definition. That implies a module system that I think has priority over type inference.
For many uses, type declarations will still be needed: for function calls across languages, or to create a particular layout of structure or specialist data structure.
What can /very/ easily be done, even in Python, is to have two kinds of function: one an actual function that returns a value, and the other a procedure that returns no value.
Then it is easy to pick up errors where no return value is used, or a return value is supplied when it isn't needed.
(In Python, procedures will always have to return None behind the scenes, as code might still call procedures as functions.)
So in such a
language, the source code may not even display the input or output types, because the compiler can infer what they logically must be. The only difference between such a modern statically typed language with no (or very few) type declarations, and Python, is that Python checks the types at run-time and the statically typed language checks them at compile-time. That gives a pros and cons: Pros for static typing: - catch some errors sooner; - allow the compiler to make some optimizations resulting in faster code; - a sufficiently sound type system may be able to prove that a certain class of bugs (type bugs) cannot occur;
I've done a lot of conversion from dynamic to static code. I found the extra discipline needed very useful.
I could no longer pass multiple types to one function, or return a range of types, but the end result was much tidier code, where parameters and return types were better defined and the functions simpler. Needing to think about such things was better for avoiding sloppy, inefficient code.
And the result was usually faster (even above the benefit expected of moving from compiled to interpreted).
(assuming you trust that the compiler is bug-free). Cons for static typing: - programmer may have to include lots of tedious code to placate the compiler; - programmer may have to fight the compiler to force it to allow perfectly safe operations which the type-checker disallows; - type inference is not always fool-proof; - typically badly suited to interactive or exploratory programming, and less flexible; - may give the programmer a false sense of security that just because the program compiles, it must be bug-free.
If the static language doesn't have flexible arrays, that can be a bit of a bummer.
-- bartc -- https://mail.python.org/mailman/listinfo/python-list
