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
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Post History

75%
+4 −0
Q&A Are there any downsides related to using Maybe or Optional monads instead of nulls?

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

posted 3y ago by Derek Elkins‭

Answer
#1: Initial revision by user avatar Derek Elkins‭ · 2021-10-10T21:38:12Z (about 3 years ago)
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.)