Ah thanks for pointing that out as I didn't make myself clear. I definitely didn't mean Java as a whole, as it is indeed a tremedously successful platform and language.

I meant specifically the lack of flexibility in some regards because of the missing of monads and friends.

For example, we have a few newer languages, TypeScript and Kotlin come to mind, implementing the "null operator":

   thing?.fieldA?.fieldB

While this is quite handy, and people unfamiliar with the Option monad will think that this new syntax is really cool, it poses two limitations: 1. It doesn't compose with other abstractions 2. I can't use this for my own abstractions

If the language designers had chosen to take one step back and implemented it in a more generic way (in some sense, in the same as my other comment in this thread about implementing "map" without "reduce"), the feature could've still been implemented in the language, but without the limitations.

I'm not sure what you meant with this point:

> people lamenting the lack of monads in Java.

Do you mean that, because you don't see people lamenting, it's not a useful feature?

> It doesn't compose with other abstractions

But monads don't compose with each other, do they? I thought you needed something more (monad transformers, algebraic effects, etc.) to get things to compose. Or maybe you meant something else by composition.

> I can't use this for my own abstractions

Yep. But Java doesn't even let you overload addition afaik, so being able to overload ? is pretty much a pipe dream.

> Do you mean that, because you don't see people lamenting, it's not a useful feature?

No, it's just that if something "backfired" for Java, I'd expect to hear people complaining about it.

> But monads don't compose with each other, do they?

They do if they're[0] traversable (cf literally `Data.Traversable` in Haskell), which almost all specific monads are. You'd have something like:

  newtype Comp f1 f2 a = Comp { unComp :: (f1 (f2 a)) }
  instance (Monad f1,Monad f2,Traversable f2) => Monad (Comp f1 f2) where
    (Comp a) >>= k = Comp $ a >>= (map join . traverse (unComp . k))

Edit: 0: actually, only the inner monad needs to be traversable.

Looks like that that's not a valid monad in general.[0] And also, I feel like it's a stretch to say that "almost all specific monads" are traversable.

[0]: https://stackoverflow.com/questions/42284879/is-the-composit...

I'm not convinced (Bool->) is a legitimate Traversable[0], but that's at least highly concerning and makes me wish the typechecker could properly handle "Instances should satisfy the following laws" comments as actual code.

0: in vaguely the same way that Int isn't a legitimate Monoid because you get nonsense by switching back and forth between sum and product (and min, max, xor, and, or, etc)