Advantages of Functional Programming

Hi! I’m Catherine, and I’m very fond of functional programming; I use functional language on an everyday basis, and even do a bit of teaching. Here at Typeable, we use Haskell as the main development language and, while everyone else was disputing whether Haskell is ready for production, we just used it and regarded this as a competitive advantage. Based on this experience, we would like to share our opinions.

How FP Improves Programming

At present, functional programming is rather popular, and many imperative languages are adopting some FP concepts such as lambda functions, partial application (currying) and higher-order functions (map, filter, folding). Some of the adoptions blend seamlessly, but some make the syntax look rather weird and foreign. Nevertheless, a programming paradigm is an approach that exists in the programmer’s mind, and is generally not part of the language itself. To some extent, any language supports different paradigms, and its structures allow developing software in various styles. The question of whether it makes sense to develop software in the functional style can’t be answered easily, and each developer will answer it based on their preferences, capabilities of the language, and other considerations. We believe that using the functional style in imperative languages or, better still, the functional language, especially in combination with static typing, will help to improve many aspects of the code, namely:

1. The code will become more concise and expressive. Expressiveness can be defined as the number of ideas per code unit and, in general, functional languages (as high-level languages) also prove to be more expressive. For example, adjusting each element in an array or list is implemented by a functional one-liner (using map/foreach/whatever, and an anonymous function), whereas the imperative style would require organizing a cycle, declaring a variable for the counter or iterator, and using explicit assignments. The difference in expressiveness is even more obvious in more complex examples.
2. The code will be decomposed more naturally. The “divide-and-rule” principle has been used in software development for a long time and serves as the basic principle of software complexity management. I’m talking not about the algorithm design method, but about a more general concept. For instance, even a simple program that reads the whole input text first, breaks it down into words, and performs some operations on each word, can be decomposed into logical parts – the reading itself, breaking the text down into words (for example, by spaces) and creating a structure used to store the words, traversing this structure including mapping the words, and results printout. Each of these actions can be implemented separately and in a rather abstract way so that they can be reused to solve other similar tasks. The code decomposition into smaller and more general parts makes the code much clearer (also for the author, in the future), prevents “copy-paste errors”, and simplifies subsequent refactoring. I’m sure a lot of developers have occasionally had to plow their way through their own or someone else’s wallpapers of unstructured code that was written in a hurry, just to make the software work. It is difficult for the human brain to fix its attention on a large number of entities at one time and simultaneously solve a global problem (working memory), which is why it is quite natural for us to break problems down into smaller tasks, solve them individually, and combine the results. In functional programming, these small tasks are expressed as minor auxiliary functions, each doing its job which can be described in one short sentence. The final result is the composition of these functions. Of course, it is also possible to split the code into separate, reusable segments in OOP and in a purely imperative low-level language such as C (using well-known principles such as SOLID and GoF patterns), but if the language makes the developer think in terms of functions, the code is decomposed much more naturally.
3. Side effects will be separated from pure functions. A pure function is a function in the mathematical sense; the result of its operation depends only on the input data. Evaluation of such a function involves nothing beyond the essential – variable values do not change, nothing is read or printed, no DB entries are made, and no requests to external services are issued. Indeed, you wouldn’t expect such operations, say, of trigonometric functions, would you? The major portion of data processing logic could be implemented using pure functions. Not all languages allow you to control the absence of side effects and check the function “purity”, but the functional approach by itself motivates the use of pure functions, without any “surprises”.
4. It will be easier to debug and test the code. This point stems from the previous two items: we have a number of small functions of which some are pure, i.e. we know that their result depends only on the input data. The code debugging becomes easier as it is only needed to check the result returned by the functions taken separately to understand the way they will work together. Unit tests for the “pure” logic of your application are written in the same unsophisticated way.

How FP Improves the Developer

Additionally, I’d like to share my experience not directly related to writing programs in functional languages, and tell you how the knowledge and application of FP turned out to be useful for me, and can be of use to you.

1. Learning an alternative paradigm is, in itself, useful for the brain. While you are mastering the functional style, you will learn to take a fresh look at familiar things. Some people will find this way of thinking much more natural than the imperative one. We can argue at length about what is “useful” and “useless” in industrial programming but, anyway, you need a clear mind, which needs training. Master the languages you don’t use in your work: LISP, Prolog, Haskell, Brainfuck, Piet. This will help broaden your mind and can become a fascinating brain-teaser. With time, you will be able to use more elegant functional-style solutions, even if you write programs in an imperative language.
2. Functional languages are underpinned by a serious theory, which can also become a part of your passions or even research, if you are eager to cast your lot, to a greater or lesser degree, with computer science. It’s never too late to learn, especially when you have clear illustrations of how a fairly amusing theory can be used to solve everyday tasks. I’d never have thought that, after graduating from university, I would be watching lectures on category theory (which my brain once failed to comprehend) and scrawling solutions to problems on paper, just because I found it interesting.
3. In addition to broadening your mind, an interest in FP will also help you expand your social network. The “functional community” has apparently earned its reputation as academic snobs who ask you to define “monad” before continuing the conversation. I also used to think this way until I was convoyed to my first few functional meetups and conferences. I was a novice junior and didn’t know the definition of a monad, but I never faced negative treatment. On the contrary, I got to know interesting people who were passionate about their work and eager to discuss, share their experience, and explain. Sure enough, any community consists of widely different individuals; you will like some of them very much, and find others toxic and repulsive, and this is perfectly normal. The fact that it will become possible for you to exchange ideas with those who view the development world from a slightly different perspective, and have a different experience, is of much greater importance.
4. The least expected point for me was that jobs requiring knowledge of Haskell were the easiest to find! As of today, I have a little over five years work experience, and, in two companies out of three places of employment, I used Haskell, which was the most comfortable and painless employment experience I could imagine. Moreover, I started off as a Haskell developer and I’ve never regretted this. My first job gave me the basic skills of client-server architecture development and working with DB. We used to solve the same “down-to-earth” and “unscientific” tasks as companies using more widespread languages. Most probably, your “Haskell developer” query on popular job sites will yield you almost no responses. At best, you will find vacancies indicating that the knowledge of alternative paradigms is an “advantage”. However, this doesn’t mean that such positions don’t exist. Vacancies appear occasionally on social media. Yes, they are few and you need to know where to search, but good specialists in this area are also few in number. Surely, you won’t be hired right away and anywhere you like, but you will sense your employability much sooner than when searching for jobs requiring more popular languages. Likely, companies might be ready to invest in developers’ training in the discipline they require: if you cannot find a Haskell programmer, train one in-house!

Conclusion

Adoption of FP elements in popular industrial development languages such as Python, C++, Kotlin, Swift, and others confirms the usefulness and strong features of this approach. The functional style allows obtaining a more reliable code that is easier to decompose, generalize, and test, irrespective of the programming language. Of course, a functional language makes it possible to make full use of all the above-mentioned advantages, producing native structures with a high degree of expressiveness. Though there are a lot of functional languages out there, we believe that, for the time being, the ones using static typing are the most convenient and useful for development. They facilitate detecting most of the errors during compilation and expressing a part of the application logic at the type level.

As the final point, I’d like to encourage you to use alternative approaches and try them out in practice, even if this is useful merely in terms of your own self-improvement.