|« March 2015|
Chad Fowler (via del.icio.us) pointed me to a delightful
post on the ll1-discuss mailing list. The discussion had turned to closures
and objects, and which could be considered
more fundamental. Anton van Straaten chimed in
with a post that I think summarizes the issue perfectly. It's
worthwhile to go read the
whole thing, but the core of it is this:
Given this tension between opposites, I maintain that the question of closures vs. objects should really be a koan. [...] Here goes:
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton saidMaster, I have heard that objects are a very good thing—is this true?Qc Na looked pityingly at his student and replied,Foolish pupil—objects are merely a poor man's closures.
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entireLambda: The Ultimate …series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by sayingMaster, I have diligently studied the matter, and now understand that objects are truly a poor man's closures.Qc Na responded by hitting Anton with his stick, sayingWhen will you learn? Closures are a poor man's object.At that moment, Anton became enlightened.
Why did I enjoy that so much? If you read this blog, you know that
I'm fond of dynamically typed languages. I frequently encounter
blogs, articles, or mailing list postings from people who believe
dynamic typing is
the one true way (I've been guilty of such things
myself, in fact). And then I turn around and see people claiming
that strong static typing has undeniable benefits, and it's just too
hard to build reliable software in dynamically typed languages
(ignoring the numerous counterexamples), etc., etc. And the thing is
… I don't think either side is entirely right or entirely
There are, I believe, many things in our field that exhibit that same
kind of duality—what Anton called
opposites. Here are just a few:
You could write a koan about each of those.
(I'll note in passing that although the Zen koan is a delightful form for capturing and expressing such tensions, Zen doesn't have a monopoly on such ideas. For just one example, compare Galatians and James. They seem at first glance to be in contradiction, and yet the core of each can be found in the other.)
I titled this blog entry
Six of One, a Half-Dozen of the
Other. For most of these things, I don't think it's really an
even split … but the alternatives are weighted differently, and
how you value them depends on your preferences, needs, fears,
and experiences. To a great degree, I think it comes down to our
predisposition toward another set of opposed concepts: directing
As much as I enjoy arguing my side of these things with all the force I can muster, studying the history of our field has led me to conclude that there are inherent trade-offs in every one of the choices listed above. Neither side solves every problem; rather, each side has some strengths and some weaknesses relative to the other. While it may be fun to take sides (and I'm sure I'll continue to do so), at some point the most productive course is to try to really understand the relative merits.
Once we do that, it will become clear that the choice boils down to what we value most … and thinking about those values would be much more fruitful.
(If you have other examples of such dualities in software development, I'd love to hear about them. Please let me know.)