Somehow I’d missed that one of our VB MVPs, Rocky Lhotka, has started a weblog! He starts out with thoughts on his C# journey for one of his books, which includes the observation:
In many ways, C# really is just VB with semi-colons.
Rocky’s been a great resource over the years (and was even nice enough to do some technical reviewing of my book) and I’m looking forward to reading his thoughts on all things .NET!
One of the reason things have been slow around here is that I was preparing a presentation yesterday to the VB MVPs yesterday at the MVP Global Summit. Since we’ve been talking about the VB 8.0 language for quite a while now (and we’ve had several semi-public releases), there wasn’t a lot new to talk about so we just discussed the new language features in more detail. It reminded me yet again that I need to get more detail on some of the new features up here and out in public.
My only regret was that I ended up missing most of the MVP events, which sounded like they were a good time. I did get to meet Anand M. and Julie Lerman, which was great, although I missed out on meeting all the other bloggers who were there! Maybe next time (or TechEd)…
Anand’s big question was “why aren’t there more VB team bloggers?” He’s right, and it’s something we’re working on…
For those of you who’ve been considering buying my book but just want to make sure that it’s worth whatever they’re charging for it these days, Addison-Wesley (my publishers) has provided a sample chapter online in PDF format. The chapter is about inheritance, so it should give you a good idea of what the rest of the book is going to be like.
As always, you can buy the book here.
I hate to post on something after everybody and his sister has posted about it (mmmmm… groupthink…), but I just wanted to make sure that my corner of the world was, indeed, aware that we’ve released the first of several technical previews of Visual Studio 2005. As someone who works off of daily builds and frequently finds that things suddenly stop working for no reason, let me just say that they are strictly “let’s see what’s new” stuff and not “let’s deploy something real” stuff. Caveat emptor. Mileage may vary. See store for more details…
Finally got around to adding the little sidebar flair for TechEd 2004… I won’t be speaking this year, but I will be in attendance! We’re hoping to do a book signing and I’m sure I’ll be hanging around the booth a lot. Hope to see you all there!
Joel talks about the fact that the major modern languages have ignored the fact that data access has become one of the most (if not the most) common jobs that programmers have to tackle. He says:
It’s about time that a language designer admitted that RDBMS access is intrinsic to modern application implementation and supported it in a first-class way syntactically.
So let me be the first to admit it: RDBMS access is intrinsic to modern application implementation. It’s the second part of Joel’s statement – the supporting it part – that’s the hard part, though. Makes me think of the Mark Twain quote, “Everyone complains about the weather, but nobody ever does anything about it.”
I think Erik Meijer and the Xen guys have a lot of interesting ideas, though…
The discussion so far in the comments section of my entry on permissiveness has been interesting. Some thoughts about the comments so far:
And, finally, I should say that we recognize that our goal to make VB the most accessible programming language on the .NET platform is still not completely realized. The process of consuming and digesting the vastness of the .NET platform has been a difficult, long-term process and one that we’re going to be working on for some time to come. The good news is that we’re going to make some huge strides in Whidbey, both in ways that have been talked about (such as the My hierarchy) and some ways that still haven’t been revealed.
I just wanted to take a moment to acknowledge an interesting series of entries by Mike Schinkel (here and here) that were followed up by a reply by Eric (here) and a further reply by Mike (here). To be honest, my reading attention span can be very short and I find my eyes glazing over when I start to read longer-winded blog entries, but these did catch my attention. (My short attention span is, of course, very ironic given that I can be kind of long-winded myself…)
To grossly oversimplify Mike’s points, he feels that
I have absolutely no argument with point #1. The kitchen-sink approach to VS IDE development has had its upsides, to be sure, but the resulting behemoth is a bit too complex even for my taste. And I’ve gotten this same feedback from others as well. This is definitely something we’re working to address in the future.
Point #2 is a little more interesting. There’s the usual problem with the overwhelming size of the Framework and how to make that digestible, but Mike also raises the question of strictness. He makes the argument (echoed by Don Box and others) that many programmers would do better with a world that’s more typeless and less strict than the one they get on .NET. As someone who lives day to day in a strongly-typed world (so to speak), this seems somewhat counter-intuitive: less typing usually equals less performance and less compile-time checking, leaving problems to be discovered at runtime. In fact, one of the major features of this release, generics, is specifically about making it easier to have *more* type safety and better performance at runtime. So the persistent voices in favor of scripting appear to be swimming against the tide. The question is: are they right?
To be honest, I think the whole question deserves more thought. We purposefully spent a lot of time making sure that things like operator overloading and generics work with late binding in Whidbey, so it’s not like we’re closing down that avenue of possibility. But, hmmmm…. Dunno. I’m just going to have to think about it some more.
(“Top minds are working on it“? Does that mean I also get to take a look at the Ark of the Covenant too?)
JayBaz points out something that is worth keeping in mind about events: they can be subject to race conditions in multi-threaded scenarios. In VS 2002 and VS 2003, you’ll need to do what the C# folks do and handle the race condition yourself:
Event Moved(ByVal x As Integer, ByVal y As Integer)
Sub Move(ByVal x As Integer, ByVal y As Integer)
Dim temp As MovedEventHandler = Me.MovedEvent
If Not temp Is Nothing Then
temp(x, y)
End If
End Sub
(The names “xEventHandler” and “xEvent” are automagically generated names – the first is the delegate type of the event and the second is the hidden field generated to hold the event delegate.)
In Whidbey, however, we’ve changed the code generation for RaiseEvent so that this will be done automatically for you. We work hard so you don’t have to!
When I last left off with background compilation, we were talking about how compilation and decompilation worked within a project. But what about between projects? This is where things start to get a little more interesting and problematic.
The simplest case is two VB projects that have a reference between them. Because they’re both source code projects, we can handle compilation and decompilation by using the same scheme that we use inside of projects – in essence, all the VB projects in a solution look like one big project that happens to produce multiple assemblies. (This is why Mike has his problem with the compiler complaining about two types with the same name in two projects that don’t reference each other, although we’re planning to fix that particular error for Whidbey.) So we just track dependencies between files regardless of which project they are in and everything works fine. There are a few added complications because now we need to track a project’s compilation level, but they aren’t really worth mentioning.
Now let’s talk about referenced assemblies such as mscorlib, System, System.Windows.Forms, etc. When you reference a compiled assembly, we have to build a symbol table for it just like we have to for a source project. The way we handle this is to treat each assembly as it’s own “metadata project” with a single file in it (i.e. the assembly). Metadata projects go through the same compilation steps as source projects: NoState, Declared, Bound and Compiled. However, the compilation process for a metadata assembly can be much simplified, for the following reasons:
Since the Compiled state makes no sense for metadata assemblies, we ignore it. And since metadata assemblies don’t really ever change (or change very infrequently) and only depend on other metadata assemblies, we can skip much of the decompilation work that I described in the first part of this discussion. In fact, we can make it very simple: when any metadata project changes, we just decompile every metadata project in the solution to NoState and decompile every source project down to Declared. Essentially, we throw away all metadata information and start over. Since metadata projects don’t really change often, usually only when you add or remove a reference, this is a reasonable simplification.
Right? Wrong.
Unfortunately, much of the logic of the previous few paragraphs is faulty because it neglects something fairly significant: multi-language solutions. Let’s say that you have a solution with a VB project and a C# project, and the VB project references the C# project. How does that C# project look to the VB project? It’s not a source project because the VB compiler only understands VB code. Yes, that’s right, class, it looks like a metadata project. And C# projects completely violate 2 of the 3 bullet points I listed above: they can change frequently (i.e. with every rebuild) and they can have references into VB source projects.
Here’s where the train wreck happens. Let’s say you’ve got three projects: VB1, VB2 and CS1. VB1 has a reference to VB2 and CS1. CS1 has a reference to VB2. When we go to load in the metadata for CS1, the compiler finds a reference to type Foo in VB2. But because we assume that metadata projects can’t refer to source projects, we only look for Foo in the other metadata projects and fail to find it. So we mark Foo as a bad type. Now VB1 tries to call some method in CS1 that returns a Foo. As we compile the call, we notice that the type Foo is bad, so we generate an error that says something along the lines of “We can’t find ‘Foo’ in ‘VB2’. Add a reference to ‘VB2.'” And, of course, the user ends up scratching his head because VB1 already has a reference to VB2. (Even better, it’s possible to get error messages along the lines of “Can’t convert type ‘Foo’ to type ‘Foo’.” if you try and use a Foo you got from CS1 and a Foo you got from VB2 together.)
OK, you say, that’s bad. But why don’t you just allow CS1 to lookup Foo in VB2’s symbol table? Then this would all work. And it would. Until the first time you actually edited VB2 and caused the project to decompile. If you’ll remember, we assumed that metadata projects don’t need to participate in decompilation. So now VB2 decompiles and CS1’s symbol table is left with a bogus pointer off into hyperspace because it didn’t know how to handle the decompilation properly. (We could just decompile the world at this point, but the performance of that would be horrendous.)
The real fix is to make metadata projects work like source projects – make them track intra-file dependencies and decompile properly. The problem is that this fix requires a fundamental reworking of our project system, which is a major, major undertaking because we made so many faulty assumptions about metadata projects. Rewriting a basic piece of the compiler like this requires an extended period of time for stabilization and a massive amount of testing to ensure we got everything right. Since we found this very late in the VS 2002 cycle, it was too late to make a change of this magnitude without causing a significant slip to the entire VS/.NET/ASP.NET product agglomeration. And the VS 2003 cycle was way too short to do this kind of work. This will be fixed, I can promise everyone, for VS 2005.
All that said, I think it’s worth acknowledging that this was a screwup on our part, plain and simple. There are reasons why multi-language solution testing came online so late, but none of the really justify the pain and annoyance that this has caused (and still causes) for customers. It doesn’t really make it better, but we really apologize for not fixing this problem in time. As always, we strive to do better.
I will add that there is a workaround for the problem. If you create a reference between VB projects using a file reference (i.e. using the “.NET” tab and browsing to the actual DLL) instead of a project reference (i.e. using the “Projects” tab), then you’ll force the compiler to see all the references as metadata projects and you won’t get weird errors. The downside is that you’ll have duplicate symbol tables for VB projects that you reference that are also in your solution. It’s an imperfect solution, but it’s all there is for the moment.
So ends the lesson on background compilation… All of this material will be on the test.