Stefan Kleine Stegemann

Programming languages vary in their expressiveness. Why is expressiveness important? Because it’s closely related to abstraction. If I can code at a higher level of abstraction, I’m more productive and the code usually better expresses what it achieves. Example? Determine the date at 12 days and 5 hours in the future:

SMALLTALK:
future := DateAndTime now + 12 days + 5 hours.

JAVA:
Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
cal.add(Calendar.DAY_OF_MONTH, 12);
cal.add(Calendar.HOUR_OF_DAY, 5);
Date future = cal.getTime();

(Sun could at least make Calendar’s add method return the Calendar itself so that we could daisy-chain the add calls like cal.add(…).add(…)).

Good old Smalltalk obviously wins. And it wins not just because the libraries are so well designed (I have to admit that the example is a bit unfair because the Java Calendar class really represents the bottom end of API design). It wins because expressiveness is build right into the language. Surprisingly, the Smalltalk language with its very few concepts is more expressive than Java that is way more complex, especially these days where Generics hit the ground. Here, the “everything is an object” metaphor together with dynamic typing makes the difference.

I keep a list of the blogs I frequently read in my del.ico.us bookmarks. Every blog I’m currently interested in is bookmarked under the tag “blogroll”. I prefer reading the blogs in a web browser over feed readers or aggregators. Therefore a bookmark points to the blog’s webpage and not to an atom or rss feed.

Yesterday I wanted to create a list with the authors of all blogs I’m currently reading. Unfortunatly, there is no way to safely extract this information from a webpage (oh dear, we are still lightyears away from the semantic web). The only way to discover details about the author is to look at a blog’s news feed. Atom feeds usually have an author element with meta information about the author. Rss feeds don’t but at least the email address of the creator can be extracted from most feeds. Luckily any blog I’m aware of provides a feed in atom or rss format. Information about available feeds is usually encoded in the header of a blog’s webpage. For each feed, a link element with rel="alternate" exists that specifies the feed’s URL and type. So the solution to my problem was to extract the feed URLs from a webpage, load the feed and get the author from the feed header.

Now I could have used regular expression to extract the alternate links. However, I recently came accross Hpricot, “a fast, enjoyable HTML parser for ruby”. And while I find regexps quite useful, I’m not a particular fan of them, especially when they get complex. So I decided to give Hpricot a try. I wrote a little ruby script to extract feed URLs from a webpage. At its center is the following code:

   def discover_feed(href)
      doc = Hpricot(open(href))
      feeds = []
      doc.search('//head/link[@rel=alternate]').each do |candidate|
         if candidate['type'] =~ /^([a-zA-Z]+\/)?([a-zA-Z]*)+.*$/
            format = $2.downcase
            feeds << {:address => candidate[’href’], :format => format}
         end
      end
   end

Thanks to Hpricot’s XPath-Style queries, finding all alternate links in the header is almost a no-brainer. I then use a regular expression to extract the feed’s format from the link’s type attribute which specifies a mime-type. The discover_feed function returns an array of hashes, one for each feed. I can now easliy select a feed:

   avail_feeds = discover_feeds(webpage)
   feed = avail_feeds.find {|f| f[:format] == 'atom'} || avail_feeds.first

The second line looks for an atom feed in the first place and falls back the first available feed if no atom feed has been discovered. Quite simple, it took me around 30 minutes to write the whole script (including installation of Hpricot). Working out a regular expression would have taken much longer (at least for me). Not to talk of the nightmare of remembering what the expression was meant to do when looking at the code next month.

Nothing new, I know. However, I just discoverd that Internet Explorer scrambles my brand new weblog. Among some other odds and ends the header is not displayed correctly. The layout is decent in Safari, Firefox and companions. It is even displayed correctly on my Nokia N80 browser. Only IE is not able to get it right. So here is my strategy: if you are looking at this page in IE and you are disgusted by the broken layout, go and download Firefox. I will not spend a minute to tweak this site for IE.

I write quite a few research papers these days. And I read many of them. I often find myself stuck in a paragraph or sentence. Its the feeling that something is wrong, that the argumentation is unclear or that I don’t know how to continue. The same happens when I read papers. Sometimes the argumentation seems clear but I feel that there is some important bit missing. In (luckily) rare cases, it seems that really I don’t get what the authors want to say. Most often the solution to the problem is the problem itself: WHAT IS THE PROBLEM? To me, that’s the most important question for writing and reading. This is a lesson that I’ve learned during many interesting and valuable discussions with a good colleague and friend. So my solution to the “stuck writer situation” is to get the problem right.

• Write down the problem
• Get the argumentation for the problem right (references from literature)
• Describe and discuss the solution
• STICK TO THE PROBLEM. For me, it’s often tempting telling the reader about too many side-aspects. I would bet that in 99% this leads me to the wrong track.

While the solution is simple, its surprises me how often I make the same mistake of not getting the problem right or leaving the track. It just happened some minutes ago which motivated me to write this post. And its not me alone. Many scientific papers fail in getting the problem right or in justifying the problem. In the worst case, the result is some unclear bla-bla about this and that. It feels that such a paper never hits the spot. And yes, I wrote such papers myself.
Hitting the spot is IMO what makes articles from authors like Martin Fowler such a pleasure to read. He has a problem and writes about the solution to this problem using a great style of writing. Simple as that.