"C#, .NET, Visual Basic, FoxPro, COM."

"What are Microsoft technologies that should have died by now?"

It's really interesting how the development community, in light of being a community of engineers, is so enthralled and passionate about subjective analysis and fortune-telling. I recently ran into a few online conversations with some long-time friends that lead me to think back to around 2001 to 2003 - a time rife with predictions about Microsoft technologies - and how most of those predictions never quite panned out.

After the J++ lawsuit debacle, Microsoft decided to take Sun head-on with a brand new (yet another) C-derived language: C#, and its accompanying runtime and base class library. Right from the get-go, Microsoft had a hard time making people take the language seriously, even having to spend an inordinate amount of time explaining how the correct pronunciation was "see-sharp". Well, after 8 years, C# is alive and kicking. And so is the .NET stack. Few Microsoft shops would rather develop solutions in anything else these days. Interestingly enough, while C# borrowed much from other environments (including Java - and not forgetting that Java itself is heavily derivative), Java has in the past few years adopted many things from the C# language, runtime, BCL and IDE.

VB has had a standing obituary for over a decade (which never quite proved to be reliable), but never a more pronounced one than during the first .NET release. People who always hated VB and "classic" VB aficionados alike derided the new "abomination" called VB.NET and perfunctorily declared Visual Basic dead. For some who were passionate about classic VB (and even classic BASIC, if ever there was such a standard), it was not merely that the VB flavor they knew and loved was dead and replaced by this thing so-called Visual Fred, VB.NOT, B#, or C-flat, but also that the new critter in VB clothing would be dead before long as well. Nothing could be farther from the truth. VB in its current incarnation is still the leading Microsoft development language (in terms of market share), beating both C++ and C#, and C# by a landslide at that.

And while Microsoft, in a series of (monumental) marketing and technical blunders and omissions, has shut VB out of certain niches, VB's market share still rivals that of Java according to Forrester, much more so than C#.

Of course, the opposite was also stated - that classic VB would die before long. Perhaps the feeding tube and respirator have been removed, but VB6 has shown a stubborn resilience and unwillingness to fade into the sunset. To me, that's hardly a surprise and only validates what I've said all along - that any development technology that is sufficiently adopted simply can't disappear in a short period of time. Chances are that one of your banks/credit-institutions/card companies/utility companies is still running a 15+ year old COBOL application.

FoxPro. OK, Fox is gasping its last breath if you can't exactly call it dead. It's not really feasible to see that any other way. Unlike VB, FoxPro won't get a reincarnation. However, it does leave behind a legacy. It seeded many of the ideas behind some of the SQL Server tools as well as being an inspirational source for LINQ.

For some who were absolutely giddy about .NET, there was the prediction that all other non-.NET development for the Microsoft platform would fade away - and most specifically, with regards to COM. Look, COM is most certainly a pain in the backside, but I always said it was far too ingrained near the heart of Windows to ever be removed. Like Iron Man, the best you can do is isolate yourself from the shrapnel with a shiny piece of technology. And MS isn't abstaining from developing new things with COM either. For 2005, the entire SSIS pipeline was built specifically for... you guessed it, COM.

Having said all that, there are some things that have indeed bought the farm. Most of them were first stabs that proved somewhat inadequate. The biggest example I can find is Remoting. Not that there was too much wrong with the technology, but it simply wasn't as encompassing or as flexible as its successor, WCF. Of course, Remoting is more like undead than dead (it's still fully supported in the framework, but won't get any fixes or additions), still limping around in (now) legacy applications until someone gets the time to migrate it over to WCF. And WCF is a bit overwhelming for the average crowd, with all its buttons and levers. Of course, if you can complain about WCF's complexity, Remoting is probably not your thing either.

A number of binding technologies seem to be destined for the same fate as well. I don't know if it's just me, but binding is always in a state of flux and nobody ever seems to *finally* get it right once and for all - a state of affairs that I'm sure leaves the anti-binding group in a standing ovation.

And moving forward, I will throw my own prediction into the hat. It's hard to see that LINQ to SQL will survive Entity Framework. It would be a ridiculous situation to have LINQ technology, and yet have no way to query into a database using it. LINQ to SQL seemed to be a ready candidate to fill that hole for the initial release. But it's an extremely poor OR/M, if I'm even allowed to call it that, and is rife with limitations that make it impractical for a lot of scenarios. EF, on the other hand, just isn't finished. It's an ambitious vision to be sure, but once it's done, you will have a much more flexible system that can connect to multiple data sources (not just SQL Server), easily plug into custom entities, removes the lame 1-to-1 mapping between tables and entities, and all while keeping with a simple set of similar designers. In other words, it would effectively do everything LINQ to SQL does and much more. It's also being worked into the guts of ADO.NET Data Services as well.

posted @ Tuesday, September 02, 2008 11:27 AM