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.
Comments on Are there any downsides related to using Maybe or Optional monads instead of nulls?
Parent
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.
Post
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