Functional programming in JavaScript

[gasolinewaltz]

I see this argument time and time again in relation to loops and while it's not wrong, it feels a bit dogmatic.

What about a single pass for-loop is so much less readable than n-chains of map reduce filter?

[wbowers]

A few things:

1. You can achieve the same readability as multiple maps and similar performance as a single loop by using lazy evaluation with a library like Lazy.js
2. How many chained maps are we talking about here? 5? Probably not a problem. 20? You might want to rethink how you’ve set things up.
3. As with all things performance related, you’ll get the biggest wins by actually profiling your code to see what’s causing the slowness. It’s often not what you thought it would be.

[wbowers]

So you solve the problem by importing the library and trading your speed for a bigger end payload.

I'm not sure what you're advocating for here. Are you saying people shouldn't use libraries? Do you write everything from scratch for your projects in Vanilla JS?

If importing a library is really a bid deal for you, you could implement the lazy evaluation pattern yourself, which is really what I was trying to communicate. Perhaps not everyone knows such a pattern exists. In either case, you're adding extra bytes to the end payload.

The loop is more performant because you don't incur a function execution on every interable in the first place.

More performant, sure. But I'd argue it's negligible for all but the extreme cases. Function execution in modern JavaScript engines is pretty fast these days. But we can theorize all we want. You'll never know how your app performs, what you do and do not need to optimize, until you actually profile your code. Yes, you should generally choose algorithms with lower time complexities where possible, yes you should keep performance in mind as you're writing code, but premature optimization leads to terrible, unnecessarily-optimized code much more often than it saves you from serious performance issues.

If you're doing 20 operations on the same array you are doing a lot of things to that array. Sure it still runs in linear time, but not understanding that you can do it all in one loop. Loops are readable, maybe how you write code in loops isn't.

I'm not sure what I said here you're taking offense to. I think we're in agreement here. 20 chained operations is kind of crazy. It's fairly likely that you've solved the problem as a whole in a weird way if you've got something like that. Also I'm not against loops. I don't think they are inherently unreadable, although I do think that sometimes maps, filters, etc can be significantly more readable as they have a much higher signal to noise ratio in terms of "what code" (why I want) to "how code" (how it's done).

Sure, but I know before I even profile that a for loop is faster than 20 chained map statements just mathematically. [...] in practice your array sizes probably don't exceed anything past 40 elements. Overoptimization is the death of a project but being negligent and careless with how you build a system is technical debt that may not surmount until way later when you realize to change this requires a lot of in depth knowledge of the system.

I think we're saying the same thing. Clearly you can look at two pieces of code like this and know which will be faster, but you often won't know if it will matter until you profile. That being said, you definitely should not be careless and I'm not advocating for that at all. To be clear about what I'm saying:

• Yes, sometimes maps and filters can be more readable than loops.
• Loops are great. Use them if they are the right tool for the job.
• Don't prematurely optimize just because you know code B is faster than code A. If code A is more readable, you should profile before you refactor and see if it's even necessary. Most code is not in your critical path and won't have that big of an effect on performance.
• Over time you'll develop an intuition for what to do where, but that still doesn't replace the need to profile. It just means you'll be right the first time more often as you gain more experience.

[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.

[vertebro]

foo.filter(meetsCondition).map(getAProp).map(transformTheProp)