Functionally Pragmatic

| Comments | conferences, featured

Michael Brunton-Spall by Adewale Oshineye
Michael Brunton-Spall by Adewale Oshineye

I was lucky enough to give the keynote at FP Days Cambridge last week, where I was able to wax enthusiastically about functional programming and the future of software development.

The slides themselves are up on SpeakerDeck, and there’s a video that will be coming out in a few months.  In the meantime here’s a very brief overview of my thoughts.

One of my concerns when I was asked, was that I felt that the functional community can be a little over focused on the academic.  This isn’t actually necessarily true, but because it’s a preconceived notion for myself (and other developers), it can be difficult to break.

My talk was therefore aimed at talking about how functional languages have a role as pragmatic languages, what that actually means, and why it’s important.


Before we can define what being pragmatic means to functional languages, we need to work out what pragmatic actually means.

I believe that Pragmatism is about being very short termed, very results focused and caring about simplicity.  Pragmatism can be summed up by a few choice slogans, “Released Code > Perfect Code” and ”Move fast and break stuff”.

Functional languages have a bad reputation for being the result of too much academia over pragmatism, terms like Applicative Functor, Currying and of course Monads mean that your average web developer gets turned off straight away and goes back to using Python, Ruby or PHP, where they can just get stuff done.

But languages such as Clojure, Scala have a number of features that can really help your pragmatic coding.  Features like Immutability, no null values and functional building blocks like map, filter and so forth all lead to significantly more readable code.

These features all lead towards fewer lines of code, and a clarity of intent on each line, which helps to make the code far more maintainable.  When you come back to any given bit of code it will be far clearer what you intended to do at the time, and the code is more localised into a small readable area.

If this interests you I suggest you try Scala or Clojure on something like AppEngine or Heroku and take it for a spin.