Functionally PragmaticPublished on 2012-11-03 23:15:46 +0000
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.