3 ms·
> I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as you use it in a distributed environment: the gua
by yakshaving_jgt 7y ago
> I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as you use it in a distributed environment: the guarantees are static. They pertain only to your little binary and don’t say anything about the rest of the system.
To argue that a static type system is not valuable because it doesn't enforce constraints on other external systems it doesn't know about is a pretty wild case of moving the goalposts.
- jmull 7y ago> To argue that a static type system is not valuable I didn’t.
- msla 7y agoSome kinds of static type systems (by which I mean all of the widespread ones which aren't Haskell or similar to Haskell) make extremely specific guarantees static, such that you can't change mere implementation details without rewriting a lot of code. For example, if you're using a library which specifies floats as an input type, and you now need doubles, you're pretty well screwed: You either rewrite and recompile a huge chunk of code or you decide you don't need to expand your precision after all. Does the library code really need to use 16-bit floating-point values, or does it only use them because someone twenty years ago believed in some superstitions about performance? That information isn't available. It isn't in the type system, so it can only be in the documentation... oh, wait, documentation focuses on How and not Why, doesn't it? Your static type system was made by people who failed to disambiguate between storage size specifications and semantics, so you're left with "16-bit IEEE floating point" as the only semantic information you're ever going to have.
- yakshaving_jgt 7y agoNot using the polymorphism available is not a problem inherent to statically-typed programming languages.