Are the critiques in "All the things I hate about Python" valid?

[bartc]

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