A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.
The reason was this:
quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular whenever something is composable and is, in fact, composed (if one can say that). I suppose one can say that, for Scala, it took a bit of time before people figured out how to do this properly, rather than just hacking the type system, but I feel that the ecosystem is more or less there now... YMMV though...
As an example: in something like Slick (a functional-relational mapper) in Scala you end up with monads to model your SQL query. One advantage this has is compile errors whenever you're doing something wrong (i.e. more typesafe), but the types that a SQL query representation ends up with will necessarily be pretty hard to read and practically impossible to write (you could have a Query of a long chain of other types for example if you're querying multiple columns).
In this example, somebody writing the query might not care about the type of the query. They will care about what the query will end up returning when executed though. I suppose it will lead to trouble when you can't read the type signatures well enough and try to figure out the compiler error, but I reckon it's better to have an error, than to see it fail runtime (at least in my world :). It's easier and safer to do maintenance too, since the compiler and IDEs can know how things should work.
In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.
One challenge that Java will have even when implementing this though, is how to move the entire ecosystem to something that is indeed more typesafe. This only works if the APIs are doing this right.
> A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.
Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference.
Type inference only enables to omit type annotations in certain parts of your code. Your values are just as typed as if you had used that type annotation.
As for the original point you were trying to make, I would say Scala is no more type safe than Java. They are about on par in how they allow unsafe expressions to type check. Scala's type system is certainly richer than Java's, but that's a separate point (and maybe the one you were trying to make).
> In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.
Absolutely not.
Omitting a type in your source doesn't remove the type from that variable. The code is exactly as typed with that type annotation as it is without.
I think his argument is that without type inference, programmers will avoid more complex types, and therefor model their domain with less precise types.
The curious case of the broken inverse: you won't get more type safety by having type inference, but you are likely to end up with less type safety when you are not having it ;)
I have seen no evidence of that. With that logic, Java programmers would use "Object" instead of "List<String>" because they have fewer characters to type?
It makes more sense after you have deliberately weakened the typing of an API because you felt that you were overstretching your co-developers (and/or your own) patience for nested angle brackets.
The basic idea is that type inference would shift the sweet spot for the right amount of typing upwards.
Hmmm. Yes, you're right. Typesafe is probably the wrong word to describe this according to you and wikipedia :)
The problem I tried to describe though is how feasible/typical/normal? it is to catch more or less (type) errors on compile time...
Like here, where I basically my point is that it is too hard to use Java's type system to it's full extent because it becomes too cumbersome to actually use it on the callsite.
Puh! Wikipedia also states:
'Type safety is sometimes alternatively considered to be a property of a computer program rather than the language in which that program is written; that is, some languages have type-safe facilities that can be circumvented by programmers who adopt practices that exhibit poor type safety.'.
In (some) Java _programs_ you would circumvent modelling your domain correctly because it would be too cumbersome to use, therefore Java _programs_ tends to be less typesafe...
I suppose that is how I use the term and heard it used in my everyday life, e.g. 'this code is more typesafe than that' and so on and so on...
I guess I should have made it more clear that this how I used the word 'typesafe' (though your definition of it is more correct) and underlined that I meant Scala/Java _programs_ not the language (nor the type system) itself.
Still, it is correct that type inference (rather obviously) doesn't have anything to do with type systems.
A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.
The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular whenever something is composable and is, in fact, composed (if one can say that). I suppose one can say that, for Scala, it took a bit of time before people figured out how to do this properly, rather than just hacking the type system, but I feel that the ecosystem is more or less there now... YMMV though...
As an example: in something like Slick (a functional-relational mapper) in Scala you end up with monads to model your SQL query. One advantage this has is compile errors whenever you're doing something wrong (i.e. more typesafe), but the types that a SQL query representation ends up with will necessarily be pretty hard to read and practically impossible to write (you could have a Query of a long chain of other types for example if you're querying multiple columns). In this example, somebody writing the query might not care about the type of the query. They will care about what the query will end up returning when executed though. I suppose it will lead to trouble when you can't read the type signatures well enough and try to figure out the compiler error, but I reckon it's better to have an error, than to see it fail runtime (at least in my world :). It's easier and safer to do maintenance too, since the compiler and IDEs can know how things should work.
In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.
One challenge that Java will have even when implementing this though, is how to move the entire ecosystem to something that is indeed more typesafe. This only works if the APIs are doing this right.
EDIT: typos, language and less parens