Jesting aside, i really am a 'converted' ex-VB programmer. I agree with tilly about avoiding such analagies, but i will do so anyway.

First, do NOT compare Perl modules to COM! Visual Basic uses COM to achieve object embedding in MicroSoft applications. COM is MicroSoft specific, just as CORBA is to Sun. Perl has the cabability to speak COM and OLE thanks to some recent CPAN modules, but unless you are writing a Perl script that specifically needs to do such, then COM is a non-issue. Perl modules can't be compared to ActiveX controls either ... those are more like Java Beans. I have heard rumors of Perl 'Beads', however...

Instead, compare Perl modules to VB Class Modules. With Visual Basic, Classes are a bit magical. You have to have name your methods to get,set, and let accordingly - that's why it is desirable to use the Wizard to create VB Classes.

With Perl, well, you don't have to follow any such rules. As a matter of fact, i LOVE to show VB heads Perl's AUTOLOAD subroutine - that crosses their eyes! Sometimes they see the beauty and power, most of the time not.

GTK+ vs. VB? On just about any given day, VB wins. Why? Because that is one of VB's greatest strengths. GUI creation. You just can't beat being able to drag a control onto a window and double clicking it to get to the code section. Maybe there is a tool avaible that gives GTK+ this same power, if there is, please let me know!

DBI vs. ADO? Well, personally i think ADO is very 'one way of doing things' whereas DBI is very flexible. For the most part though, the basic concepts are the same: connect, store, fetch and iterate a 'cursor' over the results.

So, in conclusion i say that comparing VB to Perl on a generic basis is like comparing apples and oranges. I would focus on why VB CANNOT do what your Perl script does, at least not as easily.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)