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

posted almost 5 years ago

CC BY-SA 4.0

Derek Elkins‭

2899 reputation 0 56 285 13