What C# Needs

K

Keith K

Having developed with VB since 1992, I am now VERY
interested in C#. I've written several applications with
C# and I do enjoy the language.

What C# Needs:

There are a few things that I do believe MSFT should do to
improve C#, however.

I know that in the "Whidbey" release of VS.NET currently
under development, VB.NET will get good ole "edit-and-
continue" back. Hurray! What's unfortunate (and correct
me if I'm wrong) is that C# developers won't enjoy this
feature. This is very unfortunate because THAT feature
should exist in ALL programming languages.

Another thing that C# needs is better intellisense (as
good as vb.net). I've found a few instances where I hit
ctrl+spacebar and nothing happens in C#. I write the SAME
exact piece of code in VB.NET and hit ctrl+spacebar and
the intellisense pops up just fine.

It's not like C# developers don't want to have these nice
visual and functional features enjoyed by VBers available
to them if they "choose" to use them. Keep in mind the
word "choose". Don't FORCE developers to have to use
these features. Allow them to disable or enable them as
needed. It's ONE development environment folks, why can't
all .NET languages using that dev env benefit?
 
J

Jon Skeet

Keith K said:
Having developed with VB since 1992, I am now VERY
interested in C#. I've written several applications with
C# and I do enjoy the language.

What C# Needs:

<snip>

Neither of these are C# suggestions - they're "Visual C#" or "Visual
Studio .NET" suggestions. Last I heard, E&C wasn't ruled out for
Whidbey anyway - not sure about the Intellisense improvements you're
after.

Personally, there are things I'd rather see in the *language* (and
attributes which the C# compiler should recognise) such as:

o Explicit control over beforefieldinit
o Properties with separate access/mutate protection levels (I believe
we're getting this)
o Variables declared within properties, which then can't be accessed
by other methods (except possibly where there's a new attribute
specified, eg AccessPropertyFields, to allow easier serialization)
o Possibly an attribute to be specified on the derived class which
would tell the compiler to effectively "inherit" the constructors
from the base class (ie automatically provide stub versions which
just call the base version)
 
K

Keith K

-----Original Message-----
as:

<snip>

Oh, and also some way of accessing named indexers (and preferrably a
nicer way of naming them, too). Generics will make this slightly less
important, but it's still not terribly easy to provide an efficient,
type safe, read-only indexer.

--
Jon Skeet - <[email protected]>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
.

You are correct. There are a number of improvements that
could be added to the language. My suggestions were
mainly centered around the IDE. Really, I just don't see
why any IDE, compiler, and debugger, etc. enhancements
should be "language" specific. If ONE language benefits,
then ALL languages should benefit as well.
 
R

Rob Teixeira [MVP]

Jon Skeet said:

o Explicit control over beforefieldinit
o Properties with separate access/mutate protection levels (I believe
we're getting this)

According to a dev chat, that is correct - we are getting this (about time!)
:)
Chalk one up to old VB, which actually did this correctly.
I believe you can find the transcript at either msdn.com or csharp.net.
o Variables declared within properties, which then can't be accessed
by other methods (except possibly where there's a new attribute
specified, eg AccessPropertyFields, to allow easier serialization)

I'm not sure I understand this properly. I mean, local variables can't be
accessed by other methods as it is, and how does this affect serialization.
There might be something interesting here, so i'm curious :)
o Possibly an attribute to be specified on the derived class which
would tell the compiler to effectively "inherit" the constructors
from the base class (ie automatically provide stub versions which
just call the base version)

Well, there's been a lot of this kind of talk over other OOP languages, and
all I can say is that it starts language civel wars :)
There are some legit reasons why constructors aren't inherited and
overridable (well, no inheritance means no overridable by definition i
suppose).
Personally, I wouldn't mind seeing constructors being part of the interface,
so you can do things like properly mandate constructor signatures when they
are absolutely required (like for serialization - ISerializable, as an
example).

-Rob [MVP]
 
R

Rob Teixeira [MVP]

You know what i want? A way to define parameterized properties in general!!
Let's think about this for a moment...

If I write the following:

[System.Compil..(insert namespace here depending on FW
version)...IndexerName("MyIndexer")]
public string this [int Index]
{
get { } // get the string from a list here
set { } // set the string to list here
}

What I *really* get in IL, is a function explicitly named "get_MyIndexer",
with the [DefaultMember] attribute on it, and an int parameter. It's
basically a method that has special type bits calling it a "property" for
the sake of the consumer code (and don't get me wrong, I love the idea of
separating the concept of a "property" from a method *hinthint for the J
language by the OTHER company).

Ironically, the VB .NET prototype actually has code that's closer to what
actually happens in the IL -

Public Default Property MyIndexer ( ByVal Index As Integer ) As String

The cool thing about the VB syntax is that it allows parameterized
non-indexer (non default members) properties. It also allows you to specify
more than just one indexer on the class (I'd rather like to think of it as
multiple parameterized properties instead of multiple indexers actually). Of
course, it also helps that VB uses ( ) for both param lists and array index
specifiers, whereas C(#)(++) uses [ ] for one and ( ) for the other.

-Rob [MVP]
 
R

Rob Teixeira [MVP]

I agree. Never quite felt the urge to use something like that. In addition,
you lose the ability to have the variable placed on the stack since it's a
field, so you have to deal with the heap (which is faster in .NET, but
still...) and you have to deal with threading issues (multiple threads
coming into the property and using the same
field-that-pretends-to-be-a-local).
I'm not getting a good feeling from this idea. The field would also have to
automatically be thread-static then.

-Rob [MVP]
 
J

Jon Skeet

Rob Teixeira said:
I'm not sure I understand this properly. I mean, local variables can't be
accessed by other methods as it is, and how does this affect serialization.
There might be something interesting here, so i'm curious :)

They wouldn't *actually* be local variables - they'd be instance/static
variables depending on how the property were declared. They wouldn't be
within the get/set, but within the property declaration itself. For
instance:

public int Height
{
int height;

get { return height; }
}

"height" would effectively just be a private instance variable as far
as IL is concerned (no IL/CLR changes are required) but no methods
would have direct access to it unless they'd been marked with the
attribute to say "I'm special; let me do what I want".

You'd need certain extra rules to avoid name collision etc, but I think
it would be a nice idea. It would allow the compiler to check the
convention where only the property has access to fields, and everything
(including the class) has to go through properties. Of course, this
would be awful if you couldn't specify a private mutator and a public
accessor, but this proposal takes that as read :)
Well, there's been a lot of this kind of talk over other OOP languages, and
all I can say is that it starts language civel wars :)
There are some legit reasons why constructors aren't inherited and
overridable (well, no inheritance means no overridable by definition i
suppose).

Absolutely. I fully agree with them not automatically being inherited
(see http://www.pobox.com/~skeet/csharp/constructors.html) but for
certain types (especially Exception) it would be quite handy to have a
shorthand way of saying "I want all the same constructors as my base
class". It should be stated in the derived class though, not the base
class.

The other alternative is for the IDE to make this easier, by providing
a way of saying, "Show me all the base class constructors, and let me
tick which ones I want stubs provided for."
Personally, I wouldn't mind seeing constructors being part of the interface,
so you can do things like properly mandate constructor signatures when they
are absolutely required (like for serialization - ISerializable, as an
example).

And static methods at the same time, I'd suggest. Basically, things
which can only actually be invoked by reflection, but which are handy
to get the compiler to check anyway.
 
F

Frans Bouma

Having developed with VB since 1992, I am now VERY
interested in C#. I've written several applications with
C# and I do enjoy the language.

What C# Needs:

There are a few things that I do believe MSFT should do to
improve C#, however.

I know that in the "Whidbey" release of VS.NET currently
under development, VB.NET will get good ole "edit-and-
continue" back. Hurray! What's unfortunate (and correct
me if I'm wrong) is that C# developers won't enjoy this
feature. This is very unfortunate because THAT feature
should exist in ALL programming languages.

I'm glad C# DOESN'T get E&C, so C# developers learn the GOOD way of
debugging applications instead of fixing code in the debugger. The
debugger is for testing, not for altering code.
Another thing that C# needs is better intellisense (as
good as vb.net). I've found a few instances where I hit
ctrl+spacebar and nothing happens in C#. I write the SAME
exact piece of code in VB.NET and hit ctrl+spacebar and
the intellisense pops up just fine.

I can't say much, but what I've seen of the intellisense in C# in
Whidbey is that it is better than you can possibly dream about. (how does
'you don't need to press cntr-space anymore' sound?)

FB
 
B

Bill Priess

LOL Jon... I hate VS.NET Intellisense 95% of the time... Eclipse is nice,
but I still don't like Intellisense all that much. It does nothing but get
in my way, not to mention the fact that I type faster than it can popup
most of the time (have to love keyboard shortcuts!)...

As for E&C... C#/C++/C never had it and shouldn't have it. Debugging is for
debugging, not for fixes... I have personally heard a lot of VB developers
exclaim "hey, my variable is the wrong value after I fix *insert bug here*.
what happened?!"... Always got a good laugh out of that one.. ;)

Anyhow,

Bill P.
 
D

Derek LaZard

Hi Keith.

I haven't had any problems...Occasionally I was getting a message saying something like "please standby building intellisense cache..."; but haven't noticed it lately...
Intellisense and mouse-over data windows are always there on my workstation...

[BTW, are you running alot of background/system tasks...]
[...I didn't know about the ctrl+spacebar shortcut--it works nice...]

Derek LaZard
 
D

Derek LaZard

Hi Chris. IMO, those who choose C# probably have used C/C++; at least this
is the case with me... :)

[BTW, I've been hearing alot about VB.NET, tho; I will probably port
something just to learn it...]

Derek LaZard
 
F

Frank Mulvenny

Frans said:
I'm glad C# DOESN'T get E&C, so C# developers learn the GOOD way
of debugging applications instead of fixing code in the debugger. The
debugger is for testing, not for altering code.

Argh! No no no! You are TOTALLY wrong on that! Edit & Continue is an
absolute timesaving godsend. As an ex VB/C++ programmer I can swear to that.
However, I wouldnt go back to VB from C# even if C# didnt have edit &
continue, because I much prefer the terse C# syntax. But I am living in the
certainty that E&C will return at some time in the future!

BTW, some people used to (and still do) argue that 'you dont need an
interactive debugger, reading the code is the GOOD way to debug', and we all
know that's rubbish! :)

(This wasnt a flame, but I do feel strongly about this issue ;-))
 
F

Frans Bouma

Argh! No no no! You are TOTALLY wrong on that! Edit & Continue is an
absolute timesaving godsend. As an ex VB/C++ programmer I can swear to
that. However, I wouldnt go back to VB from C# even if C# didnt have
edit & continue, because I much prefer the terse C# syntax. But I am
living in the certainty that E&C will return at some time in the future!

If you need EnC to develop good software, you are not thinking when
designing the software, nor when developing the software. Sorry to be
harsh, but all the "nooo, we want it and you are wrong and do not
understand what you're talking about" crap starts to get on my nerves
actually.

If you need EnC, start thinking about: why aren't we developing
software while it is running anyway? thus INSIDE a debugger?
BTW, some people used to (and still do) argue that 'you dont need an
interactive debugger, reading the code is the GOOD way to debug', and we
all know that's rubbish! :)

No, 'we' do not. Reading back your code is good, because it is
NECESSARY to do so when you are checking the algorithm against the code-
representation of that algorithm you wrote.

Read my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx

If you still need E&C in every day software development, I truly
hope I'll never have to work with the software you're writing, sorry. The
reason for that is: if you KNOW what to fix, you fix it SO IT will then be
fixed. If you DO NOT know what you're doing you need a runtime-verifier to
verify what you're doing, and if you can't live without E&C you definitely
make a hell of a lot of 'stupidity' mistakes, which is not in favor of you
either.
(This wasnt a flame, but I do feel strongly about this issue ;-))

feelings are things you have for your wife/partner, your pets, your
children etc. When it comes to software, you have to think, not feel. If
yuo can't proof E&C is more productive, you can feel all you want, but you
do not have a strong case. I tried to proof E&C is not a feature that's
useful, and besides some smalltalk/lisp interpreter fellow who didn't
understand what the difference between an interpreted language and a
compiled language is, no-one could proof I'm wrong.

I write a hell of a lot of lines of code per day, but I fire up the
debugger three or four times a day to test some mistery behaviour I can't
find back in my algorithm implementations or in my algorithms itself. Look
at it this way: if you write some code, and you run it, and it misbehaves
and you do not understand why when yuo SEE the misbehaviour, you do not
understand the code you've just written.

FB
 
F

Frank Mulvenny

Frans said:
If you need EnC to develop good software, you are not thinking
when designing the software, nor when developing the software. Sorry
to be harsh, but all the "nooo, we want it and you are wrong and do
not understand what you're talking about" crap starts to get on my
nerves actually.

If you need EnC, start thinking about: why aren't we developing
software while it is running anyway? thus INSIDE a debugger?

It is definately a useful facility to have. In fact, since developing
software involves debugging it, we are already developing software in the
debugger. E&C extends the power and flexibility of that debugging process.
Also, E&C is useful even outside the context of debugging as such. One can
use it to explore the facilities of some utility classes perhaps - in a live
situation. Can be very useful again.


No, 'we' do not. Reading back your code is good, because it is
NECESSARY to do so when you are checking the algorithm against the
code- representation of that algorithm you wrote.

Of course, reading your code to try and work out the problem is
a good way of debugging - that's a no-brainer.
But it's not neccesarily the only or quickest way in all cases.

This argument is one of a long line of obsolete arguments. It is the direct
descendent of that old chestnut:
"Writing your program, and having to send it
off to the computer to be batch executed, and
getting the results the next day is good
because it forces you to make sure it doesnt
have bugs."

Pure hairshirt mentality, with a soupcon of elitism.

Read my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx

If you still need E&C in every day software development, I truly
hope I'll never have to work with the software you're writing, sorry.

What other debugging facilities are beyond the pale and to be used only by
the plebians I wonder?
Changing the value of a variable?
Being able to see the value of a variable?
Altering the execution point?
Of course all these things are acceptable, because these are all useful
time-saving things to be able to do.
And if it is 'morally' acceptable for one to be able to alter the state of a
program by changing variables, why not code?

The reason for that is: if you KNOW what to fix, you fix it SO IT
will then be fixed.

The same could be said for compile errors, so therefore perhaps we shouldnt
have fast compilers that let us use the compiler as a crutch to find our
coding errors. This is the same argument as is being made against E&C.

If you DO NOT know what you're doing you need a
runtime-verifier to verify what you're doing, and if you can't live
without E&C you definitely make a hell of a lot of 'stupidity'
mistakes, which is not in favor of you either.

Of course we can live without E&C, and no doubt many other developments of
the past decades.
feelings are things you have for your wife/partner, your pets,
your children etc. When it comes to software, you have to think, not
feel. If yuo can't proof E&C is more productive, you can feel all you
want, but you do not have a strong case.

I have found it to be very useful. It's not essential, but then neither are
fast compilers, or intellisense. Or syntax colouring. However, all these
things are useful so long as one can avoid having an elitist philosophy that
considers them fit only for 'bad programmers'.

I tried to proof E&C is not a feature that's useful and besides some smalltalk/lisp interpreter
fellow who didn't understand what the difference between an
interpreted language and a compiled language is, no-one could proof
I'm wrong.

I presume you're talking about a previous thread in some discussion forum.
Do you have a link?
I write a hell of a lot of lines of code per day, but I fire up
the debugger three or four times a day to test some mistery behaviour
I can't find back in my algorithm implementations or in my algorithms
itself. Look at it this way: if you write some code, and you run it,
and it misbehaves and you do not understand why when yuo SEE the
misbehaviour, you do not understand the code you've just written.

Sorry, but your reply has displayed a quite disgusting degree of
condescension and arrogance.
I am disapointed that you should feel the need to resort to this kind of
stuff.
You seem to have a hair-trigger superiority complex! ;-)

Try and remember that in the end, the presence of E&C facility does no harm
to the 'real programmers' such as yourself, who will at no point be required
to lower themselves to making use of it.
 
F

Frans Bouma

Frank Mulvenny said:
It is definately a useful facility to have. In fact, since developing
software involves debugging it, we are already developing software in
the debugger.

No, we're not. THere is no runtime information available when we're
typing code-text.
E&C extends the power and flexibility of that debugging
process. Also, E&C is useful even outside the context of debugging as
such. One can use it to explore the facilities of some utility classes
perhaps - in a live situation. Can be very useful again.

I don't see why. Edit&Continue is about altering code at runtime
and immediately (well, after the recompile) see the effect of that
altering. That's it.
Of course, reading your code to try and work out the problem is
a good way of debugging - that's a no-brainer.
But it's not neccesarily the only or quickest way in all cases.

quickest? how do you measure that? I like to write code that is
solid and bugfree. And I want to proof that not by stepping through a
debugger but by other means, like the ones we all learned during our CS
study.
This argument is one of a long line of obsolete arguments. It is the
direct descendent of that old chestnut:
"Writing your program, and having to send it
off to the computer to be batch executed, and
getting the results the next day is good
because it forces you to make sure it doesnt
have bugs."

Pure hairshirt mentality, with a soupcon of elitism.

So, you think the people who write OS kernels use E&C? Ever
debugged an OS kernel? Or ever thought of how a remote debugger works when
you're debugging that ASP.NET website application? How are you going
implement E&C in these situations? You can't. And especially debugging
ASP.NET applications is common these days.

Read the article in the url above about debugging software. Then
come back and tell me you use E&C through all the 4 categories of bugs.
I'm pretty sure you don't use E&C nor WONT use E&C in 3 of the 4
categories, which are the majority of bugs in software.
What other debugging facilities are beyond the pale and to be used only
by the plebians I wonder?
Changing the value of a variable?
Being able to see the value of a variable?
Altering the execution point?
Of course all these things are acceptable, because these are all useful
time-saving things to be able to do.
And if it is 'morally' acceptable for one to be able to alter the state
of a program by changing variables, why not code?

If I tell you I never alter variables in a debugger, do you believe
me?
The same could be said for compile errors, so therefore perhaps we
shouldnt have fast compilers that let us use the compiler as a crutch to
find our coding errors. This is the same argument as is being made
against E&C.

If there was some kind of runtime analysis software we could use,
it would a big step forward. It would be great to have pre/post conditions
in the code itself, so the compiler could check them, so we could use
compile time to highlight bugs.
Of course we can live without E&C, and no doubt many other developments
of the past decades.

It's not about if we can live with or without having it, it's
about:
1) There is a limited amount of time. Microsoft has stated in the
VS.NET newsgroup friday that there was a choice: OR refactoring OR E&C in
C#. They clearly made the choice for refactoring in C# and E&C in VB.NET
2) E&C encourages developers to use it as THE debugging tool for
their software, while these developers should be encouraged to debug by
reading their code and test the code against the algorithms they
implemented. Look at the developers using E&C: are they reading their code
and see with pre/post conditions if their code matches a PROVED algorithm?
10 to 1 they don't: they alter code in the debugger, re-run the method and
hope the values they see now in the locals window are the ones that should
be there.
I have found it to be very useful. It's not essential, but then neither
are fast compilers, or intellisense. Or syntax colouring. However, all
these things are useful so long as one can avoid having an elitist
philosophy that considers them fit only for 'bad programmers'.

I don't see what the relation between intellisense and E&C is. You
clearly do not understand what debugging is all about, or for that matter,
what 'programming' stands for. Hint: not typing in code.
I presume you're talking about a previous thread in some discussion
forum. Do you have a link?

see the blog link above
Sorry, but your reply has displayed a quite disgusting degree of
condescension and arrogance.

Hmm, having an opinion is being arrogant? Why? I can explain and
have explained it why E&C is bad debugging practise and should be avoided
and if a tool DOES make you avoid it (because it doesn't have the feature)
you as the developer will be a better software engineer in the end.
I am disapointed that you should feel the need to resort to this kind of
stuff. You seem to have a hair-trigger superiority complex! ;-)

Well, from time to time I get a little tired of the people who
think they are professionals (I'm not talking about you personally) but
show a lack of knowledge about what software engineering is all about. And
instead of bashing these people that they're not what they think they are,
which is rude and counterproductive, it's better to educate them and show
them why they're wrong and how they can improve their skills and knowledge
and THUS their software they're making. About a decade ago, my mentor at
the uni spend extra time to enlighen me why the ideas I had about
designing / engineering software were not that good and also told me why.
I'll never forget that, and if I can open other people's eyes I won't stop
doing so. So, no, this is not about being arrogant. Yes I personally think
I'm very good at software engineering, but not the best. No wonder, since
I do it for a loooong time already. What's wrong with trying to teach some
knowledge I learned during the past 10 years?
Try and remember that in the end, the presence of E&C facility does no
harm to the 'real programmers' such as yourself, who will at no point be
required to lower themselves to making use of it.

Frank, even if MS was able to implement all the features in the
world into vs.net, I still would be writing these texts. It's not about a
silly feature I won't use and you will. It's about the philosophy behind
the REASON why you would use the feature and I won't.

FB
 
N

ncaHammer

Frans Bouma said:
No, we're not. THere is no runtime information available when we're
typing code-text.

i think, C# IDE does compile (or parse) while typing (intellisense most of
the times is correct)
AFAIK designer does parse the CreateComponent method
I don't see why. Edit&Continue is about altering code at runtime
and immediately (well, after the recompile) see the effect of that
altering. That's it.

Frank implies the case of a "newbie" that is in the process of using your
code, and does not understand how it behaves. Consider E&C as an online/live
documentation or as learning tool. Much better in many cases than any docs
you may have write

In your article you forgot two other categories, i often encounter

1) Off-by-one errors most in drawing, coordinate calculation, but also the
relation of string.IndexOf and string.Substring (should i add 1, subtract 1
or leave it as is ?)
Those quests break my nerves, i wish i could write down a random expression
and while debugging write the correct one using the current context state

2) Heuristics-like (no algorithm exists, or trial and error *is* the
algorithm)
It's not about if we can live with or without having it, it's
about:
1) There is a limited amount of time. Microsoft has stated in the
VS.NET newsgroup friday that there was a choice: OR refactoring OR E&C in
C#. They clearly made the choice for refactoring in C# and E&C in VB.NET

Good point, I prefer refactoring but i guess this is not the reason
I think that the first implementation of E&C will be lame, i doubt that it
can handle templates and or unsafe code. With those omissions only VB (lame
by nature) can have it said:
2) E&C encourages developers to use it as THE debugging tool for
their software, while these developers should be encouraged to debug by
reading their code and test the code against the algorithms they
implemented. Look at the developers using E&C: are they reading their code
and see with pre/post conditions if their code matches a PROVED algorithm?

What do you mean by "PROVED algorithm"
quick-sort ?
If not how do you prove an algorithm ?
ie STDDEV of Excel (and .net) uses a PROVED algorithm, but the result is in
many cases wrong
it's better to educate them and show
them why they're wrong and how they can improve their skills and knowledge
and THUS their software they're making.

this reminds me this :
http://lists.insecure.org/linux-kernel/2000/Sep/1177.html

Should i follow it too ?
 
A

Alvin Bruney

Thankfully, your arguments belong to a dieing breed. The debugger is an
integral part of developing good software. If you aren't using the debugger
to step thru every line of code you write, you aren't developing good
software. period. I'll save the long explanation and point you to John
Robbin's book Debugging windows applications. Familiarize yourself with what
he has to say. He covers all your gripes and more.

On the question of EnC. You probably haven't used it enough to criticize it.
If you fix a bug. It is fixed. Otherwise you haven't fixed. The only
difference is how much time did you spend fixing it? 2 days thru inspection
or 2 minutes. The less time you spend fixing bugs, the more you help your
company maintain its competitive advantage.

I've worked with programmers who disliked the debugger. The inherent problem
with this approach is that it takes too long for all but the simplest
programs. And you cannot build complex software with that approach. These
programmers are making themselves less useful to the company. Have you tried
looking for a bug thru source code in a multi-threaded application? These
are all tools that need to be in your toolbox, the more you have the more
valuable you make yourself.
 
F

Frank Mulvenny

Frans said:
No, we're not. THere is no runtime information available when
we're typing code-text.

I regard debugging code as part of the development process. That is the
point I was trying to make.
I don't see why. Edit&Continue is about altering code at runtime
and immediately (well, after the recompile) see the effect of that
altering. That's it.

Well, you presumably havent used E&C before, so maybe you arent the best
person to comment on what can be done with it ;-)
Okay, exploring classes via edit & continue... how can I describe it. Think
of E&C as providing the ability to experiment with snippets of code at
runtime - not necc. even in a program you are 'debugging' as such. It's a
useful experimental workbench. Writing a little program to mess about with
the GDI+ library would be an example.

quickest? how do you measure that?

I can only provide anecdotal evidence of my own experience. However note
that I'm not proclaiming that my way is the 'one true way'. I think that is
an arrogant position to take.
I like to write code that is
solid and bugfree. And I want to proof that not by stepping through a
debugger but by other means, like the ones we all learned during our
CS study.

Edit & Continue is nothing to do with proving code correctness. But if you
find a problem in your code, E&C can be useful in fixing those problems more
quickly. But, nobody's forcing you to use it.

So, you think the people who write OS kernels use E&C?

No, and it's a complete irrelevance to me. I dont write OS kernels.
Ever
debugged an OS kernel?

No, and I never intend to - after all, I'm only a pretend programmer,
remember? ;-)

Or ever thought of how a remote debugger works
when you're debugging that ASP.NET website application? How are you
going implement E&C in these situations? You can't.

What's your point? That Edit & Continue cannot be implemented in some
scenarios?
With respect, so what?

And especially
debugging ASP.NET applications is common these days.


Read the article in the url above about debugging software. Then
come back and tell me you use E&C through all the 4 categories of
bugs. I'm pretty sure you don't use E&C nor WONT use E&C in 3 of the 4
categories, which are the majority of bugs in software.


If I tell you I never alter variables in a debugger, do you
believe me?

Heheh. I can *well* believe it, honestly!

If there was some kind of runtime analysis software we could use,
it would a big step forward. It would be great to have pre/post
conditions in the code itself, so the compiler could check them, so
we could use compile time to highlight bugs.

This sounds interesting. I noticed a thing called XC# that allows you to do
rudimentary stuff like this (if I understand your point).
It's not about if we can live with or without having it, it's
about:
1) There is a limited amount of time. Microsoft has stated in the
VS.NET newsgroup friday that there was a choice: OR refactoring OR
E&C in C#. They clearly made the choice for refactoring in C# and E&C
in VB.NET 2) E&C encourages developers to use it as THE debugging
tool for
their software, while these developers should be encouraged to debug
by reading their code and test the code against the algorithms they
implemented. Look at the developers using E&C: are they reading their
code and see with pre/post conditions if their code matches a PROVED
algorithm? 10 to 1 they don't: they alter code in the debugger,
re-run the method and hope the values they see now in the locals
window are the ones that should be there.

Actually, waitaminute how the heck do you know how people use E&C? This is
pure speculation informed by predjudice. No doubt some people do do this,
but not all (there's my bit of speculation).
I don't see what the relation between intellisense and E&C is.

2 useful and non-essential facilities provided by modern IDEs.
You
clearly do not understand what debugging is all about, or for that
matter, what 'programming' stands for. Hint: not typing in code.

I may indeed have fallen from the one true path.

see the blog link above


Hmm, having an opinion is being arrogant?

No, much of your argument was of the form 'idiots who dont agree with me
arent doing programming properly'. I think it was uncalled for. I find it
tiring and tiresome when people cant just discuss things civilly, but have
to resort to this sniping style. (Which I am now guilty of - damn you
dragged me into it ;-))
Why? I can explain and
have explained it why E&C is bad debugging practise and should be
avoided and if a tool DOES make you avoid it (because it doesn't have
the feature) you as the developer will be a better software engineer
in the end.


Well, from time to time I get a little tired of the people who
think they are professionals (I'm not talking about you personally)

Aheh, so you're not talking about me, but you explain your tone in
responding to me by saying you get sick of people who 'think they are
professionals' and show a lack of knowledge. My turn to 'hmmm' :)
Well, I get sick of 'people who know they are professionals' and yet who
lack basic manners.

Oh, and I see now that the E&C debate has been in effect for a little while
now - this, and the light hearted emphaticness of my original post probably
explains your rapidity in going into flame mode.
but show a lack of knowledge about what software engineering is all
about. And instead of bashing these people that they're not what they
think they are, which is rude and counterproductive, it's better to
educate them and show them why they're wrong and how they can improve
their skills and knowledge and THUS their software they're making.
About a decade ago, my mentor at the uni spend extra time to enlighen
me why the ideas I had about designing / engineering software were
not that good and also told me why. I'll never forget that, and if I
can open other people's eyes I won't stop doing so. So, no, this is
not about being arrogant. Yes I personally think I'm very good at
software engineering, but not the best. No wonder, since I do it for
a loooong time already. What's wrong with trying to teach some
knowledge I learned during the past 10 years?


Frank, even if MS was able to implement all the features in the
world into vs.net, I still would be writing these texts. It's not
about a silly feature I won't use and you will. It's about the
philosophy behind the REASON why you would use the feature and I
won't.

Well it's good somebody who knows the truth is prepared to bring it to the
ignorami.


By the way, here's how I order the potential new C# features, at least the
ones I can remember at this moment:
1 Generics
2 Refactoring
3 Iterators
4 E&C

Are there any other ones? As a dotnet web blogger you probably have a better
handle on what stuff is in the pipeline. Can we both agree to ignore each
other's ridiculous misguided ideas, then? Honestly, I dont want to continue
if it's just going to be a two-way slanging match, which I suspect it is.


Sincerely,
Frank, Stereotypical VB Primate.
 
M

msnews.microsoft.com

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.

Derek LaZard said:
Hi Chris. IMO, those who choose C# probably have used C/C++; at least this
is the case with me... :)

[BTW, I've been hearing alot about VB.NET, tho; I will probably port
something just to learn it...]

Derek LaZard


Chris Glasser said:
If you like all of these features in VB, why not just use VB? Does C# offer
you something that VB does not that you consider it to be worth the
aggravation of not having the VB features you like?

(All references to VB mean VB.NET, not VB6)

Chris G.
 
K

Keith K

-----Original Message-----
LOL Jon... I hate VS.NET Intellisense 95% of the time... Eclipse is nice,
but I still don't like Intellisense all that much. It does nothing but get
in my way, not to mention the fact that I type faster than it can popup
most of the time (have to love keyboard shortcuts!)...

As for E&C... C#/C++/C never had it and shouldn't have it. Debugging is for
debugging, not for fixes... I have personally heard a lot of VB developers
exclaim "hey, my variable is the wrong value after I fix *insert bug here*.
what happened?!"... Always got a good laugh out of that one.. ;)

Anyhow,

Bill P.

Bill:
The real beauty is that you don't have to use it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top