Perl career progression (Was: Perl work at Monash)
scottp at dd.com.au
Mon Sep 8 20:19:05 CDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday, Sep 9, 2003, at 10:42 Australia/Melbourne, Nathan Bailey
> Okay, so the common theme appears to be "too narrow" which is good
> except not specific enough to move forward/improve :-)
> I do think SQL stands on its own, in the sense that you are unlikely to
> write perl *applications* without some kind of database interaction,
> regardless of the webness of it. And the intention of the progression
> is more towards perl *programming* than perl *scripting*, the later
> which could equally well be done in a combination of sed, awk and grep,
> for example (and would usually not involve writing a new perl module).
It is funny you say that, because I am finding myself moving further
away from SQL.
I am really only using SQL now if I have a relational database - not if
I have non relational data.
I am finding more and more I am leaning towards hierarchical and object
databases - although non formal, mostly involved with storing XML in a
directory structure etc.
> I suspect that paragraph will result in a lot of contention, but
> presuming agreement for the sake of clarity in the current
> discussion... Would adding another column or two about other relevant
> technologies frequently used in perl be sufficient? Two good examples
> from David were messaging (IMAP, NNTP, SNMP, Jabber, etc) and
> directories (LDAP et al). I don't think incorporating LDAP skill
> (i.e. schema management) is relevant since it's not a test of your
> perl capability so much as with a specific environment (i.e. knowing
> LDAP schemas is not likely to make you a better perl programmer, but
> knowing SQL or XML may, especially if lots of applications use them)
I would be leaning towards the concept of using the abstractions for
data storage, but I am uncertain what is the best way to write that up.
DBI for accessing an SQL or simple database is ideal.
Mail::Box maybe a good example of something you should know if dealing
XML::Parser (using configurable backends) for dealing with XML Parsing.
It is hard to write, but what I look for is the idea that someone uses
not only abstractions, but the correct ones and extends them where
necessary. What I find a bad perl programmer, is one who writes their
own way of doing it - and therefore maintaining it.
Perhaps we need to rank standard sort of perl modules and then say pick
the top 10 for what people should be familiar with.
Not in this order...
* IO::* (specifically File, Dir - maybe Select and Copy)
* Net::* (specifically FTP, SMTP, POP3 - how to write your own is good)
- this is a key one that even good perl programmers miss.
- There are plenty of Net:: libs on CPAN which do not inherit from
Net::Cmd (I know, I wrote some before I discovered someone had
done all the hard work for me already)
* Image::Magick (maybe others like Image::Size)
* Getopt::* (I prefer Declare, but Std is fine)
* strict, warnings, base, vars, overload, (Carp) and other pragma
* NEXT (I love NEXT)
Maybe as part of our new portal site, and to help Simon in creation of
good tutorials we could setup a 'best in bread' selection of perl
modules and have us all vote on them - maybe that already exists
VP in charge of Pancakes
scottp at dd.com.au
Dismaimer: If you receive this email in error - please eat it
immediately to prevent it from falling into the wrong hands.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the Melbourne-pm