IanG on Tap

Jeff ‘coding horror’ Atwood recently wrote a blog entry entitled C# and the Compilation Tax that touched on a various points. I felt like offering counterpoints to all of them so I thought I’d make a blog entry of it rather than disappearing into Jeff’s ever-overfull comments.

Just in case it’s not obvious, the last two parts of this aren’t entirely serious.

Multiple Choice

Jeff says he has:

“given up on the idea that .NET is a multiple language runtime”

Oddly, he seems to be conflating two different ideas. A ‘multiple language runtime’ can mean either ‘pick any language’ or ‘pick several languages’ and Jeff seems to be talking about both.

Back in the very early days of .NET, a few people tried the latter interpretation: using multiple languages in a single project. This was a really bad idea, for the reasons that Jeff sums up in the first three of his bullets. To be honest, I’m slightly surprised to hear Jeff resurrect the idea even if just to discredit it—I hadn’t realised anyone had tried to build that kind of project lately.

The way I’ve always seen it is that the multi-language feature of .NET is there to support the ‘pick any (single) language’ idea. The .NET Framework Class Library just doesn’t care whether you’re writing in C#, VB.NET, or any other language. And likewise, you don’t need to care what language(s) the class library may be written in. So you pick whichever language you’re most comfortable with and use that throughout your project.

In short, the most useful thing about .NET’s multi-language support is that it enables you to use just one language.

(Aside: one of the things that makes the forthcoming 1.1 flavour of Silverlight interesting to me is that it finally lets you use a single language end to end even in a web app—your ASP.NET back end and your RIA front end can all use a single language thanks to having .NET at both ends. And OK, you sort of had that with JScript before, but only kinda.)

While I’m surprised to see him raise the point, I agree with Jeff that using multiple languages in a single project is a really bad idea. However, Jeff is also taking issue with the more useful interpretation—the idea that you can pick whichever language you want. That’s interesting to me, because I hadn’t realised it was controversial. He makes this point:

“Most of the community has settled on C# as the de-facto standard, so you're in for a rough slog of code translation if you want to stick with VB and cleanly integrate commonly available source code libraries into your codebase”

For my first book, I offered both C# and VB.NET versions of every example. (All except one which wasn’t possible to write in VB.NET 1.0 due to a language limitation that was fixed in later versions.) But in my most recent book (co-authored with Chris Sells, 2nd edition due out real soon now) the samples are all in C# and XAML, so I guess I have to plead guilty on that one. (I don’t recall receiving any complaints about the lack of VB.NET examples so far, by the way.)

I use both C# and VB.NET in my work, but I’m more of a C# guy. (I use VB.NET when required to by customers, and that’s pretty much it.) So I have mostly been oblivious to the extent of this problem. However, I can see how much of an issue it could be—there has been a recent trend in Microsoft’s documentation to prioritise VB.NET examples over C# ones, and it really slows me down when I come across an example that’s only in VB.NET. I find VB.NET much harder to read than C#, because I don’t know it so well. Luckily for me, I get to see a lot more C# than VB.NET.

So I can see the point that the resources out there on the web make it easier to be a C# guy than a VB.NET guy.

But does that mean that .NET’s multi-language capability is of no use? I’m not so sure. I love PowerShell, for example. That’s a different language from C#, and with good reason—it tackles a different set of problems. But I love that the whole .NET framework is right there for me to use from within PowerShell. (I’m not so keen on the name, but that’s another issue.)

The .NET multi-language story seems to be working well for me there.

Perhaps the truth is that offering multiple languages that fulfil exactly the same role is pointless. And to the extent that C# and VB.NET offer the same feature set with different syntax, then there’s not much good reason for both to exist. (Other than history, and the need to overcome developer inertia... If there had been no C#, I’d probably never have taken .NET seriously as a reason to stop using C++. And if there had been no VB.NET, even more VB developers would have stayed for VB6 even longer than they did.) Perhaps if the feature set of these languages diverges, distinct raisons d’etre will emerge.

Who Are You Calling Insensitive?

Jeff also raises case sensitivity. Feel free to skip this whole section, what with this being an almost entirely pointless debate. But I just can’t let him get away with this:

“case sensitivity in a programming language is wrong, and will always be wrong.”

The problem with this is that there is no clearly-defined alternative.

You might be thinking “hold on, what about case insensitivity? Isn’t that a viable alternative?” But case insensitivity is relative, and consequently its definition is a bit woolly: when you say ‘case-insensitive’ what do you actually mean? VB.NET doesn’t seem entirely sure. It is quite happy with this:

DIM X AS INTEGER

And yet it’s not happy with this

dım X as ınteger

It barfs on my lower case letter ‘i’. And OK, so I used a Turkish lower case ‘i’ without a dot over it. (If the font your browser has chosen happens not to have that character, then just imagine a lower case version of the example, with no dots over the ‘i’s.) But I think that’s a perfectly good kind of lowercase version of ‘I’, and what’s more, VB.NET agrees with me! Let’s ask VB.NET to convert that back to uppercase:

Dim x = "dım X as ınteger"
Console.WriteLine(x.ToUpper())

it prints out the first example, which it was perfectly happy to compile.

What rules is VB.NET using for case insensitivity at compile time? I have no idea, but apparently it’s not using the same rules it applies to strings at runtime. Nice.

Case insensitivity is, by definition, parochial. The output of this:

Dim x = "DIM X AS INTEGER"
Console.WriteLine(x.ToLower())

varies from one culture to another. So does the result of this case-insensitive comparison:

Dim x = "DIM X AS INTEGER"
Dim y = "dim x as integer"
Console.WriteLine(String.Compare(x, y, True))

That prints “-1” in a Turkish culture indicating that the strings are not equal according to a case-insensitive compare. But in the en-GB culture, it prints “0”, indicating that the strings are equal.

This means that if your language is case-insensitive, the very syntactic correctness of your code is culture-dependent. As far as I know, VB.NET does the cultural imperialist thing, declaring that the only culture that matters for source code is en-US. But I’m not even completely sure that I’ve correctly identified VB.NET’s behaviour here.

Wouldn’t life be simpler with a language where such things are a complete non-issue?

But like Jeff said, it’s a religious issue. It doesn’t really matter that much—if you’re hitting issues where the case insensitivity (or otherwise) of your chosen language causes you an issue you’re probably doing something wrong. But Jeff’s still wrong.

Background Irritation

Jeff raises the lack of background compilation in C# as a cause of reduced productivity compared to VB.NET. I thought I’d just throw my experience in here as an alternative point of view.

I hate VB.NET’s continuous bloody interference. I HADN’T FINISHED TYPING YET YOU STUPID COMPILER! CAN’T YOU SEE THAT? DOES IT LOOK TO YOU LIKE I’M DONE TYPING? DID IT NOT OCCUR TO YOU THAT THE REASON YOU’VE FOUND ALL THOSE ERRORS IS BECAUSE I’M NOT FINISHED YET?!! I’LL TELL YOU WHEN I WANT YOU TO CHECK MY WORK, AND NOT BEFORE!

There. I feel better now.

Yes, I’m sure rebuilding my C# applications every other keystroke, as Jeff apparently feels compelled to do, would have a negative effect on my productivity. How could it be otherwise when VB.NET’s less than helpful attempts to do that automatically are so very distracting? “It looks like you’re writing program. Would you like help?” Oddly enough, I don’t feel the need to disrupt my train of thought continuously. So I would prefer it if VB.NET didn’t disrupt me automatically.

To put it slightly more seriously, I have a bunch of habits that are adapted to compilation happening only when I intend it to. Jeff has a bunch of habits that are adapted to compilation happening all the time. C# and VB.NET offer tools that are better adapted to one or other way of working. Neither is absolutely better than the other.