I attended the Microsoft Professional Developer's Conference in Los Angeles last week. Microsoft formally unveiled "Longhorn", the next version of Windows, along with a bunch of new underlying technology. The target of the conference was most emphatically developers, and the focus was "how to build stuff with these new tools". My first day's reaction was PDC = Moo!; a positive impression of a lot of cool new stuff. Parts of the conference were excellent; in particular, Rich Rasheed's keynote surveying new technology from Microsoft Research was amazing. But my takeaway is... there's a lot less here than it would at first appear.
If you're still reading and haven't clicked your back button in disgust, let me explain. The most important thing is not how easy it is to build code, the most important thing is how well the code runs once it is built. This concept seems to have escaped the Longhorn developers, and from this viewpoint Longhorn and its underlying technologies are pretty unexciting.
Remember, the audience for the PDC was professional developers. We build code that other people pay to use. It might take five people six months to build an application that thousands of people use every day for years. What's more important, the experience those five people had for six months (and the fact that it took them six months instead of four), or the experience those thousands of people will have for years?
At the highest level there are two things a development platform can to do improve applications: first, improve performance, and second, enable functionality, in that order. Let's take look at Longhorn from this angle.
Performance can be subdivided into speed and robustness. Longhorn will certainly hurt speed. Whether it helps robustness remains to be seen; we can only hope it will, given that this is a big problem for Windows currently.
It is interesting that in all the demos and discussions at the PDC, nobody worried about performance. I have to believe XAML imposes substantial overhead on the GUI (look at what XUL did to Mozilla). And vector graphics? Hopefully it can all be pawned off on GPUs and everything will work okay. WinFS is going to be a big time resource hog. I'm guessing it is painfully slow now and that there’s a bunch of people working hard trying desperately to make it fast enough (not to be confused with fast, period). Indigo isn't far enough along for performance to be assessed, but because SOA is simpler than object proxying Indigo has a great chance to be faster than COM+ or DCOM or .NET remoting (none of which were fast enough to be useful in “real” applications). Let's hope the security wrappers don't kill the basic speed of ASMX; in the real world people still use sockets with no security whatsoever, because they're fast.
In the opening keynote, Jim Allchin made a point of saying "the PDC 'bits' will be slow". He said it unapologetically, like yeah, Longhorn is slow now, but we'll make it faster later. 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. There were zero cases where I heard a presenter at the PDC say "this was done for performance". Functionality for developers was the guiding design principle.
Okay, so maybe performance will be a liability for Longhorn. Surely the amazing functionality enabled by Avalon and WinFS and Indigo means applications will be cooler, right? Yeah, maybe. But let's double-click on this a bit.
Surely WinFS is going to make applications better? I mean, XML metadata for every file. Common data shared transparently between applications. Automatic searching and grouping. What could be better than that? Well, it won't work. WinFS is going to be glacial. Whatever benefits WinFS holds for applications will be overwhelmed by performance so poor as to make them unusable.
How about Indigo? Clearly better, right? Yes, clearly better, as compared to any object-oriented program-to-program communication, like COM+, DCOM, or .NET remoting. (Or for that matter, clearly better than CORBA.) But clearly better than sockets? We'll see. The built-in security functionality of Indigo is compelling, and it is possible that by riding on ASMX (essentially, using SOAP to access exposed services) the overall performance will be acceptable.
So although Longhorn will make code easier to build, it won't really make the code run better. And that's why I'm unexcited. I'm not disappointed, mind you; my expectations were low. On August 16th I posted:
My wishes were pretty low tech, huh? And I didn't get them.
Let me wrap up with something positive. Whidbey looks really nice (the upcoming release of Visual Studio). Not only will it make programmers more productive, but it will make debugging easier and more thorough, resulting in more stable code for customers. And - get this! - it does not look like the wheel was reinvented. It is Visual Studio, but with incremental improvements. Yippee.
So I can keep on cranking C++ for the Win32 SDK. This is your friendly neighborhood curmudgeon, signing off...