in reply to
Explaining a Perl project to a VB-bound audience
Visual Basic is an object oriented scripting language built from a procedural background. Mostly. Perl is a procedural scripting language with OO tacked on. Mostly. They both have modules (packages written in VB or Perl that can be included in other packages for added functionality). They can both depend on shared libraries (whether .so or .dll). They both have interfaces to widget toolkits (Win32 API or kits like gtk+).
Now I haven't programmed in Visual Basic outside of Access, but the main differences I've seen relate to the IDE (since VB has an editor, and for Perl I use emacs). VB has a somewhat "stronger" type system-- you can declare ints, longs, strings, arrays, structs, enums and all kinds of messy nonsense that turns out to be a lot faster for the programmer using scalars, arrays, and hashes. And while there are plenty of good built-ins for VB, nothing there compares to CPAN in terms of breadth or in terms of easily accessed documentation.
The weirdest question I've ever gotten about Perl (from my manager) was "Is it really free?". This scared me more than anything, since it shows the depth to which issues surrounding software freedom are just unknown outside the geek community (and I've met plenty of very tech savvie folks who don't seem to understand it either).
But I've usually explained Perl as a contrast to VB by having days worth of stupid problems with VBA (and I've been doing it long enough and frequently consulted a real VB programmer often enough to think the problem was *not* me), then solving my problem in mere moments using Perl. Then I offer to show them the code and answer any questions they might have. This last step is crucial, since at that point they usually surrender.
In my case, it really helped that the first high profile Perl success stories I had were in automating work that was otherwise very tedious. And in the second such case, I was able to completely refactor the work I'd done in VBA (two weeks of work) into a full-featured Perl application in about three hours-- actually while the VBA thing was running, so I lost no actual time to convert. In fact, the Perl script was so much faster that I was able to rewrite it completely, debug it, and run it before the VBA version had just done the last step.