higher order function

Scala: How to use higher-order functions with Option (instead of match expressions)

Table of Contents1 - Sample data2 - From match expressions to higher-order functions3 - Notes4 - Resources5 - Comments

I originally wrote a long introduction to this article about Scala Options, but I decided to keep that introduction for a future second article in this series. For this article I’ll just say:

  • idiomatic Scala code involves never using null values
  • because you never use nulls, it’s important for you to become an expert at using Option, Some, and None
  • initially you may want to use match expressions to handle Option values
  • as you become more proficient with Scala and Options, you’ll find that match expressions tend to be verbose
  • becoming proficient with higher-order functions (HOFs) like map, filter, fold, and many others are the cure for that verbosity

This is a page from my book, Functional Programming, Simplified

How to Write Scala Functions That Take Functions as Input Parameters

“Haskell functions can take functions as parameters and return functions as return values. A function that does either of those is called a higher order function. Higher order functions aren’t just a part of the Haskell experience, they pretty much are the Haskell experience.”

From Learn You a Haskell for Great Good

What is “Functional Programming”?

Table of Contents1 - Defining “Functional Programming”2 - A working definition of “pure function”3 - Note 1: Higher-Order Functions are a great FP language feature4 - Note 2: Recursion is a by-product5 - Proof: Wikipedia’s FP definition6 - Proof: A wonderful quote from Mary Rose Cook7 - That’s great ... but why immutable values?8 - Summary9 - See also

Note: This is an excerpt from my forthcoming book on Scala and functional programming. (No one has review this text yet. All mistakes are definitely my own.)

Back to top

Defining “Functional Programming”

It’s surprisingly hard to find a consistent definition of functional programming. As just one example, some people say that functional programming (FP) is about writing pure functions — which is a good start — but then they add something else like, “The programming language must be lazy.” Really? Does a programming language really have to be lazy (non-strict) to be FP? (The correct answer is “no.”)

I share links to many definitions at the end of this lesson, but I think you can define FP with just two statements:

Higher order functions *are* the Haskell experience

This is a great way to put this: “Higher order functions aren’t just a part of the Haskell experience, the pretty much are the Haskell experience.”

(A “higher order function” is a function that can take a function as an input param, or returns a function as a return value.)

The quote and image come from this LYAHFGG page.