A Paradigm Shift

This entry is part 1 of 5 in the series Towards Functional Programming

I started out, like most programmers do, writing imperative code. In recent years, however, I have begun to understand the power of functional programming. By understanding the thinking from a different programming paradigm you can become a better developer, even if you don’t switch to a different language or framework. You can use functional programming techniques in C# or Java, and properly applied, they are sure to improve the quality of your code! This series of posts tries to explain why anyone would want to take a closer look at functional programming.

In the Beginning was the Code

The Emperor of the Imperative EmpireI first learned programming in BASIC on the Apple IIc in the mid eighties. Incidentally it was Microsoft that supplied BASIC for a majority of the popular home computers of the seventies and eighties, including both the Apple II and the C64, and it was selling licenses for Microsoft BASIC that made Bill Gates his first gazillons.

After many years of doing BASIC I then learned a couple of other languages, including C and some Pascal. I also tried to learn C++ on my own, but didn’t get it until at university when I was taught object oriented design and development. I also learned a bit of Java. When I was employed I learnt Visual Basic and later C#.

… and the Code was Imperative

Superficially these languages are rather different from each other, but the common denominator for all these languages is that they are all imperative languages! “Imperative” comes from the Latin word for “to command” and this means that programs are constructed by setting up an initial state (a collection of variables with known values) and then executing a sequence of statements that manipulate the program state.   

A simple example would be calculating the sum of an integer array, which looks basically the same in any of these languages.

int sum = 0;
for(int i = 0; i < values.Length; i++)
    sum = sum + values[i];

Here, the program state is contained in the two variables sum (keeping track of the running sum) and i (keeping track of the current iteration index). Both of these are initialized to zero, and then updated in each iteration of the loop. The three different statements are clearly imperative (since they order the computer “Do that”, “Change this”), and modifying state:

  • declaration, allocating (and initializing) a variable
  • iteration, the for statement explicitly manages the iteration, allocating, initializing and updating the iteration index as well as checking the termination condition before each iteration
  • assignment, which change the assigned variable

Computer Hardware is Imperative

Most programming languages are imperative, because this is an abstraction that closely models the way the computer hardware works, where executing (imperative) machine code instructions changes the state of the machine (such as the CPU registers or memory contents).

Object oriented languages like C++, C# and Java improve this model by encouraging encapsulating and protecting most state inside objects instead of using a global scope, but are nevertheless imperative in nature, as they all emphasize changes in state. Indeed the point of most instance methods are modifying (or exposing) the object’s internal state.

Introducing Functional Programming

The all-powerful Lambda

However, a few years ago I decided it was time to look at an entirely different class of languages, namely functional languages. Now, I’m not talking about functional as in if something works or not. The term “functional” is used because  of the emphasis on application of “mathematical functions”, instead of changes in state. I’ll explain some of the important differences between imperative and functional programming in a later post. The rest of this post is aimed at helping you understand why it could be interesting to know more about functional programming.

Higher productivity and quality

I had read articles like Why Functional Programming Matters, Beating the Averages and Lisp as an Alternative to Java, which all claim you can get higher productivity and quality using functional programming. Statements such as [functional programming] is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days from How To Become A Hacker was also intriguing.

All this made me interested in functional programming (or “FP” for short), but did not really help learning how or where I could apply FP techniques without learning a whole new language. It was still also unclear to me as what FP was all about, exactly. I just didn’t get it.

My curiosity was further prompted by discussions on FP with Adam Petersen, who I had the pleasure of working with for a few months when I was doing a consulting job using C++. I was looking at the usage of the C++ STL and boost libraries in the existing code base, and even though I knew C++ well (or so I thought) I still could not fully understand some of the impossibly terse and elegant code that Adam put out, much less write code like it, as it seemed to require a different way of thinking. It was not that it did something I couldn’t have written, but I would have written the same thing much differently, using at least three times the number of lines of code, in a manner that felt clumsy in comparison. Adam, of course, used functional programming techniques in C++.

No Assembly Required

I was at this point certainly interested in “getting” functional programming, as it now seemed clear it was worthwhile to learn, and useful even when not actually programming in a FP language. However, learning FP would not prove very easy! Learning the syntax of a new language is easy, learning a different way of thinking is much harder. I basically had to rewire the programming patterns etched into my brain by 25 years of imperative thinking, and learn new problem solving techniques using a fundamentally different way of thinking. My first attempts in using functional languages had a heavy imperative accent.

However, don’t start thinking that this FP stuff is much too hard, or that you will have to spend years and years until you finally get it. Yes, doing a cold turkey switch to a FP language without a mentor would probably be abysmal for your productivity, but the good news is that it is entirely possible to benefit from FP in smaller chunks than what I tried to bite off, and that you can get clear benefits from using FP within the comfort of your primary programming language (especially C#).

In the next post I’ll try to elaborate on what it is, exactly, that makes functional programming so powerful, compared to imperative programming.

Series NavigationA Functional Language >>

Leave a Reply

Close Menu