6 ms·

To put it plainly, Java is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to

To put it plainly, Java is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix. edit to respond: calling them "bells and whistles" is a deep misunderstanding of what sum types are. They profoundly change how every single piece of code in the language is written, starting from how nulls are handled, and cannot be retrofitted into an existing ecosystem. (You can add them later, but baking in sum types from the start is very different. In particular Java would not have its terrible exception system if it had sum types.)

mc10 6y ago
I’m curious what your alternative is, given that Go famously also lacks sum types.
- damnyou 6y ago
  Yes, Go is a fundamentally broken language too. As is C++, as is C. Sum types are the absolute bare minimum a language must have for me to not consider it broken beyond hope. Go in particular is really unfortunate for a language so new. The language's weaknesses have dropped my estimation of its creators by several notches.
  - Guthur 6y ago
    "I'm broken and can not use a language without Sum Types" There, I fixed it for you.
    - damnyou 6y ago
      Yes, that's possible. I would rather tear my eyes out than use a language without sum types. The benefits of sum types in being able to model arbitrarily complex domains are extraordinarily massive. Every language has product types. Every programmer understands how useful product types are. Why in the world would the same not apply to sum types?
      - AnimalMuppet 6y ago
        You sound like you have a hammer, and so every problem looks like a nail. Sum types can be useful. Other aspects of languages can be useful, too. Why fixate on that one? And if you're going to say that it's a minimum bar, well, some of the other features are missing in most languages that have sum types. Pick the language that has the total set of features that makes it easiest to write whatever program you're trying to write. Don't get locked in to focusing on only one feature.
        damnyou 6y ago
        Yes that's why I write Rust. Our field has a terrible reputation for quality. In my estimation roughly 70-80% of that is directly or indirectly because of the lack of sum types. Directly: people don't have the right tools to make invalid states in their business logic unrepresentable. Indirectly: the lack of sum types results in broken null and error handling.
        Guthur 6y ago
        At this stage I'm now convince you're trolling us all. Well done you had us all fooled :)
        damnyou 6y ago
        Not trolling. Entirely serious.
        bombela 6y ago
        Can anybody explain why the parent is being downvoted? We can argue on the percentage. But the point on the direct and indirect damages makes a lot of sense.
        AnimalMuppet 6y ago
        Late reply; I hope you see it. My reply is late because I had to think for a day first. So, my sincere congratulations - a post that makes me think for a day is much rarer than a post I agree with. To me, sum types for error handling are isomorphic to checked exceptions. They both let you do dual-track programming - separating the normal path from the error path. Both have compiler support for enforcement. But checked exceptions are no longer considered to be the answer. What went wrong? The problem turned out to be the programmers. They did at least two things that subverted checked exceptions. First, they silently ate exceptions (that is, had an empty catch block just to make the exception go away. This is the equivalent of having a sum type that is either an integer or Nothing, and a function. Rather than return the sum type, the function returns an integer. In the Nothing case, the function just returns 0. That's about the same as the empty catch block to not have to declare the exception in the function's return type. The second way checked exceptions went wrong was the opposite. When a function could throw Exception1, Exception2, Exception3, and Exception4, it was tempting to just declare it as throwing Exception (the base class). In the same way, a function that gets SumType1 back from one function, SumType2 back from another function, and SumType3 from a third function may return the sum of the sum types. It becomes an Everything type. In both cases, the problem was that programmers were lazy. But here we are 20 years later, and programmers are still lazy. Until the programmers change, sum types won't fix things any more than checked exceptions did.
    - exclusiv 6y ago
      Also - "I refuse to use most languages that have been used to solve a shit ton of problems". Or, "I will not use any language which made software eat the world"
  - timmattison 6y ago
    Does the Either type from the vavr library for Java cover this? https://www.baeldung.com/vavr-either https://www.baeldung.com/vavr-either
    - damnyou 6y ago
      Having a type available in an optional library is not the same thing as having them baked in from the beginning. The absence of sum types warps a language in grotesquely terrible ways, such as Go's err != nil patterns or Java's exception system and visitor patterns.
    - PhantomBKB 6y ago
      I wouldn't say no, because it's built with the right spirit in mind. But at the same time, it's different from languages have native support for sum types. Advantage of sum type is that it can be matched exhaustively like an enum, but at the same time it's flexible to contain any data like a data class.
  - benibela 6y ago
    C has unions What more do you need?
    - damnyou 6y ago
      Are unions used for error handling and null checking? No? Then they're not very useful.
WClayFerguson 6y ago
Improving a dominant (but broken) language is called "innovation" and "improvement". There's no reason all your magic bells and whistles couldn't have been added into Java. Creating new languages just made life worse for everyone.
- tombert 6y ago
  >There's no reason all your magic bells and whistles couldn't have been added into Java. Because it's designed in a way that doesn't always allow these bells and whistles. If I were to tell you that we should have kept using horse-drawn carriages, and that any of the fancy bells and whistles that cars have could be added to horse-drawn carriages, you would probably look at me with confusion. > Improving a dominant (but broken) language is called "innovation" and "improvement" Sure? But modifying an existing (and for most of its history proprietary) language can be a difficult, potentially-political move. If I have an idea on how to do, I don't know, linear-types checked at compile-time, I wouldn't have any idea where to begin adding that to the javac compiler. It might be easier to build my own little language to build it, and then hope that maybe the Oracle devs decide to pick it up.
  - WClayFerguson 6y ago
    The horse-drawn carriages analogy is not applicable because I'm using Java in my current project, like most other large corporations, I don't find it antiquated, I find it "state of the art". There are some improvements that can be made however (any language can be improved on), that would require minimal breaking changes (like fixing Type-Erasure), and I'd even be fine with minimal breaking changes that break backwards compatibility every 5 years or so. The problem is when people say "Let's burn it all down and start over, so zero existing code is salvageable."
    - tombert 6y ago
      Sure, great, but you must understand that adding language features to basically anything that isn’t Lisp moves glacially at best. I mean, let’s go with your example with type erasure; people have been complaining about it for more than a decade, and Oracle still hasn’t fixed it. The Java language designers aren’t stupid, and I’m sure they’ve read the complaints, but it still is almost universally agreed upon to be a broken feature of the language. It’s almost never clear if “language feature X” is a good idea until it’s been implemented and battle-tested. If I have a new idea on how to build something in a compiler and I’m not sure if it’s a good idea, are you saying that the best path forward would be for me to make a PR to javac instead of building a proof of concept language?
oftenwrong 6y ago
Sum types are coming to Java in the form of sealed classes: https://openjdk.java.net/jeps/397 https://openjdk.java.net/jeps/397
- Twisol 6y ago
  To be fair, Java has always supported a particular flavor of sum types founded on subtyping: use an abstract class with a private constructor as a base, add nested static final subclasses for the variants, and decide whether to use instanceof or the Visitor pattern to dispatch on each variant. (The Visitor approach corresponds to a certain isomorphism -- the sum type `A + B` is equivalent to `forall T. (A -> T, B -> T) -> T`, where the pair of handlers `(A -> T, B -> T)` is the titular visitor.) That JEP elaborates on the same ideas (notably using `instanceof` instead), as the linked JEP explains, but the motivation for sealed classes extends to further harmony with subtyping. The major item seems, to me, to be allowing interfaces to be a supertype. A minor but distinctive item is that the sum type's variants can be defined at (some) distance from the base type, rather than all being defined in a single breath. The problem is, even though you could always express sum types in Java, it's verbose, unpleasant, and above all "clever" in a way unnecessary in other languages. I think this JEP helps somewhat -- the private constructor trick in particular goes away -- but it doesn't really help with clients of your sum type. Pattern matching is still yet to come, and if you want a Visitor, you still need to write a Visitor. To the grandparent's point, this JEP isn't enough to provide a coherent alternative to checked exceptions or other kinds of structured control flow.
kaba0 6y ago
Every language is fundamentally broken from day 1, whether it is a known tradeoff or something that remains hidden for several years. Also, even if you had the perfect language with a presumably not-mainstream feature, you would have to make that feature somewhat known in the developer ecosystem (just look at Rust’s borrow checker, it does cause issues for newcomers as opposed to features already having an analog in other languages). While FP ideas were known before Java (ML predates it by quite a few years), it has become only recently more acceptable, so it makes sense to only know incorporate it into the language (and yet again, do note that FP is not a silver bullet so java has to let developers write imperative constructs just as well as before)
- damnyou 6y ago
  Unlike first-class monads, sum types are not some sort of esoteric FP construct that arises from challenging technical problems around dealing with external state. They are the very obvious dual of product types, which every language has some version of. They are easy to understand, require very little tutorial-ing, and their power is immediately obvious when you start using them. Product types model "x and y", sum types model "x or y". One of them is universal. The other has been totally missing from mainstream languages until recently. No wonder our software sucks so much.
  - kaba0 6y ago
    I agree with you in that I really like and really miss them from languages since most of them doesn’t have it in a feasible way. But sealed classes are coming fortunately in Java at least.

mc10 6y ago

I’m curious what your alternative is, given that Go famously also lacks sum types.

damnyou 6y ago
Yes, Go is a fundamentally broken language too. As is C++, as is C. Sum types are the absolute bare minimum a language must have for me to not consider it broken beyond hope. Go in particular is really unfortunate for a language so new. The language's weaknesses have dropped my estimation of its creators by several notches.
- Guthur 6y ago
  "I'm broken and can not use a language without Sum Types" There, I fixed it for you.
  - damnyou 6y ago
    Yes, that's possible. I would rather tear my eyes out than use a language without sum types. The benefits of sum types in being able to model arbitrarily complex domains are extraordinarily massive. Every language has product types. Every programmer understands how useful product types are. Why in the world would the same not apply to sum types?
    - AnimalMuppet 6y ago
      You sound like you have a hammer, and so every problem looks like a nail. Sum types can be useful. Other aspects of languages can be useful, too. Why fixate on that one? And if you're going to say that it's a minimum bar, well, some of the other features are missing in most languages that have sum types. Pick the language that has the total set of features that makes it easiest to write whatever program you're trying to write. Don't get locked in to focusing on only one feature.
      - damnyou 6y ago
        Yes that's why I write Rust. Our field has a terrible reputation for quality. In my estimation roughly 70-80% of that is directly or indirectly because of the lack of sum types. Directly: people don't have the right tools to make invalid states in their business logic unrepresentable. Indirectly: the lack of sum types results in broken null and error handling.
        Guthur 6y ago
        At this stage I'm now convince you're trolling us all. Well done you had us all fooled :)
        damnyou 6y ago
        Not trolling. Entirely serious.
        bombela 6y ago
        Can anybody explain why the parent is being downvoted? We can argue on the percentage. But the point on the direct and indirect damages makes a lot of sense.
        AnimalMuppet 6y ago
        Late reply; I hope you see it. My reply is late because I had to think for a day first. So, my sincere congratulations - a post that makes me think for a day is much rarer than a post I agree with. To me, sum types for error handling are isomorphic to checked exceptions. They both let you do dual-track programming - separating the normal path from the error path. Both have compiler support for enforcement. But checked exceptions are no longer considered to be the answer. What went wrong? The problem turned out to be the programmers. They did at least two things that subverted checked exceptions. First, they silently ate exceptions (that is, had an empty catch block just to make the exception go away. This is the equivalent of having a sum type that is either an integer or Nothing, and a function. Rather than return the sum type, the function returns an integer. In the Nothing case, the function just returns 0. That's about the same as the empty catch block to not have to declare the exception in the function's return type. The second way checked exceptions went wrong was the opposite. When a function could throw Exception1, Exception2, Exception3, and Exception4, it was tempting to just declare it as throwing Exception (the base class). In the same way, a function that gets SumType1 back from one function, SumType2 back from another function, and SumType3 from a third function may return the sum of the sum types. It becomes an Everything type. In both cases, the problem was that programmers were lazy. But here we are 20 years later, and programmers are still lazy. Until the programmers change, sum types won't fix things any more than checked exceptions did.
  - exclusiv 6y ago
    Also - "I refuse to use most languages that have been used to solve a shit ton of problems". Or, "I will not use any language which made software eat the world"
- timmattison 6y ago
  Does the Either type from the vavr library for Java cover this? https://www.baeldung.com/vavr-either https://www.baeldung.com/vavr-either
  - damnyou 6y ago
    Having a type available in an optional library is not the same thing as having them baked in from the beginning. The absence of sum types warps a language in grotesquely terrible ways, such as Go's err != nil patterns or Java's exception system and visitor patterns.
  - PhantomBKB 6y ago
    I wouldn't say no, because it's built with the right spirit in mind. But at the same time, it's different from languages have native support for sum types. Advantage of sum type is that it can be matched exhaustively like an enum, but at the same time it's flexible to contain any data like a data class.
- benibela 6y ago
  C has unions What more do you need?
  - damnyou 6y ago
    Are unions used for error handling and null checking? No? Then they're not very useful.

WClayFerguson 6y ago

Improving a dominant (but broken) language is called "innovation" and "improvement". There's no reason all your magic bells and whistles couldn't have been added into Java. Creating new languages just made life worse for everyone.

tombert 6y ago
>There's no reason all your magic bells and whistles couldn't have been added into Java. Because it's designed in a way that doesn't always allow these bells and whistles. If I were to tell you that we should have kept using horse-drawn carriages, and that any of the fancy bells and whistles that cars have could be added to horse-drawn carriages, you would probably look at me with confusion. > Improving a dominant (but broken) language is called "innovation" and "improvement" Sure? But modifying an existing (and for most of its history proprietary) language can be a difficult, potentially-political move. If I have an idea on how to do, I don't know, linear-types checked at compile-time, I wouldn't have any idea where to begin adding that to the javac compiler. It might be easier to build my own little language to build it, and then hope that maybe the Oracle devs decide to pick it up.
- WClayFerguson 6y ago
  The horse-drawn carriages analogy is not applicable because I'm using Java in my current project, like most other large corporations, I don't find it antiquated, I find it "state of the art". There are some improvements that can be made however (any language can be improved on), that would require minimal breaking changes (like fixing Type-Erasure), and I'd even be fine with minimal breaking changes that break backwards compatibility every 5 years or so. The problem is when people say "Let's burn it all down and start over, so zero existing code is salvageable."
  - tombert 6y ago
    Sure, great, but you must understand that adding language features to basically anything that isn’t Lisp moves glacially at best. I mean, let’s go with your example with type erasure; people have been complaining about it for more than a decade, and Oracle still hasn’t fixed it. The Java language designers aren’t stupid, and I’m sure they’ve read the complaints, but it still is almost universally agreed upon to be a broken feature of the language. It’s almost never clear if “language feature X” is a good idea until it’s been implemented and battle-tested. If I have a new idea on how to build something in a compiler and I’m not sure if it’s a good idea, are you saying that the best path forward would be for me to make a PR to javac instead of building a proof of concept language?

oftenwrong 6y ago

Sum types are coming to Java in the form of sealed classes: https://openjdk.java.net/jeps/397 https://openjdk.java.net/jeps/397

Twisol 6y ago
To be fair, Java has always supported a particular flavor of sum types founded on subtyping: use an abstract class with a private constructor as a base, add nested static final subclasses for the variants, and decide whether to use instanceof or the Visitor pattern to dispatch on each variant. (The Visitor approach corresponds to a certain isomorphism -- the sum type `A + B` is equivalent to `forall T. (A -> T, B -> T) -> T`, where the pair of handlers `(A -> T, B -> T)` is the titular visitor.) That JEP elaborates on the same ideas (notably using `instanceof` instead), as the linked JEP explains, but the motivation for sealed classes extends to further harmony with subtyping. The major item seems, to me, to be allowing interfaces to be a supertype. A minor but distinctive item is that the sum type's variants can be defined at (some) distance from the base type, rather than all being defined in a single breath. The problem is, even though you could always express sum types in Java, it's verbose, unpleasant, and above all "clever" in a way unnecessary in other languages. I think this JEP helps somewhat -- the private constructor trick in particular goes away -- but it doesn't really help with clients of your sum type. Pattern matching is still yet to come, and if you want a Visitor, you still need to write a Visitor. To the grandparent's point, this JEP isn't enough to provide a coherent alternative to checked exceptions or other kinds of structured control flow.

kaba0 6y ago

Every language is fundamentally broken from day 1, whether it is a known tradeoff or something that remains hidden for several years. Also, even if you had the perfect language with a presumably not-mainstream feature, you would have to make that feature somewhat known in the developer ecosystem (just look at Rust’s borrow checker, it does cause issues for newcomers as opposed to features already having an analog in other languages). While FP ideas were known before Java (ML predates it by quite a few years), it has become only recently more acceptable, so it makes sense to only know incorporate it into the language (and yet again, do note that FP is not a silver bullet so java has to let developers write imperative constructs just as well as before)

damnyou 6y ago
Unlike first-class monads, sum types are not some sort of esoteric FP construct that arises from challenging technical problems around dealing with external state. They are the very obvious dual of product types, which every language has some version of. They are easy to understand, require very little tutorial-ing, and their power is immediately obvious when you start using them. Product types model "x and y", sum types model "x or y". One of them is universal. The other has been totally missing from mainstream languages until recently. No wonder our software sucks so much.
- kaba0 6y ago
  I agree with you in that I really like and really miss them from languages since most of them doesn’t have it in a feasible way. But sealed classes are coming fortunately in Java at least.