“Reports of my death…”

Ok, so another article claiming that “VB is dead” (or, at least, will be one of these days). Nothing particularly new. What was interesting about the article, though, was a pair of quotes from Uttam Narsu from Forrester Research. In the middle of the article he says:


[developers] ask if VB is the best language to do OO development. And generally the answer is no.

Then the same guy who gave the above quote later says:


[…] developers can produce programs faster with VB than with C#.

So… C# is a better language to do OO in, even though it takes longer to write an OO program in C# than it does in VB. That seems contradictory to me. (There also a statement by another analyst in the article about all the “baggage” that VB carries, which I also wonder about, given where the “C” in “C#” comes from…)

Caveat emptor

Sean and Scott say that I “let […] it be known that “Orcas” will follow the “Whidbey” release of .NET”, although I’m afraid that I can’t take credit. Eric beat me to it at VSLive! many months ago. I figured if my VP could say it in public, I could get away with it too… How’s that for CYA?

But I would add a “caveat emptor” on that as well. Looking beyond the current release is always an inexact science to say the least, and who knows? Another release could be added before Orcas. (Wonder why Whidbey and Orcas are islands, while Everett isn’t?) Or the codename could change. Or giant alien ants could arrive on our planet, making the entire software industry as we know it obsolete. (And, in the immortal words of Kent Brockman, “I, for one, welcome our new insect overlords.”)

So I wouldn’t get too hung up on Orcas just yet…

Codenames

In addition to talking about existing features of the language, I’m also planning on talking some about some future features. (I won’t, however, be revealing anything that hasn’t already been publicly announced, sorry.) Before doing that, though, it’s probably useful to talk for a moment about the various codenames for versions of VB .NET that I might unconsciously use:

  • RTM: This is what we tend to call Visual Basic 2002, namely because it didn’t really have a codename. “RTM” stands for “Release To Manufacturing,” which is the final milestone in any product. Given that the VB 2002 release was a long time in coming (some of the original groundwork was started before VB6 shipped, in 1998), this may also have been a bit of an unconscious choice…
  • Everett: This was the codename of Visual Basic 2003. Everett is a city north of Seattle.
  • Whidbey: This is the codename for the next release of Visual Basic, the one we’re working on now. Whidbey is an island north of Seattle (you go through Everett to get to the ferry to Whidbey Island). It’s also the place where I got married a number of years ago.
  • Orcas: This is the codename for the next release after Whidbey. Orcas is an island in the San Juan group of islands even further north of Seattle.

Assuming everything goes well, I’m going to spend a little time talking about some planned features for Whidbey. I won’t spend any time talking about Orcas because: a) we haven’t really announced anything about it, and b) it’s far enough off that I probably couldn’t talk accurately about details anyway.

In case anyone is wondering, there is no apparent rhyme or reason to whether a project gets a codename or to what the codename is if it does get one. About half the projects I’ve been on didn’t have codenames, the other half did. My favorite codename is, of course, the only one I ever got to pick. It was Access 97’s codename, Mach5. (I’ll let you figure out the reference yourself.)

DirectCast revealed

Since I’m on the cusp of rewriting the section in the VB language spec on DirectCast so that it actually tries to make sense, I thought I’d talk about it here, since I don’t know how much people understand about this strange little operator. DirectCast is a cast operator that has the same syntax as CType and is useful in some narrow situations. But first, a little background…

You may have noticed that all VB.NET projects get a default reference to Microsoft.VisualBasic.DLL. It doesn’t show up in your list of references because you can’t remove it. Why? Because it isn’t possible to express all of the VB language in IL, so we sometimes have to rely on helper functions. A good example of this is conversions from Object. If you convert an Integer to Object, for example, the CLR will only let you convert it back to Integer. However, VB will allow you to convert it back to Long, Double, String, etc. To make this work, the compiler emits a conversion from Object as a call to a helper function. The helper function takes the Object, looks at the type of the value contained in it and then does the appropriate conversion to the target type.

When we started working on Microsoft.VisualBasic.DLL, we decided to write all the language helpers (and all the familiar user functions like Left, Right, Mid, etc) in VB. In addition to the fact that we like VB, it’s also a great way to dogfood the product. So we set about writing the helpers, but we quickly ran into a chicken-and-egg problem. Let’s say that we’re writing the helper that converts something typed as Object to Integer. It would contain code something like:

If TypeOf o Is Integer Then
    Return CInt(o)
End If

See the problem? The CInt(o) conversion tries to convert something typed as Object to Integer… which is going to call the helper again. And again. And again. Until you run out of stack space and die. The problem was there was no way to “escape” from the extra VB conversion semantics and say “just cast this directly to x type, forget about all the fancy stuff.” And that’s where DirectCast comes in. The function of DirectCast is to just give you the CLR supported conversions and none of the extra conversions that VB supports by use of a helper. So when you say DirectCast(o, Integer), if o does not contain an Integer, you’ll get an exception, whereas CType(o, Integer) will work if o contains a Long, Double, String, etc. As you can imagine, we use this all over the place in our helpers.

Ok, so now you’re asking: “So why isn’t this just something you hacked in for building your runtime? Why did you make it a full part of the language?” Well, one reason was that we wanted to follow the principle that we didn’t want to have to “cheat” to build our runtime – presumably, if we needed to do something, others might, too. (There are still a few minor cheats that we make when building our runtime, but that’s another blog entry.) And, as it turns out, there are some narrow situations where using DirectCast can make things a tiny bit fast than they might otherwise be. Essentially, if you know that what you’re converting is exactly what you say it is, then you can use DirectCast to bypass the little bit of overhead that you incur by using the runtime helper. The most common place I use it in my own code is when dealing with collections like ArrayList:

Dim a As New ArrayList()
Dim i As Integer
a.Add(42)
i = DirectCast(a(0), Integer)

In this case, I know that the thing I’m getting out of the ArrayList is an Integer, so I skip the helper and go straight to DirectCast. However, I only suggestion you use this in situations where you know it will work, and you think you need that extra little bit of performance. In the real world, you’re hardly ever going to notice the difference, so you might as well go with the more flexible conversion operators like CType, CInt, etc. But when you identify some place you need that extra little “oomph,” it can come in handy.

Another thing I’m going to have to get to…

Frans has a very interesting reply to an entry by Roy. A lot of it is about particular design aspects of one language versus the other, which I think people can argue about forever and ever, but what caught my eye was:

I personally think Microsoft has made a mistake by introducing VB.NET. The reason for this is that VB.NET creates a serious positioning problem: what’s the real difference between C# and VB.NET besides some language definitions? Is one the real RAD tool and the other for the keyboard-lovers who like to do everything the hard way? Why does one have XYZ and the other does not and vice versa? I don’t see it why they’ve created these problems in the first place. […] I therefor won’t be surprised when Microsoft phases out VB.NET in the long run over C# […]

My first reaction to the question “Why did Microsoft create VB.NET?” is always to think of Louis Armstrong’s response when he was asked to explain jazz: “Man, if you gotta ask, you’ll never know.” And then my second reaction is: if you use VB.NET and
VC#.NET for a while, you’ll quickly realize that they are not just the same language with different syntax. To use a phrase that will date me, they each have a very distinct “look and feel” that goes beyond which features each language supports, and this look and feel is has significance. (To riff off my Louis Armstrong reference, to me VB feels a lot like jazz, while VC# feels a lot like classical music.)

But I realize all this touchy-feely stuff doesn’t really answer the question. It’s definitely something I’m working on nailing down because I think it’s vital that we be able to articulate it in a better way than we have in the past. And out of that explanation should flow the reality that VB.NET isn’t going anywhere in the short term or the long run. The free market, of course, gets the final word (as always), but we’re going to continue to bang away hard on new versions of VB.NET as long as there are people who are going to use them…

Finding the balance

OK, so I’m just following the latest trend at Microsoft – even though my first post is conveniently dated several days before this article. Now I’m just left hoping that I’m not the one that “blow[s] it for everybody else” (as Joshua Allen succintly put it).

This blog is a bit of a mix. It runs on hardware and software that I purchased with my own dime and is physically located in my basement in an old armoire (which my wife insists on calling a “chiffarobe,” like some character from “To Kill a Mockinbird”). On the other hand, I’m naturally going to talk about what I spend a lot of my day doing, and I will occasionally post on company time, like right now. So it’s going to be a delicate balance, and one that I’ve obviously been thinking about for a long time.

Back in my salad days of uber-geekdom (i.e. in my early teen years before I discovered the opposite sex), I was a Doctor Who fanatic. As such, I naturally owned a highly prized Tom Baker-esque wool multicolored scarf, to which I would affix various Doctor Who related buttons. One of the few that wasn’t Doctor Who related (and the whole point of this story) was one that read “Proudly Serving My Corporate Masters.” I think that about sums up my relationship with my employer: I’m basically a semi-sellout who really enjoys working for the Man and everything that comes with it, but who nonetheless likes to pretend that he can also be his own man, with a little “m.” Am I fooling myself? Depends on who you ask, I guess…

[Ed. note: I am extremely frightened to find that a quick search on Google reveals
that an ex-Microsoftie has written a book called “Proudly Serving My Corporate Masters.” Am I really that unoriginal? As it turns out, maybe. The author tracks down where the phrase came from, and… there’s my button!]

An interesting story…

I was going to avoid the sensitive subject of the VB6 to VB.NET upgrade for a while – you know, get my feet wet before tackling anything difficult – but my hand has been forced. Robert Scoble posted a story about the competition between Canon and Nikon that made me think of that particular controversy. The quotes that I found most interesting were:

So, how did Canon get in? Easy, they changed their lens mount. Whoa, wouldn’t that piss off professionals? After all, do you know how much a 300mm F2.8 lens is? About $4000. Wouldn’t people rebel against “lock in?” Especially “lock in” that demonstrated the company didn’t see much value in keeping their lens mount the same?

And:

But, do you think that professional photographers didn’t hate Canon for changing their lens mount and taking an approach toward its customers that said “we’re gonna obsolete you, and make all your old stuff worthless so we can make a better product?” Heck yes! But, funny thing about customers. They buy a better product.

I don’t draw any particular conclusions from the story (after all, Nikon could have just improved their autofocus without changing their lens mount), but it does have interesting intersections. Anyway, I’m sure I’ll have more to say about this as we go along.