edit and continue, immediate window

[Alex Tsukernik]

As far as I can tell edit and continue has been discontinued, and the
immediate window has been crippled so badly that it's no more flexible than
the watch window. Why can't the vb.net debugger interpret msil in process
like vb6 interprets p-code? then presumably it would not be hard to do what
VB6 already does for immediate window and edit and continue. Does anyone
(Microsoft in particular) seriously think that VB's syntax made it the most
productive RAD tool on the market? Without those RAD features VB is crap
and can not with a straight face be described as a step up in productivity.
Am I the only one who thinks this is infinitely more important than array
declaration syntax or the value of true?

Alex

[Jonathan Allen]

MS has acknowledged this problem, but we are not going to see a solution
before V1. Issues such as integrated debugging, multi-threading and the loss
of interpreted code are making it a difficult proposition.

--
Jonathan Allen


"Alex Tsukernik" <alxts@hotmail.com> wrote in message
news:3b363ac3$1@news.devx.com...
> As far as I can tell edit and continue has been discontinued, and the
> immediate window has been crippled so badly that it's no more flexible
than
> the watch window. Why can't the vb.net debugger interpret msil in process
> like vb6 interprets p-code? then presumably it would not be hard to do
what
> VB6 already does for immediate window and edit and continue. Does anyone
> (Microsoft in particular) seriously think that VB's syntax made it the
most
> productive RAD tool on the market? Without those RAD features VB is crap
> and can not with a straight face be described as a step up in
productivity.
> Am I the only one who thinks this is infinitely more important than array
> declaration syntax or the value of true?
>
> Alex
>
>

[Corrado Cavalli]

In this area, past is better than the future :-(

Corrado

[Jonathan Allen]

I agree. While what we gain exceeds what we lose (for me at least), it still
hurts.

--
Jonathan Allen


"Corrado Cavalli" <corradocavalliNOSPAM@tin.it> wrote in message
news:3b378e7b@news.devx.com...
> In this area, past is better than the future :-(
>
> Corrado
>
>

[Alex Tsukernik]

It seems to me that most if not all of what's being gained in vb.net
existed/exists/will exist in other languages/IDEs from Microsoft and
competitors, what's being lost, namely RAD prototyping/debugging features
like amazingly flexible immediate window and edit and continue, will not
exist anywhere other then obsolescing VB6. It's silly to relinquish such a
competitive advantage.

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3b37abb6@news.devx.com...
> I agree. While what we gain exceeds what we lose (for me at least), it
still
> hurts.
>
> --
> Jonathan Allen
>
>
> "Corrado Cavalli" <corradocavalliNOSPAM@tin.it> wrote in message
> news:3b378e7b@news.devx.com...
> > In this area, past is better than the future :-(
> >
> > Corrado
> >
> >
>
>

[Karl E. Peterson]

Hi Alex --

Yep, I think you've highlighted the #1 reason most folks will reject VFred as a
******* stepson of Classic VB. They've sold
edit-compile-run-break-edit-run-break-edit-run-break since the QB days. There's a
reason MS Basic was successful, and it sure ain't the "value of True."

Later... Karl
--
http://www.mvps.org/vb

"Alex Tsukernik" <alxts@hotmail.com> wrote in message news:3b37b8be@news.devx.com...
> It seems to me that most if not all of what's being gained in vb.net
> existed/exists/will exist in other languages/IDEs from Microsoft and
> competitors, what's being lost, namely RAD prototyping/debugging features
> like amazingly flexible immediate window and edit and continue, will not
> exist anywhere other then obsolescing VB6. It's silly to relinquish such a
> competitive advantage.
>
> "Jonathan Allen" <greywolf@cts.com> wrote in message
> news:3b37abb6@news.devx.com...
> > I agree. While what we gain exceeds what we lose (for me at least), it
> still
> > hurts.
> >
> > --
> > Jonathan Allen
> >
> >
> > "Corrado Cavalli" <corradocavalliNOSPAM@tin.it> wrote in message
> > news:3b378e7b@news.devx.com...
> > > In this area, past is better than the future :-(
> > >
> > > Corrado
> > >
> > >
> >
> >
>
>

[Mike Mitchell]

On Mon, 25 Jun 2001 11:04:19 -0700, "Jonathan Allen"
<greywolf@cts.com> wrote:

>MS has acknowledged this problem, but we are not going to see a solution
>before V1. Issues such as integrated debugging, multi-threading and the loss
>of interpreted code are making it a difficult proposition.

Difficult, you say. I say: Downright, bloody useless. The loss of
these features alone has already killed the potential of VB.NET in
very many programmers' eyes. You are taking away their favourite RAD
language and giving them something that is incompatible, has lost
major RAD features, is more complex, and requires a special framework
for deployment.

In other words, downright, bloody useless.

MM

[Kunle Odutola]

"Alex Tsukernik" <alxts@hotmail.com> wrote in message
news:3b37b8be@news.devx.com...
> It seems to me that most if not all of what's being gained in vb.net
> existed/exists/will exist in other languages/IDEs from Microsoft and
> competitors, what's being lost, namely RAD prototyping/debugging features
> like amazingly flexible immediate window and edit and continue, will not
> exist anywhere other then obsolescing VB6. It's silly to relinquish such
a
> competitive advantage.

I mourn the loss too but it *is* slated for the next version so....can we
wait four years? ;-)

Kunle

[Jonathan Allen]

From what I understand, their number one concern is creating robust and
scalable applications. RAD capabilities are still important, but definitely
secondary.

A good example of where they did do a good job with RAD is VB.Net's
background compiler. With it, we don't have to manually compile programs
before we see if anything is wrong. It is like VB's "Auto Syntax Check", but
far more comprehensive. While it doesn't replace the ability to resume after
an exception, it has reduced my reliance on edit and continue.

--
Jonathan Allen


"Alex Tsukernik" <alxts@hotmail.com> wrote in message
news:3b37b8be@news.devx.com...
> It seems to me that most if not all of what's being gained in vb.net
> existed/exists/will exist in other languages/IDEs from Microsoft and
> competitors, what's being lost, namely RAD prototyping/debugging features
> like amazingly flexible immediate window and edit and continue, will not
> exist anywhere other then obsolescing VB6. It's silly to relinquish such
a
> competitive advantage.
>
> "Jonathan Allen" <greywolf@cts.com> wrote in message
> news:3b37abb6@news.devx.com...
> > I agree. While what we gain exceeds what we lose (for me at least), it
> still
> > hurts.
> >
> > --
> > Jonathan Allen
> >
> >
> > "Corrado Cavalli" <corradocavalliNOSPAM@tin.it> wrote in message
> > news:3b378e7b@news.devx.com...
> > > In this area, past is better than the future :-(
> > >
> > > Corrado
> > >
> > >
> >
> >
>
>

[Kathleen Dollard]

Jonathan,

How does background compile change your use of edit and continue in anyway?

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Jonathan Allen]

I used to program while the application was running so I could get the
compiler errors and such immediately. With the background compiler, I don't
need to hit Run to determine if my syntax is complete and all the variables
declared.

--
Jonathan Allen


"Kathleen Dollard" <kathleen@nomailplease.org> wrote in message
news:3b388d5f@news.devx.com...
> Jonathan,
>
> How does background compile change your use of edit and continue in
anyway?
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --
>
>

[Vlad Ivanov]

Oh this is a much bigger loss than you make it seem.

Having to stop the debugger just to plugin a missing .MoveNext is a sad step
backward. Keep in mind that this missing .MoveNext may be 25 minutes down
the execution path - lets say a certain chain of events need to happen inside
of an app for error to show itself - so you found it, hey you missed .MoveNext
- so instead of fixing it and let the test compelete itself - you now have
to go through the whole process again - just to see if your fix worked. That
would be 25 more minutes. And you may need to repeat it more than once.

Thats just plain horrible.


"Jonathan Allen" <greywolf@cts.com> wrote:
>I used to program while the application was running so I could get the
>compiler errors and such immediately. With the background compiler, I don't
>need to hit Run to determine if my syntax is complete and all the variables
>declared.
>
>--
>Jonathan Allen
>
>
>"Kathleen Dollard" <kathleen@nomailplease.org> wrote in message
>news:3b388d5f@news.devx.com...
>> Jonathan,
>>
>> How does background compile change your use of edit and continue in
>anyway?
>>
>> --
>> Kathleen
>> (MS-MVP)
>> Reply in the newsgroup so everyone can benefit
>> --
>>
>>
>
>

[Jonathan Allen]

Yes, but that is not a problem with "Edit and Continue" itself. That is a
problem with exception handling and the runtime unwinding the stack. And I
don't think anyone is saying that isn't a big deal.

--
Jonathan Allen


"Vlad Ivanov" <blah@blah.com> wrote in message
news:3b38f949$1@news.devx.com...
>
> Oh this is a much bigger loss than you make it seem.
>
> Having to stop the debugger just to plugin a missing .MoveNext is a sad
step
> backward. Keep in mind that this missing .MoveNext may be 25 minutes down
> the execution path - lets say a certain chain of events need to happen
inside
> of an app for error to show itself - so you found it, hey you missed
..MoveNext
> - so instead of fixing it and let the test compelete itself - you now have
> to go through the whole process again - just to see if your fix worked.
That
> would be 25 more minutes. And you may need to repeat it more than once.
>
> Thats just plain horrible.
>
>