This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: Language Design & Paying the UI "Tax"
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
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…
Previous Topic
