VS.NET Background Compilation Issues

Ryan Lowe comments on my post and on the Visual Studio link that I originally commented on. He's not happy with the way background compilation works in VS:

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...

That's an interesting problem, and one that "new school hackers" would simply not have were they using Smalltalk. In a Smalltalk system, the code you are creating doesn't need a complex background compilation process - each method is compiled into byte code at the point where you accept (compile) it. That means that you can actually create a test - before the code is written (with said test referring to non-existant code). The system will complain about references to objects that don't exist, but you can let that go. Your test will fail of course - but that's the point (then, at least). You can then start creating the classes and code you need, testing incrementally the whole time

XP came up out of Smalltalk because Smalltalk supports that way of working. While you can use agile techniques in any language, they offer the most productivity in a truly agile language (like Smalltalk). Look at what VS and Eclipse are trying to do - build a Smalltalk-like system. You could actually be working with one, instead of with some second hand, not fully baked copy :)