Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs

Dashboard
Notifications
Mark all as read
Q&A

Are there any downsides related to using Maybe or Optional monads instead of nulls?

+6
−0

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:

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.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

+6
−0

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.)

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Monads in C# (1 comment)
+3
−0

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.)

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »