Readers of my prior posts about the "My" Classes planned for VB 2005 know that I am pretty enamored with them: here, here, and here. I think the "My" classes have the potential to become one of the most significant productivity features of VB 2005 and beyond, and could result in a huge reduction in development complexity.
However I recently read several articles about extending the "My" namespace that have me extremely concerned. The first was by Anand whose article was entitled "Extending the "My" Namespace." Both The Microsoft VB Team‘s Paul Vick and TheServerSide.NET‘s Ted Neward picked up on Anand’s article here and here, respectively.
The second article was by Keith Franklin entitled "Oh My!! – A Look at the My Namespace in Visual Basic 2005" in Code-Magazine‘s Sept/Oct 2004 issue. Though don’t quote me, I also seem to remember Mike Sax talking to me about how he would like to extend the "My" namespace with serial communication functionality.
(Note: I deliberately use the terms "classes" and "namespace" interchangably because because "My" encompasses both classes and a namespace, and because collectively others have used both terms.)
I definitely respect the writing and development skills of both the authors of the two articles I quoted, and I think they did an excellent job of explaining in technical terms how to extend the "My" namespace. I also respect Mike Sax’s ideas and opinions very highly too. So please don’t take this as a criticsm of them or their articles or ideas. Instead just take it for face value.
So after reading those articles, you’ll now know how to extend the "My" classes in VB 2005. However, just because you can extend the "My" namespace doesn’t mean you should!
I’ll go ahead and give the benefit of the doubt to everyone else as it is possible the problems caused by extending the "My" classes are not be immediately obvious. Maybe the past 10 years running the leading reseller of components for Microsoft-centric developers (via VBxtras and Xtras.Net) has given me specific insight into this issue that others without similar experience would be hard pressed to have.
As a way to explain why extending "My" would be a bad idea, let me anticipate for you both a positive and a negitive future, five years hence. In the positive future:
It’s 2010 and Microsoft has released two more versions of VB since VB 2005. Microsoft released "VB Revolutions" in late 2009 ("VB, Reloaded" was previously released in mid 2007.) VB now contains almost every bit of needed functionality used 80+ percent of the time wrapped up in an incredibly intuitive class/object hierarchy.
Collectively VB developers are still not quite as skilled as their C# brethren. However, as a group they have increased their productivity compared to their C# brethren by literally an order of magnitude. VB developers now garner 50% higher wages than C# developers simply because of the incredible productivity difference (A small group of C# developers lobbied for adding "My" to C# however more than 75% of active C# developers successfully defeated this potential inclusion by convincing the Microsoft C# team they didn’t need a "dumbed-down" programming language.)
Further, the third party component market is booming. Unlike the early days of .NET, most VB developers now embrace the use of third party components, and most of those components are accessed via the "My" classes. The reason VB developers are so collectively positive about third party components now are 1.) the entry costs have been brought down and 2.) the risk of using third party components has been almost completely removed, unlike five or more years ago. Now every different type of component implements a defacto standard interface, and there are many components implementing each widely used interface.
For example, one of the earliest interfaces was the IZip interface. Any component that implements the IZip interface can be specified in the app’s app.config file as a "provider," and any use of My.Files.Zip in code would use the specified provider:
<add interface="IZip" type="MyTools.Zip, Tools" />You see Microsoft decided before releasing VB 2005 way back when they had to lock down the ability to extend the "My" classes so it was only possible for Microsoft, or someone with Microsoft’s blessing, to extend them. Had they not done so, they knew all hell would have broken loose(see my negative future below for this alternative.).
Though Microsoft decided to lock down the "My" classes they did offer an alternative. Taking a page out of their own play book and empowering developers to use it, Microsoft made it possible for developers to "embrace and extend" the "My" classes by creating their own class that could psuedo-inherit a copy of the "My" classes, and then extend them:
Embrace "My" As Xtras."My" Console.WriteLine( "CurDir: " & Xtras."My."Application.CurrentDirectory )Or just:
Embrace "My" As Xtras Console.WriteLine( "CurDir: " & Xtras.Application.CurrentDirectory )Once a developer "Embraces" the "My" namespace, they can "Extend" it in any manner they wanted.
Of course Embracing and Extending wasn’t Microsoft’s only plan for the "My" class, but it silenced the would-be complainers who were chomping at the bit to extend "My."
Microsoft’s next "My" step was to sponsor an open-source project. They engaged a third party component specialist from outside the company to manage the process, and they provided funding to ensure the project maintained its priority.
They called this project "My", Reloaded" as a pun on the Martix movie trilogy, and that is of course how VB9 later got named "VB, Reloaded." At first they hosted MyR on GotDotNet until GDN was finally taken down do to a massive crash which lost all source code (fortunately most GDN source was available from individual developers), and then Microsoft started hosting MyR on SourceForge as well as all sponsoring a GDN-replacement space on SourceForge (Interestingly, Microsoft invested $50 million in SourceForge only 6 months after the switchover. But then that’s another story…)
They started the MyR project by engaging the .NET developer community, especially third party components vendors to propose extensions to the "My" namespace. They used the .NET Wiki tool called FlexWiki created as a side project by then Windows Program manager David Ornstein to ensure it was as open and friction free as possible. For any proposed extensions that had enough outside interest, the MyR project manager elevated the extension to "Acknowledged."
Once "Acknowledged", the MyR project manager informed the appropriate members of Microsoft’s internal VB team and engaged community members interested in the extension to collaborate until they all agreed upon the exact interface that would be used to extend the "My" classes. At that point, and only then, the extension became an "Approved" extension.
Once approved, a member of the Microsoft VB team used private/public key encryption to "sign" the "Approved" extension interface so the .NET framework could recognize it, and they released a small patch for the .NET framework that anyone using the extension would need to apply. Microsoft also modified the .NET framework to apply that patch itself over the Internet, assuming the user agreed and had the appropriate code access security. (Actually I’m not sure of the details on this one. It is possible they just including the patch in Windows Update, or maybe that was the early talk and they found a way to avoid patching the framework to recognize approved extensions. Whatever the case, it works and doesn’t cause problems.)
Interestingly, when the MyR concept was first announced, almost all of the larger third party vendors were tentative. Once the "Approved" extensions started to trickle out, open source developers started to create free versions of these components and then came the huge outcry from those same large third party component vendors. Most of those with lower-level easy-to-implement components went out of business, but they complained loudly about how Microsoft had screwed them as they were going down.
Then an interesting thing happened. Saavy 3rd party vendors started innovating on top of the approved "My" extensions. Developers had to cast to use the innovations, but that was fine. Most of these vendors sales went through the roof! Developers started buying more components than before because the standarization gave them the confidence to incorporate more external components into their apps, and because they wanted the vendor support they didn’t get from open source.
Still other new vendors came along and started offering tech support for the open source components, ala RedHat. Their businesses thrived! All in all, by the release of VB Revolutions, 3rd party component usage grew among developers from around 20% in 2005 to over 80% of developers in 2010. And those developers purchased and actually used a lot more components. Because they could depend on them.
Oh, a few more things.
The next version of C# scheduled for 2011 plans to incorporate the "My" classes. Microsoft’s C# team decided to heck with the zealots amongst C# developers; they’d get "My" classes anyway, and they would be happy they did (or else C# might disappear.)
Also, Java usage is way down now, to less than 5%. Even though five years ago everyone believed that .NET and Java would be a close #1 and #2 instead what happened was it .NET/Win and .NET/Else (i.e. Mono) became #1 and #2. Funny how things change. :)
And now for the bleak version:
It’s 2010 and things have been very discouraging over the past five years.
Microsoft has managed to release only one new version of VB since they released VB 2005 to much fanfare. This more recent version came out in 2008 and was called "VB, Finally!"
Microsoft released two versions or C# in the same time, but VB was in such disarray they had to skip a VB release, and man did that add fuel to the C# developers fire! "Real Programmers use a language with a future!" was all VB loyalists heard from the C# contingent. The name of the last VB was particularly ironic because it just may be the final version Microsoft releases. There sure is a lot of buzz to that effect.
Back just before VB 2005 was released, everyone thought things were going to be great for VB, what with the "My" classes they were promoting as an almost panacea for simplifing VB development and improving VB developer productivity. Boy was that not the case!
I think the problems all started with the fact Microsoft allowed the "My" classes to be extended. Just like the DotCom euphoria (don’t people ever learn?), VB developers of the day jumped on "My" classes and started putting ever utility function they could thing of into "My." And it worked great. In the begining.
By extending "My", the "tool" builders on development teams were able to create their own extensions to "My" which brought them the same huge benefits for their own internal development framework that all VB 2005 developers were seeing with "My." Productivity was increasing significantly.
Then after about three months, a trickle of third party component vendors started releasing new components that adding to the "My" classes. This too made it easier for developers to learn and understand third party components. By six months after VB 2005’s release, practically ever third party component had a "My" extension. All seemed wonderful. Kind of like the world felt on Sept 10th, 2001. (Well heck, maybe more like April 2nd, 2000, the day before Judge Thomas Penfield Jackson ruled against Microsoft which triggered the DotCom crash…)
Then things started to unravel. At first it wasn’t so bad. Developers would choose two component they needed, but those used different names for the same concept: Mike Sax’s Sax.Net used "My.Communications" and another vendor used "My.Comm." Not a biggie, but confusing.
But as the months went by, the proverbial shit hit the fan. Vendors were using the same names in their extensions that other vendors were using, but they were not compatible. And it got worse, developers had so extended "My" that very few third party components could be used without conflicting with the developer’s own pre-written frameworks.
In short order, corporate developers started missing milestones left and right. They were finding it impossible to integrate the third party components on which their project timelines depended.
Next came a backlash against third party components. A few blogging firebrands blamed third party vendors while conveniently ignoring the fact it was instead Microsoft who has inadvertently laid a huge trap for all VB developers.
Of course this caused sales of third party components to literally grind to a halt. The lucky 35% were able to move to some other software or related business such as consulting. Unfortunately the remaining 65% of third party component vendors went bankrupt within a one year period.
Whatever the case, the tech media smelled blood so started sniffing around, with C|Net in the lead. They interviewed VB developers and third party components vendors, and to a statement printed everything negative and nothing positive. This caused a tidal wave of fear among development managers and their bosses, and .NET projects all over were canceled.
At first it was just VB projects, but then it also included C# and soon anything .NET because managers were either confused and didn’t understand it was a VB.NET problem (except for the third party components that might be used in C# apps, or course), or they just became wary of any development tool from Microsoft.
Soon VB developers started filling the jobless ranks quickly followed by C# developers. Not all lost their jobs, but not everyone could learn other technologies quickly enough to switch. But more importantly, with the civilized world having become so dependant on computers, this caused us to slide into a horrible worldwide recession, almost bordering on a depression.
Then in 2006, sensing opportunity, Novell released Latte which was a new language with the flavor of VB but instead supporting the Java VM. Latte was based on the core code of Mono. Borland, not one to be loyal to any one platform, created Latte Builder by leveraging Eclipse, and it was universally agreed to be the best IDE around for Latte. RedHat then bought Borland and Borland became RedHat’s developer division.
Former VB developers started learning Latte en masse, or at least those who didn’t have to take two menial jobs just to keep food on table. Some former C# developers even chose Latte because it didn’t have any "basic" baggage, but most C# developers moved to Java.
IBM, sensing opportunity, invested $10 billion. Some of that money went to prop up Novell whose Zimian Mono team had converted their code to support Latte and needed an infusion. Another recipient was RedHat because IBM wanted to see two strong Linux players and wanted to ensure Linux/Latte would never be challenged by Windows/VB again.
IBM also used some of that $10 billion to purchase numerous application software companies. Those with .NET apps were given marching orders to rewrite in Java or Latte, move their clients over, and then drop their .NET versions. In what appeared to be an amazing blink of an eye but was really two years, IBM had a full suite of software on Linux to rival Microsoft’s front and back office solutions including their own commercial version of OpenOffice.
Back around 2006 Dell started pushing Linux really hard, and by the time IBM had completed its Linux suite of applications, Dell announce it would no longer ship Windows on any of its computers by default; you would have to special order it. Dell shipped all new PCs with either RedHat or Novell Linux.
Clearly Microsoft’s revenues went into a tailspin. By 2009 MS had become one tenth of its former size selling legacy systems to late majority customers and laggards with no R&D budget, all in the period of just a few years.
Although I’m sure it was just urban legend, Bill Gates reportedly had to mortage his Lake Washington home to cover payroll one month. Pundits claim that is when Melinda filed for divorce followed by a bitter child custody battle which is still raging on today, and the news media is having a field day with it.
Finally, in late 2009 something really tragic thing happened. Software written in .NET for the air traffic control system malfunctioned because of a "My" class conflict that occurred in a dynamically loaded module. That malfunction caused a huge fully loaded Etihad Airways Airbus A380 with 574 passengers and crew aboard to crash midair with an Air France Boeing 747 Advanced carrying 512 passengers and crew (Etihad is the national airline of the United Arab Emirates.)
The crash occurred directly over UN Headquarter in New York, and the UN Headquarters was demolished when the two planes fell on it. The debris covered a radius of 1.37 miles and killed a total of 6247 people, 5291 of which were Americans…
Funny. Just five years ago life didn’t seem so grim. :(
See what I mean? Extending the "My" classes is a real no-no!
Okay, so both scenarios are a bit extreme. Please don’t post comments about how items that were technical impossible or statistically unlikely. I know that. I wasn’t trying to document perfection. I was trying to paint a picture, and I wanted one to be as rosy as possible and the other to be totally grim just as did George Orwell with his famous work "1984." Actually, I hadn’t expected to write such long scenarious but once I got started I just couldn’t stop! :-) I actually had tons of fun writing them.
I had planned to follow the scenarios with specific arguments and a summary, but after writing them I think the scenarious speak for themselves. I just hope Microsoft is listening. If Microsoft doesn’t listen, its up to all VB developers and third party vendors to keep the second scenario from becoming reality. :-)
P.S. For the record, I think the first scenario has a lot more potential to transpire as described because of actions related to the "My" classes than the latter. Especially the last paragraph of the latter!