Edit and Continue vs. Mort
All this talk about E&C, I thought it'd be a good idea to talk about the personas.
Ian has a good description of the personas we use when talking about Visual Studio users. There's a language correlation, too. VB primarily targets Mort, C# targets Elvis, and C++ targets Einstein.
Mort
Consider what happens when Mort decides to solve a problem with some software. He probably doesn't know what the solution will look like. He will likely try to find some existing code that does something similar and cut-and-paste it into his code. He won't waste time trying to understand how this chunk of code works, he's got a problem to solve. He'll run the code & try it out in a couple ways. If it works, he's done.
If it doesn't work, he'll run under the debugger. He'll try experimenting with various changes to the code until it seems to work. (In VB6, he would do much of this experimentation in the immediate window, and then paste the result into his code.) E&C is the foundation of this approach to development.
Comments
- Anonymous
March 14, 2004
> E&C is the foundation
> of this approach to development
Wrong. E&C is a debugging tool and a very useful one. Why even have a debugger if you architect and write perfect code the first time??? It is a productivity tool and nothing more. Yes, there are "Mort" VB developers, and the are C++ "Mort" developers as well I'm sure. For you to say that all VB developers are "Morts" is rediculous and insulting to your customers. I happen to prefer C#, but I know many good VB.NET developers. I'd like to hear what Dan Appleman has to say about this. - Anonymous
March 14, 2004
Couldn't one make the same argument...that refactoring is a Mort feature? Think about it, if you have a good design up front, why would you need to refactor??? In the real world we continually refactor our code and we also use E&C when it is available. I like E&C and I don’t consider myself a Mort developer.
I think any productivity feature is a good one. I personally believe that E&C helps more with productivity that refactoring would. Think about an application where you have to make 20 clicks or entries to get to the code that is problematic. It sure is nice to tweak a little to see the results without having to drill back into your app. For certain tasks E&C is pointless…but for others it is a great feature.
VB is a great beginner language. It is also a very power development tool for an experienced developer. There were a number of key areas where it was lacking and I feel that VB.NET has bridged that gap. C# is a great language too and in many ways better than VB.NET. I guess I will have to play with both to decide for sure if I prefer E&C or refactoring.
Thanks for all your hard work at MS…I personally love your products!
Tom - Anonymous
March 14, 2004
Hey Sean. I don't mean to describe Mort as an insulting label. Most people who write software professionally seem to fit the Mort description, based on the survey results I've seen. I imagine Morts don't really want to spend their time learning more about software development - they've got better things to do. - Anonymous
March 15, 2004
The comment has been removed - Anonymous
April 08, 2004
Programmers that don't analyze problems/code won't change based upon whether E&C is in VS.NET or not. This is like saying (~very~ loose analogy) that there can be peace in the Middle East if the United States pumped more food into the region.
Both problems are more systemic. Productivity (by adding E&C) seems more like something which can be solved as opposed to good programming practices (by not having E&C).
I like the feature, but I don't really NEED it. I can think of many things VS.NET could do better I would much rather have.
My 2 cents. - Anonymous
April 23, 2004
For the right developer; E&C is nothing more then a time saver. For other developers, it's a learning tool. But, I believe for the most part, that it can instill bad habits.
I don't care...more work for me in the future I guess :)
Personally, I want to see intelligent refactorings. - Anonymous
April 30, 2004
Chris,
Relying on a refactoring tool can instill bad habbits, also. No need to get it right up front, the IDE will correct your code so there's no need to get it right up front.
E&C, however, is a very useful utility (I would use it more than refactoring because most of my code doesn't need to be refactored so much that I would need to use a utility as a cruch). I have very strict disciplines and designing and getting things right up front is something that I excell at. In fact, my quality rate is 99%... and the 1% defect is mostly to misunderstanding the spec but not functional defects. Things have not once returned to me in the last 2 years due to a defectiveness in my parts of the code (the only people who believe me when I say that are those I work with. I have been able to pass it on to one other newcomer and now he is almost as productive). When I turn things in, they work, are designed very well, and few people have any trouble using the objects/object models or reading/maintaining my code. Most of their difficulties are in adapting themselves to it because they are used to be so disciplined.
For example, our application takes not only minutes to build (it's a huge application) but much time to navigate to where we need to be at the debugging cycle. Having to restart the debugger to change a +/- sign is rediculous.
Of course, other things, like changing a function defination, possible a switch block or something like that, I can understand it it has to be restarted but for changing variables or adding a few more lines of computation, E&C is invaluable in all of my contexts.
Personally, I'm dissappointed that Refactoring took precedence of debugging. In my OPINION, those who NEED refactoring [as a crutch or as a frequently used tool] are probably more in need of a better debugging experience than those who don't. I mean, if you constantly need to refactor, then theres a good change you have more bugs to track down, as well. People can be trained to write good code that doesn't need to refactor frequently but we all need to debug. My debugging takes place before I turn it in, not after. Of course, we all need to refactor, too, because the software changes with time and requirement, but far less frequently than debugging.
But, it doesn't surprise me, the more tools we come up with that make programming easier and abstract more and more technical details away and make it easier to write more code faster, will inevitably produce a lot of developers who need to refactor for various reasons and possibly rely on this tool and find it more useful than a good debugging experience, I don't want to generalize so I'll leave it at that.
Thanks,
Shawn - Anonymous
January 25, 2007
PingBack from http://zombiesrus.net/?p=4