What If the Team Hates My Functional Code?

> I think FP is really more about pushing effects and mutations to edges, purifying (and simplifying) intermediate steps/functions, and using simple data structures.

This 100%. Simple data structures with minimal use of side effects can often be used within in an OO code base without raising any eyebrows.

Hello.

You've just described the Rust programming language.

May the Borrow Checker bless you and all your bits until the head-death of the universe.

I really like this concept!

It's something I regularly say to our juniors - if you have two ways to do something and one is much easier to debug later, it's probably a better choice. It's a nice extension of not writing unnecessarily overcomplicated code and keeping things readable.

From a slightly different perspective, and not entirely disagreeing with you but moving into a related discussion: as an industry we sometimes forget that we can build higher level debuggers just like we build any other higher-level abstractions. If the question is "how do we insert a console.log here?" (or a logging.log() to a file on disk. Or RS232 null modem command sequence plus log ASCII. Depending on the app and era) it's sometimes fine to say that question is too low level on specific output format and that we should be reaching for higher-level debuggers.

I understand the problems that higher level debuggers take time for someone to build, install, or at least train on using, and that's often time that projects can't afford, but there can be huge benefits to Developer Experience if you build or find debuggers specific to your abstractions, especially in places like functional programming pipelines.

(As some easy examples, I've worked with the Redux Dev Tools a few times and getting a "redux-eye view" of an application's data state is sometimes incredibly more useful than trying to add a bunch of console.logs into all your actions and reducers manually. Similarly, I've become a big proponent lately of using RxJS-Spy for RxJS work: it adds a single operator `tag('pipeline-name')` that is a no-op in Production builds and then gives you a great Dev-time API for observing [or debugger breaking] specific pipelines or pipelines filtered by regex of name, all without manually adding or removing `tap` and `console.log` in those same pipelines.)

We don't always have to stick to lowest common denominator debug tools. We don't still need to make sure that we can pipe to our dev terminal over serial port to get our debugging done or log everything to plaintext files that are hard to manage. I think sometimes people forget that.

Similarly, I do find a responsibility that if I write code that is best debugged with higher level tools, that I make sure to document those tools, and try my best to train people on them as they ask.

That only works when you drop in subtle hints of that this way of coding has surpassed our usual way of coding as state-of-the-art in 1970-something.

That's what this article is discussing: A means of writing code in an FP style that is easy for others less or unfamiliar with FP to maintain, debug, and refactor.

Functional programming if done well is much better for maintenance. I find a strictly typed functional code base very easy to maintain. It's far less a house of card.

That there's nothing to stop another developer from coming along and putting another for loop inside it.

I don't think Functional Programmers have a fear of for-loops, I think they love for-loops, they just prefer to define them "steps first".

A silly cross-paradigm way to look at it is that a lot of functional programming is about "dependency injecting the for-loop" and "inversion of control of the for-loop". For similar reasons to dependency injection in OOP, functional programming wants to focus on the more interesting to the program abstractions up front and leave the final "for-loop wiring" to libraries or the language itself.

The for-loops don't go away, they are still there as necessary wiring. The functional programmer just wants to "dependency inject" all the interesting piece-at-a-time steps inside that for-loop rather than worry about the entire final wired loop body. Just like dependency injection in OO is supposed to make it possible to deal with a class at a time without needing as much of the entire class diagram in your head all once. Also, just like dependency injection: it's designed so that you have a lot smaller, easier to test pieces that make up the whole.

"Fear" could be a wrong word here. I think there's contempt involved instead. Which isn't justified either though. Everything is a tool, and should be used in a right context. I.e. for loops can be better justified sometimes (I find them useful around 1% of cases, but when they are they do their job well)