functional programming

Scala idiom: Prefer immutable code (immutable data structures)

(I originally wrote this blog post in 2012, and it seems like it has held up well over time.)

One great thing I’ve learned from Scala and functional programming over the last few months is this: 

Make your variables immutable, unless there’s a good reason not to.

“Immutable” means that you can’t change (mutate) your variables; you mark them as final in Java, or use the val keyword in Scala. More important than you not changing your variables is that other programmers can’t change your variables, and you can’t change theirs.

Books are an investment, not an expense

I’m surprised when people complain about the price of a book like Functional Programming, Simplified. First, it’s less expensive than most other books on functional programming. Second, it’s a big book that took me nearly two years to research and write.

Third — and most importantly — I’ve invested thousands of dollars in books, training classes, and conferences to make myself a better programmer. I truly think of a good book as an investment in knowledge and my career, not an expense. Shoot, I once read one book that helped me start a multi-million dollar consulting business.

What’s the easiest way to learn functional programming?

People occasionally ask me, “What’s the easiest way to learn functional programming?” If you look at all of the books on the right side of this image, I can tell you that reading all of those books wasn’t an easy way to learn functional programming (FP):

IMHO there’s a much easier way to learn the FP basics: I’ve made almost 40% of my book, Functional Programming, Simplified, freely available.

Functional error handling in Scala

Because functional programming is like algebra, there are no null values or exceptions. But of course you can still have exceptions when you try to access servers that are down or files that are missing, so what can you do? This lesson demonstrates the techniques of functional error handling in Scala.