Hacker News Reader

Comment by cjensen | Hacker News Reader

I like functional program a lot, but that very first transform of a chain of if's into a horrifying mess makes a pretty good case for using if. In the if case, function2 and function3 were called identically, but in the functional case suddenly things are inconsistent.

Is this a satire?

View on HN

They're called identically in the if case, but they're not used identically. One of functions isn't guaranteed to return a value, so it requires an "if x != null". flatMap basically says "this might be null." Part of the point here is that it makes it explicit when something might return null and ensures it's handled properly.

It doesn't take long to get used to that style. It took me maybe three weeks of playing with Java 8 streams in my spare time before I got quite comfortable with it.

It does look nice but does everything have to be done in one line/chained? Are we just showing off? There are times to use it and not.

Clarity I think comes from breaking out branching into small parts. Coding just for one-liners leads to confusion in teams many times for non functional programmers. You might have programmers yak shaving just to cut down on "ifs" because they are harmful now? Same with null types. Some languages are built for it and others aren't.

The example is less lines of code, and functional clean code, but is it easier to expand, follow and use throughout your codebase? I guess that is up to the project/team, I feel like in many cases this outlook could be adding complexity where simplicity does just fine.

Here's how this works. If a function would not return null originally, you continue to return the original type and use Optional::map.

If a function could return either T or null, return Optional<T>, and then use Optional::flatMap to join them together.

Pretty straightforward.

I am not sure either if this is a joke.

IMO it's the eta-reductions that are terrible for readability. I think the following is fine:

    Optional<String> x = Helper.functionOne()
                           .map((descriptiveName) => Helper.functionTwo(descriptiveName))
                           .flatMap((descriptiveName) => Helper.functionThree(descriptiveName));

I find the map/flatMap version easier to follow, myself. It does takes some time to grow accustomed to, though.

I'll take clarity and expressiveness (e.g. how easy it is to deduce intended behaviour) over consistency any day but perhaps I'm missing something? What's the downside of said inconsistency? (Assuming it's trivial to log inputs and outputs of each function call, if needed)

Reply on news.ycombinator.com