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

S

sln

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
 
T

Tim Greer

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

Tim Greer

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

Randal L. Schwartz

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

:)
 
C

cartercc

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
 
J

Jürgen Exner

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

:))

YMMD

jue
 
R

rabbits77

Sherm said:
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. :-/
 
T

Tim Greer

cartercc said:
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).
 
C

Charlton Wilbur

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
 
T

Tad J McClellan

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

Tim McDaniel

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

Peter J. Holzer

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
 
P

Peter J. Holzer

Jürgen Exner > ...

~~~~~~~~~~~~~~~~~~~~~~~~~
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
 
P

Peter Makholm

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
 
V

Vicky Conlan

According to said:
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".

--
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top