They tell you that you should learn a functional programming language because it will change how you think about code. What they don't tell you is how you'll be justifying your "crazy" ideas to your team members forever after that. How do you explain to someone that instead of writing a synchronized block you'd like to create 3 new classes and an interface to model an event stream with callbacks? Why on earth would you want to create an object to wrap potential nulls when an if-statement works just fine? If you haven't taken the plunge into functional yet, let me show you some of the ideas you'll bring back from your journey. If you're already a seasoned functional programmer, we can go over how to introduce the functional paradigms into our everyday work without scrapping it and rewriting the whole thing in OCaml.
Nathan Dotz is a Detroit-area software developer who has been a vocal advocate for functional programming since 2010, from international speaking engagements to badgering local user groups. He currently works for Detroit Labs, where his focus is on functional programming for the JVM and high-availability APIs and services for mobile clients.