The Definition of Functional Programming

The definition of functional programming is relatively easy. Functional programming is programming with mathematical functions. Is that all? Of course, not!

Mathematical functions

Functional programming is programming with mathematical functions.  I think you already guess it. The key to this definition is the mathematical expression function. Mathematical functions are functions that return every time the same result when given the same arguments. They behave like an infinite big lookup table.

Referential transparency

Referential transparency is the property that a function (expression) always returns the same result when given the same arguments. Referential transparency has far-reaching consequences:

• Mathematical functions can not have a side effect and can, therefore, not change the state outside the function body.
• The function call can be replaced with its result but reordered or put on a different thread.
• The program flow is defined by the data dependencies and not by the sequence of instructions.
• Mathematical functions are much easier to refactor and test because you can reason about the function in isolation.

That sounds very promising. But with so many advantages, there is a massive restriction. Mathematical functions can not talk to the outside world. Examples?

Mathematical functions can’t

• get user input or read from files.
• write to the console or into a file.
• return random numbers or time points because the return values are different.
• build a state.

Thanks to mathematical functions, the definition of functional is concise but does not help so much. The critical question remains. How can you program something useful with functional programming? Mathematical functions are like islands that have no communication with the outside world. Or to say it in the words of  Simon Peyton Jones, one of the fathers of Haskell. The only effect that mathematical functions can have is to warm up your room.

Now, I will be a little bit more elaborated. What are the characteristics of functional programming languages?

Characteristics of functional programming languages

Haskell will significantly help me on my tour through the characteristics of functional programming.

Haskell

There are two reasons for using Haskell.

1. Haskell is a purely functional programming language, and therefore you can study very well the characteristics of functional programming by using Haskell.
2. Haskell may be the most influential programming language of the last 10 – 15 years.

My second statement needs proof. I will provide them in the next post for Python and C++. Therefore, here are a few words about Java, Scala, and C#.

• Philip Wadler, another father of  Haskell, was one of the implementors of generics in Java.
• Martin Odersky, the father of Scala, who adapted a lot from Haskell, was also involved in implementing generics in Java.
• Erik Meijer is a passionate admirer and researcher around Haskell. He used the Haskell concepts of monads and created the well-known C# library LINQ.

I will even go one step further. Who knows functional programming, and in particular Haskell, knows how the mainstream programming languages will develop in the following years? Even a pure object-oriented language like Java can not withstand the pressure of functional ideas. Java now has generics and lambda expressions.

But now, back to my subject. What are the characteristics of functional programming languages?

Characteristics

In my search for functional characteristics, I identified seven typical properties. These must not be all characteristics, and each functional programming language has not supported them. However, the characteristics help to bring meat to the abstract definition of functional programming.

The graphic outlines the characteristics of functional programming and my next posts. I will provide many examples in Haskell, C++, and Python. But what do the seven characteristics mean?

First-class Functions are typical for functional programming languages. These functions can accept functions as argument or return functions. Therefore, the functions have to be higher-order functions. That means they behave like data.  Pure functions always return the same result when given the same arguments and can not have a side effect. They are the reason that Haskell is called a pure functional language. A purely functional language has only immutable data. That means they can not have a while or for loop based on a counter. Instead of the loops, they use recursion. The essential characteristic of functional programming is that you can easily compose functions. This is because of their bread-and-butter data structure list. If an expression evaluates its arguments immediately, it’s called greedy or eager evaluation. If the expression evaluates the arguments only if needed, it’s called lazy evaluation. Lazy evaluation will reduce time and memory if the evaluated expression is unnecessary. I think you already guessed it. Classical programming languages are greedy. They evaluate their expressions immediately.

What’s next?

In my next post, I will start with first-class functions, which we have had since the beginning of C++.

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery,and Matt Godbolt.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS

Seminars

I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

• C++ – The Core Language
• C++ – The Standard Library
• C++ – Compact
• C++11 and C++14
• Concurrency with Modern C++
• Design Pattern and Architectural Pattern with C++
• Embedded Programming with Modern C++
• Generic Programming (Templates) with C++
• Clean Code with Modern C++
• C++20

Contact Me

• Mobil: +49 176 5506 5086
• Mail: schulung@ModernesCpp.de
• German Seminar Page: www.ModernesCpp.de
• Mentoring Page: www.ModernesCpp.org

Modernes C++ Mentoring,