One of the core concepts that has driven my quest for knowledge about programming techniques has always been my own laziness. After all, what attracted me to computers back when I first started playing with them was the notion that they could do things for me. All I had to do was sit back and tell them what I wanted.
But I quickly learned that computers were very literal. Unless I told them exactly what I expected in explicit and unambiguous terms, using a language that they understood, they would rarely give me back what I had in mind. And being lazy, I didn’t want to work any harder than I had to, to express my intentions.
I started to look for ways to make coding easier and more fun. And that search led me directly to functional programming.
New Ways to Look at Problems
I was first introduced to functional programming when I was a senior front-end engineer working at a small start-up in San Francisco. One day, a programming wizard who labored deep in the bowels of the company’s research group heard me complaining about some of the messy state-dependent code I was working on, and lured me into a conference room with fancy promises. There, he proceeded to give me an impromptu three-hour introduction to Haskell, a classic functional programming language, including a cursory explanation of the philosophy of functional programming.
That promise kept me going as I started to dig into this exotic realm. I believed that functional programming techniques could offer me better ways to break a problem apart and solve it in tiny, focused bites. I was thrilled by the possibility that I could make my code cleaner, more portable, more manageable, more readable, and easier to maintain.