Just a reminder: there’ll be an MSDN chat with the VB language team tomorrow. Be there!
I’ve followed with interest some of the discussions touched off by Ole’s entry on “Oh, not Oooh” and his follow-up piece. On the whole, I would have to agree with his overall thesis regarding the run-up to the PDC: even though I work for Microsoft and think the PDC is going to be awesome, I’ve found the quasi-mystical aura that many people (who I won’t mention by name) are trying to impart to the conference somewhat confounding at times.
My biggest issue with the mysticism is that it engenders this whole “complexity vs. simplicity” debate that’s swirled around Ole’s entries, and which I think is a red herring. The question is not how complex a technology is or how simple it is, the question is how organic it is. Case in point: in many of these discussions, the transition from VB6 to VB.NET is held up as a canonical example of moving from less complexity to more. But the truth is that from a complexity standpoint VB6 was probably a more complex product than VB.NET is. What’s different, though, is how the two products surfaced their complexity to the user. VB6 did an excellent job of tucking away the things that most people didn’t need in their day to day work – maybe a little too well at times. And it did an excellent job of sticking features right where you expected them to be. (A big feature for Whidbey is going to be returning Edit and Continue to the product, but the reality is that before VS 2002 most people probably weren’t even aware that Edit and Continue was a feature at all. They just did what they wanted to do and it worked. No thought required.)
In many ways, though, VB.NET is much simpler in terms of design and implementation than VB6 was. The problem (such as there is) is that complexity in VB.NET has been surfaced in ways that still do not feel entirely natural. Indeed, a lot of the work that our team has before us in Whidbey and beyond is not removing complexity but trying to create a more natural way of working with the product. This is what I mean when I say that technology should be “organic.” Well designed products don’t surface every bell and whistle to the user, they follow a principle of Everything in its Place. Using technology should be all about a natural unfolding of the capabilities of the technology as you need them, not shoving all this cool stuff in your face at once. And despite all the hoo-hah about complexity, I think that the .NET platform has actually gotten a pretty good start on this even if there are some rough edges that need to be worked on.
Ultimately, I think that this is really what the PDC is going to be about: letting people know about how we’re going to make your life easier and more natural, not how we’re going to “change Windows as you know it.” If we do our job right, developers moving to Avalon and Longhorn and Yukon and Whidbey and so on should feel like they’re meeting an old friend who they haven’t seen for a long time. Sure, there’s going to be a lot of catching up to do, but you should also immediately feel that familiar rapport, that feeling like you’ve known them all your life.
Whether we achieve that remains to be seen, and I think that’s worth showing up to the PDC for…
Chris’s posted some continuing thoughts on the question of whether its a good idea to grade people on a curve when doing performance reviews (or any other place where grading occurs, I guess). Like Chris, I also believe pretty strongly in grading on the curve but I still have lots of reservations about it. That’s because a curve can so easily be misused in a way that is damaging to employees, the company, or both. But the alternative, inevitable grade inflation, seems to be worse.
(Grade inflation is something I got enough exposure to in college, thank you very much. Which is not to say that I wasn’t hypocritically disappointed that my university started giving out graduation honors on a curve starting with my class. It turned out something like over 50% of the class was graduating “cum laude“ or better. It is numerically impossible that every student at a university is above average.)
Ultimately, it reminds me of the famous Churchill quote: “Democracy is a very bad form of government. Unfortunately, all the others are so much worse.” Same for the curve, same for the curve…
Recently, we threw a big party with some friends at our house. The theme was “Back To School” and we encouraged people to dress up along a school theme. I got inspired.
I’ve made some minor modifications to my blog software again. Hopefully, nobody will notice, but if something stops working, please let me know…
After introducing it with much fanfare, I’ve been very negligent in actually answering anything submitted to Ask a Language Designer. So let me start to make amends. The first questions I want to address were narrowly asked but touch on a broader question. Both Muhammad Zahalqa and Kevin Westhead ask why VB doesn’t have a ‘using’ statement like C# has and when/if we will have one in the future.
The general question of "Why doesn’t VB have feature x?" is, as you can imagine, one that keeps coming up over time. It’s gotten even more common since C# came on to the scene, since VB and C# are much closer to each other than, say, VB and C++ are. So I thought I’d spend a little time talking in general about why some features that exist in other languages don’t make it into a particular release of VB. And, in the process, I’ll address the question of the ‘using’ statement.
When a feature doesn’t make it into VB, it’s typically because of one of the following reasons:
- It’s a bad feature. I’m throwing this in here because it does happen every once in a while that we get a request for a feature that some other language has that we think is just a bad idea. There isn’t anything that I can think of off the top of my head that’s fallen into this category, but it does happen.
- It’s not a good match for VB. There are some features that we think just don’t make sense for our customers and the kinds of things that they do. It’s not that we think that nobody would ever use the feature, just that it’s very unlikely that most of our users would need or use the feature. The prime example of this is the unsafe code feature in C#. Although there are situations in which people use unsafe code, they tend to be pretty limited and very advanced. In general, we believe that even very advanced programmers can happily exist in the .NET environment without ever needing unsafe code and that it tends to mainly be programmers coming to C# from C and C++ that find the feature useful. (Our experience since shipping VS 2002 and VS 2003 has so far validated these beliefs.)
- It’s not a good cost/benefit tradeoff. Some features are good ideas, but the benefit gained by having the feature doesn’t seem to justify the time it would take to design, specify, implement, test, document and ship the feature when compared against other features we want to do. To pick a prosaic example, the C# command-line compiler csc.exe has a feature where it will read in a "default" response file that contains references to all of the .NET Framework DLLs. This means you don’t have to explicitly "/r" DLLs like System.Windows.Forms.DLL when compiling an application on the command line. It’s a nice idea and handy on the command line, but in the past the overhead of implementing the feature in vbc.exe was judged to be higher than its benefits. So it didn’t make it into the product for VS 2002 or VS 2003. The danger, of course, is that little features like this can end up being constantly cut from release after release because they’re not big enough to be "must have" features, but not small enough to escape the ax. (You’ll just have to give it a try in Whidbey to see whether it made it in this time or not…)
- We ran out of time. This has got to be the most painful situation for the product team, because it’s something we desperately wanted to get done but for one reason or another, we just didn’t have time. So instead we have to sit back and suffer the slings and arrows of outrageous fortune for not having the feature, contenting ourselves only with the knowledge that next time will be different. A prime example of this is operator overloading. We really wanted it for VS 2002/2003 but it was too big to fit into the schedule. We’ll definitely be doing it in Whidbey.
So what about the ‘using’ statement? One of the major struggles of the VS 2002 product cycle was trying to figure out how to deal with the transition from reference counting (i.e. the COM model) to garbage collection (i.e. the .NET model). We spent a lot of time trying to see if we could make reference counting coexist with garbage collection in a way that: a) was reasonable and b) was comprehensible by someone less than a rocket scientist. While we were doing this, we deferred making any decisions on garbage collection related features like the ‘using’ statement. After banging our heads against the proverbial wall for what seemed like forever, we came to the very difficult conclusion that we couldn’t reconcile the two and that full-on garbage collection was the way to go. The problem was, we didn’t reach this dead end until late in the product cycle, which meant that there wasn’t enough to time left to properly deal with a feature like ‘using’. Which, let me just say, really, really, really sucked. So the painful decision was made to ship without the feature and, yes, we said to ourselves next time will be different.
Is this time different? This is another one of those things that you’ll have to try out in Whidbey to see… (wink, wink)
A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. People who are serious about getting the job done on time and under budget will use tools such as Visual Basic (controlled all the machines that decoded the human genome). But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity.
VB controlled all the machines that decoded the human genome? I’d never heard that, but there’s at least some evidence on the web that it’s true. (Really, it’s one of those things that’s just "too good to check.") Does that mean we can take downstream credit for all the things we learn from the human genome? "Visual Basic Finds Cure For Cancer?" I guess we’ll just have to wait and see…