Author Archives: paulvick

Game on

I’m back, and even with a slight tan… (Thanks, SPF30. Normally, I turn red like a beet.) Things are going to be busy for me for the next few weeks, so the relative silence will probably continue. I’d like to say it’s because I’m working hard on some cool PDC talk, but I’m not – I’m coming up against a very hard deadline for my language reference book, and I’ve got to really cram to get it done. Hopefully I’m going to turn in the final manuscript and then head off to sunny LA to relax at the PDC…

Less blogging, more sun!

Just an FYI for those of you who hang breathlessly on my every word and structure your lives around my blog: I’m going to be out of touch next week while attending the wedding of a friend in Maui. Yeah, it’s going to be tough, but somebody’s got to show up for it… I expect (hope?) to be completely out of touch for that time, so everyone’s just going to have to take care of themselves while I’m gone.

(Sadly, though, some work will follow me – I’ve got some major deadlines coming up on the language reference book, so that’s coming along with me.)

Miss Congeniality

Brad Merrill asked for a more “chatty” bio for the panel discussion page than the one I submitted for the speaker bio section. He also asked for us to talk about any “big questions” we might think about. See if you can find the most important one in there…

All programming involves making tradeoffs and compromises, but language design reduces the problem to its most stark terms. Stripped of the fancy graphics of a GUI or the richness of an object model, programming languages are the alligators of the computing world: very much alive, yet in many ways unchanged over millennia as the environment around them underwent radical transformation. How do you evolve something so perfectly suited to its task, yet so limited in its ability to absorb mutation?
Sweeping metaphors aside, programming languages continue to bump up against the limitations of their medium, namely plain text. Is it possible to look at code in ways other than text that might help programmers be more productive and make programming easier to learn? And what about the Tower of Babel-like profusion of domain-specific languages over the years such as SQL, XML, etc.? Is there a way to find commonalities between differing language domains in a way that enables people to write code that spans them using only a single language? (Without, of course, having that single language become Esperanto?) And, most importantly, will VB ever get any respect? These are the questions I ponder late at night…
I joined Microsoft in the antediluvian past, namely 1992. Back then, Windows 3.1 was the hot new operating system taking the world by storm, a little project named Visual Basic had just shipped, and I started on an upstart database product named Microsoft Access. I ended up working on Access for nearly four and a half years, and after Access 97 shipped I took a job working on OLE Automation, thinking it was the future of component automation. What did I know! Fortunately, after shipping Visual Basic 6.0 I moved over to work on the Visual Basic compiler proper just as the team started working on moving it to some new runtime that Microsoft had decided to build. Four years later, we shipped Visual Basic .NET 2002. Along the way, I moved from being a developer working on code generation to managing the compiler team and working on the design team for the language. Now I’m working full-time on design issues, as well as continuing to write the Visual Basic .NET Language Specification and working on a Visual Basic .NET language reference book. You can find my weblog at http://www.panopticoncentral.net.

Should be an interesting discussion.

“…and my platform is world peace.”

Like Chris, I don’t particularly like writing a bio. However, I’m going to be sort-of speaking at the PDC, so here’s mine: (I figure I should get some mileage out of it since I had to go through the trouble of writing it.)

Paul Vick is a Technical Lead on Visual Basic .NET, where he has been a part of the VB language design team since 1998. Paul originally began his career working at Microsoft in 1992 on the Microsoft Access team. After shipping versions 1.0 through 97 of Access, he moved to the VB compiler team in 1998. He participated in the design and implementation of the Visual Basic .NET language, driving many of the language changes for .NET. He is the owner and author of the Visual Basic .NET Language Specification and his weblog can be found at http://www.panopticoncentral.net.

I say I’m going to be “sort-of” speaking because I’m not going to be giving a talk on VB, but I will be on the languages panel later in the week. Since there’s only one VB language talk being given, there was a little mini-contest between me and the PMs as to who was going to give the talk. Amanda and Steven won. Suckers…

From our mouths to your ears in Internet time

It’ll be a little while before the official transcript of the chat yesterday is posted up, but Tom already has a pretty accurate list of the highlights. One interesting aside he made was:

BTW: In case you couldn’t imagine this yourself: I like VB.NET and hope we won’t see any “last minute changes” like we saw with the first release of Visual Basic .NET. I was really happy with some features that were introduced in the first beta of Visual Basic .NET (like short circuit evaluation) that I was a little disappointed when I read/experienced they were removed or were moved to different keywords (OrElse and AndAlso in case of short circuit evaluation). But such things can happen when you start working with beta software…

As far as beta releases go, we explicitly try not to make radical changes between beta releases. By the time we reach beta, things should be relatively stable so that people can reasonably see how the product will work in a real production environment. While we can make design changes between beta and sometimes add or remove things based on feedback or further experience with the feature in the wild, the VS 2002 beta cycle was extraordinary in a lot of ways. Users should expect that, from a language perspective at least, the beta releases should be pretty stable. Although I reserve the right to eat those words, should the need arise…

I’ll add, though, that all bets are off when it comes to alpha releases such as the one that we’re going to be releasing at the PDC. Since what you’re getting, again from a language perspective, is not even what we consider a finished product, things may change substantially between alpha and beta. Mostly it will be new stuff that’s been coming online after we dropped the alpha, but there is some stuff that we’ll likely be fiddling with. So caveat emptor on that.

Mysticism and the PDC

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…

Grading on the curve

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…