Monthly Archives: July 2003

There are two kinds of people in this world…

…those who think Edit and Continue is a good idea and those who don’t. I still haven’t gotten to answering Franz‘s original question, but a recent entry he made does start to address the question.

I totally understand what he’s saying when he talks about the fact that Edit and Continue allows for some very bad programming habits. I spent a few summers teaching teenagers to program, and I got to see first hand some of the ways that bad habits can derail programmers, especially new programmers. From a theoretical standpoint, it is infinitely preferable for programmers to follow the well-worn steps to programming nirvana: understand the problem, design the program structure, implement the program, test the program, fix the bugs, ship the program. In that order.

And yet… The reality is that life is messy and does not always conform to theoretical norms. I am a skilled programmer who works on a major product produced by a large corporation. But even I have lots of times where the code that I write only needs to be “good enough” and not brilliant. I’m not talking about the VB compiler here – obviously, that has to be brilliant – but about all the side projects and throwaway tools and prototypes and test cases that I work on in my day to day life. It doesn’t matter that they’re well designed, only that they work.

And that’s what makes Edit and Continue so wonderful. When I need to bang something out rapidly, I can design the application on the fly. I outline the application, hit F5 and I’m off, writing the code as I go along. If I made a mistake, no problem, I can fix that on the fly without having to restart the entire application. If I’m working on something that really needs to be polished up later, that’s cool – I can do that later. But for now, I’m getting my work done and I’m doing it without all the theoretical design overhead that I really don’t need at that moment. And there are a lot of people in this world who just need to get their work done like this and don’t need to produce well-designed, meticulously thought-out applications. That’s why Edit and Continue is such a big feature for them.

(I’ll also add that I suspect that many, but certainly not all, developers who do not want Edit and Continue haven’t really tried it. Even for people who think fully through their design and eschew debugging on the fly, there is always those times when you hit an exception 10 minutes into running your application and you realize that you just forgot to initialize some stupid variable. If only you could just fix that one damn line and not have to re-run the application again for 10 minutes… If only…)

Anyway, like I said, I’ll freely admit that EnC can enable people to slide by with some pretty bad habits. But if people find it useful, why not do the feature and allow people to decide for themselves whether they’re going to have bad habits? The purpose of a tool is not to make people use it in the “correct” way, the purpose of a tool is to assist people in getting something done. That means that just because someone might misuse a feature does not, in and of itself, mean that you shouldn’t do it. This is really a core philosophy of VB: whatever it takes to give you the shortest path between your idea and a completed application. That’s RAD.

Whidbey and Orcas roadmap

Thanks to Scott and Sean for pointing out that MSDN has published a high-level roadmap for Whidbey and Orcas. I’m planning at some point in the near to talk a little more about some of the details of Whidbey features, especially generics. Not because I have an urge to blab secrets but because I think there’s value in letting people know where things are headed, and even get a chance to get some feedback.

Wifi and meetings

There’s been a lot of buzzing around on the web about the whole question of using Wifi and IM to have backchannel discussions during lectures and presentations (especially after the New York Times wrote an article about it), but I see Wifi more day to day in meetings and it drives me nuts. Because the reality is that most of the time it’s not people having backchannel discussions in meetings, it’s just people tuning out of the meeting and reading email/surfing the web. Which raises the question: if you came to the meeting to just surf and read email, why did you come at all?

I don’t know whether we’re at the leading edge here or not here at Microsoft. We’ve had Wifi for long enough now that most people who can obtain a laptop do so so they can bring it to meetings and be connected. Indeed, I got one two years ago for exactly that reason, and then traded it in a year or so ago for a TabletPC so I could be even more inconspicuous when reading email during a meeting (i.e. so I could put it in my lap rather than sticking it on the table). However, what I eventually came to was exactly what I was saying above: if I’m going to this meeting so I can sit here and read email, why am I bothering to be here in the first place? Ultimately, I think it’s either rude to the rest of the meeting attendants or a waste of my time or both, take your pick. But the phenomenon is now that each meeting literally consists of two groups of people: those who came to go to the meeting and those who came to surf and read for an hour. (Maybe people purposefully go to meetings they have nothing to say in so they can read email in peace, whereas in their offices people would bug them…)

There’s really nothing to be done about it, anymore than there is anything to be done about people having loud personal conversations on cell phones in public spaces. There might be some side benefit for meeting organizers, too. At any meeting you set up, look around and see who’s checked out and make a mental note of it. Those are the people you don’t need to bother to invite to future meetings.

(And, as a side note, I’ve stopped taking my tablet to meetings to make it harder for me to check out. Which is not to say that my mind still doesn’t wander…)

MustOverride and line orientation

One of the side projects that I’m working on in addition to this weblog is a managed scanner and parser for the Visual Basic .NET language. I started on the project because I’d really like to write some project analysis tools that I could use to determine things about how people use the language, but as it’s gone on I’m hoping to also release it into the community as a sample. (One of the wrinkles is that I’m “writing” the managed parser by looking at the existing unmanaged parser, so it’s not like the code I’m writing is completely of my own invention, although it is largely so.) I think that the more that people can work with a language in an automated way, and the more tools people can write for a language, the better it is for people who use that language. Anyway, we’ll just have to see. I still have to finish it first…

After I finished the scanner (scanners are easy), I started parsing expressions and have been working my way up the parse tree hierarchy. I’ve recently reached type members and, in particular, methods. An interesting thing is the way that VB’s line orientation interacts with MustOverride methods when parsing. In C#, parsing methods is pretty simple because after a method header you can see either a semicolon or an open curly brace. If it’s the former, then you’ve got an abstract method declaration; if it’s the latter, then you’ve got a concrete method declaration. Whether or not you specified “abstract” as a modifier on the declaration is really something for declaration semantics to sort out later on. In VB, though, the following fragment is ambiguous if you don’t look at the modifiers:

<modifiers> Sub Foo()
Dim Bar As Integer

In other words, once you’ve gotten through the method header, the next line starts with “Dim,” which could either mean that Foo was a MustOverride method and Bar is a field, or that Foo was a concrete method and Bar is a local. To figure out which is which, you absolutely have to look at the modifiers to see if “MustOverride” is there. This is the kind of thing that drives formal grammar writers nuts because it means you have to hork up your grammar productions to make it all come out right. It doesn’t make such a big deal, though, if you hand-code your parser, which is what we do for VB. (Hand-coded parsers vs table-driven parsers seems to be one of those religious arguments that language people get into. Let me just say I don’t take a formal position on the question.)

Interestingly, there are at least a few other places in the language (esp. in terms of object creation expressions versus array creation expressions) where things get complicated like this. But overall, it’s been pretty smooth sailing. I’ll let everyone know as the project progresses.

Yup, I did know that

Duncan points out a little something extra that VB.NET’s Try…Catch syntax supports. It’s something the underlying IL supports and it seems useful, so we figured, why not? A use that comes to mind is when dealing with COMExceptions:

Try
' Do some COM interop
Catch ex As COMException When ex.ErrorCode = &H80043919
' Handle this specific error
End Try

Nothing fancy, just a little something extra. An interesting thing to note is that the CLR doesn’t actually support specifying both a type filter (i.e. ex As COMException) and a filter expression (i.e. Where ex.ErrorCode = &H800043919), so the above Catch clause is a filter expression that checks both the type and the value together. It doesn’t use a type filter. I was never really clear why the CLR did it that way, but it’s not a big deal either way.

Best laid plans…

Before going to bed, I thought I’d check the logs really quickly to see if anything looked amiss, and, sure enough, I’d screwed something up moving to the new software. I’d been testing the new software at a different URL and forgot to tweak one of the settings when I moved it up to the root. As a result, the links for all the RSS items was messed up, which caused automated aggregators to start trying to fetch from the wrong location. It should be fixed now, I hope this hasn’t screwed anything up permanently.

New software

OK, as I previously threatened, Panopticon Central is now running on custom software adapted from the original BlogX codebase. I ended up rewriting a lot of the data caching behavior as well as adding a number of new features and making a few cosmetic changes. I hope everything will continue to work. Please leave comments if there are problems or things I screwed up.

The major changes that readers will notice:

  • The RSS feed has moved locations. The old location returns a permanent redirection and it seemed to work with SharpReader, so I hope it does with everyone else…
  • I added a comments RSS feed. Now you can thread comments using your aggregator, if you so wish.
  • The RSS feeds now return ETag and Last-Modified headers. I’m serious hoping this is going to cut down on the bandwidth.

Most everything else was internal. The major thing still on the “to do” list for external readers is Trackback support (and all related flavors of APIs). And I’m sure I’ll continue to fiddle with the internals. It’s a lot of fun.