6 ms·

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 in

• rimunroe 8y ago
  Is a type system really worth that much if it can't help you in a situation where your code is ugly and hard to follow?
  • freddie_mercury 8y ago
    "Is X really worth it if it isn't perfect and doesn't cover every edge case?" I kinda feel like humanity has repeatedly decided the answer to this question is "yes". "Being valuable" isn't binary. There are relative amounts of value, I think.
    • carlmr 8y ago
      Being valuable isn't binary, but you shouldn't stop in the middle if it's possible to do better easily.
      • kjeetgill 8y ago
        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?
  • sorokod 8y ago
    Type system helps those who help themselves.
  • stickfigure 8y ago
    Unequivocally, yes. 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.
    • igouy 8y ago
      > … Dart… have optional type systems… fyi "Dart’s type system is now sound" and "…types are mandatory". https://www.dartlang.org/guides/language/sound-dart https://www.dartlang.org/guides/language/sound-dart
      • stickfigure 8y ago
        Wow great news! That makes Flutter even more exciting.
    • lmm 8y ago
      > 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.
• agumonkey 8y ago
  It's stupid code, but a type system has to be code agnostic. Otherwise you're back to dynamic languages with local type annotations.
• Anderkent 8y ago
  > And this is, well, uhm, well... acceptable? It is not. The only purpose of a type system is to prevent broken code from compiling. When it fails to do so, it is broken.
  • dtech 8y ago
    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] [1]: https://www.typescriptlang.org/docs/handbook/type-compatibility.html https://www.typescriptlang.org/docs/handbook/type-compatibil...
    • Anderkent 8y ago
      Well, sure, it's better than having an even worse type system! No one's saying java's type system is worse than not having anything.
• bdhess 8y ago
  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.
• opnitro 8y ago
  Is it? The whole point of a type system is that it gives you guarantees over your code. Certain bugs should be inexpressible within the language.
  • emodendroket 8y ago
    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.
    • opnitro 8y ago
      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.
    • picsao 8y ago
      Redefining the outlier. The outlier is a person catapulted out of its car during a accident. This is rarely a good thing, but sometimes a very lucky event. As only the lucky ones get to tell the tale in a bar, the world is full od outliers.
    • ilikehurdles 8y ago
      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.
      • emodendroket 8y ago
        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.
• macspoofing 8y ago
  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.
• byte1918 8y ago
  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.
• Doxterpepper 8y ago
  What's the point of strong typing if it only saves you most of the time?
  • dtech 8y ago
    So a type-system that does the right thing in 99.999999% of the cases is completely useless according to you?
    • Retra 8y ago
      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.
    • tom_ 8y ago
      I think the question is rhetorical.
      • HelloNurse 8y ago
        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).
• coldtea 8y ago
  >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" The very idea of the type system is that it makes "broken code" of a certain type a compile error.
  • cmiles74 8y ago
    For certain and specific definitions of "broken code".
    • coldtea 8y ago
      Yeah, for the type of broken code that has the wrong types.
      • cmiles74 8y ago
        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.
      • PDoyle 8y ago
        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.
• Someone 8y ago
  In Java f.get(0).get(0).get(0) typically is the way to write want in languages that allow operator overloading is written as: f[0][0][0] You will rarely see that with three constants, but f[x][y][z] isn’t uncommon.
• lmm 8y ago
  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.