4 ms·

> Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they

by pron 4y ago

> Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. > The JVM is a marvel of engineering. Java... not so much. This was James Gosling's stated strategy and one of the secrets of Java's exceptionally-long-lasting success. While many developers like feature-rich, sophisticated languages, the vast majority of them really, really don't (although they are underrepresented on HN, certainly when it comes to language feature discussions). Many of the things people need can be hidden in the runtime, wrapped by a conservative, non-threatening language. Gosling called that "a wolf in sheep's clothing." See the first half of this talk by Brian Goetz on this very subject: https://youtu.be/Dq2WQuWVrgQ https://youtu.be/Dq2WQuWVrgQ

ackfoobar 4y ago
> it's getting there, so stay tuned It's nice to see from a theoretical perspective. But my impression is that the ecosystem is moving towards having no checked exception. What will happen to the existing code when generics works with union typed checked exceptions?
Quekid5 4y ago
> The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. Happy to hear something might be getting done about it, but users have suffered for 20+ years. I'm probably not going back to Java anyway :). Any technical details you can share about a potential redesign? AFAICT checked-exception-like-things will always be at odds with the variance requirements on method signatures, so I'm a bit curious. (Outside of the natural solutions where variance isn't a problem, e.g. polymorphic variants or row types.) Regardless, I'm waaay more interested in the JVM-level improvements that you & co. have been doing! Kudos! Btw, any inside tips on TCO? ;) > [Gosling] I have seen that talk, and I largely agree with the philosophy (assuming the goal is correct), but in this particular case, I think it was a mistake to let the problems fester for 20+ years rather than just admitting defeat and removing the checked-ness. If it's going to take that long to implement a solution to a constant pain point... the solution might as well not exist. (Perfect = enemy of good and all that.) EDIT: Just to add: I definitely don't mean to cast aspersions on anybody in the Java language design team or anything like that -- if that's how my original comment came across. Everybody makes mistakes and predicting the future is hard at the best of times :). I just wish they'd reevaluated some things along the way...

by pron 4y ago

ackfoobar 4y ago

> it's getting there, so stay tuned It's nice to see from a theoretical perspective. But my impression is that the ecosystem is moving towards having no checked exception. What will happen to the existing code when generics works with union typed checked exceptions?

Quekid5 4y ago

> The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. Happy to hear something might be getting done about it, but users have suffered for 20+ years. I'm probably not going back to Java anyway :). Any technical details you can share about a potential redesign? AFAICT checked-exception-like-things will always be at odds with the variance requirements on method signatures, so I'm a bit curious. (Outside of the natural solutions where variance isn't a problem, e.g. polymorphic variants or row types.) Regardless, I'm waaay more interested in the JVM-level improvements that you & co. have been doing! Kudos! Btw, any inside tips on TCO? ;) > [Gosling] I have seen that talk, and I largely agree with the philosophy (assuming the goal is correct), but in this particular case, I think it was a mistake to let the problems fester for 20+ years rather than just admitting defeat and removing the checked-ness. If it's going to take that long to implement a solution to a constant pain point... the solution might as well not exist. (Perfect = enemy of good and all that.) EDIT: Just to add: I definitely don't mean to cast aspersions on anybody in the Java language design team or anything like that -- if that's how my original comment came across. Everybody makes mistakes and predicting the future is hard at the best of times :). I just wish they'd reevaluated some things along the way...