|
Re (tilly) 1: Explaining a Perl project to a VB-bound audience
by tilly (Archbishop) on Jan 19, 2002 at 21:29 UTC
|
I would avoid such analogies as dangerous. If you try to
say how Perl resembles specific features in other languages
which Perl is only superficially similar to, then people
will assume a large amount of inappropriate and incorrect
baggage. Plus you will invite questions about why you
didn't just use VB for your project, which gets into all
sorts of dangerous advocacy territory. Remember that nobody
likes hearing that the tools they know don't work well,
particularly when it is true. (It scares them.)
So try to avoid that minefield if you can.
Instead try to find descriptions that stand on their own
except where the concepts really are parallel. And
then just use words like "object" and "class". As for Perl,
introduce it with a quick description of what it is is,
and what it is particularly good for. "Perl is a freely
available scripting language which is particularly good
at things involving text manipulation." Focus on the
positive, not the negative. | [reply] |
(ichimunki) Re: Explaining a Perl project to a VB-bound audience
by ichimunki (Priest) on Jan 19, 2002 at 20:05 UTC
|
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. | [reply] |
(jeffa) Re: Explaining a Perl project to a VB-bound audience
by jeffa (Bishop) on Jan 19, 2002 at 22:41 UTC
|
Hi. My name is Jeff Anderson. I am a VB-aholic, but i have
been *sober* for 2 years now.
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)
| [reply] |
|
|
GTK does have a GUI interface builder called Glade, you may have not been in the office when I was playing with it. :)
I only tinkered with it breifly, but it made UI creation very easy. It is geared toward building C/C++ applications, but it does have a Perl binding...how well it really works, I don't know.
/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"
| [reply] |
|
|
...how well it really works, I don't know.
All of the hardcore gnome hackers that I've spoken with seem to come to the same concensus: use the .glade file, but not the code.
Personally, I don't mind the C code glade generates, but most seem to disagree. The Perl code that can be generated via glade is done with glade2perl, which is a Perl program that makes heavy use of Glade::PerlGenerate. IMO, the code that it generates is absolutely hideous! I generally hand-write my own, but have been meaning to try libglade (see below).. and'll be glad to let you know how it is if/when i do.
As far as peoples' distaste towards glade generated code... it seems preferable to just use libglade
to dynamically generate the UI from the .glade xml file.
I believe (but am not sure) the Perl binding for this lib is Glade::PerlRun, though I've never used it.
| [reply] |
|
|
I don't know if any one factor is going to convince the brass that Perl is a winner. In my case, we started out working with MS ASP on an NT/IIS server. Every time we wanted to do anything new, we'd realize that ASP just didn't cut it, and so early on we started to switch to Perl. Now it's pretty much all we use. The "ASP guy" had to go find somewhere else to occupy his time ;)
-Guv
| [reply] |
Re: Explaining a Perl project to a VB-bound audience
by vladb (Vicar) on Jan 19, 2002 at 20:05 UTC
|
I've worked with VB extensively as well. Not for the last year however ;-). From all I can recall, one way to approach your problem would be to liken Perl modules to an
OCX (or COM) object in VB. For example, VB has a Database interface COM object which could be brought up in your discussion on a variation of DBI module (for MySQL databases). As far as the CGI works, I'm not sure if you could compare anything unless the audience has written any ASP type of application in VB script. By and large, explaining CGI is a different matter.. it's simply a different 'technology'. So you may delve into how a server processes requests and executes scripts requested by the web client and etc.
As far as GTK+ goes, there's ample analogies that one could come up with when it comes to VB. VB programmers are accustomed to interacting with their application GUI via a set of GUI interfaces (objects + their methods/attributes). So you might think of likening the two this way.
Sorry, that's just about as much as I may recall right now ;-)). Hope this is useful.
Cheers,
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
(crazyinsomniac) Re: Explaining a Perl project to a VB-bound audience
by crazyinsomniac (Prior) on Jan 20, 2002 at 12:55 UTC
|
You have been give many-a-suggestion already, some of which are silly, and some of which are good. My advice is simple: teach them some perl. They are at heart programmers, and as such, should be familiar with some concepts. You should just introduce in *loose*terms* what modules are, and how they fit into this application. Most importantly, give out reading material, like abstract's for modules, along with short examples. For example:
DBI - Database independent interface for Perl
use strict;
use DBI;
my $DataBaseHandle = DBI->connect(......
You get the picture.
If, however, the programmers are totally clueless about stuff like "CGI", I suggest also a primer on that, as reading material only, ....
You've spoken with the guys, right? Well if you didn't, please do. Prod them a little bit, gauge their general knowledge of the components involved in your project, and then bring plenty of reading material, to hand out at the end of your presentation (as well as the reading material to hand out before).
Hopefully you get my drift, even though it can't articulate it well at this moment. Good hunting ;)
| [reply]
[d/l] |
|
|
Wow, I didn't expect to raise that much interest on this topic... Thanks all for your help!
One fact you maybe missed is that the presentation is not really geared towards "forcing" them to use Perl; it is just meant to show them *how* this stuff works, _not_ why it's better than some of what they actually do ;-)
I guess I'll just take a mixed approach, probably introducing general concepts about CGI, CPAN and modules, and also giving them some stuff to read (maybe before actually giving the speech, i.e. XML-RPC, MySQL information, maybe also some perldocs). However, if I happened to get negative feedback, I could get to establish comparisions to VB using your advice. I agree that it could be dangerous, but still, if Perl is good at things that VB isn't at. they should face it: that's just the way it is. (and viceversa -GUI generation in Perl (using Glade) was rather a headache, as some of you pointed out ;P)
Oh well, nobody said this world had to be fair for anyone ;-)
Apart from that, I didn't really mean to relate so directly Perl to VB, just find analogies that could let them understand better why I used it as well as some of the stuff it can actually do.
Anyway, I'll take all of this info into account. Again, thanks a bunch!! :-))
| [reply] |
|
|
This may be a silly comment, but if you're trying to explain to someone how something works, aren't you necessarily going to teach this some of how the language works?
Or, are you just going to work with the high-level design? In which case, the language they do and don't know is irrelevant. Languages are implementation details. Designs are language-independent (for the most part).
I mean, they're not going to maintain a Perl application without knowing Perl, right?
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
| [reply] |
|
|