I like FP - I think that engineering and writing code in a way that would also let it be written in all the craziness of full FP style means you found the right

I like FP - I think that engineering and writing code in a way that would also let it be written in all the craziness of full FP style means you found the right abstraction - but I would never write it that way. A nice example from the article: const processData = composeP(syncWithBackend, cleansePII, validateData) async function processData(data) { await validateData(data) const cleansedData = cleansePII(data) await syncWithBackend(cleansedData) return data } // or for the Promise-chainers… const processData = data => validateData(data) .then(cleansePII) .then(syncWithBackend) .then(() => data) I would always write this as the 2nd option - it's always going to be the easiest to debug[0] and the abstractions it leverages are equivalent to the composed version in the first example or third example. When I write code that leverages FP principles (pure functions, composition, immutable data structures, etc) I know I've found the right abstraction - but there's never a need to actually abstract it all the way. That's the job of a good compiler. I'm nearly always writing code for other people to later debug, fix, extend and understand and rarely for the computer - don't make your future self's job harder than it needs to be. [0] https://sambernheim.com/blog/debug-driven-development https://sambernheim.com/blog/debug-driven-development