But, the hype about MS ending free support for VB6 ... whatever. It's not like my VB code is going to suddenly stop working. Not to mention that the VB interpreter is still going to be part of WinXP, WinServer2k3, and Win2kPro. Oh - and .Net (which means it's part of Mono, which is F/OSS). It just isn't going to be part of Longhorn.

As for transitioning a product from language X to language Y ... the basic rules apply.

• Firm your spec up - it's your roadmap.
• Firm your test suite up - it's the barrier at the side of the road to keep you from the cliff.
• Estimate a month per subsystem, add it up, then triple it.
• Don't do it.

Not to mention that transitioning from VB (which is extremely OO) to Perl (which isn't) is going to be problematic. Transitioning from VB (which is crappily OO) to Ruby (which isn't) is also going to be problematic. Transitioning from anything to PHP (which is a toy) is dumb. (I don't know Python well enough to make stupid comments about it.)

Frankly, I'd rewrite VB applications in Javascript (which is actually a pleasant language once you get past the browser incompatibilities) and go from there. At least, you still have the same graphical interface you're used to.

Frankly, I'd rewrite VB applications in Javascript

I think you are confusing Visual Basic with VBScript or perhaps Visual Basic for Applications. Visual Basic itself has no relation to browsers whatsoever (unless you would care to write a CGI or ISAPI application in it). Visual Basic targets the native windows GUI - not that that makes it any less awfull.

/J\

It is not very hard to write a completely stand-alone Javascript application that uses the browser as the rendering engine. You have access to CSS for layout, the DOM for data, and Javascript is a full language with some really nice features that I'd love to see added to Perl6 (but which won't be, for various reasons).

And, since you're writing it for a Win32 machine, you can specifically target IE, with all of its quirks, making your application quite easy to build quickly. Forms can be handled by

<form onSubmit="do_something();return false;">
</form>
[download]

and everything else is done with location.reload() and a very small frameset.

The only thing you don't have using Javascript-in-IE vs. a standalone VB app is control of the menubar. Frankly, I'm not impressed with menubars in corporate apps.

Oh - deployment of fixes is now very simple, too. You just have an onLoad handler for the window that checks to see if a server is available, and then asks the server with XMLHTTPRequest if there's an update. If there is, it goes ahead and sets the location to the spot, does an implicit reload, and onLoad does a save of the data locally, overwriting the old icon. :-)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

"There are, if I counted correctly, at least 10 languages targeting Parrot right now, and Perl isn't one of them. (Though Python is ...)"

This sounds like you are saying that Perl is not targeting Parrot? Parrot is the interpeter for Perl 6, so this doesn't make a lot of sense.
Unless you are saying that Perl isn't one of the '10 languages'. In that case, I apologize.

Perl isn't one of them ... yet. The only semi-working Perl6 interpreter (Pugs) actually targets Haskell, not Parrot. (This is largely due to Parrot's lack of support for certain necessary features in Perl6, like objects.)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Would a VB6 to Parrot compiler be possible ?

Strangely a similar question came up on a mono list just today - I think my favourite quote from that was :

VB isn't a language, per se. Rather, it's a scripting environment for COM objects.

My recommendation, if you have a wealth of legacy VB6 code, would be to feed it through the translator in Visual Studio 2003 for instance and then fix the problems by hand ( for instance VB.NET can't take some of the VBA.Collection stuff that people used before VB had proper 'hashes').

/J\

The complaints about VB aren't new. I don't believe the issue is so much the lack of support, but the problem that the upgrade path that has been presented requires some companies to do a major rewrite of their code, so that they can port it to VB.NET, and gain no net advantage overall.

There were complaints when support ended for Windows 95. It'll happen for any product that ends support, if there is a significant burden on the owners (or renters, depending on your take on software licensing) of the software to move ... especially if it seems that the company is pushing the move to try to force you to buy new software from them, when you already had software that meets your needs. This migration is worse, as it's not just selling new hardware, but your coders need to be retrained, and change significant portions of their existing code. (see VisualBasic.not for a list of incompatabilities between VB6 and VB.NET).

The advantages to VB6/VBA, and the other products in the VB family is that it already comes pre-installed on a large number of desktop systems, so the companies who develop in it don't have to spend extra time supporting their user base in installing new software. (which would be required from just about anything these days that doesn't run exclusively in a web browser, like the JavaScript/JScript/ECMAScript family, or older versions of Java (if you standardize on too recent of a version, you can shoot yourself in the foot). I'm not going to pretend that VB runs everywhere, but for some companies, it fits their needs, and they have no good migration paths.

How big of a deal is this overall? I'm going to guess it's on the order of magnitude of y2k -- it has the potential to screw up a whole lot of things, but odds are, it's not, if companies do their due diligance, and the media is overhyping this to attract readers so they justify the price at which they sell advertising.

Just to keep this a perl thread I would like to say that I have hated almost every time I used VB and loved almost every time I used [htp://wxperl.sf.net|wxPerl] (perl bindings for the wxwidgets.com cross-platform framework).

Granted VB has a nice forms designer, which makes me think wx's sizers approach is sometimes overdone. But basically instead of using a "scripting environment for com objects" you might enjoy trying it with perl. Not to redo stuff but for new projects.

Anyway as I understand it from far away, the (ultra cool) Haskell target is actually there to solve the bootstrapping problem and will be rewritten in perl 6.

I think you pose an extremely good question though in that a VB6 to Parrot compiler might make you quite rich.

All of which are not great reasons to ditch VB. Another thread somewhere else had people mentioning other basic languages out there, like Realbasic, openoffice.org's basic, and another one I forget. One of them lets you import VB projects.