The Java type system is broken • Hacker News Board

Re: The Java type system is broken

#71

Post by mohaine » Thu, Jul 19, 2018, 3:42 PM UTC

enitihas wrote: post #55

monocasa wrote: post #50

Earlier quoted context omitted.

Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.

Did C# really break backwards compatibility of their bytecode? What I understand is that C# generic and non generic APIs are completely different, and are not inter operable.

Not sure on the first part but the second part is true.

When there is a C# class that both has and doesn't have type information, they are actually completely different classes that just happen to share a base name.

This really made it painful when they first added generics. If you used generic containers but wanted to call into a library that predated it you hand to transform your data in/out of all the calls to the library. In Java land you didn't have to do anything other then a blind cast on the out side which doesn't even have a runtime penalty.

Long term the C# way was probably better but then they didn't have nearly as robust of a library ecosystem when they added generics.

Re: The Java type system is broken

#72

Post by piinbinary » Thu, Jul 19, 2018, 3:44 PM UTC

mcculley wrote: post #44

The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.

Since there is no subclassing [0] in Go, many of those cases are not expressible in Go.

[0] Interfaces can contain other interfaces, but I think that is still different because you can't do

    var a []subinterface = []superinterface{...}

Re: The Java type system is broken

#73

Post by OnlyRepliesToBS » Thu, Jul 19, 2018, 3:44 PM UTC

MrBuddyCasino wrote: post #37

> Everything is broken. Everything is fine. This is the correct conclusion. The people getting outraged over this are the same that will hold long and boring monologues about how everybody does REST wrong.

Directive: Deride and downplay.

But under no circumstances explain yourself or justify.

Re: The Java type system is broken

#74

Post by J-Kuhn » Thu, Jul 19, 2018, 3:46 PM UTC

stingraycharles wrote: post #9

TazeTSchnitzel wrote: post #5

My favourite feature of Java's type system is that, because any object type also accepts null, the type system is unsound and you can convert anything to anything else: https://raw.githubusercontent.com/namin/unsound/master/doc/u...

Wouldn't that be a problem in most languages? Even Haskell allows for it through Data.Dynamic If I can serialize to String, and then deserialize a String to any type of class, I can effectively "cast" anything to anything.

Read about Bottom (⊥).

null can be considered bottom (if it were not for primitives)

Re: The Java type system is broken

#75

Post by pjmlp » Thu, Jul 19, 2018, 3:52 PM UTC

monocasa wrote: post #50

mcculley wrote: post #44

The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.

Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.

The missing part every time this story gets told, is that Microsoft already had a generics implementation ongoing being lead by Don Syme of F# fame.

They just decided to release 1.0 without generics, instead of waiting for it to be 100% ready.

As Don clearly describes on his blog.

Re: The Java type system is broken

#76

Post by monocasa » Thu, Jul 19, 2018, 3:54 PM UTC

enitihas wrote: post #55

monocasa wrote: post #50

Earlier quoted context omitted.

Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.

Did C# really break backwards compatibility of their bytecode? What I understand is that C# generic and non generic APIs are completely different, and are not inter operable.

Yeah, IIRC they added the "constrainted." instruction prefix. It's a prefix to the callvirt instruction that constrains the the underlying call to the specified type, allowing runtime generic type decisions/exceptions rather than only compile time decisions like Java.

Re: The Java type system is broken

#77

Post by tabtab » Thu, Jul 19, 2018, 3:57 PM UTC

mcculley wrote: post #44

The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.

Just use dynamic or better yet type-tag-free languages. Types are hard to get right and hard to reason about. Sure, there are some Sheldons out there who master it even under pasta applications, but most of us are not Sheldons. C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt.

For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values to see if they are interpretable as the intended type:

   function foo(int a, date b) {...}

This would be equivalent to:

   function foo(a, b) {
     if (! parsableAsInt(a)) throwTypeError(...);
     if (! parsableAsDate(b)) throwTypeError(...);
   }

And don't overload operators, such as how some languages use "+" to mean both arithmetic addition and string concatenation. Use a different symbol for concatenation like PHP does.

Re: The Java type system is broken

#78

Post by monocasa » Thu, Jul 19, 2018, 3:58 PM UTC

pjmlp wrote: post #75

monocasa wrote: post #50

Earlier quoted context omitted.

Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.

The missing part every time this story gets told, is that Microsoft already had a generics implementation ongoing being lead by Don Syme of F# fame. They just decided to release 1.0 without generics, instead of waiting for it to be 100% ready. As Don clearly describes on his blog.

Sure, totally.

In fact, I'm a big fan of how Microsoft does versioning, supporting previous versions, but releasing major versions with backwards incompatible changes. You see this in DirectX, and IMO, that's why we're talking about DirectX and Vulkan, rather than AZDO OpenGL these days. It really gives you an opportunity to clean up the cruft.

Re: The Java type system is broken

#79

Post by pjmlp » Thu, Jul 19, 2018, 3:59 PM UTC

nine_k wrote: post #63

bad_user wrote: post #28

It’s pretty tragic how people respond to such criticism emotionally, instead of acknowledging the issues and working towards fixing them or educating others in the traps and compromises involved. HN is less prone to toxicity, but this is reminiscent of Reddit and it drives away the people that want to help. As a piece of advice, some type theory never harmed anyone ;-)

Application of type theory, or any theory, or any formal method, requires humility and patience. To apply a formal method to your work requires to acknowledge that your intuition might me wrong, your past decisions incorrect, and your knowledge of the subject area deficient. Often you have to step back, rethink, and rework. This is a normal mindset for a scientist, and a pretty common mindset for an experienced engin…

It is also tribalism.

When one is a polyglot developer, we are like mercenaries, a bag full of tools, each with its caveats, and we care about the solution less how we got there juggling those tools.

Developer X tend to keep searching for external confirmation that they did the right choice. Any attack on tool X triggers defensive attacks, as if they would be a personal attack.

Of course I am exaggerating here, just extrapolating from those that I know on my circle.

Re: The Java type system is broken

#80

Post by projektir » Thu, Jul 19, 2018, 4:04 PM UTC

buremba wrote: post #10

Welcome to the world of enterprise-ready complex applications. I agree that these cases should be covered by the compiler but man, there are mainstream languages that don't implement generics just because they're complex and pretend that they're not helpful. It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering an…

> It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.

Hmm. If I knew your coolant was leaking, but had no idea how to fix it, would you prefer I didn't tell you? Just want to keep driving that car around with that coolant leaking?

At the very least, this is educational and helps better understand Java for those of us who work with it.