From the examples: "String s = gridWrapper.get(0).get(0).get(0);" - Java type system is broken!
Java is not perfect, but this looks to me like a broken code indeed ".get(0).get(0).get(0)".
Could we rephrase the message of the article as "If you write
really broken code in Java, you might be not guarded by the type system". And this is, well, uhm, well... acceptable?
Right. I think this is the promise of Java generics: we promise we'll warn you if you're relying on dynamic type checking because we can't prove all dynamic type checks will pass.
This article gives a series of examples that break that promise.
In some situations. The examples in this article, I think, make it clear that for a lot of "broken code" these errors are caught. It's too bad that there are edge cases, but that is Java all over, in my opinion.
I think that's always the conflict in these discussions. We can usually agree on how things work but your "broken and unsounds" is simply a "limitation" to others.
Saying things like "do better easily" makes sense in the context of fixing something that's broken.
But for anyone who just sees it just as a limitation this comes off as presumptuous. What do you want to change? How do you want to overcome the limitation? At what cost?
Several new languages (eg Typescript, Dart) have optional type systems that still bring significant value to the table.
Sure - all other things being equal, I'd much rather have a type system that is completely sound. Ceylon's type system is beautiful and I'm happy to see its union + intersection types being adopted by Typescript. But honestly, I'm not going to lose much sleep over these particular issues in Java. Bad code gets refactored.
A bigger complaint should be made that generic type erasure makes libraries hard (eg, the number of places you have to pass around Class<?> or TypeReference objects to let the runtime know what to do). But that was a clearly a compromise decision and everyone knows about it.
> Several new languages (eg Typescript, Dart) have optional type systems that still bring significant value to the table.
I think it's too early to say that this approach has proven to be successful - indeed another reply says that Dart has switched to a stronger type system with required types, which I'd take as significant evidence that optional typing is not a good tradeoff. Certainly my experience of the checkers framework in Java was that optional types are the worst of both worlds.
> But honestly, I'm not going to lose much sleep over these particular issues in Java. Bad code gets refactored.
I'm worried (or rather, I would be worried if I hadn't seen the bug reports, which seem to be being taken seriously and fixed in the compiler). If they can happen in bad code, who's to say they can't happen in good code.
> A bigger complaint should be made that generic type erasure makes libraries hard (eg, the number of places you have to pass around Class<?> or TypeReference objects to let the runtime know what to do). But that was a clearly a compromise decision and everyone knows about it.
I'd argue that the only cases where you need that are when you're doing something you shouldn't (reflection). But I guess in a language without typeclasses there are problems that have no good solution.
If you don't like this example, you can always find cases where the limitations of the type system (or more specifically Generics) become apparent. This isn't quite so obvious during 'normal' application development, but if you start creating libraries or frameworks and you want generic type support, you will run into a wall very quickly.
Well, think of it this way. A seat belt cannot help you at all if an object flies through your windshield. Nevertheless, driving while wearing a seat belt is, overall, safer than driving without one.
This is HN, we don't need seat belt analogies. Very strict type systems forbid this class of errors during compilation, others do a best effort and fail at runtime.
Whoever you are, analogies can help clarify your thinking. A type system that prevents some errors is not without value just because it cannot catch others. If the uncaught types of errors are rare and the type system that would solve them somehow burdensome it may even be a reasonable compromise to accept these faults.
Of course. At this point I'm not sure what this has to do with the code snippet mentioned upthread or the response to it. Your analogy didn't really convey why you'd think java allowing "String s = gridWrapper.get(0).get(0).get(0);" is a good vs bad thing, it just tells me that types don't protect you from everything, I think. I didn't find that the analogy added anything valuable and instead kind of simplified a problem that didn't need simplifying. The topic isn't whether type systems are valuable, but whether the positive value of java's outweighs the harmful logic it allows the developer to write.
A language like rust can prevent writing code like that, and thus prevent that sort of error, while a language like javascript is even more lax. Both have their tradeoffs wrt productivity and performance.
Sure, and there's a point to all kinds of semi-strong typing. I'm glad Python does time checking at runtime, even it can't protect me from everything. When the type system becomes part of the grammar, it should be stronger than that though.
I don’t think that is true anymore. There are languages like typescript that don’t provide anything near that guarantee but are still seen as very useful.
The author is trying to write a concise example. You could achieve the same effect by writing three for loops, but that would take additional code and declarations that make his point less clear.
The type system should give guarantees. I believe these cases violate the specification, and I think the specification is right to require the typechecker to check all code rather than just most code: a type system that works 100% of the time is much more useful than a type system that works 99.99% of the time, because it means you can blindly rely on it rather than having to double-check it every time you do anything critical and then maintain all those double-checks.
If we take the view that these are bugs in the Java compiler, then of course a bug that's rarely triggered is less bad than a bug that's triggered all the time. But both are bugs all the same.
If he were to show real world example, few would bother to follow it through because it would be tens of lines of code spanning through multiple classes and namespaces.
Don't throw out a number like that. We're talking about a Turing complete language, which means we're talking about protections that have to range over all possible programs and abstractions. It may be that your problem domain is extremely biased toward some small region of that space, in which case a type system that doesn't work there is actually useless.
Either way, it is hard to reason about factors like that numerically when we've not qualified which kinds of programs we're expecting the type system to actually work for.
Not really, a language in which some type errors are impossible (rather than merely very unlikely) makes it drastically easier to prove something useful about programs (e.g. to optimize away runtime checks that would otherwise be needed as a safety net and impossible cases).
Typescript with its explicitly unsound type system show that a "broken" type system is immensely valuable, especially when you get something in return for that [1]
Java is not perfect, but this looks to me like a broken code indeed ".get(0).get(0).get(0)".
Could we rephrase the message of the article as "If you write really broken code in Java, you might be not guarded by the type system". And this is, well, uhm, well... acceptable?