Sunday, August 20, 2017

Best Book on Technical Blogging

The medium is the message.
~ Marshall McLuhan (
In 
Understanding Media: The Extensions of Man)
Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it.
Johann Wolfgang von Goethe, German writer and statesman
I've been searchin'
So long
To find an answer
...
Good things
In life
Take a long time
yeah yeah
~ Chicago (
Lyrics from 
(I've Been) Searchin' So Long)
Let me count the ways.
~ Elizabeth Barrett Browning (From Sonnet 43) 

I'll begin with a starkly honest acknowledgment: Everything that I know about bloggingI mean literally everythingI learned from an amazing book which I will be introducing shortly. But I need to backtrack just a bit to set the stage. You may have glanced at the Goethe quote atop this essay; it got me thinking to yet another observation of his, one that I seek to remain mindful of, as best as I can. Goethe had noted, elsewhere, that
Things which matter most must never be at the mercy of things which matter least.
And this precise theme is what compelled me to drop all plans this weekend—and weekends are pretty much the only time when I write essays to post to my blogfor gathering thoughts and jotting down what was going to be a hard-core, software-centric essay. Instead, I knew it was time for me to share with my readers the very best guidance there is on the subject of technical blogging. Okay, enough of the cloak-and-dagger πŸ”ͺπŸŽ©πŸŒ‚

With that, I will now try doing some justice in expressing the profound debt I owe to a remarkable book entitled Technical Blogging: Turn Your Expertise into a Remarkable Online Presence. I believe it is available at Amazon and also available at The Pragmatic Bookshelf. This fine book is by serial blogger extraordinaire Antonio Cangiano. Frankly, the biggest challenge at the moment has me thinking to the words—which you may have noted atop this essayof one of the most prominent English poets of the Victorian era, Elizabeth Barrett Browning ("Let me count the ways") ⛏

But we won't allow perfect to be the enemy of good, will we? πŸ™‰ So let's have at it... In no particular order, what follow are the central themes that have made Antonio's Technical Blogging: Turn Your Expertise into a Remarkable Online Presence stand out, head and shoulders above others, and helped me immensely. Yes, without the shadow of a doubt, Technical Blogging has had a tremendously positive impact on increasing the effectiveness of my blogging! 

Much as I said earlier, everything that I know about bloggingI learned from Technical Blogging. I can't recall even a single occasion when I felt the need to consult any other book—or online resource for that matter—for advice on putting together the very best blog that I'm capable of. This book has everything covered: From selecting the theme of the blog, the style of blogging, the technical details of choosing your blogging platform, promotion, even making some money. I have to confess, though, in connection with the last point, that I write purely from my passion for sharing with others what I know, and what I continue to learn, in our protean software development industry. There is, I hasten to add for those so inclined, absolutely nothing wrong with monetizing your blog; after all, we've all heard countless times how
The business of America is businessπŸ’°
For the sake of accuracy—an ever-abiding concern of mine in the service of my readerswhat Calvin Coolidge (the 30th President of the United States) actually said was that "The chief business of the American people is business". So there πŸ˜‡

In sum, and speaking a bit more to the sheer volume of actionable advice on anything and everything related to (technical) blogging, Technical Blogging simply can't be beat; the more I have read this remarkably high quality book over the past several years, the more the hunch was confirmed that my search for the finest book ever on technical blogging had come to a conclusive end ⛳


As my life goes on I believe
Somehow something's changed
Something deep inside
Ooh a part of me
There's a strange new light in my eyes
Things I've never known
Changin' my life
Changin' me
I've been searchin'
So long
To find an answer
...
Good things
In life
Take a long time
yeah yeah
~ Chicago (Lyrics from (I've Been) Searchin' So Long)

Next up, to use the notion of SNR—the much vaunted Signal-to-Noise Ratio of which all engineers get disabused at one time or another during their professional training—this masterpiece has practically zero fluff. It's all good stuff ♨ In my mind, this book will easily still be around for another decade, serving as a rich source of insights into what really makes blogging tick; no doubt, technologies will come and go, as they have in the past. However, Technical Blogging has enduring ideas, which you will simply not find elsewhere.

Antonio's precept of "Content is king" continues to deeply resonate with me to this day; FWIW, I'll add that I began blogging three years ago, with this fine book lying open at my side, through it all. Speaking of the aforementioned notion that "Content is king"—which is IMHO really the killer idea of bloggingI have done my level best to pay tribute elsewhere to the equally immense debt of gratitude I owe to another singularly awesome book. Of the more-than-a-handful of books I've read on the art of writing, by far the one which has had the greatest impact on my own writing is entitled Writing with Style: Conversations on the Art of Writing, by John Trimble with The University of Texas & Austin. Having a laser-sharp focus on crafting content of the highest quality is vital. This focus remains, as always, my compass in everything that I put together for my readers; much as I said earlier, everything that I write for this blog, I do so purely from the passion for sharing with others what I know, and what I continue to learn from immersion in our exciting and ever-in-flux software development industry πŸΎ

I had noted elsewhere my sentiment about how
If you take away from this essay only one book, please make it Writing with Style: Conversations on the Art of Writing by John R. Trimble. I refer to the volume fondly as WWS. My writing life can be cleanly divided—much as the World Wars (WW) divided history into pre- and post-WW—into pre- and post-WWS πŸš‘
And I stand by every single impression, conspicuously including the preceding one, and others, regarding the delineation of my writing life, which I had shared elsewhere in paying tribute to that other gem of a book. Regarding the book we're pursuing in this essayTechnical Blogging: Turn Your Expertise into a Remarkable Online Presence—the need for a similar delineation (in my blogging life) never arose, simply because I had the great good fortune of starting my blogging life with this trusty guide and constant companion during all my canters and gallops through the terrain of effectively sharing with you all that I write as I grapple with the dual processes of discovery and formulation 🐎


The sheer amount of high quality material in this book borders on the overwhelming, in a very good way. On this note, I have another confession to make: To date, I have tapped into perhaps only a small fraction of the copious advice that is to be found in the pages of Technical Blogging. Then again, I'm in no hurry, and my learnings from this fine book continue. By the same token, there is a ton of great advice in there that you should avail of at your own cadence ✅

To pick just one example, it was only recently—one weekend ago from the current weekend in fact—that I posted a mention of my blog to Reddit. And wow, as a first-time user of that social forum, I was pleasantly astonished by the overwhelmingly warm response I got from readers in Reddit! Evidently, it's time to explore some more πŸ˜‰

Johanna Rothman, consultant and author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, has perhaps summed it up the best in sharing her experience of and estimation of the value of Technical Blogging when she noted how
I felt as if Antonio were my own private consultant helping me every step of the way, updating and crafting my blogs for maximum value. I will be reading and rereading this book every few months to make sure I haven’t missed anything. If you blog, read this book. If you’re considering blogging, read this book. Do not let a day go by without reading this book.
Well said, Ms. Rothman 😎 I can tell you in full candor, dear reader, that my copy of Technical Blogging is lit up with highlighter marks, not to mention the tape flags, which you might have noticed cropping up in the pic atop this essay. And it is not a random decision that I chose to have Technical Blogging be flanked on each side by two other classics from the same publishing company (The Pragmatic Bookshelf). In fact, the book that started it all, i.e. the series of books in the The Pragmatic Bookshelf—as best as I recall—is the spectacularly influential The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas, which you'll see proudly flanking Technical Blogging in that pic 🎬

In the end, I can say without reservation that serial blogger extraordinaire Antonio Cangiano has shared in the pages of the book Technical Blogging: Turn Your Expertise into a Remarkable Online Presence stellar advice that you will simply not find anywhere else—our industry is lucky to have individuals like him. I eagerly look forward to his next books. 

And since I had earlier mentioned on a personal note that I write purely from my passion for sharing with others what I know, and what I continue to learn, I'll close on a personal note as well: My late father—it will be two years on September 1st since he passed away—was a chemical engineer by profession, and he imbued me deeply with pragmatism. At times, and especially lately, I simply haven't been able to help but think to and reminisce about how proud he would be to hear about the vibrant blog that this has become, directly as a result of the participation and involvement of readers like you πŸ† 

My better half—she is a big fan of Mother Teresa and doing charitable work—has leavened my pragmatism by imbuing me with the primacy of humbleness, and helping everyone around us grow and blossom (I know this sounds old fashioned). In turn, I remain truly humbled by what my coworkers (both past and present) have written about working with me ⏳

Sunday, August 13, 2017

When Object Orientation Met Functional Programming


 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) 

Object Orientation

+

Functional Programming

=

"Functional, I presume?"


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.
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 personfrom 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 PressMoors 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 Evansthat 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 wasand hopefully pragmaticof 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 dramaacts, 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.

Monday, August 7, 2017

Beautiful Code, Beautiful Prose



Unfortunately, moral beauty in art—like physical beauty in a person—is extremely perishable.
~ Susan Sontag

Programs must be written for people to read, and only incidentally for machines to execute.
~ Structure and Interpretation of Computer Programs by Harold Abelson and Gerald (Second Edition, The MIT Press)

In literature, the ambition of the novice is to acquire the literary language; the struggle of the adept is to get rid of it.
~ George Bernard Shaw  

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?
~ Alan J. Perlis
Let's start with a simple premise: What do beautiful code and beautiful prose even look like? Even more fundamentally, are these qualities not so abstract—to the point of being ephemeral and ethereal—that even contemplating their pursuit would be akin to tilting at windmills? Clearly, there is no arbiter to pontificate and decide this matter. There are, however, some guiding principles that may fruitfully lead us down (and visualize this) a cherry-lined lane of discovery πŸ’

Humans have pursued beauty in other realms, including this noble attempt, memorably enshrined in the delightful poetry of American poet Ogden Nash, who implored the heavens, in his poem Kind of an Ode to Duty, plaintively asking why πŸ˜‰
O Duty,
Why hast thou not the visage of a sweetie or a cutie?
Why glitter thy spectacles so ominously?
Why art thou clad so abominously?
Why art thou so different from Venus
And why do thou and I have so few interests mutually in common between us?
Why art thou fifty per cent martyr
And fifty-one per cent Tartar?
Consider, too, what the British mathematician and philosopher Bertrand Russell had to say on this very elemental, yet elusive, quality:
Mathematics, rightly viewed, possesses not only truth, but supreme beauty—a beauty cold and austere, like that of sculpture, without appeal to any part of our weaker nature, without the gorgeous trappings of painting or music, yet sublimely pure, and capable of a stern perfection such as only the greatest art can show. The true spirit of delight, the exaltation, the sense of being more than Man, which is the touchstone of the highest excellence, is to be found in mathematics as surely as poetry (italics mine).
To this I add the seemingly anachronistic case of this observation by top-notch writer and Lisp hacker Peter Seibel. I have written an essay elsewhere regarding how the overwhelming impression which his book Practical Common Lisp left on my mind was that it had been written by someone who cares as much about the art of programming as he does for the craft of writing well. In fact, there is an intriguing self-admission by Seibel in that book's About the Author section where we are told, tongue in cheek style, that πŸ˜†
Peter Seibel is either a writer-turned-programmer or a programmer-turned-writer. After picking up an undergraduate degree in English and working briefly as a journalist, he was seduced by the Web...
And wow, does his command of both programming and writing shine throughout the book. Picking this thread—how individuals can care as much about their art as they do for the craft of writing well—leads me to briefly unroll the ball of yarn some more. Buckle up, here we go...

My basic premise is that there exists a profound nexus between (software) code and prose: While the English language, or any other spoken language, for that matter, is clearly not Turing complete—I've heard, though, that COBOL occupied a fabled place somewhere between spoken and programming languages πŸ™‰—the simple fact is that rewriting (spoken languages) maps directly to the programming notion of refactoring, which its originator, Martin Fowler, describes succinctly as
a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
To segue a bit, my late father, a chemical engineer by profession, and a man of uncommon decency and integrity, was a big fan of books by the prolific American author, the late James A. Michener, widely regarded for his meticulous research behind his books. So I can think of no better way to pay tribute to and honoring the memory of them both than by sharing this delightful quote by Michener, as cited by Professor John Trimble—more on him later—in Trimble's sage book on writing style entitled Writing with Style: Conversations on the Art of Writing. In reminding us of the sobering fact that writers "...have accepted the grim reality that nine-tenths of all writing is rewriting...", Trimble cites Michener as reflecting on his own work, and sharing how
I have never thought of myself as a good writer. Anyone who wants reassurance of that should read one of my first drafts. But I'm one of the world's greatest rewriters.
And there you have humbleness and greatness, all rolled into one 😎

In returning from the segue, and while still exploring the profound nexus between software code and prose, I'll add that software design patterns are a first class attempt at reclaiming the beauty that may otherwise languish due to neglect and bit rot. This, too, has a direct counterpart in the crafting of prose; for more, I refer the interested reader to Professor John Trimble's Writing with Style: Conversations on the Art of Writing.

Allow me to wedge in here, edgewise, the factoid that probably the preeminent tome on modern American usage—now in its fourth edition—is by yet another individual who cares as much about their art (the practice of law), as they do for the writing craft: Bryan Garner. His magisterial volume, simply entitled Garner's Modern American Usage (Oxford University Press), was received to wide acclaim, and for good reason; it simply happens to be one of those overwhelmingly rich yet can't-put-me-down volumes πŸ’― A polymath of sorts, Garner has been recognized as a pioneer across a wide range of fields, including English usage, grammar, jurisprudence, legal advocacy, and is the president of the company—note here the marriage-made-in-heaven name—LawProse Inc. 🎩

The near-mystical Drawing Hands lithograph by M. C. Escher

Then take the case of noted language aesthete, eminent Clojure hacker, blogger, and author, Michael Fogus. In the fine volume entitled Functional JavaScript (O’Reilly), Fogus notes that
The first rule of my personal programming style has always been the following: 
Write beautiful code. I’ve achieved this goal to varying degrees of success throughout my career, but it’s always something that I strive for. Writing beautiful code allows me to optimize another aspect of computer time: the time that I spend sitting at a desk typing on a keyboard. I find a functional style of writing code to be exceptionally beautiful if done well, and I hope that you’ll agree by the time you reach the end (italics mine).
Elsewhere in Functional JavaScript, Fogus reflects some more on beauty, pointing out how
In fact, functions are a beautiful unit of work allowing you to adhere to the long-practiced maxim in the UNIX community, set forth by Butler Lampson: 
        Make it run, make it right, make it fast 🐒
Likewise, functions-as-abstraction allow you to fulfill Kent Beck’s similarly phrased mantra of test-driven development (TDD): 
        Make it run, then make it right, then make it fast 🐎
Also in Functional JavaScript, amplifying the same theme of beauty and pragmatism, noted software architect Steve Vinoski observes (in his Foreword to the book by Fogus) that
Most software development efforts require pragmatism, though, and fortunately for us Fogus tackles this important requirement as well. Having beautiful, sophisticated and simple code is ultimately meaningless if it’s not practical, and this is a large part of the reason functional programming stayed hidden in the shadows for so many years. Fogus addresses this issue by helping the reader explore and evaluate the computing costs associated with the functional programming approaches he champions here. 
And of course books, just like software, are ultimately about communication. Like Crockford, Fogus writes in a manner that’s both brief and informative, saying just enough to drive his ideas home without belaboring them. I can’t overstate the importance of Michael’s brevity and clarity, since without them we’d miss the incredible potential of the ideas and insights he’s provided here. You’ll find elegance not only in the approaches and code Fogus presents, but also in the way he presents them (italics mine).
Let's next turn our attention to the pursuit of beauty in the Pulitzer Prize-winning book GΓΆdel, Escher, Bach: An Eternal Golden Braid whose author, Douglas Hofstadter, astonished the world with the publication of this mind-bending fugue of a book. This book's monumental impact was perhaps best heralded by the American popular mathematics and popular science writer Martin Gardner who elegantly summed it up by noting that
Every few decades an unknown author brings out a book of such depth, clarity, range, wit, beauty and originality that it is recognized at once as a major literary event. ‘Godel, Bach’ is such a work (italics mine).

Finally, in laying to rest the thread we had picked up earlier—how individuals can care as much about their art as they do for the craft of writing well—let's check out an excerpt or two from the almost-sublime prose of an author whose name is quite possibly alien to the majority of my fellow software designers and developers, though I may be pleasantly mistaken in my assumption πŸ˜‚ Allow me to introduce Philip M. Bromberg, Ph.D, by way of this review of his book Awakening the Dreamer, by Richard A. Chefetz, M.D. who cuts to the heart of the matter in reflecting on the vista-opening power and beauty in Bromberg's prose by noting that
Whether the wish is to know oneself more deeply, to understand better the psychoanalytic process, or simply to immerse oneself in seamless, elegant prose, Philip Bromberg's Awakening the Dreamer is enormously satisfying. Besides showing that the analyst's thoughtful self-revelation is not simply permissible, but actually necessary in the analytic process, Bromberg makes salient connections between leading-edge work in affective neuroscience and the relational psychoanalytic tradition he helped create. A nearly effortless read, Dreamer places the reader inside the minds both of a master clinician and of his patient (italics mine).
It's simply impossible to even try to contemplate doing any sort of justice to the caliber of Bromberg's prose; the best antidote is for me to share a typical passage from this prolific writer. In particular—and I have a confession to make here—as someone who is smitten by the pixie-dust magic qualities πŸ’₯ of em-dashes, I couldn't help but resonate with the impact wrought to great effect by Bromberg's use of em-dashes through the length and breadth of his seminal work. Here, in his  fine book entitled The Shadow of the Tsunami: and the Growth of the Relational Mind (Routledge), for example, he invites us to
Consider the following lines written by Carlos Ruiz Zafon (2001) in his novel, The Shadow of the Wind. Daniel, the protagonist, is suddenly reunited with the most deeply important friend of his childhood, and in the reunion he relives the birth of that friendship: 
It seemed to me that this oversize, solitary boy had constructed his own tin companions and that I was the first person he was introducing them to. It was his secret. I shared mine. I told him about my mother and how much I missed her. When my voice broke, Tomas hugged me without saying a word. We were ten years old. From that day on Tomas Aguilar became my best—and I his only—friend. (p. 94, emphasis added) 
Through Zafon’s brilliant placement of the two em-dashes in the final sentence, he endows "best" and "only" with linguistic unity, and in so doing he evocatively endows the word "friend" with experiential wholeness that transcends our cognitive awareness of each boy’s individuality. Even though each adjective remains unique to the personality of just one of the boys, the relational oneness of that friendship is felt as greater than the sum of its parts. The author could have written "Tomas Aguilar became my best friend, and I his only friend" but if he had, separateness would replace oneness; the way Zafon uses language pulls the reader not only into the book but into himself. Individuality and oneness become a single entity in the act of reunion.

Next, I have the pleasure of mentioning two other leading thinkers and writers: Elizabeth Saunders and Cal Newport. I mention them in the same breath because it was through the writings of the latter that I was introduced to the writings of the former 🎯 I have reviewed Elizabeth's books elsewhere and they are hands down the final word on time management ⏰ Briefly, along with another book—the remarkable tome Probability Theory: The Logic of Science, by E. T. Jaynes (Cambridge University Press)—I had reviewed Elizabeth's second book, entitled How to Invest Your Time Like Money (Harvard Business Review Press), noting how
...just when you thought that Elizabeth had shared all imaginable wisdom on the subject of time investment, she comes back with yet another tour de force of a book. What had amazed me about her first book—The 3 Secrets to Effective Time Investment—was that I could randomly open the book to any page, and be guaranteed a nugget of wisdom. Just to make sure the magic was still working πŸ˜‰ I opened the book randomly to the page which leads off a discussion (entitled Routines Require Intentional Practice), and found this insight that I'm partially excerpting here: 
At first it will take a great deal of mental and emotional fortitude to even want to start putting these routines into practice.... It's like hacking a new pathway through the jungle of the day when you were used to strolling down a well-established trail or like breaking up scar tissue and retraining your muscles when your body developed bad compensation techniques after an injury.... Ultimately, though, strengthening simple routines leads to a life where you consistently achieve more success with less stress. 
This stellar follow-up book—How to Invest Your Time Like Money—is every bit as good.
As for the second of these two leading thinkers, Cal Newport, I have previously shared my perspective on his work in an essay entitled Top Thought Leaders to Follow, starting with the preamble that
At the top of my list is Cal Newport, who is just about the most clear-eyed thinker I know of. Cal teaches at Georgetown University in Washington, D.C, where he is an Assistant Professor of Computer Science. What's unique about Cal are his uniquely original insights, which he shares with the world through his Study Hacks Blog—Decoding Patterns of Success. As the name of his blog signals, his posts seek to capture the essence of achieving meaningful success through wide-ranging, engagingly written, and eminently thought-provoking discussions.
Even more relevant to our present theme, Cal had this to say, in his slim and stellar book entitled How to Win at College: Surprising Secrets for Success from the Country's Top Students πŸŽ“ (Broadway Books), on the craft of writing, as should be practiced in daily life. Thus, in a chapter in that book, with the delightfully evocative title Write as if Going for a Pulitzer, he reminds us how
Good writing sparkles, not just in content but also in form. When you read good writing, the varied rhythm of the sentences, the careful choice of words, and the descriptive phrases grab your attention and pull you through the topic toward inevitable conclusions. The experience is almost cinematic. You lose yourself in the prose and come out on the last page feeling as if you just experienced something significant. This is how you should aspire to write. A student who goes beyond just demonstrating coherent knowledge of a subject, and also artfully crafts the delivery, is going to stand out among his or her peers. Professors' eyes will light up, your name will be remembered, and you will score consistently higher on your written assignments (italics mine).
Here you  have the indelible imprints of someone caring for the craft of writing that is all at once suffused with pragmatism πŸ”¦

Let's next turn to what English poet and playwright William Shakespeare, widely regarded as the greatest writer in the English language and the world's pre-eminent dramatist, had to say on beauty, by way of this monologue, spoken in the play by Prince Hamlet πŸ“– And Shakespeare certainly had a way with words; here he has angst-ridden Hamlet ruefully ponder over
What a piece of work is a man! How noble in reason! How infinite in faculties! In form and moving, how express and admirable! In action how like an angel!
In apprehension, how like a god! The beauty of the world! The paragon of animals! And yet, to me, what is this quintessence of dust? (italics mine)

As a postscript to the thread—this time drilling down to the level of the irreducible atoms that form the very substrate of both code and prose—let's take a peek at the nexus between thought, words, prose, and code, the latter being the distillation of someone's attempt to reify the conceptualization of a process. So here is Donnel B. Stern, writing with his trademark and uncommonly clear formulations, as he observes in his book, Unformulated Experience (Routledge), how
Merleau-Ponty (1964b) distinguishes "empirical speech," the established usage of conventional expressions, from "creative speech," which "frees the meaning captive in the thing." "To speak," he says about authentic speech, "is not to put a word under each thought..."

We sometimes have, on the contrary, the feeling that a thought has been spoken—not replaced by verbal counters but incorporated in words and made available in them" (p. 44). He goes on to discuss the creative use of language this way: "Language signifies when instead of copying thought it lets itself be taken apart and put together again by thought. Language bears the meaning of thought as a footprint signifies the movement and effort of a body" (p. 44). And earlier (1964a), he tells us that speech 
tears out or tears apart meanings in the undivided whole of the nameable, as our gestures do in that of the perceptible. To make of language a means or a code for thought is to break it. When we do so we prohibit ourselves from understanding the depth to which words sound within us—from understanding that we have a need, a passion, for speaking and must (as soon as we think) speak to ourselves; that words have the power to arouse thoughts and implant henceforth inalienable dimensions of thought; and that they put responses on our lips we did not know we were capable of, teaching us, Sartre says, our own thought [p. 17].

This is hardly a vision of language as passive, docile, or merely categorical. It is instead apocalytic, intuitive, antic, possessed. Language is no servant; it is disobedient and revelatory. Language is a dervish. It belongs to us and it carries us away, all in the same instant.
This is precisely the sort of riveting prose that knocks my socks off; the inseparable entanglement with the irreducible atoms which are the bedrock of code and prose; and another reason—perhaps, the reason—why designing and crafting software code and prose are inextricably woven into a unified tapestry which, at its finest, drive many of us, software designers, and others, to be sure, in these pursuits 🐬
Merleau-Ponty, M. (1964a), Introduction. In: Signs, trans. R. C. McCleary. Evanston, IL: Northwestern University Press, pp. 3-35. 
Merleau-Ponty, M. (1964b), Indirect language and the voices of silence. In: Signs, trans. R. C. McCleary. Evanston, IL. Northwestern University Press, pp. 39-97.
And this is precisely what the brilliant English novelist, essayist, journalist, and critic George Orwell had in mind when he alerted us, in a justifiably admonitory tone, in his prescient essay Politics and the English Language regarding how
As I have tried to show, modern writing at its worst does not consist in picking out words for the sake of their meaning and inventing images in order to make the meaning clearer. It consists in gumming together long strips of words which have already been set in order by someone else, and making the results presentable by sheer humbug.
I used the phrase "riveting prose" above, and it relentlessly ushers in a flood of memories, this being a phrase which I first came across in the pages of a stellar book that has had, by far, the greatest impact on my writing: Writing with Style: Conversations on the Art of Writing, by John Trimble. In fact, you can find a notable mention in a prior essay here on my blog, noting in that essay that
When Graham's Hackers & Painters came out, many years ago (it predates my reading any of his works on Lisp), I was so impressed by its quality that I wrote to him, telling him how highly I thought of his book, plus recommending to him the best book available on this planet on writing well, namely Writing with Style: Conversations on the Art of Writing by John R. Trimble. Graham graciously replied to me, saying that he in fact had a copy of Writing with Style in his bookshelf. I was pleasantly surprised, because while most everyone has heard of The Elements of Style (by Strunk and White), hardly anyone is even aware of John R. Trimble's stellar gem of a book. In my mind at least, and with all due respect to the former book (because I have read and appreciated its advice), Writing with Style is the book that The Elements of Style wants to be when it grows up πŸ‘»
If you take away from this essay only one book, please make it Writing with Style: Conversations on the Art of Writing by John R. Trimble. I refer to the volume fondly as WWS. My writing life can be cleanly divided—much as the World Wars (WW) divided history into pre- and post-WW—into pre- and post-WWS πŸš‘ Here is Professor Trimble, gently reminding us in WWW how
The average college student isn't ready for semicolons. She hasn't discerned any need for them,  nor is she eager to. They look forbiddingly exotic—about as tempting as a plate of snails 🐌
Enough said. And yes, I got smitten by the pixie-dust magic qualities πŸ’₯ of em-dashes, which I alluded to earlier, directly as a result of reading Professor Trimble's classic and ever-sparkling WWW. While on the subject, allow me to share merely a single excerpt, and a single sentence at that, from the works of one of the most elegant and precise writers of the world, the British mathematician and philosopher Bertrand Russell. As I share this, I can't help but pause and reflect on the current affairs of our world today, and the irony of it all as Russell looked to "men who were deeply imbued with a respect for law". He noted, in "Individual and Social Ethics" in The Basic Writings of Bertrand Russell (1961), how
It is noteworthy that the most successful revolutions—that of England in 1688 and that of America in 1776—were carried out by men who were deeply imbued with a respect for law.
Prose doesn't get any more elegant, refined, and poignant than that, does it? 🏰 And to really get these lovely interlopes, these em-dashes, out of my system, let's together look at what lawyer and prose-pro Bryan Garner, whom we met earlier, has to say about them in his magisterial volume entitled Garner's Modern American Usage (Oxford University Press)
The em-dash is perhaps the most underused punctuation mark in American writing. Whatever the type of writing, dashes can often clarify a sentence that is clogged up with commas—or even one that’s otherwise lusterless... 🎯
Some books fall into disuse, other into use; yet others into overuse 🎻 My copy of this particular bookburgundy color and allfinds itself valiantly propped up against a table leg ⛳

My well-worn (paperback) copy of Writing with Style: Conversations on the Art of Writing, literally fell apart at the seams from, shall we say, extended use; the careful reader will note the spiral-bound copy toward the right-hand side in the pic above.

So I got to thinking about something that the noted Lisp hackerand founder of Y Combinator, now the preeminent startup-company acceleratorPaul Graham had to say in connection with the pursuit of beauty in design. So I dug up my well-worn copy of Hackers & Painters (O'Reilly Media), harking back to my days in wintry Minnesota ⛄ and boy, was I surprised, pleasantly so, I hasten to add, to rediscover, in revisiting its pages, just how profound and lasting an impact the pursuit of beauty has in creating and evolving designs of the highest order. To give you a better flavor of Graham's take on this subtle matter, I really can't do much better than share some excerpts as I flip through the well-worn (wizened? although using this latter word would be a tad too anthropomorphic) pages of Hackers & Painters...

But first, some clarification of the term hackerin the sense that in which it's used hereis in order:
A hacker is any skilled computer expert that uses their technical knowledge to overcome a problem... πŸ“–

With that slight digression—a definitional oneout of the way, let's hear Graham's profound musings on what it might mean to pursue beauty in the quest for creating and evolving (software) designs of the highest order. He notes that
Measuring what hackers are actually trying to do, designing beautiful software, would be much more difficult. You need a good sense of design to judge good design. And there is no correlation, except possibly a negative one, between people's ability to recognize good design and their confidence that they can. 
The only external test is time. Over time, beautiful things tend to thrive, and ugly things tend to get discarded. Unfortunately, the amounts of time involved can be longer than human lifetimes. Samuel Johnson said it took a hundred years for a writer's reputation to converge. You have to wait for the writer's influential friends to die, and then for all their followers to die (italics mine).
And here is Graham again, writing this time on a more personal notebut with his trademark perspicacity and perspicuityelsewhere in the book, reflecting on his high school days, observing that
There was something else I wanted more: to be smart. Not simply to do well in school, though that counted for something, but to design beautiful rockets, or to write well, or to understand how to program computers. In general, to make great things.
Yes, there seem to exist far more than mere tenuous links between beauty and great software and prose, dare I say πŸš€ Come to think of it, the notion of beauty as a guiding principle to crafting great softwareand prose, to be sure—has spawned an entire series of books on the pragmatic unity of beauty and technology, brought to us by the publishing industry's vanguard company we all fondly know as OReilly. Here is the basis of the theme, nicely articulated by the editors (Diomidis Spinellis and Georgios Gousios) of the book Beautiful Architecture (O'Reilly). They note in the Preface that
The idea for the book you’re reading was conceived in 2007 as a successor to the award-winning, best-selling Beautiful Code: a collection of essays about innovative and sometimes surprising solutions to programming problems. In Beautiful Architecture, the scope and purpose is different, but similarly focused: to get leading software designers and architects to describe a software architecture of their choice, peeling back the layers of their creations to show how they developed software that is functional, reliable, usable, efficient, maintainable, portable, and, yes, elegant.
And this is how Greg Wilson and Andy Oram, the editors of another book in this series, entitled Beautiful Code, tell the reader in the Foreword to the book how
In May 2006, I asked some well-known (and not so well-known) software designers to dissect and discuss the most beautiful piece of code they knew. As this book shows, they have found beauty in many different places. For some, it lives in the small details of elegantly crafted software. Others find beauty in the big picture—in how a program's structure allows it to evolve gracefully over time, or in the techniques used to build it (italics mine).
Finally, in wrapping up our brief exploration of how beauty can serve as an unerring guiding principle to crafting great software, glancing as we did at some ideas captured in the series of books on the pragmatically unifying approach of pursuing beauty in mastering technology, let's look at what the editors (Andy Oram and John Viega) of yet another book in this series have to say on this subject. This one is entitled Beautiful Security, and we are let in on how
To people tasked with creating secure systems, the effort seems hopeless. Nobody at their site cooperates with their procedures, and the business managers refuse to allocate more than a pittance to security. Jaded from the endless instances of zero-day exploits and un-patched vulnerabilities in the tools and languages they have to work with, programmers and system administrators become lax.  
This is why books on security sell poorly (although in the last year or two, sales have picked up a bit). Books on hacking into systems sell much better than books about how to protect systems, a trend that really scares me.  
Well, this book should change that. It will show that security is about the most exciting career you can have. It is not tedious, not bureaucratic, and not constraining. In fact, it exercises the imagination like nothing else in technology (italics mine).
There you have it, observations from the trenches of the software industry on exercising the imagination in the quest for beautiful unifying themes, weaving many strands into a unified and beautiful whole; truly, then, the whole is other than the sum of the parts.


And I haven't even talked about beauty in the realm of those who pursue the endless frontier of artificial intelligence ⛏ Perhaps we can delve into that in a future essay. Let's settle at this time with a quick look at what Ray Kurzweil, in his nice book How to Create a Mind: The Secret of Human Thought Revealed (Penguin Group, US), has to say in harking back to an earlier generation and asking
What is it that the later Wittgenstein thought was worth thinking and talking about? It was issues such as beauty and love, which he recognized exist imperfectly as ideas in the minds of men. However, he writes that such concepts do exist in a perfect and idealized realm, similar to the perfect “forms” that Plato wrote about in the Platonic dialogues, another work that illuminated apparently contradictory approaches to the nature of reality. 
The most important result of this new depiction of the cortical hierarchy is that now we can say each and every region of cortex forms invariant representations. In the old way of thinking, we didn’t have complete invariant representations—such as faces—until inputs reached the top layer, IT, which sees the whole visual world. Now we can say that invariant representations are ubiquitous. Invariant representations are formed in every cortical region. Invariance isn’t something that only magically appears when we get to higher regions of the cortex, such as IT... Thus all regions of cortex form invariant representations of the world underneath them in the hierarchy. There is beauty in this
Our puzzle has shifted. We no longer have to ask how invariant representations are formed in four steps from bottom to top. Rather we have to ask how invariant representations are formed in every single cortical region. This makes perfect sense if we take the existence of a common cortical algorithm seriously. If one region stores sequences of patterns, every region stores sequences. If one region creates invariant representations, all regions create invariant representations. Redrawing the cortical hierarchy along the lines shown in figure 5 makes this interpretation possible.
To this precise description of the magic and beauty of interpretations and reinterpretations I can only add some poetic leavening, by way of the words of celebrated American poet Robert Frost when he observed how
I have never started a poem yet whose end I knew. Writing a poem is discovering
In sum, this essay, entitled Beautiful Code, Beautiful Prose as it is, could just as well have been entitled Beautiful Prose, Beautiful Code. Is this juxtaposition mere semantic hair-splitting, or are we on to something more profound? Which comes first, the code or the prose? But as I hope I've been able to demonstrate in this essay, the two are intimately bonded to each otherlike unborn twins clasped in a fraternal hug—that we might as well  embrace the ineluctable conclusion that any attempt to disentangle the two (code and prose), would be a futile exercise at best, and folly at worst.



And to bring closure to the metaphor of symbiosis, no book in my mind exemplifies this theme better than Refactoring to Patterns by Joshua Kerievsky (Addison-Wesley Professional). Noted software designer Ward Cunningham had remarked about this book that "Now the connection between software patterns and agile development is finally told". Bruce Eckel, president of Mindview, Inc., and author of the groundbreaking book Thinking in Java (Prentice Hall) went a step further in elaborating how
This book refactors and restructures GoF, and much more. Refactoring to Patterns takes a subject that has been presented as static and rigid and makes it dynamic and flexible, converting it into a human process with experiments, mistakes, and corrections so you understand that good designs do not occur by turning some series of cranks—they evolve through struggle and reflection. Kerievsky has also restructured the presentation to make it far clearer and easier to assimilate. Indeed, he has solved a number of the organization problems that I have struggled with in Thinking in Patterns. This book is a clear introduction and combination of the disciplines of testing, refactoring, and patterns, and it is filled with easy reading, good sense, and great insights (italics mine).

One love
One blood 
One life 
You got to do what you should 
One life 
With each other 
Sisters 
Brothers 
One life 
But we're not the same 
We get to  
Carry each other 
Carry each other 
One...life 
One 
~ U2 (lyrics from One)
A little blue bird tells me that it's time to wrap up. Plus I have this sinking feeling that I've got way more material (on this subject) than can be covered in a single essay. So if anyone is interested, by all means let me know—either here (via your blog comments) or there (by whispering in the ears of the little blue bird—and your truly will get started on a future installment of this essay to elaborate on, and delve into, any thematic aspects that grab your fancy. Deal?

With that, I leave you with this serene pic of the celebrated Fallingwater architecture, suspended as it is in glorious harmony with the surrounding foliage 🌿