Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Are there any downsides related to using Maybe or Optional monads instead of nulls?
I have recently stumbled across the Maybe (or Optional) modal usage in .NET Code:
Based on everything I read, there are multiple advantages on relying Maybe instead of nulls:
- no
NullReferenceExceptions - leverage (some of) the functional programming paradigm advantages
I have also studied the implementation and usage of Maybe monad usage and all the code seems more "fluent" since there is no need for null checks (null propagation might help with this though).
What makes me wonder is the fact that I have never seen this being used in enterprise projects I have worked on and not being mentioned by any of my colleagues. Are there any downsides in switching to using Maybe instead of the regular nulls?
The only thing that comes into my mind is the need to ensure conversions at the service boundaries (e.g. the client might like nulls instead of complex objects) and conversions when using ORMs (databases still work with NULLs or similar). However, these are part of the "infrastructure" code which you write only once per service.
2 answers
This is mostly an addition to r~~'s answer which I mostly agree with. This elaborates on the "non-idiomatic" part a bit.
Modern Java code doesn't have a problem using Optional. Why? Because Optional is part of the standard library and has been since Java 8 (which is when it would have made most sense to add such a type, though it would have been technically possible [and Guava did so] in Java 5).
For C#, which doesn't (yet) include an analogous type in the standard library, it feels strange to pull in a library just for this one simple type, and many libraries including it also include and push a much more opinionated and "functional" set of code. The alternative is to make your own type which is easy but perhaps too easy. It feels like something that should be in the standard library (because it should), and it also has a high risk of being incompatible with a future standard library version. (For example, Guava's Optional is not compatible with Java 8's Optional.)
All this said, there is absolutely nothing particularly "functional" about Option/Maybe/Optional. It's simply a container that can contain at most one element. These types are obviously popular in (typed) functional languages, though mostly because most of those don't have any analogue to null. Similarly, there is absolutely nothing "OO" about null. In fact, it violates various pillars of object-oriented design. Using Optional makes more sense from an OOD perspective than using null does. I will admit that a concise syntax for lambdas helps, but 1) Smalltalk which is often considered an exemplar of OOP has always had "blocks" which are roughly a concise lambda syntax, and 2) the lambda ship has already sailed since C# 2.0 and Java 8.
So my main disagreement with r~~ is I see no need to "go all in" in a "high functional" style to use Optional. Guava and Java 8 and most of their users certainly didn't. These were certainly influenced by ideas popular in functional programming (FP), but none present themselves as "functional" or "go all in". And, again, many "functional" things added, e.g. the immutable collections of Guava, are in no way specific to FP nor contradict OOP. Indeed, again, good OOD should lead you toward many of these, e.g. an ImmutableList<A> is (conceptually but truly) covariant in A, while a List<A> is invariant. (C# has the hideous array covariance because people expect this kind of covariance because they often think of arrays as values, but mutable arrays lack this covariance. If C# separated read-only (i.e. immutable) and read-write array types, this hack would not have been necessary.)
0 comment threads
In my opinion, all of the downsides boil down to two objections:
- It isn't idiomatic (in C# and VB.NET)
- It's slightly less performant
The fact that it isn't idiomatic means that, as you noted, it'll often need to be translated at API boundaries. It also means that your coding style might vary from what other developers expect and from what you yourself use when working with other data types.
The fact that it isn't as performant as an unboxed nullable value is usually something you can ignore, unless you know that it isn't, and then it tends to be a hard blocker.
The advice I'd give to a C# developer on my team would be consider the broader, ‘high-functional’ programming style that Maybe/Option is a part of—immutable data objects, lots of anonymous functions, pattern matching via the newer switch expressions or via fold-like functions, heavy use of the type system to express invariants. That style brings lots of benefits and lots of friction with existing .NET libraries (except for libraries that target either F# or enabling this programming style in lesser other .NET languages). If it's worth it, go all in. If not, picking and choosing this style for some data but not others is probably more trouble than it's worth.
(As for ‘monads’, the fact that Maybe is monadic is worth very little to a .NET developer. The real value of recognizing abstractions like functors and monads comes when you can actually, y'know, abstract over them. As far as I know, .NET still doesn't have higher-kinded polymorphism, which means that goal remains out of reach. If you want higher-kinded types in a language that still allows a C#-like experience, Scala is waiting for you to switch allegiance from the CLR to the JVM. Back in .NET-land, ‘monad’ can only mean a particular code style as opposed to actual expressive power, which is why that's what I focused on above.)
0 comment threads