If you’ve ever sat down and attempted to learn computer programming on your own, then you’re aware of the sheer amount of information available online. It can be a little overwhelming to sift through the many tutorials, opinion pieces, and online programming courses available today. If you don’t have a large amount of programming experience, it can be difficult to parse helpful information from the unhelpful, especially when it comes to an oft-misunderstood paradigm like functional programming.
The modern programmer needs to be versatile. It’s crucial to be able to adapt your programming style on the fly and be familiar with a broad range of programming applications and concepts if you want to work in the high-demand field of computer programming.
There’s a lot of misinformation and oversimplification out there surrounding functional programming and what sets it apart as a concept and programming approach. Here, we’ll discuss some of the applications for functional programming, as well as how it differs from other imperative-based programming paradigms. If you want to learn to program and remain competitive in the workforce, this is a great place to start.
Functional vs. Imperative Programming
Before you can gain an understanding of functional programming, it’s important to grasp how it differs from imperative, or procedural, programming. Most mainstream computer programming languages, especially object-oriented programming interfaces such as C#, Java, C++, and Visual Basic, are designed primarily to support imperative programming; when you think of computer programming in the general sense, you’re almost certainly thinking of imperative/procedural programming.
With imperative programming, each statement entered by the programmer modifies the state of the program. It’s the simplest concept of computer-programmer interfacing; the person behind the keyboard enters a series of commands to be carried out by the computer, much like the imperative mood in spoken language is used to delineate verbal commands. The statements as entered by the programmer are executed in sequence in order to reach a certain goal.
Object oriented imperative languages are beneficial when you’ve got a fixed set of operations on things, with new things added as the code evolves over time. New classes can be added that implement extant methods, without modifying any of the existing classes or commands.
To use the kitchen as a metaphor, a useful scenario for visualizing imperative programming would be to observe the operations of food preparation (bake, broil, sauté, microwave, refrigerate) as a fixed set of action circumstances into which new and disparate data (the food itself) can be entered over time. The operations don’t change much, but the things might; you might use a common ‘bake’ capability to make both a cake and a pizza, but the things involved in each process (ingredients, cook time) are different.
Functional programming, on the other hand, is used ideally when you have a fixed set of things and primarily add new operations as the code evolves. New functions can be added to work with existing data types, without modifying the existing functions. They excel when it comes to data manipulation in tree form and are widely used by compilers and others, due to the easily nested nature of the programs themselves.
A functional programming kitchen analogy would be akin to a personal chef who always prepares the same lasagna but in different kitchens—the things, in this case, ingredients (noodles, water, sauce, mushrooms, and parmesan), are relatively static, but the operations (bake, broil, grill, sauté) and their specifics vary greatly based on the kitchen.
Both approaches to programming have strengths and weaknesses. In the object-oriented imperative kitchen, it can be incredibly tedious and time-consuming to add a new operation (i.e., deep fry), as this often requires editing innumerable class definitions in order to make the new method workable. In the functional kitchen, where operations vary but ingredients often don’t, it can be extremely cumbersome to edit the function definitions and add a new ingredient (i.e., onions) to the recipe.
Anyone who wants to learn to program in today’s world would benefit from a solid understanding of the differences and similarities of these two types of programming. Object oriented imperative programming offers the programmer easy control over encapsulation, allowing control mutation of the internal state, and subtyping, which allows substitution of compatible types and implementation inheritance.
Functional programming, on the other hand, can allow substitution via the more general mechanism of type classes, where a mutable internal state is not desirable.
Languages and Definitions
Since its inception, functional programming has found more of a home in data management and academia than its imperative counterparts, which are considered more useful for commercial software development. That said, viewing imperative vs. functional programming as a zero sum, either/or scenario is not necessarily the best method by which to understand their differences and similarities.
While most programmers and online programming courses differentiate between imperative and functional programming based wholly on languages (“C++ is a purely imperative language, Common Lisp is a purely functional language), this is not an entirely accurate or helpful approach. ‘Functional’ and ‘imperative’ refer more to the style and philosophy behind a program’s construction and execution than the languages in which they are written.
For example, a functional programming style can be accomplished to great effect within languages that were not specifically designed for the paradigm. The Perl and PHP
languages, for instance, were both designed with imperative programming in mind but have been widely used to apply functional programming concepts.
Other imperative languages, such as C++11 and Java8, include constructs to facilitate a functional programming style. On the other hand, Scala, which is most frequently associated with the functional programming style, includes the presence of mutable state and side effects which are typically considered aspects of object-oriented languages.
The bottom line is, whether you’re using a programming language designed for imperative programming or one geared toward functional applications, it all comes down to the way you work as a programmer and how you build your programs. Imperative style programs and functional style programs are both only as good as the writing and organization behind them; if your build is sloppy, the end result will be sloppy regardless of which philosophy you adhere to.
Master your voice
If there’s one thing that a little research into functional programming makes clear, it’s that computer programming courses, and one-on-one instruction are crucial when it comes to developing and implementing new concepts. Wading through forums and comment threads to figure out a workaround for a newly encountered programming problem can derail your entire process and cause unnecessary frustration and work delays.
For programmers who are trying to stay on the ball and develop a solid grasp of both functional and imperative programming concepts, continuing education is important.