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 richer or more powerful or 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 said Master, 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 entire Lambda: 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 saying Master, 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, saying When 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 wrong.

There are, I believe, many things in our field that exhibit that same kind of duality—what Anton called tension between opposites. Here are just a few:

• Functional vs. OO (Anton's koan is just one example of this).
• Compiled vs. interpreted languages.
• File-based source code vs. live images.
• Relational vs. OO databases.
• Tests as design tools vs. tests as quality tools.
• Browser-based apps vs. rich clients.
• Code as data vs. rich syntax.

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 vs. enabling.

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.)

I'm sitting in on a "webinar" today (how I loathe that word!) hosted by The Conference Depot using some software called On-Site Pro. They recommend that you test your browser compatibility, etc. before the meeting starts, which I did. I was greeted by this:

You are running the Mac OS X Operating System. On-Site Pro no longer officially supports this Operating System.

The application may work for you with limitations. However, for a better meeting experience, please upgrade to a Windows 98/2000/NT4/XP operating system.

Even if I don't like it, I can understand them not supporting OS X. (Although I suspect that "no longer" is stretching the truth ... I doubt they ever did support it.) But calling a switch to Windows an upgrade -- that's going too far. (And never mind that this "upgrade" would require buying new hardware, which they fail to mention.)

I have an XP box here at work that I could use -- but I want to see how serious the limitations actually are. More later.

Update: The limitations are pretty serious: the software didn't work at all. Good thing I had a Windows box handy ... but here's to the day when I won't have to.

… but I have to, ‘cause it feels so good. ;-)

I told you so!

(And heartfelt congratulations, as well.)

Here’s another cat on the loose, leaving an empty bag behind.

For several months now, my friend Stuart Halloway has been talking to me about his new job, and the project he’s been working on. I noticed a couple of weeks ago that the website is finally showing some details—the company is out of stealth mode, and I can finally start talking about it.

Stuart’s job is with a company called Near-Time, and the product is called Flow. It is, quite frankly, the collaboration tool I’ve wanted for a long time. I saw an early version in October, and even in a rough state it was breathtaking. Flow includes the best of Wikis, blogs, browsers, bookmark managers, outliners, and email clients, all in one program. Flow gains a lot of power from having all of those things integrated into one interface (and it doesn’t hurt that it’s a good interface).

Although Flow is useful for individuals, it’s designed for collaboration. It seems to me to be an ideal tool for collaborative research, planning, and development work of various kinds, especially (but not only) if you can’t be face-to-face. Best of all, Flow is a collaboration tool that doesn’t require constant connectivity. The assumption of intermittent connectivity is baked into Flow and the protocols it uses for information sharing.

Near-Time is preparing for an early-access release of Flow in the coming weeks. If you and some others in your group use Macs, I urge you to register and try it out. I think you’ll be impressed.

Via Tom Pierce I found Bill Clementson's list of Lisp quotations. (If you're reading my website, you're probably aware that I'm fond of collecting quotations myself.)

I particularly enjoyed this one:

Will write code that writes code that writes code that writes code for money.

That's as good an answer as any to the classic Lisp troll question: "What's with all the parentheses?"

If you’re interested in software development—even if you’re a non-programmer who wonders if you might ever be able to learn this stuff, or if you’re interested in effective ways of teaching programming—you should watch this video of the Self system in action. (I recommend watching one of the big ones, even though they’re very large files, so you can see what’s going on on the screen.)

This video was made in 1995. It’s a video produced by a software research lab, and that shows in the production values. But you can see in the video the genesis of a lot of today’s software technology. The Squeak user interface system is borrowed from Self. (But we all work in web applications, you say? Avi Bryant is trying out the same ideas in that context.) Self is the original Naked Objects system. The prototype-based OO system that’s at the root of JavaScript (and was central to NewtonScript) originated in Self. Ruby singleton classes were influenced by prototypes. And the implementation technology is equally impressive. Remember that the demo you see is written entirely in Self, and is running on Sun computers from 1995. The techniques pioneered in Self became the basis for Sun’s HotSpot Java VM—one of the names in the credits is Lars Bak, who went on to become HotSpot’s architect.

The Self project at Sun is, unfortunately, long dormant. The web page is still there, and if you’ve got a Mac and are still running Jaguar you can run it. There are still a few problems on Panther, unfortunately. (For that matter, if you have a Sparc machine running Solaris you can also try it out.)

But whether it’s directly useful today or not, it’s still fascinating history, and it’s sobering that although Self has influenced other technologies, those more successful systems are in many ways pale shadows of the original. It’s yet another vivid demonstration that much of the future of computing can be found in the past.

All of a sudden, in the past week or so, a bunch of cats have been let out of their bags. Several of my friends are doing cool things that I haven’t felt free to talk about … and they’re all going public at once. Here’s the first of a few upcoming blog entries about cats on the loose.

If you haven’t read Dave Thomas and Andy Hunt’s Pragmatic Starter Kit books—Pragmatic Version Control and Pragmatic Unit Testing—you definitely should. (They’ve just released a new edition of the unit testing book, covering C# and NUnit. Now that I think of it, that counts as yet another cat recently out of the bag. But since they haven’t sent me a copy, I can’t really write about it, can I? Ahem. :-)

But all along, the book I’ve really wanted to read is the third one in the series: Pragmatic Automation. The one that hasn’t been written yet. Isn’t that typical?

Here’s the breaking news that I can finally talk about: I noticed that it’s now being proclaimed from the Pragmatic Programmer’s website that the author of Pragmatic Automation is Mike Clark.

Now, by way of full disclosure, I have to admit what I’ve already admitted to Mike: when he first told me that he might be doing this, my first thought was, "But I wanted to read Dave and Andy’s automation book!" But that gut reaction was wrong, and it didn’t take me long to realize it. Mike is the right guy to write this book.

Dave and Andy will still be actively involved, of course, and they’ll make sure Mike covers their favorite tricks. But you’ll also get to read about Mike’s tricks. On this topic, more heads are definitely better. Automation is an open-ended topic. Mike is an aggressive automator—he loves to let the computer take over the drudgery for him. And Mike understands that automation is as much about consistency as it is about efficiency.

Mike’s still writing, and the book isn’t scheduled to be available until June. But you may as well set your money aside now. More than ever, Pragmatic Automation is the starter-kit book I’m dying to read.

James Robertson thinks that Java is an interruption in the forward progress of software development. It’s nice to see this meme spread a bit; I’ve thought the same thing since 1996 or so. During ‘95 and ‘96, watching Java start to gain traction, I was amazed by the ignorance and ire surrounding many of what I considered Java’s best features:

• the virtual machine
• garbage collection
• methods "virtual" (in C++ parlance) by default
• a singly-rooted class hierarchy

I came to view Java as a baby step that would serve primarily to soften up developers’ attitudes toward these things, thus shortening the leap required to adopt even better languages like Lisp, Smalltalk, and their ilk. I don’t think I was alone in believing that, but I didn’t hear anyone else saying it for a while.

It is nice to see people returning to serious language research again. Efforts like the Feyerabend Project and more practically focused offshoots like OOPSLA’s Onward! track and the Post-Java Workshops (as well as increasing grass-roots interest in languages like Ruby, Haskell, Squeak, Oz, and even an ongoing Lisp revival) give me hope that we’ll be ready to take a larger step soon.