通过

Edit and Continue vs. Elvis

  • 项目

Continuing on a theme, today we talk about Elivs and E&C. We don't have a good way of measuring how Elvis uses E&C, since C# has never had the feature in a released product. So, what I say here is even more likely to be wrong than normal.

Elvis likes good code, but knows that by the end of the day he needs to have a working solution. E&C represents an opportunity to improve his efficiency and remove tedium. Elvis likes being productive, so he would welcome E&C.

Does he use E&C to experiement with a line of code until it works? Probably, but not often. Guessing isn't his style.

Does he use E&C alleviate long build times? Probably not, since the compiling C# is so much faster than C++.

Does he use E&C to compensate for complex bug repros? Yeah, sometimes. But C# apps tend to get the same functionality as C++ in fewer lines of code, so there's less complexity to manage. And the oldest C++ systems have been around a lot longer than the oldest C# systems, so maybe they haven't had an opportunity to grow quite as complex. 

But given the choice between waiting for stop debugging + build + start + repro, and not waiting, the choice is obvious - you want E&C.

Comments

  • Anonymous
    March 18, 2004
    The comment has been removed
  • Anonymous
    March 18, 2004
    I second the vote for E&C. It's the one thing that I really hate about C# in general. If it can be done, why not support it? It could always be an option you could turn off...
  • Anonymous
    March 18, 2004
    Elvis is dead, get over it. And shave those sideburns while you're at it.
  • Anonymous
    March 18, 2004
    "If it can be done, why not support it?"

    With limited resources, we have to decide how to spend our time for the best benefit of the customer. We chose Refactoring instead of E&C (see my earlier posts). It was a tough call though.

    I see a lot of comments here & on other blogs that say we made the right choice, and a lot that say we made the wrong choice.

    Please keep the feedback coming.
  • Anonymous
    March 18, 2004
    There's only one scenario that I've found myself wishing hard for E&C: when I'm debugging distributed apps and I need to attach debuggers to multiple processes. Starting up multiple processes and attaching debuggers to them is a real pain.

    E&C would be a possible fix; I'd settle for being able to script out what happens when I start debugging. It would be very cool if the IDE let me specifiy a set of processes to start when I choose "start debugging", and attached the debugger to all of them.
  • Anonymous
    March 18, 2004
    Paraphrase: "E&C does not alleviate long build times, since compiling C# is so much faster than C++."

    I beg to differ.

    It takes over FIVE AND A HALF MINUTES to load and compile on my my 2GHz 512MB machine after I make a change to the bottom layer of code. Five and a half minutes. I can go to the bathroom, walk around the building, come back, and yes - it's still compiling.

    We're working on a large solution (72 projects to date). Most of the developers in our group have the same problem.

    Please, anything to speed things up.
  • Anonymous
    March 18, 2004
    Re: Scripting of the Debug Processes dialog
    Yes please! This is such a time consuming pain I have to do 20 times a day.

    Re: Time to build your solution
    I suspect that you don't need 72 projects in your solution and that simplification of your solution down to 10 projects would be possible. The C# compiler is very very fast:

    A month after .Net was publically announced, Peter Golde (formerly of the C# team) said:

    "As a point of reference the last time I checked the WinForms framework code had around 250,000 lines of C# code in 1,200 source files. The C# compiler did a full, from scratch build (source files to final DLL) in under 20 seconds. Incremental build speeds this up by another factor of 4 or so for a rebuild with only minor source code changes."


    Obviously, if your project is 5 million lines of code, I am probably wrong about simplifying the structure of your solution - but I doubt it's that large. I have worked on a 135-project C# project which took 5 minutes to build (including regsvcs time to install). The project was more suited to 8 assemblies so we modified our build process.
  • Anonymous
    March 18, 2004
    Yeah, it looks like our build times don't scale well with number of projects. I believe that good code organization is important, so I'm disappointed by that perf issue.
  • Anonymous
    March 18, 2004
    Jay:
    I feel that you (C# team) made the wrong choice, but you have enough time (until 2005)to correct it :-)

    IMHO Elvis should evaluate the equation
    RefactoringsPerMonth * RefactorSaveTime < DebugSessionsPerMonth * E&CSaveTime before any decision
  • Anonymous
    March 18, 2004
    I'm not sure what C++ had to do with anything here. Who cares if C++ is faster or slower or more complex or less complex? First, not everyone coding in C# came from a C++ background (I came from VB6, others come from Java, etc.). Second, as a developer I don't care about the comparison of C# to C++, if I'm not writing in C++. I notice there's no comparison to VB.NET, J#, or any other .NET language.
  • Anonymous
    March 18, 2004
    The comment has been removed
  • Anonymous
    March 18, 2004
    Steve and Rich,

    Your solution can contain multiple projects, and they can all be launched at the same time. A project doesn't need to do a build, and it doesn't need any code -- just open the exe as a project. Projects can also attach to an exe.
  • Anonymous
    March 18, 2004
    See http://blogs.msdn.com/greggm/archive/2004/03/18/92491.aspx
  • Anonymous
    April 06, 2004
    The comment has been removed
  • Anonymous
    April 07, 2004
    Staffan: thanks for the feedback.
  • Anonymous
    April 23, 2004
    Just give us some sophisticated refactorings(read: IntelliJ). Something more than just rename.
  • Anonymous
    April 27, 2004
    I welcome good refactorings over E&C. I'm the kind of person who thinks E&C is something that could have subtle bug in it and then causing weird behaviour during the usage of it. I'm all for features but E&C sounds a bit too good to be true. Atleast where I'm coming from.
  • Anonymous
    April 27, 2004
    Thanks for the feedback, Joku. I find it interesting that you trust refactorings but are wary of E&C. Around here, we worry more about making refactoring reliable than E&C. If E&C goes afoul, the issue disappears when you end the debugging session.
  • Anonymous
    April 30, 2004
    I'm beginning to see a pattern, those whem jay "thanks for the feedback" appears to be those who support the feature of refactoring as opposed to E&C. What kind of compelling argument can we make for E&C that would cause MS to be thankful for the feeedback?

    By the way, its almost offending to thinks that Mort/Elvis/Einstein represents a group of people. I'm a VB programmer (which may explain why I think E&C is so useful) but I'm also a very accomplished C# developer, and an accomplished C++ developer, and lo-and-behold, code windows apps in assembly (less frequently now than I used to). Did I mention Java, I'm not as experienced but I definitely pull my weight in Java (I like C# better after having used it for a while).

    Refactoring is useful, but I just happen to think that E&C is more useful (in all of my contexts). I would use E&C probly everyday in a typical debug scenario (as a time-saver and a useful way to interactively fine-tune an algorithm that otherwise takes me a few minutes to rebuild and navigate to just to change a +/- or >=/< operator). I doubt refactoring can help me in these contexts, which makes it less useful.

    How many times have I had to rename a variable and propogate it through my code? I name them properly the first time so its not an issue to me. I've had to change a variable (and propogation path) once and that was in an ASP application so refactoring wouldn't have helped me.

    Thanks,
    Shawn
  • Anonymous
    May 10, 2004
    It's interesting to me to see how divided folks are on E&C vs. Refactoring.

    The E&C camp doesn't refactor often, and doesn't think refactoring often is important. Shawn, for example, doesn't need rename because "I name them properly the first time ".

    The Refactoring camp thinks that Refactoring is vital part of being a good developer, but E&C is a nice-to-have productivity tool.

    Oh, and "thanks for the feedback".
  • Anonymous
    May 16, 2004
    Please, please, please give me E&C , ... VB.Net developers will get it so why don't we?
  • Anonymous
    May 17, 2004
    Uhh... thanks for the feedback!

    Seriously, I'm glad to see all the comments here regarding E&C (and every other feature).

    So you know: the feedback regarding E&C is being forwarded around & discussed at the highest levels of management. My boss's boss's boss's boss's boss is looking at it, and is involved in the discussion of C# E&C.
  • Anonymous
    May 17, 2004
    The comment has been removed
  • Anonymous
    May 23, 2004
    Honestly, I'm curious what the developers who say E&C is a bad thing are doing during those unproductive 60+ seconds after they click start in Visual Studio when they are testing a bug fix they just made.
    What am I doing during those long 60 seconds to recompile? I'm cursing about the fact that I don't have E&C like I used to.
  • Anonymous
    May 24, 2004
    cwillis: Honestly? They're doing TDD, and rarely touch a debugger. Test-Driven Debugging is very effective!
  • Anonymous
    June 07, 2009
    PingBack from http://greenteafatburner.info/story.php?id=5107