Why no "Edit & Continue" for C#? RRS feed

  • Question

  • User-926394948 posted
    I keep hearing that VB.net will get "Edit & Continue" functionality, which is great. Unfortunately, it sounds like C# will not be getting it. From an interview with Ari Bixhorn (referenced below), they say that the capability is built into the framework itself, but that they didn't put it in C# just because C# developers thought it was "unimportant". If they surveyed C# develops that used to be C++ programmers, they might not even know what Edit/Continue is! I understand how important it is for VB developers, but if it is already in the framework, why not implement that wonderful feature for their most-prized language--C#? If they did, I would be willing to bet that it would quickly become a feature that C# developers could not live without as well. If it will in fact be a feature in the next C# version, someone please let me know! Mike =============== reference: http://www.ftponline.com/vsm/2003_12/online/meader/page4.aspx article by Patrick Meader "PM: As far as other languages go, I understand edit-and-continue is implemented in the framework, but not all .NET languages are required to implement it. For example, C# won't. AB: That is correct. ....... This was high on the list of VB.NET developer requests, and relatively unimportant to C# developers surveyed. But we understand our customers will be up in arms if we deliver Whidbey without edit-and-continue. Edit-and-continue has always been part of the soul of Visual Basic, so VB developers have expected it to be there. Not surprisingly, they were a little shocked when it wasn't in there. "
    Wednesday, November 5, 2003 10:17 AM

All replies

  • User263997249 posted
    The way I hear it, it's because it's a huge deal to implement and as you can see from the quote, there were "more important" items on their ToDo list.
    Wednesday, November 5, 2003 10:44 AM
  • User-926394948 posted
    Yeah, that answer was way too easy I suppose. :) I was hoping for insight from someone on the inside. I develop my web apps in C# and it's just a pain-in-the-ass to hit the stop button and restart just to see if my change worked.
    Wednesday, November 5, 2003 11:46 AM
  • User899048038 posted
    Well, it's all about language target audience. VB is kind of defined as the RAD-oriented language and c# as the discipline-oriented language. Because of this, the VB team puts their resources into features which increase productivity and efficiency the most, and the c# team puts their resources into features which lean more towards elegance, and software development practices. These are are not always conflicting goals, but of course they are also not always the same. This is one feature that happens to land much higher on vb's list of goals than c#'s. P.S. This post is not meant as a troll for a language flamewar, and I won't be responding to any remarks along that line.
    Wednesday, November 5, 2003 1:14 PM
  • User-950908124 posted
    Well, everytime I hear a feature request for the "With" keyword C# developers are always the first to say they want to keep "VB Features" out of C#. Well, the Edit-And-Continue is primarily a VB feature and the C# developers are just getting what they want, no VB-less C#. Although I thought C++ had a similar feature. Thanks, Shawn
    Wednesday, November 5, 2003 1:36 PM
  • User-926394948 posted
    Yes, the C# team does have a long list of great new features. Nobody would fault them for saying, "Yes, we agree that this feature would be a great benefit to C# developers as well, but these other features should come first. We would like to add that in the future." I guess that is what I hope to hear sometime anyway. Hopefully they are not totally discounting that feature just because the C# developers they polled said it was not necessary. Just because they add a great productivity feature to C#, it will not make it any less powerful of a language. Eventually, the C# team will likely run out of ideas to evolve the language for "elegance" and "software development practices". At that point, maybe they will then shift focus to productivity enhancements. But since that is their focus at this time, I can wait. :) P.S. Thanks for the replies to my original post.
    Wednesday, November 5, 2003 3:35 PM
  • User2091567487 posted
    They did enhance CLR to accomidate Edit-And-Continue. New meta data tables are defined, which is instantiated by the debugger to inject "delta" codes into compiled IL and fix references. It's just amazing how much effort was made at the CLR level to have this done, it's too complicated to be incuded in version 1. Last week at the PDC "Ask The Experts" evening, I was among a group of attendees talking to Dr. Anders Hejlsberg, the creator & architect of C#. Someone asked him about the missing of E-n-C in C#. He doesn't like crude code-injection techniques and such debugging practices, so unless somebody convinces him otherwise, you won't see E-n-C in C# soon. To me, E-n-C as a debugging tool does seem a little weird. There's limited editing you can do in Whidbey: you can edit and add statements before and after the break point, but you can't change the method's signature. You can't put a try block around it either. You can backtrack the break point, but that only moves the Instruction Pointer backwards, the existing state is not changed, meaning that the variable values are not rolled back. So you have to know exactly what you are doing and the ramification of your action, to debug correctly. Gotta be careful not to introduce new bugs. For Asp.net developing, there is no need to rely on E-n-C anymore, because your code file will be a partial class of your .aspx file; the 2 will be compiled together to form 1 class. So individual page editing can be compiled and tested, there is no need to rebuild the entire site. We C#/C++ developers are not familiar with E-n-C techniques, therefore are not sure about the usefulness of this debugging tool. Let's wait and see if some of us will find it valuable, after playing with VB's E-n-C for awhile. Similarly, VB coders aren't crazy about some of Visual C#'s high priority features like refactoring, simply because they have never been exposed to it yet. But this one I'm sure they will love it, once they see the demo and understand how it works. -- Juyi Kuo
    Thursday, November 6, 2003 1:26 AM
  • User-950908124 posted
    C++ & C# programmers may not be familiar, but 3 million VB developers are. It's a very useful debugging tool. One which has saved me much time from having to rebuild large projects just to make a change (I'm not the only one with a good debugging experience as a result of the feature). It may appear that moving to C# is the better way to go, but why should I have to stick with VB just so I can have a better debugging experience? It gets old listening to the arguments of C#/C++ developers not understanding certain things that just happen to be features in VB and then determining the world is a better place because no VB feature is in C#. I've heard many tell me "learn a real programming language and quit hanging on to VB". Well, how is VB any less real than C#? Name one managed .NET app that can't be developed in VB that can in C#? The bottom line is that productivity is lost when we have to stop the debugger and then make a change and then re-run the debugger vs. make the change during a breakpoing and move on. It is not an all-ecompassing debugging tool, it never was meant to be. Even in VB, we couldnn't change the function signature (it's unrealistic to expect the whole app to be changed in-place), couldn't change a select statement (switch() in C#), and the state of the debugger was always progressive even after moving the location of the current executing line. If you wanted to set a variable, you had to set it yourself -- the debugger didn't managed state in such a manner to revert it back if you moved the executing line above the current. However, it was a very useful feature for certain kinds of debugging: a numeric was originally programmed incorrectly, some other variable was originally programmed incorrectly, forgot to set an instance of an object, accidently left out or added a parameter or more when you call another method or you had them in the wrong order. Calculations, formulas, or basic algorithms needed some tweaking. Simple stuff like that, you could correct without having to rebuild the project everytime you needed to make a change. Even now, in ASP.NET, our web application takes about 40 seconds to build each time we need to run it and that means productivity loss just to keep tweaking a particular value. Our machines are P4 2.4+ GHz machines with at least 512-1024 MB ram. It's a very large web app and a few supporting business layer DLLs (which themselves requires may 1 second of compile time). So the bottom line is yes, such a feature could be benificial to C# programmers as well, whether any C# programmer currently cares. But it's offensive to hear people say "then just stick with VB because we don't want VB features in C#". If anyone doesn't want to progress and be more productive, it has to be the people who make such remarks. For now, we can all manage. I'm not about to stick with VB just because of that feature, but among other things, even though I'm good in C++/C/C#, VB is still just more productive overall. And really, I haven't yet found something I can do in C# that I can't do in VB. Thanks, Shawn
    Thursday, November 6, 2003 6:38 PM
  • User263997249 posted
    I thought it was just that C# developers don't like to be productive? ;) I use both at work about half and half, but once I leave work, it's all VB...why? Not because I hate curly braces or just love the VB language (in fact there are a few things I hate about VB that i love in C#), simply because of the IDE and features that make me more productive. C# may be cool, but I can't be productive with it, forget it! :P That being said, I'm really excited about a lot of the new language features for C# too! :)
    Thursday, November 6, 2003 6:52 PM
  • User1356982465 posted
    I'm not sure there are going to be any language features in C# not in VB actually. Generics and partial types are in VB, and so is operator overloading and unsigned data types in Whidbey. If anything, one could argue there's more in VB, like with. I actually prefer C#, and that's still my primary at home, but work requires VB.
    Thursday, November 6, 2003 8:36 PM
  • User-950908124 posted
    Paul always has good things to say. I can live without the "with" in C# and I'd love to have it. But the edit-n-go feature is something that really, should be included. I don't make such decisions. But it'll be one more thing that makes VB yet-even-more-productive(tm). That said, I'm looking forward to the new language features we *do* know about. Thanks, Shawn
    Thursday, November 6, 2003 11:24 PM
  • User-1454098704 posted
    If you are a VC++ programmer, then you must be familiar with E&C. As a matter of fact, VC++ gives you more option during debugging time such as memory window and conditional break points then VB with VS6.0. Now with VS2003, you get the best of both world during debugging. I believe in finishing projects in a timely manner and not being snobby about what my favorite tool has and does not need. The more tools I can use the better. I use VS2003 and not just VB, C# or C++.
    Monday, November 10, 2003 2:01 PM
  • User-950908124 posted
    It's hard to do when VC++ supports E&C and VB.NET does, but not C#. Thanks, Shawn
    Monday, November 17, 2003 6:03 PM