Bruce McKinney on Visual Basic.NET

Many mixed feelings about posting this on the first day of the MVP summit. I got this email from Bruce McKinney this morning:

We haven’t talked for a while. I thought I’d let you know that I just posted a version of our discussion of VB.NET on my web site. Check out:

www.pobox.com/HardcoreVB/vbnet2.htm

How far out-of-date is this description of VB.NET in 2008?

It’s bizarre to think that most of the people on the VB Team have probably never heard of Bruce McKinney. I’m going to post this now because I received it now, and delaying it would be as much editorializing someone else’s post as deliberately timing it would have been. I did not. It came out of the blue this morning. Had I wished this to be main topics at the summit, I would have tried to get these things into our conversations weeks ago. I do not.

Obviously many of you do not know who Bruce McKinney is. Perhaps you don’t know who Dan Appleman is either. Perhaps you’re a C# programmer and think you just don’t care. But merging business programming and platform power started with VB (we’re comparing with Dbase and C++ in this time frame). The success of this merge is part of the history of C#, part of why the market existed in 2000. Bruce McKinney and Dan Appleman (and a few others) are the ones who proved that power mattered in such languages. They proved that business programmers could do great things and that they needed a powerful language to do it. Thankfully VB.NET/C# moved us an order of magnitude closer to the metal and allowed us to do the amazing things we do today.

That’s what Bruce meant to our collective history. Do you care what Bruce meant to me? As I look at the future and the work I’m doing to provide easier development and the thinking I’m doing to about the next level of abstractions, Bruce and Dan remain prophets. We can’t separate from the metal – which is why my current mantra is that we need to abstract application writing while not abstracting debugging and not hiding what’s really going on. Code still matters. Dropping down from an abstraction to the metal still matters. Anyone for in-line DSL? In line 3GL in a DSL? I believe understanding 3GL will eventually become as unnecessary as understanding assembly is today, but we can’t get there with a declaration or in a single jump or just because we want to get there. It’s a decade. We can only get there with a long iterative process that will require we go to the metal, understand why we went to the metal, and iterate again. Unlike VB6, we sit on an amazing platform where this process will work. .

If you still can’t quite recall where you heard that name before – Bruce McKinney wrote Hardcore Visual Basic which was on the bookshelf of most of the people that pushed the edges of Visual Basic. And if you read Bruce’s piece, remember this is one of the smartest guys there was in VB6.

Tip on Debugging Stable Composition Problems in MEF

My debugging strategy is to develop a hypothesis or two, pick the easiest most valuable one to test, test it in the easiest manner, and go on. I’m working to disprove the hypothesis because this is far easier to do and helps avoid me getting stuck on a particular notion of what is wrong. A test is more valuable if it cuts out a greater portion of the possibilities for failure, which John Robbins calls the divide and conquer approach.

I bring this up to explain that I rarely use the reporting MEF provides to solve stable composition errors. Maybe one day I will, but its much faster for me to find the missing part and begin adding the “AllowDefault=true” parameter to the Import attribute. I’m not being chaotic or random, it just works for me.

This morning I remained a bit stumped by a stable composition error. I realized it was a stable composition error because it went away when I said “AllowDefault=true”. But, my own reporting and other tests showed that the implementation was clearly in the container. So, what was going on.

A passing hypothesis flitted through my head “what would happen if there were two?”

It was a quick test to put a break point right after composition competed and request the exports for the part. Voila there were two!

Two tips:

- Stable composition fails when cardinality is not correct. A big word say Import fails when there are zero or more than one match.

- If you have multiple discovery directories, it is very easy for common assemblies to wind up in more than one directory. This results in multiple matches, and why I had the cardinality failure.