> It seems like this disagreement should be easy to resolve. You are saying that it's hard to satisfy the type checker when porting a dynamically-typed program; OP says this happens very rarely. Therefore you can easily disprove OP's claim by providing some examples that happen commonly in practice. Provide them, please!
Great, let's stay in a weakly typed language -- and give the smallest of examples. This is so easy to come by it should be obvious that extrapolating this up to real business systems greatly magnifies cost. Here's weakly typed Java:
That's a function that counts characters in a string. It compiles. Now let's drop the types:
Function countChars = str -> str.length();
That is a correct definition of the same function but it doesn't compile. The compiler needs information to carry out its proof.
This extrapolates to infinite more examples and the cost in building actual business systems is profound.
Now carry this to a strongly typed system.
The general claim is that type inference will allow the second form to somehow magically pass the compiler.
Not true.
The type inference requires `length` to be formally declared before the compiler can pass the program. I.e., the compiler must be told about the types somewhere.
In a dynamically typed language I can late bind `length`; ie the compiler doesn't need to be "told" something that I, the programmer, have got fully covered by my own measures.
But the compiler doesn't know this. I've already done my proof of correctness (as I should). But because the compiler does not have context, I have to tell it something that has no innate value to me and what I'm delivering -- it only has value to the closed-room of the compiler. This is hostile to productivity and serves only my early commitment to having a type prover guard my every move.
Great, let's stay in a weakly typed language -- and give the smallest of examples. This is so easy to come by it should be obvious that extrapolating this up to real business systems greatly magnifies cost. Here's weakly typed Java:
That's a function that counts characters in a string. It compiles. Now let's drop the types: That is a correct definition of the same function but it doesn't compile. The compiler needs information to carry out its proof.This extrapolates to infinite more examples and the cost in building actual business systems is profound.
Now carry this to a strongly typed system.
The general claim is that type inference will allow the second form to somehow magically pass the compiler.
Not true.
The type inference requires `length` to be formally declared before the compiler can pass the program. I.e., the compiler must be told about the types somewhere.
In a dynamically typed language I can late bind `length`; ie the compiler doesn't need to be "told" something that I, the programmer, have got fully covered by my own measures.
But the compiler doesn't know this. I've already done my proof of correctness (as I should). But because the compiler does not have context, I have to tell it something that has no innate value to me and what I'm delivering -- it only has value to the closed-room of the compiler. This is hostile to productivity and serves only my early commitment to having a type prover guard my every move.