Larry O'Brien has a great article in the SD Times “Windows & .NET Watch“ that discusses his experiences at that latest Microsoft PDC. I especially like the report about the Visual Basic .NET demonstration of the beloved Edit and Continue feature:
During Chris Dias’ talk on Visual Basic .NET, he demonstrated “Edit and Continue,” a much-beloved feature of VB6 that hasn’t yet been available on .NET. An audience member asked if it would be available in C#. Dias, who is group program manager for Visual Basic, answered with an obviously rehearsed reply: “The VB.NET team has chosen to put a lot of resources into this feature. Whether the C# team chooses to allocate resources for it is their choice.”
When the questioner began to say, “Well, it is a big deal to—,” Dias cut him off with an icy “Yes. It is a big deal.”
Apparently the C# team decided that edit-and-continue wasn't important enough to put into their product for the Whidbey release. Personally, I think this is a big mistake having saved countless hours while debugging and developing using edit-and-continue with VB6. Yeah, that's right - I'm a VB transplant and I love C#. I've been sending emails to everyone I can find on the C# team pleading with them to implement edit-and-continue. I stressed it's value to me as a developer and told them that I find it bewildering that the Microsoft Office team decides to put in a billion features that I will never use all in the name of ROI and TCO and if the C# team truly cares about ROI and TCO, they will implement edit-and-continue at some point in the near future. The whole argument about .NET being language-agnostic goes out the window when the VB.NET team puts in a HUGE, HUGE, HUGE productivity feature like edit-and-continue and C# team decides not to. Well, OK, maybe the IL still ends up being pretty much the same; however, the choice is clear to developers that need productivity features - VB.NET is the winner. How many times have you been in debug mode after a lengthy procedure to get to a specific point and situation in code in order to find a problem, and then need to make small tweaks to fix it? For me, this happens quite often. The process of stopping, fixing, recompiling, and re-running takes a lot of time; especially in a world where customers want their products/solutions yesterday!
Let me make it clear that I think C# is the best thing since sliced bread and I like it much more than VB.NET. I find it easier to read and write. However, if I'm going to save a ton of time due to the edit-and-continue feature, I'm happy to switch to VB.NET and recommend their product to management as well. Management at most companies are all about ROI and TCO. The C# team will come to realize this in a big way after Whidbey is finally released. That is my prediction.
