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.

Clarifying my Microsoft Developer Division Rant

Contents


I Ranted and Eric Rebutted

The day before yesterday I wrote a long winded and rambling rant about how Microsoft’s release cycle and process for creating developer tools. I commented on how I believe it is making them fall behind and causing many formerly loyal Microsoft developers to look at open source solutions on non-Windows platforms. I referenced a post that Microsoft’s Eric Lippert wrote over 2.5 years ago titled Top Minds Are Working On It[1]. In retrospect it might have appeared I was being critical of Eric but that wasn’t my intention, and if that’s how I came across I apologize. Instead I was referencing Eric’s comments as symptomatic of the Microsoft culture at large. And yesterday I awoke to find that Eric had issued a rebuttal.

While I Respect the People at Microsoft…

But before I address his comments let me talk about Eric and all the others I’ve met from Microsoft. Eric is actually a brilliant guy, and very likeable. I’ve met Eric face-to-face and it’s obvious he’s much smarter than me. But then I could say that about most of those I’ve met from Microsoft; they don’t hire dummies. As a rule I’ve been impressed with every Microsoft employee I’ve met. They are super bright and AFAICT they do really want to do "Good Things(tm)".

…They Become Detached

But group dynamics being what they are, when you get a group of super-bright people together they become competitive, hone their debate skills, and learn to be strong advocates for whatever their own positions. And they can become detached from the outside world, much like politicians in high office. Politicians are also typically super bright, and most enter office wanting to do Good Things(tm), but once "on the inside" they loose touch with the concerns of their constituents. So I am not condemning Eric and his Microsoft colleagues, I am merely commenting on the culture that results and collectively channels them.

Eric Unconsciously Supports my Thesis!

So I started yesterday’s post saying I’d been planning to blog on the topic for a while but the reality was I still didn’t know how best to explain my concerns. But for better or for worse I did write a rambling essay yesterday, but ironically Eric’s comments made my points far better than I! My central thesis was that Microsoft isn’t meeting developer’s needs because of their processes and infrequent releases and consequently open-source alternatives are meeting developer’s needs instead. Eric’s both debated my examples and pointed out they now plan to address some issues I referenced. But not only did Eric not address my central thesis, he ironically supported it given his rebuttal’s choice of focus! In my post I wrote the following:

"Microsoft’s culture is to argue semantics when reality doesn’t match their world view"

And Eric’s comments proceeded to do exactly that! In my post from 2.5 years ago[1] I called for Microsoft to address things that PHP, Ruby, and Python are addressing today, which Eric rebutted at the time. In yesterday’s rebuttal Eric referenced his earlier comments stating (emphasis mine):

"Second, my ‘esoteric’ reasons for not implementing a scripty version of VB on the .NET platform were hardly esoteric then and are hardly esoteric now. They are (1) fracturing the language further causes confusion amongst customers and is massively expensive for little gain, …"

Dismissing the Proposal, Not Solving the Problem

Now I’ll freely admit Eric is far more qualified to evaluate my suggestion on technical merit, but that wasn’t the point of my 2.5 year old post. Customers with needs a company’s not addressing will often propose solutions they believe will address their needs, yet often their suggestions aren’t workable for whatever reason. People who specialize in addressing customer needs know that rather than dismiss suggestions as unworkable it’s far better to determine the customer’s actual needs and implement a workable solution instead. And often, many other customers have those same needs. So Eric dismissed my proposed solution but didn’t address my unresolved needs that prompted the proposal. I don’t attribute this failing to Eric, I attribute it to Microsoft’s current culture.

Not More Power; Transitionality!

Eric then went on to say:

"(2) we can do things to make VB.NET more powerful without fracturing the language,…"

Ironically, I didn’t ask for a more powerful VB.NET; I asked for one that was easier to start using and one that developers could then easily transition to more powerful usage. Though they believed they were providing an easier to use Visual Basic 2005, they addressed the language but not how people develop applications. Though they made strides with the Express Edition, my biggest concern was with the complexity of the development environment and the language. I suggested an interpretive environment with a transitional language design that allowed new developers to start easily yet be able to effortlessly grow their expertise with use. What I envisioned was something like Boo, but I wanted it 2.5 years ago with a simple interpretive environment, and I wanted it from Microsoft so that it could possibly generate a large and immediate and user base with a thriving community and significant peer support.

Today’s Potential Didn’t Address Yesterday’s Deficiency

Eric continued with the following…:

"(3) Microsoft makes scripting languages like Iron Python"

…but omitted the fact that a robust Iron Python was just a gleam in Jim Hugunin’s eye 2.5 years ago and is still not ready for prime time. Further, Microsoft’s approach is to host IronPython in Visual Studio which does nothing to bypass the complexity of Visual Studio!

Nor Does an Orphan Address Yesterday’s Deficiency

Eric then said:

"…and JScript .NET, use the right tool for the right job."

To which I did a double take wondering if he were really serious! JScript .NET is such the orphan that I can’t even believe he suggested it! The JScript .NET newsgroup has less than a screen full of messages, JScript .NET hasn’t been updated since 2003, and nobody’s even written about JScript .NET in years! So could Eric really have been serious when he suggested JScript .NET? Well, assuming he was, then:

  • JScript .NET does NOT have an easy-to-use interpretive environment, and
  • JScript .NET is a complex language; NOT simple-to-use, and
  • Again, JScript .NET has NO user-base!

And a Potential isn’t a Solution

Moving on Eric said:

"The .NET framework is already amenable to the development of scripting languages."

So why do we still not have a viable scripting solution for .NET supported from Microsoft more than half a decade after the .NET Framework’s first release?

Yes, there’s Powershell, but…

Okay, that’s not quite true. Eric didn’t mention it but in the spirit of honest debate, there is Microsoft’s PowerShell. But while I will freely admit PowerShell is really nice, PowerShell:

  1. Was only just released so doesn’t address the past 2.5 years,
  2. Doesn’t have a development environment,
  3. Can’t be used for web development,
  4. Doesn’t have a compiler for creating components for use in other .NET languages.
  5. Doesn’t have transitionality allowing it to scale up for much more complex projects as the developer’s experience grows.

A Correct yet Irrelevant Point

Eric then makes a point about "scripting languages" vs. "dynamic languages" (emphasis mine):

"Third, I want to make a distinction between scripting languages (languages intended to script things) and dynamic languages (languages which admit a type system which cannot be deeply analyzed at compile time.) Scripting languages are often dynamic languages, however it is entirely possible to use dynamic languages for tasks other than scripting. "

Okay… So Eric’s points are very technically valid, but they are totally irrelevant! Frankly I wasn’t asking for a language that was "intended to script things," I was proposing a language (and IDE) that would be:

  1. Productive,
  2. Easy to start using, and
  3. Scalable as one’s skills evolve.

Call it "scripting", call it a "dynamic language", call it whatever; it’s irrelevant. What is relevant is for it to be productive, easy, and scalable. Microsoft could choose to get there however they will, bit like arguing the semantics of "Car" vs. "SUV" with someone who just needs transportation, Eric’s distinctions were simply irrelevant to the needs. Totally unrelated, I ran across this joke yesterday. What could be more ironic?

Interest Doesn’t Necessarily Change Process

Eric finishes his prior point with:

"The VS team is VERY interested in understanding how to make the platform more amenable to dynamic languages."

Great! But are they going to actually engage people who are not .NET developers in the design of said dynamic languages and their respective development environments and then incorporate their feedback? Or is the VS Team just going to plug another dynamic language into Visual Studio? If the latter they will do so ignoring that Visual Studio users already have the language(s) they need and that there are at least an order of magnitude more people for whom Visual Studio is too overwhelming.

A Solution Offered; Wrong Product, Years from Now

A couple other comments Eric made were:

"C# 3.0 will have the "one line auto-implemented properties" feature you requested for VB. Enough people asked for it, we put it in. I do not know if VB will be doing the same. You’re welcome. "

and

"Current C# 3.0 features move in the direction of dynamic languages without actually making the language dynamic (lambdas, improved generic method type inference, extension methods, implicitly typed locals, anonymous tuple types). All of these however are implemented so as to keep the language statically analyzable. We are considering features for C# 4.0 which would make the language more dynamic without losing that important statically analyzable core."

That’s well and good, but it doesn’t address VB.NET, and it also makes my own point that Microsoft’s release cycles are too far apart! There are badly needed enhancements and they need to get them to developers more often than once every three years. C# 3.0 is still a way’s out, people need something today, and I personally wonder if I’ll even care about programming by the time C# 4.0 is released. Hell, I hope to have made my fortune and be retired by then! :-) But seriously, C# is a professional developer’s language and adding features to a professional developer’s language wasn’t even close to what I was proposing.

Too Little, Too Late: Acknowledged

In the last paragraph, Eric finally gives tacit acknowledgement of the concerns I raised in yesterdays post:

"Now, maybe these features aren’t what you want, or are too little too late, or the release schedule is too long for your liking, or whatever. That’s unfortunate."

Exactly. The release cycle needs to be compressed by an order of magnitude as it has been at the competition. More on this in a bit.

Studying Users Isn’t Feeling their Pain

Eric then signs off with:

"However I take exception to the claim that we do not study what real users are doing and try to provide tools that do what they want. We do that every day."

With this Eric either misunderstood my point, or more likely I didn’t state my point in a manner that was understandable. Whichever the case, let me clarify. I know the VS Team works hard to study real user’s needs every day. But what I also know is that the people who make the decisions about what gets released and when have considerations that are far different from the needs of developers. And it is human nature for one to place solving one’s own pains ahead of solving the pains of others as people simple can’t fully comprehend pains they don’t experience.

Trade-offs that Shortchange Developers

Eric let’s be concrete; if solving a customer problem today will cause the VS team a problem tomorrow they won’t do it. For example if the VS Team plans to rearchitect something next version they won’t provide an interface that developers need in this version if doing so will make that rearchitecture difficult. Some would say this is good product engineering to which I would actually agree, but it is nonetheless a trade-off that keeps developers from getting what they need today.

Experiencing Pain Empowers Real Solutions

So, if you’ll reread my post from yesterday you’ll see that I didn’t say "Microsoft doesn’t listen to customers"; I know damn well they do. On the contrary, I said that Microsoft’s Developer Division "Don’t solve real world problems." And the reason you don’t is because you don’t experience the pain that those real world problems cause. By comparison most developers contributing to open-source projects are doing so to solve pains which they themselves have, and that is why they are addressing developer needs much faster than Microsoft’s Developer Division.

Yes it is a Paradox…

An observant person would say that I’ve present a rather intractible dichotomy for Microsoft’s Developer Division; i.e. they need to use the developer tools they build to solve real world problems yet they also need to to develop those tools ten times faster! Now I’m sure these comment will cause the blood of those in Microsoft’s Developer Division to boil thinking I believe it’s possible they do their work ten times faster and do real world projects. But I was not advocating that; I’m fully aware of the myth of the "man-month" in software development projects.

…But Solve it You Must, Or Else

What I was pointing out, however, is if Microsoft’s Developer Division maintains its status quo they will slip farther behind and the loss of developers to other platforms will accelerate. And since developers, developers, developers have always been Microsoft’s life blood it is critical they address this issue. Every developer they loose to Linux or the Mac doubly weakens Windows. Microsoft must address this issue if they are to maintain the same level of relevancy during the next twenty years that they’ve had for the past twenty years. And most of what I’m suggesting isn’t complex, and it isn’t new. They probably have most of what they need already written and used internally. They just need to rethink what they are offering.

Change, or Be Changed

So to wrap up this second long-winded essay:

Microsoft’s Developer Division needs to implement drastic changes sooner than later. If they do not, outside forces will soon impose drastic changes upon them and it’s certain they will find those imposed changes to be far more painful. Or as the mechanic on the old Fram Oil Filter commercial used to say "Pay me now, or pay me later."

What if I’m Not Wrong?

P.S. If you’re from Microsoft’s Developer Division and choose to dismiss my concerns, just ask yourself this: What’s the downside for you if I’m right?

  1. Eric Lippert’s post was in response to my post entitled A Modest Proposal: VBScript.NET, aka "Helping Mort use .NET".

 

Anonymous Methods in C# 2.0: What’s Old is New Again!

Paul Kimmel recently wrote an article for informit.com entitled "Anonymous Methods in C# 2.0" where he made the following statement:

Linguistically, I love methods, but as a practical matter anonymous methods may
just be an example
of some inventive person at Microsoft being a bit too clever.

Unfortunately that was the pull-quote used to promote the article on another part of the site. Unfortunate, because I think they are one of the best new features in C#.

I won’t take Paul to task here - I’ll just assume he’s never worked with a similar language feature in any other language, but I was extremely excited when I first saw they were adding anonymous methods to C# 2.0. Anonymous methods are similar to the Smalltalk concept of CodeBlocks which I learned of and fell in love with during my Clipper 5.0 programming days in the early 90’s. Clipper 5.0’s Codeblocks were my favorite language feature because they provided so much power with so much simplicity.  Even that crazy new language Ruby has (Code)Blocks!

I remember the reason they added CodeBlocks to Clipper was to support "User Defined Commands (UDCs)."  UDCs allowed the developer to use the old dBase-style commands and have them translated via a preproccessor into function calls with parameters (I always love it when language designers actually use a language! When they do, they add really useful features!)

So, looking at the dBase REPLACE command, which is roughly equivalent to a SQL UPDATE, the UDC would convert this:

REPLACE Name WITH "Mike Schinkel" FOR Status="X"

Into something like this (forgive me if it’s not 100% correct, it’s been a looong time since I coded in Clipper):

dbreplace( {|| Name:= "Mike Schinkel" }, {|| Status="X" } )

Try doing that without a language feature like CodeBlocks!

During my Clipper 5.0 days, I found the basic benefits of a (Code)block/Anonymous Function are three-fold:

  • They eliminate the need to uniquely name a method when it would probably be called only once
  • They reduce the number of method names you need to track,
  • They allow you to define code physically closer to the using code. 

Maybe I’m wrong, but I’ll bet Paul will soon find anonymous methods to be one of the most useful language features added to C# in v2.0; right up there with Generics!

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?

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!

What major advantages does C# have over Java?

Matt Davey just posted about a presentation to management types where they asked the question (among others)

What major advantage does the C# language have over and above the Java language?“

My first thought was “attributes“ which allow developers to tag code with metadata that can be programmed against but I was sure there was more. Since I’m not a C# guru I did a quick web search and found a great essay entitled "A comparison of Microsoft’s C# Programming Language to Sun Microsystem’s Java Programming Language" by Dare Obasanjo.

Dare listed the following things C# has that Java does not:

  1. Deterministic Object Cleanup
  2. Delegates
  3. Enumerations
  4. Value Types (Structs)
  5. Boxing
  6. Run Time Type Identification (as operator)
  7. foreach Statement
  8. Properties
  9. Multidimensional Arrays
  10. Attributes
  11. Indexers
  12. Preprocessor Directives
  13. Aliases
  14. Runtime Code Generation
  15. Pointers and Unsafe Code
  16. Pass by Reference
  17. Variable Length Parameter Lists
  18. Verbatim Strings
  19. Overflow Detection
  20. Explicit Interface Implementation

That’s a lot!  Though that list is great, it was written as a list for developers, not managers. The question then would be, which of these differences could actually translate into a benefit a manager could appreciate?

I’ll take a stab at this, but would love comments from others on how to best present C# as having values business people can appreciate. I can’t find a direct business benefit for some of these features:

  • Without Deterministic Object Cleanup Java apps could create unacceptable performance bottlenecks after deployment, which could cost a lot of time and money to fix.
  • Delegates allows a more flexible implementation of callbacks, which reduces the complexity of code and reduces the likelyhood of logic errors.
  • Enumerations increase robustness by providing type checking and reduces “copy&paste“ errors because enumerations can be converted to their string equivalent. Java developers will need to spend more time testing and debugging. 
  • Properties allow more natural syntax. If Java programmers “get lazy“, write directly to fields, and later need to trigger code on a field assignment, they have to modify a lot of client code.  If they get lazy in .NET, they can just change the field to a property w/o affecting client code. However it does take a recompile (I’ve always hated that about .NET)
  • Attributes allow developers to embed metadata and program against that metadata. This increases the power and flexibility available to a software architect designing an application framework. .NET modules are discoverable which greatly reduces the need to distribute related information across multiple source files. This reduces potential errors and hence testing and development time as well as increases reliability and robustness. In my mind this is probably one of the strongest benefits of using C# over Java.
  • Runtime Code Generation allows an application to implement its own extensions based on user imput. Most developers will never attempt this, but when it is useful there really isn’t an alternative.
  • Overflow Detection increases robustness and reliabiliy because potentially critical errors that might go unnoticed in Java will be caught by the .NET runtime.
  • Explicit Interface Implementation can offer significant cost savings when naming conflict occur during code integration, especially if those conflicts are in 3rd party components.

That’s my list. BTW, I think VB.NET offers all the same benefits.  Do you have more?