The proper spelling of Perl is no indication of whether a person knows the language. A person can know a language and still miss some of the meta-information about the language, such as how it is customarily spelled. Judging a person's Perl skills by how s/he spells it is overly simplistic.

Judging a person's Perl skills by how s/he spells it is overly simplistic.

I'd never judge a person's skills by how they spell the language. However, it's a useful clue about how useful they will be to me, which is a lot more than just their skill from having studied the book.

Most of what I do when I program isn't about remembering the technical things about Perl. It's about finding answers to the things that aren't just about the language, like is there a module that helps me with this, or how do I link to that library, or can I find a framework to leverage.

For that, you gotta be plugged in to the community, and because of that, you know that it's never spelled "PERL".

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

> Most of what I do when I program isn't about remembering
> the technical things about Perl. It's about finding
> answers to the things that aren't just about the
> language, like is there a module that helps me with
> this, or how do I link to that library, or can I find
> a framework to leverage.
>
> For that, you gotta be plugged in to the community, and
> because of that, you know that it's never spelled "PERL".


Oh come on. Why would someone who is "plugged in" to the community have to subscribe to every single belief? Judging someone based on how thye write the word is absurd and in reality, very few people actually really care that much.

And for the record, Larry Wall, in a 1999 Linux Magazine expressly stated that "Perl not only stands for Practical Extraction and Report Language", which is something many community regulars who argue against the usage of PERL actively ignore in order to make their points work at all.

They completely ignore that that meaning can be written as PERL, just as many people write TMTOWTDI instead of writing it out in full. And isn't the tabooifiing of "PERL" contrary to the core belief of TMTOWTDI?

Markup added by GrandFather. See Writeup Formatting Tips

Oversensitivity to the casing of perl is just an affectation. And like most affectations it serves only to delineate the "cool" crowd from the "uncool".

Haah ha! She wears glasses.

Haah ha! He's wearing Nike Air Total Package Lows. They are just soo last week!

That is not to say that I wouldn't, but there is another thing to consider. I am a sysadmin and not a programmer. I write a little Perl code and heavily use CPAN for wheels that should not be recreated. I just don't program on a regular basis and doubt that my programming would ever be good enough to give back to CPAN at any level what I have extracted from it.

I am a monk, I sit here and (mostly) feel like I am lurking in programming discussions that I understand but don't program enough any more to actually solve. I vote and occasionally participate in discussions but being a non-programmer these days it is mostly just my opinions more than actual programming help.

The community is large and strong. I just suspect that there are many, many more people in my shoes than in the shoes of the people who actually have the skills to donate back to the community.

I also cannot contribute to CPAN.

Maybe not for the same reasons, but for my own.

Although immediate supervisors agree that taking without giving is not nice, the beauracracy is such that I will never be given permission to publish anything that I do at work on any open source forum. (I've been pushing for almost a year).

Since I have a home life (kids, hobbies, husband (only one)), I do not wish to spend my time ignoring my family while programming stuff for CPAN. Besides, it might be legally difficult to differentiate between this work and the work I do at work.

My own moral dilema about taking and not giving back in turn is satisfied by: (a) repeatedly telling my bosses that we are using the sweat of others for our own gain, (b) providing other perl help wherever I can.

Sandy

You are able to give back to CPAN, maybe not perl code but that's not all there is.

For example, what if you find a bug in a module? Or something you believe is a bug? You can always mail the module maintainer and inform him about it. After which he can look at it and fix the bug.

You could also try to create a little test-case/script and send it along with your bug report so that the maintainer can easily check if the bug is fixed and perhaps include the test in the distribution. (To make sure the bug is fixed once and for all.)

Another thing you might be able to do is mail the module maintainer about a unclear statement that is too unclear in the docs. You said it yourself, you are not a programmer, perhaps the programmer who wrote it considers it to be too obvious to add a bigger explanation?. Perhaps you don't understand all the constructs used in the module's documentation, perhaps the examples need to be easier, ...

If you do that then you are indeed not contributing code or modules to CPAN but you certainly are contributing to CPAN (IMHO).

And thus, by my definition, you're not "into" Perl, in the way that I would look for if I were hiring a Perl hacker to work for me.

There's nothing wrong with that. This discussion started by trying to sort out why "PERL" is bad on a resume. It's a red flag for me, because it means you're not "into Perl". I probably wouldn't even return that guy's call.

I'm not sure why people are freaking out about this. It's about respect of the culture, which I consider an essential component for being a good Perl programmer.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I see, you are using a much narrower view of being "into" Perl than I was.

I'm "into" using Perl and keeping up on the recent developments. You, on the other hand, were referring to being "INTO" Perl. :-)

-Kurt

There are two major consequences of this. First of all, since you are judging on highly incomplete information, your prejudices are guaranteed to sometimes lead you to make wrong decisions. Secondly, since we are often in a position where we need to make decisions based on partial information, we need at least some prejudices.

So the question is whether it is a worthwhile prejudice to make a snap judgement about people and companies that say PERL. It is definitely a prejudice. It is definitely sometimes wrong. But is it worthwhile to make this facile judgement?

My personal belief is that in most situations it is worthwhile. Let me invent some sample figures and run some numbers to justify it.

Sturgeon's law says that 90% of everything is crap. He was probably an optimist. But let's say that he's right. Let's say that 3/4 of bad Perl programmers (and jobs) say PERL, while 3/4 of the decent ones say Perl. Then over 96% of people who say PERL are bad, while 1/4 of people who say Perl are decent. Given that 70% of people say PERL, this rule really improves your chances of finding a decent programmer (or job, depending on how you use this) after a relatively short search. Yes, you'll make mistakes. But this isn't proving to be a bad initial filter.

Now if I'm really motivated, I'm going to plumb that remaining 70% for that the 3.6% or so of decent possibilities in the pot that I'll otherwise miss. But in real life I'm rarely so motivated.

Yes, I know that means that I'll miss good people. Yes, I know that it is horribly unfair to those I'll overlook. But life isn't about being perfect, it is about making reasonable trade-offs. In fact trying to be perfect is itself an unreasonable trade-off - you wind up putting too much work out for too little reward.

So your anecdote notwithstanding, I'll continue to apply this prejudice in all situations other than ones where I think that the effort of an exhaustive search is worthwhile.

Let me say up front that I am not accusing you of anything, nor do I have any reasons to believe that you would subscribe to anything that follows in any way whatsoever.

Isn't it a slippery slope from what you are saying above to

• Women make lousy programmers, and they will want to take leave to have kids anyway, so we can discard any applications from them. That'll cut the pile.

  Or

• Overseas universities have much lower standards than domestic ones, so the degrees from there aren't worth the paper they are written. Discarding applicants with those will trim the pile.

  Or any number of other, many more obvious, pre-judgement criteria?

  All of which would be equally, ethically dubious. Some of which are, in most countries, outright illegal.

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

  "Science is about questioning the status quo. Questioning authority".

  In the absence of evidence, opinion is indistinguishable from prejudice.

Yes, there is a slippery slope. And it isn't a long one, either.

An better example than the ones that you gave is the following, "Blacks are admitted and then get preferential treatment in universities thanks to affirmative action, so we should not consider their degrees to be as good."

I consider this to be better because virtually any educated American whose eyes are open has seen this happen. Far from every black, not even a majority, but there are plenty of painfully bad examples walking around. By contrast I can't say that I've seen any evidence that the women who are interested in programming are significantly worse than the men who are interested in programming. And my personal experience with people who got degrees overseas has been very good.

So I've admitted that this line of thought can lead to horrible conclusions. Obviously nobody reasonable would want to say them. (At least not in public.) But is it wrong?

My answer is that, on a personal level, it is not wrong. Even the reverend Jesse Jackson has admitted that when he is walking down a dark street, he worries more if he is being followed by a black man than a white man. A glance at US crime statistics strongly suggests that this is a fairly reasonable concern. Trying to deny that this is factually the case may make us feel good, but it is intellectually dishonest.

But on a societal level, it is very bad. It creates and perpetuates a permanent underclass. It leads to a nasty cycle where lack of opportunity creates conditions that reinforce the biases that cause the original lack of opportunity.

A major job of government is to make people act in ways that benefit society as a whole when those people individually would not act that way. For instance I know that my personal financial contribution makes an imperceptable difference to how good the roads I commute on, while keeping my money makes a huge difference to my life. Therefore government makes me contribute, by charging me taxes and then spending it on roads. (For more on the intrinsic problems with supplying public goods I heartily recommend The Logic of Collective Action.)

When you combine these facts it makes perfect sense for government to force people not act on certain prejudices that they may have. Which it does - as evidenced by the laws you mention. (The fact that we need such laws is evidence that the issues are not about to trivially resolve themselves.) And I personally support these laws because I think that they are a good thing.

In short, there are reasonable prejudices that I don't want people acting on. But there are also reasonable prejudices that I don't mind people acting on. Where do I draw the line?

I personally mostly draw the line based on how easy it is for someone you're prejudiced against to fix the issue. If you're black, you aren't changing that (OK, Michael Jackson did...) so I don't want people acting on that prejudice because it locks you into a ghetto. OTOH if you don't know how Perl is supposed to be capitalized, it is trivial for you to change that. Therefore I feel that my stigmatizing you for that fact is not a significant barrier to you.

I say mostly because I also find it very reasonable to be prejudiced against people because of characteristics that directly affect performance. The canonical example is that you don't pick short people to be basketball players. Now perhaps the short person actually is better. But physical height is such a direct factor in your ability to play basketball that it is going to be very hard for you to overcome that handicap.

A big difference between the Perl/PERL prejudice and the ones you've posted (aside from the fact that yours cannot rationally be defended as being accurate IMO) is that it concerns something someone does as opposed to something someone is. Using the wrong case when spelling perl is a mistake, same as a syntax error when programming. If I were employing programmers or looking at a prospective boss, I would prefer candidates who do not habitually make syntax errors, and that is a perfectly valid prejudice to have.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

The distinction between perl and Perl is optional, according to perlfaq1. (I wouldn't use PERL though as someone will jump on you if you do.)

Maybe it was just a typo!

Although sometime the cleverest people are afraid to ask the simplest of questions

You can go for years with small but glaring gaps of knowledge

Some people are Pretty random or lazy with their use of caps anyway. JAVA java PYTHON Python c++ C MySql MYSQL .Net you usually know what they mean really.

...unless, of course, it's in the shebang line.

Seriously, though, in casual reference I hardly ever say 'Perl' ... I'd guess I instinctively type 'perl'. I loathe 'PERL', though.

Cheers,
Matt

it's just that he's not into the Perl community and doesn't know certain things...

There's a difference between being passionate about something and being knowledgeable about something. Though I think Perl attracts more people who are passionate then some other languages...

I disagree about people using CPAN and not contributing. I think people who benefit, should want to contribute and should if there able, but I don't think it's a mandate.

If Linux finally gets a large share of the desktop space, would end users be in the wrong for not subscribing to the kernel lists or submitting patches?


-Lee

perl digital dash (in progress)

The Linux desktop is not a programming language. I would expect Linux developers to be aware of the various Linux programming community areas. I would not expect Aunt Sally in Accounting using Linux on her desktop to be aware of such things, any more than I would expect a match.com user to have a Perlmonks handle.

However, I would expect the programmers of match.com to have a Perlmonks handle, and know about rt.perl.org, and so on. That's what I'm arguing here. To be an effective Perl programmer, you're in the community because that's part of being an effective Perl programmer. Hence, the "PERL" shibboleth is valid, as far as I'm concerned.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

My first response to your post as a lifelong antisocial non-joiner of things was unthinking disagreement, until I thought for a minute about my progress in Perl.

I had been using Perl for a couple of years before contributing to CPAN and then ending up a regular here, and I think my Perl (and programming knowledge generally) has shifted into a new (and much higher) gear since I started engaging with the community. Plus of course I now have a better idea of just how much more there is to know.

Engaging with the community is the difference between a programmer who blindly relies on the tools provided in the form of published modules, and hence works always within external constraints; and one who really knows that, if they find a bug or shortcoming in a CPAN module, they can fix it themselves. Put in vaguer but more general terms, the horizons of a community connected perl programmer are probably broader.

As an added bonus, it's probably fair to say that a perl-er who engages with the community is more likely to have a more realistic assessment of their own skill level than one who doesn't.

I'm not sure it's entirely true to say that one can't be 'into' Perl without engaging with the community, in the sense of being an enthusiast for the language, but it seems likely that one could reasonably expect higher standards from someone who does.

To address cogs point, sometimes it seems that monks make too much of the correct capitalisation of perl/Perl/PERL. Personally, I often miss out the initial capital when posting because I'm so used to typing:

perl myscript.pl

--------------------------------------------------------------

"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."

John Brunner, "The Shockwave Rider".

I've seen estimates of the number of Perl programmers to be somewhere between 100,000 and 1,000,000. My estimate is that the number of people that are part of the "community" are at most a few thousand, of which most aren't "making a contribution".

If I look around me at my current employers, and several of my previous employers, there are Perl programmers (and people programming in Perl) at all of them. Except myself, none had any interest in participating in "the community".

Besides Perl, I also use (or have used) C, shell, Linux, Solaris, HP-UX, MySQL, Sybase, awk and a few other things a lot. I've never been involved in their communities either.

Perl --((8:>*

It's not cool to simply be tapping the CPAN because it's there.

Being cool and being effective are. for the most part, orthogonal concepts. Just ask the stereotypical 1950's accountant. :-) Speaking to the topic at hand...it it possible to become a very good Perl programmer armed with only the docs that come with perl and by having a take-only mindest with respect to CPAN. Does this disqualify that person from making informed hiring decisions with respect to Perl programmers? In my opinion, not at all.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

It's not cool to simply be tapping the CPAN because it's there

That's pretty dogmatic. It's an organic system with room for many roles: some people consume, some only occasionally produce, some produce full-time. As Larry says, there's more than one way to do it. There's no point demanding CPAN contributions from people who aren't in a position to make them, or who don't want to. If you want more CPAN contributions, work to ensure that contributing is easy, fun, and rewarding. --Nat

That sound's a lot like; If you wanna play with my ball, you gotta play by my rules.

If active participation in the vaunted "Perl community" is a prerequisite for using perl and CPAN, then that should be a clear and obvious part of the licence agreement.

It isn't. Why not?

Perhaps, because it would be "open source" if it were.

Can someone tell be the difference between perl, Perl, and PERL?? I've been using perl for close to 10 years now, written some really awesome applications, and haven't the slightest clue.

The OP really demonstrates why first impressions and assumptions should never be used to make a final decision or judgement.

Sorry :-)

perl is the compiler.

Perl is the language.

PERL is nothing (at least nothing in Perl context).

Of course there's always the chance that someone who is "plugged in" will start using PERL simply for the specific purpose of being iconoclastic and contrarian, or just to discredit certain viewpoints.

What? I'm shocked, just shocked to hear you say that people do things for the specific purpose of being iconoclastic and contrarian.

Cheers,

Brent


-- Yeah, I'm a Delt.

The language is 'Perl', the interpreter is 'perl'. At least on Unix systems. Which are the ones that matter to me.

-sauoq
"My two cents aren't worth a dime.";

so Perl , perl or PERL matters in this case.

Or not considering their resume simply because they haven't paid a diploma mill to get a certification?

Yes, this puts me at both sides of this argument. Certification sucks as a means of sorting candidates. PERL instead of Perl should be in the same category for me. Call me inconsistent. :)

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.