When you get started with functional programming (FP) a common question you’ll have is, “What is an effect in functional programming?” You’ll hear advanced FPers use the words effects and effectful, but it can be hard to find a definition of what these terms mean.
I always find it confusing when people claim that the IO monad somehow makes an impure function pure. Frankly, I think that argument does a confusing disservice to people who are trying to learn functional programming (FP).
“The fact that #scala Future is not lazy just blows my mind. After years of using Scalaz Task, Future is now totally unusable.”
The last part of that tweet is a bit of hyperbole to me, as I’ve been using the Scala Future for a long time myself, and I’ve had no problems using it. That being said, the examples at the top of the Reddit page were interesting, so I decided to try to understand the differences.
Some advanced Lispers will cringe when someone says that a function “returns a value.” This is because Lisp derives from something called lambda calculus, which is a fundamental programming-like algebra developed by Alonzo Church.
“In Haskell, a function’s type declaration tells you a whole lot about the function, due to the very strong type system.”
One thing you’ll find in FP is that the signatures of pure functions tell you a lot about what those functions do. In fact, it turns out that the signatures of functions in FP applications are much more important than they are in OOP applications. As you’ll see in this lesson:
“When a function is pure,
we say that ‘output depends (only) on input.’”
This lesson has two goals:
“They say no ship can survive this.”
A short excursion to ... The Twilight Zone
Hello, Rod Serling of The Twilight Zone here. Al will be back shortly, but for now, let me take you to another place and time ... an alternate universe ...
“Object-oriented programming makes code understandable by encapsulating moving parts. Functional programming makes code understandable by minimizing moving parts.”
“Learn the rules like a pro, so you can
break them like an artist.”
“Learn the rules, and then forget them.”
Haiku Master Matsuo Basho
Alright, that’s enough of the “preface” material, let’s get on with the book!
As I wrote earlier, I want to spare you the route I took of, “You Have to Learn Haskell to Learn Scala/FP,” but, I need to say that I did learn a valuable lesson by taking that route:
“I have no special talent. I am only passionately curious.”
A Golden Rule of this book is to always ask, “Why?” By this I mean that you should question everything I present. Ask yourself, “Why is this FP approach better than what I do in my OOP code?” To help develop this spirit, let’s take a little look at what FP is, and then see what questions we might have about it.