This post is part of a series, if you haven’t seen the other posts in this series you can find them here:
- How to become a web developer that stands out from the crowd
- How to become a web developer. Part 2 : Larger projects
- How to become a web developer. Part 3 Object Oriented Design
- How to become a web developer. Part 4 Functional Programming
- How to become a web developer. part 5 : Web application architecture
Why you need to understand Functional Programming.
No, it’s not because Functional Programming will solve all your coding problems.
Functional Programming is just another tool in your arsenal. Some problems are easier to solve using Functional Programming techniques. Others are more suited to logical programming. Others are best done using OO.
The more tools you have the better programmer you will become.
In addition a number of languages with a stronger functional programming ethos have become popular over the last few years.
Some core Functional Programming concepts you need to understand
Just like OO there are a few core concepts you need to wrap your head around. I have deliberately left out some of the more advanced concepts from this post (Monads, Homoiconicity, Lazy Evaluation, Currying, etc).
If you are serious about your functional programming journey it really is worth spending the time to understand all of these.
Although it’s probably the least practical of the languages mentioned above Haskell is the purist functional language in the group. If you are serious about getting to grips with functional programming then check out the fantastic “Learn you a Haskell for Great Good!” guide.
A closure is a function called in one context that remembers the variables from the environment in which it was defined. Multiple closures defined within the same context remember that same context, so changes they make are shared between them. Every time a function is called that creates closures, a new, shared context is created for the new closures.
In essence you can think of it as a pairing between a piece of code (the function) and a scope (the scope available at the point of definition). When you pass the function along to other parts of your program, the scope travels along with it.
Higher order functions
Higher order functions are functions that do one of two things.
- Take a function as input
- Return a function as output
If you come from a language without functional programming features this can seem a little strange at first. It is one of the most useful concepts to wrap your head around though.
If you are familiar with the command pattern in the OO world you already have a taste of what this allows you to do. Often the command pattern is just a workaround for not being able to take a function as an input parameter.
Returning a function is slightly less common but no less useful. For an excellent example of this in use have a look at how scales are implemented in d3.js.
Function composition is the act of composing multiple simple functions to create a more complex result. You can compare it to the way the unix command line works. Lots of small simple programs can be combined using the | command to feed the output from one application to the input of another.
A function can be considered to have a side effect when in addition to returning a value it also get’s input from or modifies another part of the program or the outside world.
Some examples of side effects include:
- modifying a global variable or static variable
- modifying one of the functions arguments
- raising an exception
- writing data to a display or file
- reading data from a file or database
- calling other side-effecting functions
You should be very aware of when your functions produce side effects. Side effects make the behavior of your application harder to predict and control. The same function called twice might produce wildly different results.
Pure functional languages don’t allow any side effects in functions, instead all side effects are pushed into a monad. Don’t worry you don’t need to understand monads just yet, but they aren’t that scary. If you are interested there is a great talk by Brian Beckman that does a good job of explaining monads:
For now just be aware of side effects and try limit side effects to as few areas of your code as possible.
Functional programming is a large topic and learning it can feel like a brain melting task at times. Especially if you come from an imperative/OO background. Just bear in mind that learning OO in the beginning was just as hard, it seems easy and logical once you have spent thousands of hours practicing it. The same goes for functional programming.
Keep at it, it’s worth it in the long run.