Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

  (email not shown publicly)

Journal of autarch (914)

Sunday May 06, 2007
09: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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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.


    • 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 of something else.)
  • The whole idea of, 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 think people will be using it.

    So by that definition, the answer to your question is "If you know everything in" :-)



  • 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 stay up to date on the best CPAN modules when there are so many new ones every week.

    • 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 I would ignore, except maybe Jesse's Template::Declare, but that's far from mature enough to be best in class, and has yet to prove itself.

        OTOH, if you're writing your own templating system or using eperl, you're not up to date on CPAN ;)
    • 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 think there's a new best module in any category every day, by any means. The best of any given category changes relatively infrequently, and it takes time before a new module becomes the best.

      By definition, for a module to be "best in category" it has to hav
    • I've found that subscribing to the recent uploads [] 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 something new and useful. That's just enough exposure so that, when 3 months down the line someone says "I need a program to do X" I remember that I've seen Foo::X go past on CPAN.
  • 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 started to work on Bugzilla's code several years ago, it was not in a state where a project like "Use DBIx::Class and Catalyst" was a feasible project. A huge amount of cleanup was required before anybody could even see the architecture of Bugzilla.

    I'm glad
    • 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 install off CPAN, distro packages, etc.

      This is not a language problem. Ruby and Python will both have similar issues. PHP doesn't because nobody uses any modules, they just write everything from scratch.

      Reiventing all the wheels is of course another viable op
      • 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 email handling bundled in their standard library.

        That's also one reason why PHP users require few modules--they have a ridiculously extensive standard library.

        I agree that it's better to spread the work out on libraries across the community, though. It just m
        • 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 write Bugzilla again tomorrow, it's not the language I would change, it's the database schema, relationships and workflow - I'd be looking at closer integration with project documentation (specifications, screenshots, UML documentation), version control and

      @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-tracker, not a project management system, so we don't work on those other things. If we had three times as many programmers, and we had them consistently available, we could consider branching out into those project-management areas, but right now our focus
    • 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 []. It's a breeze to install too.

      Off the top of my head, you could also take a peek at how Krang [], Bricolage [], and *cough* RT [] *cough* have handled the module install issue.
  • 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 can read C and could pull something off in it if required, and have done a few small projects in it).

    However, that's actually one of my primary objections to Perl--that it takes so much. You could say, "Every language takes that long!" But I don't think it
    • 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 important reason, but I do think you've reached a truth.

      Some of the defaults in Perl 5 are wrong. Some of them (particularly in the area of OO) are wrong in the sense that they don't work (SUPER:: is particularly broken for all but the simplest uses). Others a

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

      • 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 quick look, and bugzilla still lacks any real OO design, wouldn't know a design pattern if it jumped up and down shouting "I'm an iterator" and still suffers badly from NIH.. heck even copy and pasting CPAN modules directly would be better than some of wheel

        @JAPH = qw(Hacker Perl Another Just);
        print reverse @JAPH;