Discussion on: Should I use fp-ts Option?

[Luca Saba]

I'm trying to...understand FP so, my comment may be dumb.

I think the initial example is unfair. This is a more concise way to write it.

const greet = (name: string | undefined): string => {
  if (!name) {
    return 'Greetings!'
  }

  if (isAuthor(name)) {
    return `Hello ${lowercase(name)}`
  }

  const last = lastName(name)
  if (last) {
    return `Hello ${last}`
  }

  return 'Greetings!'
}

I think it's very readable. You don't have side effects. You've only one variable, name, and, in every line, just knowing it, you can understand what will be thew outcome.

In the Option version, when you arrive at the second O.fromNullable(name), you need to read back all the pipe to understand what will the outcome be.

Am I wrong ?

P.S. It certainly breaks the single return law but... multiple return allow you not to "stack in your memory" the state of a variable in every step.

[Anthony G]

No, you're not wrong, and your comment isn't dumb. Probably most developers today would say that what you've written is easier to read. You could even argue that your approach looks closer to pattern matching in a language like Haskell.

You're right about reading back the pipe. I think your comment is a bit similar to alnj's, both of which point out a flaw in my article. I wanted to pick a simple example that would showcase some features Option has beyond a more traditional control flow (alt, chain etc). If I had included Either & related functions, it would have been a more elegant flow (example), but I was worried about scope creep

I'm still asking the same questions you are quite frequently in my own work. There really are a lot of grey areas around readability today. Hopefully, as fp catches on, more and more people become adept at reading this kind of code

I'm not sure I agree about the single return law, though - while I understand your point about keeping a stack in your head as you're reading it, I think it can be equally difficult to keep track of the conditions that have caused the function to exit early, and it can lead to less explicit code in general

[Aleh Atsman]

@lucasaba I had a similar reaction when I read the example in the blog post. You're right, the projects I've seen using fp-ts can be challenging to read. While I appreciate the safety and reliability it offers, I prefer cleaner and more concise code, like the one you mentioned. I believe that in the world of IT, every technology and idea comes with its own trade-offs, and in the case of fp-ts, readability seems to be a trade-off.