Functional Scala: High, Higher, Higher Order Functions. Welcome to the sixth episode of Functional Scala!
This time, we’ll finally dive into one of the most powerful concepts i consistently referred to again and again within almost every previous part of this series: Higher Order Functions. Isn’t that cool? I know it’s not, since a cool name alone can’t set you on fire. I will demonstrate you some of its coolness and show you some essential aspects which induce not few voices to accuse Higher Order Functions as one of the basic principles for elegance, compactness and efficiency in Functional Programming. So what’s a Higher Order Function then? So here you have it. Just for the records: the critical part for detecting all proper values which will be selected for the resulting list, seems to be the predicate which is used by that guard. So far, nothing really exciting happened. Ok, just for fun – let’s filter a list of integer values again, but now retain all odd values of the incoming list. . … and ‘Bob’s your uncle’ What’s left? Addendum. The “Scala is too Complex” Conspiracy.
They don’t want pragmatic Scala programmers. The “Scala is too complex for the average programmer” movement is disturbing. It conspires that Scala is too difficult for the average programmer to learn and that it is too academic. Scala is a hybrid programming language that is object oriented and functional.
Java is a programming language that is object oriented and imperative. This means that Java programmers have no functional programming power. This year I read Programming in Scala and practiced some functional programming. It is true that moving from object oriented to functional programming requires a shift in mindset. Fortunately Java 7 is looking to add lambda support to the language so we will soon no longer have to write anonymous inner classes wherever single method interfaces and abstract classes (SAM types) are expected.
For any programmer who has not looked at Scala or who has been deterred by a “too complex” conspirator, here are some code samples.. Case classes Folding Lists. Pointing out the obvious: Scala Pitfalls: Trait Bloat. Those of you following the active development of the Scala programming language may have noticed interesting Subversion commits today (r25962-25964) claiming to reduce the size of scala-library.jar by about 1.5MB.
That's no small amount for a library that was creeping up on 9MB as of Scala 2.9.x, yet zero functionality was lost. So I bet you're wondering: how was this possible, and why is it important? Friends of mine know that I've been really picking up on Scala lately because, as a person who comes from a very heavy imperative/object-oriented programming background, I find it to be a good hybrid language that offers both clean OO and functional programming constructs. Try as I might, I doubt I'll ever bring myself to appreciate the Lisp-derived languages, so when weighing Scala vs., for instance, Clojure, I found the superior OO support in Scala to be the aspect that put it over the top.
One aspect of Scala's OO concepts harkens back to my days of heavy C++ development.