Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: A Perl aptitude test

by Aristotle (Chancellor)
on May 03, 2003 at 01:32 UTC ( #255219=note: print w/replies, xml ) Need Help??

in reply to A Perl aptitude test

To be honest, I find it hard to think of anyone who gets any of the questions other than #1 wrong as as fairly decent. At best, they know how to use Perl for a quick one off task (which is a pretty useful skill, no doubt), but I wouldn't rely on them for writing anything that has to be reliable.

#1 is not a waste of time at all, though I'd rather make it a bonus question. This specific parsing rule has certainly tripped up every Perl beginner at least twice, and probably plays a trick even on more advanced programmers once in a while. I know it took me quite a while to understand the semantics exactly. I'd consider someone who answers that question fairly capable at understanding Perl code (which includes their own) although it doesn't necessarily mean they are used to good coding practices (like strict).

Regarding strict, I would extend the question to also ask when it is not useful. Truly insightful coders know when to break the rules.

Similarly, in #5, I'd also ask for an explanation of $var = @array;, and for a comparison between the two.

Overall, I think the questions are decently chosen. I would consider someone who answers them all well unlikely to make a big mess with Perl.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: A Perl aptitude test
by tilly (Archbishop) on May 05, 2003 at 15:35 UTC
    I keep on seeing people saying this, and here I am thinking to myself, "Gee, and here I would only give myself even odds of getting #6 right." I know what the operator is for, I know how to use it perfectly well as a sort function, I know how to use complex combinations to do sorts on complex data.

    But do I know whether the comparison function is supposed to return a 1 or -1 to sort to say that the left side is smaller than the right this time...? I could guess but I never remember that. If I really need to know it, I can look it up any time. All that I need to know the vast majority of the time is that whatever way it goes, sort and the comparison functions agree on how it is done. (And this tidbit is of a kind I find hard - for instance I still have to think about whether in a LEFT JOIN the table you want to fill in blanks for should be on the left or the right.)

    EDIT AUG 2009 Somehow this node got badly messed up. I've filled in the end with what I think is my original thought, but it is unlikely to be right. :-(

      (Indeed anyone who develops an understanding of obscure constructs by constantly experimenting with how many language constructs they can use is a hazard to your code base...)

      Interesting viewpoint.

      Do you have a feel for which (perl) language constructs you would deprecate from your codebase?

      Would this be a single, hard & fast list or would it vary by codebase or project?

      Is it just knowing the obscure constructs that constitutes the hazard? Or does the person have to use them before they are guilty?

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        It varies by codebase, project, and most importantly, who you expect to work with and then maintain it later.

        The problem is that TIMTOWTDI is a maintainance headache. Anyone who wants to abuse it forces you to have all maintainance work done by someone who has more expertise than the regular programmer. Not the same, because someone who is merely the same may just know a different set of tricks, but better so that they are likely to know all of the tricks that the first show-off used.

        The answer is to decide which ways to do it you will settle for based on other factors, and to stick to them so that someone else can pick up the code and be brought up to speed in a reasonable amount of time. Having people who know lots more ways to do it is fine and good and may be a good thing (knowing your choices in advance makes it easier to pick a good set of choices to stick to), but actually using them all all of the time is a bad thing to do unless you are trying to be hard to understand.

Re: Re: A Perl aptitude test
by parv (Priest) on May 03, 2003 at 06:17 UTC
    Similarly, in #5, I'd also ask for an explanation of $var = @array;, and for a comparison between the two.

    Thanks Aristotle; you induced self doubt there given that i was also thinking of the value of a list being evaluted in scalar context.

    So i suppose, OP could add/replace a question something like..

    What are the values of $x and $y below? @odd = (1,3); $x = @odd; $y = (1,3);

    ...I feel much better now after consulting w/ perl.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://255219]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (3)
As of 2018-04-21 03:14 GMT
Find Nodes?
    Voting Booth?