September 24, 2006
In his recent essay, Design Patterns of 1972, Mark-Jason Dominus–a long-time favorite writer of mine from the Perl community–writes:
Had the “Design Patterns” movement been popular in 1960, its goal would have been to train programmers to recognize situations in which the “subroutine” pattern was applicable, and to implement it habitually when necessary. While this would have been a great improvement over not using subroutines at all, it would have been vastly inferior to what really happened, which was that the “subroutine” pattern was codified and embedded into subsequent languages.
He draws this analogy because, he believes, the “Design Patterns” movement, noble in its intent, has weakened programmers by desensitizing them to defects in their tools.
The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.
This isn’t the first time he’s made this point. Several years ago, he offered a presentation on Christopher Alexander, where he asserted that the “Design Patterns” movement has turned out to be less useful for programmers than what Alexander proposed for architects. (To reduce the possibility of misunderstanding, it’s probably best to skip ahead and read slide 9, slide 10, slide 11 and slide 12 first.)
It’s sometimes difficult to envision a programming language embodying what we commonly think of as a pattern, which is why his analogies to the “subroutine pattern” of the 1960’s and the “object pattern” of the 1980’s are so perfect.
September 9, 2006
Ajaxian points to an article on a so-called “Live Filter” pattern (if the original article‘s site is down, see the Google cache).
The definition from the article:
We propose that for many problem domains, the basic concept of filtering is now much more appropriate than searching. With a search, you start off with nothing and potentially end up with nothing. Counter to this approach is filtering, where we present everything available, and then encourage the user to progressively remove what they do not need. Using Ajax to provide immediate feedback, we can display the number of results a user can expect to see if they were to submit their query at this moment.
The original article goes into many details about how it’s implemented underneath, and there is a Live Filter demo available.
This seems very much like a solution in need of a problem. For example, nowhere in the article is there a mention of faceted searching/navigation. It’s unclear why faceted searching did not meet the author’s needs, or why the concept of filtering should be thought unique in 2006. In all, it looks a bit like an excuse to promote AJAX and, especially, Ruby on Rails.
Judging by the demo, this is a poor man’s faceted search system. When you click on one of the (static and pre-determined) “filters”, the only thing the AJAX interface gives you is a message that reads: Your search will return 7 results. and a button you can click to actually see the results.
A real faceted search system, on the other hand, will present you with context-aware options and immediately tell you how many results each option will give you. This is usually implemented without AJAX, but an AJAXY interface can be a great design help: hiding suboptions, preventing full page refreshes, or even displaying the best results for an option as you hover over it.
I can see how “live filters” are slightly better than a normal search box for some specific, narrow applications, but, compared to building out a faceted search system, you might as well be doing all this in a TN3270 terminal.
The original article goes into good detail on what’s unique about Ruby on Rails in making building and maintaining this applicatation easier than on other platforms. As an introduction to building applications in Rails and/or server-side AJAX design considerations, it’s great, and probably on par with a lot of toy applications you’ll find in intro books. (I recommend looking at Live Filter source.)
August 5, 2006
As I hit the road for SIGIR in Seattle, I leave you with Steve Yegge’s anti-OO rant, which I just happened across when I was supposed to be napping this afternoon (I never did sleep today). He makes good points in a humorous way. Even if you’re not a programmer, you will be able to read this and understand his main point.
I am fascinated by programming languages and the evolution of language features. I am even more fascinated by language zealotry.
It’s certainly true that Java programmers tend to either discount or even not acknowledge alternative viewpoints. Then again, the first third of Programming Python is 95.263% advocacy rather than substance. I just chalk it up to culture.
And so, the sun is set, my car is packed, I am wired, and the roads are becoming empty… now’s just the right time to be leaving. I will blog more from the conference….
(I owe several people e-mails. I will tend to those during the week.)