> My experience with Swift is we tried to make a really fancy bi-directional Hindley-Milner type checker and it’s really great because you can have very beautiful minimal syntax but the problem is that A) compile times are really bad (particularly if you have complicated expressions) and B) the error messages are awful because now you have a global constraint system and when something goes wrong you have to infer what happened and the user can’t know that something over there made it so something over here can’t type check. In my experience it sounds great but it doesn’t work super well.
I feel like B) is very well known in the programming language community. I certainly heard people talking about in at least ~20 years ago. A) should be obvious in the presence of overloading. I guess the type inference algorithm becomes part of the assumed semantics of the language and it's difficult to change after the fact.
Yeah, my impression is that B happened earlier in Haskell.
1. Let's create a super advanced type inference system so that you can write Haskell like a dynamic language but have it be static.
2. Oops, now when you make a mistake, it propagates through your program and causes a type error somewhere completely different.
3. New code style rule: you may omit type signatures on local functions, but always place them on top-level functions so that they serve as a barrier to incorrect type inferences.
What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors.
Trying to write untyped dynamic code in a statically typed language thus just results in frustration, those languages were made to work statically and to throw a lot of type errors, they are horrible as dynamic languages.
> What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors.
This isn't true at all. I write a lot of python and I don't think I've ever had a duck-typing happy coincidence that wasn't an error. No it's exactly that I'm only depending on the aspect of the type that I need at the call/use site (so I can update types while maintaining those contracts and I don't need to update any signatures anywhere).
I feel like B) is very well known in the programming language community. I certainly heard people talking about in at least ~20 years ago. A) should be obvious in the presence of overloading. I guess the type inference algorithm becomes part of the assumed semantics of the language and it's difficult to change after the fact.