> So what we really need are Perl standards of competency. A certificate that
> proves that at some point in time you knew Perl to that standard might be
> useful. Or it might not. If you are a professional contractor you might be
> bothered to get the certificate, but it's no big deal.
>
> So, maybe the emphasis needs to be less on certification in the sense of
> exams and tests and all that, and more on a way to define common and widely
> accepted standards of competency....
one obsticle to this discussion in the past has been the quesiton
of what "programming perl" means. kind of like "speaking german":
it ranges from Wagner to e-mail w/ different requirements for each.
core (spoken) language competency is usually framed in terms of
an X word vocabulary and ability to read specific levels of standard
grammer (e.g., the A cert in language, above).
instead of debating wheter we can "certify" everyone in their own
variety of perl hacking, what if we focus on a given level of core
language competency (e.g., knowing what "$_" means in specific
situations, what "shift" does to you). anyone writing perl for just
about anything should know what "eval" means to them.
the certificate "level" could be based on vocabulary: know what these
terms mean and you have an "A" level (e.g., $, @, %). know this many
more and it's a "B" (e.g., "->"). write XS in your sleep and you get
a "Z" :-).
this might save us the agony of debating what makes a "programmer" and
leave the focus entirely on people understanding specifics of the Perl
Language. after that if we want to certify perl in various uses and
systems there could be additional certificates for these areas also.
--
Steven Lembark 2930 W. Palmer St.
Chicago, IL 60647
[EMAIL PROTECTED] 800-762-1582
