Archives for the year of: 2007

After finishing Brand‘s How Buildings Learn a few weeks ago, I picked up another Brand book: The Clock of the Long Now which discusses (among other things) how one would design a clock intended to keep accurate time for 10,000 years. Chapter 11 lists the key design principles that the clock’s principal designer decided were most important to the clock’s success or failure. The principle that caught my eye was transparency.

(segue from discussion of clock design to software design)

Transparency is the quality of how easy (or hard) it is to understand how a mechanism works. Upon reflection, one of the reasons that I favor the pure Ajax/REST web architecture I described earlier is because it’s easy to mentally separate into three parts (browser, wire, server) and it’s easy to understand how these parts interact (HTTP requests from browser to server via wire; HTTP responses from server to browser via wire). Why is this ability to compartmentalize subsystems desirable? Because it’s easy to debug when something inevitably goes wrong.

But there’s a tension here; abstraction in software is supposed to be a good thing. The pace at which we can develop software has increased substantially for those of us who don’t have to worry about (for instance) pointers, packets, and concurrent access to persistent storage. Yet anyone who’s tried to debug a problem within an überframework will tell you that it’s hard to figure out where the error’s occurring (their code or your code), let alone fix it. This tension was described in Joel Spolsky’s the Law of Leaky Abstractions article. Net: all abstractions are imperfect, and when a mechanism underlying an abstraction fails, it’s difficult to understand and remediate the problem since the abstraction previously allowed you to remain blissfully ignorant of the underlying mechanism.

So from a design point of view, both abstraction and transparency have merit. Abstraction reduces the amount of detail one needs to master in order to accomplish a task or apply a concept. Transparency makes it easy for new team members to understand the flow of the system and allows developers and administrators to quickly track down and resolve problems. So how to find a balance between these two qualities?

I have some not-fully-formed thoughts on this question, so I’ll save them for a later entry, but I’d be happy to hear others’ thoughts in the meantime.

Related to yesterday’s post, I just caught up on the comments to Peter Gurevich’s (MS IE Performance PM) guidance to avoid using closures in IE. Matt Kruse had a perfect, concise response which I feel compelled to quote here verbatim:

Closures don’t cause memory leaks.

Browsers that have garbage collection bugs (IE6) and continue to retain those bugs in new versions (IE7) cause memory leaks.

Closures are an extremely powerful and useful programming technique. It’s unfortunate that you would recommend against their use simply because your browser has a bug that causes a memory leak.

A huge amount of time has been spent by the js community to detect, resolve, and work around these IE memory leaks. It’s too bad this was required, and will continue to be required as long as MS refuses to fix the problem.

Hopefully IE’s market share will continue to drop and we can begin to ignore these memory leaks because every other browser out there handles closures just fine.

+1.

Peter Gurevich, Performance Product Manager for the Microsoft Internet Explorer web browser, just wrote the third part of a blog series on improving the performance of Javascript execution within IE. Peter’s trying hard to help developers, but he’s got a thankless job since many of the problems are the result of not so much developer coding errors as IE design and implementation problems. The situation is compounded by the bitterness many developers feel towards Microsoft for taking a long vacation from major IE enhancements after winning the browser wars though a combination of rapid innovation and monopolistic business practices.

So when I hear Peter say things like:

Closures (functions that refer to free variables in their lexical context) are both extremely powerful and extremely dangerous. There are certain programming techniques that demand their use and once you learn how to use them they can quickly become one of the most overused features of the JScript language. Currently the misuse of closures in connection with the IE DOM and various COM components are the number one cause of heightened memory usage within IE.

While this is all true, it’s frustrating to read since he advises to avoid idioms that are not necessarily incorrect or misguided from a language perspective, but rather they’re problematic in the context of IE’s rusty engine. It’s like calling to report a busted-up highway and being sent a map of the backroads.

So while these posts on care and feeding of IE provide useful information, I’d also like to see frequent transparent communication on what Microsoft are doing to address the most fundamental problems that their browser presents to web developers.

What is Microsoft doing to address IE’s problems? Though they say they’re working on it, they haven’t published any concrete goals or plans for IE vNext. More transparency is welcome. What should they do? Rewrite or replace the layout engine. And the Javascript implementation.

Once again I must stress that I applaud Peter for writing these articles, but Microsoft also needs to communicate (in detail) about how they’re addressing root causes.

Based on guidance from James Snell and a WordPress plug-in from Ben Smedberg, I’ve removed the RSS feeds from this blog and replaced them with Atom 1.0 feeds.

Thanks James and Ben.

I’ve had a blog on IBM developerWorks since October 2004. But, I think I’ll do a personal web site and blog to experiment with new technologies that I don’t use at work and also so I have a place to post stuff that’s got nothing to do with my job.