Functional programming

2016 was the year my understanding and appreciation for functional programming grew big time. Functional programming (FP for short) is a programming model old as programming but its popularity gained traction only a couple of years ago. According to Wikipedia, it’s “a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data”. Or with simpler words, programs are written with functions, not classes and they don’t maintain state data in variables.

Benefits of FP are more predictable, readable, maintainable and testable code since it encourages you to write small functions with which you can easily omit storing data in extra variables.

I was doing FP last year only with JavaScript with conjunction with React (open-source library for creating UI from Facebook). The reason is that the two really play well together, with help of other utility libraries like recompose and ramda. I admit that I am still fresh in FP and still find it hard to use it when code is not strictly related to React. For example when coding custom business logic like form validation in FP style (i.e. like here).

But knowing the benefits of FP and some of its concepts (pure functions, function currying, partial applications, side effects, immutability, higher-order functions) counts for something, right? I’ve read learning FP takes time since it requires completely different mindset and it would be best if learner would know nothing about imperative programming.