On the Hunt for a New Programming Language

When it comes to programming on the modern-day GUI (post-DOS) platform, the vast majority of my coding has been, in order of experience, using T-SQL, VBScript in ASP, and about equal parts classic VB (v3.0 to v6.0) and VB.NET. As you can see from my order of experience, I’m really a database guy, and since the beginning of the web I’ve always viewed the web as somewhat of a database publishing environment (anyone remember the DOS product dbPublisher Pro from Digital Composition Systems?) What’s more the web allows a potentially infinite number of people to use a developer’s database publishing apps without any extra effort to distribute them. Finally, the web provides ability to capture evidence the apps were run, how often, and by how many people. Is it any wonder I have more of inclination to develop for the web as opposed to desktop applications? Back during the period from 1994 to 2006 when I ran VBxtras/Xtras.Net where we where a reseller of ActiveX controls and then later .NET components, I never really thought about the cost of add-on components. Almost anything I wanted to play with I can get an NFR (not-for-resale) copy just by sending an email or picking up the phone. Although I still have many of those relationships from a decade+  in the business, I hesitate to ask for NFRs these days except from my really close friends simply because this business I’m in today has nothing to do with benefiting those people. So numerous facts have me giving up on my prior five year assumption that I would someday learn VB.NET at an advanced level and have me instead actively considering alternatives:

  1. As I just stated, the fact I now have to pay for third party components and tools means I’m paying more attention to cost of acquisition,
  2. My recent favorable impressions of open-source developer tools and components, on par with some of the best tools ever sold by Xtras.Net,
  3. My increasing frustration with the Microsoft developer division’s process and release cycle,
  4. All best web applications seem to target L.A.M.P. such as Mediawiki, WordPress, vBulletin, Subversion, Trac,  Ruby On Rails, Django, etc. and all but one of them are free to use
  5. Completely preconfigured stacks (including O/S) that are becoming available for download as a VMware appliance,
  6. Recognizing that Ubuntu’s has an approach strategic enough to result in Microsoft being profiled in a revised edition of Clayton Christensen’s Innovator’s Dilemma as yet another example of why great companies loose their leadership position,
  7. And lastly my rising disgust for ASP.NET (and I promise I will blog about those specific soon…)

By the way, even though I dislike ASP.NET, I do still really like the .NET Framework and programming model. Oh and a note about the first point; whereas there is good open-source tools available for .NET, the operative word is "tools" not components. When you compare what’s available to freely use for .NET compared to what’s available for any of the "P"s (Perl, Python, and PHP), .NET just can’t compare, at least not in depth or breadth. Of course being commercial products the .NET third party components are more polished and of course have commercial support available. However, unless you are big company that needs to CYA and have a throat to choke, those are often dubious benefits especially when you consider the benefits of open-source (i.e. source code, and the ability to fix something and contribute it back so you’ll know it stays fixed!) Anyway, I could write for hours on the pros and cons for open source vs. commercial developer components and tools but that’s not the subject of this post. The subject is about which language I will focus the majority of my future attentions on learning and using, and I’d love to get your input before I decide. Here are the current contenders:

PHP
All the major web apps I mentioned above seem to be built using PHP and I’m currently running many of those apps, PHP is pretty similar to the ASP that I know so well, it’s web-specific, there is a huge support community, it runs on both Windows and Linux, and every Linux web host known to man seems to offer it preinstalled. However, there seems to be lots more crap PHP code examples littering websites than good PHP code examples making it harder to learn so it might be hard to seperate the wheat from the chafe, it is not easy to configure on Windows Servers (especially at a shared web host), and no one individual framework seems to have gotten the lion’s share of the market attention so picking one would be a crap shoot. Oh, and it uses those infernal semi-colons just like C#.
Ruby on Rails
Ruby and it’s framework Rails have gotten tons of attention and it seems all the cool kids are doing it, especially lots of the Web 2.0 startups, it is very database-centric, has very elegant URL mapping functionality, and it seems you can get web apps built really fast using it. And Ruby.NET is also on the horizon meaning I might be able keep my toe in .NET. However, the community comes across as just a little bit too religious and I’m generally alergic to that, AFAIK it doesn’t run on Windows, or at least not for shared hosting. Plus I’ve had people I respect tell me that Ruby doesn’t have nearly as many users as the "P" languages, that Rails it not nearly as mature as its purported to be, and that Rails makes simple thing simple but complex things extremely difficult. And the number of available web hosts that offer it is quite limited.
Python
Unlike PHP, it seems Python is well suited for both web and desktop apps, which might come in handy from time to time, and a shipping IronPython means that I definitely can keep my toe in .NET. The Django framework seems to be a little more mature and have a little less religion than RoR, and Django also has nice URL mapping functionality, albeit slightly less elegant than RoR. And it seems to run equally well on Linux and Windows. However, Django seems more document publishing-centric and less database-centric, there are very few web hosts that support DJango, and I’ve heard it is a real bitch to get working on a web host.
VB.NET+Castle/MonoRail(+Mono)
But then again, maybe I will stick with VB.NET. The Castle/Monorail project is supposed to be a lot like RoR, and I’d even have the option to use Mono on Linux. However, the third party tools are definitely wanting, most web hosts haven’t a clue what Mono is, and they coded Castle/MonRail in C#, so I’d always be dealing with semi-colons…
ASP+IIS+JScript
I could stick with ASP, which I still like, and learn JScript to replace VBScript, the latter of which just has too many limitations when compared with the other current options. This clearly also runs on Windows and any Windows web host will support it, and I already know Windows backwards and forwards. On the other hand, I’ll need to use ISAPI Rewrite for clean URLs, JScript on ASP it has no future and few code examples on the web, and what third party components and tools (to speak of…)?!?
ASP+IIS+VB.NET
I could also use develop VB.NET objects and call them from ASP; that’s what we last did at Xtras.Net (and I think that is what they are still doing, last I checked…) Of course, calling .NET objects as ActiveX controls just doesn’t feel right, and again there’s that third party component and tools problem…
PowerShell+IIS+???:
Of all the teams working on tools for developers over at Microsoft, the PowerShell team run by Jeffrey Snover is the only one that gets me excited anymore. And in an email from him (or was it a comment on my blog, I don’t remember exactly) he said that PowerShell can do web, and will be able to do it more easily in the future. On the other hand, it’s not here today, and what if webified PowerShell is just another way to do rubbish ASP.NET instead of what it should be, a url-based object-selector-and-invoker like Django or Rudy on Rails.  And what’s the chance it will ever run on Mono…?
Other:
Is there anything else do consider…?

At this point I should probably explain what I’m not considering, and why:

Java on Anything:
Although I was really impressed at a Sun Tech Days recently here in Atlanta , even the Sun people were all over dynamic languages with praise, like Jython and JRuby. And though I was impressed with NetBeans 5.5, all the other "enterprise" baggage like J2EE and Servlets and JSP Custom Tags gives me the feeling I’d be jumping out of the frying pan and into the fire.  Oh, and Java uses those infernal semi-colons too.
C# on Anything:
One word: semi-colons!  Sorry but if I’m going to go .NET, it’s going to be VB.NET (or IronPython). VB.NET is so much more natural to me than C#, and there are things you just can’t do in C# that you can do in VB.NET related to using "implements" on a method in an inherited class (I ran into that limitation of C# compared to VB.NET on a project several years ago where I was managing a pair of interns coding in C# and they hit a wall because of that limitation. I can dig it up if anyone cares, or better yet, can someone who knows the specifics explain it in comments?)
Perl on Apache:
Although my partner on Toolicious Ben Coffey who is a devoted disciple of Perl will cringe to hear this (yet again), I can’t quite get my head around Perl, and they tide, at least today, is away from Perl. Of course Ben claims that will all change with Perl 5.0, but to me that remains to be seen and I’d rather go with a bird in the hand (i.e. one with a lot more active current user base) than a bird in the bush.  But who knows, they say you should learn a new language every year; at any rate if he’s right maybe I’ll try and pick up Perl 5.0 in around 2012. :)

So there you have it: my potential choices and non-choices. Any thoughts I which I should choose?  Any and all input will be appreciated and considered seriously.

Can Microsoft’s Developer Division Compete Moving Forward?

I’ve been planning to blog about this for some time but just haven’t gotten to it. Well here goes…


Contents

Note: The day after I posted this I decided to add headings to make the argument easier to follow.


Is Microsoft’s Approach Failing?

I believe Microsoft legacy processes simply cannot react fast enough to the innovation happening in the open source arena on the language and web framework front. Microsoft’s developer division typically offers three-year version cycles where they first architect Visual Studio and related technologies in a vacuum. In recent years they’ve even thrown out alphas and betas to the Microsoft faithful to get feedback which, and thankfully they’ve used a lot of that feedback. But that approach just isn’t working in the market anymore. When the release cycles of
scripting languages frameworks like Ruby On Rails and Django and CMS platforms such as Drupal are sometimes as little as a few months, it’s really hard to wait around for the next version of Visual Studio.

After Ten Years; Too Little, Too Late?

It would be different if Microsoft’s developer technologies provided at least 95 percentile of what’s needed by work-a-day developers on a daily basis, but they don’t. Case in point is we still don’t have the ability to do complete URL Rewriting for ASP.NET on IIS even though Apache has had mod_rewrite for years. Looking back, how many years of massively duplicated developer effort in the field did it take befor Microsoft finally provided a login module and a method of managing site-wide templates?!? (i.e. “MasterPages”) Oh, about a decade from when they first released Active Server Pages.

Providing Solutions Frequently Just Not a Priority

It’s not just that Microsoft’s developer division takes too long to offer new solutions to recurring needs; it is that they place such low priority on providing those solutions. Three year development cycles testify to that fact, especially when you consider it takes Microsoft many releases to address fundamental needs. The guys on the product management teams at Microsoft are really smart people, but they often can’t see how much trouble they cause people in the field by their decisions. They see the world of creating Visual Studio, but they don’t see the world of using Visual Studio to develop software.

Core “Real World” Problems Not Addressed

What’s more, Microsoft architects its developer products in a vacuum; they don’t use them to solve “real world” problems. Sure, they may use them internally for developing productsbut when does the average developer’s project look like product development at Microsoft? They often create excellent software but software that either doesn’t solve real world problems or does so in a totally over-engineered manner. While running Xtras I watched many a developer launch a 3rd party component business because they had identified a need while working on a real world project. However, once they saw small success as a vendor they started developing, designing, and even envisioning new products in a vacuum. And often those products either didn’t address real world needs or did so in a really unnatural manner.

Microsoft is a much worse example of this. Their saving grace thus far has been market share and financial resources to brute force their products into the market, and many of the faithful won’t even look at other s offerings to understand why some of Microsoft’s offerings so miss the mark. I know, until recently I was one of them.

Values “Sugar”-Free Over Productivity

And Microsoft’s product managers often dismiss feature requests that would make development a LOT easier as simply being “syntactic sugar. For example, one such dismissed feature request I made years ago was for simplified property references in VB.NET. I wanted a syntax that would allow a developer to implement a single-line syntax for specifying properties you didn’t need anything special, something like:

1. Property Foo Into _Foo

Instead of nine lines of:

1. Private _Foo
2. Property Foo
3.    Get
4.       Return _Foo
5.    End Get
6.    Set(ByVal value)
7.       _Foo= value
8.    End Set
9. End Property

That would have reduced the number of lines of VB.NET code by probably half an order of magnitude. But they just weren’t interested in it because it “bloated the language and otherwise had no value” (I am paraphrasing from memory.)

Focuses on Details, NOT the Big Picture

Even more, I advocated an advanced scripting language that would be a lot like today’s “in-vogue” scripting languages. I called my proposal VBScript.NET. But then my suggestions were dismissed for esoteric reasons and I was told that Top Minds Are Working On It! (Well, evidently not, or so many developers wouldn’t be moving to PHP, Ruby, and Python.) Microsoft’s culture is to argue semantics when reality doesn’t match their world view, and they are blissfully willing to ignore the pain that continues to exist.

Revolutionary Paths Are Often Dead-Ends

What’s more, probably because of its financial resources and a hubris that comes from being the industry leader, Microsoft has a bad habit of creating huge revolutionary jumps instead of small evolutionary steps. Rather than always creating lots of little independent layers of loosely coupled components, each with it’s own independent functionality, documentation, and rationale for existence, Microsoft often builds monolithically complex solutions where the individual components are highly coupled, not documented, hidden beneath the covers, and frankly with functionality that has not been fleshed out well had it had to be developed to stand on its own. This creates bloated and fragile systems that are often extremely hard to debug and for which there is no passionate community of supporters surrounding it.

ASP.NET: Wrong Medium, Wrong Model

ASP.NET is a perfect example of many of these problems. Rather than study the web and realize it was a violently different platform than desktop apps, Microsoft chose to shoehorn an event model onto the web and use a page-oriented implementation. Not only did they get the medium wrong, they also got the model wrong. And this decision resulted in an outrageously complex pipeline processing model with tons of code that is hard to debug or even understand, and that requires lots of high end developers to figure it out and repeatedly explain to newbies what they need to do just be able to do some of the simplest things, things that are brain-dead easy in PHP for example.
But hundreds of thousands of Microsoft-centric developers just trudged along and accepted it as the next best thing because Microsoft said so. And for a short time, I was one of those true believers.

ASP.NET: Exceptional Engineering, Answers Wrong Questions

Now, however, even many Microsoft developers are starting to see ASP.NET for what it really is: An exceptionally engineering product that answers the Wrong Questions. Former ASP.NET developers are moving to the platforms I mentioned earlier (Ruby on Rails, Django, and Drupal) simply because those platforms offered developers the syntactic sugar they crave, and because the developers of those platforms focused on solving pain because the pain they were solving was their own.

Open-Source: Answering the Right Questions, Rapidly

Open-Source development by nature results in lots of little independent layers, and there are communities that sprouted or are sprouting to support each of those independent layers. Each of those layers has had an opportunity to be fleshed out, and by comparison it shows. How can something like Open-Source PHP on Apache take on mighty Microsoft’s ASP.NET and IIS, and win? Because they answer the right questions, and they did so in far less than a decade.

Is there any hope for Microsoft’s Developer Division?

Which brings me back to the original question:


Can Microsoft’s Developer Division Compete Moving Forward?

Frankly, though I really like the .NET Framework and hope I’m wrong, I’m completely skeptical.

 

Technologies are best when they are simple

What’s the next big thing? AJAX? Ruby on Rails? PC Virtualization? Open-Source Software? Data Security? Open Office File Formats? Windows Vista? Windows Live? Apple’s iWhatever? Yeah, all those things will get lots of hype, but the next big thing is something we’ve had access to all along:

Simplicity

Are my thoughts revolutionary? Nah, I’ve been reading about it at places like Information Week and the other usual suspects. Even Bill Gates at Microsoft gets it, through Ozzie at least (though execution will be the key.) But unlike all that gets hyped, simplicity as a concept that is for real.

Let’s look at two of the best known examples:

  1. Simple Mail Transfer Protocol.
  2. Really Simple Syndication.

Over the years, the world’s Internet email infrastructure evolved from that simple little mail transfer protocol (spam and all!) And RSS exploded as a method to syndicate blog posts in a very short order instead of one of the many complex content syndication concepts most of us never even heard of.

To most people the Internet came out of nowhere ten (10) years ago yet it evolved for at least twenty (20) years prior. The Internet’s foundation protocol TCP/IP isn’t exactly simple, but once the simple protocols HTTP and HTML were layered on top, Internet use exploded because implementing websites was simple (by comparison.)

But it’s not just simple technologies, its also simple to install and simple to use applications: ASCII text editors (i.e. Notepad), web browsers, email clients (w/apps like Outlook Express), instant messenger clients, wikis, blogging apps, online forum apps, and QuickBooks (simple is relative; accounting is required yet QuickBooks doesn’t really require accounting expertise.)

And to many people this simplicity makes sense. Scott Cook (founder of Intuit) got it. The founders of the original Instant Messenger (ICQ) got it. Pierre Omidyar (founder of eBay) got it. Google gets it. The original author of PHP Ramus Lerdorf gets it. And a lesser known group also gets it; the developers of Basecamp (although 37 Signals could also be the poster child for when a group elevates a concept to an ideology, and like all ideologists, becomes blind and misinterprets the concept. But I digress…)

Okay this is all obvious, and well, it’s simple. So what’s the big deal? People recognize that simple is important but without a simple roadmap, most don’t know how (pun intended.) I don’t know that I can provide that roadmap, but at least I can get you started.

First, just for grins, let’s look at some counter examples:

  • MS-Access – Have you ever tried to develop an app is MS-Access? Yeah right.Access it pretty easy in where it allows you as a user to point and click, but once you hit its brick wall of end user functionality, you’ve got to be an Access guru to do anything more with it.
  • VB.NET – Thank god for the My namespace in VB 2005, albeit five years late, but VB.NET is still too damn difficult to use productively without weeks of learning.Don’t get me wrong, I love the power of VB.NET language, but it has very little transitionality.
  • ASP.NET – I know its blasphemy, but let’s be real: VIEWSTATE, __doPostBack(), Server Controls, @Register, @Import, WebForms, DataGrid, etc. etc. There’s so much complexity there, where does one start? It’s no wonder so many people still use ASP & VBScript.
  • Exchange Server – Oh my god! How complex a beast can you get? Most POP3/SMTP servers use files and directories; Exchange using some bastardization of an Access/Jet database that corrupts whenever the power fluctuates. And have you ever tried implementing server events?
  • SharePoint – I can’t even figure out SharePoint as a user, let alone as a developer. What was Microsoft thinking?
  • Active Directory – Need I say more?!?

I’ve bashed on Microsoft thus far, but let me not give them all the credit:

  • XML, though itself simple, has been complicated with namespaces which I’ve studying for literally years I but still can’t figure out how to use.
  • SOAP – Okay, Microsoft was heavily involved here. But why did they have to make web services so hard?I mean, what was wrong with HTTP POST?
  • J2EE – There’s a reason J2EE developers get paid the really big bucks.
  • Oracle – Have you ever tried to tune an Oracle database application?
  • Content Management Systems – Is there anything out that can pass for simple? I’ve been using DotNetNuke on one of my sites for a while and I can tell you, it isn’t.

This brings me to my key point. Aside from being intuitively obvious, what’s so great about simple?

The Benefits of "simple" are, quite simply:

  • For the User: Productivity
  • For the Platform Provider: Rapid and Widespread Adoption

But you say that all of my counter examples have widespread adoption?

Do not underestimate the institutional will of large organizations to implement tremendously complex technology, because they can.

On the other hand, departmental users, users in small businesses, college students, home users and more can’t deal with complex technology. If it’s too difficult, they don’t or can’t use it. And there are many, many more of them than there are large organizations. What’s more, large organizations are effectively made up of these small groups and individuals. Simple technologies benefit all.

Microsoft, with its Windows monopoly has been able to get away with complexity and consequent low user productivity and low platform adoption with many of its products for a long time. But with the new challenges from Google, SalesForce, et. al. they better get pragmatic religion, and they better get it fast.

And that roadmap to which I referred? To quote Albert Einstein:

As simple as possible, but not simpler

:-)

Why Exactly Do We Still Need a New VB6?

DevSource has another article Will VB 9 Win Over the VB 6 Faithful? where the .NET advocates sing the praises of VB9 and the VB6 faithful bemoan how VB9 will be even worse for them than VB7 and VB8.  Problem is, this entire issue has been clouded with emotion, like so many other issues as of late (For example can you say "Iraq War" or "Gay Marriage?"  I thought you could.)

What I’d like to know is this: What are the real reasons why VB6ers feel they still need a new VB6 five+ years later?  What tangible problems are they having that they can’t get solve by continuing to use the old VB6 for one set of problems and the new VB.NET for everything else?

BTW I’m not taking sides here; I honestly want to see if I can spawn a productive dialog per change to identify viable solutions Microsoft might consider implementing to make everybody happy.  FWIW!

P.S. And please don’t say "I don’t want to/have time to learn it" because that’s just unrealistic in the technology industry.  Welcome to the real world, after all.

Assertions in VB.NET?

Blake Watson talks about RemObject’s Chrome, a Pascal that’s not Delphi, on DevSource. There he talks about “class contracts, a concept I’ve liked since I first read Bertrand Meyer’s Object-Oriented Software Contruction, 1st edition back in the late 80’s back, and a feature I’d love to see in VB.NET. Whaddayasay Mr. Vick?

Tags:

Visual C++ and LINQ - is it Needed?

Esther Schindler who is the editor of the email newsletter DevSource Update recently wrote about Visual C++ and Microsoft’s LINQ Project that adds the ability to use SQL code directly in VB and C# programs (emphasis mine):



Ever since the PDC, developers and the press have been talking about the LINQ technology that Microsoft showed off. The overwhelming response appears to be positive, and from all I can tell (I haven’t taken the time to read the tech docs) it seems to be justified. But I can’t help it if I see the plot holes in a movie, and it’s my job to ask the questions that everybody is trying not to ask. After all, what we saw at the PDC wasn’t a product. It wasn’t even a technology preview. We (rather gratefully) got a peek at what the Smart Folks at Microsoft are scribbling on their white boards. This is the time to point out any problems — when they can be incorporated into the final design documents.


For instance, I carefully noted that, in all the LINQ demos, nobody so much as mentioned C++. (A Microsoft PR person later told me that each language group sets its own priorities, and the Visual C++ team hasn’t decided yet where LINQ will fit.) Also, everybody has asked programmers about the wondrous capabilities of LINQ; what do the DBAs think? I realize that DBAs and programmers rarely drink at the same bars, but still…!


My response to her concerns about LINQ and Visual C++ is:



You should use the right tool for the right job. Anyone programming databases with C++ is almost certainly using the wrong tool. VB.NET and C# are much better tools for doing database development. Hopefully this is so obvious I don’t have to explain why.


She continued with (emphasis mine):



The larger question, though, is about the much-vaunted ability for a Visual Studio programmer to access databases without knowing SQL or XML particularly well. I’m wary of anything that promises “ease of use” by assuring someone that it’s okay to remain ignorant. I remember, far too well, how the computer industry promised to make computers “idiot-proof.” The result? We now have a lot of idiots using computers. Sometimes, making things simpler _isn’t_ a good idea.


I’m not saying that LINQ is a bad thing. Far from it: I suspect it’s an elegant solution of the “Duh, why didn’t we think of this before?” variety. However, this is the time to raise the uncomfortable questions, and I don’t see very many people doing so.


Uh, as far as I can see, LINQ doesn’t hide SQL or XML, it just gives a much cleaner syntax for accessing that can be syntax checked at compile time.  A developer would still need to write SQL and to understand XML. For example, this looks like to me it requires knowing SQL:



Dim custs() As Customer = …
Dim waCusts = Select c.Name, c.City From c In custs Where c.State = “WA”


Did Esther really look at LINQ before writing this editorial?  Maybe people aren’t asking the questions because the questions are not relevent?

Just Say NO to Extending the “My” Classes in VB 2005, Redux

Last month I wrote a really long blog about the “My” Classes in VB 2005 with two hypothetical scenarios regarding the future of .NET and development because of the introduction of the “My” classes. I had a lot of fun writing it, but afterward realized it was far too long to get across my key points. That is why I am revisiting the subject today.

The “My” classes is a beautiful and incredibly useful addition to Visual Basic, and I applaud Microsoft for thinking of it. In hindsight, it is obvious, but isn’t that true of all the best innovations?

However, because the “My” classes can be extended, I believe there will be thousands of competing, incompatible implementions all crammed into that one single namespace path. The concept and implementation of namespaces in .NET was incredibly elegant and solved many problems, but “My” class extensions will do the exact opposite.

However, when I wrote blogged last month there was one thing about “My” class extensions I did not know. Joe Binder, the program manager at Microsoft for the “My” classes whom I video interviewed several months ago, was gracious enough to provide a detailed comment regarding my post explaining that thing I did not know, and I quote:

With regard to conflicting names, it is important to note that My extensions must be added manually to each project; they will not show up by simply referencing an assembly. (My is actually a namespace nested under the root namespace of the project.) This point is especially compelling from the perspective of third-parties looking to extend My and the scenario you describe above: In order for any name conflicts to occur, users must not only reference the third-party assembly, but manually add the My extension to their project. If there is a name conflict, the user can back out the My extension and still use the third-party component living in the referenced .dll directly; or they can rename the My extension. The point is that all My extensions exist as source in the project; they cannot be pre-compiled.
Whew! That calms my fears greatly! It means .NET components with conflicting “My” extensions, especially from 3rd parties, will still be able to be used together albeit in reduced usability form.

However, Joe’s comment still doesn’t address the biggest reason I felt “My” class extensions will create a problem. If not somehow constrained, I believe the thousands of competiting and incompatible “My” class extensions will effectively shackle Microsoft and keep them from evolving the “My” class “standard” in future versions of VB for fear of breaking too many people working code. If I’m right, that will be a huge loss.

Let’s hope I’m wrong.

Extending the “My” Classes in VB 2005 … Just Say NO!

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!

Mort, the “Hobbyist”, and the “Occupational” Programmer get their due

Wow!

Several months ago I blogged about the need for a much simpler way to get into .NET, and I named my proposed solution VBScript.NET (in hindsight the name was a poor choice because people assumed I was proposing porting VBScript to .NET instead of providing a simplified VB.NET, but highsight often is 20/20…) And I was not the only one, lots of others blogged about the same topic (see here, here, here, here, here, and here to list a few.)

It looks like Microsoft was listening after all! Check out the New Visual Studio Express products, in beta at this point! I haven’t downloaded any of them yet, and I don’t know if they’ll address all the issues my proposal was meant to address, but even if not at least they are trying!

Kudos Microsoft!

UPDATE (2007-01-01): I’ve since come to the conclusion that the Express Edition still does not address the needs of the occupational programmer.

What information do you need when you consider purchasing a component?

UPDATE (2006-May-18): I am no longer running Xtras.Net

As many of you know, my company produces a printed catalog called Xtras.Net which we subtitle Your Source for Quality .NET Tools. However, we are revising the design for the next printing, and also adding features to our website to coordinate with some of the changes.

For example, we’d like to include icons for 100% managed code vs.Managed Code calling unmanaged DLLs vs. a wrapped ActiveX.  Another might be to denote if royalties are required.  Yet another would be WinForms vs. WebForms vs. Windows Services vs. IDE add-ins.

For the general case, are those sufficient?  Are there other things you’d like to see when consider a component purchase?