5 ms·

Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optim

Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)

cyberbanjo 5y ago
What would do notation add to Java?
- pharmakom 5y ago
  There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!
  - Skinney 5y ago
    Excessive nesting? Optional supports both .map and .flatMap.
- emptysea 5y ago
  Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ [1]: https://zio.dev https://zio.dev
  - kaba0 5y ago
    For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency. As for others, without proper Monads, I doubt they would have much use.
- mhh__ 5y ago
  Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.
  - seanmcdirmid 5y ago
    Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.
    - mhh__ 5y ago
      I've only ever done a hello world in Kotlin I'm afraid.
      - seanmcdirmid 5y ago
        You should check it out. Definitely not as expressive as Scala for expressing EDSLs, but it has a couple of features (scoped this for lambdas and extension functions/properties that can be injected into a lambda's namespace by a scoped this type) that you can get a lot of mileage out of.
karmakaze 5y ago
The unfortunate stance on ADTs is that Java doesn't want them generalized. The standard answer is use Records and Sealed classes. What does this mean? Well with generics we can have two libraries that know about Map<> and concrete types TypeA and TypeB and can interface type-safely using Map<TypeA, TypeB>. What we can't do is have two libraries that know about TypeA and TypeB interface type-safely using a sealed type of TypeA and TypeB. Even without considering libraries, another use we may want to talk about a sealed type of TypeA and TypeC, but of course TypeA can only be in one of the sealed class trees. The worst part is that Java already has a Union type that's only ever used in multi catch(ExceptionA|ExceptionB e).
- karmakaze 5y ago
  I've been thinking about the lack of ad-hoc SumTypes in Java. The sealed class approximation isn't good enough. I'm seriously considering taking up TypeScript in earnest as my 'go to' language. It's an outlier in supporting A | B | C and being mainstream with pretty good runtime performance. One thing I'd have to check is the quality of IDE support for refactoring tooling. Refactoring operations for Java using IntelliJ almost always works and as I expect or better.
Twisol 5y ago
For myself, I'd like to see use-site variance replaced with declaration-site variance. It's really painful sometimes to have type arguments within generics more than one level deep; you have to start adding `? extends` (usually; or `? super` occasionally) at all the intermediate levels. I somewhat suspect Java is locked into its current approach to variance, but gosh, I much prefer Scala's approach here.

cyberbanjo 5y ago

What would do notation add to Java?

pharmakom 5y ago
There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!
- Skinney 5y ago
  Excessive nesting? Optional supports both .map and .flatMap.
emptysea 5y ago
Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ [1]: https://zio.dev https://zio.dev
- kaba0 5y ago
  For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency. As for others, without proper Monads, I doubt they would have much use.
mhh__ 5y ago
Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.
- seanmcdirmid 5y ago
  Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.
  - mhh__ 5y ago
    I've only ever done a hello world in Kotlin I'm afraid.
    - seanmcdirmid 5y ago
      You should check it out. Definitely not as expressive as Scala for expressing EDSLs, but it has a couple of features (scoped this for lambdas and extension functions/properties that can be injected into a lambda's namespace by a scoped this type) that you can get a lot of mileage out of.

karmakaze 5y ago

The unfortunate stance on ADTs is that Java doesn't want them generalized. The standard answer is use Records and Sealed classes. What does this mean? Well with generics we can have two libraries that know about Map<> and concrete types TypeA and TypeB and can interface type-safely using Map<TypeA, TypeB>. What we can't do is have two libraries that know about TypeA and TypeB interface type-safely using a sealed type of TypeA and TypeB. Even without considering libraries, another use we may want to talk about a sealed type of TypeA and TypeC, but of course TypeA can only be in one of the sealed class trees. The worst part is that Java already has a Union type that's only ever used in multi catch(ExceptionA|ExceptionB e).

karmakaze 5y ago
I've been thinking about the lack of ad-hoc SumTypes in Java. The sealed class approximation isn't good enough. I'm seriously considering taking up TypeScript in earnest as my 'go to' language. It's an outlier in supporting A | B | C and being mainstream with pretty good runtime performance. One thing I'd have to check is the quality of IDE support for refactoring tooling. Refactoring operations for Java using IntelliJ almost always works and as I expect or better.

Twisol 5y ago

For myself, I'd like to see use-site variance replaced with declaration-site variance. It's really painful sometimes to have type arguments within generics more than one level deep; you have to start adding `? extends` (usually; or `? super` occasionally) at all the intermediate levels. I somewhat suspect Java is locked into its current approach to variance, but gosh, I much prefer Scala's approach here.