Microsoft won't "Bring back Classic Visual Basic"

Microsoft won't "Bring back Classic Visual Basic"
Answer to community's proposal


Status update: An idea you voted for has been closed!
1 vote has been returned to you Go spend your votes on more ideas...


Bring back Classic Visual Basic, an improved version of VB6

7302 votes -> Declined

We have read all of the comments on this thread and I’d like to
thank you for providing your constructive feedback on this issue.
Instead of merely repeating our support and migration guidance
that has been laid out on http://msdn.com/vbrun, I’d like to
address some of your specific comments here.

To play back the feedback themes we’re hearing:

- VB6 is awesome

- VB6 needs to be brought forward and maintained: in a new release
or OSS

VB6 was and still is without a doubt awesome. VB6 made developers
incredibly productive building a breadth of applications and as a
result we have a wealth of applications and passionate developers
to this day in 2014. One way I see our mission in developer tools
is to empower developers to solve problems. This includes both
today’s problems AND the problems of tomorrow. VB6, as you all
have stated repeatedly in this thread, is an excellent tool for
solving the problems of its day. We also stand behind our decision
starting in 2002 to meet the current demands of our developers and
the industry with .NET. For the scenarios VB6 set out to do, we
see VB6 being “complete”. We feel good about VB6 being able to
continue maintaining their applications for the past 15 years.
Current needs ranging from distributed applications and services,
to web applications and services, to devices, to new architectures
and languages, required fundamental changes to the whole stack. We
looked at how we could accommodate these needs through incremental
changes to VB6 while maintaining its essence, and that was not
possible.

To address the modern needs we would need to go far beyond
updating the language. We have to remember that VB6 is not just a
language. VB6 is a language, a runtime, a platform library, a
tool/IDE, and an ecosystem tightly packaged together in a way that
made all of them work well together. We’ve worked with many
customers on migration from VB6 to .NET and found that while yes,
there are language changes, the dominating factor in migration
difficulties isn’t the language differences. Even open sourcing
the language/runtime wouldn’t solve the fact that VB6 was
thought for a different set of problems, and the fact that its
strength came from the end-to-end solution provided by all these
five pieces working together. Take a change like 64bit, the
complete runtime, tools and ecosystem chain would need to be
retooled.

So, moving forward what can we do? Where we have been able to help
move forward is in our stance around support and interoperability.
The VB6 runtime it is still a component of the Windows operating
system and is a component shipped in Windows 8.1. It will be
supported at least through 2024. This ensures your apps and
components continue to run as you incrementally move forward to
.NET. The support policy is here:
http://msdn.microsoft.com/en-us/vstudio/ms788708. There are
numerous interop strategies that we developed and evolved to
enable incremental migration as you upgrade your skills, described
here: http://msdn.com/vbrun.

In summary, VB6 was awesome. We agree. We don’t expect or demand
anyone to throw away their code or rewrite from any of our
technologies unless it makes business sense for them to do so. We
have to innovate to enable our customers to innovate. It is not a
viable option to create a next version of VB6. We stand by our
decision to make VB.NET and the .NET Framework. We think they are
awesome too. It is not feasible to open source VB6 tools chain and
ecosystem. The VB6 runtime was last shipped in Windows 8.1 and
will be supported for the lifetime of Windows 8.1. Support and
interop are great tools to move forward incrementally.

I hope you feel we’ve listened to your feedback and that I’ve
explained things well enough that you understand our decision.

Paul Yuknewicz
Group Program Manager
Microsoft Visual Studio Cloud Tools
Visual Studio team

Visual Studio team
    Product Team, Microsoft