I'm not sure you quite said this but nullable isn't just another word for Optional with syntactic sugar. You can have Optional<Optional<Integer>>, but Integer?? is not a thing. This means you can't (or shouldn't?) use it for, say, return value of a generic "get a value from a map" because you might want to be able to store nullable values in the map and probably want to distinguish "it wasn't there" from "it was there but the value was null". IIRC, in some languages with generics and nullable you can't actually write a function that applies ? to a generic argument, because there's no way to say that the generic argument isn't itself nullable.
Re:What Color Is Your Monad
by kelseyfrog on Wednesday February 16, 2022 @04:24PM
(#30365894)
I'm not disagreeing, but this is a very good jumping off point for what is an enormous discussion in the philosophy of programming right now. You've identified the correspondence between the programming language support and relevant monadic constructions. There's also the principle that programming is about applying relevant abstractions. The point of contention revolves around the question of "Should monads be available to programmers in the abstract where programmers are supported enough to write their own monads? Or should monads be reified into language constructs, thus making it a up to the language designer to choose the finite set of available monads and syntactify them into language constructs?
A vocal camp wants monads in the abstract and feels like reified monads as language constructs completely misses the point. The other camp is happy to accept new syntax and keywords to get their work done and see monads as ivory tower language enthusiasm. The choices that language designers make increasingly put their languages on one side or another of this dividing line.
I usually translate in my head to side-effect thingies. Much easier. So, Maybe<T> is short hand for it could be there, or not, you'd have to check. Same with Result<T>. Or Optional<T>. Or Future<T>. It's nicer than having null as a default value and then triggering a null pointer exception because you forgot to check but a bit less readable if you start wrapping them.
But if you have a language with nullable types, like Kotlin, you can your cake and eat it. For example, you can have functions like isNullOrBlank defined on nullable strings (String?) which don't throw a null pointer exception if you call them on a null value. Just syntactic sugar for the common use case.
Likewise, Kotlin has more syntactic sugar that functional programming types would frown upon that is actually nice to use. Like suspend functions that you can use to write asynchronous programs that almost look like they are normal synchronous ones. With proper support for cancelled co-routines, error handling, threading, reactive programming, etc. Yes, they're colored functions. But, colored functions are nice and easy to work with. My compiler will tell me off when I do it wrong.
Is it all monads under the hood or just a pragmatic language?