Tom Dacon said:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should
have sprinkled some smileys around my comments to put across the notion
that I was aiming at irreverence rather than vitriol. In any case, I don't
agree with your responses, although I respect your right to hold them.
And,likewise, I don't agree with your responses, but you do have the right
to have them
As to edit-and-continue, surely you do deep-path inspection of your code
during testing, don't you? Isn't it a pain when you're deep in a debugging
session, hit a show-stopper, and have to exit the session, fix the bug,
and then reconstruct the whole testing scenario back down to that point
again before you can continue? Sometimes you can save the situation right
there
And you really think that test is trustworthy? Does changing code so thta it
works with the current state any indication that it is going to work with
other state? Does it pass the covering unit tests? Once you modify the
method your test run is tainted, IMHO, and its worthless to go on. You will
waste more time testing future parts that may break the next time around
because the fix didn't work.
Fixes should not be done on the fly. The errant code should be considered,
the cause of the code needs to be considered, then a fix devised, documented
if you do so, and applied. After that test coverage applied again. Simply
fixing something until you think it works and then moving on is not terribly
safe to my mind.
Again, this comes back to typos. The only bug you could realistically fix
would be a mistype in an SQL statement or xpath statement and E&C is like
using $100,000 whiteout to do so when you could fix the typewriter instead.
It really is the wrong thing to be focusing resources on, code authoring(not
the author, mind you) needs to be enhanced. IDE's simply do not provide
enough support for embedded langauges.
The greater evil is code edited in E&C mode so the user doesn't have to
break out of his debug session to fix a problem. I worry about seeing code
which was obviously formed out of the desire to stop debugging. I know many
people say they will go back and fix it, and even that they usually do, but
even if 5% of those occurances are not fixed the quality of the code as a
whole is going to drop substantially.
and proceed. Saves a lot of time. Of course it doesn't always work that
way, but every once in a while you gain from its presence. I missed
hearing that
Ok, the rare occasion happens where it comes in handy, all and good, except
waht did it cost? Did you maybe lose something that you would have used
every day for something that you might use once a week? A month? Does the
cost of such a feature justify its use?
the C# team has decided to do it - thanks for correcting me - but I'm
delighted to hear it. Try it some time, when you get it in a version of
VS.Net that supports it. Might change your mind. Myself, I'd make it an
IDE
I don't think I will, thank you. I have little need for it.
option, that you can turn off if it's causing you performance problems, so
if for some reason you need to load the whole world in your solution you
can avoid whatever difficulties its presence induces. Instead of loading
the whole world, though, why not try thorough testing of the lower-level
assemblies, to the point where you trust them (think NUnit and its
brethren), and then just reference them and use them as binaries from the
part of the code that you're currently working on?
I assume this is meant to address background compilation moreso than E&C. As
far as that goes, I don't know if VB offers a way to turn it off, I just
know it causes some trouble. Personally I don't think I really *need*
background compilation. Whidbey does an admirable job warning me of the
errors I make most frequently and I simply do not consider the compilation
time significant in most circumstances.
But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things.
I often see this in people who have never known anything other than a
single programming language, and therefore believe that the way it does
things is the only right way to do them. These are usually young
programmers, in the early stages of their careers, to whom exposure to
other ways of doing things hasn't yet given a wider perspective. I
wouldn't think you could get to be an MVP without being a rather
experienced developer, and unless C++ is the only language you've ever
known before C#, and unless you have had no experience in any other
development environments, I'd expect you to have a balanced viewpoint as
well. Do I misunderstand?
I saw it but I didn't have any comments.
As for my experiance, I certainly am not the most experianced person around
here and will not claim to be, although I am not alone in my opinion about
E&C by any means. Believe it or not, I've spent most of my career using VB,
I even used E&C for a year or so. But I eventually started looking at my
code and the code the greater community was creating and publishing, and it
became pretty clear that E&C had a noticable taint. People wrote for and in
E&C, instead of using it as a tool to fix the occasional minor mistake. I
even began to notice tutorials that taught people to write within E&C
itself.
E&C is generally used as a crutch first and as a tool second. That isn't
going to change.
I am forced to wonder what mollifying the masses really cost. E&C support
required modifications to the IDE, the debugger,the runtime, and probably to
the compilers. So, the CLR folks were forced to put in the piping to support
E&C, costing what? What was dropped from or never considered for the
debugger to find the time to implement its piece of E&C? The VB team put
together E&C support and delievered a product that I don't think evolved as
significantly as C# and C++/CLI did, what was left out to support E&C? The
C# team managed to wedge it in, but again, at what cost? All they've said so
far is no announced feature was dropped. However, there are still edges that
needed polishing, right down to features I use every ten minutes, like
refactorings. As best as I can tell, the end user is stuck with some runtime
code that exists to support E&C, even though they will never have a reason
to use it.
And all of this was done to provide a feature that basically either allows
people to write bad code quickly or to use the feature once in a while. Was
it worth it? Or was it added because VB6 developers were to stuck on the
idea to let it go?
