Whidbey May Miss the Next Coding Revolution
The Visual Studio.NET source code editing capabilities have consistently lagged the competition, mainly in the Java space. While Whidbey introduces some much needed enhancements to the C# (and VB) IDE such as refactoring and dynamic code formatting to catch, I predict that Whidbey will find itself once again behind the ball.
The truth is much of the new changes in Whidbey will be wasted effort, because I see a revolution brewing within the next three years in the way source code is written.
Text editors are going to go away (for source code, that is)! Don't get me wrong, source code will still be in text files. However, future code editors will parse the code directly from the text file and will be display in a concise, graphical and nicely presented view with each element in the view representing a parse tree node. (NOTE: I now the word graphical is misleading, so I explain it more in this newer post.)
Religious beliefs about key bindings will disappear, because most of those key combinations will become completely irrelevant in the new world. Yes, Don Box will finally kiss his Emacs goodbye. The new paradigm actually eliminates syntax errors (at least, they will be flagged immediately by the new graphical editor) and many semantic errors, because each edit operation directly alters, adds or deletes a node in the in-memory parse tree.
It also has good potential to eliminate hundreds of lines of coding by collapsing. Such an editor could introduce new keywords or nodes, that could map to hundreds of lines of textual code at save time, without requiring an improvements to the compiler or language. For example, the editor could be enhanced to support delegation, whereby a class inherits all the public methods and properties from a member variable. It could support default parameters in C#, which maps to multiple methods, when written out to a text file; the editor could recognize this pattern when reading back from a file. Backing store properties can be entered and displayed concisely. A lot of crud can simply disappear, with the editor automatically importing the appropriate namespaces when a class is reference or omitting the class name from an enum constant.
There are countless other benefits such as the ability to present multiple radically different views of code, all simultaneously synchronized; even within a view, code can be pivot, sorted, and filtered in different ways.
From a development standpoint, it is far easier to write an intelligent editor from a parse tree then from a sequences of lines of text, which is why it will happen. Hence, the effort put into dynamic code formatting, which may be thrown away, would probably have been better placed in edit-and-continue support. On the other hand, edit and continue may actually be easier to implement in the new model, because the parsing step is eliminated when the user edits code. In addition, implementing refactoring would have been significantly easier because code is stored in memory using a natural object tree representation rather than as streams of text. Changing the name of a function directly could instantly change all references elsewhere without the need to go through a dialog, because each reference in the view is not stored as text but as a direct link to the function object. The effort that Microsoft put into robust real-time parsing for Intellisense is completely wasted.
Part of my current entrepreneurial work is rethinking today's existing application and revitalizing them with artificial intelligence. One of these applications is text editing. I have been thinking about this upcoming revolution for some time, but just recently I have noticed that many other developers were coming to same conclusion, which usually means it is going to happen soon. Just in the past week, Lutz Roeder mentioned separation of code and text in his Reflector presentation; the presentation was actually dated in 2001. There was also many good examples of the potential of SCID (Source Code in Database), which refers to this shift in programming, in http://mindprod.com/projects/scid.html via secretgeek.com.
I think a major cause of the delay in this revolution is that both C/C++ relied on preprocessors and headers. Some historical languages like Smalltalk actually had this support. Fortunately, more modern languages like C#, Java and VB are standalone files, one class per file, with a little or no preprocessing support. This enables easy parsing.