5 ms·

I agree that the third point is important, but it's not clear that it's static typing that is important, and not type annotations. One reason why I can still fa

I agree that the third point is important, but it's not clear that it's static typing that is important, and not type annotations. One reason why I can still fairly easily read and understand Eiffel code that I wrote decades ago is Design by Contract. And there's normally nothing static about DbC, it's about assertions that are checked at runtime and that by convention are part of a class's interface. What both type annotations and DbC are is self-enforcing documentation (of an interface) that doesn't go out of sync with the actual code. But for that, you don't necessarily need static type checks. Now, type checking of type annotations that happens exclusively at runtime is an option that hasn't been explored much (after all, if you already have type annotations, why not let the compiler make use of them?), but an option that has sometimes been used successfully is having a mixture of static and dynamic type checks. You can often greatly simplify a type system by delaying (some) type checking until runtime (examples: for covariance or to have simpler generics).

neilparikh 9y ago
I think one disadvantage of runtime type checking and DbC is that the compiler can't aid you in refactoring. For example, if you add a case to a variant or sum type, or change the parameter or return type of some function, in a static type system, the compiler can tell you all the locations you need to change. In a runtime system, you have to find them yourself, or wait till you see an error at runtime. Now, this is still better than the alternative of having the error propagate until it crashes 10 functions down, but the compiler finding all the places that need to be changed is something I've found to be really useful, especially in early development when there's a lot of refactoring happening. Presumably, this is probably useful in later stages as well, when the system is large enough that you can't expect to find all the uses of a function or type manually.
- spronkey 9y ago
  IDEs can still substantially aid in refactoring with runtime type checking and return type annotations - see WebStorm and PHPStorm for two good examples of this. It isn't perfect - but certainly for things like changing the return type of functions, it will usually get you at least 90% of the way there. Now, whether you consider that's actually helping solve the refactoring, or actually introducing new bugs, well - that's another issue :)

neilparikh 9y ago

I think one disadvantage of runtime type checking and DbC is that the compiler can't aid you in refactoring. For example, if you add a case to a variant or sum type, or change the parameter or return type of some function, in a static type system, the compiler can tell you all the locations you need to change. In a runtime system, you have to find them yourself, or wait till you see an error at runtime. Now, this is still better than the alternative of having the error propagate until it crashes 10 functions down, but the compiler finding all the places that need to be changed is something I've found to be really useful, especially in early development when there's a lot of refactoring happening. Presumably, this is probably useful in later stages as well, when the system is large enough that you can't expect to find all the uses of a function or type manually.

spronkey 9y ago
IDEs can still substantially aid in refactoring with runtime type checking and return type annotations - see WebStorm and PHPStorm for two good examples of this. It isn't perfect - but certainly for things like changing the return type of functions, it will usually get you at least 90% of the way there. Now, whether you consider that's actually helping solve the refactoring, or actually introducing new bugs, well - that's another issue :)