What do you need to have to be considered a Master at Perl?

Discussion in 'Perl Misc' started by sln@netherlands.com, Jan 15, 2009.

  1. Guest

    I'm just going to jumstart the topic with these:

    - Technically expert at Regular Expressions
    - Analytically and Creative at Regular Expressions
    - Thoroughly adept at map/split/grep, know limitations
    - Arrays and Hashes, including slices and references

    Add some more...

    sln
    , Jan 15, 2009
    #1
    1. Advertising

  2. Tim Greer Guest

    wrote:

    > I'm just going to jumstart the topic with these:
    >
    > - Technically expert at Regular Expressions
    > - Analytically and Creative at Regular Expressions
    > - Thoroughly adept at map/split/grep, know limitations
    > - Arrays and Hashes, including slices and references
    >
    > Add some more...
    >
    > sln


    And a lot more...
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
    Tim Greer, Jan 16, 2009
    #2
    1. Advertising

  3. Guest

    On Thu, 15 Jan 2009 17:46:48 -0800, Tim Greer <> wrote:

    > wrote:
    >
    >> I'm just going to jumstart the topic with these:
    >>
    >> - Technically expert at Regular Expressions
    >> - Analytically and Creative at Regular Expressions
    >> - Thoroughly adept at map/split/grep, know limitations
    >> - Arrays and Hashes, including slices and references
    >>
    >> Add some more...
    >>
    >> sln

    >
    >And a lot more...


    Some more, add some

    sln
    , Jan 16, 2009
    #3
  4. Tim Greer Guest

    wrote:

    > On Thu, 15 Jan 2009 17:46:48 -0800, Tim Greer <>
    > wrote:
    >
    >> wrote:
    >>
    >>> I'm just going to jumstart the topic with these:
    >>>
    >>> - Technically expert at Regular Expressions
    >>> - Analytically and Creative at Regular Expressions
    >>> - Thoroughly adept at map/split/grep, know limitations
    >>> - Arrays and Hashes, including slices and references
    >>>
    >>> Add some more...
    >>>
    >>> sln

    >>
    >>And a lot more...

    >
    > Some more, add some
    >
    > sln


    You listed map/split/grep and mentioned regular expressions. You then
    mentioned arrays, hashes and slices/references. That's pretty
    rudementary. There is a heck of a lot more someone would need to know
    (well) to be considered an expert. I don't see the point of listing a
    ton of things, and it's hardly about listing things that would actually
    define someone as an expert (or "master") anyway. I don't see the
    purpose of this thread, so I won't post to it again.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
    Tim Greer, Jan 16, 2009
    #4
  5. Tim Greer <> wrote:
    [I don't see posts from robic0 aka sln, therefore answering to you]
    > wrote:


    >> Some more, add some


    Trivial: please see "perldoc perl" for a comprehensive list.

    jue
    Jürgen Exner, Jan 16, 2009
    #5
  6. >>>>> "sln" == sln <> writes:

    sln> I'm just going to jumstart the topic with these:
    sln> - Technically expert at Regular Expressions
    sln> - Analytically and Creative at Regular Expressions
    sln> - Thoroughly adept at map/split/grep, know limitations
    sln> - Arrays and Hashes, including slices and references

    Someone who doesn't say:

    "Post all your souce code to.. trashbin.com "

    perhaps. Or

    "There is no such thing as a C++ program. There are only programs
    written in C++ (or other languages). "

    Or even ask the question:

    "I need to permute the 26,25,24,... letters of the alphabet. "

    :)

    --
    Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
    <> <URL:http://www.stonehenge.com/merlyn/>
    Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
    See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
    Randal L. Schwartz, Jan 16, 2009
    #6
  7. cartercc Guest

    On Jan 15, 6:06 pm, wrote:
    > I'm just going to jumstart the topic with these:
    >
    > - Technically expert at Regular Expressions
    > - Analytically and Creative at Regular Expressions
    > - Thoroughly adept at map/split/grep, know limitations
    > - Arrays and Hashes, including slices and references


    From time to time I apply for different jobs, not really needing a new
    job but looking for better opportunities, and twice I have gotten as
    far as taking a Perl programming exam. I'm not a real programmer but
    have done a fair amount of web stuff, database stuff, sys admin, and
    data processing, and don't consider my skills exceptional.

    In both exams, I placed in the top quintile, which surprised me very
    much. In both cases, I had made it through two rounds of interviews.
    My take is that there must be a lot of people who claim to know Perl
    but maybe they don't.

    I've been using Perl consistently for about ten years, and I guess if
    you do anything for that long you tend to develop some skill at it.

    CC
    cartercc, Jan 16, 2009
    #7
  8. Sherm Pendley <> wrote:
    > writes:
    >
    >> I'm just going to jumstart the topic with these:
    >>
    >> - Technically expert at Regular Expressions
    >> - Analytically and Creative at Regular Expressions
    >> - Thoroughly adept at map/split/grep, know limitations
    >> - Arrays and Hashes, including slices and references
    >>
    >> Add some more...

    >
    >Someone who understands the Chomsky hierarchy, and why not every context-
    >free language can be described with a regular grammar.


    :))

    YMMD

    jue
    Jürgen Exner, Jan 16, 2009
    #8
  9. rabbits77 Guest

    Sherm Pendley wrote:
    > writes:
    >
    >> I'm just going to jumstart the topic with these:
    >>
    >> - Technically expert at Regular Expressions
    >> - Analytically and Creative at Regular Expressions
    >> - Thoroughly adept at map/split/grep, know limitations
    >> - Arrays and Hashes, including slices and references
    >>
    >> Add some more...

    >
    > Someone who understands the Chomsky hierarchy, and why not every context-
    > free language can be described with a regular grammar.

    BFD, that describes just about every CS undergraduate who has taken
    a theory course.
    Unfortunately, I think you might be surprised to learn that CFLs aren't
    that impressive a concept. :-/
    rabbits77, Jan 16, 2009
    #9
  10. Tim Greer Guest

    cartercc wrote:

    > In both exams, I placed in the top quintile, which surprised me very
    > much. In both cases, I had made it through two rounds of interviews.
    > My take is that there must be a lot of people who claim to know Perl
    > but maybe they don't.


    You will pretty much find that's the case with any language. Due to
    this, sometimes a qualified programmer doesn't get a job in those
    cases, because the current "programmers" are threatened by you. Also,
    because the current programmers have convinced the equally clueless
    boss, that their methods are best. Those are the jobs that few
    qualified programmers want, because you are actually forced to work in
    bad code and they won't want to change it (or see a need to). That's
    when you start encountering companies that think AWS is the future,
    because no one actually had to program (you just pay a service online
    for the data transfer, disk space, the number of requests, and use of
    their service).
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
    Tim Greer, Jan 16, 2009
    #10
  11. >>>>> "r" == rabbits77 <> writes:

    r> Sherm Pendley wrote:

    >> Someone who understands the Chomsky hierarchy, and why not every
    >> context- free language can be described with a regular grammar.


    r> BFD, that describes just about every CS undergraduate who has
    r> taken a theory course.

    Then why do they ask so many questions about parsing (X|HT)ML with
    regular expressions?

    Asnwer: because they don't *really* understand it, having just learned
    enough to pass the exam and then forgotten it the next week.

    Or because they never had the theory course in the first place.

    r> Unfortunately, I think you might be surprised to learn that CFLs
    r> aren't that impressive a concept. :-/

    Impressive, no. But understanding the difference between regular
    languages and context-free languages, even if it isn't in those terms,
    is the mark of a professional.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Jan 16, 2009
    #11
  12. rabbits77 <> wrote:
    >Sherm Pendley wrote:
    >> writes:
    >>
    >>> I'm just going to jumstart the topic with these:
    >>>
    >>> - Technically expert at Regular Expressions
    >>> - Analytically and Creative at Regular Expressions
    >>> - Thoroughly adept at map/split/grep, know limitations
    >>> - Arrays and Hashes, including slices and references
    >>>
    >>> Add some more...

    >>
    >> Someone who understands the Chomsky hierarchy, and why not every context-
    >> free language can be described with a regular grammar.

    >BFD, that describes just about every CS undergraduate who has taken
    >a theory course.


    Exactly. You _almost_ got the joke.

    jue
    Jürgen Exner, Jan 16, 2009
    #12
  13. The Seven Stages of a Perl Programmer (was: Re: What do you need to have to be considered a Master at Perl?)

    <> wrote:

    > Subject: What do you need to have to be considered a Master at Perl?



    For me, they must first get past these prerequisites about the
    two "weird things" that are in Perl, but not in any other
    programming language (AFAIK):

    context (scalar vs. list)

    two completely separate systems of variables (package vs. lexical)

    If they get past those, then proceed to the ones below. :)



    I can't find Tom Christiansen's original, so I'll go with Nat's
    reconstruction of:

    The Seven Stages of a Perl Programmer


    (From http://prometheus.frii.com/~gnat/yapc/2000-stages/)

    Novice:
    * Thinks CGI and Perl are interchangeable terms.
    * Still thinks Perl looks like bad C code viewed over a noisy modem.
    * Is insecure about the concept of dollar signs and at signs.
    * Thinks Perl should be more like sh or tcl.
    * Has heard of the ``Unix mindset'', but hopes it's a treatable condition.
    * Can't figure out how to read input from the keyboard.
    * Thinks regular expressions are somebody cursing.
    * Wonders why no one can give him a straight answer about whether
    Perl is compiled or interpreted.

    Initiate:
    * Has begun to learn about $_* and doesn't like it one bit.
    * Thinks the -w flag is a waste of time.
    * Thinks Perl should be more like C++ or Java.
    * Is still trying to figure why Perl has two different kinds of arrays.
    * Knows how to use perlbug, but sends in bogus bug reports.
    * Has been bitten by implicit context conversions, but hasn't caught
    on yet to how it was triggered.
    * Can't keep == separate from eq, and still thinks that + should
    concatenate strings.

    User:
    * Thinks Perl is just for text processing.
    * Uses the Perl debugger.
    * Has used other people's modules.
    * Wonders what an object is.
    * Knows their way around CPAN.
    * Knows the difference between local and my.
    * Uses <DATA>.
    * Is still trying to figure what references are for.
    * Thinks Perl should be more like scheme or eiffel.
    * Submits real bug reports with perlbug.

    Adept:
    * Write JAPHs to impress their friends and annoy their coworkers.
    * Begins all programs with use strict.
    * Thinks Perl should just be Perl.
    * Has taken enough advantage of cryptocontext to annoy others.
    * Knows how to create records and objects with hash refs.
    * Uses syscall to get at undocumented operating system calls.
    * Curses the flexibility of the Perl object system.
    * Uses /e in substitutes.
    * Has begun to wonder what typeglobs are for.
    * Has written their own modules in Perl.
    * Begins to look at all data in terms of regular expressions.
    * Understands why regexes can't match nested data.
    * Rewrites minor utilities in Perl.

    Hacker:
    * Writes games in Perl.
    * Has written extension modules in C.
    * Uses AUTOLOAD and closures in curious ways.
    * Appreciates the aethetics of the Schwartzian Transform.
    * Delights in the flexibility of the Perl object system.
    * Has written their own pod2XXX translator.
    * Understands the output from Perl -D flags.
    * Accesses the Perl symbol table directly.
    * Submits bug reports with working patches.
    * Edits files using a special Perl-embedded version of vi or emacs.
    * Has contributed modules, manpages, and tools to the standard
    Perl distribution.

    Guru:
    * Can answer any Perl question instantly.
    * Can write anything in Perl, and does.
    * Takes advantage of undocumented language features.
    * Writes code that gives even Larry pause.
    * Implements opaque objects and compiled regexes using closures.
    * Can read and understand the output of the perl-to-C compiler.
    * Embeds Perl interpreters in larger applications.
    * Has written their own -d:debugger module.
    * Used object-oriented programming before it existed.
    * Is debating taking their turn with the patch pumpkin.

    Wizard:
    * Is on a first-name basis with Larry's wife.
    * Has written or rewritten major subsystems of the Perl compiler or interpreter.
    * Is thinking about rewriting the regex engine, the memory allocator,
    or the garbage collector.
    * Doesn't write games in Perl because they realize that Perl is the game.


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
    Tad J McClellan, Jan 17, 2009
    #13
  14. Re: The Seven Stages of a Perl Programmer (was: Re: What do youneed to have to be considered a Master at Perl?)

    On 2009-01-17, Tad J McClellan <> wrote:
    > <> wrote:
    >
    >> Subject: What do you need to have to be considered a Master at Perl?

    *SKIP*
    > I can't find Tom Christiansen's original, so I'll go with Nat's
    > reconstruction of:
    >
    > The Seven Stages of a Perl Programmer
    >
    >
    > (From http://prometheus.frii.com/~gnat/yapc/2000-stages/)
    >

    *SKIP*
    > * Understands why regexes can't match nested data.


    If I got that right, it's not the case any more.

    > * Rewrites minor utilities in Perl.


    Hmm...

    *CUT*

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Jan 17, 2009
    #14
  15. Tim McDaniel Guest

    In article <>,
    ~greg <> wrote:
    >The perlre section on (??{code}) warns that
    >
    > Recursing deeper than 50 times without consuming
    > any input string will result in a fatal error. The maximum
    > depth is compiled into perl, so changing it requires a
    > custom build.

    ....
    >If the warning had said "recursing deeper than 50 times...will result
    >in a fatal error" then I would have felt I understood it.


    If I read that, I would assume that the coder had alocated a
    fixed-size stack of 50 elements. (I'd say that the design was
    inferior to one without a fixed small limit, of course.)

    >What I do not understand is how "consuming ... input string" could
    >change the situation.


    I strongly suspect it's a heuristic. It's not that the code could not
    recurse deeper in that case or others. It's that the designer chose
    to forbid this particular case. "Without consuming any input string"
    means that for 50 calls, the recursion made absolutely no progress.
    They figured that, if it's made no progress in 50 recursions, it's
    never going to make progress. It's a rule-of-thumb intended to stop
    an infinite recursion that's going nowhere, before it sucks down all
    of available memory, and sucks down oodles of time filling it.

    As an analogy, it's like the pseudocode

    ping -c 1 -w 1 $MY_ISP
    if exit code was not 0,
    die with an error saying that we can't reach Internet host $MY_ISP

    Maybe the machine's network connection was flaky or just coming up.
    Maybe if I'd instead had it ping 2 times (-c 2) or take 2 seconds to
    check (-w 2), it would have gotten a response. But I chose a
    rule-of-thumb: if we can't get one ping packet back in one second,
    the network is deemed to be unusable.

    --
    Tim McDaniel; Reply-To:
    Tim McDaniel, Jan 18, 2009
    #15
  16. Re: The Seven Stages of a Perl Programmer (was: Re: What do you need to have to be considered a Master at Perl?)

    Eric Pozharski <> wrote:
    > On 2009-01-17, Tad J McClellan <> wrote:


    >> The Seven Stages of a Perl Programmer



    >> * Understands why regexes can't match nested data.

    >
    > If I got that right, it's not the case any more.



    The seven stages is circa 1997.


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
    Tad J McClellan, Jan 18, 2009
    #16
  17. Re: The Seven Stages of a Perl Programmer (was: Re: What do youneed to have to be considered a Master at Perl?)

    On 2009-01-17 22:04, Eric Pozharski <> wrote:
    > On 2009-01-17, Tad J McClellan <> wrote:
    >> <> wrote:
    >>> Subject: What do you need to have to be considered a Master at Perl?

    > *SKIP*
    >> I can't find Tom Christiansen's original, so I'll go with Nat's
    >> reconstruction of:
    >>
    >> The Seven Stages of a Perl Programmer
    >>
    >> (From http://prometheus.frii.com/~gnat/yapc/2000-stages/)
    >>

    > *SKIP*
    >> * Understands why regexes can't match nested data.

    >
    > If I got that right, it's not the case any more.


    Right. I expected a point "has figured out how to match nested data with
    regexps" in one of the later stages, but it wasn't there ;-).

    hp
    Peter J. Holzer, Jan 18, 2009
    #17
  18. On 2009-01-17 22:29, ~greg <> wrote:
    > Jürgen Exner > ...
    >> Sherm Pendley > ..
    >>>Someone who understands the Chomsky hierarchy,
    >>> and why not every context-free language can be
    >>> described with a regular grammar.

    >>
    >> :))
    >>
    >> YMMD

    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > I looked it up:
    >
    > Acronym Definition
    >
    > YMMD You Made My Day
    > or
    > YMMD Your Mileage May Differ


    The latter is rare. It is normally written

    YMMV Your Mileage May Vary

    So you can assume that the former was meant.

    > However, whether "recursive regular expressions" is an oxymoron,
    > or whether perl forces us to expand the definition of "regular expression",
    > isn't the sort of terminological question that could ever bother me.


    But as a Perl programmer, should be aware that Perl regexps are not
    regular expressions in the mathematical sense.

    hp
    Peter J. Holzer, Jan 18, 2009
    #18
  19. Re: The Seven Stages of a Perl Programmer (was: Re: What do you need to have to be considered a Master at Perl?)

    "Peter J. Holzer" <> writes:



    >>> (From http://prometheus.frii.com/~gnat/yapc/2000-stages/)
    >>>

    >> *SKIP*
    >>> * Understands why regexes can't match nested data.

    >>
    >> If I got that right, it's not the case any more.

    >
    > Right. I expected a point "has figured out how to match nested data with
    > regexps" in one of the later stages, but it wasn't there ;-).


    It's on slide 35.

    //Makholm
    Peter Makholm, Jan 20, 2009
    #19
  20. Vicky Conlan Guest

    According to <>:
    >From time to time I apply for different jobs, not really needing a new
    >job but looking for better opportunities, and twice I have gotten as
    >far as taking a Perl programming exam. I'm not a real programmer but
    >have done a fair amount of web stuff, database stuff, sys admin, and
    >data processing, and don't consider my skills exceptional.
    >
    >In both exams, I placed in the top quintile, which surprised me very
    >much. In both cases, I had made it through two rounds of interviews.
    >My take is that there must be a lot of people who claim to know Perl
    >but maybe they don't.


    Having marked Perl tests a few times in the last year or two, I'm not
    at all surprised you scored higher than you expected. The fact that
    you are willing (and able!) to read a Perl newsgroup is quite a good
    start. I've had people apply for software engineer jobs who couldn't
    write a simple* regular expression. Quite frequently, actually.

    (Although my last set of tests were actually a much higher standard,
    give or take, than I've seen for years, so perhaps the job market is
    shaking a few of the more competent coders into availability at last!)

    Also, don't forget that a lot of people's performance would probably
    suffer from the general nerves of "being in an interview/test situation".

    --
    Vicky Conlan, Jan 20, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. WangQiang
    Replies:
    6
    Views:
    380
    Mitch
    Mar 18, 2006
  2. WangQiang
    Replies:
    12
    Views:
    464
    Nick Craig-Wood
    Mar 20, 2006
  3. WangQiang
    Replies:
    0
    Views:
    260
    WangQiang
    Mar 18, 2006
  4. WangQiang
    Replies:
    1
    Views:
    311
    chenchen
    Mar 18, 2006
  5. WangQiang
    Replies:
    1
    Views:
    92
Loading...

Share This Page