Thanks to Scott and Sean for pointing out that MSDN has published a high-level roadmap for Whidbey and Orcas. I’m planning at some point in the near to talk a little more about some of the details of Whidbey features, especially generics. Not because I have an urge to blab secrets but because I think there’s value in letting people know where things are headed, and even get a chance to get some feedback.
Especially there is relatively less info on new features in Whidbey for VB.NET……
I’m glad that the focus of Whidbey ( as far as VB.Net is concerned) is productivity. I originally started programming in assembler, then C, then VB (along the way also used COBOL, Algol, Lisp, prolog). The reason I changed languages was because of productivity. I sacrificed power and flexibility for productivity.
The current version of VB.Net has decreased my productivity substantially whilst giving me back some power and flexibility. Therefore, for me VB.Net is 1 step back. But it has the potential to take 3 steps forward. If the VB.Net team can focus on dveloper productivity it will take us that 3 steps forward.
One final point. Reading the road map for Whidbey, it appears that a lot of work has been done to reduce the amount of code a developer has to initially write (which is good). But I would also like tools/wizards/something to help with code maintenance. E.g. on MSDN it states "E.g. The comment on MSDN is "code editor enhancements will automatically author common programming tasks, enabling developers to "fill in the blanks"". This is fine for the initial code, but may not help for maintenance. I normally spend more time maintaining existing code.
Anyway, keep up the good work.
Interesting different perspective.
Eric Rudder, senior vice president of Server and Tools at Microsoft comments "To that end, Whidbey will be a minor upgrade, similar to Visual Studio .NET 2003".
If, as a developer, Whidbey increases my productivity substantially, regardless of the amount of code changed, I would regard Whidbey as a major upgrade.