The split between the ‘recipe-makers’ and the equation-crafters has begun to be bridged

ONE IMAGINES that progress in the world of computers moves with lightning speed. The competition to come up with new features, combined with the apparently rapid adoption of the latest technology, ensures ideas tumble from the research lab into the marketplace as fast as possible. Right?

In fact, academics in the world of computer science complain that practitioners are often not only missing the latest advances in the field, but ignoring innovations that are decades old.

Historically, the best example is the graphical user interface (GUI), which was developed at Stanford and Xerox Parc in the late Sixties and early Seventies, but took more than 10 years to appear in the mainstream market.

It gets worse when you consider the techniques the creators of computer software use. Object-oriented programming spread through academia at the same time as GUI development, but only took off within the coding world in the Nineties.

But perhaps the longest gestation period for a good idea has been what’s called “functional programming”, a stalwart of academic thinking almost since the first theories of how computers should be programming emerged.

Only now, more than 50 years later, has it gathered much popular appeal. If it takes off, the benefits will be programs that can more easily take advantage of all the computer power modern systems provide, either across networks or just within a single desktop or smartphone. The programs will also, in theory, be easier to test or even conclusively prove as being bugfree.

The potential road block is the words “in theory”. Some ideas may take too long to take off, but others never make it from academic research to the real world for very good reason.

Functional programming represents a profoundly different way of programming than current practices, and one perhaps closer to the way mathematicians and theorists think than our software engineers do. If it is to become popular, it will require not only that its practitioners can apply their ideas to real world problems, but that a whole industry can wrap its head around profound changes in the way they work.

To give a vague idea of the difference between functional programming and the current norms of programming, think of a cooking recipe. When a coder builds software in conventional programming, he or she is usually writing a recipe for the computer: a set of instructions to be followed, one step at a time, in chronological order. Add some flour, mix in an egg . . .

Now think of an equation. A long equation, the kind you see scribbled on a blackboard behind someone in a movie who is being clumsily depicted as some kind of mathematical genius. Functional programming is more like composing one of those equations. A lot can go into it, and when you calculate an equation like that, you have a lot of choices in what chronological order you add things up. But hopefully, however you do it, you’ll end up with the same result.

It’s obvious with a recipe what you’re making, and how far along you are. It’s not obvious, however, that you’re really following the instructions correctly, because they may be vague or ambiguous. With an equation, there’s only one right answer but it’s not entirely clear how you build an equation for a delicious cake without being a parody of a movie genius.

This is how it’s been between academic computer scientists and real world programmers for some time. Academics want computers to be programmed with extremely long equations; real programmers want cake – or at least, their programs to do something in the real world, like run a spreadsheet or play a game. Recently, though, the split between the recipe-makers (who use a style called imperative programming) and the equation-crafters (who use functional programming) has begun to be bridged. Functional programming languages, such as Haskell and the Microsoft-supported F#, have started to be used in practical applications. More importantly, a generation of new programmers are graduating from university with a sense that the theoretical constructions they’ve been taught aren’t just for class. It’s a small nod, but just the fact one of the most successful entrepreneurial start-up incubators in the US, “Y-Combinator”, is named after an element of the underlying mathematics of functional programming, should be an indicator.

Functional programming is more than just esoteric; it’s becoming somewhat cool.

Whether fashion is enough to catapult functional programming out of the ivory towers and into the trenches of commercial programming is unclear. It’s still true that most coders think, at best, like engineers rather than mathematicians. Most of them don’t have time to think in pure logic, when they’re struggling with the million other small irritations that surround coding: from misspelled commands to flaky internet connections.

But the academics have been wrong in the short-term, and right in the long-term before. Perhaps, one day, programming computers will be more a question of getting the maths right once than throwing together the ingredients every time and hoping that, today, nothing gets burnt.