Ole Eichorn on Longhorn

Tim Bray linked to The Emperor’s New Code by Ole Eichorn. It’s a rant about the new technologies in the eventually coming Windows “Longhorn” release. The jury hasn’t even stepped into the box yet with regards to Microsoft’s new UI paradigm (XAML) and the WinFS filesystem/database, because no one is really using that stuff yet. Ole comments on these untested technologies. Rather than commenting on that, I’m going to comment on the commentary.

First of all, Ole is hung up on speed. He gives tremendous importance to the speed of the code, saying that development velocity really doesn’t matter. It’s true that people aren’t likely to use dog slow programs. But today’s hardware is fast enough that writing everything in C++ is simply not a requirement. If speed were what it was all about, we’d still be writing assembly language.

Ole cautions us to “look at what XUL did to Mozilla”. All right, I’ll look at what XUL did to Moz. Yes, it’s not quite as snappy as a native app. But, it works identically on both my Mac and PCs, and the XUL/JavaScript combination has enabled the Mozilla developers (and plugin developers) to add all sorts of useful features that would take ages to put together in C++. On all of my machines, Moz’s UI is responsive enough, and the rendering engine (written in C++) is plenty fast and does a much better job of rendering than that of IE. So, Moz puts the speed where it really counts: rendering performance (C++) and new feature development (XUL/JavaScript).

I think that features, usability, and possibly marketing are more important than speed. Java programs have generally failed to make any inroads in the desktop app space because they looked like crap and didn’t work like any of the other programs that people owned or used. Windows Media Player is an example of a slow piece of software, but people still use it because of its marketing (it comes with Windows!) and features like the media library. I think most of an app like Quicken could be written in a higher-level language than C++ and still be snappy.

I can appreciate that there may be debug code and features which haven’t yet been optimized, but performance isn’t something you add in later. It has to be designed in from the start.

The phrase “premature optimization is the root of all evil” has been around a long time, and is even cited in Eric Raymond’s Art of Unix Programming, where ESR talks about the pain that can be caused by trying to optimize things before you know where performance problems are. Especially if you’re working the agile way and have tests to back you up, you can make major implementation changes step-by-step to improve performance where it counts.

I do agree with Ole that XAML will not necessarily add anything. There are many things that people have created XML syntaxes for that could just as well be done in standard code.

For some reason, Ole insists that “WinFS is going to be glacial”. I have no idea where that thought comes from. Others have been experimenting with database-driven filesystems for some time. Microsoft has been in the database business for quite a while, and I think they’re quite capable of making a database engine that can handle a typical desktop user’s filesystem efficiently.

Of the 140,000 files, there is one file I care about more than any other, my Outlook .PST file. This one file is a repository of all my emails, sent and received, all my calendar items, and all my contacts. Know why it is one file? For performance. Try storing every email, appointment, or contact in a separate file, and you’ll have the slowest PIM known to man.

The Outlook.pst file is a database. As I understand WinFS, that’s a database too. And it’s probably going to be based on very similar code. Storing every email in a separate file will be the same thing as storing them in separate records in the Outlook.pst file.

Microsoft is taking some large steps with Longhorn, but they’ve got a ways to go yet. There are interesting projects (like Storage) going on in Linux-land and I’d really like to see some Linux-based desktops gain traction before Longhorn ships. Competition is a good thing.

(Updated to add a paragraph about program speed)