Monthly Archives: July 2003

Pulling on the loose thread…

Anand asks me in a comment whether I’m going to support TrackBack. It’s a very relevant question, as I’m currently neck-deep in a rewrite of the BlogX code to add a whole bunch of features that it currently lacks. In fact, I’m very lucky that my wife is also currently neck-deep in grading for the summer class she teaches, or else my disappearing into my study for long stretches of time during a weekend of beautiful weather would cause some marital friction…

This all started, of course, by pulling on a single loose thread on the sweater: in the immortal words of our current president, I “misunderestimated” how much interest my blog might pull in, so each day I’ve been watching a bit alarmedly as the amount of my bandwidth being eaten up by the blog has grown and grown. I finally turned on gzip compression in IIS (I believe), which should help, but what I really wanted to do was implement ETags and Last-Modified on my RSS feed so I can cut down on the huge amount of bandwidth that SharpReader is sucking up. (They’re, like, 50% of the hits. Good for Luke… I use it too!) So I figured, “Hey, it’s .NET and I work on .NET. How hard could it be?” Classic last words for a developer.

The first problem was that, as much as I like C#, I just think a whole lot better in VB because I don’t have to translate as I work (and I like the VB IDE experience better, but I may be sliiighly biased). So first I translated most of BlogX (everything except the HTML control for WinBlogX) into VB using an automated translator. And then I spent a bunch of time cleaning up all the problems and stylistic disagreements that that caused. And then I spent a bunch of time cleaning up the code base so that it worked “the way I like it.” (This is no knock on Chris, I’m just one of those anal developers who just aren’t happy if they haven’t rewritten most of any codebase they take on.) And then I finally got around to trying to add new features. Which of course made me realize I didn’t understand how the whole thing worked, which entailed more research and rewriting, blah, blah, blah, blah.

Suffice it to say, I’ve devoted way more time to this than I had ever planned and still haven’t gotten a fully functional blog working. But I’m getting close! And soon this blog will have all kinds of whizzy-bang features. And I’ll have learned a whole lot of things about web programming that I never knew, which was really kind of the original point anyway.

And then Dare will release a new version of BlogX with all the features I added and many more to boot, and I’ll wonder, “Was it really worth it?”

Language divergence

Eric points to an editorial from Visual Studio Magazine that I think is really spot-on, although I think the title is a bit of a misnomer.

Patrick is, I think, accurate about some of the whys and wherefores of VB.NET’s history, and about the need to recapture some of what has been lost in the transition to .NET. There’s no question, for example, that not having edit and continue has been a huge loss, something that has been keenly felt within the company as well as without. It’s going to be a major feature in Whidbey and one I’m very excited about getting back. (I’d better be, since one of the things I’m supposed to do is make sure we do edit and continue right. If it’s wrong, my head is going to be one of those on the block…) And there’s even more stuff that we’re working on in addition to that, but we’ll get to that later, I hope…

The only issue I have with the editorial is the use of the phrase “language divergence.” The phrase is problematic because it’s so general that it can mean a lot of things that are not what we’re working towards. For example, it doesn’t mean that VB.NET is going to stop providing excellent support for the platform. It also doesn’t mean that we’re going to try and “dumb down” the language or compromise on the power and flexibility that we afford developers today. What it does mean, to us at least, is that VB is not just “C# without braces.” Our goal is not to just ape whatever another language does, our goal is to server our customers as best as we possibly can. If that means that we do some things differently than C# does, then we’ll do them differently. If that means we do some things the same way as C#, then we’ll do them the same way. Some people (not Patrick) have used “language divergence” as a shorthand for a mindless “not C#” philosophy, which would be incredibly short sighted and is not what we’re doing. Just as C# borrowed a ton of concepts that VB made popular, we feel free to borrow their best ideas right back. Why not, if it helps our customers?

So, in the end, I think the whole “C# vs VB” argument is a non-starter. The real question is: are we doing a good job making your life easier? Are we the best tool for developers out there? That’s the important thing and what we focus on every day.

Dictionary lookup operator

I’ve been converting some C# code into VB (because I think better in VB than I do in C#), and the conversion reminded me of another small feature of VB that people tend to forget about. Everyone who’s used Access or VB probably is familiar with the ! operator. Most of the time, you probably used it with DAO/ADO, something like: (Forgive me if the methods are wrong, it’s been a while since I wrote any non-ADO.NET code.)

rs.AddNew()
rs!CustomerName = "John Smith"
rs!Address = "10 Main Street; Seattle, WA"
rs!Phone = "(206) 555-1212"
rs.Update()

You probably used the ! operator because you saw someone else using it, and it was a lot easier than writing rs.Fields("CustomerName") = "John Smith". But you probably never thought about what, exactly, the ! operator was doing. Sadly, the operator has fallen somewhat into disuse because of the advent of strongly-typed datasets in ADO.NET. But it’s still quite handy!

The technical name for the ! operator is the “dictionary lookup operator.” A dictionary is any collection type that is indexed by a key rather than a number, just like the way that the entries in an English dictionary are indexed by the word you want the definition of. The most common example of a dictionary type is the System.Collections.Hashtable, which allows you to add (key, value) pairs into the hashtable and then retrieve values using the keys. For example, the following code adds three entries to a hashtable, and looks one of them up using the key “Pork”.

Dim Table As Hashtable = New Hashtable
Table("Orange") = "A fruit"
Table("Broccoli") = "A vegetable"
Table("Pork") = "A meat"
Console.WriteLine(Table("Pork"))

The ! operator can be used to look up values from any dictionary type that indexes its values using strings. The identifier after the ! is used as the key in the lookup operation. So the above code could instead have been written:

Dim Table As Hashtable = New Hashtable
Table!Orange = "A fruit"
Table!Broccoli = "A vegetable"
Table!Pork = "A meat"
Console.WriteLine(Table!Pork)

The second example is completely equivalent to the first, but just looks a lot nicer, at least to my eyes. I find that there are a lot of places where ! can be used, especially when it comes to XML and the web, where there are just tons of collections that are indexed by string. One unfortunate limitation is that the thing following the ! still has to be a valid identifier, so if the string you want to use as a key has some invalid identifier character in it, you can’t use the ! operator. (You can’t, for example, say Table!AB$CD = 5 because $ isn’t legal in identifiers.) In VB6 and before, you could use brackets to escape invalid identifiers (i.e. Table![AB$CD]), but when we started using brackets to escape keywords, we lost the ability to do that. In most cases, however, this isn’t too much of a limitation.

To get really technical, x!y works if x has a default property that takes a String or Object as a parameter. In that case, x!y is changed into x.DefaultProperty("y"). An interesting side note is that there is a special rule in the lexical grammar of the language to make this all work. The ! character is also used as a type character in the language, and type characters are eaten before operators. So without a special rule, x!y would be scanned as x! y instead of x ! y. Fortunately, since there is no place in the language where two identifiers in a row are valid, we just introduced the rule that if the next character after the ! is the start of an identifier, we consider the ! to be an operator and not a type character.

“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.