Monthly Archives: March 2005

Relational people vs. object people

As we move towards Beta2 and are preparing for the headlong rush towards RTM (release to manufacturing), I’ve been lucky enough to be able to carve out some time to start doing some research for ideas that might show up past Whidbey. We’re not talking anything formal here, no feature lists or anything like that. Just the opportunity to spend some time noodling with some ideas on the whiteboard and fiddling with some prototype ideas. It’s one of the perks of having been around a long time – especially since most people on the team are still totally heads-down on shipping.

One of my areas of investigation has been the relationship between data access and the VB language and how we might allow people to work with data more effectively. This is an area with a lot of creative ferment going on, and I’m having the good fortune to spend some time working with people like Erik Meijer (one of the original authors of ), kicking new ideas around. In many ways, it’s a return to my roots – I started life at Microsoft on the Access team and worked a lot on the query designer generating SQL. So to get to go back and think about how to make data really easy to use is just a wonderful opportunity.

As I start to ease more back into thinking about data and data access, though, I find myself facinated by a schism between the data world and the language world that was not obvious to me back before I’d worked on either side of the divide. I find it kind of curious, but it seems to break down like this:

On the one side, it appears, are the database folks. Database folks usually cut their teeth designing databases and database products. They are extremely comfortable with the concept of normalization and prefer to deal with data stored in rowsets. Although they readily admit its limitations, they basically like the SQL language and feel that it is a very logical and powerful way of manipulating data. Their command of SQL allows them to slice and dice information in truly astonishing ways. In .NET, they prefer to work directly with datasets (maybe strongly-typed, maybe not), because that’s a very natural way for them to work and maps well to their domain knowledge.

On the other side are the language folks. Language folks usually cut their teeth working with programming languages and compilers. They are extremely comfortable with the concept of encapsulation and prefer to deal with data stored in hierarchical object models. They generally dislike the SQL language and feel that is a very poorly designed language, although they may envy its power. Their command of programming languages allows them to build astonishingly useful models of data that encapsulate large amounts of metadata. In .NET, they prefer to work with object/relational mappers, because objects is a very natural way for them to work and maps well to their domain knowledge.

The defining feature of this divide is that the guys in one camp tend to think that the guys in the other camp are crazy. (And, yes, I know, this is really a three-way battle, but I’m just leaving the XML guys out of it for now. Those guys are really are crazy.) It’s just another one of those religious debates, like case-sensitivity or curly braces, in which the extremists on either side espouse the One True Way, tossing hand grenades at the other side, and the moderates in the middle just try and keep their damn heads down.

This entry was sparked by Andy’s Conrad’s eminently reasonable thoughts on datasets. All he’s saying is something that seems completely obvious to me — sometimes relational is better, sometimes objects is better, it just depends on what you’re doing. And yet, it seems to me that this sort of pragmatic view of data is somewhat… lacking in some of the discussions of data access that I’ve seen elsewhere. Either it’s all O/R mapping and you’d be insane to want to work with your data in a relational way, or it’s all SQL and you’d be insane to want to work with your data as objects, and to heck with the idea that sometimes they’re just two great tastes that taste great together…

Anyway, it’s nice to be coming home a bit. More news when there’s something actually to talk about…

Way, Cyrus.

Yes, it’s going to suck. So will this one. It’s just a law of nature: Alan Moore doesn’t translate. This one was OK but didn’t get close to the original material. This one sounded so bad that I couldn’t even bring myself to watch it.

Am I missing any? Instead, go buy the books:


No, really, do it. Now. Probably Watchmen is most accessible, but my personal all-time favorite is V for Vendetta. (I’ll tell you a story about that one in a moment.) From Hell is pretty dense reading and is probably left to the end. The League is great fun, especially if you like authors like H.G. Wells, Robert Louis Stephenson, Jules Verne, etc.

Also, I suggest that you go buy all the Swamp Thing, Miracleman, Promethea, Top Ten, Tom Strong, etc. books that you can find. You might also really like his short subject books on DC heroes. It’s some of his finest work.

Gosh, do I sound like a fanboy?

(To the degree that I allow myself to hope, I have greater hope for V. Watchmen was a tour-de-force, but V for Vendetta was more emotionally affecting – I thought that Valerie’s letter, in particular, was incredibly powerful. Funny story: I was originally introduced to Alan Moore by the owner of a bookstore that my brother used to buy comics from. One day he said “Oh, yeah, I’ve got this magazine from Britain that’s got some new Alan Moore stuff you might like.” The magazine was called Warrior and it serialized Miracleman (called Marvelman in England before Marvel’s lawyers got to it) and V for Vendetta. I was way deep into V for Vendetta and had just gotten to the cliffhanger at the end of Act II (“Welcome home, Evey.”) when Warrior went under and stopped publishing! I had to wait something like a year and a half for DC to buy the rights to the series and start republishing it. Needless to say, I was very excited when the DC reprints finally caught up to the original story and I could find out what the hell happened.)

How do you do two mutually exclusive things at the same time?

As an example of how VB .NET threw its lot in with the MSDN camp instead of the Raymond Chen camp, Joel points to the example of the disappearance of Set and parameterless default properties. (I should add that Joel slightly misspoke again – VB still has default properties; now, though, they can’t be parameterless.) This is an interesting design point to pick because it was one of those that unambiguously showed the dilemma that we faced when moving to .NET. Namely, how do you do two mutually exclusive things at the same time?

You see, when we started out on the grand .NET experiment, lo those many years ago, we were all Raymond Chen-ites, every one of us. We were going to port VB to this new .NET platform and, by golly, it was going to be 100% compatible with the previous version. We had all kinds of assurances from the CLR team that they were going to support whatever we needed to make us compatible. We had all kinds of directives from management that compatibility was paramount. So we set off busily building a product that would allow migrating VB6 code unchanged to this new platform and would make VB .NET be a no-brainer upgrade for our millions of users.

So, what happened? Among other things, reality asserted itself.

Let’s use Joel’s example, because it’s an excellent one. One of the cornerstones of .NET was that it was a multi-language platform. No longer would one language be crippled in favor of another – no! We were all going to be on a level playing field. Only… well… there’s this little problem with assignment operators. Because, you know, VB has these two types of assignment: value (Let) assignment and reference (Set) assignment. And the C-style languages (C++, Java, C#) have only one type of assignment that changes meaning depending on the type of value you’re assigning. OK. No big deal, right? Each language can keep its own way of dealing with assignment, right?

Yeah, but then there’s properties. A key feature of properties is that they allow you to define what happens when you assign to the property. Hmmm. Assign. As in the assignment operator. As in “two types of assignment” vs. “one type of assignment.” But we’re still cool, right? Because the CLR allows you to define multiple “set” accessors for properties. Yes, that’s it, VB properties will allow users to define both a Let and a Set property accessor and the C-style languages will allow users to define only a Set property accesor. And everybody will be happy, right?

Until they try and work together, that is. You see, the flaw in this little argument is: what about the class libraries? Yeah, class libraries. Little things like, oh, WinForms and the Base Class Libraries. Because, you see, those libraries were supposed to be used by both VB and the C-style languages. And there was just no way to finesse the issue that the two language camps had two approaches to assignment when trying to write properties that would work with both languages equally well. Believe me, we banged our head against the wall for a long time trying to invent some scheme that didn’t require one language or the other to contort itself. We thought about ways to make properties with just a Set to map correctly to a Let/Set. We thought about ways that properties with a Let/Set could map correctly to just a Set. In the end, though, we came to the conclusion that there was no good answer. Either we had to foist what looked like completely arbitrary requirements on programmers working in the C-style languages (i.e. surface the “two types of assignment” in C++/C#), or we had to deliver a seriously sub-par experience for developers working in VB (i.e. surface the “one type of assignement” in VB). Or we could take a third way – drop Let/Set assignment, drop parameterless default properties, break existing code that used them, and adopt a unified type of assignment.

To be clear, this is not “the reason” why VB .NET is not 100% compatible with VB6. This is just “a reason” that is representative of the sea-change that existed when moving from the Win32/COM platform to the .NET platform. But it is illustrative…

(As a postscript, I’ll add that parameterless default properties were always a bit weird because it appears there were never any clear rules about how they worked. If I remember correctly, not even the developer who owned the compiler’s semantic analyzer at the time could explain what was supposed to happen in some fairly straightforward cases. The spec was the code – as long as test cases from previous versions worked, the code was “right.” Ug.)

Playing the performance shell game

Another “just links” entry… I thought that Raymond’s entry on the performance shell game was particularly good, and Michael’s additional take was very relevant. Much of performance work involves shifting work around from scenario to scenario, and when doing so it is vitally important that you keep track of the bigger picture. The fact that it’s not possible to test every scenario can easily lead to tunnel vision, where you get so motivated to improve one important scenario (application startup) that you lose sight of perhaps an even more important scenario (OS startup) that’s “not your department,” but which impacts users all the same…

Comments broken (now fixed)… why didn’t anyone say anything?

In my continuing quest to block out comment spam, I made a tweak last week to my SQL scripts. Instead of doing a full-text match to a list of banned comment titles (among other filters), I started doing a keyword match. So if, say, you use the name of a certain drug that can help Bob Dole, then the comment would be automatically filtered out. Because this was a hack, I didn’t do anything fancy like put filtered comments into a table so that I can know if I’m filtering out legit comments.

Which, it appears, came back to bite me in the rear. When moving my list of banned stuff from “full text” to “keyword,” I failed to delete a banned comment title named “re:“. Since that automatically appears in the comment title when you post, that means that only comments that changed the title have been getting through for a week. It really *seemed* quiet around here, didn’t it? Alert reader David Totzke finally sent me an email through the Contact form saying “what’s up with this?” Which led me to the problem, which led me to the fix. Many thanks go to David! (And, in the future, anyone can use the Contact form to let me know if something isn’t working!)

I apologize to anyone whose comments have gotten incorrectly booted…

Save Ferris! I mean, VB6!

A few days ago Scoble emailed me with the heads up on his post talking about the MVP revolt spurred on, in part, by the fact that VB 6.0 mainstream support is ending this month. Then life intervened and I’m just now getting some time to get back to the whole brouhaha. In the meantime, this has roiled through at least a few corners of the blogsphere. I’d throw in a couple of gratuituous links, but if you read any number of .NET or VB blogs, you’re going to have seen them. Well, OK, two entries that stand out in my mind were those of Dan Appleman and Scott Swigart. There were plenty others that I although thought were good, but one man can only link so much. The petition itself can be found here.

I should start off with the statement that I have a great amount of sympathy for people who have not yet made the move off of VB6 and who would very much like to see support extended even further than it already has. I know that support can be a real issue and is something that people worry about. Beyond that, though, I can’t really say anything because I’m not even remotely involved or included in decisions about things like product support. I, along with the rest of you, will be interested to see what kind of response the outcry elicits.

As for the petition itself, it asks for two main things: 1. That we develop new versions of “unmanaged VB”, and 2. That we integrate those new versions of “unmanaged VB” into the Visual Studio shell.

To start with the second point first, to those who think we should integrate VB6 into the current Visual Studio shell, I can only offer the perspective of a developer who’s worked in both codebases: best of luck. In VB6, all of the pieces of the puzzle (compiler, debugger, forms package, runtime, etc.) were designed to work solely with each other and were tightly bound together. In Visual Studio, all of the pieces of the puzzle were designed to work with mutiple clients and were loosely bound together. Thus, the architectures are totally different and, in many ways, incompatible. Heck, we spent four years getting VB .NET integrated into the Visual Studio shell and we were writing it from scratch (and therefore could design a compatible architecture)! Trying to extract some of the pieces of VB6 and fit them into an architecture that was not designed to couple with them as tightly as their previous home would be a huge undertaking.

And when I talk about a “huge undertaking,” I’m not talking huge in terms of fungible stuff like money or people. I’m talking huge in terms of non-fungible stuff like time. No matter how much money or how many people we threw at the problem, it would still be a significant amount of time before anything could be produced. I’m talking, like, years. So, now we’re talking about having something in, what, 2007? 2008? At best? Ten years after the previous version of “unmanaged VB” shipped? I’m not really sure how that’s going to make much of a difference to the issues that people are confronting today.

Now, obviously, we could still satisfy the first request by shipping a new version of VB6 that wasn’t integrated into the Visual Studio shell, and that would take a lot less time. At this point, though, I don’t believe that even that would really buy people that much. Leaving aside the question of the desirability of a separate-but-sort-of-equal development envrionment, Microsoft has stated very clearly (pace Richard) that managed code is the direction that our company’s components and APIs are headed. As such, fostering new development (as opposed to extending support for existing development) in “unmanaged VB” doesn’t just postpone the inevitable, it makes it worse. It encourages people to keep writing a lot more code that, somewhere down the road, they’re going to have to port to .NET. It’s alleviating pain in the short term only to cause greater pain the long term, something that I don’t think it would be responsible for us to do. (One part of the petition that did mystify me a bit was the request to “Ease […] migration of unmanaged VB/VBA code to VB.NET.” Does anyone think that we haven’t been working on that?)

So, while I can be sympathetic to where the petitioners are coming from, I can’t ultimately support their stated goals. Obviously, we continue to have work around helping people make the transition from COM to .NET at their own pace and helping them be clear on the advantages of doing so. VB 2005 is going to help a lot here, I think, and we continue to work on even more things for the road beyond. In the end, I think that’s the best thing we can do.

When a step forward looks like a step backwards…

One of the things that would be amusing if it wasn’t so annoying is the way that a step forward can be perceived by people as a step backwards. Case-in-point: the commonly heard refrain that C# is the “official” language of .NET (and Microsoft) because so much of the frameworks are written in C#. Scott has a pretty good set of arguments against this canard framed in the context of the present day, but the thing that I find really ironic is how all this hand wringing is so woefully ignorant of history and how it is backhanded evidence of the essential correctness of the strategy of moving VB to .NET.

To wit: can anyone tell me, for the ten years (give or take) between the introduction of VB 1.0 and the introduction of VB .NET 7.0, how much of the Win32 APIs or the COM APIs were written in VB?

Of course the answer is: none, to my knowledge. In fact, the VB team itself did not use VB in any meaningful way in its own product. The VB runtime functions were all written in C/C++. The VB forms package was written in C/C++. All of the VB controls were written in C/C++. Beyond the VB team, every major Microsoft product and operating system was written using C/C++. Every. Single. One.

Now, during that time was there massive hand wringing about how “C++ is the official language of Microsoft” and how “I’m going to use C++ over VB because that’s what Microsoft uses”? Of course not. Why not? Because VB and C++ lived on two almost completely different planets. C++’s great advantage was that it had full and easy access to the entire power of the platform; it’s greatest disadvantage was that you had to do every damn thing for yourself. VB’s great advantage was that it took care of a lot of the nitty-gritty for you and make programming easy; it’s greatest disadvantage was that it didn’t have full and easy access to the entire power of the platform. (Instead, you often had to turn to advanced books or gurus to accomplish what should have been simple tasks.)

The reason why there is so much angst about this question now is because, for the first time, we’ve accomplished a relatively level playing field on .NET. VB is no longer limited in what it can do with the platform – if you need to customize what you’re doing with WinForms, for example, you have pretty much an unlimited ability to do so. And C# and C++ (using their CLI binding) now can take advantage of all the cool automatic features that VB users have been taking advantage of for decades.

So the bottom line is: as far as an “official” language goes, things are the same as they ever were. Actually, that’s not true: with the introduction of VB .NET, for the first time Visual Basic is being used in a meaningful way inside the company. Several of the libraries in the CLR 1.x were written in VB, and there will be even more VB code in the CLR 2.0. So, ironically, VB is actually much more of an official language at Microsoft than it has ever been, yet the external perception is just the opposite.

Which is why this particular line of argument grates on my nerves like nails on a chalk board. My suspicion is, though, that this erroneous line of thought has mostly been fueled by legitimate problems in the past with the messaging around .NET. What matters to people is not so much what the frameworks are written in, but instead what language we use to talk to the public with. All the hoopla around the new C# language combined with the natural affinity that many MSFT people feel for C-style languages (c.f. the last few paragraphs) meant that, for a while, things like talks, samples, and all manner of other code displayed publicly skewed heavily in the direction of C#. This was a mistake, and one that we’ve been working hard to correct – we’ve been very active in educating people internally as to how their language choice for example code can be perceived outside of the company. We’ve made a lot of progress, although there’s always more work to be done.

As for the whole “what the frameworks are written” in thing goes, maybe we should just decompile the frameworks using Reflector, recompile it using VB, and provide a “VB CLR”… (Note to the humor impaired: this is a joke.) Except, of course, for the non-trivial chunks of the frameworks that are written in C++…