A few weeks ago I was in Redmond for the Whidbey Compiler Development Lab. It’s been quite awhile (2 years?) since the last dev lab specifically for .NET compiler authors. It was interesting to see the number of enthusiastic new faces mixed in with the slightly world weary battleaxes.
New guys enter the lecture room, look around nervously for a few seconds, and sit in awkward silence. Veterans amble in, cross the room, and exit through the opposite door with nary a sideward glance. They know where the coffee is!
Building 20 has had a facelift since my last lab there in mid 2004. The good news is that the network center is all-new with firewalls that can finally handle VPN connections to the outside without requiring a special summons of the patch panel genie. Yay!
The bad news is the interior was redecorated by Starbucks. Dark carpet, earthtone olive, mustard and rust wall colors. Every wall a different color. You get the picture. They turned a mostly windowless but well lit and light colored bland interior into a tragically fashionable cave. Oh well. At least they didn’t move the coffee.
Jeff Sandquist was our host, with Jim Miller and several other MS folks (they really don’t like to be called Microsofties) milling around, quizzing the guests, or lurking at the back of the room. The main theme for the week’s seminars was what’s new in the upcoming .Net 2.0 (codenamed “Whidbey”) platform release that would be of particular interest to language implementors.
The speakers did a good job of distinguishing between what C# syntax supports or allows and what CLR supports. (Gasp! There’s a difference? You betcha) Generics, partial classes, versioning, new or expanded IL opcodes, IL patterns that the JIT’r will give special handling to, how Yukon takes control of everything in the managed environment, etc.
Seminars on .NET by the folks that wrote it is certainly great, but the real value of these dev labs is in the opportunity to tear apart a prickly problem in your own application with the .NET dev team looking over your shoulder, and in the opportunity for ad hoc hallway conversations with Microsoft or other attendees. You know, information exchange without the mind-numbing slide show. I think some of the noobs might have missed that last point, as I heard one small grumble about the event schedule not being packed to maximum temporal density.
Borland’s debugger guru Alastair Fyfe also attended the dev lab, on a quest to sort out some .NET and native code debugging issues. Jeff and Jim did a great job of locating and/or kidnapping key MS devs to field our specific questions. Mike Stall stopped by and had an intense debugger jam session with Alastair that bordered on mind meld.
Our hosts pinged us with a few questions as well, mostly to find out what sorts of things our tools are dependent upon to give them a feel for what areas of the CLR (or debugging APIs) they should be careful not to upset, or give plenty of advance warning if they do.
Towards the end of the week the dev lab attendees were treated to a presentation by Jim Hogg (formerly of the CLR team) introducing the Phoenix Project from Microsoft Research. Phoenix is a new architecture Microsoft claims will be the basis for all future Microsoft compiler technologies. It certainly has potential. The real question is whether they will be able to transition it from the warm safe womb of Microsoft Research into the cold hard world of product development.
Now, why would Microsoft demo their super secret proprietary compiler architecture to a group of outside language developers?
Because it isn’t secret and it doesn’t have to be proprietary.