Windows bug o' the day

Don't try this at home: select a bunch of folders in Explorer and select "Search...". Rather than bringing up a search window that searches the folders, it will slowly bring up a bunch of the buggers (one per folder) and then, in my case, crash hard.

BTW: one of the most irritating things about explorer.exe crashing is that many taskbar icons vanish when it restarts. Fascinatingly, although MS provides an API for apps to use to restore icons on a crash, MS's own Task Manager doesn't actually implement it.

Insanely bad Outlook 2003 search folders

I just took the leap from Outlook 2000 to Outlook 2003. Gratifyingly, the upgrade was flawless (so far) and pulled all my settings across, even including the SpamBayes plugin which has continued doggedly making spam a dim memory.

However, one of the features that I thought I would like most about 2003, Search Folders, appears to have been implemented in an afternoon by an undergrad arts major. The default views such as "Unread Mail" are of course useless for anyone that filters mail, especially since a lot of unread mail is spam. And you can't customize the criteria for inbuilt views: the button is simply greyed out. It's also hard to restrict the folders you want to scan, since you can either select "recursive" mode for all folders or for none, and then select everything manually, a real problem for people like me that have about 20 folders.

To make it worse, once you've worked out that you need to create your own search folder you can only specify AND for combining criteria. I want to show unread OR flagged mail, which doesn't seem to be supported even in the advanced area (which doesn't actually have an "Unread" field to select anyway, even though other parts of the UI display it). There is a "Unread or For Followup" inbuilt view, but it shows nothing and I can't see what criteria it uses because, surprise surprise, the button is greyed out.

And then, in case I was still in the mood for self-flagellation, it turns out that Outlook 2003 has some insane number of different coloured followup flags you can use, and I cannot match any of them to the ones already in use in my inbox (there's no "faded red" flag icon in the menu, just red and orange).

Since I'd consider myself an expert Outlook user and in a good position to evaluate this product, I hereby award Microsoft -3 out of 10 for usability.

PS: on further investigation ... it gets worse. Trying to sort by unread and then by ascending date just gets ignored - the ascending date part is not there when you go back to "Customize View" no matter how hard you swear at the dialog box. Even better, selecting the "Unread Messages in This Folder" view while in a search folder produces a broken blank message list. Glad this product has shaded buttons, 20 flavours of followup flag and alpha-blended fading mail alerts, or I'd feel ripped off.

C# and virtual methods

Continuing my ramblings on C#'s default to non-polymorphic (non-virtual) methods, I've been revisiting an excellent series of interviews at artima.com with Anders Hejlsberg, daddy of C#. One quote is of particular interest:

Bill Venners: In Java, instance methods are virtual by default—they can be overridden in subclasses unless they are explicitly declared final. In C#, by contrast, instance methods are non-virtual by default. To make a method virtual, the programmer must explicitly declare it virtual. Why is non-virtual the default in C#?

Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.

This is a very telling statement because (a) it's wrong - it's not a performance issue in Java and (b) because it's not consistent with another key C# design decision. Java classes are JIT'ed at runtime when information about subclassing and method overrides is known, so that JIT can easily auto-"final" methods and classes. The only reason for the programmer to use final is to ensure safety API-wise.

The inconsistency is that, if methods are "sealed" by default to make API contracts safer, why aren't classes also sealed by default? I think the real reason is that C# required sealed methods in order to not suck when linking against precompiled classes (eg the entire .NET standard framework), but sealed classes wouldn't have made much difference. If Anders actually believed what he was saying about sealed methods in API contracts, then it would apply to classes too.

I think the real reason for these design decisions in C# is that this is the same default as C++, a language whose author unabashedly admits major design decisions were driven by performance, not safety.

Blogs adding to knowledge fragmentation?

Continuing my rambles on RSS, I've been vaguely worried recently that RSS-based weblogs add yet another level of fragmentation to the information store that is the internet.

Once upon a time there was Usenet, which was one of my primary knowledge resources. The advent of Deja News (now Google Groups) was a big leap in being able to tap into other people's expertise. Now I monitor mailing lists, RSS feeds, web-based forums not to mention instant messaging logs. It worries me that I often search Google Groups and get invaluable information, yet rarely contribute because of the low signal-to-noise ratio. How do I search the information sources that I now contribute to?

RSS and webcasting

Now I know why I started to feel a little deja vu coming on when I finally twigged onto RSS's rise to prominience. It's webcasting come back to haunt us.

Some of us remember the non-event that was webcasting back in the heady days of the Netscape/Internet Explorer Wars. Netscape had Netcaster and Microsoft had Active Channels (there was so many "Active" products from Microsoft in those days that I initially thought "ActiveX" was a joke based on their naming scheme). Everyone was very excited about who would win the war (they both had incompatible channel formats of course), and there was much serious discussion about how terrible it was that news sites had to support both.

And then it all just faded away, probably because it was a classic solution-looking-for-a-problem technology that no one actually wanted. And also because there wasn't much interesting content: it was designed around the idea that big news sites would use it rather than as a grassroots tech.

Now we have the grassroots rise of RSS, which provides 90% of webacasting and which people actually want and use.

Java vs .NET runtime optimization

This article is yet another article showing Java beating C/C++ in several benchmarks. There are quite a few of these around, and whether you have problems with their methodology or not, I think they provide cumulative evidence using C++ for performance alone is pointless. I think it's likely that the only people remaining in the "Java must be slow" camp don't actually use it.

Interestingly it contains a discussion on why Java might be able to beat C++. There seem to be two main reasons why:

1. The Java JIT can make global optimizations at run time that aren't possible at compile time: this includes system classes.


2. The removal of arbitrary pointer manipulation allows not only safe GC, but also safe inferences about aliasing.

Some of real wins come when the JIT can de-virtualize and inline methods. For example, although any method on HashMap might be overridden by a subclass, 99% of the apps out there won't subclass it. For those apps, methods like HashMap.isEmpty () can be inlined and reduced from a virtual method call to three bytecode instructions (and probably two in machine code).

In fact I believe the main reason why C# defaults to non-virtual methods is because of the CLR's use of precompilation, which means that having every method virtual would be a big performance hit. So in the CLR, de-virtualization effectively needs to be done by hand. C#'s designer makes a virtue out of a necessity by claiming this is a better idea anyway: you should design for overridable methods. While I can agree with that, there's no reason not to use virtual by default and use "final" when you really don't want to have someone override a method.

MS actually recommends you do not use static compilation in this MSDN article, making the same claim that the JIT can produce much better performance. So why do they precompile the CLR framework classes and remove the opportunity for global optimizations?

Development Platform Franca

All the discussion on Slashdot today about the release of Mono 1.0 (people variously asserting that Mono is the devil, Mono is crucial to Linux, Java is better, nyah, nyah, your father smells of elderberries) got me thinking again about what the real values of Java as a platform are. As a language it's fine, but other OO languages are good too. The API's are fine, plenty to choose from but that's not it it either.

It has struck me more than ever over the last couple of years or so while Java has really matured that its real value is as a lingua franca development platform, not a language or a VM. The platform developers agree on language (Java), API's (XML, net, logging, threading, etc), namespace management, API documentation (JavaDoc), build systems (Ant and Maven, standard build layout in src, lib, classes, etc) deployment (especially for web deployment) and even IDE's to some extent (a number of projects I received recently came with Eclipse project files). You can take big web app developed in SunOne and have a very good chance of running it in WebSphere or Tomcat/JBoss. I've developed my own web apps in Tomcat on Linux and then dropped them into WebSphere on Windows without issues (this ability to move apps around must give Bill Gates the shivers).

This standardisation allows me to grab some fairly complex libaries and frameworks and just use them, without worrying about what hokey build system, source code layout, language, memory manager, collections framework, homegrown logging system or dirty preprocessor tricks it uses.

The language part of the Java platform is the smallest part. It's a standard: I don't particularly care what the standard is, just that it's good enough and that everybody agrees with it. The common language is important across projects too: although I can use a library in .NET that's written in Eiffel# I'm likely to have some problems if I need to dive into the source to work out what I'm doing wrong. The language-geek dicussions about generics, value types, checked exceptions, etc are, while interesting, just not germane: none of these are features that would influence your choice of platform. The key choice is the environment: platform API's and runtime containers.