Wesner responded to my previous comment and pointed to an article describing SCID, Source Code As Database concept. I've also taken a look at the old Lutz Roeder presentation (MS PowerPoint) where he is toying with similar ideas. In the end, I think we are agreeing more than we are disagreeing. That is to say, that having the IDE become intimately aware of the code that is being created within it is a great thing. However, and this is a biggie for me and I think is the point where Wesner and I part ways: I want the IDE to use this intelligence to help me and make me more productive at writing code. I don't, however, want the IDE to constrain me.
Squiggly lines, dynamic icons and other decorative graphic elements that give me information about the code I am writing are great. Tools for visualizing the code post-factum (like Reflector) are also great. So is IntelliSense and code formatting intelligence. There may even be cases where interrupting text flow with graphical elements (like a Color picker) may be acceptable, though I am not sure about that one. BUT! There is a very fine line that must not be crossed here and it is far better to err on the side of not doing as much than doing too much. For example, the May 2004 build of VS Whidbey gives the developer a pretty rich way to describe code formatting preferences. Great, except, here's an example of the IDE going too far: if when declaring a variable, I separate the type from the name with tabs because I want to align successive declarations, the IDE reformats the code and replaces the tabs with a single space. To me, this is annoying as all hell. (whether this is intentional behavior or an alpha bug, its a perfect example to illustrate my point)
Wesner thinks this stuff is irrelevant and code formatting is a waste of time to begin with. I disagree. I think that's much like saying that Esperanto is a plenty expressive language, so why not just have everyone convert to it. In practice, familiar code formatting is key to readability of code; and that would not change in a SCID-like world either. Different people are used to different formatting styles, and those styles affect their ability to read and write code productively. But this is, of course, going off on a tangent...
I do understand where Wesner wants to take us though. It does feel like coding in simple text is just so 1980. Surely, today we could do better. But I think the limiting factor is not the display representation of code but rather the input method. Keyboard + Mouse can only take us so far and anything that forces one to jump frequently from one to another is only going to adversely impact productivity. We need to make the next big jump in HCI, but realistically, I dont think it will happen for quite some time yet, probably not this decade.
posted @ Thursday, June 24, 2004 7:00 PM