 |
Object Orientation |
+
 |
Functional Programming |
=
 |
“Functional, I presume?” 🎩 |
Dr. Livingstone, I presume?
~ Greeting of H. M. Stanley (on locating and meeting David Livingstone in Africa)
No one has ever quoted me back to me before.
~ When Harry Met Sally (The 1989 American romantic comedy movie by Nora Ephron)
Till love that was, and love too blest to be,
Meet—and the junction be Eternity?
~ Emily Dickinson (In XIX, from The Complete Poems of Emily Dickinson)
…a blending of concepts that achieve a greater whole when combined. In particular, three dichotomies…: static typing versus expressiveness, functional programming versus object-oriented programming, and powerful language features versus dead simple Java integration.
~ Joshua Suereth (Scala in Depth, Manning Publications)
Meet tranquilly as friends,
Salute and pass without a hint—
And there the matter ends.
~ Dickinson, Emily (In VII, from The Complete Poems of Emily Dickinson)
When the worlds of object orientation and functional programming collide, there can be awkward moments. Imagine, if you will, object orientation meeting the functional style of programming for the first time. The silence is deafening, both desperately trying to break the ice. Object Orientation finally plucks up the courage and, sounding a polite note of civilized diffidence, innocently asks, “Functional, I presume?” 🌂 In less ethereal realms, we can look to a more tangible example, perhaps most memorably captured by Vaughn Vernon in the preface to his book Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka where he hastened to comfort us in the knowledge that
…if Functor and Monad sound like viruses you caught as a child, steer clear of scalaz for a while.
In turn, I hasten to add that scalaz just happens to be an awesome Scala library for functional programming. At any rate, Vernon was, in the preceding quote, softening the impact of the collision between the two worlds in rightly sharing the caveat to stay away from the complex Scala libraries, such as scalaz, at least in the beginning, since we typically don’t need to solve problems with libraries intended to satisfy a specific programming style—but we’re getting ahead of ourselves and should take a deep breath before proceeding 🐳
Before we do, I wish to remind myself—and in turn my readers—exactly what it is that compels me to write these essays. First, and yes, this is for the know-it-all, right there in the back row, so he can’t admonish me by saying, Hey 😱
Second, I generally avoid putting together (technical) tutorials, incredibly helpful as they are, simply because the internet is already awash with them; my inclination is to dig deeper, and share my findings with you, remaining mindful of the advice that
Originality does not consist in saying what no one has ever said before, but in saying exactly what you think yourself.
Third, I strive to stay true to the gentle guidance—at once comforting and inspiring—in these memorable words, reminding us that
True Ease in Writing comes from Art, not Chance,
As those move easiest who have learn’d to dance
Fourth, and finally, I find myself resonating with this quote from George Orwell, though nowhere near the acuteness that Orwell surely experienced when he divulged in “Why I Write” (England Your England and Other Essays) how
Writing a book is a horrible, exhausting struggle, like a long bout of some painful illness. One would never undertake such a thing if one were not driven on by some demon whom one can neither resist nor understand. For all one knows that demon is simply the same instinct that makes a baby squall for attention. And yet it is also true that one can write nothing readable unless one constantly struggles to efface one’s own personality. Good prose is like a windowpane.
Okay, I feel so much better, having got that out there as to exactly why I write; after all, should we all not start from the premise that “If you wish to converse with me, define your terms”? 😎
So in this essay, I intend to demonstrate that the much vaunted separation between the worlds of object orientation (more generally, object-oriented programming, or OOP) and functional programming (FP) is merely a false dichotomy. The two are positively not at odds with each other; as we tear down the fabricated wall that somehow got foisted between the two, we will see one singularly unified edifice, one that is strengthened as the two programming paradigms buttress each other.
We will hopefully catch a glimpse of the veritable marriage-made-in-heaven—and I was simply compelled to reach for a living example with which to demonstrate the unison—between OOP and FP in the guise of the Scala programming language. In my mind, no other language comes close to Scala in blending the two torrential rivers, each starkly powerful in its own unique offerings, which we software designers try to channel and harness in our attempts to power the digital infrastructures that power the economies of the world.
In other words, we wish to be emboldened by what the blending has to offer whereby these haunting words in the poem The Ballad of East and West by Rudyard Kipling begin to resonate with us
Oh, East is East and West is West, and never the twain shall meet,Till Earth and Sky stand presently at God’s great Judgment Seat;But there is neither East nor West, Border, nor Breed, nor Birth,When two strong men stand face to face, though they come from the ends of the earth!
As you may know all too well, from your likely having witnessed first hand the almost-predictable patterns of how the programming landscape shifts in rhythmic cycles, much like the proverbial sand dunes. So I begin with the observation that OOP is alive and kicking. This essay is, in some ways at least, an attestation to precisely that observation: For my readers who have been digesting a steady diet of essays lately, related as they predominantly have been to the exploration of paradigms related to and centered on FP, I want to show just how nicely OOP and FP complement each other. In the same breath, I wish to honor my roots in the equally fertile terrain of OOP. Yes, without a shred of doubt, FP has much to offer; not as a replacement of all things OOP, but as a worthy parter-in-hand to complement and strengthen what OOP already offers 🏂
The OOP world remains a vibrant and rich ecosystem, offering much to the software world. In fact, OOP continues to power much of our industry, despite FP having made significant inroads into grabbing mindshare in the programming community. A great deal has of course been written about OOP, but perhaps none as beautifully, and in nearly as riveting a style, as in the book entitled Growing Object-Oriented Software, Guided by Tests Steve Freeman and Nat Pryce (Addison-Wesley). More on that later… 🐚
First, though, let’s take stock of the current players in the JVM solution space, which literally forms the foundational substrate on which the digital infrastructures of the world continue to build ever upwards. The lovely Lisp-for-the-JVM language Clojure is nothing short of amazing, but it places tremendous burdens on those who seek to wield its power. Fellow Austin resident Bruce Tate summed this up nicely in this take on Clojure in his fine book entitled Seven Languages in Seven Weeks (The Pragmatic Bookshelf), where he reminded us that
If you need an extreme programming model and are willing to pay the price of learning the language, Clojure is a great fit. I think this is a great language for disciplined, educated teams looking for leverage. You can build better software faster with Clojure.
Clojure tends to required a pure FP mindset, though I remain acutely aware of Lisp hacker Doug Hoyte’s admonition on precisely this point, in his mind-bending book entitled Let Over Lambda, but pursuing that here will simply lead us down a rabbit hole of a much deeper discussion than what we bargained for ⛏
Another pure FP language is Haskell, which, though not a JVM language, has been, and remains, a fertile ground for the gestation, evolution, and realization of the finest ideas that FP has to offer. Keep in mind that there is no escape hatch in Haskell; you either program in a purely functional style, or you don’t program. Period. I wonder if that has anything to do with how I find myself reminded, at this very moment, of an amusing observation that I first came across in the stellar book entitled Programming Scala (Second Edition, O’Reilly) by Dean Wampler and Alex Payne regarding how 😆
There’s a joke in the Haskell community that they have delayed success until the last possible minute.
The authors were, of course, relating that joke while educating us in the finer points of lazy evaluation, in particular the use of data structures with lazy evaluation, such as Scala’s Stream type, pointing out how a few functional languages, like Haskell, are lazy by default.
And that brings us full circle to the strongest contender among the current players in the JVM solution space: Scala. The hybrid FP / OOP language that is Scala has brilliantly proved that unifying the OOP and FP worlds is not only possible, it is actually the blending of the two, in fact, which gives us the best of both world. Here, in the words of Joshua Suereth, in his book entitled Scala in Depth (Manning Publications), we learn succinctly how ⛱
Scala provides the tools needed to blend the object-oriented and functional programming worlds. Scala is at its best when these two evenly share a codebase. The biggest danger to misusing Scala is to ignore its object orientation or its functional programming. But combining the two is the sweet spot that the language was designed to fulfill (italics mine).
To underscore the centrality of the theme (of blending) in his book, Suereth goes on to elaborate how
The book promotes the blended style of Scala, where paradigms are mixed to achieve something greater (italics mine).
Let’s remember also how, in praising Scala, James Gosling, father of the Java programming language, once remarked that
If I were to pick a language to use today other than Java, it would be Scala.
It pays to listen when smart people are talking 🎯
We need powerful tools in our toolbox if we are to have a good shot at taming complexity in software, and elsewhere. It’s no coincidence that you’ll see perched in the pic above—smack in the middle of three powerful programming leitmotifs and ensconced at the bottom by the logic of science which effectively eliminates all escape hatches—is the final word on blending, taken to its logical conclusion. It is a volume that appears admittedly small enough in the pic so as to make us squint hard; let’s not do that. It is, should the reader’s interest be piqued, the tour de force entitled The Way We Think: Conceptual Blending And The Mind’s Hidden Complexities by Gilles Fauconnier and Mark Turner (Basic Books). Yes, we need all the tools—conceptual, algorithmic, infrastructural, thematic, AI, probabilistic, you name it—that we can get our hands on 🍴
I feel that the brief detour (i.e. stocking up on software tools, thereby equipping us to confront complexity head on) was warranted in that we software designers find ourselves, and indeed our entire industry itself, awash with myriad telltale signs of complexity: tangled dependencies, near-combinatorial explosion in the state-space, kludges aimed at solving performance woes, hacks and workarounds to issues elsewhere, and much more.
With that brief detour out of the way, and lest we digress and start ruminating on the specifics of one language or another, and on one tool or another, let’s return to our central theme, which is that of the sparks that fly when OOP meets FP ☄ But I would be remiss and faltering in the service of my reader if I were negligent in reminding her or him about how—and the excerpt below is your truly speaking in first person—from an essay elsewhere
…I think we agree that all languages inevitably carry some baggage—it’s the relative degree of the conceptual burden that a programmer has to bear, when using the model of a given language, which sets a language apart from others. To put this in more concrete terms, allow me to share an anecdote based on my half-dozen years of programming in C++. With all due respect to those for whom the experience of programming in C++ is a pleasant and productive one—rather than the harrowing torment of Sisyphus, penitently toiling away at pushing the boulder uphill—given the bewildering variety of rules, exceptions-to-said-rules, which is the conceptual burden that a C++ programmer has to bear.
The setting for my half-dozen years of programming in C++ was the beautiful state of Minnesota—beautiful, but the harsh, frigid winter season, however, seemed to stretch interminably each year—so the more I would try to warm up to C++, the more that recalcitrant mule of a stubborn language would dig in its heels, responding with nothing but mirthless frostiness… ⛄
And oh my, how the programming landscape undergo displacements and shifts, akin to the proverbial sand dunes, much as I mentioned at the outset. So it’s only fair that I let Guy Steele, who happens to be one of my programming heroes, have the final word on this matter. Witty as ever, and you really should look up his sterling book entitled Common Lisp: The Language, 2nd Edition for ample proof of his wittiness. Here he is, for example, in the sub-section (19.6) entitled By-Position Constructor Function, reminding us, tongue firmly planted in cheek, that the happenstance is that
Because a constructor of this type operates By Order of Arguments, it is sometimes known as a BOA constructor 🐍 (italics, bold, and the serpent are all mine).
So anyhow, back to the matter of our industry’s shifting programming landscape, Steele was reflecting on grabbing mindshare when he noted how
We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp 🐘
The stark fact is that these shifts take place quite predictably as the industry responds to the needs to consumers. Some languages wither away, while others thrive. So let’s talk some more about the astonishing feat of the blending—of OOP and FP—which the creator of Scala (Martin Odersky) was able to pull off in the process of giving us a harmoniously blended language (Scala). Here, I cannot imagine a better articulation of this precise point than what I found in the pages of the sparkling and spritely book entitled Programming Scala by Dean Wampler and Alex Payne (O’Reilly). In his foreword to the book, thought leader Jonas Boner neatly pointed out how 📖
Through some very elegant design choices and simple yet powerful abstractions that were taken from the object-oriented and functional programming worlds, Martin Odersky has managed to create a language with high cohesion and orthogonal, deep abstractions that invites composability in all dimensions of software design. Scala is truly a SCAlable LAnguage that scales with usage, from scripting all the way up to large-scale enterprise applications and middleware (bold is mine).
You are about to learn how to write reusable components using mixin and function composition; how to write Reactive applications using Akka; how to make effective use of advanced features in Scala such as macros and higher kinded types; how to utilize Scala’s rich, flexible, and expressive syntax to build domain-specific languages; how to effectively test your Scala code; how to let Scala simplify your Big Data problems; and much, much more (italics mine).
To that I’ll add the thoughts of Adriaan Moors who is, by his own admission, “happily hacking the Scala compiler and thinking of where to take Scala”. In his foreword to the book Programming in Scala, Third Edition by Martin Odersky, Lex Spoon, and Bill Venners (Artima Press) Moors turned his attention to the amazing Java ecosystem and reminded us that
These improvement to the Java 8 platform are very exciting for Scala, and it’s very rewarding to see Java align with the trend Scala has been setting for over a decade! There’s no doubt that Scala provides a much better functional programming experience, with immutability by default, a uniform treatment of expressions (there’s hardly a return statement in sight in this book), pattern matching, definition-site variance (Java’s use-site variance make function subtyping quite awkward), and so on! To be blunt, there’s more to functional programming than nice syntax for lambdas (italics mine).
To be fair, I hasten to remind you in the words of one of the most graceful writers in our industry, David Flanagan, who, joined by Benjamin Evans as a co-author for the sixth edition of the classic volume Java in a Nutshell (O’Reilly), reminded us how 🚫
It’s worth noting that Java is best regarded as having support for “slightly functional programming.” It is not an especially functional language, nor does it try to be.
And more to the point of the prior quote, in which Adriaan Moors referred to how there’s “…more to functional programming than nice syntax for lambdas”, it’s only fair to point out—and you’ll find this reference buried deep in the guts of the superb book Java in a Nutshell (O’Reilly) by Flanagan and Evans—that we do ourselves a service by remaining mindful of how
Java is fundamentally an object-oriented language. However, with the arrival of lambda expressions, it becomes much easier to write code that is closer to the functional approach.
The first taste of functional programming that Java developers are likely to encounter are three basic idioms that are remarkably useful … (eliding here the delightfully succinct coverages of filter(), map(), and reduce()… Java has full support for these key functional idioms (and several others).
…easy access to the basics of functional programing—and especially idioms such as map, filter, and reduce—is a huge step forward for the Java community. These idioms are so useful that a large majority of Java developers will never need or miss the more advanced capabilities provided by languages with a more thoroughbred functional pedigree.
With that, I hope you have a fair and balanced view of at least one vista of the current programming landscape 🍒
To return to the OOP strand of the hand-in-hand partnership with FP, which is there for the taking, so much has been written, and with such high quality, that describing it further would be pointless. But one contribution to that literature stands out in my mind. While several volumes have fittingly captured the excitement and pragmatism surrounding OOP, perhaps none as beautifully, and in nearly as riveting a style, as in the book entitled Growing Object-Oriented Software, Guided by Tests Steve Freeman and Nat Pryce (Addison-Wesley).
I first read this book six years ago. Since then, I’ve made it a point to read it periodically, if only to remind myself of what’s truly great in OOP. In particular, the flavor of OOP that Freeman and Pryce oh-so-delectably serve up is the test-driven development (TDD) approach to OOP. Thus, for example, let’s savor what they have to say in the section of their book which leads up to a discussion of Feedback Is the Fundamental Tool 🔦
Everyone involved in a software project has to learn as it progresses. For the project to succeed, the people involved have to work together just to understand what they’re supposed to achieve, and to identify and resolve misunderstandings along the way. They all know there will be changes, they just don’t know what changes. They need a process that will help them cope with uncertainty as their experience grows—to anticipate unanticipated changes.
We think that the best approach a team can take is to use empirical feedback to learn about the system and its use, and then apply that learning back to the system. A team needs repeated cycles of activity. In each cycle it adds new features and gets feedback about the quantity and quality of the work already done. The team members split the work into time boxes, within which they analyze, design, implement, and deploy as many features as they can.
A couple of other pointers that leaped out as I devoured Growing Object-Oriented Software, Guided by Tests for the first time include, which I present here in no particular order 🌱
“… you have nothing to lose but your bugs” 🐛
Developers spend far more time reading code than writing it, so that’s what we should optimize for… 🍀
Stop Me If You’ve Heard This One Before: This book is about the techniques of using tests to guide the development of object-oriented software, not about specific technologies 🌴
The catch is that few developers enjoy testing their code. In many development groups, writing automated tests is seen as not “real” work compared to adding features, and boring as well. Most people do not do as well as they should at work they find uninspiring… 🌲
Test-Driven Development (TDD) turns this situation on its head. We write our tests before we write the code. Instead of just using testing to verify our work after it’s done, TDD turns testing into a design activity 🌳
Perhaps nobody has summed up the rationale and wherewithal for Growing Object-Oriented Software, Guided by Tests better than legendary programmer-author, Robert “Uncle Bob” Martin who told us with glowing words that
At last a book, suffused with code, that exposes the deep symbiosis between TDD and OOD. The authors, pioneers in test-driven development, have packed it with principles, practices, heuristics, and (best of all) anecdotes drawn from their decades of professional experience. Every software craftsman will want to pore over the chapters of worked examples and study the advanced testing and design principles. This one’s a keeper.
So there you have it: OOP, especially as viewed from the growth and evolvability vantage point, at its very best 💯
And to tie this all back to the other half of the story—the FP strand of the symbiotic tapestry that we’re unraveling in our exploration—allow me to sum it up in the distinctively crisp writing style of Dean Wampler who, along with his co-author Alex Payne, has this to say in one of the later chapters in their stellar book entitled Programming Scala (Second Edition, O’Reilly) regarding precisely this matter. They remind us how
Scala is a functional programming language, but it is also an object-oriented programming language like Java, Python, Ruby, Smalltalk, and others. I’ve waited until now to explore Scala’s “OO side” for two reasons.
First, I wanted to emphasize that functional programming has become an essential skill set for modern problems, a skill set that may be new to you. When you start with Scala, it’s easy to use it as a “better Java,” a better object-oriented language, and neglect the power of its functional side.
Second, a common architectural approach that Scala promotes is to use FP for programming in the small and OOP for programming in the large. Using FP for implementing algorithms, manipulating data, and managing state in a principled way is our best way to minimize bugs, the amount of code we write, and the risk of schedule delays. On the other hand, Scala’s OO model provides tools for designing composable, reusable modules, which are essential for larger applications. Hence, Scala gives us the best of both worlds (italics mine).
I recently had lunch with a good friend and brilliant fellow programmer, and we got to talking about the “Internet of Things” (aka IoT) 📡 and other stuff. One utterly intriguing metaphor my friend shared with me—one which immediately resonated with everything I know about both languages—was how he heard someone say that “Java is like prose; Scala, more like poetry”. As I understood it, after a few moments’ worth of reflection, the gist of the metaphor is that whereas prose is spelled out and easy to follow, it is, by the same token, not concise, though easier to maintain and debug; think of an obedient puppy 🐕 Okay, perhaps not a recalcitrant kitten 🐱 On the other hand, Scala is concise and at the same time rich in conceptual density, sometimes making it a challenge to grasp other people’s Scala code, and in some ways raising the bar of debugging difficulty 🐂 But the tooling is improving daily, and we continue to tap into the enormous reservoir of the Java ecosystem as always.
Funny, but as we concluded the preceding exploration, brief as it was—and hopefully pragmatic—of the Java/Scala continuum in juxtaposition with the parallel continuum of prose/poetry, I couldn’t help but reflect momentarily on my reference to the “Internet of Things” (aka IoT). Only connect 101, anyone? Or consider these words of E.M. Forster, from his novel entitled Howards End—imagine imperative Java code embodying the ploddingly prosaic aspects of prose and Scala’s declarative style of computation personifying the passion and denseness of poetry. Forster reminisces in Howards End, telling us to
Only connect! That was the whole of her sermon.
Only connect the prose and the passion, and both will be exalted,
And human love will be seen at its height.
Live in fragments no longer.
Only connect…
Let’s note, too, in passing, Roger von Oech quoting the preeminent psychoanalyst Carl Jung as saying that
Only the paradox comes anywhere near to comprehending the fullness of life.
So here we are, our drama swiftly drawing to a close. What better than to end the drama—acts, scenes, and all, Acts 1-4 in particular—than to let the legendary duo of Pac-Man and Ms. Pac-Man take it away? Shall we not have the duo remind us anew of the power residing in partnerships and symbiosis while getting a kick out of recalling the fun we had as kids, standing face to face with those monstrously large arcade machines, playing video games? So as I got myself educated, all over again, in the antecedents of the duo, I was enlightened to learn that
The three intermissions have changed to follow the developing relationship between the original Pac-Man and Ms. Pac-Man (from when they first meet to having a stork drop off their baby); the latter later served as the attract opening sequence for Jr. Pac-Man.
I leave you with these words of Jelaluddin Rumi—thirteenth-century Persian philosopher, mystic, scholar, and poet—whose poetry has been exquisitely rendered into American free verse by Coleman Barks. This excerpt, from Barks’ The Essential Rumi (Harper Collins) can make us pause and deliberate on the undertones of this essay’s theme with this profound knitting-together of stunning metaphors
When two of them meet, they are no longer two.
They are one and six hundred thousand.
The ocean waves are their closest likeness,
when wind makes, from unity, the numerous.
This happened to the sun, and it broke into rays
through the window, into bodies.
The disc of the sun does exist, but if you see
only the ray-bodies, you may have doubts.
The human-divine combination is a oneness.
Plurality, the apparent separation into rays.
Friend, we’re traveling together.
Throw off your tiredness. Let me show you
one tiny spot of the beauty that cannot be spoken.
I’m like an ant that’s gotten into the granary,
ludicrously happy, and trying to lug out
a grain that’s way too big.
