C# is getting Edit and Continue in Visual Studio 2005 | | | re: C# is getting Edit and Continue in Visual Studio 2005
Wow thats nice. I have no idea why you have mixed feelings about it.
One of the most painful times to not have edit and continue is when you are
working on a large procedure to migrate a database. I really sucks when you
have to wait two hours until you reach the breakpoint again. LOL
---
Alex Korchemniy
"Richard Blewett [DevelopMentor]" wrote:
[color=blue]
> I've just seen on Eric Gunnerson's blog that C# is getting Edit and Continue in Whidbey. That will please alot of people - although me, I have mixed feelings about it ;-)
>
> http://blogs.msdn.com/ericgu/archive...15/242931.aspx
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
OK, let me be clear that I *do* mean *mixed* feelings. E&C is a useful tool in some scenarios and can really help resolve things like getting the logic the wrong way round in an if, etc then you are debugging a problem. But I have been burned in the past in two ways by it.
1) Writing a bunch of fixes via edit and continue and then the debug session getting trashed so having to close VB and losing all my changes (I know its my fault but E&C has a siren call theat leads you down that path.
2) It is a dangerous tool in the hands of inexperenced developers in that they will keep hacking around in a function in the debugger until it gets the result they want. Whether the function as a result actually fits all test criteria or whether the code is structured in a maintainable form becomes a secondary (or not even considered) issue.
Its nice to get E&C but to be frankly I didn't miss it all that much - you only really miss it if it is one of the main features of how you write code, and from a C++ background primarily it never was for me (I know C++ had E&C from version 6 but frankly I think it sucked rocks compared to VB's version.). Test Driven Development to me is a much more powerful thing to have at your disposal - and maybe combined with E&C gives quite a good sweet spot in that if while making changes in a function you break something you'll know pretty quick.
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
Wow thats nice. I have no idea why you have mixed feelings about it.
One of the most painful times to not have edit and continue is when you are
working on a large procedure to migrate a database. I really sucks when you
have to wait two hours until you reach the breakpoint again. LOL
---
Alex Korchemniy | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:uDwkqrvsEHA.2536@TK2MSFTNGP11.phx.gbl...[color=blue]
> 1) Writing a bunch of fixes via edit and continue and then the debug[/color]
session getting trashed so having to close VB and losing all my changes (I
know its my fault but E&C has a siren call theat leads you down that path.
Well, I don't know which model C# will follow, but in VC++, E&C still
requires saving changes to disk before compiling & continuing execution.
[color=blue]
> 2) It is a dangerous tool in the hands of inexperenced developers in that[/color]
they will keep hacking around in a function in the debugger until it gets
the result they want.
I don't see this as being a problem with E&C. Bad programmers will
write bad code. E&C helps (good & bad) programmers write code faster.
Therefore, E&C will help bad programmers to write bad code faster. But it
also helps good programmers write good code faster.
--
Truth,
James Curran
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
(note new day job!) | | | | re: C# is getting Edit and Continue in Visual Studio 2005
The point I was making in 2 wasn't about *bad* programmers it was about *inexperienced* programmers. I don't think E&C teaches people good programming practice, although it is a very useful tool in the right hands.
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
[color=blue]
> 2) It is a dangerous tool in the hands of inexperenced developers in that[/color]
they will keep hacking around in a function in the debugger until it gets
the result they want.
I don't see this as being a problem with E&C. Bad programmers will
write bad code. E&C helps (good & bad) programmers write code faster.
Therefore, E&C will help bad programmers to write bad code faster. But it
also helps good programmers write good code faster. | | | | re: C# is getting Edit and Continue in Visual Studio 2005
Nearly any feature can be abused, or misused.
"Richard Blewett [DevelopMentor]" wrote:
[color=blue]
> The point I was making in 2 wasn't about *bad* programmers it was about *inexperienced* programmers. I don't think E&C teaches people good programming practice, although it is a very useful tool in the right hands.
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>[color=green]
> > 2) It is a dangerous tool in the hands of inexperenced developers in that[/color]
> they will keep hacking around in a function in the debugger until it gets
> the result they want.
>
> I don't see this as being a problem with E&C. Bad programmers will
> write bad code. E&C helps (good & bad) programmers write code faster.
> Therefore, E&C will help bad programmers to write bad code faster. But it
> also helps good programmers write good code faster.
>
>
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:%239$ZueusEHA.1336@tk2msftngp13.phx.gbl...[color=blue]
> I've just seen on Eric Gunnerson's blog that C# is getting Edit and
> Continue in Whidbey. That will please alot of people - although me, I have
> mixed feelings about it ;-)
>[/color]
Ya, annoying, ain't it? :)
| | | | re: C# is getting Edit and Continue in Visual Studio 2005
I would be more curious in how they "figured out a way to do it". Did they
figure a cheap way to do it? If so, how in general?
--
William Stacey, MVP
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:#9$ZueusEHA.1336@tk2msftngp13.phx.gbl...[color=blue]
> I've just seen on Eric Gunnerson's blog that C# is getting Edit and[/color]
Continue in Whidbey. That will please alot of people - although me, I have
mixed feelings about it ;-)[color=blue]
>
> http://blogs.msdn.com/ericgu/archive...15/242931.aspx
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
For the projects I work on it will be a godsend. It may take up to 10
minutes to compile, launch, and get back to where I was in the debugger when
I realized I needed to write ( someBool == true ) instead of ( someBool ==
false).
Like all tools, it can be abused - I don't find that to be a compelling
enough reason to not have the feature.
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:uDwkqrvsEHA.2536@TK2MSFTNGP11.phx.gbl...[color=blue]
> OK, let me be clear that I *do* mean *mixed* feelings. E&C is a useful
> tool in some scenarios and can really help resolve things like getting the
> logic the wrong way round in an if, etc then you are debugging a problem.
> But I have been burned in the past in two ways by it.
>
> 1) Writing a bunch of fixes via edit and continue and then the debug
> session getting trashed so having to close VB and losing all my changes (I
> know its my fault but E&C has a siren call theat leads you down that path.
>
> 2) It is a dangerous tool in the hands of inexperenced developers in that
> they will keep hacking around in a function in the debugger until it gets
> the result they want. Whether the function as a result actually fits all
> test criteria or whether the code is structured in a maintainable form
> becomes a secondary (or not even considered) issue.
>
> Its nice to get E&C but to be frankly I didn't miss it all that much - you
> only really miss it if it is one of the main features of how you write
> code, and from a C++ background primarily it never was for me (I know C++
> had E&C from version 6 but frankly I think it sucked rocks compared to
> VB's version.). Test Driven Development to me is a much more powerful
> thing to have at your disposal - and maybe combined with E&C gives quite a
> good sweet spot in that if while making changes in a function you break
> something you'll know pretty quick.
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
> Wow thats nice. I have no idea why you have mixed feelings about it.
>
> One of the most painful times to not have edit and continue is when you
> are
> working on a large procedure to migrate a database. I really sucks when
> you
> have to wait two hours until you reach the breakpoint again. LOL
>
> ---
> Alex Korchemniy
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
I'm not saying I don't want it, in general I'm pleased - I just wasn't running around my house shouting "WAHOO!!!" when I heard because it also can have a downside that I've experienced directly
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<e3PPA$xsEHA.3152@TK2MSFTNGP14.phx.gbl>
For the projects I work on it will be a godsend. It may take up to 10
minutes to compile, launch, and get back to where I was in the debugger when
I realized I needed to write ( someBool == true ) instead of ( someBool ==
false).
Like all tools, it can be abused - I don't find that to be a compelling
enough reason to not have the feature. | | | | re: C# is getting Edit and Continue in Visual Studio 2005
Now *there's* an image... :-)
I agree about the dangers of E&C, but I think it likely that a programmer
that abuses E&C is likely to abuse other tools, not use the appropriate
tools, or use them incorrectly.
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:eAof8B1sEHA.2316@TK2MSFTNGP12.phx.gbl...[color=blue]
> I'm not saying I don't want it, in general I'm pleased - I just wasn't
> running around my house shouting "WAHOO!!!" when I heard because it also
> can have a downside that I've experienced directly
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
>
> nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<e3PPA$xsEHA.3152@TK2MSFTNGP14.phx.gbl>
>
> For the projects I work on it will be a godsend. It may take up to 10
> minutes to compile, launch, and get back to where I was in the debugger
> when
> I realized I needed to write ( someBool == true ) instead of ( someBool ==
> false).
>
> Like all tools, it can be abused - I don't find that to be a compelling
> enough reason to not have the feature.
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
Devin wrote:
[color=blue]
> Nearly any feature can be abused, or misused.[/color]
True, however you forget an important step. I assume you're a developer,
what else would you do reading this newsgroup ;). A developer sometimes has
to develop GUIs. Now, the best thing that can be done is to help the user as
much as possible so that the user makes the least amount of mistakes, which
results in the highest amount of succesful work. The point is thus to
disallow things which can result in failure, so you add checks, disable
controls on a given state etc. etc.
A developer is also a user, a user of a development environment and computer
language. No matter what, it's best that the developer makes the least
amounts of mistakes so the success rate is high. Giving a tool like E&C to
developers, makes it very easy to alter code inside the debugger until the
results are what is expected. This typical behavior is called 'Trial and
Error'.
What's way more efficient is to take a step back and actually analyse what
you've written, think through what the code should look like and compare that
with the code what was written. No trial and error, but structural software
engineering. People who develop planes don't have edit and continue, as they
arent able to alter a flying plane to fix a bug. Software engineers sometimes
seem to think that what they write is not that mission critical.
However this has been beaten to death for a loooooong time now. I can only
advice people what I've learned during the past 11 I do serious, professional
software development: learn to debug with analysis of the code written, the
algorithms to write. Debugging is hard, it's a science. However I firmly
believe that if a developer is forced to use a debugger like the gdb
commandline debugger, he/she will learn soon enough that stepping through 500
lines of code just to reach the lines where the error is originated is not
helping, and neither will altering code on the fly 'to see if this works'.
The only times I feel the need for E&C is when I need to use XPath queries
and I have an error in them. It's pure trial and error, and restarting the
app is then time consuming. It's however not the lack of E&C that makes it
time consuming. It's the lack of understanding of XPath on my side that makes
it time consuming. I also could have setup a set of simple tests to see which
query would do the trick for example, read more documentation etc. etc.
Without E&C you are forced to do that, but at the same time also learn things
along the way. With E&C you can hack around till it works and move on, with
the risk of running into the same error very likely.
I've written a piece about E&C some time ago and why it is bad. I can tell
you, being anti-E&C is not making you a lot of friends. Which I find rather
strange, as if people don't want to learn how to write proper software! http://weblogs.asp.net/fbouma/archiv.../01/22211.aspx
Frans.
[color=blue]
>
> "Richard Blewett [DevelopMentor]" wrote:
>[color=green]
> > The point I was making in 2 wasn't about bad programmers it was about
> > inexperienced programmers. I don't think E&C teaches people good
> > programming practice, although it is a very useful tool in the right
> > hands.
> >
> > Regards
> >
> > Richard Blewett - DevelopMentor
> > http://staff.develop.com/richardb/weblog
> >[color=darkred]
> > > 2) It is a dangerous tool in the hands of inexperenced developers in[/color]
> > that they will keep hacking around in a function in the debugger until
> > it gets the result they want.
> >
> > I don't see this as being a problem with E&C. Bad programmers will
> > write bad code. E&C helps (good & bad) programmers write code faster.
> > Therefore, E&C will help bad programmers to write bad code faster. But it
> > also helps good programmers write good code faster.
> >
> >
> >
> >[/color][/color]
--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP | | | | re: C# is getting Edit and Continue in Visual Studio 2005
David Levine wrote:
[color=blue]
> For the projects I work on it will be a godsend. It may take up to 10
> minutes to compile, launch, and get back to where I was in the debugger
> when I realized I needed to write ( someBool == true ) instead of (
> someBool == false).
>
> Like all tools, it can be abused - I don't find that to be a compelling
> enough reason to not have the feature.[/color]
My question then to you is: if it takes 10 minutes to compile, why hasn't
anyone asked why there are so many projects in 1 solution and why you didn't
use TDD? I.e.: write the test first, then the implementation of your routine,
then run the test, see if the routine fails the test or not.
This is why E&C will not help you: the compile time of your solution will
still be 10 minutes. Step back and change! Chop up the solution into smaller
solutions. You don't work on 100 projects at teh same time, probably only 1.
This means that only 1 project has to be recompiled, or a couple. There are
build tools which do this for you. Command line builds with simple nmake
scripts are way faster than building in vs.net. Also with smaller solutions,
debugging/building is faster and running tests/altering code/ running tests
is also faster.
The fun thing is: with the TDD approach, you already have your test and you
keep it. So you can always check if what you altered failed some tests and
the TESTS are the representation of the specification you have to implement.
It might sound odd or old fashioned, but software development is not
something about ad-hoc code hammering. It's about crafting code to represent
functionality and data-structures. That takes time and skills and above all a
plan. Now, why is it that in the rest of the engineering business the plan is
the leading aspect of a project and everything is tested if it complies to
the plan, but in software land it appears to be something which can be
accomplished in a trial and error way inside a debugger 'till it works'. I
hope boeing never implements E&C on their products so their engineers can try
to 'fix' problems when the plane malfunctions at 30,000 feet.
Frans.
--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP | | | | re: C# is getting Edit and Continue in Visual Studio 2005
You have a valid point but I disagree with your conclusion; IMO you present
a very one sided picture of how devs will use E&C. As everyone has already
pointed out, any tool can be misused - that still does not invalidate the
tool.
Developers are not equal - everyone has still different skill sets and
different levels of training and experience. A developer at a lower skill
set, or an inexperienced, lazy or incompetent developer might all use E&C
for fulltime trial-and-error, throw-code-at-it-until-it-works development,
but most developers don't use it that way and most don't work that way at
all. All good developers think about their design and implementation. Even
well-designed, structurally sound software can have off-by-one bugs, and
those are ideal candidates for E&C, and there are many other completely
valid uses of E&C.
IMO, where E&C shines is where a bug is painfully difficult and time
consuming to reproduce - once I am there I don't want to have to shutdown
the app to make an edit, especially when a simple minor edit will correct
the problem.
All modern debuggers provide the means of modifying the application data.
Conceptually this is no different then modifying the code that is being
executed - from the perspective of the the CPU code is data that is
interpreted as CPU instructions. By following your logic the editing of data
should also be disallowed and for the same reason (especially since many
applications are data driven) - the bug could just as likely be in the data
as in the code operating on the data.
BTW, trial-and-error is recognized as a technique that is part of the
scientific method - it is also known as experimentation. By itself it is not
evil, it is the misuse of the technique that is the problem. You even admit
to using it yourself for xpath queries!
Cheers,
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0dokz2j4ahwa003@msnews.microsoft.com...[color=blue]
> Devin wrote:
>[color=green]
>> Nearly any feature can be abused, or misused.[/color]
>
> True, however you forget an important step. I assume you're a developer,
> what else would you do reading this newsgroup ;). A developer sometimes
> has
> to develop GUIs. Now, the best thing that can be done is to help the user
> as
> much as possible so that the user makes the least amount of mistakes,
> which
> results in the highest amount of succesful work. The point is thus to
> disallow things which can result in failure, so you add checks, disable
> controls on a given state etc. etc.
>
> A developer is also a user, a user of a development environment and
> computer
> language. No matter what, it's best that the developer makes the least
> amounts of mistakes so the success rate is high. Giving a tool like E&C to
> developers, makes it very easy to alter code inside the debugger until the
> results are what is expected. This typical behavior is called 'Trial and
> Error'.
>
> What's way more efficient is to take a step back and actually analyse what
> you've written, think through what the code should look like and compare
> that
> with the code what was written. No trial and error, but structural
> software
> engineering. People who develop planes don't have edit and continue, as
> they
> arent able to alter a flying plane to fix a bug. Software engineers
> sometimes
> seem to think that what they write is not that mission critical.
>
> However this has been beaten to death for a loooooong time now. I can only
> advice people what I've learned during the past 11 I do serious,
> professional
> software development: learn to debug with analysis of the code written,
> the
> algorithms to write. Debugging is hard, it's a science. However I firmly
> believe that if a developer is forced to use a debugger like the gdb
> commandline debugger, he/she will learn soon enough that stepping through
> 500
> lines of code just to reach the lines where the error is originated is not
> helping, and neither will altering code on the fly 'to see if this works'.
>
> The only times I feel the need for E&C is when I need to use XPath queries
> and I have an error in them. It's pure trial and error, and restarting the
> app is then time consuming. It's however not the lack of E&C that makes it
> time consuming. It's the lack of understanding of XPath on my side that
> makes
> it time consuming. I also could have setup a set of simple tests to see
> which
> query would do the trick for example, read more documentation etc. etc.
> Without E&C you are forced to do that, but at the same time also learn
> things
> along the way. With E&C you can hack around till it works and move on,
> with
> the risk of running into the same error very likely.
>
> I've written a piece about E&C some time ago and why it is bad. I can tell
> you, being anti-E&C is not making you a lot of friends. Which I find
> rather
> strange, as if people don't want to learn how to write proper software!
> http://weblogs.asp.net/fbouma/archiv.../01/22211.aspx
>
> Frans.
>[color=green]
>>
>> "Richard Blewett [DevelopMentor]" wrote:
>>[color=darkred]
>> > The point I was making in 2 wasn't about bad programmers it was about
>> > inexperienced programmers. I don't think E&C teaches people good
>> > programming practice, although it is a very useful tool in the right
>> > hands.
>> >
>> > Regards
>> >
>> > Richard Blewett - DevelopMentor
>> > http://staff.develop.com/richardb/weblog
>> >
>> > > 2) It is a dangerous tool in the hands of inexperenced developers
>> > in
>> > that they will keep hacking around in a function in the debugger until
>> > it gets the result they want.
>> >
>> > I don't see this as being a problem with E&C. Bad programmers will
>> > write bad code. E&C helps (good & bad) programmers write code faster.
>> > Therefore, E&C will help bad programmers to write bad code faster. But
>> > it
>> > also helps good programmers write good code faster.
>> >
>> >
>> >
>> >[/color][/color]
>
>
>
> --
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET Blog: http://weblogs.asp.net/fbouma
> Microsoft C# MVP[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0dokza54lk2x004@msnews.microsoft.com...[color=blue]
> David Levine wrote:
>[color=green]
>> For the projects I work on it will be a godsend. It may take up to 10
>> minutes to compile, launch, and get back to where I was in the debugger
>> when I realized I needed to write ( someBool == true ) instead of (
>> someBool == false).
>>
>> Like all tools, it can be abused - I don't find that to be a compelling
>> enough reason to not have the feature.[/color]
>
> My question then to you is: if it takes 10 minutes to compile, why hasn't
> anyone asked why there are so many projects in 1 solution and why you
> didn't
> use TDD? I.e.: write the test first, then the implementation of your
> routine,
> then run the test, see if the routine fails the test or not.[/color]
How on earth do you know if it had a unit test or not? You are also assuming
that a simple unit test is sufficient to test all aspects of an app - it
isn't. Further, a unit test is also more code that has its own bugs and
failures. And don't be mislead by the simple example I gave - it was
illustrative, not defnitive; there are many problems that occur that are
relatively trivial to diagnose and fix once the problem becomes known, but
will only occur in a given context that is extremely difficult to reproduce.
Further, don't make any assumptions about what has and has not been
discussed, tried, rejected, etc.
[color=blue]
>
> This is why E&C will not help you: the compile time of your solution will
> still be 10 minutes. Step back and change! Chop up the solution into
> smaller
> solutions. You don't work on 100 projects at teh same time, probably only
> 1.[/color]
You have no idea of any of the systems I work on, the solutions and their
projects, or the environment they run in. If you want to try to dictate the
one-true-method of writing code, organizing projects, etc. then feel free to
try it, but don't be surprised if this arrogant attitude generates a lot of
backlash.
[color=blue]
>
> The fun thing is: with the TDD approach, you already have your test and
> you
> keep it. So you can always check if what you altered failed some tests and
> the TESTS are the representation of the specification you have to
> implement.[/color]
Yes, we know. We use it as *one* of our tools.
[color=blue]
> It might sound odd or old fashioned, but software development is not
> something about ad-hoc code hammering. It's about crafting code to
> represent
> functionality and data-structures. That takes time and skills and above
> all a
> plan. Now, why is it that in the rest of the engineering business the plan
> is
> the leading aspect of a project and everything is tested if it complies to
> the plan, but in software land it appears to be something which can be
> accomplished in a trial and error way inside a debugger 'till it works'. I
> hope boeing never implements E&C on their products so their engineers can
> try
> to 'fix' problems when the plane malfunctions at 30,000 feet.
>[/color]
I see....I've been architecting, designing and implementing systems for a
long time myself, all the way from circuit boards to panels to motor control
centers and more; and for more than the past decade, to writing device
drivers and application software. I should have asked you how to do it a
long time ago....I obviously have no clue what constitutes good engineering
practices.
You have a hectoring, accusatory style that is very offputting, you should
tone it down a notch. | | | | re: C# is getting Edit and Continue in Visual Studio 2005
David Levine wrote:[color=blue]
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
> news:xn0dokza54lk2x004@msnews.microsoft.com...[color=green]
> > David Levine wrote:
> >[color=darkred]
> >> For the projects I work on it will be a godsend. It may take up to 10
> >> minutes to compile, launch, and get back to where I was in the debugger
> >> when I realized I needed to write ( someBool == true ) instead of (
> >> someBool == false).
> >> Like all tools, it can be abused - I don't find that to be a compelling
> >> enough reason to not have the feature.[/color]
> >
> > My question then to you is: if it takes 10 minutes to compile, why hasn't
> > anyone asked why there are so many projects in 1 solution and why you
> > didn't
> > use TDD? I.e.: write the test first, then the implementation of your
> > routine,
> > then run the test, see if the routine fails the test or not.[/color]
>
> How on earth do you know if it had a unit test or not? You are also
> assuming that a simple unit test is sufficient to test all aspects of an
> app - it isn't.[/color]
It isn't? Ok, gui stuff aside, the rest can and should be unit-tested. That
aside, your 10minute compile problem is not going away with E&C. You really
should address that.
[color=blue]
> Further, a unit test is also more code that has its own
> bugs and failures. And don't be mislead by the simple example I gave - it
> was illustrative, not defnitive; there are many problems that occur that
> are relatively trivial to diagnose and fix once the problem becomes known,
> but will only occur in a given context that is extremely difficult to
> reproduce.[/color]
Weird, I never run into these and believe me, the code I write has a lot of
layers on top of eachother.
[color=blue]
> Further, don't make any assumptions about what has and has not been
> discussed, tried, rejected, etc.[/color]
errr, I was trying to help. Apparently you don't want to be helped. You
describe a problem, that you need a debugger feature to circumvent a 10minute
compile problem. I try to help you with that problem and I get "dont make
assumptions this" and "how on earth do you know that". I'm sorry David, but
if you don't want me to help you, that's fine, just say so and I can spend my
time elsewhere.
[color=blue][color=green]
> > This is why E&C will not help you: the compile time of your solution will
> > still be 10 minutes. Step back and change! Chop up the solution into
> > smaller solutions. You don't work on 100 projects at teh same time,
> > probably only 1.[/color]
>
> You have no idea of any of the systems I work on, the solutions and their
> projects, or the environment they run in. If you want to try to dictate the
> one-true-method of writing code, organizing projects, etc. then feel free
> to try it, but don't be surprised if this arrogant attitude generates a lot
> of backlash.[/color]
WTF?! Who's arrogant here!?
I was just trying to explain that there might be a solution to your problem.
And what do I get? I'm arrogant. David: good luck finding a solution to your
problem, I truly hope someone else who tries to help you is not slapped in
the face with "your arrogant attitude". Geezz...
Frans. | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0dokza54lk2x004@msnews.microsoft.com...
[color=blue]
> My question then to you is: if it takes 10 minutes to compile, why hasn't
> anyone asked why there are so many projects in 1 solution and why you[/color]
didn't[color=blue]
> use TDD? I.e.: write the test first, then the implementation of your[/color]
routine,[color=blue]
> then run the test, see if the routine fails the test or not.
>[/color]
I'm sure you were trying to be helpful Frans, and I agree with many of your
points, if not all of them. However, your message is coming across as
patronizing and pedantic.
To whit, count the number of times that your message includes the word
'you', including the implicit 'you' but excluding 'your'.
[color=blue]
> This is why E&C will not help you: the compile time of your solution will
> still be 10 minutes. Step back and change! Chop up the solution into[/color]
smaller[color=blue]
> solutions. You don't work on 100 projects at teh same time, probably only[/color]
1.[color=blue]
> This means that only 1 project has to be recompiled, or a couple. There[/color]
are[color=blue]
> build tools which do this for you. Command line builds with simple nmake
> scripts are way faster than building in vs.net. Also with smaller[/color]
solutions,[color=blue]
> debugging/building is faster and running tests/altering code/ running[/color]
tests[color=blue]
> is also faster.
>
> The fun thing is: with the TDD approach, you already have your test and[/color]
you[color=blue]
> keep it. So you can always check if what you altered failed some tests and
> the TESTS are the representation of the specification you have to[/color]
implement.
[color=blue]
>[/color]
Respectfully, once again, I agree with many of your points. In my TDD work,
I've found that I need E&C far less. However, I agree with David that I
find it handy. For example, let's say I write my test and the write my
code, and run my test. Every now and then, it fails. I place a breakpoint
in the unit test code just before the call that I suspect is breaking and
run again. The debugger stops and I enter my code. I find my logic error,
fix it, continue, and the test passes.
I had made a mistake. That's all. So I'm human... sue me.
E&C will help those of us who type quickly, program professionally, use
agile methods, and need to get it done.
It will also help inexperienced programmers do a poor job. So what. I'm
way past trying to save people from their own mistakes.
To me, programming is an art. Anything that removes restrictions on the
canvas is welcome, AFAIAC. I do abstract. Some folks paint by numbers.
The world is big enough for both.
On the other hand, while I agree with your points, I must agree also with
David that your tone, in this particular message, is condescending at best.
--- Nick | | | | re: C# is getting Edit and Continue in Visual Studio 2005
>> >[color=blue][color=green][color=darkred]
>> > My question then to you is: if it takes 10 minutes to compile, why
>> > hasn't
>> > anyone asked why there are so many projects in 1 solution and why you
>> > didn't
>> > use TDD? I.e.: write the test first, then the implementation of your
>> > routine,
>> > then run the test, see if the routine fails the test or not.[/color]
>>
>> How on earth do you know if it had a unit test or not? You are also
>> assuming that a simple unit test is sufficient to test all aspects of an
>> app - it isn't.[/color]
>
> It isn't? Ok, gui stuff aside, the rest can and should be unit-tested.[/color]
Unit tests are all well and good, but they do not solve all problems, and
there are many types of testing that unit testing does not begin to address.
Sometimes all that the unit test does is validate your own misconceptions
about the system. There are integration tests and systems test that need to
be performed and these cannot be performed in isolation.
There are also tests that require a different environment then is present
during the unit test, and duplicating this environment is extremely
difficult. And just so you know, we have hundreds of unit tests built into
the project, and they are all run as part of our automated build process.
And to your original complaint...yes, the team got together and discussed
the situation and we decided that it wasn't worth the downside to break up
the solution into a number of smaller solutions; we decided to live with the
long edit/compile/debug cycles and we would look at doing it differently on
the next project. There are problems when you break up a big solution into
numerous small solutions.
In addition, simply doing a compile doesn't take all that long when all that
changes is one project - anywhere from 2 minutes for a minor edit (such as
an E&C would do) to 10-15 minutes, depending on what needs to be built. It
is usually the time it takes to log in to the server, download the latest
bits from the server, download the project that was open, and get to the
point in the session where the problem occurred, that consumes the majority
of the time.
[color=blue]
> That
> aside, your 10minute compile problem is not going away with E&C. You
> really
> should address that.[/color]
You keep throwing the term "you" around - that makes it personal, and for no
good reason. You assumed that the 10 minutes is solely because of the
compile time - I never said it was solely due to compiling. And you are also
assuming that this was "the" problem that I thought E&C would fix. All I
said it would help with that particular irritation.
[color=blue]
>[color=green]
>> Further, a unit test is also more code that has its own
>> bugs and failures. And don't be mislead by the simple example I gave -
>> it
>> was illustrative, not defnitive; there are many problems that occur that
>> are relatively trivial to diagnose and fix once the problem becomes
>> known,
>> but will only occur in a given context that is extremely difficult to
>> reproduce.[/color]
>
> Weird, I never run into these and believe me, the code I write has a lot
> of
> layers on top of eachother.[/color]
Then you are fortunate.
One example: we do a lot of complex installation code out of custom actions.
The environment that the code is executing in at that time is very different
then the environment that is present under a debugger or out of the
application. Application base paths are different, the appdomain is
configured per the MSI host, and oh-by-the-way, if you are doing an
uninstall/install (otherwise known as an upgrade) the MSI host does not
unload the appdomain used for the uninstall-time custom action before
calling the install-time custom action. This means that assemblies do not
get unloaded, types do not get unloaded, etc. which completely changes the
operating environment of the code. When we write a unit test all it does is
validate the routine as per the environment that exists at the time the unit
test is run, which may be completely different than the environment it is in
at the time the MSI is installed. And this is just one example where a
simple unit test does not fully test a routine.
Unit tests are great when the functionality is entirely self-contained, and
IMO its usefullness diminishes as the amount of interaction with other
components of the system increases. It also decreases in usefulness as the
complexity of the configuration, setup, or complexity of the mock objects
increases. All code has bugs, including the test code. At some point the
complexity of the test negates the usefulness of the results as the
reliability of the result degrades.
There are other examples where unit tests aren't useful.
[color=blue]
>[color=green]
>> Further, don't make any assumptions about what has and has not been
>> discussed, tried, rejected, etc.[/color]
>
> errr, I was trying to help. Apparently you don't want to be helped. You
> describe a problem, that you need a debugger feature to circumvent a
> 10minute
> compile problem. I try to help you with that problem and I get "dont make
> assumptions this" and "how on earth do you know that".[/color]
Um, errr, I'm sure you really believe you mean well, but it comes across as
condescending and nasty.
[color=blue]
> I'm sorry David, but
> if you don't want me to help you, that's fine, just say so and I can spend
> my
> time elsewhere.[/color]
I'm sure you have something of value to contribute but the way you word
things and the approach you take is needlessly confrontational. I've had
many discussions up here and I've never had this experience with anyone
else.
[color=blue]
>[color=green][color=darkred]
>> > This is why E&C will not help you: the compile time of your solution
>> > will
>> > still be 10 minutes. Step back and change! Chop up the solution into
>> > smaller solutions. You don't work on 100 projects at teh same time,
>> > probably only 1.[/color]
>>
>> You have no idea of any of the systems I work on, the solutions and their
>> projects, or the environment they run in. If you want to try to dictate
>> the
>> one-true-method of writing code, organizing projects, etc. then feel free
>> to try it, but don't be surprised if this arrogant attitude generates a
>> lot
>> of backlash.[/color]
>
> WTF?! Who's arrogant here!?[/color]
You're posts here are. You made an enormous number of assumptions about the
solution, the projects, why it took 10 minutes to get back to a particular
point in a debugging session, if it had unit tests, and the environment it
was running in, my background, and engineering practices in general. You
then compounded this by making additional assumptions about the real cause
of the problem, it's solution, and its implementation. You then worded your
message in such a way that it was imperative, accusatory, superior, and
self-righteous (and note that I am categorizing what you write, not you
personally).
I not only support TDD and unit testing, I am doing a presentation on it to
my company! Yet you have a way of expressing yourself that makes me want to
disagree with your statements even when I agree with them. As I said
earlier, tone it down a notch.
Also, the analogy you used about how Boeing should not use E&C on planes is
flawed. There are a lot of dead test pilots who probably wished the plane
*did* have E&C (or pray&land). Upfront engineering minimizes flaws but it
does not eliminate them.
| | | | re: C# is getting Edit and Continue in Visual Studio 2005
Frans Bouma [C# MVP] wrote:[color=blue]
> My question then to you is: if it takes 10 minutes to compile,[/color]
He never said he had a 10 minute compile. His actual quote was :
"10 minutes to compile, launch, and get back to where I was"
I can easily imagine a 1 minute compile followed by a 9 minute setup to get
back to the situation of the error.
--
Truth,
James Curran [erstwhile-MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com | | | | re: C# is getting Edit and Continue in Visual Studio 2005
David Levine wrote:[color=blue][color=green][color=darkred]
> >> > My question then to you is: if it takes 10 minutes to compile, why
> >> > hasn't
> >> > anyone asked why there are so many projects in 1 solution and why you
> >> > didn't
> >> > use TDD? I.e.: write the test first, then the implementation of your
> >> > routine,
> >> > then run the test, see if the routine fails the test or not.
> > >
> >> How on earth do you know if it had a unit test or not? You are also
> >> assuming that a simple unit test is sufficient to test all aspects of an
> >> app - it isn't.[/color]
> >
> > It isn't? Ok, gui stuff aside, the rest can and should be unit-tested.[/color]
>
> Unit tests are all well and good, but they do not solve all problems, and
> there are many types of testing that unit testing does not begin to
> address. Sometimes all that the unit test does is validate your own
> misconceptions about the system. There are integration tests and systems
> test that need to be performed and these cannot be performed in isolation.[/color]
first: I'm not a native english speaker, so if my sentences are formulated
wrong/badly, I'm sorry, but it's not my first language.
second 'you' and 'your' in my sentences are mostly used as a 'general' term,
I also could have used 'one'. Dutch has a word for this, English doesn't
afaik.
true, if your tests are flawed, it's not going to bring you anything, better
yet: it's worse than not having them.
[color=blue]
> There are also tests that require a different environment then is present
> during the unit test, and duplicating this environment is extremely
> difficult. And just so you know, we have hundreds of unit tests built into
> the project, and they are all run as part of our automated build process.[/color]
ok, but I didn't know that, still you posted a problem as an argument in
favor of E&C. So all I read was: "I have this 10 minute period" (I admit, I
misread the sentence, it was compile + setup time, however it doesn't matter
much for the argument IMHO) and believe me, you're not the first with that
argument in favor of E&C. (this subject has been beaten to death in the
whidbey newsgroups) Most of the time when someone came with that argument, it
turned out their methods of software development in general weren't efficient
enough.
I always come with the Operating System development argument: it takes 7 to
8 hours to build windows XP if I'm not mistaken. No developer can test
his/her changes with such a long build cycle, so they use different
approaches to the problem: it's fixing the problem by the root of the cause,
not with a fix for the sympthom.
[color=blue]
> And to your original complaint...yes, the team got together and discussed
> the situation and we decided that it wasn't worth the downside to break up
> the solution into a number of smaller solutions; we decided to live with
> the long edit/compile/debug cycles and we would look at doing it
> differently on the next project. There are problems when you break up a
> big solution into numerous small solutions.[/color]
It wasn't a complaint, just an advice. Remember: I don't have a problem, you
and your team have. So it's not me who complaints about something, you did
(and rightfully so, 10 minutes compile-setup time to get something tested is
unworkable).
There are problems to chop up a big solution into smaller ones, however I'm
not sure if those would be bigger than the big problem you have now. It will
only get worse in the future: what if a bug shows up when the application is
in production? That would be horrible to debug. E&C will not help you with a
lot of bugs either, as what it can do for you at runtime is limited (i.e.:
you can't add/alter all possible constructs, just a small subset)
[color=blue][color=green]
> > That aside, your 10minute compile problem is not going away with E&C. You
> > really should address that.[/color]
>
> You keep throwing the term "you" around - that makes it personal, and for
> no good reason.[/color]
Why is that a bad thing? You posted the problem, so why should I address it
to someone else? Don't think I belittled you or anything, we see a lot of 'I
have a big solution and vs.net falls apart' problems here, so you're not
alone. But again, I just wanted to help. If you feel offended by me helping
you, I'll step back and leave you alone and your big project.
[color=blue]
> You assumed that the 10 minutes is solely because of the
> compile time - I never said it was solely due to compiling. And you are
> also assuming that this was "the" problem that I thought E&C would fix. All
> I said it would help with that particular irritation.[/color]
... and I said it might not help you in that.
[color=blue][color=green]
> > Weird, I never run into these and believe me, the code I write has a lot
> > of layers on top of eachother.[/color]
>
> Then you are fortunate.[/color]
... or perhaps I organize better? :) Or do you think I work on mickey mouse
projects?
[color=blue]
> Unit tests are great when the functionality is entirely self-contained, and
> IMO its usefullness diminishes as the amount of interaction with other
> components of the system increases. It also decreases in usefulness as the
> complexity of the configuration, setup, or complexity of the mock objects
> increases. All code has bugs, including the test code. At some point the
> complexity of the test negates the usefulness of the results as the
> reliability of the result degrades.
>
> There are other examples where unit tests aren't useful.[/color]
sure, however I used them as an argument to test routines which contain
bugs. You see, it starts with silly things like pre-post conditions. If a
given routine has a given set of pre/post conditions and these succeed, your
routine does what it should do and you can move on. This can easily be done
with unittests. The fun thing is: if all pre/post conditions of all routines
are tested, (even by hand, doesn't matter) your system is theoretically
correct. Then it comes down to: is the design correct and does it fail
because of unforeseen circumstances. At the same time you then also enter the
area where E&C is likely not going to help. I mean: you can attach a debugger
at any time to a running system, but also you can add trace listeners to a
running system. Monitoring is half the debugging.
My argument was: too little is done to prevent routines which are buggy
(i.e.: their pre/post conditions aren't met) to enter a system, which later
on causes problems.
[color=blue][color=green][color=darkred]
> >> Further, don't make any assumptions about what has and has not been
> >> discussed, tried, rejected, etc.[/color]
> >
> > errr, I was trying to help. Apparently you don't want to be helped. You
> > describe a problem, that you need a debugger feature to circumvent a
> > 10minute
> > compile problem. I try to help you with that problem and I get "dont make
> > assumptions this" and "how on earth do you know that".[/color]
>
> Um, errr, I'm sure you really believe you mean well, but it comes across as
> condescending and nasty.[/color]
I don't see why, I just try to help you with a problem. You apparently see
that as condescending, which I find odd, because I'm just trying to help and
what do I win with condescending you? I invest time to answer YOU. Believe
me, I have a lot of work on my plate every day, so I can spend my time better
than simply condescending people I don't know.
[color=blue][color=green]
> > I'm sorry David, but
> > if you don't want me to help you, that's fine, just say so and I can
> > spend my
> > time elsewhere.[/color]
>
> I'm sure you have something of value to contribute but the way you word
> things and the approach you take is needlessly confrontational. I've had
> many discussions up here and I've never had this experience with anyone
> else.[/color]
Perhaps you MADE it personal and you assumed I wrote it as if I knew it all
and am here to tell you how it's done because you assumed I thought you were
stupid. David, if I think someone is stupid I don't even bother replying.
[color=blue][color=green]
> > WTF?! Who's arrogant here!?[/color]
>
> You're posts here are. You made an enormous number of assumptions about the
> solution, the projects, why it took 10 minutes to get back to a particular
> point in a debugging session, if it had unit tests, and the environment it
> was running in, my background, and engineering practices in general.[/color]
Well, there wasn't a lot of info, was there, just the problem, which was
used as an argument for E&C. I didn't say anything about your background nor
engineering practises, I just used a general metaphore to explain why I think
in general people should pay more attention to common practises than to fixes
for a symphtom: fix the cause, not the result of the problem.
As I said earlier, 'you' can mean you David but also the people in general,
afaik. Again, I'm not a native english speaker. But I stop now, as I don't
have time to fight a silly battle over what I meant and wrote and how my tone
was and how I apparently condescend people, if all I want to do is trying to
help.
Frans.
--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP | | | | re: C# is getting Edit and Continue in Visual Studio 2005
>[color=blue]
> first: I'm not a native english speaker, so if my sentences are formulated
> wrong/badly, I'm sorry, but it's not my first language.
>
> second 'you' and 'your' in my sentences are mostly used as a 'general'
> term,
> I also could have used 'one'. Dutch has a word for this, English doesn't
> afaik.[/color]
Ok. I'll accept that you don't mean any of this personally, but I will point
out to you when you make statements that are unnecessarily harsh and/or
personal, and we'll let it go at that. I don't have the time, inclination,
or desire to get into a flame war over a trivial incident.
[color=blue]
>
> ok, but I didn't know that, still you posted a problem as an argument in
> favor of E&C. So all I read was: "I have this 10 minute period" (I admit,
> I
> misread the sentence, it was compile + setup time, however it doesn't
> matter
> much for the argument IMHO) and believe me, you're not the first with that
> argument in favor of E&C.[/color]
I disagree. I think it matters a great deal. It especially matters in cases
where the bug is timing related, especially in a heavily multithreaded
environment with threads at different levels of priorities. It may take
hours, or even days, to reproduce a specific chain of seemingly random
events that gets you to the point where a bug manifests itself. Some
problems are extremely difficult to analyze, predict, and reproduce.
Thankfully, this is the exception rather then the rule for most of the C#
code I've worked on to date. The ability to E&C under these conditions is
extremely valuable.
[color=blue]
> (this subject has been beaten to death in the
> whidbey newsgroups) Most of the time when someone came with that argument,
> it
> turned out their methods of software development in general weren't
> efficient
> enough.[/color]
E&C is one more tool in a suite of tools. One could also argue that
calculators encourages sloppy thinking because we don't have to do simple
math, but I don't think you'll get any support for arguing that calculators
shouldn't be used.
[color=blue]
>
> I always come with the Operating System development argument: it takes 7
> to
> 8 hours to build windows XP if I'm not mistaken. No developer can test
> his/her changes with such a long build cycle, so they use different
> approaches to the problem: it's fixing the problem by the root of the
> cause,
> not with a fix for the sympthom.[/color]
"fix the problem, not the symptom" is a mantra I thought I had invented. You
are preaching to the choir.
[color=blue]
> It wasn't a complaint, just an advice. Remember: I don't have a problem,
> you
> and your team have. So it's not me who complaints about something, you did
> (and rightfully so, 10 minutes compile-setup time to get something tested
> is
> unworkable).[/color]
Our team does not have a problem. I want tools that make my life as a
developer more efficient and enjoyable - E&C is one such tool. I've also
done debugging by writing a number to a monochrome screen buffer to indicate
a routine that the code was in. I use the tools I have available.
[color=blue]
>
> There are problems to chop up a big solution into smaller ones, however
> I'm
> not sure if those would be bigger than the big problem you have now. It
> will
> only get worse in the future: what if a bug shows up when the application
> is
> in production? That would be horrible to debug. E&C will not help you with
> a
> lot of bugs either, as what it can do for you at runtime is limited (i.e.:
> you can't add/alter all possible constructs, just a small subset)[/color]
Bugs always show up in production code. There is no such thing as perfect
code, there is only code in which a problem has not yet manifested itself.
[color=blue]
> Why is that a bad thing? You posted the problem, so why should I address
> it
> to someone else? Don't think I belittled you or anything, we see a lot of
> 'I
> have a big solution and vs.net falls apart' problems here, so you're not
> alone. But again, I just wanted to help. If you feel offended by me
> helping
> you, I'll step back and leave you alone and your big project.[/color]
If you have specific advice on how large solutions should be organized then
present them and provide this benefit to the entire development community.
Write a whitepaper and the ideal method of organizing a large project. I
assure you people will listen (and criticize where criticism is warranted).
[color=blue]
> You see, it starts with silly things like pre-post conditions. If a
> given routine has a given set of pre/post conditions and these succeed,
> your
> routine does what it should do and you can move on. This can easily be
> done
> with unittests. The fun thing is: if all pre/post conditions of all
> routines
> are tested, (even by hand, doesn't matter) your system is theoretically
> correct.[/color]
I look at a routine as having three essential components; data in, process
logic, and data out. Are you saying that the unit test examines the data in,
data out (or object state) and these constitute the pre/post conditions? If
so, I agree.
There are problems with such a simple testing/verification model which I
consider to be one of the weaknesses of unit testing.
Unit tests work really well when all the logic is internal, and it decreases
in usefulness as the number of external objects it uses for its logic
increases - I look at it as a spectrum of reliability. Quite often the
behavior of external objects (libraries) is different then our initial
understanding of them. The fidelity of the behavior of the mock object used
to simulate the real object's behavior determines the reliability of the
resulting test. If the mock object actually behaves differently then the
real object then all the unit tests may pass and your system may be
theoretically correct but pragmatically incorrect; this is very bad when the
differences in behavior are subtle or occur only when the system is under
stress.
I also don't usually see good unit tests for throwing and handling
exceptions, and I especially don't see good integration tests for simulating
exceptions when the different sections are tested as a unit.
I agree with the concepts of unit testing and TDD in general even (though it
has the feel of being the latest fad). However, I am concerned that an
over-reliance on unit testing, especially incomplete or incorrect testing,
will provide one with the illusion of correctness instead of its reality.
[color=blue]
> Then it comes down to: is the design correct and does it fail
> because of unforeseen circumstances.[/color]
[color=blue]
> At the same time you then also enter the
> area where E&C is likely not going to help. I mean: you can attach a
> debugger
> at any time to a running system, but also you can add trace listeners to a
> running system. Monitoring is half the debugging.[/color]
That is correct - examining the data produced by a running system is an
enormous aid and quite often is the only debugging tool available
[color=blue]
>
> My argument was: too little is done to prevent routines which are buggy
> (i.e.: their pre/post conditions aren't met) to enter a system, which
> later
> on causes problems.
>[/color]
Yes I agree.
| | | | re: C# is getting Edit and Continue in Visual Studio 2005
If you read the thread you'd have seen why I said I had mixed feelings about it - but basically because in inexperienced hands if can be a tool for hacking a method until it appears to work rather than standing back and working out what is going wrong. So I'm pleased its coming but I was burned on projects with E&C with inexperienced developers in the past.
And you are quite welcome to state what the hell does it matter if I have mixed feelings and frankly, if you're not interested - it doesn't matter at all :-)
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
Ok. So why do you have mixed feelings about it.
I am itching, of course, to say "what the hell does it matter to anyone
here if you have mixed or isolated feelings about it, but, I am polite,
you know. This being a public forum etc. :)!
To get back to the point, you are pleased and have mixed feelings abt
edit and continue so, what gives?:) | | | | re: C# is getting Edit and Continue in Visual Studio 2005
At this point, it would probably just confuse the heck of me. I do fine
without it now.
--
William Stacey, MVP
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:e8tM$eQtEHA.2532@TK2MSFTNGP10.phx.gbl...[color=blue]
> If you read the thread you'd have seen why I said I had mixed feelings[/color]
about it - but basically because in inexperienced hands if can be a tool for
hacking a method until it appears to work rather than standing back and
working out what is going wrong. So I'm pleased its coming but I was burned
on projects with E&C with inexperienced developers in the past.[color=blue]
>
> And you are quite welcome to state what the hell does it matter if I have[/color]
mixed feelings and frankly, if you're not interested - it doesn't matter at
all :-)[color=blue]
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
> Ok. So why do you have mixed feelings about it.
>
> I am itching, of course, to say "what the hell does it matter to anyone
> here if you have mixed or isolated feelings about it, but, I am polite,
> you know. This being a public forum etc. :)!
>
> To get back to the point, you are pleased and have mixed feelings abt
> edit and continue so, what gives?:)
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
news:e8tM$eQtEHA.2532@TK2MSFTNGP10.phx.gbl...[color=blue]
> If you read the thread you'd have seen why I said I had mixed feelings[/color]
about it - but basically because in inexperienced hands if can be a tool for
hacking a method until it appears to work rather than standing back and
working out what is going wrong. So I'm pleased its coming but I was burned
on projects with E&C with inexperienced developers in the past.[color=blue]
>[/color]
Richard,
Sounds as if you were burned on projects with inexperienced developers in
the past.
E&C likely had nothing to do with the problems that you experienced -
eliminating E&C leaves you with inexperienced developers.
regards
roy fine
[color=blue]
> And you are quite welcome to state what the hell does it matter if I have[/color]
mixed feelings and frankly, if you're not interested - it doesn't matter at
all :-)[color=blue]
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
> Ok. So why do you have mixed feelings about it.
>
> I am itching, of course, to say "what the hell does it matter to anyone
> here if you have mixed or isolated feelings about it, but, I am polite,
> you know. This being a public forum etc. :)!
>
> To get back to the point, you are pleased and have mixed feelings abt
> edit and continue so, what gives?:)
>
>[/color] | | | | re: C# is getting Edit and Continue in Visual Studio 2005
Roy Fine wrote:
[color=blue]
>
> "Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
> news:e8tM$eQtEHA.2532@TK2MSFTNGP10.phx.gbl...[color=green]
> > If you read the thread you'd have seen why I said I had mixed feelings[/color]
> about it - but basically because in inexperienced hands if can be a tool for
> hacking a method until it appears to work rather than standing back and
> working out what is going wrong. So I'm pleased its coming but I was burned
> on projects with E&C with inexperienced developers in the past.[color=green]
> >[/color]
>
> Richard,
>
> Sounds as if you were burned on projects with inexperienced developers in
> the past.
>
> E&C likely had nothing to do with the problems that you experienced -
> eliminating E&C leaves you with inexperienced developers.[/color]
Yeah, but to use a rude metaphore: children with guns in their hands are lot
more dangerous than without guns in their hands.
Frans.
--
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP | | | | re: C# is getting Edit and Continue in Visual Studio 2005
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0dop5st468ra002@msnews.microsoft.com...[color=blue]
> Roy Fine wrote:
>[color=green]
> >
> > "Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:e8tM$eQtEHA.2532@TK2MSFTNGP10.phx.gbl...[color=darkred]
> > > If you read the thread you'd have seen why I said I had mixed feelings[/color]
> > about it - but basically because in inexperienced hands if can be a tool[/color][/color]
for[color=blue][color=green]
> > hacking a method until it appears to work rather than standing back and
> > working out what is going wrong. So I'm pleased its coming but I was[/color][/color]
burned[color=blue][color=green]
> > on projects with E&C with inexperienced developers in the past.[color=darkred]
> > >[/color]
> >
> > Richard,
> >
> > Sounds as if you were burned on projects with inexperienced developers[/color][/color]
in[color=blue][color=green]
> > the past.
> >
> > E&C likely had nothing to do with the problems that you experienced -
> > eliminating E&C leaves you with inexperienced developers.[/color]
>
> Yeah, but to use a rude metaphore: children with guns in their hands are[/color]
lot[color=blue]
> more dangerous than without guns in their hands.
>[/color]
The analogy does not work - whereas you can make a strong case that guns
serve no useful purpose to society at large - the same case is not so easy
when considering E&C. Developers can progress from the state of
inexperienced to experienced, and the E&C tool may provide benefit. And the
process of transitioning from one state to the next could easily be
facilitated with the E&C tool and a teacher or leader. Again, the same case
is not so easy when considering "children with guns".
And then to the second part: You are incorrect in classifying the scenario
as a metaphor. A metaphor would have been (for example) "chickens with
guns" or "dumber than a sack of rocks". Metaphors are figurative elements.
Applying anthropomorphic behavior in non-innate objects is always
metaphoric. Since the two are so very different (E&C for inexperienced
developers and children with guns), you may want to consider the simile
(when introducing a comparison of unlike things for dramatic impact)
regards
roy fine |  |
Similar C# / C Sharp bytes | | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,419 network members.
|
