By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,649 Members | 1,816 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,649 IT Pros & Developers. It's quick & easy.

What C# Needs

P: n/a
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?
Nov 15 '05 #1
Share this Question
Share on Google+
46 Replies


P: n/a
Keith K <kp******@linuxmail.org> wrote:
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)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Nov 15 '05 #2

P: n/a
-----Original Message-----
Jon Skeet <sk***@pobox.com> wrote:
Personally, there are things I'd rather see in the *language* (and attributes which the C# compiler should recognise) such
as:
<snip>

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

--
Jon Skeet - <sk***@pobox.com>
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.
Nov 15 '05 #3

P: n/a

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...
Keith K <kp******@linuxmail.org> wrote:
<some snippage here...>
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]
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 15 '05 #4

P: n/a
-----Original Message-----
Jon Skeet <sk***@pobox.com> wrote:
Personally, there are things I'd rather see in the *language* (and attributes which the C# compiler should recognise) such
as:
<snip>

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

--
Jon Skeet - <sk***@pobox.com>
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.
Nov 15 '05 #5

P: n/a
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]

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...
Jon Skeet <sk***@pobox.com> wrote:
Personally, there are things I'd rather see in the *language* (and
attributes which the C# compiler should recognise) such 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 15 '05 #6

P: n/a

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...
Keith K <kp******@linuxmail.org> wrote:
<some snippage here...>
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]
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 15 '05 #7

P: n/a
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]

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...
Jon Skeet <sk***@pobox.com> wrote:
Personally, there are things I'd rather see in the *language* (and
attributes which the C# compiler should recognise) such 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Nov 15 '05 #8

P: n/a
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]
"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:OL**************@TK2MSFTNGP12.phx.gbl...
Rob,
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 :-)


I'm guessing that Jon is asking for something like

int MyProp {
int i;
get { ... }
set { ... }
}

i would compile down to a field, but the compiler would restrict its
scope to the MyProp accessor methods. Much like how the VB.NET
compiler handles Static locals. That's why you'd have to be able to
control serialization of it.

Personally I've never felt I needed this, and I'm not sure if it's a
good idea. I think it would just cause confusion, having something
that looks like a local but that has the lifetime of a field.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

Nov 15 '05 #9

P: n/a
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]
"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:OL**************@TK2MSFTNGP12.phx.gbl...
Rob,
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 :-)


I'm guessing that Jon is asking for something like

int MyProp {
int i;
get { ... }
set { ... }
}

i would compile down to a field, but the compiler would restrict its
scope to the MyProp accessor methods. Much like how the VB.NET
compiler handles Static locals. That's why you'd have to be able to
control serialization of it.

Personally I've never felt I needed this, and I'm not sure if it's a
good idea. I think it would just cause confusion, having something
that looks like a local but that has the lifetime of a field.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

Nov 15 '05 #10

P: n/a
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> <"Rob Teixeira [MVP]"
<RobTeixeira@@msn.com>> wrote:
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 :-)


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 :)
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).


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Nov 15 '05 #11

P: n/a
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> <"Rob Teixeira [MVP]"
<RobTeixeira@@msn.com>> wrote:
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 :-)


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 :)
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).


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Nov 15 '05 #12

P: n/a
"Keith K" <kp******@linuxmail.org> wrote in news:5a7701c35769$005f1600
$a*******@phx.gbl:
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
--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #13

P: n/a
"Keith K" <kp******@linuxmail.org> wrote in news:5a7701c35769$005f1600
$a*******@phx.gbl:
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
--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #14

P: n/a
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.

On Fri, 1 Aug 2003 09:24:12 +0100, Jon Skeet <sk***@pobox.com> wrote:
Frans Bouma <pe**********@xs4all.nl> wrote:
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?)


That sounds awful to me, actually. I *like* having to press control-
space, as otherwise I often end up having to press escape to get rid of
the popup which I often don't want.

I hope anything that is done automatically can be optionally turned
off...

The main way in which I'd like to see intellisense improved is to make
the popups more useful when they *do* appear - rather than having a
single line with arrows on when there are multiple options, show some
number (eg 8) of the options at a time, with a scroll bar.

FWIW, Eclipse is the first IDE which gave me an autocomplete/intellisense
I actually like. VS.NET could do a lot worse than taking a few leaves out
of Eclipse's book. (I gather it's finally getting refactoring though.
Better late than never.)


--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Nov 15 '05 #15

P: n/a
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.

On Fri, 1 Aug 2003 09:24:12 +0100, Jon Skeet <sk***@pobox.com> wrote:
Frans Bouma <pe**********@xs4all.nl> wrote:
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?)


That sounds awful to me, actually. I *like* having to press control-
space, as otherwise I often end up having to press escape to get rid of
the popup which I often don't want.

I hope anything that is done automatically can be optionally turned
off...

The main way in which I'd like to see intellisense improved is to make
the popups more useful when they *do* appear - rather than having a
single line with arrows on when there are multiple options, show some
number (eg 8) of the options at a time, with a scroll bar.

FWIW, Eclipse is the first IDE which gave me an autocomplete/intellisense
I actually like. VS.NET could do a lot worse than taking a few leaves out
of Eclipse's book. (I gather it's finally getting refactoring though.
Better late than never.)


--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Nov 15 '05 #16

P: n/a
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" <cd*******@hotmail.com> wrote in message
news:e5**************@tk2msftngp13.phx.gbl...
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.

"Keith K" <kp******@linuxmail.org> wrote in message
news:5a****************************@phx.gbl...
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?


Nov 15 '05 #17

P: n/a
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" <cd*******@hotmail.com> wrote in message
news:e5**************@tk2msftngp13.phx.gbl...
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.

"Keith K" <kp******@linuxmail.org> wrote in message
news:5a****************************@phx.gbl...
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?


Nov 15 '05 #18

P: n/a
Hi Keith.
I've found a few instances where I hit
ctrl+spacebar and nothing happens in C#.

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
"Keith K" <kp******@linuxmail.org> wrote in message news:5a****************************@phx.gbl... 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?

Nov 15 '05 #19

P: n/a
Hi Keith.
I've found a few instances where I hit
ctrl+spacebar and nothing happens in C#.

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
"Keith K" <kp******@linuxmail.org> wrote in message news:5a****************************@phx.gbl... 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?

Nov 15 '05 #20

P: n/a
Frans Bouma wrote:

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 ;-))
Nov 15 '05 #21

P: n/a
Frans Bouma wrote:

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 ;-))
Nov 15 '05 #22

P: n/a
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #23

P: n/a
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #24

P: n/a
Frans Bouma wrote:
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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.
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.


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.
(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 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.

Nov 15 '05 #25

P: n/a
Frans Bouma wrote:
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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.
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.


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.
(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 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.

Nov 15 '05 #26

P: n/a
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:FY*********************@news-text.cableinet.net:
Frans Bouma wrote: 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.


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.
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.


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 my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx
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 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?


If I tell you I never alter variables in a debugger, do you believe
me?
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 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.
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.


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.
(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 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 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?


see the blog link above
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.


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #27

P: n/a
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:FY*********************@news-text.cableinet.net:
Frans Bouma wrote: 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.


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.
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.


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 my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx
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 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?


If I tell you I never alter variables in a debugger, do you believe
me?
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 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.
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.


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.
(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 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 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?


see the blog link above
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.


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #28

P: n/a
"Frans Bouma" <pe**********@xs4all.nl> wrote in message
news:Xn********************************@207.46.248 .16...
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
Read my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx


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<g>
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-kern.../Sep/1177.html

Should i follow it too ?
Nov 15 '05 #29

P: n/a
"Frans Bouma" <pe**********@xs4all.nl> wrote in message
news:Xn********************************@207.46.248 .16...
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
Read my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx


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<g>
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-kern.../Sep/1177.html

Should i follow it too ?
Nov 15 '05 #30

P: n/a
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.

"Frans Bouma" <pe**********@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

Nov 15 '05 #31

P: n/a
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.

"Frans Bouma" <pe**********@xs4all.nl> wrote in message
news:Xn*********************************@207.46.24 8.16...
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:HD********************@news-text.cableinet.net:
Frans Bouma wrote:

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!


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------

Nov 15 '05 #32

P: n/a
Frans Bouma wrote:
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:FY*********************@news-text.cableinet.net:
Frans Bouma wrote:
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.


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.
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.


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.

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.


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 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.

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?


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 my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx
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 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?


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


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

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 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).
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.


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).
(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 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.


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.

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?


see the blog link above
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.


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.
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)


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?
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.


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.

Nov 15 '05 #33

P: n/a
Frans Bouma wrote:
"Frank Mulvenny" <fr***********@info.r.us> wrote in
news:FY*********************@news-text.cableinet.net:
Frans Bouma wrote:
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.


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.
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.


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.

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.


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 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.

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?


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 my article about why E&C is bad practise and how to debug
software:
http://weblogs.asp.net/fbouma/posts/22211.aspx
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 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?


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


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

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 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).
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.


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).
(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 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.


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.

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?


see the blog link above
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.


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.
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)


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?
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.


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.

Nov 15 '05 #34

P: n/a
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" <de*****@mindspring.com> wrote in message
news:uh**************@tk2msftngp13.phx.gbl...
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" <cd*******@hotmail.com> wrote in message
news:e5**************@tk2msftngp13.phx.gbl...
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.

"Keith K" <kp******@linuxmail.org> wrote in message
news:5a****************************@phx.gbl...
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?



Nov 15 '05 #35

P: n/a
-----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 getin my way, not to mention the fact that I type faster than it can popupmost 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 fordebugging, not for fixes... I have personally heard a lot of VB developersexclaim "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.
Nov 15 '05 #36

P: n/a
Joe


"Bill Priess" <no*****@nospam.com> wrote in message
news:oprtfv3intcimqky@localhost...
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... :) )


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

http://www.ximian.com./about_us/pres...html?pr=novell
Joe
--
http://www.csharp-station.com
Nov 15 '05 #37

P: n/a
-----Original Message-----
Hi Derek-

I agree that C/C++ people probably feel more comfortable using C#. ButKeith, the original poster, said that he had been using VB since 1992, so Ithought 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.


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.
Nov 15 '05 #38

P: n/a
"Keith K" <kp******@linuxmail.org> wrote in news:0a3c01c35b56$54814960
$a*******@phx.gbl:
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.


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

--
Solutions Design : http://www.sd.nl
My open source .NET Software : http://www.sd.nl/software
My .NET Blog : http://weblogs.asp.net/FBouma
-------------------------------------------------------------------------
Nov 15 '05 #39

P: n/a
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


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
Nov 15 '05 #40

P: n/a

"Keith K" <kp******@linuxmail.org> wrote in message
news:06****************************@phx.gbl...
-----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


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.


Think again... mbas

http://www.go-mono.com/languages.html#mbas

HTH,
Tom Shelton
Nov 15 '05 #41

P: n/a
-----Original Message-----

"Keith K" <kp******@linuxmail.org> wrote in message
news:06****************************@phx.gbl...
>-----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

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.


Think again... mbas

http://www.go-mono.com/languages.html#mbas

HTH,
Tom Shelton

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.
Nov 15 '05 #42

P: n/a
-----Original Message-----
"Keith K" <kp******@linuxmail.org> wrote in news:0a3c01c35b56$54814960$a*******@phx.gbl:
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.
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 thefirst place?

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?
Nov 15 '05 #43

P: n/a

"Keith K." <kp******@linxumail.org> wrote in message
news:9e****************************@phx.gbl...
-----Original Message-----

"Keith K" <kp******@linuxmail.org> wrote in message
news:06****************************@phx.gbl...

>-----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


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.


Think again... mbas

http://www.go-mono.com/languages.html#mbas

HTH,
Tom Shelton

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.


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
Nov 15 '05 #44

P: n/a
-----Original Message-----
"Keith K" <kp******@linuxmail.org> wrote in news:0a3c01c35b56$54814960$a*******@phx.gbl:
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.
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 thefirst place?

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

you place a breakpoint... where? At the start of the program? No, youplace a breakpoint at the spot right before where YOU think it can bewrong. You fire up the debugger, you see your misspelling error, you stopthe 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 oflines of code, do you really think I run that one in the debugger? It isutterly slow in the debugger. I only debug when I need to. When amisspelling in a formula is found, INSIDE the debugger, (like a '-' shouldbe a '+'), you alter the - into a + and recompile and re- run, not in thedebugger. 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 fixyou just made will bring you DIFFERENT parameter values for the routineyou're currently IN), to see if your misspelling fix works? If you NEEDTO, 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 iscertain the formula is ok. If not, the fix is a TRIAL/ERROR fix. Plain andsimple. And we all know what kind of software is breeded from Trial/errordevelopment.


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.
Nov 15 '05 #45

P: n/a
*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

"Len Weaver" <le********@meritsoft.net> wrote in message
news:uQ**************@tk2msftngp13.phx.gbl...
Hello Frans,

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

Nov 15 '05 #46

P: n/a
-----Original Message-----
"Keith K" <kp******@linuxmail.org> wrote in news:0a3c01c35b56$54814960$a*******@phx.gbl:
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.
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 thefirst place?

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

you place a breakpoint... where? At the start of the program? No, youplace a breakpoint at the spot right before where YOU think it can bewrong. You fire up the debugger, you see your misspelling error, you stopthe 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 oflines of code, do you really think I run that one in the debugger? It isutterly slow in the debugger. I only debug when I need to. When amisspelling in a formula is found, INSIDE the debugger, (like a '-' shouldbe a '+'), you alter the - into a + and recompile and re- run, not in thedebugger. 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 fixyou just made will bring you DIFFERENT parameter values for the routineyou're currently IN), to see if your misspelling fix works? If you NEEDTO, 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 iscertain the formula is ok. If not, the fix is a TRIAL/ERROR fix. Plain andsimple. And we all know what kind of software is breeded from Trial/errordevelopment.

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?
Nov 15 '05 #47

This discussion thread is closed

Replies have been disabled for this discussion.