sftwr2020

When Object Orientation Met Functional Programming

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 đŸ˜±

That’s not writing, that’s typing

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.

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.

8 comments

  1. Hi Akram, I think a lot of us were introduced to the wave/particle-like duality of OO/FP by Scala. What I think is unique about Scala is that Odersky managed to deftly weave a functional syntax on top of the traditional OOP bedrock of Java. E.g.:

    – Objects/traits with type parameters -> function objects with arrow syntax
    – Classes -> immutable data with case class syntax
    – Method parameters -> implicit syntax and then typeclasses
    – Static unapply method -> (extensible) pattern matching
    – And so on.

    If you haven't already, take a look at OCaml because it's the only other functional language which blends OOP in as well as (or even better than) Scala: https://realworldocaml.org/v1/en/html/objects.html

    You may be interested in the following passage from Peter Seibel's book Coders at work:

    'Seibel: What's your short list of ones you want to play with more?

    '[Joshua] Bloch: I want to try Scala, though I have some doubts as to whether it will be the next big thing. I have great respect for Martin Odersky. I think there are a bunch of neat ideas in the language. But I also think it may be too complex and too oriented towards academics to succeed in the world at large. I have no right to say that, though, because I haven't learned it yet.'

    Reply

  2. – Hi Yawar, thank you for those deeply thought out, insightful observations. Other readers, and me, get educated tremendously in the process, as readers like you make the time to participate and improve the reading and programming communities, my blog included 🙂

    – I thoroughly enjoyed reading how you draw parallels, and very aptly so, between the wave/particle-like duality and the blend of OO/FP in Scala! And what a coincidence, because just the other day I was reading a delightful treatment of this precise subject—the wave/particle-like duality you mention and which—in the highly readable book called The Outer Limits of Reason: What Science, Mathematics, and Logic Cannot Tell Us (MIT Press) by Noson S. Yanofsky. Referring to the famous double-slit experiment, Yanofsky reminds us in stark terms the message of legendary Amercian physicist and Nobel laureate (the late Richard Feynman) in these words:

    "We choose to examine a phenomenon which is impossible, absolutely impossible, to explain in any classical way, and which has in it the heart of quantum mechanics. In reality, it contains the only mystery. We cannot make the mystery go away by ‘explaining’ how it works. We will just tell you how it works".

    – Ah, the limiting factors in our lives… So space limitations—yep we are ever so briefly digressing to talk about a book with the words "outer limits" in its title—will not permit my delving into the details, though I can't help but remark on the irony of it all, since this blog has the words Programming Digression in it lol.

    – Anyhow, to bring closure to the point that Yanofsky is making about the blended nature (aka the wave/particle-like duality) of light, he remarks on a seemingly inexplicable aspect of the double-slit experiment, noting that

    "Now, for the amazing aspect of this experiment and probably the most mind-blowing result in all of science. Physicists have a way of performing this experiment by releasing one piece of light at a time… The remarkable aspect is that an interference pattern is still found…. How can this be? When we have many photons, we can say that the photons are interfering with each other like waves in a pond. But when each photon is released one at a time, what can a single photon interfere with to create such a pattern? The answer is that the single photon interferes with itself… How can one object pass through both slits simultaneously? That is the major mystery of quantum mechanics".

    – Cool stuff, which I invite interested readers to check out that book, and others, from the stellar MIT Press 🙂

    – To your point about what is unique about Scala (i.e. in your own words: "Odersky managed to deftly weave a functional syntax on top of the traditional OOP bedrock of Java"). I find myself nodding in agreement as I read your first class observations, which I reproduce here to situate them in the context of my reply:

    * Objects/traits with type parameters -> function objects with arrow syntax
    * Classes -> immutable data with case class syntax
    * Method parameters -> implicit syntax and then typeclasses
    * Static unapply method -> (extensible) pattern matching
    * And so on.

    – Speaking of OCaml… Honestly, I know more languages than I know what to do with, lol. This is awesome, though: I hadn't quite realized that OCaml blends OOP with FP! Thank you for sharing the pointer. While browsing online at O'Reilly, I had come across their book called Real World OCaml: Functional Programming for the Masses but never got around to checking it out…

    Reply

  3. – Adding a few more thoughts…

    – And then there is the remarkable volume by UPenn professor Benjamin Pierce (Professor of Computer and Information Science at the University of Pennsylvania) called Types and Programming Languages (MIT Press) in whose pages the glory of the lambda calculus is writ large… Yep, the whole mathematical machinery is in there, readers. So I pulled out my copy of the book—lit up as it is with scores of brightly colored tape flags—from one of my bookshelves and see that it makes mention of how "…The chapters on concrete implementations of typecheckers present significant code fragments in OCaml (or Objective Caml), a popular dialect of ML".

    – Speaking of type theory, and its under-recognized (neologism alert?!) centrality to the craft of programming, I can only remind the interested reader that, over the last two decades type theory has emerged as the central, unifying framework for research in programming languages. I also invite you to check out its refreshing applicability to Scala in my review of Scala in Depth, a rather amazing language brought to us programmers by, of course, Martin Odersky.

    – Oh goodness, I recall now that Pierce even mentions the programming language ML 🙂

    – And speaking of ML, Chris Okasaki's sparkling gem of a book entitled Purely Functional Data Structures (Cambridge University Press) is replete with some of the highest quality ML on this planet. For those not familiar with Okasaki amazing work at Carnegie Mellon University—which is where he earned his Ph.D. under advisers Daniel Sleator, and Robert Tarjan—Purely Functional Data Structures goes into the guts of vitally indispensable FP data strucutures. The book description succinctly reminds us how

    "Most books on data structures assume an imperative language like C or C++. However, data structures for these languages do not always translate well to functional languages such as Standard ML, Haskell, or Scheme. This book describes data structures and data structure design techniques from the point of view of functional languages. It includes code for a wide assortment both of classical data structures and of data structures developed exclusively for functional languages.This handy reference for professional programmers working with functional languages can also be used as a tutorial or for self-study".

    – And please don't anyone even get me started digressing on ML 😉

    – My paperback copy of ML for the Working Programmer, 2nd Edition (Cambridge University Press) by L. C. Paulson is not too far from where I sit at this moment. So my buddy and brilliant fellow programmer Josh (Suarez) one of the handful of programmers I know who actually took a university course that used ML as the vehicle of programming instruction; the rest of us learned the quixotic language from—yes you guessed it—Paulson's ML for the Working Programmer…

    Reply

  4. – I'm happy, Yawar, that you mention one of my all-time favorite books, namely Coders at Work: Reflections on the Craft of Programming (Apress) by Peter Seibel! Since you mention Seibel's interview with Joshua Bloch-each of my paperback copies of his first and second edition of the outstanding book Effective Java (Addison-Wesley) are falling apart at the seams from overuse-it got me thinking to another one of Seibel's interviews (in the book), that one with Guy Steele, who happens to be one of my programming heroes, widely regarded as the father of Common Lisp, and of course the lead author of the Java Language Specification. BTW, a third edition of Bloch's Effective Java is in the works, stay tuned (Java 7 and Java 8 changed things dramatically, and Java's increased support for multiple paradigms increases the need for best-practices advice, and the third edition, when it hits the bookstores, is supposed to deliver).

    – Finally, thanks also for sharing an apt excerpt from Bloch's reply in his interview with Seibel (in Coders at Work). I dug up my well-worn copy of Coders at Work, and found, elsewhere in the same interview, this intriguing reply by Bloch in response to a question by Seibel:

    "The jury is basically still out on anything that hasn't been tested by a huge quantity of programmers under real-world conditions. Often languages only succeed in some niche and people say, “Oh, they're great and it's such a pity they didn't become the successful language in the world.” But often there are reasons they didn't. Hopefully some language that does use declaration-site variance, like Scala or C# 4.0, will answer this question once and for all".

    – Looking forward to future comments and observations from you, as well as from other readers!

    Reply

  6. You are so awesome! I don't believe I have read something like this before.
    So wonderful to find someone with some unique thoughts on this topic.
    Seriously.. thank you for starting this up. This website is
    one thing that's needed on the internet, someone with a bit of originality!

    Reply

  7. Writers 
 use the same words everyone uses, but when we get it right, the emotions, the feelings, the concepts, the images, the ideas are distilled with clarity and force. Then nobody notices our words. 
 Like cleaning a window. When you do it right, and the light shines through and you don’t notice the glass. (Angels in Red Suspenders, 1998)

    Keep cranking out your prose, my friend, and keep the light shining through!

    Reply

  8. Mobile app testing service is a vital part of every software product development project. However, not everyone is a professional software tester, or not many people are willing to spend their time as one. This is where a software testing service can help. Companies that use software tester services save thousands of dollars a year by using only high quality testers. Most professional software testers charge thousands of dollars per test. Yet, if you use a good tester, the cost is much lower. There are many benefits to using a testing service.

    Reply

Leave a Reply to Akram AhmadCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.