These two functions are equivalent:

  const f1 = function(s) {
    let data;
    try {
      data = JSON.parse(s);
    } catch (err) {}

    if (data != null &&
        data.a != null &&
        data.a.b != null &&
        typeof data.a.b.c === 'string') {
      let x = parseFloat(data.a.b.c);
      if (x === x) {
        return x;
      }
    }
    return null;
  };

  const f2 =
  R.pipe(S.parseJson,
         R.chain(S.gets(['a', 'b', 'c'])),
         R.filter(R.is(String)),
         R.chain(S.parseFloat),
         S.fromMaybe(null));

Note that in the first function we have an unsafe expression,

  data.a.b.c

which we must guard with null/undefined checks. Unsafe expressions can easily get out of sync with their corresponding guards.

We can apply functional programming concepts to JavaScript code to obviate the need for null/undefined checks. The fact that we can't have all the benefits of FP in JS shouldn't dissuade us from taking advantage of the ideas which are applicable.

Less as a real argument than as devil's advocate, here's a shorter non-library version:

   function f1(s) {
      try {
         let data = JSON.parse(s);
         let x = parseFloat(data.a.b.c.substr(0));
         if (x === x)
            return x;
      } catch(e) {}
      return null;
   }

...ok, it's a bit golfy, and in JavaScript you don't get much control over exception catching. But in general, exceptions can be used like an implicit Maybe/Either monad, just as mutability is an implicit IO monad.

(Also, you picked an odd task - it's unusual to expect a float to be represented as a string in a JSON object, and a check that rejects NaN but accepts weird floats like Infinity is not terribly useful.)

It's a contrived example, certainly.

Your counterexample is informative. I hadn't thought of exceptions in this way. The downside of putting everything in a `try` block, of course, is that we'll potentially catch exceptions arising from a bug in our code which should crash our program.

Food for thought David, thanks!

> I feel like this rush to adopt functional language features in non-functional languages is

Very few languages in use are fairly described as "non-functional"; pretty much any structured programming languages that supports function pointers supports the functional paradigm. A language doesn't have to be pure to support functional programming.

Without closures, or something that well approximates them, it seems hard to say a language "supports the functional paradigm". You can write functional code in C, but beyond very simple things you're implementing most of the machinery yourself.

"A language doesn't have to be pure to support functional programming."

This is very much the case.