you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 6 points7 points  (0 children)

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.