Monthly Archives: May 2004

The “native” .NET language?

In the comments on my post on language choice, Patrick asked “isn’t C# the language that’s most ‘native’ to the .NET environment?” Christopher then follows up with a related question as to whether developers should use functions in the System namespace instead of ones in the Microsoft.VisualBasic namespace because the former might be faster. We see these kinds of questions fairly often, so it’s worth discussing them a little bit.

Before going any further, I’d recommend that people who have questions like this take a look at an article that Derek Hatchard and Scott Swigart wrote for MSDN entitled “Visual Basic .NET Internals”. It looks at a bunch of these issues in detail and is an excellent place to start on this question.

The bottom line, though, is that there is no language that is ‘native’ to the .NET environment. While it’s certainly true that there was no language called ‘C#’ that existed before .NET came into being, one of the major selling points of C# is that it is an amalgm of the syntax and features found in C, C++, Java and VB, adapted for the .NET platform. In that sense, it is exactly like Visual Basic on .NET – an adaptation of a previously existing language (just as C++ and Java were, in turn, adaptations of C, which was, itself, an adaptation of prior languages). Both C# and VB were designed to work well with .NET, and developers can choose either language without any concern about access to the fundamental capabilities of the .NET platform, because they both compile down to IL in the end. The only differences you’re going to see between the IL the two languages generate is when one language does something more for you than the other language does (or we have a bug, in which case, let us know about it).

The question of the Microsoft.VisualBasic namespace is similarly straightforward. The base class libraries (i.e. the System namespace) provide a huge amount of functionality which both C# and VB give you full access to. The functions in the Microsoft.VisualBasic namespace are built directly on top of the System namespace and provide functionality that goes above and beyond the functionality that the System namespace provides. As such, there is no real reason not to use the functions there because they provide you “all the features of the class libraries and more.” (And we’re going to go even further in VB 2005.) Having said that, there may be situations in which you may want to sacrifice some of the extra functionality for a little more performance. This is the same kind of tradeoffs that you have to make with the System namespace, and so if performance is critical, it’s always important to understand the functions that you’re calling (the paper linked to above talks a lot about this).

The problem with blanket pronouncements like “always use CLR functions instead of VB functions“ is that you can easily shoot yourself in the foot without knowing it. One suggestion I’ve seen in more than one place is to use the functions exposed by the Convert class (a CLR class) instead of the intrinsic conversion operators (CInt, CStr, CLng, etc.) exposed by the VB language. This is supposedly because the CLR functions are going to perform better than the VB “functions.” The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you’ll get significantly worse performance by calling Convert.ToInt32 instead of using CInt. So it’s always very important to know what you’re doing when you start tackling issues like performance.

So, in the end, there is no “native” language on the CLR and performance is something you’re going to have to think about no matter what language you choose. (In fact, I think I should add a rule #0 to my “Ten Rules of Performance:” When it comes to performance, beware rules.) There are certainly lots of other factors to think about when choosing between VB and C#, but I don’t think these are two of them.

Send us those Watson reports!

I would have to second Cyrus’s request for everyone to send us Watson crash dumps when you run into problems. Watson is an invaluable tool for finding squirrly bugs that may be difficult for us to reproduce or require configurations that, for some reason, we don’t test. I will also add that debugging a Watson crash dump is a big pain in the rear, so you can also take some perverse pleasure in the fact that whoever introduced the bug in the first place is going to have to suffer to fix it. (I confess that sometimes I get a little jolt of satisfation on this as a user when I’ve hit some particularly bad crash.)

Interestingly, in VS 2002 and VS 2003, the VB compiler itself won’t report most crash dumps. That’s because Watson normally works by catching unhandled exceptions that escape out into the system. The problem with this is that after Watson finishes collecting its crash information, it really can’t do anything but kill the offending process, so you lose everything you’ve got in the IDE at that point. So instead of having compiler crashes result in losing everything, the VB compiler catches all of its own exceptions and gives you a dialog that says, in effect, “Something bad really happened. Save all your work and restart the IDE.” Since we never let any exceptions escape out into the system, Watson never gets involved. (I believe the C# compiler does the same thing in VS 2002 and VS 2003.)

For VS 2005, Watson has been enhanced to allow us to invoke it without actually having to kill the application. So going forward, VB will give you a Watson dialog to let you report the crash and then let you save your data. So we expect to get a lot more Watson reports this time around, which is a good thing. (As a side note, in VS 2002 and VS 2003, we did allow exceptions to escape to Watson during the betas so we could get better beta information. It was just suppressed in the released retail version.)

Interestingly, one of the handful of features that I actually implemented in VB 2005 was enabling this Watson reporting…

Should I move from VB6 to VB .NET or C#?

TechEd 2004 was crazy busy, so there’s going to be some catch up time before I get back into full swing blogging. However, one thing I did want to relate before I forget it.

Last night, Duncan Mackenzie, Amanda Silver, Steven Lees and I (the middle two are VB Program Managers) were having dinner at TechEd and we started discussing the logic of a statement made by several customers during the conference that boiled down to: “We figured that since VB .NET wasn’t the same as VB6, we might as well move to C# when we moved to .NET“ After thinking about this for a moment, it occured to me that this is somewhat akin to saying:

“We figured that since British English wasn’t the same as American English, we might as well learn German when we moved to Europe.”

I mean, it’s a free country and all, but the logic of this does seem a little, well, illogical. Although the two languages can do many of the same things and have many similarities, taking on the extra burden of doing the cultural retraining necessary to move from VB to C# without some kind of well-researched rationale seems to me to be doing a whole lot of work that you don’t really need to. VB .NET adds a lot of power to VB and tweaks a few familiar things, but it’s still substantially the same language, just in the same way that British, American, Canadian and Australian English are all the same language, even if three out of four insist on using “u“s in funny places. (Although on the plane ride back, I got stumped on a crossword because I wrote in “lustre“ rather than “luster.“ I guess I watched too many British shows on PBS growing up.)

The way of the world, I guess, but it doesn’t make sense to me…

Why aren’t Try variables in scope in the Catch or Finally?

Bill McCarthy recently asked me a question that’s come up a number of times both internally and externally: why can’t a Catch or Finally block access local variables declared in a Try block? In other words, why doesn’t the following work?

Try
    Dim i As Integer = 5
Finally
    Console.WriteLine(i)
End Try

There are four answers to the question: the practical answer, the simple answer, the complex answer and the real answer.

THE PRACTICAL ANSWER: The question is moot because changing it now would potentially break code by changing the binding path. For example:

Class Foo
    Private i As Integer
    Sub Bar()
        Try
            Dim i As Integer
            Throw New NullReferenceException()
        Catch
            i = 5
        End Try
    End Sub
End Class

THE SIMPLE ANSWER: Catch and Finally blocks are not children of the Try block, they’re siblings. You can see this by the indentation style and by convention. And the normal scoping rules are that sibling blocks cannot see each other’s locals.

THE COMPLEX ANSWER: You can still say “Yes, but you could still have made an exception in this case, right?” True. However, requiring Catch/Finally variables to be placed outside of the Try block generally results in better code by emphasizing the initial state of the variable (since an exception can occur almost at any time, so the initial state is the only thing you can assume). For example, the following code has a bug — if the File constructor throws an exception, then the Close call is going to throw one too.

Try
    Dim F As File = New File("foo.txt")
    F.Read(...)
Finally
    F.Close()
End Try

THE REAL ANSWER: You may find both of these arguments unpersuasive, which is fine — a quick search on Google quickly found similar debates around Java and I’m sure other languages have them too. The real answer is that it’s a judgment call and certainly one that we’ll probably be arguing about from here until eternity…

Attributes, CLS compliance and VB 2005

Since I’m answering questions today, I might as well address Robert‘s question as to why VB doesn’t support attributes that take 1-dimensional arrays. Actually, not only does VB not support attributes that take 1-dimensional arrays, we also don’t support attributes that take parameters typed as Object. So why not? Time, mostly, but the CLS comes in to play here as well.

Attributes that take 1-dimensional arrays and Object are not CLS compliant, as per CLS rule #34 (see pg. 118 of Jim Miller’s excellent Common Language Infrastructure Annotated Standard book). Interestingly, though, the C# compiler does not warn you when you declare attribute constructors that use the non-CLS compliant types but you declare your assembly to be CLS compliant. My take on it is that they have a bug in their compiler and that they should warn you. However, I suspect they might also make a claim that the vague wording of the rule makes their compiler behavior correct – the rule states that other types cannot be “encoded,” so I guess they could argue that it’s not the attribute definition that’s non-CLS compliant, but some theoretical use of it. However, the CLS rules generally talk about prohibit you from declaring something non-CLS compliant not using something that’s non-CLS compliant, so I’m not sure I would lend this argument (if, indeed, they actually wanted to make it) much credence.

Anyway, language lawyering aside, the issue was that attributes came online very late in VB 2002, and we ended up not support 1-dimensional arrays and object values in attributes for time reasons. We figured it wouldn’t be that big of a deal because, hey, they’re not CLS compliant! Of course, since there’s no warning from the C# compiler about using these types in attributes, people expect them to work in VB and, when push comes to shove, the CLS argument just isn’t very satisfying. Which is all a long way of saying that we’re supporting them in VB 2005.

And I’m going to have to go now and test to see whether we give you a CLS warning…

Explicit interface implementation (and event handling)

Christian notes some differences between the way C# and VB implement interfaces, prompting Peter to ask “Was it accidental or intentional?” The answer is: it was intentional. The exact thought process that lead to the current design is somewhat misty in my memory because it was so long ago, but here’s kinds of how it went:

VB6 supported implicit event handling and interface implementation very similar to the way that C# does implicit interface implementation. You stated that you implement an interface and then you used a “magic name” to implement a method in the interface. When we were designing VB 2002, though, we wanted to allow people to handle multiple controls’ events with a single handler. The magic name design for event handling would have effectively prevented that, because there was no reasonable “magic” name that could mean “hook me up to x.Click and y.Click.” (C# obviously doesn’t have this problem since they don’t support declarative event handling.) So we decided to drop magic naming for event handlers in favor of an explicit Handles clause that allowed multiple events to be handled.

Once we’d taken that step, we decided we liked the new explicitness of event handling and decided that it would work for interface implementation as well. It meant that we could get rid of clunky VB6-style magic names (i.e. “Sub IDisposable_Dispose(…)”) entirely and also meant that a single class member could implement multiple interface members, although so far I don’t know of many places where that comes in super-handy (since most interfaces are, by nature, discrete from one another). Also, because it didn’t rely on magic names, there was no chance that you might “accidentally” implement an interface member without realizing it.

So that’s the story.

TechEd 2004 sessions

Things are starting to heat up for TechEd 2004! I’m not going to be speaking this year, but I’m going to be doing the following:

  • 5/24, 5pm – 9pm, Working at the VS 2005 booth
  • 5/25, 12:30pm – 5pm, Working at the VB Community Lounge
  • 5/26, 9:30am – 1pm, Working at the VS 2005 booth
  • 5/27, 9:30am – 1pm, Working at one of the VS 2003 booths

I’m also going to be doing a book signing with Addison Wesley on Thursday, 5/27 from 12:30pm to 1:30pm so come by, buy a book and/or get one signed!

We’re also going to be having the following major track sessions:

DEV340  Visual Basic: Tips and Tricks for Optimizing Your Applications
Monday, May 24 10:45 AM- 12:00 PM, Room 31ABC
Speaker(s): Brian Randell
Track(s): Developer Tools and Technologies
What do you need to know to build the most powerful solutions with Visual Basic .NET? This session presents tips and tricks, optimizing techniques and gotchas covering the VB language, data, deployment, security, Windows, Web, devices, .NET Framework, and more.
 
DEV341  Visual Basic: Migrating and Upgrading Lessons Learned
Monday, May 24 3:15 PM- 4:30 PM, Room 3
Speaker(s): Jay Roxe
Track(s): Developer Tools and Technologies
Do you have VB 6.0 applications that you want to migrate to .NET? Get best practices for planning and executing your migration smoothly, and learn from previous migrations. Topics covered also include the migration wizard, and the VB 6 code assistant.
 
DEV342  Visual Basic 2005: Rapid Development the VB Developer
Thursday, May 27 8:30 AM- 9:45 AM, Room 20D
Speaker(s): Steven Lees
Track(s): Developer Tools and Technologies
Visual Basic 2005 will reduce the amount of code required to write your application by 50% or more in common scenarios while continuing to provide full access to the .NET Framework. See how drag-and-drop data access, centralized application management and deployment, an improved debugging experience, and rich IDE features will help you accomplish common tasks while dramatically reducing the errors in your code at design time.
 
DEV343  Visual Basic 2005: IDE and Language Enhancements
Thursday, May 27 5:00 PM- 6:15 PM, Room 6B
Speaker(s): Amanda Silver
Track(s): Developer Tools and Technologies
Visual Basic 2005 will take developer productivity to new heights while leveraging the full power of the .NET platform. See how substantial language enhancements and rich IDE features will dramatically increase your productivity and help you write more compelling applications. Learn how to author strongly typed containers using generics, make your applications more efficient with asynchronous calls, and utilize the power of the platform using My. Learn how these features — as well as XML documentation comments, operator overloading, Code Snippets, and more — make Visual Basic 2005 the most powerful and productive release ever!
 
DEV390  .NET Framework: So You THINK You Know What an Object Is…
Tuesday, May 25 10:45 AM- 12:00 PM, Room 6A
Speaker(s): Carl Franklin
Track(s): Developer Tools and Technologies
You’re a VB programmer. You might think you know what a .NET object is, but do you really? Things are not really as they seem in this most popular session which explores reference types vs. data types, the effects of casting, shadowing, overriding, and other OOP mechanisms on objects in Visual Basic .NET, and how you can easily be tricked into thinking one plus one does not equal two.
 
DEVC38  Meet the Visual Basic Team
Thursday, May 27 3:15 PM- 4:30 PM, Cabana 06
Speaker(s):
Track(s): Developer Tools and Technologies
Come meet the Visual Basic team! Get your questions answered about today’s solutions and tomorrow’s technologies. Give your input on what features we need to continue to make VB successful for the next ten years.

Yes, coding *is* a zero-sum game, Robert…

Scoble questions whether greater community engagement really takes away from time that developers have to spend on other things like fixing bugs. I would have to agree with John Cavnar-Johnson on this one: from personal experience, blogging and other community engagement like the newsgroups does suck time away from other activities that I could be pursuing like designing new features, writing new code or fixing bugs. I don’t think Scoble is totally off base with his “all work and no play makes Jack a very dull boy” thesis, but I think that that model only really applies to the creative end of development which is only one part of the overall work it takes to get a product out of the door. A huge chunk of the product development cycle is, indeed, one-step-after-another work where you just have to get the damn work done. And if you’re busy blogging, you’re not doing that.

That being said, I am reminded of the famous Churchill quote, “Democracy is the worst form of government except for all the other forms that have been tried.” As in, yeah, it sucks that community engagement takes time away from other things, but what’s the better alternative? Robert has it right that community engagement provides valuable insight to both us and the community, and so even if it’s a zero-sum game in terms of developer time, I still think everyone comes out ahead.

Which, I suppose, was Robert’s original point. OK, I guess it’s time for me to go back to doing something useful…