What C# Needs

  • Thread starter Thread starter Keith K
  • Start date Start date
Bill Priess said:
Keith, agreed, and if it is introduced into the new IDE, I wouldn't use it
anyhow. But I have seen a lot of VB programmers fall into that trap. Also,
I noticed that you mentioned that C# is ISO certified and your interest in
MONO. Great job! C# becoming an ISO certified language was one of the
biggest reasons why the company that I work for switched from ASP/JScript
to ASP.NET/C#.


( Ahhh, if MONO takes off, a happy man I will be... :) )
Click to expand...

It's looking more possible every day. Ximian just got bought by Novell:

http://www.ximian.com./about_us/press_center/press_releases/index.html?pr=novell


Joe
 
-----Original Message-----
Hi Derek-

I agree that C/C++ people probably feel more comfortable using C#. But
Keith, the original poster, said that he had been using VB since 1992, so I
thought that in his case he might be happier just sticking with VB.

Maybe Keith would like to chime in and tell us how he feels. :-)

Chris G.
Click to expand...

Certainly.

I really don't have a problem using VB.NET, but C# offers
some compelling features and is ISO compliant which makes
it more attractive to larger corporations. I'm beginning
to notice more and more companies looking for C#
developers as both consultants as well as employees. The
ability to create "unsafe" code blocks and the language
syntax reminds me of my 'C' days back in the early 90's.

I am also pursuing some Java development and C#'s syntax
closely mirrors that. I just feel that if MSFT continues
to promote a single dev environment, then ALL .NET
languages should be able to benefit from RAD features.
Just because a developer chooses C# as his/her language
does not mean that he/she does not want to make use of the
RAD-ness. I'll never leave VB behind, but let's face it,
C# offers a great deal.

MSFT: VB developers have LONG been treated like the "Dung"
developers of Visual Studio. What amazes me is that many
of your C++ developers (I know some personally) would LOVE
to see some of the RAD features in their language and
debugger that we in VB land have enjoyed for years.

Let's face it, if the Ximian "Mono" project takes off,
then C# will be the language that takes Visual Studio.NET
developers into the land of Linux and Unix. Not VB.NET.
 
I disagree! There are times when you are not actually
TRYING to FIX code. I just may want to change a formula
or call a different function right quick for "whatever
reason". It may have been a SIMPLE typing error (i.e. a
mispelled word or something). I should NOT have to stop
the program, make that simple change and restart the
program and then have to wait until it reaches that part
of the code to see my results.
Click to expand...

Sigh :)
You all don't get it, do you. Let me explain it once again. :) WHY,
why, WHY, why, why, W H Y, WHY are you stepping through that code in the
first place?

1) the routine you wrote misbehaves
2) you checked the code against the algorithms it has to perform. It seems
to do that
3) you reread the code and everything should be fine.

you place a breakpoint... where? At the start of the program? No, you
place a breakpoint at the spot right before where YOU think it can be
wrong. You fire up the debugger, you see your misspelling error, you stop
the debugger, you fix the spelling error

and you are done, DONE, done, D O N E!

The current application I'm working on has 10 projects, a hell of a lot of
lines of code, do you really think I run that one in the debugger? It is
utterly slow in the debugger. I only debug when I need to. When a
misspelling in a formula is found, INSIDE the debugger, (like a '-' should
be a '+'), you alter the - into a + and recompile and re-run, not in the
debugger. Do you re-step through the code (you have to recompile/restart
(even with E&C) and perhaps re-step into the current code because the fix
you just made will bring you DIFFERENT parameter values for the routine
you're currently IN), to see if your misspelling fix works? If you NEED
TO, you weren't sure the '-' should be a '+'.

That's the whole point.

A developer should be sure about the code he/she types in. Utterly simple.
If he sees a mistyped formula, and thus fixes the formula, he then is
certain the formula is ok. If not, the fix is a TRIAL/ERROR fix. Plain and
simple. And we all know what kind of software is breeded from Trial/error
development.

That's all.

FB
 
Hello Frans,
to. When a misspelling in a formula is found, INSIDE
the debugger, (like a '-' should be a '+'), you alter
the - into a + and recompile and re-run, not in the
Click to expand...

The point here is that with E&C (as it will exist in the next
version of VB) is that you will NOT have to recompile and re-run. After
fixing your bug you can continue to step through your code, or hit F5 to
advance to the next break point. The situation you describe only allows
one bug to be fixed per debug session, with a wait-and-recompile before
you can begin the next session.

When programming in VB6 I would usually write code for four or five
hours, then test/debug all of that code in a single debug session. The
'R' in RAD stands for Rapid. E&C is definitely a RAD feature.

I agree that some people use E&C as a substitute for design, but
removing a feature just because some people will abuse it seems wrong to
me.

Later,
Len
 
-----Original Message-----


Sigh :)
You all don't get it, do you. Let me explain it once again. :) WHY,
why, WHY, why, why, W H Y, WHY are you stepping through that code in the
first place?
Click to expand...
WHY, WHY, WHY WHY, WHY? You're not being FORCED to use
this feature, but don't keep it from those of us who DO
want to use t! Just leave it disabled. You debug and fix
the way you want to and we'll debug and fix the way we
want to. Isn't Democracy Grand?
 
-----Original Message-----


Sigh :)
You all don't get it, do you. Let me explain it once again. :) WHY,
why, WHY, why, why, W H Y, WHY are you stepping through that code in the
first place?

1) the routine you wrote misbehaves
2) you checked the code against the algorithms it has to perform. It seems
to do that
3) you reread the code and everything should be fine.

you place a breakpoint... where? At the start of the program? No, you
place a breakpoint at the spot right before where YOU think it can be
wrong. You fire up the debugger, you see your misspelling error, you stop
the debugger, you fix the spelling error

and you are done, DONE, done, D O N E!

The current application I'm working on has 10 projects, a hell of a lot of
lines of code, do you really think I run that one in the debugger? It is
utterly slow in the debugger. I only debug when I need to. When a
misspelling in a formula is found, INSIDE the debugger, (like a '-' should
be a '+'), you alter the - into a + and recompile and re- run, not in the
debugger. Do you re-step through the code (you have to recompile/restart
(even with E&C) and perhaps re-step into the current code because the fix
you just made will bring you DIFFERENT parameter values for the routine
you're currently IN), to see if your misspelling fix works? If you NEED
TO, you weren't sure the '-' should be a '+'.

That's the whole point.

A developer should be sure about the code he/she types in. Utterly simple.
If he sees a mistyped formula, and thus fixes the formula, he then is
certain the formula is ok. If not, the fix is a TRIAL/ERROR fix. Plain and
simple. And we all know what kind of software is breeded from Trial/error
development.
Click to expand...

If that's the case, then all debuggers should get rid of
the edit-watch functionality so that variable values can't
be changed either in the debugger. Heck, according to
you, Frans, if I see that I mistakenly set a connect
string to the wrong server, why would I want to change
that string while in debug mode (5 minutes into the
execution of the program)? I should just stop the
debugger, go and change the connect string (if it's
hardcoded for WHATEVER reason) and restart the app and
wait another 5 minutes until I reach that point again
where I can pick up the debugging. Heck, why even have a
debugger? Let's just all go BACK to HAVING to generate
message boxes and TRACE files.
 
-----Original Message-----


Sigh :)
You all don't get it, do you. Let me explain it once again. :) WHY,
why, WHY, why, why, W H Y, WHY are you stepping through that code in the
first place?

1) the routine you wrote misbehaves
2) you checked the code against the algorithms it has to perform. It seems
to do that
3) you reread the code and everything should be fine.

you place a breakpoint... where? At the start of the program? No, you
place a breakpoint at the spot right before where YOU think it can be
wrong. You fire up the debugger, you see your misspelling error, you stop
the debugger, you fix the spelling error

and you are done, DONE, done, D O N E!

The current application I'm working on has 10 projects, a hell of a lot of
lines of code, do you really think I run that one in the debugger? It is
utterly slow in the debugger. I only debug when I need to. When a
misspelling in a formula is found, INSIDE the debugger, (like a '-' should
be a '+'), you alter the - into a + and recompile and re- run, not in the
debugger. Do you re-step through the code (you have to recompile/restart
(even with E&C) and perhaps re-step into the current code because the fix
you just made will bring you DIFFERENT parameter values for the routine
you're currently IN), to see if your misspelling fix works? If you NEED
TO, you weren't sure the '-' should be a '+'.

That's the whole point.

A developer should be sure about the code he/she types in. Utterly simple.
If he sees a mistyped formula, and thus fixes the formula, he then is
certain the formula is ok. If not, the fix is a TRIAL/ERROR fix. Plain and
simple. And we all know what kind of software is breeded from Trial/error
development.
Click to expand...
What if it's not a typing error, I just WANT to change it
because I WANT TO to see what the results would be?
 
Keith K. said:
That's great news, it still does not change my original
posting suggestion, however. All languages should be able
to benefit from ide, compiler and debugger enhancements to
VS.NET.
Click to expand...

I'm not disputing that... I agree. What I was commenting on was the comment
about VB.NET and Linux/Unix. VB.NET is going to be supported by mono. In
fact it already is partially.

Tom Shelton
 
*cough* Multiple Inheritance *cough*

It's always a judgement call... a lot of people like to hide/deny things
because they're too afraid they'll be used badly. Pointers, Multiple
Inheritance, EnC. And you'll see people that want to hide some things and
not others, because they don't want to lose the functionality of some of the
features.

I agree with you, I don't like the removal of features because people think
it might be used badly and/or they can't be bothered to work out a decent
way to make it work (in the case of MI). That being said, I generally find
myself naturally coding the way Frans says. I've never used EnC before
because I've hardly touched VB, but I don't think I would use it much/at
all. But I wouldn't say that it shouldn't be included just because I like my
way of developing.

Niall
 
Back
Top