Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

autarch
  (email not shown publicly)
http://www.vegguide.org/

Journal of autarch (914)

Sunday May 06, 2007
10:01 PM

What does it mean to "know" Perl?

[ #33209 ]
One of the Bugzilla maintainers posted a blog entry on "The Problems of Perl" (on LiveJournal, love the irony ;)

It's spawned a lot of discussion and some advocacy (ugh, advocacy). One of the points I've seen come up several times is that the author complains about something in Perl, and someone suggests a module that might help, to which the author replies "I'll check that out."

In a few other threads the author has claimed to know Perl pretty well.

In reponse to that a few folks have said "well, if you don't know about Module X you don't know Perl."

This brings up the question of what it means to "know" Perl. Personally, I tend to agree, this blog author really does not know Perl. He may be able to read Perl well, and he may be able to write clean Perl, but that's different from really "knowing" the language.

A programming language is more than the sum of its syntax. In that sense, I know C. But in the sense of actually understanding the lore and spirit of the language, I don't know C at all. But the word "know" is pretty loaded here, and it's easy to interpret in many different ways. Let's try to come up with two different terms.

For someone like this blog author, I'd say that they are "competent" with Perl. They won't be flummoxed trying to read Perl, if you give them a task to code in Perl they can do it without writing something horrible, but they won't do the best possible job either, because they don't know enough to do so.

For the other version of "know", let's say "expert". An expert knows more than the syntax, they know the lore. They're aware of the ongoing community and discussion behind the language. For Perl, a large part of this means being aware of what's on CPAN, and knowing how to use it to solve problems. It probably also means going to mongers meetings, conferences, reading mailing lists, hanging out on Perlmonks or IRC, etc. You don't have to do all of those, and you don't really have to be an active writer/speaker, but you have to have some level of involvement.

Achieving competency should be a pretty quick process for anyone who's competent in another language. Once you've learned the syntax and some core libraries, you can apply your existing design skills to write not-too-horrible code.

But achieving expertise is much harder, and it's an ongoing effort. Right now I'm definitely a Perl expert. If I went away for two years and came back, I'd probably just be competent, and it'd take catching up to become an expert again.

In practical terms, I'd prefer to work with experts than competents, but I'd hire a competent if I had enough experts on the team already to make sure the competents do expert-level work. A team of competents will produce an okay code base, but one that reinvents many wheels, and has a lot of niggling problems.

Unfortunately, it seems like employers can't even distinguish between competent and incompetent, much less between competent and expert. But that's a whole 'nother journal entry.

List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

What does it mean to "know" Perl? 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Right now I'm definitely a Perl expert.

    And modest too.
    • I don't think he meant it in an arrogant way. I think that was a summation defined by the criteria given in the previous paragraph. Given those criteria the author considers himself "expert" level in Perl.

      I myself, would be competent, striving for expert.

      :
    • There's nothing immodest about calling oneself a Perl expert, especially if you're Dave Rolsky.
      --

      --
      xoa

    • I have never claimed to be modest, nor would I. Given my giant ego, saying that I'm merely an "expert" in Perl is modest compared to what I might want to say ;)
  • Someone (Tom Christiansen?) wrote a description of different levels of Perl experience, from novice to user, hacker, guru... (I see a "Perl Purity" test, which uses the levels, but I thought there was a description of each of the levels. Maybe I'm thinking
  • The whole idea of perl101.org, which we're still trying to get in a form I won't mind publicly announcing, is "What Every Perl Programmer Should Know." It's the bare minimum bar of what to know to take full advantage of the language in the cases that I th
    --

    --
    xoa

  • For Perl, a large part of this means being aware of what's on CPAN, and knowing how to use it to solve problems.

    That was much easier five years ago. By that criteria, I have a difficult time considering myself a Perl expert; it's awfully difficult to

    • If "staying up to date on CPAN" means "being knowledgeable of the latest templating system / CMS / framework / OO gimmick in CPAN" I lost count, umm, many, many years ago. Because I don't use any of them.

      • It could mean that, or a DBIx plugin, or which Unicode-aware module handles encodings correctly and transparently.

      • I meant it more like "knowing what to use". As far as template systems go, I don't think the best modules in that class have changed for a long time. There's TT, Mason, and HTML::Template. For some (non-web) uses, there's also Text::Template. Anything else
    • Yes, there's many new CPAN modules all the time. I "follow" the new uploads, as in I look at what's new at least once a day, and occasionally click through to read a module's docs.

      That's a little different from staying up to date on what's best. I don't th
    • I've found that subscribing to the recent uploads [cpan.org] RSS feed helps with that. It makes it pretty easy to keep up to date with new releases of modules that you might already be using, and can be an entertaining 5 or 10 minute diversion when someone uploads s
  • I actually have heard of and did know about most of the modules and frameworks that were suggested by many of the commenters on my blog, as do several other Bugzilla contributors. Remember, Bugzilla is written by a community, not by just me.

    When I first st
    • The module installation problem is real. Yes, Perl folks in the know are comfortable with CPAN, but it's true that many aren't.

      As have been mentioned in various threads, there are solutions to that, including "bundle them manually", PAR, automating the ins
      • Hahahaha. :-) Yeah, I hate being stuck between that divide of "reinvent all the gears, wheels, and rods" or "require more modules than anybody wants to deal with." :-)

        It's true that it's a problem in any language, though some languages have things like ema

        • they have a ridiculously extensive standard library.

          Except when they don’t (because ¾ of it are optional at compile time).

    • I'm not sure how it can be easier to port to a new language that the developers and users know less, than to a framework written in a language the system is written in and developers and users already have some familiarity with.

      As it happens, if I was to w
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • Hi TeeJay. I think more of our users know Python than Perl, but it's true that more of our developers know Perl than Python.

        Have you looked at the database schema of Bugzilla in any depth?

        We're working on custom workflow right now.

        Our goal is to be a bug-t
    • So if we start to add lots of required modules to the Bugzilla project, that's a big problem for our users.

      Six Apart have solved this problem rather nicely by bundling all modules with MovableType [sixapart.com]. It's a breeze to install too.

      Off the top of my head, you
  • Also, I wanted to respond to your point about how much time and research it takes to become a Perl expert. I agree--that's what it takes.

    It probably takes that for C, as well, although I wouldn't know since my C experience is somewhat limited (although I c

    • But working toward Python best practices takes far less effort, I'd say, than equivalent Perl best practices, partly because the Python standard libraries are more extensive.

      I'm not entirely sure that that's true, nor even that that's the most importan

      • Yes! Thank you, I think you said that very well, and I completely agree. :-)

        -Max
      • There are some quirks and issues when you get deep into perl as you've said, but bugzilla doesn't come anywhere close to this, and I'd wager you'd find equally problematic issues when you reach a similar depth of programming in Python or Ruby.

        I've had a qu
        --

        @JAPH = qw(Hacker Perl Another Just);
        print reverse @JAPH;
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.