Blogs
Highlights
Categories
Tags
Analytics Big Data Bring your own device Business Business Models Cloud Computing Collaboration Command and Control Consumerization Data Delivery Models eCar Economy Enterprise Architecture Facebook help desk Innovation Internet IT Leadership IT Management IT Operations J2016 Journey 2014 London 2012 Media Mobile Mobile Payments Mobility Multi-sided Markets New Media NoSQL Open Innovation Organizational Change Payments Product Lifecycle Management Security Smart Mobility Smarter organizations Social Media Social Networks Social Organization Sustainability Sustainability Tracks Trends Video Vision White Papers Working Environment Workplace
The rise of Functional Programming
June 7th, 2012 Thierry Caminel Tags: Development, Trends
Posted in Technology |
For many of us, Functional Programming (FP) is related to some boring computer science courses about lambda calculus and strange programming language like Lisp, Haskell or OCaml, used only by academic people and not by real programmers, who obviously use C or Java.
But FP is one of the hidden key concepts behind the “big data” revolution. It probably became mainstream when Google described, in their 2004 seminal paper[1], MapReduce as an “abstraction inspired by the map and reduce primitives present in Lisp and many other functional languages”. Now Twitter, LinkedIn, Akamai, TomTom, Erickson and others use modern functional languages such as Clojure (a Lisp dialect), Scala (a combination of Java and FP) or Erlang (a distant descendant of Prolog).
The main reason is that FP facilitates distributed programming. In FP, functions, not objects or procedures, are the fundamental building blocks of programs: whereas object programming put emphasis on object composition, FP put it on composition of functions. Functions can be combined, sent remotely, applied locally on distributed data sets, and that is the main paradigm shift of “big data”. By eliminating side-effects and mutable variables and facilitating code distribution over several CPU, FP eases concurrent programming, a topic more and more important as the number of CPU core increases. FP makes also easier the development of internal Domain Specific Languages (DSL), these little languages embedded into applications simplifying the maintenance of business logic and improving programmer’s productivity.
Obviously FP will not replace imperative programming, first because few developers have to deal with scalability concerns or DSL development, and because tooling will tend to hide complexity of concurrent and distributed programming, through libraries or language evolution (for example, Java 8 will introduce lambda expressions). FP principles are also behind some widespread languages like SQL or XSLT, so most programmers already do some kind of FP but haven’t realized it. JavaScript also allows FP, and interestingly recent and popular libraries emphases this aspect for example to ease HTML DOM tree manipulation (jquery [2]).
Anyway it might be a good idea that software developers have explicit knowledge of principles of FP in order to write better code, such as avoiding side effects and instances variables, using immutable data structures, combining functions to be applied to objects. These skills might become more and more important in the future as FP patterns will spread.
So if during your next job interview the candidate appears to know what a monad is [2], you might consider hiring him with confidence for your next-generation framework.
[1] J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In OSDI’04, 6th Symposium on Operating Systems Design and Implementation, Sponsored by USENIX, in cooperation with ACM SIGOPS, pages 137–150, 2004.
[2] http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/.



Another use case for functional programming (languages) is writing programs where security and correctness are more important than speed of writing (and, partially, execution speed; but especially Haskell can be blazingly fast if used correctly – see Bryan O’Sullivan – Fast Code Nation). In FPLs, the compiler can warn you about any unhandled cases, and some languages will even give you warnings (or errors) for non-terminating programs. With stronger type systems, you can go even further and put the specification of your program into the types.
Given that hacking is mostly finding un-/ill-handled inputs – or, rephrased, programming the bugs and reachable code blocks to do something unintended – this can be very helpful for writing secure programs. If viewing any input as a programmable language is helpful for thinking about hacking, then it’s probably useful as well for securing things. Look at LANGSEC and their short intro for more on that (language-independent – you should read that even if you don’t care about FP).
For those of you who want to know what’s possible with (research) languages, go take a look at Compcert, a C compiler that has ben proven to be correct, i.e. not modifying the program’s meaning while compiling/optimizing. Also, the first half of this talk (implementing a toy language with numbers and addition) is reasonably comprehensible if you know a bit of FP and/or Haskell: Conor McBride – Agda-curious?