4 ms·
The problems with null are: 1. They are not composable (can't map or flatmap or fold/reduce them). 2. They can only represent one extra value, if you need mor
by haspok 4y ago
The problems with null are:
1. They are not composable (can't map or flatmap or fold/reduce them).
2. They can only represent one extra value, if you need more, you are back to square one (eg. you can't return an error value, only the fact that there is no value).
If we make another step, one could argue that even optionals are lacking, one should model the possible domain values with sums and products in such a way that no nulls or optionals are required. Do not try this in a language with such a basic type system as Java or even Kotlin though, you will run into the limits of the type system almost immediately.
- kaba0 4y agoIn modern Java you could do this: sealed interface Option<T> permits Some<T>, None<?> {} record Some<T>(T value) implements Option<T> {} record None() implements Option<T> { static <T> None<T> none() { return new None<>(); // can also be a single instance } } The only less than ideal part is that None needs the generic type, but that can be easily circumvented by adding a generic helper method. You can add all the Monad goodies to the Option interface and you will even get exhaustive switch cases with pattern matching. The only thing Java’s type system can’t express is abstracting those Monad goodies, but it can absolutely implement them on a case-by-case basis.
- sn9 4y agoMario Fusco gave a talk showing how to implement monadic patterns in Java years ago. I never found the talk online, but here's the speaker deck: https://speakerdeck.com/mariofusco/monadic-java https://speakerdeck.com/mariofusco/monadic-java
- haspok 4y agoThank you for bringing this to my attention, my current project is on Java 11, and I'm really struggling with the restrictions around enums (the poor man's sum type :)) and interfaces... maybe I can push for Java 17 at least! The fundamental problem in Java is, however, what you stated in your last sentence: you are limited in abstraction, in most cases you have to implement the specifics.
- dtech 4y ago2 is not different for Option(al)/Maybe. 1 is simply not true in Kotlin: value?.let is both map and flatmap for value with nullable type. Which one depending on whether you return a nullable type inside the let (flatmap) or not (map).
- tsss 4y agoIt absolutely is true. The ?. operator is nominally different to map/flatMap. It does not extend to other monadic types and neither can you abstract with map/flatMap over nullable types. Not to mention more advanced type system features like higher kinded data that Kotlin can only dream of. Option can be mapped over types, ? can not. Option can be handled by sop-generic programming, ? requires a special case. Option is bijective, ? is not.
- MrBuddyCasino 4y ago1. They are not composable (can't map or flatmap or fold/reduce them). Kotlin helpfully added mapNotNull() and similar methods. 2. you can't return an error value, only the fact that there is no value Yes I much prefer Rust-like return values, the non-local control flow of exceptions leads to convoluted code and improper error handling.