4 ms·

> Yes, some aspects require fixing (e.g. the interaction of lambdas with checked exceptions; there's much we can do there, but we need to design this carefully)

> Yes, some aspects require fixing (e.g. the interaction of lambdas with checked exceptions; there's much we can do there, but we need to design this carefully) I do like the Java platform in general, but this sort of argument from hypothetical future Java fixes strikes my as incredibly disingenuous. People aren't programming in a hypothetical future Java. I can literally pose no argument against your imagined solution to this problem without very specific details. (Implication being, it's a straw man at best.) And saying saying stuff like (in an adjacent thread): > You're assuming that deconstructing and exhaustive patterns will continue to be restricted to ADTs only. That may or may not be the case. Is just complete fiction. (EDIT: Are you going to solve the halting problem, or are you going to provide details before just promising "it'll be ok"? I assume the Halting Problem is out of the question, but what's the plan, then? Details, pls) Either point to extant JEPs or explain in detail what the exact plan is, please.

pron 3y ago
First of all, you completely misunderstand my point. I neither ask people to judge Java based on some hypothetical future, nor ask for feedback on future designs. I acknowledged there's a real problem and mentioned we're exploring solutions, but even with the problem Java is the world's most popular typed programming language in 2023. Not every problem is big, and PL fans tend to grossly overestimate the cost of some cumbersomeness in a language and grossly underestimate the cost of language complexity because their preferences are often in the minority. Having said that, we have a few experiments with type-safe "checked exception transparency" for lambdas (and methods in general), but as always we like to sit on them for a few years because the cost of a bad feature may be much higher than the cost of a missing one. We only publicly discuss specific solutions once there's something to be gained by such a discussion and once we've decided that the problem merits a solution in the short term. > Is just complete fiction. I was responding to a statement about deprecating Optional in favour of an ADT, and hinted at this design, which is under exploration (https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-object-model https://openjdk.org/projects/amber/design-notes/patterns/pat...): case Optional.empty() -> ... case Optional.of(var x) -> ... It's not complete fiction, this is actual stuff we're working on, but not everything we explore will end up in the language.

pron 3y ago

First of all, you completely misunderstand my point. I neither ask people to judge Java based on some hypothetical future, nor ask for feedback on future designs. I acknowledged there's a real problem and mentioned we're exploring solutions, but even with the problem Java is the world's most popular typed programming language in 2023. Not every problem is big, and PL fans tend to grossly overestimate the cost of some cumbersomeness in a language and grossly underestimate the cost of language complexity because their preferences are often in the minority. Having said that, we have a few experiments with type-safe "checked exception transparency" for lambdas (and methods in general), but as always we like to sit on them for a few years because the cost of a bad feature may be much higher than the cost of a missing one. We only publicly discuss specific solutions once there's something to be gained by such a discussion and once we've decided that the problem merits a solution in the short term. > Is just complete fiction. I was responding to a statement about deprecating Optional in favour of an ADT, and hinted at this design, which is under exploration (https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-object-model https://openjdk.org/projects/amber/design-notes/patterns/pat...): case Optional.empty() -> ... case Optional.of(var x) -> ... It's not complete fiction, this is actual stuff we're working on, but not everything we explore will end up in the language.