Java Without If (opens in new tab)

The point of a static type system is to have the language help you out as much as possible to write type-error free code. It can't guarantee that you haven't messed up, but it's supposed to help.

Null ruins that. It's a known source of runtime exceptions, and it is not a compilation error to return null or forget the null-check. It is a compilation error to pretend that an Optional<T> is just a T. The Java compiler is not smart enough to prevent you from doing something silly like calling get() on Optional<T> without checking isPresent() first, but at least it gives you something.

Also Optional has some really nice creature comforts. It gives you the ability to map to compose an Optional<T> with functions that couldn't care less about the Optionality, and it lets you use flatMap to chain successive calls that might fail together, avoiding an arbitrary number of null checks (that you might forget!) in your code.

Frankly arguing against Optional<T> is like arguing against map on lists/streams and saying that for is good enough for you. You can do it, but I think you'd be nuts to work against yourself like that.

Simple answer: never return null.

If something is wrong, throw an exception. If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty.

The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc.

But no one should ever have to check for null anymore.

you shouldn't really be running `optional.isPresent()`, but rather, use a map operation, or a flatMap operation, all the way until you need to interface an outside api (in which case, you use a `getOrElse(defaultValue)`).

You're right about code that branches based on `isPresent()` is semantically the same as null checks - and if you only did that and didn't use any functional paradigm like mapping on the types, you don't really get any real benefit!

Optional types shine the best when you can chain them:

BufferedImage avatar = users.getUser(userName) .flatMap(User::getAvatarUri) .flatMap(ImgIO::read) .orElse(anonymousAvatar);

I made this up, but I hope you see the point. Optional is just a fancy null pointer if you don't use it in a functional way. :-)

I think the most benefit of wrapping the result in an optional is so you can use compiler to enforce exhaustive pattern matching[1].

   Optional<Integer> num = getSomeRiskyNumber();
   match num {
     Some(x) => ... ;
     None => return error or whatever;
   }

The compiler will verify you at least pretended to look at the None result instead of just ignoring it (but you could still swallow the none).

1: does java even have this?

Optional forces the null check (at the cost of a pointer dereference :( but that's Java for you). That's the difference.

It also provides some nice combinator syntax for handling that null beyond .isPresent, but if you were to just get .isPresent it would be a win.

Documentation is optional (hah) and therefor shouldn't be relied on.

Optional as a return type means there's no need to check for documentation, there's no need for @Nullable, and you get some pretty syntax to boot.

A few things that need responding to. First, optional is the same as a maybe. They're different names for the same thing.

If you want to return a status instead of nothing, you use an Either type (as mentioned in the post). In an Either, you populate left or right, but not both. You can let left be your status and right be your template type. You could codify this as StatusOr<T>.

In a StatusOr land, you return if there's an error; otherwise you continue the computation. This gives a few advantages, but one is that you control the flow of control. (This is also done decently with exceptions in Java, iirc)

However, all of these - maybes, either - they make your functions composable.

There's a good talk... Railroad oriented programming... that dives into this.

In Scala, you're encouraged to write more bulletproof code by avoiding exceptions at all time, simply because it's easier to realize that (in your case) getSomeRiskyNumber returns an option instead of an integer.

  getSomeRiskyNumber map {
    case Some(i) => Map("risk" -> i)
    case None => Map("error" -> "Error retrieving number.")
  } map { response =>
    Json.toJson(response) 
  }

Reading this code you know you're always going to generate a json response to the user, and depending upon what getSomeRiskyNumber() returns, the json response will either look like { "risk": 23 } or { "error": "Error retrieving number." }. No exceptions needed.

>Why is Optional<> better then throwing an exception or returning a null?

https://www.infoq.com/presentations/Null-References-The-Bill...

> To just return 1 value you've allocated at least one object (Optional)

May be nitpicking, but in your other example, you've allocated at least one object (Integer) to just return 1 value, which means that supertight performance is not important in getSomeReskyNumber

First of all, the use of isPresent is a red flag that optionals aren't used right.

You'd typically use a sequence of map, flatMap and orElse calls. For example, this is some controller code I'm currently shipping:

    return Drawing.getForLocation(id)
        .map(d -> ok(Json.toJson(d)))
        .orElse(notFound("No drawing for location " + id));

That construct is more readable to me than an if(drawing != null) check. The cognitive load issue is a bit of a red herring. I'm used to optionals now and they're no more of a cognitive load than an if construct. But that's eye of the beholder stuff, so let's park the cognitive load issue for now.

Getting down to the meat of your argument, why is optional better than an if not null check or an exception?

I think anyone can see why it's better than throwing an exception. Optional makes it obvious to the caller that (a) there can be no response, and (b) what happens exactly when there's no response. With exceptions, either they're unchecked, in which case you don't know what exception to catch without peeking, and it's really easy to forget to add a try/catch handler at all; or it's checked, but even in that case the handling code is uglier than an equivalent optional construct.

The more interesting question is why it is better than deliberately returning null. Again, it's about signaling. A library author can signal to the caller that they should expect not to get a value sometimes. Yes, it's possible to return null from a method that returns an optional, and this will cause an NPE, but in that case the error is the library's, not the callers. In making API's, you want to encourage correct use, and optionals help do that.

Optionals in java suffer from the same problem as most API's in java do though. They're uglier than they need to be, and some common use patterns are awkward. For example, in my spark code in scala I'll use constructs like this one to convert a stream between types where the conversion might fail for some elements (and I don't care about the ones where it does):

    val someIntermediate = someStream.flatMap(convertMaybe)

That works because Option can be handed to flatMap directly.

But in Java streams, you can't do that, and you end up with constructs like this:

    someStream.map(convertMaybe).flatMap(o -> o.isPresent() ? Stream.of(o.get()) : Stream.empty())

Which is insane. In Java 9 they're kind of sort of fixing this and it's going to be

    someStream.map(convertMaybe).flatMap(Optional::stream)

Which is still ugly though.

Any way, I think optional has its uses in Java. It's definitely something that helps when building out robust API's. But where optionals would be most valuable, the combination with streams and futures, is where they're painful to work with. That's par for the course in Java though. Oracle's not actually all that good at designing API's. Usually the first attempt at something turns out so broken it has to be replaced wholesale later (like java.util.Date), or it's so ugly it feels bad to use it (CompletionStage? seriously?). But, to each their own, I'm sure my attempt at it would be even worse, and despite the warts I still like Java 8 overall.

In my case above, there's just one object, maybe (or maybe there isn't?).

In the case you're presenting, one might consider:

  Stream<Foo> myVals = gateway.callThatApi(...)
  return myVals.forEach(val -> getFooOrBar(val).apply(val))

Not quite as nice as Scala would let me do it, but closer, simpler.

Streams also let you add filters to the "list" of values, reduce them to a single value with a reducer, or use a nice set of "collectors" that reduce to Java generic collection types. (Collectors.groupBy is so handy).

Streams are also lazy, which I think is more good than bad.

The thing I tell everyone to do right now, today, is to open their Java code and search for "return null", then replace it with "return Optional.empty()". It'll break your code in lots of places, but things will be better when you fix all those things. Often you'll find lots of places that didn't handle the null possiblity at all!

What makes it clearer? I think you're just more used to "match", whereas other people are more used to "if".

The structure is almost identical. You even have an "else" clause!

Nice because it is readable but I generally dislike clever/elegant solutions for fizzbuzz. Here is my own clever haskell solution:

  module Raindrops (convert) where
  import Control.Monad (liftM2)
  import Data.Foldable(fold)
  import Data.Maybe (fromMaybe)

  convert = build rules
  build = liftM2 fromMaybe show . fold
  rules = uncurry rule <$> [(3, "Pling"), (5, "Plang"), (7, "Plong")]
    where rule i s j = if j `mod` i == 0 then Just s else Nothing

Short explanation: the fold function combines lists of monoids. In this case it combines three seperate monoids and does `[Int -> Maybe String] -> Int -> Maybe String`. It takes a list of functions that might create a string from a number, gives them all the same input and concats all strings that were returned. If none were returned the result stays Nothing and is then replaced by the string representation of the input via fromMaybe.

I like this solution because it shows how powerful it is to abstract over these concepts but also that trying to be too clever quickly ends in impossible to follow complexities.

While it's "neat" to encode a lot of stuff into types, it also makes code comparatively very difficult to understand for almost everyone. A big part of this is that documenting type systems is even harder and the tooling is even worse than documenting regular code, at least in mainstream languages (like C++; some called me a template guru years back), and of course that many developers are simply not very experienced with complex type systems. For that reason most developers stay well within the bounds of their languages' type system; it arguably gives you code that may be more "plain" and less "smart", but also code that far more developers will be able to reason about efficiently.

Feature rich type systems are really great if you have a good understanding of your types. Often, you don't. One of the best parts of software is it's malleability. Pushing business logic up into types makes it less malleable.

Checkout clojure.spec - you might find it very useful. The problem with types is that they are only a static/at rest description of your data. For example, it's a String or it's a Date.

But does that String contain @ character (checking for email)? Is this Date in the future or in the past (validating a credit card form)? Types say nothing about that. I'm not saying that types have zero utility, but in the vast majority of my use cases compile-time type checking doesn't go very far.

Scala is still a baroque abomination which excels in nothing and the advantages are shadowed by its warts. Kotlin is just Turbo Java.

And because it is implemented poorly, it adds complexity. Even Scala, which had Option from start, has three ways to return value from Map (Option, nullable return value, and throw an exception if not found). Kotlin has only single way.

I think java's problem here is how annoying it is to split these up. For example your example completely split up in java vs haskell:

Java

  IntPredicate even = i -> i % 2 == 0;
  IntUnaryOperator add2 = i -> i + 2;
  UnaryOperator<IntStream> process = s -> s.filter(even).map(add2);
  for (int i in process.apply(numbers)) {
      System.out.println(String.valueOf(i));
  }

Haskell:

  printProcessed  = mapM_ print . process
    where process = map (+2) . filter even

Good points. I just feel that this is something IDEs really need to solve, without involving work from me. And it might be a limitation of the JDK debugging system (though I imagine it could be shimmed into IDEs either way).

Basically I want to see a "skip to next chained method" button alongside "step" and "step into" and "step over". And maybe another that lets me step to the next iteration of a given chained method as well.

That's the traumatizing way. Not bad if you have one mapped function. Terrible if you have dozens. Stepping through code should not require setting more than one breakpoint - but if I have to find where a set of chained method calls goes wrong I have to breakpoint-binary-search to the problem.

When you have "if" statements, you can press "next" repeatedly in Eclipse/IntelliJ/whatever and step through the code. When you use chained method calls you're constantly going into and out of function calls, and all the local variables become return values that you don't ever necessarily get to see in a stack frame, and sometimes you have to step through loads of boilerplate to see the next interesting line of code, even when you're doing something totally simple.

Can you explain the "a programmable semicolon" part? I've tried and tried and can't think of any way that makes sense to me. I use flatMap all the time but still don't understand the expression.

My approach works with arbitrary conditions, that's why it takes closures as arguments. So it's a little bit of a different requirement, I wanted something as general as possible.

Python https://gist.github.com/bradmwalker/b300f36e9427f729b458

It's all type signatures. The actual function is seven lines.

I came up with nearly the same solution in swift:

https://github.com/zachcoyle/fizzbuzz-without-booleans/blob/...

But I like your solution better

I also wanted to avoid match expressions as well

On the contrary, I'm fascinated by the prospect of a job where I'd be paid to abuse type systems to produce useless programs. :)

On the contrary, once you understand how it works, it's trivial to change the program

Let's say you wanted to change the program to yield "Fizzbuzz" instead of "FizzBuzz" in the 15 case, but the rest being the same.

I would first build my string from "fizz" and "buzz" and then I'd have to do .map(capitalize) as the second to last step. If I wanted to have the correct case in the originating strings I could just run them into to_lowercase first before anything happens and capitalize correctly afterwards.

(Actually, the capitalize function itself is probably more complicated than this change)

Similarly, other changes are intuitively easy to stick into the correct place in the program once you know what this program does.

Try to down with the sickness your brain has before commenting something utterly useless and calling names. I was talking about the lack of competent workforce.

And if you are mapping not to a value but to the execution of a statement, should that be map instead of for?

Well, I agree with that. If you're mapping use map instead of a for loop.

Eh, in that case you should roll your own container type appropriate to the business logic, e.g. DBWriteResult<T> (or return Optional<Optional<int>>, but probably not that)

clang will(at least v4 will) tell you you did a silly thing if it can reason that your a statically binding a reference to nullptr. int & i = (int)0;

Not sure how far it can go down the rabbit hole though. This is really where value types/regular types are really nice.

I think it would have been better for Java to allow the flatmap like stuff for any reference instead of creating an optional. But I am not a fan of either for when there is no value due to error conditions. There are optional values and there are errors that prevent the fulfillment of the contract. So either throw so something can be done or return a class that can either be an error or the value. But returning null does not allow the caller to act on it.

You are so right though about non-null references. I would go further and say nullable should not have been the default but an added keyword. That is the trait of a c++ reference I like. Just use it and don't check for null. With that Optional can have some differentiation and is meaningful for situations where an error hasn't occurred.

> If this API is not understood then the code feels convoluted.

I think there is more going on here. For the sake of eliminating an if, you are lifting everything else into what is effectively a separate language with the original code embedded in that language. Overall, that doesn't look like a win to me.

After all, what is the actual domain logic? Is it flatMap().map().flatMap().map()? Or is it validate().businessLogic().generate() ?

That doesn't mean that what is going in isn't useful, but it seems to me we need to have a way to specify the lifting without writing it down everywhere, so that the actual code can be expressed at the base level again.

Map, filter, fold, etc. are pretty much standard constructs and any decent programmer should be familiar with them.

There are subtle variations in naming like Java's Map is Select in C# because Microsoft modeled its functional API on SQL, but you have the same differences for iteration and selection (the things you are referring to for and if).

For example you have 'for (int i = 0; i < n; i++)' in C, but you don't have the exact same way of doing it in Python, where you have to use a range: 'for num in range(0, n):' or you can write a 'while' loop in Java but not in Go where it's a 'for' with a single expression.

I would choose a functional version over a three level nested for loop monster any day.

I think this is replacing a formalism closer to natural language with one that is more abstract.

It's often justified to do that. For instance, we model stuff as matrices or graphs to gain access to their mathematical properties or because we have specialized hardware for matrix operations.

The big debate right now is whether the mathematical properties of functional programming are useful enough to move further away from natural language for general purpose programming.

We probably think something like this:

  Parse and validate the request
  If that fails then
    return 400, "invalid request: " + err

  Run business logic to get a result
  If that fails then
    return 500, "logic failed: " + err

  return 200, result as JSON

So should we use a formal language that looks similar to that or are there good reasons to use a chain of map and flatMap calls to hide the branching logic?

Reading an API's documentation doesn't mean that the mental overhead when using it is gone. You still have to think about how the pieces fit together, how to get from generic examples to your specific case etc.

I can dream up APIs which will keep confusing you, no matter how long you use them (hello Android SDK!). Or which have difficult to memorize syntax (hello Bash!).

I think this has to do with implicit behaviour vs. explicit statements. Using Optionals introduces an implicit layer that is much "thicker" than even the most tricky for syntax out there. There is a strong case for keeping all involved parts as simple as possible. And this assumes there are no implicit caveats and exceptions in the overall behaviour of the type, or that any one decides to subtly move the goal posts behind the scenes five years down the road.