C# & VB-> General Questions

[Lee Alexander]

The opposite is also true though - people tend to assume that using the

debugger a lot and starting to run the code as quickly as possible will
boost their productivity.

Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.

and I was as productive as my colleagues who used IDEs.

How did you measure this?

I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc.

You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.

Personally I think code should be *so* simple that it's blatantly
obvious what each bit does.

Sounds good to me

Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. Yep.

I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

I'm sure you'll be able to cherry pick your *perfect* job

Regards
Lee

 

[Jon Skeet [C# MVP]]

Why? What's the exact difference you experience? There is no timeout in
debug mode that forces you to edit as quick as possible. You can sit down
and rethink/implement logic without time pressure even in debug mode.

No, but once you've got something which works for the particular bug
you've run across, there's not (IMO) the same impetus to mentally check
through all the other cases which might happen. If you're relying on
the debugger to show you what code does in one case, you're probably
not thinking about all the other cases. (Generic "you" there, btw - not
you in particular.)

This strongly depends on the developer.

Sure - but I think it's worth strong developers sacrificing a bit of
ease for the sake of not encouraging bad habits in weaker or less
experienced developers. (As Daniel mentioned, there's also the issue of
what else has been missed out due to the effort of including E&C.)

 

[Jon Skeet [C# MVP]]

That's an excellent summary of the key topic... probably the best summary
here.

I'm not "aligned" with any one, nor do I believe that all opponents of E&C
are immature developers who've only ever used C++. Your concern is a valid
one.

I do NOT believe that starting the debugger, and then writing code, is a
good idea. That's a hair-brained idea. On the other hand, I haven't met
anyone who does that. Just how many advocates of "write in the debugger"
have you met at conferences or SIGs or in your dev teams? Could it be that
the concern about coding in the debugger is an overreaction to the nutty
ideas of a tiny minority?

I happen to usually work with experienced developers. (In the company
I'm in now, I'm the most junior by over 10 years, and have been for
most of the time.)

However, I've seen plenty of code which suggests that people have been
writing code in the "try rather than think" mode.

Can E&C be misused? Yes, and we should warn folks about that. Tell them
that E&C is not a healthy way to originate code. However, just like I
believe Singletons can be misused, but that folks should only be warned, I
believe that E&C can be misused, and that a warning is all that should be
issued.

I think we just disagree about how often it'll be misused rather than
how often it'll be used correctly. Virtually everything else, we agree
about (although unit tests should generally build and run quickly
enough that E&C shouldn't cause much of a difference, IMO).

Gotta go now, but thanks for the non-patronising discussion. I think
this issue is one which leads to more assumptions about people than
almost any other (in development)

 

[Jon Skeet [C# MVP]]

Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.

I answered that earlier - in some cases (like a debugger) the pros
outweigh the cons. For E&C, I believe the cons outweigh the pros.

How did you measure this?

Code written, bugs fixed, bugs not created in the first place.
Informally, of course.

You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.

I can't say I've ever found it useful. Not that I'm trying to stop you,
of course

Sounds good to me

I'm sure you'll be able to cherry pick your *perfect* job

That would be lovely, but the market isn't quite that nice

Still, I've got an online C# test to do in a few minutes, so that
should be fun...

 

[Roy Fine]

Sam,



Maybe you and some of the others used it. In the German C# community there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.


Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.

EXCELLENT POINT ! Best point made in this thread.

roy fine

 

[Tom Dacon]

Nick, thanks for your comments.

I'm not going to dive into the middle of the E&C debate, although my
experience with it has been good, and I don't feel that the quality of my
code has suffered from its use. I think it's a case of knowing when to use
it, and when to back out and restructure the code if I see that it has
design faults or a poor implementation. The only problem I've had with it is
when I made a fix using E&C and then lost it in a crash of the IDE that
prevented me from saving the change. Psychologically, I felt that the fix
had been made, and sometimes have found that I failed to go back into the
source and reinsert the fix after bringing the project back up again. Other
than that occasional and irritating slipup on my part (and I personally take
full credit for the failing, rather than blaming E&C) I think it's a useful
tool, but just a tool like any other in our arsenals.

As to the new stuff in VB.Net for the next go-round, I'm seriously
considering referencing the My namespace in my C# code, just to get access
to some of the coding shortcuts. I'm not 100% sure that this would be a good
idea, it probably isn't, but I'm mulling it over.

On the 'fair and balanced' thing, I've been in this biz a hell of a long
time, and it seems that there's always a need for people to divide
themselves into the Thems and the Us's. In the old days it was the
engineering programmers versus the business programmers: Fortran and Cobol.
In the early days of Windows, it was the Unix programmers versus the Windows
programmers: X Window System versus the Windows API. In the early days of
the Mac, it was Pascal versus C, and of course it will always, it seems, be
Apple versus Microsoft. For a certain time, Sun and Scott McNealy were the
anti-Christ, and everyone else in the Unix world was against them. On
Windows, for a while it was C++ versus VB1-6, and now it's C# versus VB.Net.
Tires me out. I'd like for us to leave this kind of stuff behind us, and
take the opportunity to learn from each other. I've personally programmed
professionally - delivered a commercial product - in twelve or maybe
thirteen distinct programming languages over a long and varied career, and I
believe that I've learned something useful from all of them, and especially
from the experienced programmers I encountered in the process.

And I apologize to anyone who was offended by my gratuituous dig at the
Republicans in my original post. Just beeped out. Sorry.

Best regards,
Tom Dacon

 

[Tom Dacon]

Depends on the programmer. Good programmers will write good code with

EXCELLENT POINT ! Best point made in this thread.

roy fine

Indeed. I couldn't agree more.

Tom

 

[Peter N Roth]

edlin rules
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where
the
compile / link time can be minutes or longer. Most things can be used
badly
but does that mean we shouldn't have them if the pros outweigh the cons?
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind. While we're at it let's
cut
the debugger out as well. Heck let's go the whole hog and get rid of Dev
Studio, going back to trusty old notepad and cmd.

Regards
Lee

Jon

 

[Guest]

It's been an ineresting discussion to follow. Speaking from an end user's
point of view, I couldn't care less how sloppy the code is nor what form it's
in, I just want a simple interface for the enduser and an application that is
bug free. Maybe a bit more use of debuggers would help because there's a lot
of software out there that's not intuitive to use and is very buggy!

 

[Daniel O'Connell [C# MVP]]

Sam,



Maybe you and some of the others used it. In the German C# community
there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.

Don't apply a small subset of the population to the population as a whole.

Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.

I disagree. GOod programmers that use E&C badly will write bad code faster.
Good programmers that use E&C correctly will notice very little productivity
increase.

 

[Roy Fine]

Don't apply a small subset of the population to the population as a whole.


I disagree. GOod programmers that use E&C badly will write bad code faster.
Good programmers that use E&C correctly will notice very little productivity
increase.

Daniel, you are attempting to assert as fact something that you can neither
prove or disprove, when all the time you know it only as personal opinion.

you are close to becoming like the clock that once chimed 13 - it is a bogus
clock and now i distrust all times that i have received from it!

regards
roy fine

 

[Roy Fine]

The teams that built the IDE interfaces for C# and VB are different groups
of people. They implemented feature sets that are different in some
respects, based on their notions of what their developers would want. The VB
group apparently thought that the editor should show errors immediately,
while the code was being typed - it's more like VB6, and I must say that
that it's pretty handy, to boot. The C# group apparently thought that their
developers would be coming from C++, where the VS6 IDE gives them
essentially no real-time help. They probably thought that their developers
would disdain that kind of hand-holding. You know: "REAL programmers don't
need squigglies!"

BUT - VC++ 6 had Edit and Continue - I remember the great fanfare when it
was anounced.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/msdn_vc6ed_cont.asp

Consider this summary from the link:

<quote>
Hopefully, this article has provided you with valuable information that will
enable you to take the greatest advantage of the Edit and Continue
functionality of Visual C++ 6.0. One of the best aspects of Edit and
Continue is that almost any Visual C++ user can benefit from it, whether
they know the feature is revolutionary or not. The result should be
smoother, less interrupted, and generally more productive development. That
has certainly been proven true here at Microsoft, where we've received
e-mail from developers throughout the company thanking us for Edit and
Continue. But they're a quirky set, so let us know how you use Edit and
Continue and how it's changed your development the next time you see a
Visual C++ team member at a trade show or conference.
<quote>

regards
roy fine

 

[Daniel O'Connell [C# MVP]]

Daniel, you are attempting to assert as fact something that you can
neither
prove or disprove, when all the time you know it only as personal opinion.

you are close to becoming like the clock that once chimed 13 - it is a
bogus
clock and now i distrust all times that i have received from it!

And you have yet to post any point what so ever. Your posts run between Ad
Hominem attacks and empty "good going" responses.

Worse yet, *YOUR* response was
"EXCELLENT POINT ! Best point made in this thread."

In other words, his opinion was somehow a good one while my disagreeing one
was distrustworthy? Is it perhaps that you believe the earlier opinoin while
disagree with mine? Do you not see how self-serving your stance is here?

I'm sorry, you aren't here to participate in discussion or even listen, you
are entirely concerned with supporting something based on your own raw bias
instead of facts or even well formed arguments. All you are trying to do is
discredit everyone who disagree's with you by any means possible.

And that is disgusting.

 

[Tom Dacon]

So, Hareth, if you're still following this discussion, did you find out what
you wanted to know?

Any further questions?

Tom Dacon
Dacon Software Consulting

 

[Tom Dacon]

Hey, Daniel, let's call a truce on this. This is getting to the point where
it's no longer an invigorating exchange of ideas, and has stopped being
either illuminating or fun.

I'll use it and make what I think is good use of it, you're free to ignore
it even when it becomes available, and we let all these other folks make up
their own minds by trying it out and seeing whether it works for them.

Of all things, I don't like the idea of this community of developers making
decisions based on mere hearsay. Sure you've got strong opinions about what
you perceive as the lack of value of the feature, I've got my own ideas
about it that differ from yours. I'm happy to see everyone else make up
their own minds based on their own experiences, informed by the opinions
they've read about it here and, I hope, elsewhere.

How's that sound?

Tom Dacon
Dacon Software Consulting

 

[Jeff Louie]

Hi Tom... No problem. Looking at my recent post and all the obvious dumb
errors in them (still there) I wish there was an
EDIT_AND_CONTINUE_NEWS_READER_FOR_DUMB_POSTERS_LIKE_ME_WHO_HIT
_THE_SUBMIT_BUTTON_WITH_BRAIN_OFF

Regards,
Jeff

 

[Jon Skeet [C# MVP]]

It's been an ineresting discussion to follow. Speaking from an end
user's point of view, I couldn't care less how sloppy the code is nor
what form it's in, I just want a simple interface for the enduser and
an application that is bug free.

But the sloppier the code is, the harder it is to maintain and to find
bugs. Clean code is a means to an end, the end being a better
application with fewer bugs.

Maybe a bit more use of debuggers would help because there's a lot
of software out there that's not intuitive to use and is very buggy!

Or perhaps a bit more thinking at the design stage coupled with more
testing would help... randomly going into the debugger isn't going to
fix bugs. You've got to know they're there to start with.

 

[Jon Skeet [C# MVP]]

Hey, Daniel, let's call a truce on this. This is getting to the point where
it's no longer an invigorating exchange of ideas, and has stopped being
either illuminating or fun.

I'll use it and make what I think is good use of it, you're free to ignore
it even when it becomes available, and we let all these other folks make up
their own minds by trying it out and seeing whether it works for them.

Of all things, I don't like the idea of this community of developers making
decisions based on mere hearsay. Sure you've got strong opinions about what
you perceive as the lack of value of the feature, I've got my own ideas
about it that differ from yours. I'm happy to see everyone else make up
their own minds based on their own experiences, informed by the opinions
they've read about it here and, I hope, elsewhere.

How's that sound?

Lack of value of a feature is one thing - when a feature is downright
dangerous (as Daniel and I believe it is), that's a different matter.
It's fine for people who don't like the feature to ignore it - but
Daniel and I aren't so much worried for our own code as for the people
who *don't* ignore it, but who misuse it and write sloppy code which
possibly we'll have to end up working with.

I'll continue to recommend that people think very carefully before
using it...

 

[Tom Dacon]

Lack of value of a feature is one thing - when a feature is downright
dangerous (as Daniel and I believe it is), that's a different matter.
It's fine for people who don't like the feature to ignore it - but
Daniel and I aren't so much worried for our own code as for the people
who *don't* ignore it, but who misuse it and write sloppy code which
possibly we'll have to end up working with.

I'll continue to recommend that people think very carefully before
using it...

Jon, and Daniel, I'm pretty much done with this discussion, but as a final
comment I'll just say that if they're going to write sloppy code they'll do
it with or without E&C (interestingly, this is the other side of the coin
that a previous observation was engraved on). Personally, I've always found
that the best solutions to bad coding practices have been education and
mentorship. I fail to see that a prohibition against a single particular
feature of the development environment.addresses that core issue, but then
perhaps my experiences have been different from yours.

And there I said I wasn't going to keep going on this...human nature's a
funny thing, no?

Best regards,
Tom Dacon
Dacon Software Consulting

 

[Hareth]

Thanx for all the insight....I got the idea.....

I'm just surprised how far this post went.....I started WWIII, and I don't
even know which button I pressed!

Anyway,

I'm innocent...lol

Hareth