Microsoft walks VB tightrope

(continued from previous page)

developers report working with VB, while 34 percent work with VB.Net--a percentage that has remained constant since the introduction of VB.Net at the end of 2002, according to Joe McKendrick, a research consultant with Evans Data.

The petition protesting the shift, which was signed by more than 2,000 people, including 222 MVPs, has sparked a debate in the Microsoft development tool community.

Proponents of Classic VB argue that Microsoft is essentially stranding its older VB customers.

"Any organization with an investment in Visual Basic code--consultants, ISVs, IT departments, businesses, schools, governments--are forced to freeze development of their existing VB code base, or reinvest virtually all the time, effort, intellectual property and expense to rewrite their applications from scratch," wrote developer and author Rich Levin in a recent blog entry.

Others developers argue that those VB6 customers should make the move to newer Microsoft technologies.

Juval Lowy, founder and chief architect of consulting firm iDesign, said that current VB6 or older applications do not need to be "ported" to work with Visual Basic.Net. Instead, developers can leave older VB code essentially intact and find ways to share data between older VB applications and newer ones.

"The name of the game is not portability--it's interoperability," he said. "Porting applications is just a waste of engineering effort."

Carrot and stick
Responding to specific requests in the Classic VB petition, Somasegar said that Microsoft does not intend to release a new version of the "migration wizard" for moving VB6 code to Visual Basic.Net.

Also, the company will not make the changes to VB6 to allow it to run as another programming language in Visual Studio. That approach would be "technically implausible," Somasegar said.

In addition, Somasegar gave details of some of the company's efforts to keep existing customers of older versions of VB6 in the Microsoft fold. With Visual Studio 2005, which is code-named Whidbey, developers will be able to use prewritten components, called controls, that worked with VB6, he said.

"To be fair, we did lose a little bit of the VB experience when made transition from VB6 to VB.Net," Somasegar said. "Whidbey Visual Basic is going to provide the best RAD (rapid application development) experience that they have ever seen."

The VB6 Upgrade Center will provide information on how VB6 developers can continue to use their existing applications by using VB and VB.Net together, said Jay Roxe, product manager for Visual Basic.

Roxe noted that customers can purchase support on VB6 for three more years or use credits from an existing support contract for VB6-related incidents. Microsoft already added two years to its initial deadline for cutting off mainstream support, extending it to seven years.

Microsoft has little choice but to follow through on the decisions it made regarding the move to .Net several years ago, DeMichillie said.

The "carrot" Microsoft can use to entice VB6 developers to migrate are new features, such as the Avalon presentation system and Indigo communications being built into the Windows operating system, DeMichillie said. The "stick" is cutting off mainstream support, he said.

"There's not a huge difference between mainstream versus extended support," DeMichillie said. "But companies don't like it: It's a psychological milestone which says that the product is getting long in the tooth."

[Jeff Putz]

Evolution rolls on...

I said it before and I'll say it again. Technology evolves. All of this talk about porting applications is totally irrelevant. Why would anyone port an application if it works? My .NET apps work fine, so why would I want to port them to Java? Why would a Java person port to .NET? VB6 won't magically stop working at the end of mainstream support.

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...
http://weblogs.asp.net/jeff/archive/2005/03/09/391400.aspx

[Bill Dautrive]

wrong

This is just a thinly vieled attempt to wring more money out of developers.

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.

[ross613]

Microsoft on right track here....

I have to mostly agree with the poster's comments about this - launched in '98, VB6 has lived pretty much all of its lifecycle. The story didn't really offer anything concrete here about why support should be further extended.

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 @ http://spaces.msn.com/members/ross613)

Borland Opportunity?

Finally, a niche market that can be served by an ISV without fear of competion by Microsoft.

WRONG! Time spent for Interoperability could be time spent for porting over

Juval Lowey is completely wrong here. The article says,

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

[aabcdefghij987654321]

get a life guys

vb6 is old, it's broken, so much of it is just bad. VB.Net is at least a step in the right direction. Get your heads out of the dino-days and start coding with today's languages.

[aabcdefghij987654321]

and the best is it's free

free as in beer, gratis, and you pay nothing. In fact with windows 2003 it comes preinstalled!

[PolarUpgrade]

Microsft May Be Hitting a Complaince Wall Here

MS appears to fail to realize what in fact is happening here: For the first time in history a market segment is essentially refusing to migrate to the new revenue stream (This being not one Whidbey about software).

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.

[open-mind]

So Switch to REALbasic. It's better.

Great cross platform IDE and cross compiler. Fully object oriented. Easy port from VB. No chains to MS. Creates standalone single-file executables on Windows, OS X, and Linux. Checkout RealSoftware.com. I have no connections to REAL ... just a customer and a fan.

[hpdvs2]

Perhaps at this point we should be pushing to get Microsoft to release VB6 and the IDE as Open Source. They don't make money on it any more, and the new systems have no real reliance on it. If that were done, VB6 could cleanly be turned into a multi-OS version language.

[Mrate]

MS is planing to get ride of VB-Net in 2010... New does become old...