Interesting blog entry from my old friend and colleague Steve Trefethen on Microsoft APIs. Steve brings up a lot of good points, and I particularly agree that the API landscape is way more fragmented and confusing than it should be, and we at Microsoft need to fix that. However, I also come in on the opposite side of several issues Steve raises, so I thought it would be worthwhile to call out a few specific points.
It seems Redmond has one-upped Google by putting out alpha software and beta software with "Go Live" licenses. How long will it be before we see alpha software with a "Go Live" license? Are we to believe businesses today are betting their future on all of this pre-release code?
While I agree the proliferations of alphas, betas, CTPs, etc. can be confusing, I actually don't feel this is a bad thing. Years ago, Microsoft (and the industry as a whole, for that matter) was much more secretive about project under development. These days, customers overwhelmingly prefer transparency, even knowing that transparency means working with software that has a few warts and is subject to change in shape and behavior. The comparison with Google is also interesting because Google customers have clearly been very happy to use services that Google has deemed beta quality (Gmail, Maps, Toolbar, etc.). Given the way folks are voting with their feet in favor of these things, a reasonable person could conclude that customers often find value in software even if it's not considered "RTM quality."
Is [an MSDN statement comparing WPF to GDI] implying that the new Office 11 Ribbon UI is "constrained? Ah, but it's not .NET so it must be constrained. And what about Vista's fancy new albeit unmanaged UI surely that must be constrained right?
Nobody ever said that all things .NET were constrained. The referenced quote was making a point that it's a great deal of work to build WPF-quality user interfaces with straight Win32 because Win32's GDI is old and crufty. Of course you can build the Office ribbon and cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives.
Btw, where is Microsoft's developer support for the new Vista UI? That's not due to arrive until Orcas ships. Didn't the MFC guys know when Vista was going to ship? Or was it that it just didn't matter until recently?
Our bad. While Developer Division was successful in launching .NET 3.0 technologies (e.g., WPF and WCP) with Vista, we did not deliver comprehensive tooling that enables developers to easily take advantage of the breadth of the platform. Yes, the MFC guys (i.e., my team) knew Vista was coming. We were just not agile enough to release such a product before Orcas. However, making mistakes is also a great way to learn, and you can bet that future tools releases will have better schedule alignment with major platform releases.
It's almost as though the Microsoft factory is stuck on hyperdrive. They're competing with Linux, Apache, PHP, Flash, Eclipse, Java, Oracle/MySQL/DB2/etc, Google, Mozilla, Open Office, MySpace, Yahoo and over the past 12 months have released betas in nearly all of these areas.
I wouldn't say that we're in "hyperdrive." This is who we are. We're the world's largest software company, we have broad product and business portfolios, and we're going to be very competitive in all of the markets we serve. However, I do think it's fair to say that because of this broad scope, Microsoft is less technologically homogenized than in past years, which can mean a lot of different platforms with a lot of different APIs which can result in a lot of confusion.
Staying with Microsoft tools will undoubtedly mean moving to .NET...
No way, Jose! In fact, the Visual C++ team's primary focus is on the native Windows platform. We have some very aggressive post-Orcas plans for advancing the state of the art of native development. Our secondary focus, btw, is on native-managed interop, with the goal of enabling ISV-style applications to have their cake and eat it too by getting full value from their native code while still incorporating and benefiting from .NET technologies (or bringing together the Raymond Chen camp and the MSDN Magazine camp, to use Joel Spolsky's taxonomy).
I might also add that Olivier Giroux over at NVidia (who takes a wait-and-see approach to all of this new technology) intimates why native C++ code will always be important:
...I have to write cross-platform software by day...
In fact, many of our best C++ customers use C++ because it enables them to target almost any platform, whether it's consumer software on the Mac or server software on Linux or avionics software running in a jet fighter. These customers require the portability and/or the runtime control offered by C/C++, but we do need to make sure they also have a development-time experience comparable to that of the managed code developer.
Does anyone know what will really happen to WinForms with WPF being touted as the new UI for Windows? Will there be an Interop WPF toolkit available to move your WinForms apps one form at a time to XAML/WPF?
I have a couple of thoughts on this: first, WPF does not currently have the features and capabilities necessary to supplant WinForms as the framework of choice for line of business style applications. I know we've tried to message this appropriately, but I agree that it sometimes gets lost in the WPF enthusiasm. Projecting down the road, I would ask: what are your expectations? If, some day in the future, WPF does overtake WinForms in terms of LOB capabilities, my expectation would be that we would continue to support WinForms for existing customers but recommend WPF for new code. Or am I talking crazy talk here? Meanwhile, we do intend to support mixed WPF-WinForms apps in the Orcas release. A WinForms to XAML converter is something I know people have talked about internally, but I expect customer demand would dictate what we do here.
The sad thing is that I'm actually interested in several of these technologies but the field is increasingly looking like the slide from Stephen Colbert's The New AT&T (see about 50 seconds into the video). I've been trying to keep up though it seems a lost cause with each passing day I'm falling further behind.
First, props for the pointer to Colbert's hilarious AT&T video! More seriously, my view on this is that the day has long passed where it is practical to keep up with every developer technology coming out of Microsoft. Ten years ago, it was totally doable and expected that any "real" developer was totally on top of all of the new stuff coming out of Microsoft. Today, software developers are more specialized. A developer may focus on web applications or ISV-style native apps or LOB apps or mobile or SOAs or some industry vertical or some other spoonful of alphabet soup. Or maybe even one or two of these. After all, most of us have day jobs and the world of Microsoft platforms is so big that simply understanding it all to any reasonable level of depth would be a full time job in itself.
That said, I'm not going to hand-wave away the fact that there are areas where would do have overlap or should better aligned or must be better at messaging when and where to use what technology. And we also need to better align platform and tools releases. All of these things are true. But I don't believe it should be a fundamental goal to homogenize our platforms and APIs before letting anything out the door.