The article starts with “your team hates your functional code” and goes into ways you can sneak FP past your team. It never mentions the objectively correct thing to do, which is “have a frank discussion with your team about if there’s a role for FP in the project.”

I think the problem with the article’s approach is neatly summarized by how it describes the team lead’s concerns:

You can’t write code that you know to be inferior. The way that you used to write code was more error-prone, complex, and muddled. … But that seems to be what the senior wants… or at least, what they can cope with.

They don’t consider the possibility that the senior could be right and your code isn’t better just because it’s “FP”.

This is just bad functional code to be honest (and all the variations suggested in the article):

const renderNotifications = flow(
  map(addReadableDate),
  map(addIcon),
  map(formatNotification),
  map(listify),
  wrapWithUl
);

Here’s what’s bad about it:

1. There’s no clue about what the input to this function is. Point-free style is generally more readable in a language like Haskell, because even when you don’t name the arguments, you can still support the readability with type annotations like renderNotifications :: [Notification] -> SomethingThatIHonestlyCantDiscernFromThisCode. And in a language like Haskell, you can hover your mouse over addIcon in your editor and it will tell you the input and output types (specialized to that call site even when addIcon itself is polymorphic) and if your types are faithful to your domain, that will give you ample clue to understand the code better.
2. Even though it looks like there’s no mutation here, I’d argue that there’s no ease of reasoning gained! We’re passing a list of notifications through 5 stages, and each stage has access to the complete output from the previous stage and it has the power to modify the input to the next stage completely! Isn’t this how we model the semantics of imperative programs to begin with? Each statement in an imperative program is semantically like a function that receives the full state of the program and returns a new state. This means, this code is at least as hard to follow as the equivalent imperative program that mutates the fields of these objects being passed around. But it’s actually much worse, because it goes out of its way to avoid the imperative syntactic sugar and obfuscates it even more.
3. An important goal of functional programming is to build your program up from pieces that require as little context as possible to be meaningful. I’d argue that functions like addIcon are directly in opposition to it. Why don’t you just have an icon here that you pass separately to formatNotification. This way, I can interact with that icon in a REPL or maybe write tests for it without having to create a Notification first. Or maybe the specific icon here depends on the contents of the notification, in that case, why not have a iconForNotification(notification) function with type Notification -> Icon, this way I can pass iconForNotification(notification) separately to formatNotification. That said, in all likelihood, you don’t actually need the entirety of a Notification in order to decide on the Icon, so it’s much better to have a function that accepts that relevant subset of Notification only.
4. This flow thing is also conceptually messy. The easiest way to demonstrate its messiness is to try to assign a type to it. You’ll need very advanced type system features to do that. In Haskell, the equivalent to flow(a,b,c) would be c . b . a, where . has the very simple type (b -> c) -> (a -> b) -> (a -> c). A very good example of things getting conceptually simpler when you break them down.

I think these superficial notions of functional programming are really hurting the adoption of the actual principles that functional programming aims for. It’s not that functional programmers enjoy solving puzzles in the form of writing point-free code or finding ways they can use map, fold or reduce.

The actual tenets are local reasoning and composing your program from small, independently meaningful pieces that can be composed in other ways in order to support new features, isolated tests and the ad-hoc programs you build in a REPL.

If the people you’re working with tell you there’s “too much magic” there’s too much magic. It’s a subjective position, and the other people on your team are the ones who get to decide. Stop trying to show how clever you are and write code people can read.

This is obviously a bit of a tough topic because concise examples tend to not be super representative of cases where conflicts arise.

Honestly seeing this example the only thing I can wonder is whether this code replaced something like

function renderNotification(notification) { 
  return {
    date: readableDate(notification),
    icon: icon(notifincation),
    notification: humanReadableDetailss(notification)
  }
}

let renderedNotifications = notification.map(notifications)

The biggest challenge with taking FP techniques from ML languages is identifying the useful concepts with the patterns that exist in ML or other functionally pure languages because of the functional purity and not due to expressiveness.

If your primary goal is to actually be readable to other people, then you can totally avoid swimming upstream if you take the concepts without trying to “translate” what you would write in Haskell into JS, and still get the advantages of functional thinking (namely in not having mutation soup making control flow unclear)

The article started off real well, but then let me down big time. The concerns from the senior about readability, debuggability, and performance are legitimate; I was looking toward those arguments, possibly with concessions about when FP is not as good. Unfortunately, the author does not answer any of these concerns, blindly doubles down on the rightness of the FP approach, and instead of addressing the points, just gives tips for making the FP code stylistically more palatable.

Take performance for example. In a /r/rust thread last weekend, someone asked about the performance loss of using iterator methods for base85-encoding a byte array versus a loop+index approach. Their thinking was that the iterator methods would give the analyses more information about the problem and that the optimizer would then be able to generate faster code. Instead, as they found, the iterator version was 4x slower. In this case, since they were benchmarking against an existing solution, they could see the performance regression. But what if this had been original code? Would an encoder based on the slower iterator approach have been merged with the wrong belief that performance was as good as it could be? These are real concerns that senior engineers would have and an advocate of FP should be able to address them. (Incidentally, it’s possible to make the original code 60% faster, by going into the opposite direction: by writing more procedural code that gets the compiler to spit out fewer instructions.)

If a proponent of FP is not able to rationally discuss concerns about performance, debuggability, or readability in the team, and clings to how much better the approach is, then it’s dogma. And putting lipstick on a pig is not going to make FP be better received.

There are a few comments here that bring up the question of performance. I informally benchmarked a comparison using Node 14 (V8) and an array of a million random numbers, adding 1 to each:

• Immutably with a for loop: 7.782ms
• Immutably with array.map(): 40.019ms
• Mutably with a for loop: 3.437ms
• Mutably with array.forEach(): 11.156ms

Although traditional for loops are the clear winner, in most cases, the performance bottleneck in a JavaScript app is not going to come from choosing the wrong way to iterate over an array. If only that were the case, it would be easy to find and fix. Over the 10+ years I’ve been writing JavaScript, it’s usually either something expensive relating to binding a data model to the DOM, a need to cache the results of expensive and redundant calculations in memory, or, in most cases, the size of the code itself, which can be expensive to transmit, parse, and execute and can even crash some mobile phones.

I’ve worked with some senior developers coming from other languages who claim that creating and invoking higher order functions in JavaScript is some kind of extravagant computational expense. When one is working with some massive vertex buffer or something, perhaps it is, but in most cases the size of the array is not large enough to make a perceivable difference. For compositional, testability, readability and index safety reasons (particularly when operating on nested data structures), I think the compromise advocated at the end of the article is actually a very sensible default, even if it’s prefaced by some questionable pure FP code and couched in a rebellious tone. Declaring the result of each FP-ish return value with atomic statements yields a much better debugging experience in JavaScript than either dogmatic extreme.

This is, incidentally, a thing I dislike a lot about Rust stylistically. A lot of Rust is written chaining a bunch of map()s and or_else()s and such.

It’s passable if, even as in this article, it’s a straight transform. But it rarely is. There’s often side effects (either unintentional bad ones or good ones that’d make life simpler (eg, a max/min, without using tuples on tuples))… or implicit awaiting in async version of this chaining (how many things are happening in parallel? Hope you did the right buffering call!) and… it’s just a beast to debug. A for loop would be way more obvious in a lot of cases (if for no other reason than to crack open gdb)

They are probably right and your code is probably bad.

Something is clear to me:

• you have a positive attitude towards functional programming
• your team doesn’t

Both sides rationalize in different directions:

• you think challenging yourself is valuable and the pain it creates is secondary
• your team only sees pain and they look for justifications to hide the fact the decision is already taken

Bottom line: both make a decision based on instinct. The difference is that one enjoys learning while the other don’t, and also cannot tolerate someone who wants to learn.

Quoting myself from the Reddit post on this a few days ago:

Unless you get some golden opportunity to rewrite the application, find a new team or a new job, because it really is going to degraded the cohesiveness of a code base to have many competing styles. Ideally, you’d move to a language where the functional ergonomics are easier, first-class, and encouraged; it’ll be harder to have a fragmented code base when there’s only one style in town. Nitpicking on whether or not to use lens operators is a completely different ballpark than seeing composition being questioned in a merge request like the author stated.

This got me curious. Does V8 or other JS engine optimize .map calls with fusion?

For many people, though, using pipe() and flow() at all can be a problem. They might simply have never come across this kind of thing before and not understand how it works.

This feels like the crux of the issue. When many people don’t understand how something works, that’s not a problem with those people, it’s a problem with the thing. You have to speak to folks where they are, not where you want them to be. And in that framing, you have to understand that code is not an equation, or a clever application of mathematical principles — it’s a recipe, followed step-by-step, by human programmers with limited cognitive capacity. You gotta design to that reality.

So like

// `render` is a verb that transforms X to Y, it doesn't modify X, thus...
render(ns notifications) -> rendered_notifications // ...it returns a result
    ns_with_date = add_readable_date(ns)  // as should all interior operations
    ns_with_icon = add_icon(ns_with_date) // (could re-use a stack var for this)
    ...
    return rendered_form_of(ns_with_changes)