PERL as shibboleth and the Perl community

[merlyn]

OK, having taking a beating in that recent thread, I realized the problem is that many separate things I believe were getting collapsed and miscommunicated. So, I've taken a moment to step back and try to get things to be more clear for myself.

Let's start with my ethics of open source. I believe that for open source to work, there must be give as well as take. Now the "give" might be in the form of code, but it doesn't have to be. For example, it could be participating in mailing lists or online forums, such as monks. It could also be bug reports or smoke tests. It could even be simply sending feature requests to developers, or working with conference coordination. Or perhaps just promoting open source within an organization.

Now, to be a member of the Perl community, I believe someone should have the open source ethic as I just defined it there (give and take). I also believe that someone should be aware of the existing docs, including reading the FAQ from time to time, and also reading good books. From here, we would see that being a member of the Perl community means you know that it's not PERL, because the FAQ says so, and the good books say so.

This leads me to the next phase: using PERL as a shibboleth to sort out whether a job-seeker or potential employer is plugged in to the community. I believe this is valid, because I believe that using Perl means being aware of perldoc, and the FAQ, and the FAQ talks about "PERL". Also, using Perl effectively means being plugged in to the community, and that also leads you to discover that nobody ever calls it "PERL". So, a resume that lists "PERL" is written by someone who isn't plugged in. And an employer who spells it "PERL" is either a third-party (which I hate to respond through, personally), or a work environment lacking the Perl community connection that I need to be happy.

Finally, as a completely separate topic, I would not hire someone who wasn't both good at Perl, and plugged in to the Perl community. Spelling it "PERL" would be sufficient evidence of failure of the second condition there. Do I expect every employer to follow my lead? Of course not. That's a personal conclusion. And can you be great at Perl without being a member of the community somehow? Most definitely, but that doesn't make up for the other requirement for my hiring.

So hopefully, that sorts out where I am a bit better. You may disagree with any part of this, but hopefully now we can discuss this using terminology that I failed to establish in that last thread.

[ptum]

I happened to be reading an old interview with Larry Wall today (http://old.lwn.net/2001/features/LarryWall/), and was encouraged by one of the things he said, in response to a question about Perl certification:

LW: snip My approach to language design has always been that people should learn just enough of the languages to get their jobs done. They shouldn't have to learn the whole language to begin with. But with certification, you have to be learning the whole language. Some people feel more comfortable that way. I guess if you want to hire experts, you want to make sure they're experts. Certification is useful for that. But most of the programming out there is not done by Perl experts. It's mostly done by Perl novices, and they sometimes make sloppy programs, that's ok. They learn by experience to do better over time and eventually they become experts and then, if they want to get certified and somebody wants to certify them, that's fine. I just don't want to do that myself.

Your choice of analogy is interesting, because as is recorded in Judges 12, the failure to correctly pronounce the word 'shibboleth' was a capital offense for those trying to cross the river and escape. Some folks are occasionally a little heavy-handed and hasty in reaching a negative judgment of those who are not privy to the inner mysteries, as we define them. I've often found that my idea of what is important has a high and rather suspicious correlation with my self-perceived proficiencies.

In view of this thread, I'm mildly embarrassed to admit that I never really gave any thought to the differences between "perl", "Perl" or "PERL". I guess I have simply picked up enough to get the job done without worrying too much about mastery. Happily, I don't like acronyms (a holdover from my Army days) so I think I've never strayed into this particular faux pas. Yet I have been at least a dabbler in Perl for the past eight years or so, and I'd hope that I would at least be considered in a hiring decision, based perhaps on my ability to produce working code, rather than my knowledge of Perl lore.

I recently worked for a major online retailer, where hiring is considered a top priority and where candidates are often dismissed for (what seemed to me to be) minor deficiencies. I felt that my experience as a developer was under-valued there and that other considerations were given too much weight in hiring and promotion decisions. I made a move to greener pastures when the chance came along, and am happily earning what I consider to be a good wage. Perhaps employers can and should be very choosy, hiring only those experts with true depth and breadth in their field -- but that kind of thinking seems to leave a lot of us working stiffs out in the cold.

Of course, if the job market tightens again, like those happy golden months of 1999 and 2000, then employers will perhaps be glad enough to take anyone who can even spell "Shibboleth." :)

[BrowserUk]

This reminds me of a story I was told while I was working in the Netherlands and failing miserably to learn to speak Dutch.

The story went that during WW2 amongst the Dutch resistance and partisan groups, the acid test for being a "het inheemse Nederlands" (native Dutch), was the ability to pronounce the word Scheveningen.

The fact that amongst the group party to the discussion, there were native Dutch speakers from Den Haag, ApelDoorn, Harderwijk, Maastricht, Groningen and Gent(*), and many of them would have been condemned as Nazi spies by their varying pronounciations of the town's name, rather diminished the impact of the shibboleth.

Oh darn. Now I've gone and and provoked Godwin's Law.

(*) For those who don't know, Gent, is in the Flemish speaking part of Belgium. Flemish is very similar to Dutch, suffiently similar that speakers of the two groups generally have no problems communicating even on quite deep and intellectual subjects. However, the biggest difference (as far as I am competent to judge as a non-speaker of either) is the pronounciation.

[mojotoad]

"member of the Perl community" is still the sticking point in this discussion.

I suggest some more vivid analogies which that phrase potentially straddles (list by no means complete):

• bonfire -- core group of overseers, caretakers, and log givers surrounded by a potentially large group of enthusiasts who use the warmth for their own ends. So to speak.
• fusion star -- supremely hot core with varying layers surrounding it where the fundamental concentration of energy radiates outward for all to enjoy. Of course, there's a really damn hot corona, but nobody knows what to make of those types and so tend to concentrate more on the planets that benefit from the warmth. But this example is way too close to Larry's onion speech so we'll just let this lie for now because it would take an essay.
• municipal water supply -- central caretakers and many beneficiaries, most of whom never reflect on the benefit. But, that's what you'd expect out of people that have partaken of the flouride.
• barn raising -- community effort with tangible results. Classic give and take, but it's not held against you if you live too far away or the wheel falls off of your carriage on the way.
• hell raising -- community effort with tangible results. Classic give and take, but it's definitely held against you by the larger community regardless of how large you think yours is. Like arrows of time, this illustrates the asymmetry of give and take. (antonym: stone soup)
• termite mound -- Community effort with tangible results. Classic give and take, but you're definitely eaten and reabsorbed by the hive if you even think of wandering off or hell raising. Interesting side effect: core temperature.
• crystalization -- core strength surrounded by frenetic activity adding to the structure. Like termite mounds, this has certain advantages but the core is less pleased by flexibility. Side risk: being deemed a salt and being consumed by higher life forms.
• Hollywood -- Active core that supplies a multitude of avid fans and industry players. Given the attention span of the fans and general social network topology issues, however, there is a vast surplus of potential 'In' people that can never pass muster no matter how strong their passion. Sort of like a termite mound with lots of queens that accept members only by fiat, occasional inheritance, or every now and then absorbing the cream of smaller ecosystems.
• gourmet kitchen -- Head chef, sous-chefs, anyone else stay the hell away and eat. See Hollywood, but with more pinnacles and lower pay.
• black holes -- the attraction is inevitable, given critical mass. All are the Community. If you want to raise hell, see next universe.
• cults -- the One True Way is evident. Participate. Like termite mounds, but with a hefty dose of persuasion rather than mere instinct. Ironically, whereas individuals can raise little hell, the cult as a whole can.
• financial circle jerk -- very similar to a cult, but the unifying blindness is couched in greed based on economic theories. Not as likely to raise hell as a cult.
• library -- passionate core caretakers who live only to share with non participants. Until they don't return something, that is.
• homebrewers -- loosely knit group of people that share a common interest at all skill levels, always willing to share what they know, always willing to learn from others who share their interest, and who, at the end of the day just have a darn fine time doing it. And perhaps raising a little hell.

Having said all that, if you use PERL on a job description or a resume, then you're a wanker.

Cheers,
Matt

[chromatic]

I agree about the shibboleth. I wouldn't hire a RHCE who couldn't spell "Red Hat" correctly or trust a company that claimed to support the Postgre or Postgres-SQL database. Occasionally, attention to details matter. (Hey, are you running dhcpcd or dhcpd? inetd or identd?)

[thor]

But that's the thing: in the cases you've given, the arrangement of letters is different, which would lead to different words. The difference between "perl", "Perl", and "PERL" is capitalization; their respective arrangements of letters is the same. I find it somewhat ironic that a trained linguist would have built in that much overloading into one word.

[TimToady]

Being a linguist does not prevent one from wanting to make fine distinctions when such distinctions are useful. Being a linguist also means that you understand it's okay to ignore those distinctions when they aren't useful. Case distinctions are particularly nice when you want to have it both ways. I have several T-shirts in my closet that say PERL, and yes, that does bother me just a little. Nevertheless, I do not refuse to wear them because of that. A linguist cannot afford to confuse utility with principle.

[chromatic]

Impress me with how much you know, your attention to detail, and how you're the right person for the job. Don't try to impress me with distracting, inappropriate "creativity" that just looks like sloppiness. Take me seriously as a potential employer or team lead and I'll take you seriously as a capable professional.

[gregor42]

But that's the thing: in the cases you've given, the arrangement of letters is different, which would lead to different words. The difference between "perl", "Perl", and "PERL" is capitalization; their respective arrangements of letters is the same.

OK then, we can use another example of something you wouldn't want on a resume:

therapist

vs.

TheRapist

[Mutant]

Your comments are fair enough. However, I think you may be underestimating the size and value of the group of programmers who use "PERL". They may have no interest in Perl other than as a tool to do their job (and by "job", I mean an *actual* job that they get paid for).

To them, Perl is just like C++ or Java or C# or whatever. They may not bother to take the time to thoroughly read all the docs or the latest books - they don't need to. They just read the parts that they need - they've learnt dozens of languages before, there's no need to read a FAQ unless they actually have a question (the question "how do you spell 'Perl' simply doesn't occur to them).

So the question is, are these people valuable to Perl? To me, the answer is: yes, of course! Even if they don't contribute to the community directly (ie. in any of the ways you list), the very fact that they are using Perl is of huge benefit. Maybe at some point they will enter into the community (either of their own accord, or on the advice of someone else). Maybe they'll introduce other programmers to Perl, and they'll enter the community. Maybe they'll advocate Perl just by saying "it's as good as anything else I've used".

If anything, these are the kind of people Perl desperately needs more of. We have plenty of people who are passionate about Perl. If nothing else, these sort of people demonstrate to the world that Perl hackers are not just blindly dogmatic.

[delegatrix]

Agreed. Although to me, these users are already part of the community. Are we really that snobby as to exclude them by default?

The 'perl community' as Randal defines it has long ignored perl users who just want to build applications with a tool that is available to them. They don't want to read forums, write modules, or go to conferences. They do their job without a lifetime committment to perl. These people are extremely valuable and it's that group that needs to expand.

Perl hackers need to come back down to Earth and realize that a meritocracy may be fine for core developers, but a wide user base is extremely important. The perl community is not just p5p or #perl.

[Perl Mouse]

I believe that for open source to work, there must be give as well as take.

Yes, but that doesn't mean everyone who takes needs to give as well. "No take unless give", that's the basis of commercial business - even if no money is involved, and even if the give is done under social pressure.

For open source to work, you don't need quantity in people providing. You need quality, and quantity doesn't imply quality. In fact, quantity might hinder the quality.

For instance, a forum where questions are asked and answered is more useful if a question receives just one or two answer of high quality than if it receives two dozen replies, a few high quality, lots of good answers, lots of mediocre answers, and a few really bad ones. (Which often happens on Usenet, Perlmonks and mailinglists).

An open source project doesn't suddenly fail if its number of users grows from 5,000 to 500,000, and none of the 495,000 new users "gives".

[hv]

I've been using the language for quite a while now, and have considered myself part of the community for a large part of that time. While I occasionally looked at specific parts of the FAQ when checking patches against it, it is many years since I read the whole thing - and when I last did, I'm sure I would have skipped past a question about the spelling of the language's name pretty quickly, as irrelevant tripe.

Because I don't care, and it doesn't matter, and life's too short.

Perlmonks is the only place that I regularly frequent where I often see people harping on about it, and I think it is the worse for it. But as with a person, a community has to be accepted warts and all, and when this wart itches too much I can always scratch it with a downvote or two to take my mind off the niggle.

I use perl and Perl pretty interchangeably except where I need to make the distinction clear for effective communication - and when I need to make it clear, there are better (albeit more verbose) ways to do so; I would not normally write PERL for the same reason as I don't write $OUTPUT_FILE - I find capital letters harder on the eye, and harder to read, than lowercase.

Hugo

[swimmingcartel]

I don't think that those were the things messed up in the previous thread. Based on the last thread, everyone already understood what you had said.

The real issue is that: on one hand, we understand and respect your passion towards Perl, and lots of us share the feeling with you; on the other hand, we respectfully disagree that everyone should behave in a required uniformed way.

The fun of Perl community or open source community is largely contributed by the freedom everyone feels and enjoys in such community. If we suddenly started to bound like other commercial societies, then we are losing the basic value we expected from such communities like Perl community or open source community.

Yes, it is good to contribute (code) to the community if one happened to have contributable and reusable code, but one is not forced to pursuit such code forcefully. One certainly is not disqualified from the community simply because he/she never contributed code, or time to test, or ...

I would like to say that the biggest contribution everyone had is to use Perl. The fact that you use it is the best confirmation that you love it! And the best indication to others (outside the community) that they probably should try it when there is an opportunity.

[tirwhan]

Anyone who has ever posted to a Perl forum/mailing list using "PERL" will more than likely have received a reply pointing out the mistake. Anyone who's spent some time reading these forums and lists will certainly have come across a thread discussing this issue. There are published books with reference to this spelling and the perlfaq has a piece on it. For someone to still use the spelling I can only think that either s/he has not been exposed to these resources enough (and I think it'd be hard to becomes a competent Perl programmer without that) or does not care enough to correct his mistake. Not caring about one's own mistakes is one of the things that really hold you back as a programmer and is a very annoying trait in a boss. We all do it to a certain extent, but letting it shine forth in job-related communication (which should be as professional as possible) is not good advertising.

So, I agree, PERL is a big warning flag. As with any rule, there are exceptions.

[MidLifeXis]

As with any rule, there are exceptions.

such as when your employer has a keyword system and the wank who insertet Perl into it thought it was supposed to be PERL.

[ambrus]

In the cb, we were at once talking about introducing a secret perl handshake to identify members of the community. We never realized we already have one. You just have to say Perl instead of PERL.

Update 2012-12-16: somewhat related is xkcd 1108: Cautionary Ghost.

[Articuno]

But, what if the programmers use Perl (and are into the Community), but the person who typed the "job request" (*) thought that when the boss said 'Perl' he meant 'PERL' (or even Pearl, who knows :-) and "corrects" the text before publishing ? (or maybe qr/s?he/ typed in CAPS to "highlight" (*) the word)

Now, if the employer always uses PERL consistently (*), then I think it's ok to use it as a "shibboleth" (**)

(*) Disclaimer: English isn't my first language - I don't know the right qr/words?/i ^_^;;;

(**) Coincidence: I saw that word on WikiPedia yesterday :-)

[Jenda]

I once saw an ad looking for a programmer in Pearl and Jawa ;-)

[phaylon]

I'm really wondering what this is all about. Are people here *really* arguing against merlyn's opinion with the argument that everyone should have his own opinions?


• It is absolutely not necessary that my company cares how I write the term "perl." Hell, they even say I shouldn't use "map" so they don't get confused. So that is nothing they would count on.
• Personally, as someone who has a toe in the community, I'd rather hire someone that knows the difference between "Perl" and "perl." But that's just an example. If I have the feeling that person has been touched by the spirit of TIMTOWTDI, is interested in developing in Perl and has experience, it's not that wild he jumped over that FAQ.
• But I also can understand merlyns position, which is a lot more into Perl and the community itself than mine, and even *I* would care about this stuff.

I mean, where would it stop? It's not that crucial to development in Perl to know that there's no PERL, or that there's a difference between "Perl" and "perl." At least the last part becomes an issue when you're e.g. trying to get help in Usenet. But we could go further and say, the principle of TIMTOWTDI isn't that important to a programmer. And then, how can we curse someone that he's not using map, grep, or any other stuff that he doesn't know from PHP?

One might say the difference is that the latter is about the tools you use, the first about the community and the spirit of Perl. Well, personally, I see the community as the mightiest tool, and the spirit of Perl as one of the keys to it.

[Dietz]

Just out of curiosity.
Does anybody know why O'Reilly (or is it O'REILLY) printed 'PERL' on the covers of Perl in a Nutshell and Perl CD Bookshelf, even on the latest editions?

[philcrow]

Because they use all caps for nutshells. Hence PERL IN A NUTSHELL and LINUX IN A NUTSHELL. Perl is not usually all caps, but then neither are Linux or nutshell for that matter.

Phil

[itub]

That's a graphic design decision. You should notice that they also spelled "IN A NUTSHELL" in all caps. ;-)

[chester]

I think it's good to have things that bind us as a community, and common speech is one of those things.

However, I think the distinction between PERL and perl and Perl is silly. I usually type it lowercase because I'm used to typing the command that way, and because it's linux-ish to lowercase as many things as possible, among other reasons. The same way I say bash instead of BASH, even though it's an acronymn. I have read the FAQ in perldoc, I understand the reasoning behind the distinction, I do try to "give" to the community in those ways in which I'm able, but I don't think it's worth worrying about the capitalization of the word "perl". If you judge people according to such criteria, I think you may misjudge people. I think it's very easy to read too much into something this trivial. It's possible to be plugged into the community without being exactly like everyone else in the community down to this level of detail.

This kind of thing reaches the level of dogma, in my eyes. There's no compelling reason for it (in my estimation) other than that it's proclaimed to be true by a source of authority. If I say "I needed to parse some text, so I wrote a perl script to do it", is there anyone who will misunderstand me, thinking I rewrote the interpreter itself? It's sometimes strange to see things like this being made into pseudo-religion. (Not that there's necessarily anything wrong with that; I've done my share of worshipping at the perl altar, but not when it comes to my precious choice of words. : ) )

Off-topic: This is the same reason I have no problem using comma splices, I feel that it gives a certain "atmosphere" or feel to a sentence that isn't possible using periods or semicolons, similar to a short pause in spoken language. Not all things that are "linguistically wrong" are the result of laziness or ignorance, some are the result of calculated independent choice. : ) So long as it doesn't hinder communication, I generally find nothing wrong with it.

[merlyn]

This is the same reason I have no problem using comma splices

But why use a comma there when a semicolon accomplishes the same effect; it joins two complete sentences together with a slight pause shorter than a period might. And if all you want is a slight pause—for a parenthetical phrase or sentence fragment—the em dash does just nicely, and is not frowned upon.

We have conventions for a reason. We have an agreement on what works for everyone. Inventing your own meanings is great in the privacy of your own cube, but why invent something that already exists?

[chas]

Regarding "acronyms" which have been mentioned a few times in this and related threads, it's interesting to me that typing "perldoc perl" brings up a doc that states (at the beginning) "perl - Practical Extraction and Report Language" and then later "Perl actually stands for Pathologically Eclectic Rubbish Lister, but don't tell anyone I said that." This would add credence to the thought that Perl is an acronym. Now acronyms are frequently (traditionally?) written in caps. However,"perldoc -q perl" displays a doc that states "But never write "PERL", because perl isn't really an acronym, apocryphal folklore and post-facto expansions notwithstanding."
So I don't do that, and I noticed from the beginning of my acquaintance with Perl that anyone who wrote "PERL" was immediately corrected. I understand that certain things (like writing "PERL" or leaving the cap off the toothpaste) can really annoy people, and that makes sense. But I've never been really sure why "PERL" is so heuristically incorrect aside from the fact that almost everyone agrees that is the case - which I suppose is good enough reason.
(Hope someone hasn't already said all this...)

[kiat]

I think Perl is a little unique here. It's an acronym (therefore mistakely written as PERL) as well as being pronounceable, so written as Perl.

A language name like Python doesn't share this uniqueness, in the sense that hardly anyone would write PYTHON. It's not an acronym but the name of an animal. And becuase it's a proper noun, so it's unambiguously written Python.

PHP, on the other hand, is both an acronym and is unpronounceable. Consequently, it's rare to see it written as Php (I think).

[Anonymous Monk]

I realized the problem is that many separate things I believe were getting collapsed and miscommunicated.

merlyn, on the one hand you want everyone to agree with the way you think, and on the other hand you want to be loved.

When you're not loved you assume you're not being understood..

It might help you to understand that people think differently to you. I know that some people, like you, like my own father, really struggle to get the concept of "someone else".

Truth is you don't need to be loved by everyone. You can have hard, cutting opinions, but you need to be secure in yourself and be prepared to be unloved. If you want everyone to love you then you need to be a doormat. There is middle ground.

But, in strictly logical terms, unlove != misunderstanding. Hope that helps.

[spiritway]

"Love" would be too strong a word, but I certainly respect merlyn. I think he was just trying to be understood, not looking for universal approval. Disagreement isn't lack of respect; nor does it always mean someone has misunderstood. It's just part of the give and take here at the Monastery, one of the features that makes it so helpful. There's room here for everyone, even if we disagree with them sometimes.

[merlyn]

I think he was just trying to be understood, not looking for universal approval.

Correct. In fact, I expect disagreement on some of the points. But in the previous thread, I recieved confusing (to me) responses to my posts, and realized that I was being misunderstood. So I took the time to step back and clarify my own reasoning before making any more attempts to communicate my specific points.

It was an interesting exercise, because I first just started listing about a dozen "I believe ..." statements in an outlining tool, and then I started to see a hierarchy of beliefs, and rearranged the points in a proper nesting. Once I had the nesting, I knew how to explain it better, and that resulted in the post at the head of this thread.

Are they all valid beliefs? Hard to say. Like every belief, I will find a world that correlates with that belief, opening some doors and closing others. Do I like the world I live in? If so, keep the beliefs, and if not, discard them. I'm very pragmatic that way. {grin}

[eyepopslikeamosquito]

I just noticed this quote from cpanratings of Games-Cards:

as I'm a fairly experienced PERL hacker I worked out what the complaint meant and fixed it but a newer hacker might get a bit confused.

Is "experienced PERL hacker" an oxymoron? ;-)

[mojotoad]

I think it's time to whip out the old chestnut: My computer broked down after perl install

Cheers,
Matt

[rir]

Ha! I resisted the first bait but--Hey! I'm just a fish.

Using PERL as screening criteria is reasonable to me.
Litmus tests are cheap and require little skill or effort. They do measure only one attribute; they do have their place.

But not for an initially given reason.
Cultures do not deserve respect, people do. A culture seems to inhere in, or adhere to, its people but is foolish to confuse the two.

On ethics.
Generosity is greater than fairness. I test the fit of the concept of generosity in all the places that I previously used fairness. This has been fruitful. Fairness or justice can easily become an exercise in miserly bean counting--did I get mine? Generosity promotes a finer intention and diminishes the importance of what is beyond your control.

Humor.
Much of the elite of perlmonks is supporting the significance of Perl versus PERL. I don't know to what degree this is driven by self-interest. I doubt many have considered the issue--it is such a small matter. I use Perl and perl as prescribed by that elite; if it was my code I'd be a cargo cult programmer but since it's my English I'm a clueful character. There is something amusingly weird in that.

Be well,
rir

[Aristotle]

I was with you until you drew the cargo cult parallel. How is that applicable? “Use strict and warnings” is a mantra when writing code; “avoid GOTO” has been another one for a long time. Sure, “know when not to” is added on occasion; but just because something is considered good style and widely followed in a community does not make following it mere cargo cult.

[rir]

Sorry I was obscure. Please note that that paragraph was designated Humor and not to be taken too seriously. I learned Perl from the first two Camel Books, very roughly from the first edition and with a little depth from the second. So I emulated the code presented there, specifically the bits return bless {}, ref( $self) || $self; and sub AUTOLOAD seemed to be recommended by the authors. So I used them, this was cargo culting. The cuteness and convenience of the constructs seduced me; obviously I was not alone. Now I would be more cognizant that a manual's authors obligation to demonstrate the features of a language surpasses their duty to instruct the reader about when to use the various features. Wall, Chrisiansen, and Schwartz wrote it and I imitated it--cargo cult.

If I use Perl over PERL because well respected members of perlmonks indicate that it is proper that, again, is imitation. Again based on deference to authority--cargo cult. In my case my recollection of the pink Camel is that it presented PERL as much an acronym as BASIC. That I discount my own memory makes it an exceptional case of cultism. That Perlers will think me foolish for the former and fine for the latter does amuse me slightly.

Regarding use strict; I had used perl as a replacement for awk, sed, and sh. I complained of the non-scalability of perl and was clued to the creation of the strict pragma. That increased my interest in Perl. My usage of strict is not cargo cultism, I avoided writing all but small scripts because I understood all too well some of the problems that it deals with.

just because something is considered good style and [is] widely followed in a community does not make following it mere cargo cult.

I say if such prejudices or judgements of the herd, or herd leaders, are the only reasons one follows a practice it is mere cargo cult. I do not disdain cargo cultism. I understand the negative connotations but do not give them weight. Some cargo culting is unavoidable. We learn by doing so we may be doing something we do not much understand, if it works for us and others it may go unquestioned by many. There is an efficiency in that.

Be well,
rir

[ysth]

I thought of this thread when I saw the sig in this message.

[gellyfish]

It might be worth pointing out that I have t-shirt from O'Reilly, who are often cited as a canonical source, which has "PERL" on it - the same as the one on the right here. So whilst I do largely agree with merlyn it's not surprising there is some confusion.

/J\

[merlyn]

I could argue that this is a typographic freedom, much the same way as I might write "Re-elect JOHN DENVER!" for emphasis or as part of a headline. I don't know anyone in the proper writing game at O'Reilly that doesn't spell it as the FAQ says to spell it.