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

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

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

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

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

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

  * >   
>  Difficult, you say. I say: Downright, bloody useless. The loss of  
>  these features alone has already killed the potential of VB.NET in  
>   
>  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.  
>   
> 

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

  * > 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,  
>   
>  How does background compile change your use of edit and continue in anyway?  
>   
> 

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

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

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