Oh My Favorite Demo Of The Whole Show Was One I Got On A Bus Ride Steven Burns Showed Me The Longhorn Shell Which Advances

Oh, my favorite demo of the whole show was one I got on a bus ride! Steven Burns showed me the Longhorn Shell, which advances the “pipes and filters” pattern of UNIX by piping not text streams, but object streams! So, for instance, you can grab all the currently running process with a ps command (well, get/process is the “real” name, but alias get/process ps works), and then because what’s being streamed are real objects and not just text streams, you can filter it with an arbitrary query against an object-specific property (ps | filter handlecount -gt 400) and then pump that into different formatters: ps | filter handlecount -gt 400 | tableformatter or ps | filter handlecount -gt 400 | xmlformatter or ps | filter handlecount -gt 400 | listformatter or ps | filter handlecount -gt 400 | FullGuiFormatter (I’m handwaving at what the real “full GUI formatter” command is, but I saw it work).

You know, rendering a GUI transition with AfterEffects is very nice and all, but sysadmin scripting: priceless.

The First Modeling Tool From Microsofts New A Hrefhttpmsdnmicrosoftcomvstudioproductinfoenterprisedefaultaspxpul

The first modeling tool from Microsoft’s new “Whitehorse” initiative expresses deployment topologies and the constraints that work upon them (e.g., by dropping a “Hardened IIS” component in your DMZ and a “Web Services” component in your middle-tier and connecting them, you are expressing a whole slew of constraints about what ports are open to whom, what sorts of connections will be accepted, etc.). This is not just a nicely pragmatic tool, it is also not something addressed by UML. I asked Keith Short if the decision to avoid (or at least delay) a direct conflict with UML was deliberate. “Absolutely,” he told me.

At One Of The CLR Evolution Talks I Disagreed With The Prevailing Notion That Serving The Needs Of The Current Lang

At one of the CLR evolution talks, I disagreed with the prevailing notion that serving the needs of the current language community should be of paramount concern. To me, interop trumps language fidelity. It is only via interop that minority programming languages can enter the corporate market. Crown-jewel software is always so complex that it constitutes its own domain; the idea that the Bus Factor (the number of people whose death in a bus run-down would be catastrophic to the company) can be minimized by using a majority language for the crown jewels is largely an illusion. The problem isn’t the crown-jewel software, it’s the other stuff, the administrative interfaces, the reporting functions, the integration bridges, that are legitimate arguments against the use of minority languages in corporate environments.

So the argument goes, “Well, the current language enthusiasts demand the fidelity or they won’t have the opportunity to create the crown jewels in their unique way.” But my argument is that adoption is driven by the young. It’s the kids who are just entering the marketplace who are going to do something astounding; it’s the kid who doesn’t give a fig about language fidelity who’s going to combine X with Y in a way that gives his or her company a real competitive advantage. Software advances not by theory, but by the unexpected consequences of implementation. The ultimate success of the .NET platform depends upon how pragmatic it is to combine trail-blazing components that exploit some unique expressiveness of a minority or domain-specific language with the support and infrastructure components of the more mainstream “homesteading” languages.

MS Languages Diverge in Whidbey

For the past two years, convergence has been the theme in Microsoft languages. Visual Basic .NET was a significant break from VB6 and is a very similar experience to programming in C#; Managed C++ gained the use of visual forms design; everything worked inside Visual Studio .NET. The theme of Whidbey at the compiler level is that the languages are diverging — VB.NET will have unique things (edit and continue), C# will have unique things (closures), and C++ will have unique things (deterministic finalization). As you can see, these divergences are to the service of the languages’ core audience (VB.NET: programmer experience, C#: language expressiveness, C++: control and performance).

There are other things, most notably generics, that will be shared across all languages. One of things that I was very interested at the various discussions of CLR evolution is the concern that the unification necessary for interop (what I described immediately following the BoF as a concern for the BCL, but which really extends beyond that) may impede innovation in languages: it may be the case that every language can agree to the existence of an int but with concepts such as IMap<K, V>, it’s not as sure a thing.