James Robertson links to an interesting blog post from Paul Vick about Visual Studio's background compilation. That post was preceded by an even more interesting introductory post that explained some history. Summary: The old Visual Basic was completely compiled in the background while .NET languages are not, but almost completely "compiled". Paul is in the midst of explaining why.

You'll remember that the flawed background compilation was one of my major gripes about Visual Studio .NET so I'm interested in seeing this fixed. It would also probably affect other gripes I had, including code formatting, refactoring and code completion.

For comparison, Eclipse keeps a sort of "DOM-like tree" of the code you're working on as far as I understand it. This seems to be much different than the Microsoft file-based approach, where everything is recompiled based on files being "dirty" or not, covered in Part 1 of Paul's explanation. All speculation on my part, though.

Besides being more comprehensive than Visual Studio (Paul admits that .NET does not compile the code in the background with a full compiler), Eclipse seems to be more efficient. The delays on Eclipse seem slower, and having a tree of the entire workspace in memory instead of relying on files would also explain why Eclipse is such a RAM hog. Trading resources for speed or features seems like a reasonable compromise to make for a developer workstation. RAM is cheap these days.

But to get back to what James said about Smalltalk: there's a good chance the Eclipse guys were inspired by Smalltalk's image idea -- the same people that wrote Eclipse also worked on Visual Age. I don't know much about the Smalltalk image, though ... except that it is not file-based.

As for C#'s less than perfect background compiling: I can't stand it. There's nothing worse than editing a file in a *modern* IDE, seeing no errors, then compiling/running it and finding compile errors. It's a complete waste of my time and it only gets worse as the project gets larger and more complex. I know we've come a long way from the dark ages of the command line interface but I'm a new school hacker -- I'm more demanding, I'm writing agile code and I'd rather not wait for: code, complete re-compile, run test suite, code, complete re-compile, run test suite, etc... :)

I will be following Paul Vick's blog now to get the reason, though I'm betting it will be the result of a tough engineering compromise (like keeping file paradigm around instead of hogging RAM). Microsoft's transparency though blogs in this case helps me understand these compromises. If I can grok the compromise I will respect it more as an engineer and also get a handle on when I expect the situation to improve. Definitely sweet. Blogging is changing the software business on a grass-roots level like this ... when will other companies catch the cluetrain? Who knows ...