Procedural programming != functional programming

Posted at 15:22 on 12 November 2007

One thing that irks me a bit is when developers deride “functional programming” as something for complete n00bs and script kiddies who haven’t a clue about writing software.

The most common offenders seem to be some advanced PHP developers who know something (perhaps quite a lot) about object oriented programming, think it’s the greatest thing since sliced bread, consider themselves smart (with some justification) because a lot of developers simply don’t “get” OO and they do, and look down on what they call “functional” programming.

Now they’re mostly right, but they’ve got their terminology wrong. What they actually mean is procedural programming.

There is a big difference.

Procedural programming is where you view your code linearly, as a set of instructions to be executed one after the other. You write a series of instructions outlining what you want to do, extracting commonly used bits of it into procedures and functions. You think in terms of do this, do that, if-then-else, and so on. It’s useful for small quick-and-dirty scripts, it’s very easy to learn, and it’s the way that most people start off programming. It’s software development at the level that trendy designers in Brighton who do beautiful stuff with Flash and Photoshop can understand.

However, it gets a rough press from OO geeks, since more often than not you end up with things like copy-and-paste code, global variables all over the place colliding with each other, and functions with parameter lists that reach into double figures. And when your app reaches the size and complexity of, say, WordPress, it becomes pretty unpleasant to maintain.

Functional programming, on the other hand, is a bit closer to rocket science. Joel Spolsky describes functional paradigms as considerably harder than OO, and considers them a good discriminator between really brilliant developers and the unwashed masses, along with concepts such as pointers and recursion. Most of the trendy designers in Brighton would struggle with many of the concepts, and the real experts in functional programming tend to congregate in places such as NASA, Google and MIT, writing massively scalable search algorithms and the code that keeps the Mars rovers entertaining us with panoramas of the Red Planet.

It’s where functions take on a different nature altogether: they are first class objects, and you can pass them as parameters to other functions, or have them as return values. Differential calculus is one such example: you pass a function, such as y=x³, into the “differentiate” function, and it returns another function, y=3x².

It gives you useful and powerful features such as closures — where the function runs in the context of its scope as it was when it was created — or iterators (the yield statement) and it allows you to do very fancy things with very little code. Things that would require fancy design patterns such as Abstract Factory, Decorator and so on in classic OO, and even fancier hoops to jump through in merely procedural languages. It is used at a fairly basic but very effective level in jQuery, for example, which allows you to produce jaw-droppingly fancy Ajax-enabled websites with only a few lines of code. However, that is only scratching the surface: once you really get into it, you have to grapple with highfalutinalia such as fixed point computation, monads, and much more.

Perhaps I’m being a bit pedantic here — you tend to get that way a bit when you spend a lot of time coding — but the next time you are tempted to knock “functional programming” just bear in mind that by so doing, you are inadvertently dissing people who are a lot smarter than you.