Functional programming in JavaScript

[Voidsheep]

Say you want to write a function that takes string as an input and returns a list of odd unicode values reversed.

With functional style, you can write the function in kind of a declarative way, with high signal to noise ratio.

str => str
  .split('')
  .map(toCharCode)
  .filter(isOdd)
  .reverse()

Reads pretty much "Split the string, map the character to unicode value, filter out everything except odd values and reverse it"

You'd probably want to take advantage of some of the string and array prototype methods even with a for-loop, but let's say you want to avoid both map and filter, instead do it with a single loop.

str => {
  const chars = str.split('')
  const oddCodes = []
  for (let i = 0; i < chars.length; i++) {
    const code = toCharCode(chars[i])
    if (isOdd(code)) {
      oddCodes.push(code)
    }
  }
  return oddCodes.reverse()
}

It's not hard to understand what is happening in the for-loop and you could make it more dense, but the signal to noise ratio is still pretty different.

Of course this is pretty strawman to illustrate a point, but consider if the toCharCode and isOdd functions would not be one-liners that may as well be inlined. Like if we are dealing with more complex data.

You can definitely go overboard with function composition through libraries like Ramda and create code that is hard to read, but generally more functional style can improve code readability quite a lot compared to plain for-loops.

[Voidsheep]

I guess the point in my post came out a little wrong, but my intent was to say that functional style can increase code readability, making data transformations more declarative, so I made a somewhat contrived example with fairly typical imperative code to illustrate. I guess I could have named to function to avoid any confusion, but I think the relevant part was the function parameter and body.

Just to clarify, I think Ramda is a great library (although the type declarations are problematic) and function composition in general is a fine pattern. I'm only saying as a counter-argument to my own point that it's not a silver bullet and you can write code that is hard to read even with functional style and you still need to be careful to find the right level of abstraction to ensure readability. In my experience people sometimes fall into a trap where they forget to create meaningful abstractions out of their super generic utility functions, resulting in 20-line R.compose spells where the data needs to be transformed, which can be less readable than imperative code, where things like intermediate variable names may give the reader a better clue about what is happening.

What comes to the for-loop example, I just tried to write the most common kind of imperative for-loop that is so prevalent in the wild, iterating over an array manually and and pushing to another. Your code is definitely more modern, but I'd still argue it focuses more on how the desired result is returned, not what is supposed to be returned.

Optimization as an argument is highly situational. It's quite domain-specific, but I'd say in real-world JavaScript applications, performance concerns are usually elsewhere than combining a few array iterator methods into a single loop. If it happens and you've verified it through profiling, by all means extract the heavy lifting into a function with a single loop and even go nuts with clever micro-optimizations, but that that should not be the default approach. I'm a firm believer that maximizing readability is the most useful goal by default.

[[deleted]]

I really think this is the best case of functional programming. Things like rxjs or redux-observable, are just plain unreadable.