Read more on Cloud Computing
March 16, 2005 12:24 PM PST
Microsoft walks VB tightrope
- Related Stories
-
Developers slam Microsoft's Visual Basic plan
March 14, 2005 -
Microsoft pitches new Visual Studio tools
February 7, 2005 -
Study: Visual Basic use may be slipping
May 7, 2003 -
Developers cry foul over new Microsoft language
January 18, 2001
Microsoft remains "firm" in its plans to end free support for Visual Basic 6 at the end of the month, S. "Soma" Somasegar, the corporate vice president of Microsoft's tools division, told CNET News.com.
corporate vice president
of Microsoft's tools division
That decision to end free support for Visual Basic 6, which was introduced in 1998, has caused an outcry among some of Microsoft's developer customers, even those with close affiliations with the software giant.
Somasegar said that Microsoft's intention is to ease the migration of customers to Visual Basic.Net, the current version of the product, which is is designed to quickly build Windows desktop applications that tap into databases.
To do that, the company will introduce enhancements in the forthcoming edition of its Visual Basic 2005 meant to "bring back" some ease-of-use features that appeal to Visual Basic developers, he said. For example, a popular feature called "edit and continue" will make its way into Visual Basic 2005, which is due around the middle of the year.
Also, by the end of the month, Microsoft plans to open the VB6 Upgrade Center, an area on its Microsoft Developer Network Web site, which will have technical information to help customers learn Visual Basic.Net.
What's new:
Microsoft is using a carrot and a stick to get Visual Basic 6 developers to migrate: it will cut off mainstream support for the product but the forthcoming version will add features in the forthcoming that recall VB6.
Bottom line:
Despite protests from its customers, Microsoft is tied to decisions it made many years ago to move the millions of VB developers to its .Net development system.
"It's sort of like, 'Should I give you fish for dinner or teach you how to fish?'' Somasegar said. "We had this revelation 18 or 24 months ago, that maybe we should be expending our energies and efforts to make it easy to migrate (customers') skills to take advantage of the new world."
A break with the past Despite Microsoft's stated aim to help its VB6 developers move to the .Net version of the tool, many developers said the company has not done enough.
On March 8, disgruntled users of Visual Basic 6, or "Classic VB," published a petition complaining about the planned end of free support.
Spearheaded by close Microsoft partners, called Most Valued Professionals (MVPs), the group urges Microsoft to continue the development of the older version of Visual Basic and help customers preserve their investment in existing applications. It called on Microsoft to make VB6 one of the languages in Visual Studio.Net, the company's flagship development tool.
The transition to Visual Basic.Net from VB6 is not as straightforward as most Microsoft product upgrades. When it introduced Visual Basic.Net in 2001, as part of the company's Visual Studio family of tools, Microsoft made significant changes to the underlying programming language.
Decided in the late 1990s, those changes--meant to make Visual Basic applications more industrial-strength--were in reaction to the rising popularity of Java, noted Greg DeMichillie, an analyst at Directions on Microsoft. It is estimated that there are about 3 million VB developers.
"Microsoft was seriously concerned about Java or Web development taking all those VB guys away," DeMichillie said. "Pure compatibility with Visual Basic 6 was not a key goal."
Because of the shift in the underlying language, migrating code written in older versions of Visual Basic is more difficult than a typical upgrade. Also, learning Visual Basic.Net is significant jump for developers because it represents a completely different language than VB6, critics say.
Surveys by Evans Data indicate that the number of VB6 developers outnumber the people who have learned VB.Net. Forty-four percent of
11 comments
Join the conversation! Add your comment (Log in or register)
I know college kids that are outright gurus in Java, .NET and C++... all at the same time. Does anyone remember what it was like to absorb that knowledge and put it into practice? Apparently not VB6 folks.
More thoughts on my blog...
<a class="jive-link-external" href="http://weblogs.asp.net/jeff/archive/2005/03/09/391400.aspx" target="_newWindow">http://weblogs.asp.net/jeff/archive/2005/03/09/391400.aspx</a>
The VB6 'developers' should protest by continue using VB6, MS can't force them to stop, or get smart and stop using MS tools. If you tie yourself to MS, you deserve the headaches and abuse that MS metes out to its customers.
I should add that Java class libraries seem to have more incremental update practices with a lot less whining. (Commnents about how much better Java is than VB can be taken elsewhere - including Java, I already know 3 languages and can make up my own mind.) Maybe MS development platforms would benefit from practices oriented that way.
RH
(more comments @ <a class="jive-link-external" href="http://spaces.msn.com/members/ross613" target="_newWindow">http://spaces.msn.com/members/ross613</a>)
----------------
"The name of the game is not portability--it's interoperability," he said. "Porting applications is just a waste of engineering effort."
This is totally shortsided and he's got it totally backwards. It should be 'InterOp is a just waste of engineering effort.'
INTEROP MEANS ALLOCATE LOTS OF TIME FOR MAINTENANCE
All that time one spends to connect things from an old system to the new system could have been spent on just porting the code over and being done with it. If you decide for InterOp, then make sure you allocate lots of time for maintenance of the old app just in case it doesn't mesh well with the new app.
TIME SPENT 'HERE' COULD HAVE BEEN SPENT 'THERE'
Planning, Writing, Understanding, Learning, Debugging and Coding interop code is a pain because now you have to employ a developer(s) who is proficient at both systems not only NOW but also in the FUTURE for the things, like bugs, and modifications that are always sure to happen just like it did in the old system before VB.NET came along to begin with.
So each time one has to fix a bug in the OLD system, that same amount of time could have been spent on porting it to the new system.
HASSLES CHOSEN BY DEFAULT
By choosing InterOp, one already has choosen by default all the hassles, requirements, documentation, and developers to 'STILL' keep the old system up and running. There are going to be tons of situations where the best and fastest place to make changes is in the old system because InterOp is known to be extremely SLOW because it has to translate all the time.
INTEROP WILL SLOW YOUR ENTIRE SYSTEM DOWN
In fact, InterOp will slow down your entire system , cause again, there is another layer it has to go through. InterOp is and will be SLOWER in performance than VB6 by itself or VB.NET by itself. If you look at the performance charts comparing InterOp and take a close look at the testes, you will see a huge drop. So why do something that will slow your system down not only NOW but in the long run? Why use all that "enginnering effort" to make a slow system when you can just port it over and get better speed and better maintenance. YOu can bite the bullet now with a port OR keep biting it for the long term future by using InterOp.
INTEROP = LOWER RELIABILITY
Choosing the InterOp means more pieces to the puzzle that can go wrong and that need to be debugged and documented and supported. Anyway you look at, a system that uses InterOp will have a lower reliability and there will always be these "GOTCHAS"
YEARS OF CODING
Any legacy app in VB6 that has this dilemma of whether to port or interop is going to big, not because it's VB6, but because it has years of coding behind it and that raises this question of whether to do a port or the code or use InterOp.
I.T. HOLLYWOOD / CELEBRITY COMMUNITY
Again, the I.T. Hollywood / Celebrity community gets it wrong as they have very little experience in the real world and more experience in giving powerpoint demos, writing press reports (tech articles) and sounding like a know-it-all. This reminds me of those who sit on the sidelines telling everyone what to do and those who are actually on the field day in and day out making things happen.
IBM used to play this game of obsoleting code and forec-marching customers in the glory days of big iron; but in the case of IBM what happened was that on the big computers companies quietly did not upgrade until at Y2K the market had devolved to other areas like the PC and some firms were running some code that was 25 years old or older.
MS must figure that as the desktop PC was the escape way back when for those traditionally force-marched by IBM, the marketplace has no place to go but the entanglement and perpetual-pay world of .NET web-tethered apps.
Never mind that the reason the VB6 community uses VB6 is because it represents the zenith of the non-IBM, not desktop-as-terminal method of computing.
.NET is not about Web-centric computing. It is only about placing enough of the underlying Windows core on remote servers that people are forced to the subscription paradigms made possible by .NET.
The computing world, VB6 users in particualr, understand this only too well. Undoubtedly the reason VB.NET is so unlike VB6 is that a no-going-back incompatibility is essential to the .NET strategy, for it is a strategy having no compelling reason to exist except to compel a forced march to rentalware.