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!

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.

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. :-/

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!

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.

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.

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.

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.

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 ;-).

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".

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!