This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: VS.NET Background Compilation Issues
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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 :)