Forcing FP on New Developers in a New Company

“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.”


Target Audience




schedule Submitted 1 year ago