In the previous installment of this series on becoming a web developer, we looked at the core Object Oriented Design principles you need to understand. Today, we delve into some Functional Programming.
If you haven’t seen the previous posts in this series, you can find them here:
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.
Having said that, there has been a tremendous resurgence in Functional Programming over the last few years. Many programming languages are a hybrid of OO/FP (Like JavaScript and C#) so understanding functional programming will make you a better programmer in those languages.
In addition, a number of languages with a stronger functional programming ethos have become popular over the last few years.
Languages like:
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.
For now, I am going to focus on the easier to grasp concepts that are found in most hybrid languages like JavaScript. The aim is to get you the most bang for your buck.
Closures
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.
For an in depth explanation of closures using JavaScript examples, check out this post.
Higher Order Functions
Higher order functions are functions that do one of two things.
They either:
- 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
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.
Some functional languages have first class support for function composition (with . in Haskell and >> in F# for example) other languages like Javascript don’t have first class support but have libraries that add it (underscore.js chaining).
Side Effects
A function can be considered to have a side effect when in addition to returning a value, it also gets 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 to limit side effects to as few areas of your code as possible.
Functional Programming in JavaScript
Now that we have covered the basics, let's look at how best to start using these concepts in JavaScript. I am picking JavaScript as it’s a language you have to know as a web developer regardless of which backend framework or language you use.
My go to library for making functional programming easier in JavaScript is underscore.js, there are other options and underscore has its quirks but it is widely supported, easy to get to grips with and has excellent documentation.
The documentation at underscorejs.org is a good place to start but if you prefer a tutorial, have a look at “Getting cozy with underscore.js“.
Conclusion
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.
The post How to become a web developer. Part 4: Functional Programming appeared first on Aesthetic IO.
Since I was young I always preferred teaching myself to learning from a structured syllabus.
This didn’t always make me popular with my teachers. I guess sleeping through the whole of Romeo and Juliet in an English class doesn’t make a great impression. On the other hand I formed an obsession with always researching something.
Over the years these obsessions would jump from topic to topic ranging from physics to lean manufacturing. Photography to functional programming. Cognition to physiology and strength training. Kitesurfing to fire poi. My obsessions may be random but are always led by my curiosity.
Over time I noticed that I was forming connections and finding patterns in unrelated fields and using knowledge I gained from studying the rudiments of things like cognitive psychology when trying to figure out why I was seeing certain behaviours in the teams I was working in.
I'm interested in communicating those underlying principles and connections in a way that is useful to others.
I have been working as a programmer, architect and manager for the last 12 years so there is a strong bias to helping junior programmers and software development teams improve.
I focus on underlying principles and not technologies.
Submit an article or tip
