Forcing FP on New Developers in a New Company
YOW! Lambda Jam 2013
“Starting a new company or a new major project can be a great time to start fresh with FP. Unfortunately starting is often the hardest time to take on anything novel (other than of course, the product itself!) due to perceived additional risk. The reality, however, is that systems will be built quickly, thrown away, re built, hacked on, abused and more. One of the nice side effects of FP (pun intended) is that programs are often brief – you don’t feel as bad throwing them away! At CloudBees we ended up with a mix of Scala and Erlang, with some Clojure thrown in. Almost none of this was by design (from acquisitions and mergers), but has worked out well. The biggest enabler of this has been the proliferation of micro services – at their core, service endpoints can often be thought of a functions – and if the functions are kept pure – then that allows these services to be composed (far more so than if impure) into other services in novel ways. We have also experienced benefits of shedding object oriented ideas in favour of the rigour decomposing something into sensibly named and small functions, with fewer places for state to hide. This talk will go through some of our experiences and systems, including how developers new to FP were able to pick up the smaller systems and run with them over time, and how FP ””risk”” is minimal compared to all the things that can and do go wrong elsewhere.”
Michael is a co-founder of CloudBees, and as such was able to abuse his good fortune and use FP in production (often as root!). Prior to his time at CloudBees he was at Red Hat, where he worked on the open source rule engine unfortunately named (but popularly named) “drools”. For some time he has been an advocate of FP languages and techniques, and in fact was taught functional programming before any other style of programming. You can see his open source work at https://github.com/michaelneale – best described as “polyglot”.