Monthly Archives: January 2006

Language Design & Paying the UI “Tax”

As Raymond says, most development teams face some kind of “tax” in their day-to-day work. Taxes are things that a programmer has to do or take into consideration that are usually: a) not specifically assigned for him to do, b) not specifically accounted for in his schedule, and c) not specifically very much fun. The first example Raymond used was power management — something that pretty much every Windows application should take into account but which a very great many applications don’t.

One of the wonderful things about working on a compiler is that, by and large, you escape most of the more egregious taxes. You don’t have any UI, you are pretty task-focused, you don’t deal with many other components in the system, and everyone expects you to consume a lot of resources (although not so many that the machine is brought to its knees). So lots and lots of things that other programmers have to worry about, we don’t. It’s great!

Wait, though, did I say that we didn’t have any UI? Well, technically, that’s true — the core compiler group takes text in and outputs bits on disk. But while the compiler doesn’t really have a UI itself, we don’t get off the hook completely because there’s lots and lots of UI that gets built around the compiler to help people, you know, write programs and stuff. And the language and compiler design cannot be entirely ignorant of that fact, nor can it bear no responsibility for how easy or hard it is to write that UI.

We’re at the point now with LINQ where we’re really starting to take a serious look beyond the language features, cool as they are, and pondering how these features are going to integrate with the UI. (It’s not like we haven’t thought about it at all, we have, but now we’re really taking a look at things end-to-end.) And so we started by coming up with a “language UI taxes” list that I’m shocked we haven’t put into a more concrete form until now. The various taxes that a language feature is going to have to pay include, but are not limited to:

  • The code model
  • Edit and Continue
  • Stepping in the debugger
  • Expression evaluation in the debugger (for things like the watch window, immediate window, etc.)
  • CodeDOM
  • Intellisense
  • Object Browser/Goto Definition
  • Class View
  • Code spit (i.e. things like automatically pasted in overrides and event handlers)
  • Tooltips
  • Rename symbol
  • Error correction
  • The dropdowns at the top of the editor window
  • The attribute editor
  • Dynamic help
  • Pretty listing
  • Code colorization
  • Editor outlining
  • Refactoring
  • Snippets
  • XML Documentation
  • Class Designer

In many ways, the real cost of a language feature isn’t in the feature itself, it’s in the myriad of UI taxes that must be paid on any particular feature. Optimal tax planning is the secret to a good schedule these days…

Billy Hollis, amateur PL historian…

This has been bouncing around a bit on blogs, but I thought it was funny… Billy Hollis, a longtime VBer, has posted some of his historical ruminations on VB and C-style languages:

If you like VB, look at the history of the C family [of languages] first. If you like C#, Java or C++, look at the history of the BASIC family first.

But who’s got the Star Trek game? I loved that game…

More samples coming soon (I hope)…

Just a FYI, I’ve changed the title of the “VBParser” category to “Samples,” in preparation for what I hope are several new samples in the coming months. The main thing I’ve been working on so far is an update of the VBParser sample that I wrote for VB 7.1. Besides updating the parser to parse VB 8.0 language features, I’ve also changed it to use nifty CLR 2.0 features like generics. My hope is to have it out in the next few weeks. Unlike last time, I don’t think I’m going to use GotDotNet as a distribution medium — since no one added anything to the project, I’m just going to distribute it directly and let people mail me bugs and such if they wish. Beyond the parser, I’m thinking about some samples that might fit in with LINQ, but we’ll just have to see…

New verb? To “go steveb” on someone.

I’ve been thinking about coining a new verb:

go steveb tr.v. To suddenly escalate an issue to the CEO/President/Senior VP of a company out of frustration when dealing with a low-level employee of a company. (steveb is the email address of Microsoft CEO Steve Ballmer.) As in, “Yeah, we were talking about the fact that we cut that new feature the customer wanted and I said there wasn’t anything I could do about it, so he went all steveb on me and emailed my VP.”

To go steveb is really kind of the Hail Mary pass of the corporate world: you’ve exhausted what you see as all reasonable options of dealing with the lower-level people in the corporation, so you’re giving up and hoping that by complaining to the top people that they’ll do something about your problem, even if just to shut you up. A bit of a desperation move because, of course, this will not particularly endear you to the people who you were previously dealing with (and who will likely be told to work on any response that you end up getting). Doesn’t work most of the time since high-level people are, by nature, practiced in the art of the polite kiss-off, but always worth a try.

I’ve certainly done this at times — when I had a disastrous experience traveling internationally with Expedia in the mid-90’s, I had to go steveb on them to get back the money we wasted on hours of transatlantic calls. Of course in that case I benefited from the fact that Expedia was part of Microsoft at the time… Now that I’ve reached a certain level of public note, I get to be on the other side of things, when people think “Enough of this flunky, I’m going to go straight to the top!” Since I’m always in pretty good alignment with my organization this has never been much of an issue for me to deal with, and on rare occasions its even got stuff moving that I was personally in favor of (but lacked the internal clout to move on my own).

Anyway, the verb is so MS specific that I doubt anyone will ever use it except me, I thought I’d share…

I Heart Beagle Brothers

Jeff Atwood’s little entry on cheatsheets sure brought back some memories… I loved Beagle Brothers. As a general measure of comparison, I think Beagle Brothers had more cool in one little tip/trick box than Google has ever had with their cute variations on the Google logo. Definitely one of the things I look back on with fondness…

I’ve also thought about trying to create a VB.NET language cheat sheet one of these days, but it’s on that list of “things to do when I have time.” Yeah, right…