Drafting Edit and Continue

As I think the entire blog universe knows by now, C# is going to be adding Edit and Continue in their 2005 version. As I’ve said many times before, I think Edit and Continue is a great feature, so I’m happy to see another language on board with it. Of course, there’s a selfish part of me that would have liked to see the C# team continue to ignore such a great feature and leave it completely to us, but what’s good for the goose…

What’s interesting about this, though, is that it points up one of the practical reasons why having three .NET languages at Microsoft is a Good Thing(tm). As evidenced by the fact that the C# team didn’t originally plan to do Edit and Continue, if there had only ever been C# at Microsoft, Edit and Continue would probably never have happened. The CLR team only added the underlying support for Edit and Continue because VB insisted on it and then sat down with them and worked out how it was going to happen. Similarly, I don’t know if generics would have ever happened if there had only ever been VB at Microsoft, even though I think it’s going to be an excellent feature for our customers. Lacking the C++ history, it’s something that we probably never would have pushed the CLR team to implement the way the C# team did.

It occurs to me that this is an extension of Rocky’s excellent rant on programming languages, just flipped around. His point is that programmers who limit themselves to knowing just one language limit their ability to think about programming. I think the same goes for the Microsoft.

What I find really interesting is the way that the language teams end up drafting one another as we go forward. Drafting is the phenomenon mostly commonly used in cycling where a cyclist can maintain a higher speed with less energy when following in the backdraft of the cyclist ahead of him. (A better explanation can be found here.) A lot of cycling strategy involves members of the team riding ahead of other team members (say, Lance Armstrong) so that the following rider can conserve energy for the final push at the end of the race. Interestingly, drafting can also help the lead cyclist as well, although I lack sufficient physics knowledge to really explain that.

Anyway, the point of this whole digression is that a very similar thing happens inside of Microsoft as well. When the C# team decided to implement Edit and Continue, it was easier for them to do so than it had been for the VB team because the VB team had already worked out a lot of the details (and a lot of the kinks in the system) beforehand. Similarly, the C# team started implementing generics before VB did, so they ended up working out a lot of details for us ahead of time. In the end, each team takes advantage of the work the other team is doing to advance their own language more rapidly. It’s a very virtuous cycle.

Of course, a lot of the people who don’t like Edit and Continue are the same people who don’t think that Microsoft shouldn’t bother to have more than one language (read: C# is the “one true language”). So instead of drafting, they probably think of pollution instead. Ah well, to each their own…

6 thoughts on “Drafting Edit and Continue

  1. Phil Wells

    Nonetheless, if every language is going to adopt what’s good in the others, it does beg the question: what, aside from syntax, distinguishes the languages? How do I decide what programs I should write in C# and what would be better written in VB?

  2. Drafting at the front of the pac

    …if you have ever watched a Dolphin effortlessly ride the pressure wave created by the bow of a boat as it slices through the water you can see how this might work for the rider at the front of the pelton. The group is large enough that some of the air hitting them is pushed back in front of them and tends to give the front riders a bit of a push. Not so much drafting as reverse drafting 🙂

  3. Cade Perkins

    I like the philisophical explanation of why Edit and Continue is good or bad. However, for me it comes down to one main problem with VS.NET 2003–it’s way too slow. I waste more time building, debugging, stopping, changing code, building, debugging, stopping… If I could change code midstream, I would shave hours from my .NET development time.

    As for why drafting may also help the front rider… Direct air resistance from oncoming wind is only part of the friction. Back drafts from air curling behind a rider form turbulent low pressure points that also "pull" a bike rider backward. A hind rider allows the air to continue flowing past the front rider more smoothly, thus reducing back draft for the front rider, thereby reducing the front riders resistance also.

  4. Cade Perkins

    One more thing… You use the word "digression" periodically, but I find it ironic since your blog is one of the most relevant when it comes to MS development and .NET. Please continue "digressing" if you will, but please realize that your tidbits of information and topic selection are great (IMHO)!

    Thanks for your content.

  5. paulvick

    Cade: Thanks for the comments!

    Phil: The fact that languages steal ideas from each other doesn’t mean that they’re going to end up being the same. Not all ideas that one language has is taken by other languages – just because C# stole the idea of generics from C++’s templates, doesn’t mean that C# and C++ are the same language. However, I understand what you’re getting at and it’s a question that I hope to address better in the near future…

  6. Taiwo Ayedun

    It is NOT a bad thing for VB.NET and C# to continue to have similar features. Some people just prefer one language’s syntax over the other and that preference should not be underestimated.

    However, it would be very productive for the VB.NET and C# development teams if there can be some common framework so that one team can easily build on the work of the other team rather than duplicating efforts on the same features. I recognize that this is easier said than done but I believe that it is worth the effort of both teams to evaluate such a framework.



Leave a Reply

Your email address will not be published. Required fields are marked *