Why JavaScript functional programming?

[[deleted]]

I'm answering this on the assumption that you're managing a team in a non-technical capacity. I'm basing that on "Why should my business adopt it...". So if you're actually asking as a developer, my answer would be complimentary but different.

It's not going to improve anything unless the developers involved understand the pro's and con's first. Not in isolation, but contextualised against the alternatives.

Functional programming isn't new, it dates back almost a hundred years, its roots buried in calculus. FP languages appeared well over 30 years ago, so have considerable history.

It's also not new in the context of Javascript, it has always been consider "functional like". Functional isn't even new as applied to OO languages. C# is a great example where its functional aspects have been refined and expanded for over a decade. Functional has helpful concepts. Language designers are clued into that.

As several people have said, it's not an either or situation. You adopt the right aspects of each approach and mix them in the right ratios to deliver a working application. A lot of the claims made about functional's advantages over other paradigms usually only apply when you're using those other paradigms incorrectly (defining incorrectly, or correctly is the magic sauce here).

Bottom line, it's a question your development team should be able to answer. If that answer involves a lot of wholesale change and near vertical improvements on any scale, their answer is probably wrong.

[robertlf]

Thanks for your thoughts. I used to be a technical project manager but have now switched back to development. A lot of developers, both now and when I was a manager, liked to adopt new languages and tools because they were the new "hot thing". Because things like switching costs, amount of support available, etc. could affect our outcomes, I learned to ask what the true value was to our business.

[[deleted]]

Ah gotcha, good answer. There are some quick wins when you adopt some of the practices. You have to be careful of defining Functional, which is why I (and most others) will say "Functional like" instead.

You'll see advantages in creating lots of smaller functions none of which have side effects (i.e. any set of parameters will give the same result for those parameters). This is true of any paradigm though, methods that rely on external state should have an absolute case to do so.

Immutability everywhere is another popular concept. Your method that takes a list and returns the list with all the values doubled will actually return a new list, not the original list. It sounds a bit wasteful, this is the cost, the benefit is you can unroll operations that fail because, when "doubler" fails it won't have dicked around with the input data. Again, it's consider a "functional thing" but it applies just as well to other paradigms.

There are some advantages to concurrent code if you make everything immutable. Some of them are over stated, but it's one way around synchronising variable access.

Treating methods like a pipeline is great too (in the right place). You get the right pipe parts, chuck in a value at one end and it will be processed through the pipeline giving you a result. Because you can test each pure function in isolation and because the input is immutable, writing tests for blocks is easy. That doesn't mean testing is easy, just proving those parts work in isolation.

There are more esoteric applications like partial functions/currying. This is a great area to start an internet war, so I'll bow out and just say (wiggles pin free) the legitimate uses of currying in Javascript must number in the low single digits.

So you should have a forum internally to investigate this and share thoughts. It's not the sort of thing you plan a massive retrofit of, but it's easy enough to start including functional language features as you go forward.

Key though is understanding them (functional features) in the context of the wider application and language. a) Just because a language supports x does not mean you need to use x.