Oh, oh, the Microsoft MVPs are revolting (they want Microsoft to resume VB 6.0 development). I used to be an MVP. I guess I should revolt too!

I used to be an associate editor at Visual Basic Programmer's Journal and helped plan the VBITS conferences. Me and VB go way back.

On one hand, I agree. I wish Microsoft hadn't done what it did. On the other hand, I disagree with the revolt. For why you need historical context. Lots of VB'ers back in the late 1990s were angry that their language always seemed to be a second-class citizen. It was hard to do object-oriented programming with it. VB'ers were looked down upon by other programmers and VB'ers complained at conferences that they wanted the language to get power features like object orientation and multi-threading and full access to the Windows API, among other things.

Today VB.NET is not a second class citizen and I know of some incubation groups working to make sure it even gets some cool stuff that C# and other .NET-oriented languages don't have.

This issue has gotten the focus of Steve Ballmer (he took this issue on personally at two MVP summits I attended). I've also been asking the .NET gurus like Christopher Brumme about the issues. He said they spent long anguishing nights looking at the technical details.

To take it out of Microsoft land. I remember another company that did something similar. Canon. If you go back and look at Canon SLR cameras from the early 1990s, you'll see they have a different lens mount than they use today.

Canon made a corporate decision to "switch the lens mount." When that happened, sales of Nikons went up. Why? Because Nikon didn't "obsolete their existing customer base."

But, today, I'd rather own a Canon. Why? Their lenses focus faster, are more reliable (they don't have a mechanical gear like Nikon's do), and enable new kinds of lenses, like a 50mm f1.0 lens that's impossible to build on Nikon's lens mount. Oh, and Canon now has a much larger percentage of the pro market than they used to have before (I don't remember a single pro using Canons back in the early 1990s - Nikon had a near monopoly in that market. Today you see about 50% Canons at sporting and news events).

Microsoft, for better or for worse, made such a decision. They decided to obsolete old Visual Basic in order to make Visual Basic an equal partner with C# in the .NET world.

Now, could it have been handled better? Absolutely. Everyone on the teams I talk with admits this and there is ongoing work being done to make it easier to convert from the VB 6.0 world into the VB.NET one.

I'll see if Paul Vick can take this on on his blog. He's on the VB.NET team.

For some more context: there are more than 2,000 MVPs now.

Original Link  |  Comments

    When developers balk, Microsoft sometimes listens. But when 100 of Microsoft's Most Valuable Professionals (MVPs) are up in arms, one has to figure Microsoft will sit up and take notice. Microsoft is on tap to phase out support for its Visual Basic 6 language on March 31. But there is still a sizeable number of developers who have not upgraded to the current version of VB (the VB.Net release), mainly because the upgrade is quite painful. Those in favor of Microsoft extending VB 6 support have signed the petition here.

Original Link

    This topic has been in the 'news' lately (well, at least in the blogs) and I've been considering replying.... but it turns out I don't have to, because Dave Totzke has done it for me. I don't really agree with his comment that we've kept C++ alive because Office is written in it... it is actually because the managed world doesn't replace the need to write native code against the underlying hardware and OS. We need to have at least one avenue for folks to write the high-performance graphic software, device drivers, network packet filters, etc.... so we need unmanaged C++ to stay. There isn't a similar need for new development on VB6.

     Yes, it is hard to upgrade complex code bases, but when you install VB.NET it doesn't uninstall your copy of VB6. It is possible to maintain an existing code base while you write new code in .NET and then interop as necessary between the two worlds. Within MSDN, we have Access applications that pop-up Windows Forms when you click certain buttons... we have VB6-based add-ins for Outlook and Word that are simple wrappers around .NET code and some that are a mix of VB6 code and VB.NET code...

    There are some things that were in VB6 and are not available in VB.NET that I feel still need to be available, but I think they could be made available as .NET components, ActiveX components, or add-ins to Visual Studio. Take DDE for example, it just isn't part of the .NET Framework, so I think it would be nice if we had a small component that allowed me to access DDE from within .NET, fired events when new data arrived, etc... I wish that people would put their effort towards building/requesting these types of components instead of advocating something that just isn't a good idea. At the very least, push for more effort to be put into the upgrade process, lets get someone to build more than just a wizard, build a tool that does the upgrade and includes a ton of additional libraries to help with transitioning older code. That would be a lot of work, but the end result is still better than just doing incremental development on VB6.

    By the way, this is as good of time as any to point out that I do believe that there is something missing in the .NET world right now. We need an Access-like tool for .NET... not what VB6 was, which was really much too complicated for the level of developer I'm thinking of... but something that is a drag-and-drop database form focused application creation tool. Like Access, Filemaker Pro, Hypercard, etc... but producing .NET code behind the scenes so that you can extend simple applications created using this tool with code produced out of VB.NET/C#. I think I'll call it Access.NET

Original Link  |  Comments