Michael Teper

I started looking closer at the upcoming provider model in ASP.NET 2.0 and found some troubling patterns in current incarnation of the API (as of the May 2004 CTP). One example is MembershipProvider.ChangePassword method with the following signature:

public abstract bool ChangePassword(
 string name,
 string oldPassword,
 string newPassword
);

Can anyone spot a problem? I'll give you a hint, look at the return type. Now, without looking at the docs, can you tell me without a shadow of a doubt what that boolean value indicates? I didn't think so.

In this case, the API follows the old C convention of returning a boolean value to indicate whether the operation succeeded. This convention always felt incomplete to me, and it truly has no place in the world that has structured exception handling, and ESPECIALLY, for a method that should not, under normal circumstances, be a performance bottleneck.

In my opinion, the return type should be void and one should be able to safely assume that under normal conditions the operation will always succeed. Any failure to do so is an exception, and should be handled through the exception mechanism.

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.

Wesner Moise wrote a post predicting that code editing capabilities in VS.NET 2005 will be behind the competition by the time it ships. I agree with the premise but disagree with the analysis. Wesner asserts that the advent of macro-less, easily parsable languages like C#, VS.NET, and Java opens the door for IDE's to work with parse trees. He correctly points out the benefits of this that will come through IDE intelligence about code (rather than just text). But then he goes off the deep end predicting that developers will work with a graphical representation of this parse tree directly. I just don't see that happening. Ultimately, IDE's are all about productivity, and (though is has been tried many times before), no RAD tool yet has offered a compelling replacement for laying out arbitrary code logic better than terse text syntax. RAD is great for laying out UI, its great for devising schemas, its great for visual analysis and 50,000 ft views, but its just not productive for the actual development of program logic.

What I do see happening is that desktop memory and processing power has finally enabled the IDE to maintain and work with code parse trees even for sizeable projects. I think this is the key reason we are finally seeing companies like JetBrains, Microsoft, IBM, and others start to put true code intelligence into their editors. The reason I feel Microsoft is going to end up behind the ball with Whidbey (err, VS.NET 2005) is that it was late to the party to begin with and hasn't done enough to jump ahead. The refactoring support in Whidbey (at least that has been shown to public to date) is at the level the competition was at years ago. Today, I see JetBrains putting more and more small but very powerful improvements into enhancing the actual process of writing code (think IntelliSence on steroids, it really streamlines “dull” typing); while others, like DevExpress with CodeRush take a more visual approach. In both cases, it is still all about the code expressed in a programming language and layed out by hand in a text file.