Talk:Perl

• Archive 1- Leaking; Book Reviews, Xah Lee, would-be perl critic?; Perl programming language?; Regular Expressions with Perl Examples; Logo suggestion; Merits and demerits of Perl as a programming language; Propagandistic errors; Web hosting advertisements; Obfuscation example; History; Copyedits; TOCleft and indented paragraphs; Perl 6; Section ordering; Pathologically Eclectic Rubbish Lister.

A sample Perl program

1. A sample Perl program

       $message = "Hello, world! The magic number is 234542354.";
       print $message;
       $message =~ s/d+/-1/;
       print $message;
       exit 0

The above program can be written as:

       $_ = "The magic number is 150\n";
       print;
       s/\d+/-1/;
       print;

which demonstrates the idea of topic ($_) in Perl. Also, the exit 0 at the end is completely redundant. (See: pl:Perl) --Rafał Pocztarski 07:01, 7 Aug 2004 (UTC)

A version showing slightly more powerful regex, err, power in Perl:

       $_ = "The magic number is 150\n";
       print;
       s/ (\d+) / $1 * 2 /ex;
       print;

Quite a nice example. --Rafał Pocztarski 07:11, 7 Aug 2004 (UTC)

You're saying that it shows "high use of meaningful punctuation characters"?

You've never seen any REAL perl code :). What about using this (uppercase input) as an example:

 while(<>) {
   $_=~y/a-z/A-Z/;
   print;
 }

--Taw

Even better would be a line noise winner from one of the obfuscated perl contests, if that code is public domain. :-)

But that would miss the point - we want to show real Perl code, not one that was deliberately obfuscated. --Taw

I feel this entry should shy away from obfuscated code entirely! It just helps encourage the FUD that Perl is unreadable/write only/whatever, and that's a biased opinion. I can write incredibly obfuscated Java, but no-one feels the need to be posting that on the Java page. It tarnishes the neutral tone of the entry. I'd go as far as to remove the example (it's a bit pointless anyhow, what exactly is it demonstrating? I could come up with far more interesting examples of punctuation character usage, so that can't be it).

Anway, as an aside, you do realize you can get rid of the $_ in your code?:

 while(<>) {
   tr/a-z/A-Z/;
   print;
 }

Any books that tell you otherwise, burn 'em!

Finally there's the succinct:

 print uc while (<>);

...and I'll be surprised if there's anything more readable for the same task in any other popular language, assuming you've bothered to learn at least the rudiments of Perl, that is. --Derek

Or better yet:

   print uc while <>;

Even more clean and readable. One only has to say: uc is upper-case and the diamond is input. Great example. --Rafał Pocztarski 07:04, 7 Aug 2004 (UTC)

[Pp]erl

See http://www.perldoc.com/perl5.8.0/pod/perlfaq1.html, under "What's the difference between Perl and perl?". [Pp]erl is not and has never been an acronym. --nknight 23:36 Mar 6, 2003 (UTC)

It would seem, though, that the Perl documentation is self-contradictory in this regard, since http://www.perldoc.com/perl5.8.0/pod/perl.html#NAME says "perl - Practical Extraction and Report Language," which is how Larry Wall is supposed to have gotten the name for the language in the first place. --James Munroe 04:53 Aug 31, 2003 (UTC)

But if it was Practical Extraction and Report Language, the language name should be PEARL, not Perl. (Note: All caps, an `A'.) In fact, that was its original name until Larry found another language named PEARL (or Pearl). So it went to Perl, and the acronym no longer makes sense.

Like what anon user (above) says, pearl (now perl) started off as an acronym and Larry Wall had to change the name in order to avoid clash with another language with the same name.

The old expansion would still apply to perl as words like "and" are usually excluded from an acronym. However, Wall, the jovial person that he is, came up with the new acronym "Pathologically Eclectic Rubbish Lister" to match the new name. However I feel that these events and the link given by Nknight above should not be interpreted to mean that perl is no longer an acronym but a backronym. (refer interview with Larry Wall and the question ".. How'd you come up with that name?" http://www.linuxjournal.com/article.php?sid=339 ) --Jay 08:32, 3 Mar 2004 (UTC)

Hi, folks; perl never was an acronym. If it was, then Larry himself is lying. Anyone who's been in perl long enough to read the FAQ knows the story, and I've never heard anyone who's actually read the story claim that it's not true. Most everyone who claims perl was originally an acronym is much further removed than those who know the truth.

Incidentally, I corrected the famous quip, "Nothing but perl can parse Perl," from Tom Christiansen. The source on this is the FAQ. --Jdavidb 15:55, 8 Mar 2004 (UTC)

Full Ack regarding the Perl FAQ. According to it, Perl is only backronymed to Practical Extraction and Report Language.

But (and I noticed this just in this moment) if you look at http://history.perl.org/PerlTimeline.html under 1987, the (said to be) first man page shows exactly that acronym. Perl History also talks about 18th of December 1987, release date of Perl 1.000.

But in fact the first occurence of Perl at all was in May 1987, see http://use.perl.org/articles/03/12/15/0326207.shtml?tid=1. The therein mentioned Usenet posting can be found at http://groups.google.com/groups?selm=4628%40sdcrdcf.UUCP. The posting mentions that at that date, Perl is already 3 months old.

I'll put the Usenet posting and the Perl History Timeline into the article as external links, so the details of what is true and what is not can be discussed before any decisions regarding the article's content are made. :-) --XTaran 23:07, 11 Mar 2004 (UTC)

Blame me for the initial-cap spelling of Perl for the language. When we were writing the first Camel book, the lowercase

version of "perl" kept disappearing into the text. So I discussed with Larry, and we decided together that "perl" would represent the interpreter (and be in constant-width font as a result), and "Perl" would represent the language. And no, "PERL" was never valid. --Randal Schwartz

Name

""Perl" was originally named "pearl", after the "pearl of great price" of Matthew 13:46"

What is the reference to this information? --Jay 14:44, 6 Mar 2004 (UTC)

This seems to be the source, with a little bit of this thrown in for seasoning. --chocolateboy 17:38, 6 Mar 2004 (UTC)

For a little detail on why "Perl" and not "Pearl", in Larry's (paraphrased) words from State of the Onion 2005 "I went through every single three and four letter word in the dictionary but couldn't find anything good. I don't know how I missed 'Ruby'". He wanted the name either 3 or 4 letters, hence the convenient shortening when he heard about the PEARL language.

Perl - Practical Extraction and Report Language

The manpage for Perl begins with:

NAME
       perl - Practical Extraction and Report Language

This article suggests that "Practical Extraction and Report Language" is deprecated and "was intended humorously". I see no evidence that this is the case. I intend to move "Practical Extraction and Report Language" into the intro and remove the presumably false statement if there are no objections. --Eloquence* 02:24, Apr 13, 2004 (UTC)

I have strong objections, because Perl is not an acronym. The etymology of the name is very clear and would be widely known if people weren't so desirous of ignorance. All one has to do is read chapter 27 of the 3rd edition of the camel book, or google around a bit. The name of the language was originally to be "Pearl", before Larry heard of another language known as "PEARL". He removed a letter and all was well in the world. "Practical Extraction and Report Language" is a post-facto rationalization. Perl is not an acronym. --nknight 06:53, 13 Apr 2004 (UTC)

It doesn't matter if it is a "post-facto rationalization". We are not an etymological guide and the history of the name is only of marginal interest to most readers. If this is the way the word Perl is resolved in manuals today, then it should be prominently mentioned, not falsely claimed to be "intended humorously". I can agree to include the fact that Perl was technically not intended to be an acronym, but it is also a fact that it is today widely used as one, including by the makers of Perl. --Eloquence* 06:57, Apr 13, 2004 (UTC)

Feel free to remove any discussion about the name itself, but I will strongly oppose any attempt to define Perl as an acronym of "Practical Extraction and Report Language", as it is simply false, as anyone that has done substantive research on the subject will tell you. --nknight 07:06, 13 Apr 2004 (UTC)

That's just plain silly in a case where the official documentation uses the term as an acronym, but I can agree to label it a backronym if that makes you happy. --Eloquence* 07:15, Apr 13, 2004 (UTC)

Etymological information is of encylopedic value, so don't remove anything of it. Eloquence can refer the discussions above under sections "[Pp]erl" and "Name" and take inputs from it. --Jay 10:32, 13 Apr 2004 (UTC)

Backronym in intro

I've been meaning to bring this up for a while. The backronym, "practical extraction and reporting language", is in fact rarely used to describe the language. Its main claim to fame is that it is found at the beginning of the man page, where it almost comically serves to fulfil the custom whereby man pages begin with an excruciatingly concise summary. Other than that and a couple of appearances in O'Reilly books, it's not very widespread. Furthermore, it is better applied to very early versions of the language, given that Perl is a general-purpose language and not just for report generation (there are, in fact languages dedicated to reports, which bear little resemblance to Perl). For the above reasons I recommend removing it from the intro. Thoughts? --Yath 23:39, 4 October 2005 (UTC)

Explanation of for/foreach Syntax

I understand that this isn't supposed to be an exhaustive explanation of Perl syntax, but for/foreach are much more flexible and useful than this suggests. At the very least, I suggest replacing the "foreach ( array )" with "foreach ( LIST )", which is more accurate. (fish_at_uc_org)

I just noticed the same thing and fixed it. --Diberri | Talk 17:17, Aug 16, 2004 (UTC)

Technically, ARRAY is more accurate. If you give a literal list, its first copied/aliased into an array, then the array is walked. --Randal Schwartz

After I read your post, I immediately reverted my change (thus replacing list with array). But I'm not sure that was the right thing to do, and I don't believe you were even suggesting such a reversion. (Namely because foreach( array ) would disallow useful constructs like foreach( qw/foo bar baz/ ) and even foreach( foo() ), which Perl obviously allows.) So I've reverted my original reversion; the article now uses foreach( list ). --Diberri | Talk 06:40, Aug 23, 2004 (UTC)

Yeah, list is more appropriate and I believe Perl does copy the contents of the list given in a foreach context. --Sundar 10:06, Aug 23, 2004 (UTC)

As I understand it, that part of the article is trying to explain the syntax of for, so the internals of the implementation, and the copying to a temporary array, are irrelevant. Syntactically, the target of the for is a list, not an array. Compare this with the target of pop or tie, which is syntactically an array. --Dominus 13:44, 23 Aug 2004 (UTC)

I agree. The array copy is an implementation detail. --PhilHibbs 09:03, 24 Aug 2004 (UTC)

It is undoubtedly an implementation detail, but nevertheless quite an important one affecting the code meaning, so the list-like syntax notwithstanding, maybe it should be stated that in fact for iterates over an array, not a list:

@a=(1..10); for (@a) {@a=(); print} # prints only 1

Rafał Pocztarski 18:07, 24 Aug 2004 (UTC)

Saying that perl expects a LIST at that point doesn't imply that an array is being flattened into a LIST, does it? An array is still a LIST. (fish_at_uc_org)

You make a good point, but I'm not sure this article (or any article on a programming language) should get into such minutiae. Since arrays are lists, but not vice versa, foreach( list ) should be used because 1) it's correct, even considering minute details, and 2) it's simpler than saying foreach( array ) and then having to qualify it. --Diberri | Talk 00:55, Sep 15, 2004 (UTC)

Sample code formatting

Regarding Ævar Arnfjörð Bjarmason's changes to the code formatting (using <tt> instead of <pre>), I think I prefer the look that the stylesheet imparts to <pre> blocks. --Yath 23:26, 15 Aug 2004 (UTC)

Merits and demerits of Perl as a programming language

Here's some text I removed, from a section named "Merits and demerits of Perl as a programming language":

"Like all programming languages, perl does some things well, and other things, well, less than efficiently. Many programmers have come to terms with this and use a judicious mix of shell-script and perl to get around the more obvious deficiencies (date manipulation can be slow in terms of relative processing time, for example). On the upside, perl is very useful for low level file manipulation at which, in many respects, its performance is often comparable with e.g. sed."

I'm sure a section like ==Tasks for which Perl is unsuited== could be useful and informative, but the above paragraph has no redeeming qualities. Allow me to nitpick.

• "a judicious mix of shell-script and perl to get around the more obvious deficiencies" -- Perl replaces and exceeds sh in nearly every capacity. When perl falls short, you either switch languages or call a utility, but the instances in which that utility would be sh are vanishingly rare.
• "date manipulation can be slow in terms of relative processing time, for example"- perhaps this is a rare example of when sh is better than Perl? If you can demonstrate this, I won't object to it being reinserted into the article.
• "perl is very useful for low level file manipulation"- This is too vague. By "low level file manipulation", do you mean manipulating links and permissions, or something even lower? Perl is ok for fiddling with links and permissions, I guess, but as a strength, it's no big deal. For lower-level operations... well, you'll have to clarify if that's what you meant.
• "at which, in many respects, its performance is often comparable with e.g. sed." sed? Perhaps you meant data manipulation. This is one of the foundations of Perl and is well covered elsewhere in the article.

--Yath 08:01, 14 Sep 2004 (UTC)

Yeah, I agree with Yath. --Sundar 08:12, Sep 14, 2004 (UTC)

I also agree. There's a lot of be said about Perl's failings and deficiencies (see Sins of Perl Revisited, for example) but I don't think this is it. --Dominus 13:14, 14 Sep 2004 (UTC)

But after you realize that language switch could be too costly you learn to use external sub routines and gain access to all the codebase that evolved in the C world and C library calls interface world. That's the point you become several times more productive. How many times and how fast depends on your C/C++/libs experience.—The preceding unsigned comment was added by 194.149.124.54 (talk • contribs) .

Data types and Variables

With all the Perl hackers around, we have an article on Perl that does not explain, or even do more than mention in passing, Perl data types and variables. The word data only appears as part of "database", "type" doesn't appear at all, and "variable" only appears in a misdescription of function parameters. I've half a mind to submit this article for deletion, if this is all there is to show after three years. --Tony Sidaway 11:30, 26 Nov 2004 (UTC)

Are you kidding? If incompleteness was grounds for deletion, Wikipedia would dissolve. :-) Sure, the article needs work. So be bold! For now, I've added a brief bit on built-in data types ($scalars, @arrays, and %hashes), but there's lots of room for improvement. Why don't you take a stab at it? --David Iberri | Talk 09:18, Nov 27, 2004 (UTC)

I don't think adding yet more of the same is going to make this into an encyclopedia article. I think it would probably make more sense to wikify the perldoc files (see User:Tony_Sidaway/Projects/man_perl/man_perl for an example based on Perl 5.6.1, with an example of a link to man perlbook) and reserve the main Perl article for a brief language summary as is the case with languages like Fortran, lisp and so on. --[[User:Tony Sidaway|Tony Sidaway ^Talk ]] 17:27, 27 Nov 2004 (UTC)

I'm not sure I understand what you mean bo "adding yet more of the same". If you mean that the existing article is a bit too low-level (e.g. the regular expression section needs more commentary and fewer examples, IMO) and that the built-in data types section I added is similarly too low-level, then I might agree. But I'm not sure that a brief summary would suffice. Wiki is not paper, so I don't think we need to be overly concise. Examples are good, as demonstrated by Lisp programming language. --David Iberri | Talk 19:44, Nov 27, 2004 (UTC)

Someone coming to Perl should be able to find out what he or she needs to know. The type of language it is, what people use it for, what it looks like, in general terms the kinds of facilities it provides to the user, the design considerations of the language, and its history.

What is there would probably be all right if it were more concise and (above all) accurate. The section on subroutines, for instance, erroneously refers to "Variables passed to a subroutine"--an error that could be forgiven in a first year Computer Science student, but is not to be expected in an encyclopedia.

I think I'll continue with my efforts to wikify man perl and, once I have completed that task to my satisfaction (I'll be using scripting to do the translation to wiki), I'll compose a rewrite of Perl that refers the interested reader to the appropriate sections of that copious and very readable electronic manual of the Perl language. This should provide the best of both worlds. --[[User:Tony Sidaway|Tony Sidaway ^Talk ]] 21:21, 27 Nov 2004 (UTC)

Time to split the page?

The Perl page is at 30K. It's long to read and big to edit. Would it make sense to split some of the big sections, e.g.

• Perl#Control structures
• Perl#Regular expressions with Perl examples

off into separate pages? --Swmcd 16:19, 2005 Mar 1 (UTC)

Yep :-) --chocolateboy 19:34, 1 Mar 2005 (UTC)

Only 30K? You slackers. My talk page is longer than that! :) --Maru (talk) Contribs 20:27, 12 November 2005 (UTC)

Language Design Philosophy

I recently restored the following deleted paragraph from the "language design" section of the article:

"The design of Perl can be understood as a natural response to three broad trends in the computer industry: falling hardware costs, rising labor costs, and advancing compiler technology. Earlier computer languages, such as Fortran and C, were designed to make efficient use of expensive computer hardware. In contrast, Perl is designed to make efficient use of expensive computer programmers."

The user who deleted this paragraph said in the edit comment that it was "unencyclopedic". The paragraph is factual, and I believe it is correct. Moreover, I think that it is a good capsule summary of the major overarching principle of Perl's language design. Accordingly, I believe that the criticism of this paragraph as "unencyclopedic" is mistaken. --Dominus 5 July 2005 14:17 (UTC)

I agree with you, and your revert beat out my revert by a short period of time. I see Fredrik has since offered up some "compromise language", but I still think the original language made the point better, so I've reverted back to that. In my opinion, the 'graph speaking of computer productivity versus programmer productivity is the heart of the matter and should certainly stay. --Atlant 5 July 2005 14:23 (UTC)

Having looked at Fredrik's alternative wording, I too think that the original paragraph was better. I don't think the replacement captures the important features of the situation as well as the original did. --Dominus 5 July 2005 14:27 (UTC)

I agree, "unencyclopedic" was a bad choice of word (it only referred to a small part of the paragraph). The main problem is:

"The design of Perl can be understood as a natural response to three broad trends in the computer industry."

Saying that it is a "natural response" is pretty biased. Also, the contrast with "earlier computer languages" is wrong, because although many earlier languages were designed for speed, others were certainly not. The text makes it sound like Perl invented the concept of abstracting things away from the hardware. The third sentence is at least partially redundant. Btw, Atlant, my third edit was not a revert, but rather an "unrevert"; I wrote it before Dominus did his second revert, after reconsidering deleting the entire paragraph. --Fredrik | talk 5 July 2005 14:29 (UTC)

I agree with you that the word "natural" should be removed.

I don't think the text makes it sound like Perl invented the concept of abstracting things away from the hardware. There is nothing in the paragraph as written that suggests that Perl was the first or only language to do that.

I also don't think the third sentence is redundant. It establishes a general principle, which is then elaborated upon by the following paragraph. I think the two paragraphs complement each other. --Dominus 5 July 2005 14:35 (UTC)

Re #2; it does. It contrasts Perl with "earlier languages", suggesting that Perl was a new language to provide this feature. --Fredrik | talk 5 July 2005 14:39 (UTC)

What if it said something like "Many earlier languages, such as..." instead? --Dominus 5 July 2005 14:44 (UTC)

I'm fine with that (which is essentially what I put in my reworded version). --Fredrik | talk 5 July 2005 15:02 (UTC)

Intro paragraph

The intro paragraph says:

Perl borrows features from C, shell scripting ...

200.150.42.62 changed it to:

Perl has a unique set of features partly borrowed from C, shell scripting ...

I reverted it. I think the point of the phrase "a unique set of features" is to emphasize that Perl does have its own feature set, independently of all the other languages that it has borrowed from. But that is presumably true of any programming language. If we really need to make this point, I'd rather move it down to the Language features paragraph. The intro paragraph should stay very short, for the benefit of readers who just want capsule summary of the subject. OTOH, if "unique set of features" means something else, then it needs to say so with precision. --Swmcd 2005 July 6 18:43 (UTC)

Perl is not (really) an interpreted language

I noticed the intro said that Perl is an interpreted language, so I went to edit it to change "intepreted" to "byte-compiled". But then, in the interest of consistency, I read further down. The entire article whipsaws between "interpret(er|ed|s)" and "compile(r|d|s|-time)" with little rhyme or reason (except it doesn't say "interpret-time" anyway, thankfully!). I can't imagine that the lay reader is going to have any luck understanding Perl's execution. Was there some prior discussion that decided that it's better to pretend Perl's interpreted? Or is a byte-compiled language which immediately executes the bytecode considered "interpreted" these days since actual line-by-line interpreters seem to be getting more and more rare? --TreyHarris 17:39, 24 August 2005 (UTC)

If I were doing the editing, I'd say make it clear that modern Perl is a compiled langauge. (I honestly don't know if it's fair or not to call the compiled representation of the code "byte code"; I've never looked closely at exactly what data structures come out of the compiler but I'll bet they're more complex than just byte-code that is then interpreted by a runtime engine.) But there's no doubt that everything is compiled, even any eval(...) stuff. --Atlant 17:51, 24 August 2005 (UTC)

I put "interpreted" back in. Section 1.3 Implementaion describes Perl's execution architecture. We could argue the semantics of words like "compiled" and "interpreted". However, people who read in an encyclopedia article that Perl is interpreted will draw correct conclusions about its available features and CPU requirements. --Swmcd 15:55, 2005 September 2 (UTC)

Pro vs. Con

These sections are POV, unsourced and not well written. I also think the idea of an "advantages/pro" section in a programming language article is silly, as you're required to compare it to every other language in existence, which isn't help. Criticism can be done independently of other languages though. The pro section includes those two "perl is fun!" quotes which really shouldn't be there. The con section does contain common criticisms, but it needs to be sourced. And this last "rule of thumb" I've never even heard of: "A rule of thumb is that if resources to run Java are available, then Perl can certainly be used." Java programs run considerably faster than Perl programs due to being JITed, so I'm not even sure who would say such a thing. --Nathan J. Yoder 05:49, 19 October 2005 (UTC)

I think that there are some pros/cons that are held by a wide number of experienced people. For instance, nobody would write a ray-tracer in pure Perl. And non-experienced people often have very similar initial responses when learning the language. Though I do think some care does need to be taken to make sure the pros/cons actually represent consensus of a majority of some community, and not just the thoughts of one person who just learned the language, or otherwise similar to overboard rants that some people have posted on the internet. --Interiot 20:08, 19 October 2005 (UTC)

Yes, that's why there needs to be some sourcing to confirm these aren't just every random complaint being inserted. I think "advantages" shouldn't be given their own section, they should be interwoven into the article and just listed as features to let the reader decide. Criticisms tend to be a bit harder to integrate like that without sounding hackneyed, plus I think people generally like them condensed into one section. --Nathan J. Yoder 01:11, 20 October 2005 (UTC)

All pros and con for Perl, with Perl it's just more visible, from the contributors view depned on the depth of insight into Perl and it's facilities and ability to use them where they fit. The JITcalim could be made parially invalid example using mixed approach of not only Perl. The argumentation would be offtopic here and would resemble trolling or flamewar because we are not benchamrking "the one task" in Java/Perl/mixed enviroment. The trick and truth is not to list pros as it can't be compared to everything and still be usable wiki page but provide information that educates the reader enough to be able to decide what tasks is Perl good for and what other facilites may be used to bind it with other specialized tool while the result remains effective in some way. On the other hand it's good idea to list mistakes under con to speed up the rejection during language selection for some task. It will help prevent the reader from using Perl where the gain will not be significant and in this way will reduce the FUD like "write only language" and other negative generalized attitude to reappear.

Regarding the cons added this morning, I would like to see the business one removed or significantly reworded. I work at a Fortune 100 business that uses Perl quite a bit. We don't base our business on it, but we have TONS of worker scripts that do perform little useful tasks. Also, the Symbian OS development environment is heavily based on Perl, so that's someone else who doesn't find substantive problems with it. Also, the perl/C integration, is that a valid criticism? Are there other interpretted languages which integrate significantly easier with C (other than with .NET, which is much different than any other interpretted language out there). --Interiot 20:16, 19 October 2005 (UTC)

Yes, some languages are designed to be easy to integrate like Lua and Tcl. Boost also provides some nice bindings to Python. --Nathan J. Yoder 01:11, 20 October 2005 (UTC)

Opinion is not advocacy

The title of the section is Opinion, not Pro vs. Con. I have observed that people have strong opinions about Perl. I think that these opinions are somewhat relevant to understanding the language itself, and very relevant to understanding the culture and—occasionally—controversy that surround it. The section is divided into two sub-heads: Pro and Con. However, the purpose of the sub-heads is not to advocate for their respective opinions; rather, it is to summarize and present them. There is a natural tendency for people reading this section to add material responding to opinions with which they disagree. However, doing so is not appropriate for this section. It obscures the point of the section and risks becoming POV. --Swmcd 21:28, 20 October 2005 (UTC)

Use of $a, $b in examples

The variables $a and $b have special behavior in Perl because of their use in the sort function. They are the only non-magic variables in Perl that will not cause an error if they are not declared under "use strict". Because of this, their use should be avoided in examples as doing so could lead beginners to encounter subtle problems with their code due to the lack of strict declaration checking for those variable names.

For instance, someone not familiar with Perl's rules for variable scoping could inadvertently declare a local "$a" with "my $a" and then use it outside of the declaring block; in this case, "use strict" would not cause an error, but the implicitly global copy of "$a" would be used instead.

   #!/usr/bin/perl
   
   use strict;
   use warnings;
   
   {
       my $a = ...;
       ...
   }
   
   print $a;

Mike Dillon 18:53, 22 November 2005 (UTC)

• I agree, and have changed the page to remove the references to $a and $b. Turnstep 19:50, 27 November 2005 (UTC)
  • Cool. Good work on the other edits too. P.S. Greetings from Perl Monks... I'm mdillon there and I assume you're the same "turnstep". Mike Dillon 05:26, 28 November 2005 (UTC)
    • Yep, how did you guess? :) Haven't really done much on there in years, however. Turnstep 06:39, 28 November 2005 (UTC)
      • I haven't been active there in a couple years either, I just recognized the name. Mike Dillon 18:01, 28 November 2005 (UTC)

Context-free

Perl has a context-free grammar; however, it cannot be parsed by a straight Lex/Yacc lexer/parser combination. Instead, it implements its own lexer, which coordinates with a modified GNU bison parser to resolve ambiguities in the language.

No it does not, in anything close to the strict definition of context-free. Actually, very few languages have context-free grammars (for example C doesn't, as a (b); may be either function call or variable declaration in some contexts).

Quick draft of a proof: function prototypes. Whether foo bar 1,2 parses as foo(bar(1,2)) or foo(bar(1),(2)) depends on earlier prototypes of foo and bar. Because of infinite numbers of possible functions, you can't encode this information in a context-free grammar. It's not the only Perl construct that's provably non-context-free. Taw 09:06, 3 December 2005 (UTC)

You are right that Perl does not have a context-free grammar. The regex syntax isn't even context-free, since even backreferences introduce context-sensitivity. Besides the problem you pointed out, the function itself can behave differently if it is called in scalar v. list context. Your changes look good, although explicit reference to Lex and Yacc may not be the best thing; maybe it should just say "cannot be parsed by a standard lexer/parser combination" instead of "cannot be parsed by a straight Lex/Yacc lexer/parser combination". Mike Dillon 15:23, 3 December 2005 (UTC)

Hello world

Does the warning flag belong in the shebang line of the hello world program? It's never in my programs.

Maybe I'm Wassercrats, maybe I'm not. :P -Barry- 05:14, 11 December 2005 (UTC)

I think Wikipedia should promote good coding practices, and it's good practice to get into the habit of writing -w in the shebang line of all Perl programs. --David Iberri (talk) 18:25, 12 December 2005 (UTC)

Better yet, use warnings; Turnstep 18:46, 12 December 2005 (UTC)

Add all the tips on good practice that you want, but the rule of the "Hello, world!" thing is just to print "Hello, world!" and a CR.

I don't know who wrote the following, but it basically says that using -w isn't worth the trouble unless you need help developing your style:

http://perl.about.com/library/weekly/aa081701c.htm

"...the code may be perfectly OK, but it will give you an error message so you have to go check. Let me warn you. It can be really annoying to be flooded with messages, especially if you know the code is OK, but my advice is to use -w anyway. If you learn to write code that doesn't generate warnings, you'll develop good style and be a better programmer."-Barry- 20:17, 12 December 2005 (UTC)

- The "-w" switch should be included because it's canonical. It is included in the "hello world" examples in certain Perl books.

- It is not Wikipedia's responsibility to promote good coding practices.

- The "hello world" program is not just a program to print out "Hello, world!" and a CR. It is an idiomatic program.

- The link ([1]) advises to use -w all the time, not just for "help developing your style". It's a good thing too, because it should be used all the time.

--Yath 20:26, 12 December 2005 (UTC)

The Language features or Language structure section should cover things like -w and maybe debugging tools like strict, and common practices for using Perl would be appropriate for the article. I'm not saying that any particular matter of opinion should be promoted. I wouldn't object as much about the -w in the hello world script if it was explained somewhere that it's not essential.-Barry- 21:11, 12 December 2005 (UTC)

Only good things happen when we promote coding practices that have been widely accepted as good ones. Why shouldn't this be Wikipedia's responsibility? --David Iberri (talk) 03:00, 13 December 2005 (UTC)

In promoting something, there's often one-sidedness, which isn't appropriate for this quasi-encyclopedia thing we call Wikipedia, but the function of -w can be explained, as well as use warnings;. Mentioning that using -w is generally accepted to be a best-practice is fine too, I guess. -Barry- 03:17, 13 December 2005 (UTC)

Perlscript

no mention of perlscript? Gflores ^Talk 05:58, 16 December 2005 (UTC)

The lead

I condensed the lead. The lead should be like a headline: very short, with just enough info to tell the reader what the article is about, and help them decide if they want to read further. Avoid adding anything to the lead that either is--or should be--somewhere else in the article. Swmcd 17:11, 16 December 2005 (UTC)

Perl is interpreted

There is a common distinction between intepreted and compiled languages. This distinction is not absolute. The text of most interpreted languages undergoes some kind of preliminary compliation—lexing or parsing—before it is passed to the execution engine. Conversely, every program is ultimately interpreted: CPUs interpret their own machine code.

When we say that a programming language is interpreted, that is generally understood to mean 2 things:

• programs in that langauge suffer a significant performance hit with respect to equivalent compiled programs
• the language offers strong introspection features, and—especially—an eval() function.

Both of these things are true of Perl, so we say that Perl is interpreted. Interested readers will find a more detailed description of Perl's execution architecture in the Implementation secion, while uninterested readers will draw correct conclusions about Perl's performance and language features even if they read no further than the statement Perl is interpreted.

Swmcd 05:18, 17 December 2005 (UTC)

Sorry for editing the above post. I didn't notice that it was on the talk page.

I thought the interpreted issue was settled months ago. Anyway, a significant performance hit won't be noticed with all Perl programs. This is covered on page 16 of Learning Perl, 3rd Edition. And eval() is nothing special to me, but maybe there's more meaning in what you're saying than I see. I'm not as into Perl as I used to be. -Barry- 08:33, 17 December 2005 (UTC)

The statement Perl programs are interpreted is gone, on the grounds that

"interpreted" implies "reparsed on every loop".

I've never drawn that inference, but if that's how the word is commonly understood, then we shouldn't use it. The word "interpreted" could be dropped from the lead. The word "interpreter" appears in 30 places in the article; I don't know what to do about that.

Swmcd 15:47, 17 December 2005 (UTC)

Yeah, colloquially, we say "the Perl interpreter" (the standard /usr/bin/perl program), only to contrast it with "the Perl compiler" (various forms of perlcc and friends). --Randal L. Schwartz 20:02, 17 December 2005 (UTC)

Semicolons used inconsistently in one line scripts

I've seen one liners with and without semicolons in the article. For example, there's:

my $x = shift;

and there's:

$x =~ m/abc/

I suggest that semicolons be used consistently. The problem is that I encountered a line that I'm not sure can be a valid line of Perl code or whether it's a snippet of a line, so someone more advanced than me better take care of it. -Barry- 21:57, 17 December 2005 (UTC)

You only need semicolons to separate statements. Most of the examples in the article aren't one-line scripts, they are just code fragments. The first example above would typically be a complete statement in a program, so it gets a semicolon. The second example is an expression that might be part of a larger statement, so it doesn't have a semicolon. Swmcd 13:43, 19 December 2005 (UTC)

Regex examples

Sorry, I don't understand what the following example is good for ( especially combined with 'This is more interesting for patterns that can match multiple strings', were the modifier //s should be in use ):

($matched) = $x =~ m/a(.)c/; # capture the character between 'a' and 'c'

$matched will print -1 on my machine, this should be a simple example and we should introduce $1 here Ulv 23:42, 18 December 2005 (UTC)

The example worked as written

 localhost:~/src/Perl>perl -le '$x="abc"; ($matched) = $x =~ m/a(.)c/; print $matched'
 b
 localhost:~/src/Perl>

The term "multiple strings" doesn't mean that $x contains multiple lines; it means that the RE can match more than one string, e.g. 'abc', 'axc', a3c', etc. But the text should probably be more direct than that.

We could describe either the return value or the $1, $2, ... variables; I'd rather not do both, in the interests of brevity. I think the return value is slightly simpler to illustrate:

 ($matched) = $x =~ m/a(.)c/;  # capture the character between 'a' and 'c'

Swmcd 14:46, 19 December 2005 (UTC)

Page reorganization

User:Flash200 reorganized the page.

Previously, the top-level sections were

1 Overview
2 Language structure
3 Language design
4 Opinion
5 History
6 Future
7 CPAN
8 Name
9 Fun with Perl
10 See also
11 External links
12 References

Now, the top-level sections are

1 History
2 Philosophy
3 Usage
4 Syntax
5 Resources
6 Availability
7 Opinion
8 Fun with Perl
9 See also
10 References
11 External links

I think we should revert to the previous organization.

People tend to read encyclopedia articles the same way they read newspaper articles. They start at the top, and scan down until they find what they want to know, or get tired, or bored. Also encyclopedias are consulted by non-experts; experts have other resources.

So we should organize the article to quickly provide the information most commonly sought by people who don't know much about Perl. I think

1 Overview
2 Language structure
  ...

does this better than

1 History
2 Philosophy
  ...

Swmcd 14:54, 12 January 2006 (UTC)

Redraft 1

I created a subpage, User:Flash200/Programming-language_outline, for discussing the reorg. I removed most of my own comments from this page and added them there. --Flash 04:00, 18 January 2006 (UTC)

I think you're putting the cart before the horse by making the assumption that programming language articles should all share a common structure. I'm not at all convinced of that. It seems to me that a CPAN section made a good deal of sense for the Perl article to have, and the fact that no other language has it seems like a silly reason to rule it an unnecessary section. On the other hand, a Criticism section makes sense for many languages that are or were in widespread use, but seems a bit odd for esoteric programming languages, say Emoticon or Befunge. I don't understand the need for consistency here. --TreyHarris 07:30, 17 January 2006 (UTC)

Sorry, I wasn't being clear enough. The template above is a generic one, not specific to Perl. The Perl article would still have a CPAN section or subsection. And some articles wouldn't have a "Criticism" section. The template would be adapted as needed to fit each language.

In the last several years, I've been adding encyclopedic content about programming languages to my website, and I'd like to migrate as much of that as possible to Wikipedia. Having more consistency and intuitiveness for the organization gives me a better frame of reference for deciding what content should be added where. And it may make it easier for others to work with multiple programming articles as well (reducing the incompatibility between the articles, and reducing the learning curve of going from one article to another). --Flash 18:56, 17 January 2006 (UTC)

I reverted most of the page reorganization. An historical presentation just doesn't give most readers the info they are looking for when they read a programming language page.

It is certainly possible that the page could benefit from some reorganization, but that should be discussed here first, and then applied to the existing structure of the page. Starting from a generic template and then trying to morph it into something appropriate to Perl is difficult and unnecessary.

Swmcd 04:20, 29 January 2006 (UTC)

Swmcd, I'm not sure your two edits of April 1st are accurate, could you explain them, please? "Alternatively, the interpreter can be compiled to a linked library and embedded in other programs." -> "Alternately, the interpreter can be compiled to a link library and embedded in other programs.". This is an alternative (the other option of two) rather than something that alternates (first one, then the other, then the first). It's also a library that is linked, rather than a library of links. I didn't want to silently revert, even after double checking my own understanding of those words on the OED. SimonFr 14:30, 3 April 2006 (UTC)

The term link librarary refers to a library of subroutines, suitable for linking with other code to create an executable. So it is a library that can be linked, not a library that is linked. The term linked library isn't generally used; someone hearing that term is liable to ask, "Linked with what?"

I have to disagree, the term linked library is the one I've encountered more often, with shared library being the most common. I also disagree with your assertion of potential misunderstanding. Library (computer science) mentions the library is called a dynamically linked library. This term is sometimes shortened to "dynamic link library" It may be simpler to use shared library SimonFr 11:09, 13 April 2006 (UTC)

I'm using alternately in sense 4 given at www.m-w.com

 4 : constituting an alternative <took the alternate route home>

Swmcd 11:19, 12 April 2006 (UTC)

Interesting, the OED doesn't mention this, it talks only about 'taking turns' definitions. Since they're effectively equivalent in US English, and have caused confusion to me, a British English speaker, could we use alternatively? SimonFr 11:09, 13 April 2006 (UTC)

• I always assumed that the term linked referred to the mechanism of referencing more than anything else. You cannot use a function within the library unless you link to it (Therefore the can/is issue is a moot point). Whether this is done statically (ie compile time) or dynamically (ie runtime) is irellevant. the concept of linking is for the library to be loaded into resident memory, providing a list of address pointers where each of the functions are now available to be called. Thus you are linking into this library in order to retrieve the code to run. I think you have the link around the wrong way... it isn't the library which is linked in but the program which is linked into the library. Enigmatical 23:20, 12 April 2006 (UTC)

Listed as a .Net Language?

Is there any reason why this is listed as a .Net language? I have heard rumours that Perl.Net may be on the cards but no mention is made of it in the article and so I am not sure why it is categorized as such. Enigmatical 01:51, 12 April 2006 (UTC)

processor-bound tasks???

From the article:

Perl is not efficient at processor-bound tasks, and Perl data structures generally use more memory than comparable data structures in languages like C and C++.

This is true of any scripting language, so why is it nessesary to list it specifically as a criticism of Perl? Perl also isn't good for, say, creating an operating system like one would do with C and C++, but that's hardly worth mentioning. 209.92.136.131 20:53, 19 April 2006 (UTC)

Popular alternatives to Perl

Why make people click each link in the Major programming languages box on the bottom of the article when they're looking for alternatives? Perl, Python and PHP are known as the three Ps and should be mentioned as popular alternatives, either in an infobox or somewhere else.

On this page, O'Reilly's Editor In Chief, Frank Willison, says "You can use a number of languages with MySQL and PostgreSQL, but the most popular are the three "P's," the open source scripting languages Perl, Python, and PHP."

I suggest that languages listed in my proposed Popular Alternatives infobox (if a new section isn't created in an existing infobox) be limited to those in the top chart on this page. PHP and Python are in that chart.

Here's the infobox I'd like to add above the Major programming languages box at the bottom of the article:

Popular alternatives to Perl

PHP | Python

Alternative title: Some popular alternatives to Perl.

-Barry- 02:11, 1 May 2006 (UTC)

See also Python's See also section. I figured an infobox is better for Perl's article since the See also section is full enough. -Barry- 02:19, 1 May 2006 (UTC)

Sorry but this is just silly. An "infobox" presentation makes it seem like finding alternatives to Perl has some kind of prominence among programmers. Also, it's far too vague: alternatives in what particular purpose? Every possible purpose? You can't even argue that PHP fills that bill; it's a niche language that competes in a small slice of Perl's domain. My first reaction on seeing your box is that it's thinly-veiled, partisan Perl-bashing. So let's not do this. --Yath 03:09, 1 May 2006 (UTC)

At the very least, I want to fit a "three Ps" reference in here. I wouldn't mind a short description of whatever alternative languages are included, which would mention that PHP isn't as powerful as Perl. I also wouldn't mind if Python was the only alternative listed.

I'm surprised there's no programming language comparison on Wikipedia. Maybe I'm not looking in the right place. Maybe I'll ad an external link to one. If it's a good one, then an alternatives section wouldn't be as important.

I think there's a place in this article for Perl bashing, but that would be in the cons section. I think alternatives should be mentioned in every programming language article. Python's article already mentions Perl.

There are no veils here. I haven't been a fan of Perl for a while, and I'm even less of one lately, but I won't surpress anything good that anyone has to say about Perl unless it's untrue or clearly doesn't fit in the article. -Barry- 03:41, 1 May 2006 (UTC)

I have two main points. Firstly, it's a page-wide box containing just two lonely entries. It looks silly. If you want to mention "the three P's", then do so in the text. No need for a box.

Secondly, there's lots more alternatives as Yath alluded to. Off the top of my head: Bash and Csh for simple scripting, Sed and Awk for simple text manipulation, and lots of other domain-specific languages for web programming (ASP, JSP, SSI, etc...).

I just found Comparison of programming languages but it's pretty bare. You might want to bring it up to the standard of other comparison of... articles. Imroy 09:06, 1 May 2006 (UTC)

Thanks for the link. I began fixing it up. When I fix it a little more, I'll remove some of those templates and link to it. -Barry- 00:58, 2 May 2006 (UTC)

The infor box is silly but if it were there you should add ruby Htaccess 14:23, 4 May 2006 (UTC)

At this point, the "three Ps" is an outdated concept. The application domain of Perl is shared primarily with (in alpha order): C#, Java, PHP, Python, Ruby, and shell -Harmil 19:05, 8 May 2006 (UTC)

They're probably the languages most supported by web hosts, and probably the most used for websites, but feel free to add more detail to the article if you think the three Ps part is misleading. -Barry- 08:11, 9 May 2006 (UTC)

The Web doesn't really have any bearing here (though I'm sure your average PHP programmer would be shocked to hear that). Perl pre-dates the Web by about 5 years and has always had strong usage in systems administration, scientific modeling, reporting, and a number of non-Web fields. As far as the Web goes, however, I think Ruby and Java have certainly made at least as much of a splash as Perl, Python and PHP. C# tends to be used more in the application programming world, but there's a fair amount of Web and data work that overlaps Perl and Python's domain. -Harmil 13:15, 9 May 2006 (UTC)

The problem is that most people don't care about comparing programming languages. Only zealots -- like Barry -- who want to make one language look better than another really care. This is a stupid idea. Pudge 15:19, 18 May 2006 (UTC)

TCPI?

-Barry- just added a paragraph linking to the TCPI Long Term Trends chart and uses it to claim that Perl is rapidly losing in popularity. This index is nothing more than using Google and other search engines to search for:

+"<language> programming" -tv -channel

This has about as much credibility as the old Operating System Sucks-Rules-O-Meter and I'm just itching to remove or at least rewrite that section. What do other people think? Imroy 06:23, 10 May 2006 (UTC)

I had this same discussion on Perlmonks and in Talk:Comparison of programming languages. Here's what I wrote in the latter:

--------

There's Wikipedia:Search engine test. Under idiosyncratic usage it says "A series of searches for different forms of a name reveals some approximation of their relative popularity."

The TIOBE data has been around for a long time and is regularly updated. At [2], where it says "The definition of the TPC index can be found here" you can click "here" to see an explanation. I don't think it's a good explanation, especially for laymen, but it provides some details that might matter to some people.

Here's a discussion that might be of interest.

--------

If necessary, I can do what I did in Comparison of programming languages and clarify that the data is gathered from search engine results. The numbers are actually more accurate than that sounds, so I may explain it a bit more than that, but I'd try leaving out the long footnote that I put in Comparison of programming languages. -Barry- 07:29, 10 May 2006 (UTC)

The problem is that you have only one data point: the number of times Perl is mentioned on the Web. You don't have:

• Number of times it's mentioned in journal articles
• Number of times it's used in deployed systems
• Number of times it's mentioned on the Web (but not refered to as "programming").

The other problem that I have with the idea of judging Perl "popularity" by Web hits is the idea of maturity. No one is running around saying, "hey look at this cool new language I just found," about a 20 year old programming language. On the other hand, 20 years worth of programmers continue to use it day in / day out as one of the primary tools in their toolbox.

I'm also still a bit concerned about anyone who makes this edit summary comment: [3] and then procedes to push for questionable language comparisons... Please review WP:POINT as soon as possible, and I will continue to attempt to assume good faith. -Harmil 18:28, 10 May 2006 (UTC)

Thanks for pointing me to that badly written guideline. I fixed it.

From various comments I've heard about TIOBE's data and my own data from a similar study, it seems there are people who think it's meaningful, even once they know where it comes from. It's just part of the information in that paragraph that makes the argument that Perl is losing popularity. I've read Perl has lost popularity elsewhere as well, and I'm sure I'm not the only one. If you must edit it, say something like "...based on advanced search engine queries." Maybe add a footnote with the exact query and list the search engines. Unfortunately, I don't think the page on TIOBE's website with the details is directly accessible with a link when Javascript is on. -Barry- 19:32, 10 May 2006 (UTC)

Of course the data has meaning. Almost any statistic has some sort of 'meaning'. You just have to be careful to explain what it's measuring and what it's showing. And I don't feel you are doing that properly. Since it's using simple (NOT advanced) Google/Yahoo/MSN searches, it's probably picking up mostly forums, blogs, and corporate hype. It's not picking up on the number of actual projects using a particular language, or the number of programmers with experience in that language. A search involving job advertisements would be much more realistic, IMHO. This TIOBE index is extremely superficial. Imroy 23:57, 10 May 2006 (UTC)

Not only that, but these statistics do not include any knowledge of what languages are used for intranets which can form a large part of commercial development. Enigmatical 00:07, 11 May 2006 (UTC)

TIOBE gives relative rankings. Perl needn't lose popularity in order to fall in the rankings. All that is necessary is that other langauges grow faster. I have one data point that bears on this. I host the Perl Module Mechanics page. Traffic to this page has been growing slowly, but steadily, over the last few years. Swmcd 23:24, 10 May 2006 (UTC)

The word popularity still fits. I don't think saying something like "per capita" or "relative to..." is necessary. Citing the increased number of users (or web searchers) would be useless unless you cite it for of other languages too. But clarify whatever you want if you think it's necessary. -Barry- 23:36, 10 May 2006 (UTC)

Good grief! Has anyone looked at the TIOBE page? Between 2004 March and 2004 April, Java dropped from 24% to 19% in the rankings. At the bottom, they have this FAQ

# Q: What happened to Java in April 2004? Did you change your methodology?

A: No, we did not change our methodology at that time. 
Google changed its methodology. 
They performed a general sweep action to get rid of all kinds of web sites that had been pushed up. 
As a consequence, there was a huge drop for languages such as Java and C++. 
In order to minimize such fluctuations in the future, 
we added two more search engines (MSN and Yahoo) a few months after this incident.

With artifacts like that, how can we cite TOIBE as evidence of anything? Swmcd 23:45, 10 May 2006 (UTC)

The TIOBE paragraph also says

OSCON — the open source convention sponsored by book publisher O'Reilly — is 
much less Perl-oriented than it used to be. Randal L. Schwartz, author of several 
Perl books published by O'Reilly, has said that OSCON's organizers are openly 
hostile to Perl, and that Perl isn't interesting to O'Reilly anymore.

Could we get a direct quote here? Or a report from Randal himself?

A further question is whether this is relevant to Perl, or only relevant to people who publish books about Perl. Swmcd 23:54, 10 May 2006 (UTC)

I gave the source of the quote in the edit summary. It's from a chat logged at [4]. It comes from more than one sentence, and I figured it would look better not to make it a quote. -Barry- 02:48, 11 May 2006 (UTC)

I thought there was a policy against reposting logs? Also, this edit isn't very informative regarding Perl or opinions on it. It seems more like the edit was made to embarass Randal, O'Reilly, or both. Steve_p 19:49, 18 May 2006 (UTC)

It's related to Perl's popularity and changing opinion of Perl. I don't know about the reposting logs rule, but it's not like it's a personal log. The log is well known to that community and on a public website. Major Perl 6 development takes place on Freenode's #perl6 channel, by the major players, and it's run by the Perl Foundation (or whatever they're called). -Barry- 21:10, 18 May 2006 (UTC)

I think this material needs to be moved to another section. As discussed above under Talk:Perl#Pro vs. Con, the purpose of the Perl#Opinion section is to present and summarize opinions that are held of Perl. Data indicating the prevalance of various opinions isn't really to the point. Compare the American_politics page, which has separate sections titled American_politics#Political_culture (outlining the political views of Americans) and American_politics#Political parties and elections (tabulating recent election results). Swmcd 03:39, 13 May 2006 (UTC)

This is another stupid idea from Barry. The data DOES NOT SHOW that Perl is losing in popularity. Period. It cannot show that, it does not show that, and it is incorrect to state or otherwise imply that it shows that. Pudge 15:22, 18 May 2006 (UTC)

Benchmark comparison

There's already a Comparison of programming languages article, but it wouldn't be practical to include a detailed comparison of every two languages. A detailed comparison between Perl and other languages might work for Perl's article, or maybe for a separate article titled Perl language comparison. I did that "be bold" thing and added it to this article.

I remembered this Perlmonks thread about a contest that I was thinking of mentioning here or in Comparison of programming languages, and that lead to me finding this page of links to various benchmarks. I clicked "Debian : AMD™ Sempron" then clicked "Perl" then selected the languages to compare Perl to, and that's what my tables are based on.

There are disclaimers on that website about the data not always applying, and there are other benchmarks for other operating systems. Maybe more information should be gathered for a separate page. -Barry- 08:24, 11 May 2006 (UTC)

This benchmark is horribly, horribly flawed. In just 10 minutes of cursory analysis, I was able to modify the first benchmark[5] so that it ran over 20% faster in Perl. I've removed the results, as it seems that no useful information can be extracted from such a flawed study. -Harmil 14:39, 11 May 2006 (UTC)

That kind of thing works both ways and probably balances out. Could you post your modification somewhere? -Barry- 18:20, 11 May 2006 (UTC)

I gave you the link to the modification above, and no, we cannot assert that it "probably balances out". Can we please, just stick to facts. This benchmark, like almost any cross-language benchmark is horribly flawed, and should not be referenced. -Harmil 19:21, 12 May 2006 (UTC)

Sorry, I didn't know that was the link to the diff. Unfortunately, I'm not sure how to read that and I don't want to learn. I like the added context of surrounding code anyway. I'd prefer if you use my DiffNote web application and link to the results. But it probably won't make a whole lot of difference in my opinion of whether to add the Benchmark Comparisons section. In fact, I wouldn't even be able to cite your improved version of that benchmark because of the no original research rule. On the other hand, I wouldn't object to a stronger disclaimer, especially if you've actually managed to legally improve the speed, and you may be able to submit your benchmark, which would allow it to be used in this article.

Also, even if you did speed the script as fast as you claim without breaking it, that doesn't mean Perl would have won any more tests, and if it did win one more, that's only a small fraction of the 16 or so speed tests (32 now that I doubled the data). Using one improved test to discount the validity of the entire data set is itself flawed.

I noticed that part of your modification goes against best programming practices. You replaced descriptive variables like $item with Perl's default variables like $_[0]. I guess that's technically allowed, but I wouldn't want to maintain your code.

I think we need more input on this, because I really think the Benchmark Comparisons section improves this article and I'll probably put it back. I don't think there's anything like it in other programming language articles and it could help make this article a featured page.

Again, I wouldn't mind disclaimers and references that show that the results should be considered with caution. In fact, the section can concentrate on the flaws in cross-language benchmarks, but some people would figure it balances out and may put some value on the data. How DO you choose a programming language if you want speed, or something else that can be benchmarked, but don't have different versions of the exact program you'll be using that are written in multiple languages? If you do have some important snippets written in multiple languages, how do you know you wrote them each optimally so the comparison lives up to Harmil's standards? People need to make those language choices sometimes, and most probably base it on less accurate information than is contained in these benchmarks.

It's probably more accurate to use the references here to learn how to create a benchmark specific to your machine and program (I included that link in the Benchmark Comparisons section), but if you don't want to go through all that, what do you do? Ask some guy on a message board? Questions like "what language should I use for..." are asked all the time, and when it comes to needing speed or fewer lines or less memory, the data Benchmark Comparisons article is probably better. -Barry- 20:50, 12 May 2006 (UTC)

Here's a link to the last version of the Benchmark Comparisons section that was reverted, and here's a link to Wikipedia's dispute resolution guidelines, in case it's necessary. -Barry- 21:08, 12 May 2006 (UTC)

The Benchmarks section now carries a Factual Accuracy template, but that isn't really the issue. Assuming that the benchmark results were correctly copied from their source, they are accurate. The question is whether they are meaningful or relevant to people reading the Perl page. This is an encyclopedia article. It is meant to provide a introduction/overview for non-specalists. A link to a site with benchmarks results might be appropriate; an entire section of benchmark results copied from somewhere else probably isn't. And adding a link to a page titled Flawed Benchmarks doesn't redeem it; it makes the case that the section shouldn't be there in the first place. Swmcd 02:48, 13 May 2006 (UTC)

There's a conceptual problem with a Perl vs. C benchmark: the Perl interpreter is a C program. On its face, the Perl vs. C box that gives Perl 1/1 wins for speed asserts that Perl is faster than C on that benchmark. But underneath, what it means is that the Perl interpreter has faster C code than the C implemetation of the benchmark.

We could improve the C implementation by extracting the relevant code from the Perl interpreter and using that instead. But that would probably be difficult and tedious. Here's a better idea: for the C implementaion, take the Perl code, and let the Perl interpreter run it. The Perl interpreter will execute the relevant C code, and now the C implemetation is as fast as the Perl implementation :) Swmcd 03:05, 13 May 2006 (UTC)

The table layout needs work. When I looked at it, I assumed that the numbers in each cell were tests won/total tests. Then I saw entries like 9/8, and knew that couldn't be right. After looking at the table heading, I realized that each cell reports two different counts, in the format AMD/Intel. This needs to be made obvious to the casual reader. Swmcd 03:16, 13 May 2006 (UTC)

Would a comma or pipe be better than a slash? And maybe make a number bold if it's higher than the corresponding number in the other column. -Barry- 04:25, 13 May 2006 (UTC)

-Barry-, please review my recent edits. Note that I have condensed large tables of infromation into fairly simple prose of three paragraphs' length. There are several problems with dumping huge tables AND massive amounts of disclaimer into this article. They clutter the page, aren't really Perl-specific, are arguably not very encyclopedic, and don't actually further the point of the article: explaining the nature of the Perl programming language. I hope that you can respect the need to have a clear and relaitvely usable article for any language, not just Perl, and will continue to edit in that light. -Harmil 22:31, 13 May 2006 (UTC)

Bias being added

Please -Barry-, stop editing this article to insert bias. I've placed an entry for this article on the RfC list. You've been quite clear in your convictions in your edit summaries [6], your talk page [7], and your refusal to remove material which has not only been disputed, but clearly demonstrated to be incorrect. [8] It is time to let it go. -Harmil 12:21, 13 May 2006 (UTC)

A description might help. Your RfC entry is here, under Telecommunications and digital technology, but it just says "Talk:Perl 12:15, 13 May 2006 (UTC)" -Barry- 17:14, 13 May 2006 (UTC)

You didn't sign it either. Read the Request for comment template on top of that page, particularly item 1 and 3. It says:

1. List newer entries on top, stating briefly and neutrally what the debate is about.

2. Provide a link to the relevant article's talk page.

3. Sign entries with the date only, by using five tildes: ~~~~~.

-Barry- 17:22, 13 May 2006 (UTC)

The instructions for the RFC process is horrible. In one location it asks for the talk page link and date only (and gives an edit link), then on the page that you actually edit there are the guidelines you listed which don't match at all, but you never see those, unless you scroll up after the section edit. Doh! -Harmil 21:39, 13 May 2006 (UTC)

So the question remains, -Barry-: do you intend to keep modifying this article to suit your "anti-perl" (your words) sentiments, or will you yield to the request of three (so far) editors who have cited strong concerns with you edits? I'm going to do a bit of editing to demonstrate what I'm talking about. Of course, as a fellow editor, I invite you to revise my edits in ways that help Wikipedia to cover the language, but not to re-introduce bias. This is an article about a programming language, not your preferences. -Harmil 21:54, 13 May 2006 (UTC)

There may or may not be an anti-Perl flavor to my edits, since I'm somewhat anti-Perl but try to be fair at the same time, but I still think my edits are accurate and improve the article. You initiated a RfC, so lets let that happen before removing large amounts of content from the section in question. We'll have a vote after that if you want. This isn't my article and I won't put my version back once enough people have been heard, preferably who aren't currently involved with Perl. -Barry- 22:53, 13 May 2006 (UTC)

I have given Barry warning: no more bullshit. If he continues, I will just routinely revert every edit he makes in Perl, regardless of what it is. Enough is enough. Other editors who are not Barry, feel free to join in the fun. Pudge 15:25, 18 May 2006 (UTC)

Bias being added II

In this edit summary, Scarpia refers to a slide in this document that says "...and it sux..." His edit summary says "it's unclear what the slide in question means since it's a two word summary of something said in the talk. This doesn't pass the verifiability test, and is irrelevant anyway." I believe it's perfectly clear what the slide refers to. The slide before the "sux" slide says "Benchmark.pm comes with Perl..." and the slide after the "sux" slide continues the discussion of the module. It's perfectly clear that "...and it sux..." refers to Benchmark.pm.

Scarpia's edit summary says it's irrelevant anyway. When mentioning Benchmark.pm in a Benchmark section and mentioning the slides, how could it be irrelevant to say a slide says it's a bad module?

Scarpia edited the Benchmark section so it no longer mentions the slide that makes a negative reference to Benchmark.pm. He's only allowing mention of the slide that warns about benchmarks in general. Also note that he recently blatantly vandalized this article by reinserting previous vandalism (the paragraph on the lower right of that diff). Yet another case of clear bias.

I tried to compromise by not using the quote that contains "sux" and instead using "...[the slides] warn people about the limitations of benchmarks — particularly about the module Benchmark.pm". That should be reinserted into the article.

I believe Scarpia is Brian D Foy, so if he openly admits that and if he now believes something opposing what the slides say, or if he wants to clarify something or claim he didn't mean the slide text literally, he should speak up and his new opinion or clarification can be included in the article after the description of the slides. Though his saying he's Brian D Foy may not be enough for some of the editors here. Either way, the slide with the negative reference to Benchmark.pm should be mentioned. -Barry- 02:54, 21 May 2006 (UTC)

"Scarpia's edit summary says it's irrelevant anyway. When mentioning Benchmark.pm in a Benchmark section and mentioning the slides, how could it be irrelevant to say a slide says it's a bad module?"

The reason you can't is because a "slide" does NOT convey what the author meant unless you heard the actual talk the author gave using that slide. In every other instance and to everyone else who wasn't there it is out of context. I happen to know (because the author of that slide has blogged about it) that he wasn't refereing to the module itself but how people misinterpret the results and it was a throw away joke to boot. So your using it is clearly wrong. -sigzero-

Future of Perl 5

It's best for section to have at least two subsections. The Future section should have a Perl 5 and Perl 6 subsection. Perl 6 is already written. Perl 5 should be about the Perl 6 features that are expected to be ported to Perl 5, and stuff. -Barry- 07:28, 13 May 2006 (UTC)

brian d foy's style guide

Brian D Foy apparently wants attention. See [9]

I don't think his name should be in lower case. If so, there needs to be a footnote or something parenthesized to mention his preference and how his name is generally written, and that's sloppy. I'll agree not to use a period after the "D" because maybe it really doesn't stand for anything, but unless there's a consensus for lower casing it, I won't. -Barry- 05:11, 14 May 2006 (UTC)

How a person wishes to be referred to is entirely their right to decide and is not within your remit to alter. If you insist on maintaining this presumptuous and insulting attitude, then you are also authorising us to change your name. I think from now on you should be known as"♥♥♥Jennifer ^_^" instead. -- Earle Martin (talk, contribs) 23:50, 22 May 2006 (UTC)

Al Tobey, President of the Grand Rapids Perl Mongers agrees with me: [10]. -Barry- 21:54, 14 May 2006 (UTC)

Barry wrote in a recent edit summary:

Scarpia, this is a talk page for the Perl article, and I had a
question about notable Perl guy brian d foy, who I now think is you
and who's named in the article. I need to know how to case the name.

Trying to "out" one of the editors now Barry? You're certainly not helping your image in this part of Wikipedia. Imroy 22:28, 14 May 2006 (UTC)

There's good reason to "out" an editor, if I understand what you mean by "out." See Wikipedia:Wikipedians_with_articles which says "Another reason for this page is to notify the community that these Wikipedians are potential autobiographers, with the risks that entails for NPOV in articles relating to them and their work."-Barry- 22:48, 14 May 2006 (UTC)

Call for "See also" links for Pro section

As I've said, I try to be fair. I also like uniformity in the divisions of the article, even if it takes pro-perl material to do it. The Con section has a See also section, and I intend to add another link to it ( http://www.cabochon.com/~stevey/blog-rants/blog-ancient-perl.html ) once it's working again (see http://www.google.com/search?hl=en&lr=&safe=off&rls=GGLG%2CGGLG%3A2005-21%2CGGLG%3Aen&q=%22Algol+made+its+mark+on+the+world%22 ). I found it when searching for pro-Perl opinion. Maybe someone else will have better luck. I'll keep searching for pro-Perl stuff, but I'll probably add the anti-Perl link whether I find anything or not. -Barry- 00:36, 15 May 2006 (UTC)

Please review Talk:Perl#A warning on adding content before hacking on the Perl#Opinion section.

More generally, consider that the purpose of a Wikipedia article is to inform its readers, and that the structure of the article is subordinate to that purpose. Content should be added or rearranged only if it makes the article more useful or accessible to its readers. It should not be done just for the sake of uniformity. Swmcd 02:05, 15 May 2006 (UTC)

Uniformity is nice too though, and I don't want my edits to appear biased because they might be reverted even if they're appropriate.

I was thinking that you might have had the first blockquote in the Con section in mind when you wrote "There is a natural tendency for people reading this section to add material responding to opinions with which they disagree. However, doing so is not appropriate for this section. It obscures the point of the section and risks becoming POV." I almost replaced that blockquote with something more "conny" but I think it's ok. -Barry- 03:03, 15 May 2006 (UTC)

Linking more than first instance if a term

There's some guideline about only linking the first instance of a term for which there's an article, but I rarely find that's a good idea, especially in a technical article in which people are trying to learn something complex. They shouldn't have to search the article for the first, linked, instance, assuming they even know it would be linked, and they shouldn't have to type it into the Wikipedia search box.

It can also look sloppy and inconsistent, like someone forgot to link the term. For example, at Control structures, C isn't linked, but right next to it Java is linked.

Maybe the talk page should have guidelines on top, explaining why every instance of any term that's linked should be linked, so the Wikicops will understand the reasoning--that usability is especially important for articles like this. -Barry- 07:25, 17 May 2006 (UTC)

I don't know if it's mentioned in the guides, but it's not usually a good idea to only link the first instance in a long article. It really should be "once per major section" or something similar. Imroy 07:47, 17 May 2006 (UTC)

References section

I just noticed the Wikibook template in the references section, and now I'm wondering whether the references section is just for references used in writing this article or not. If so, I think the heading should something more clear than "References." If not some of the links in that section should be under External links. -Barry- 08:18, 17 May 2006 (UTC)

Popularity, again

I removed the following:

There's also criticism of a less technical nature that may be no less important to some. Some people believe Perl's popularity has declined. in the years betwen 2001 and 2006. This may represent a true decline in Perl's usage or an aspect of the transition from a young to mature language. It may also be a result of the fact that it has been well over a decade since the last major release of Perl, and Perl 6 development continues after over 5 years without an initial relase.

In addition, OSCON — the Open Source Convention sponsored by O'Reilly, which started as The Perl Conference — is much less Perl-oriented than it used to be. Randal L. Schwartz, co-author of several Perl books, has said that OSCON's organizers are openly hostile to Perl, and that Perl isn't interesting to O'Reilly anymore.(Paraphrased from merlyn's posts (Randal Schwartz's IRC handle) on Freenode's #perl6 irc channel. sel=86#l151 Archive of chat; sel=93#l161 continued archive)

The first paragraph is classic weaselling without any facts to back it up. The second is irrelevant - what OSCON chooses to focus on is not the measure of Perl. Personal opinions expressed about what seems to be the opinion of someone else (in this case, the OSCON organizers) are not encyclopedia material. -- Earle Martin (talk, contribs) 14:18, 19 May 2006 (UTC)

Facts to back up opinions aren't necessary in an opinion section, but it's true that there needs to be some indication of what people's opinions are. I don't think that the quality of documented evidence needs to be very high if most of us have heard, as I have, that Perl isn't as popular as it used to be. Whether you've heard that or not, there was some documented evidence indicating that some people would believe Perl is losing popularity, but it was reverted. It was the part about the TCPI Long Term Trends chart in the following paragraph.

"There's also criticism of a less technical nature that may be no less important to some. Perl's popularity has declined. As of May, 2006, the TCPI Long Term Trends chart of the ten most popular programming languages shows that Perl's popularity is at its lowest since before June, 2001 (the earliest date plotted), and has dropped more than any other language over the past year. In addition, OSCON — the open source convention sponsored by book publisher O'Reilly — is much less Perl-oriented than it used to be. Randal L. Schwartz, co-author of several Perl books published by O'Reilly, has said that OSCON's organizers are openly hostile to Perl, and that Perl isn't interesting to O'Reilly anymore."

Here's an excerpt from Wikipedia's weasel words page:

"Weasel words are words or phrases that smuggle bias into seemingly supported statements by attributing opinions to anonymous sources. Weasel words give the force of authority to a statement without letting the reader decide if the source of the opinion is reliable."

With the TCPI reference, readers could decide for themselves whether the belief that Perl is losing popularity has any basis. Without it, assuming it isn't common knowledge that Perl is losing popularity, you may have a point. I don't like the trend in recent edits to this article to remove information that there's some controversy over rather than explaining things, especially in the opinion section (the related links, for example), and I'd prefer to see the TCPI reference brought back.

About OSCON, I think O'Reilly's opinion counts, and the opinion of Randal Schwartz counts. -Barry- 02:28, 20 May 2006 (UTC)

I think a good rewording of the first paragraph would simply be:

"There's also criticism of a less technical nature that may be no less important to some. Some people believe that Perl's popularity has declined. As of May, 2006, the TCPI Long Term Trends chart of the ten most popular programming languages shows that Perl's popularity is at its lowest since before June, 2001 (the earliest date plotted), and has dropped more than any other language over the past year, though the relevance of the chart, which is based on search engine results, is disputed. In addition, OSCON — the open source convention sponsored by book publisher O'Reilly — is much less Perl-oriented than it used to be. Randal L. Schwartz, co-author of several Perl books published by O'Reilly, has said that OSCON's organizers are openly hostile to Perl, and that Perl isn't interesting to O'Reilly anymore."

I added "Some people believe" and "though the relevance of the chart, which is based on search engine results, is disputed." Didn't add it to the article yet. -Barry- 02:42, 20 May 2006 (UTC)

Barry, just stop. You clearly have an anti-Perl agenda, you even admitted so yourself. That TCPI chart has been shown to be unreliable at best, and any attempt to dress it up is just an excercise in weasel words. You've worn out your welcome here. Go away and stop adding your thinly-veiled bias to this article. Imroy 03:01, 20 May 2006 (UTC)

I'll say again what I've said three times, regarding the relevance of search engine results like the ones used in TIOBE's data:

I had this same discussion on Perlmonks and in Talk:Comparison of programming languages. Here's what I wrote in the latter:

--------

There's Wikipedia:Search engine test. Under idiosyncratic usage it says "A series of searches for different forms of a name reveals some approximation of their relative popularity."

The TIOBE data has been around for a long time and is regularly updated. At [11], where it says "The definition of the TPC index can be found here" you can click "here" to see an explanation. I don't think it's a good explanation, especially for laymen, but it provides some details that might matter to some people.

Here's a discussion that might be of interest.

--------

I'm not dressing up anything. In fact, I've dressed the TIOBE chart down for you, and note that I haven't added it to the article yet. Likewise, please don't delete large amounts of the article without prior discussion. The existence of the chart, its backlinks, and its Google PageRank of 7 make it relevant, and I won't even object to adding your own point of view about it to the article, because it looks like there's no getting around that.

-Barry- 03:28, 20 May 2006 (UTC)

Barry, the Wikipedia:Search engine test is used for a number of things, mainly to decide if an article is noteworthy or should be deleted. Nowhere on that page does it say anything about using the relative result counts from seperate searches for different things. Nowhere does it say anything about using those statistics to conclude that something is losing popularity. You are hiding behind that page as if it defends the information you wish to introduce or the conclusions you have drawn. It does not, and Craig Stuntz even said so on the Talk:Comparison of programming languages page. Can you please just drop the TIOBE chart/data? I'm not going to accept its inclusion in the article as anything but a minor curiosity. Imroy 05:08, 20 May 2006 (UTC)

-Barry- wrote

Facts to back up opinions aren't necessary in an opinion section

This is false. There's nothing special about the Perl#Opinion section. It undertakes to report some facts about Perl, vis. opinions that people hold of it. Those facts must be supported by evidence and references, just like the facts reported in any other section.

I don't think that the quality of documented evidence needs to be very high
if most of us have heard, as I have, that Perl isn't as popular as it used to be.

Also false. The quality of evidence required for an assertion in a Wikipedia article does not depend on how many editors have heard the assertion. Swmcd 04:20, 20 May 2006 (UTC)

Imroy: I think you're being too literal, but I think just the fact that the chart exists and the reason for it that's mentioned the website, and its popularity shows that changes in search engine results are a consideration to some people. I disagree with Craig Stuntz too. I think he's the one who reverted the part of the footnote in Comparison of programming languages that said the TIOBE data an approximation of popularity, even though the full details about the origin of the data was right there in the footnote to avoid misleading anyone. That was a bad reversion, but I let it stand. At least the data's there.

Swmcd: point one, then it's not about opinion and it's just Pro and Con, and the heading Opinion shouldn't be used. I did let Randal's reversion of one of the links stand without questioning him about the problem because I believe he'd know whether something in a Perl article is inaccurate and I wouldn't want a high level of clear inaccuracy, but that's probably biased of me and the link should probably be included considering the limited number of such links that are available.

Swmcd: point two, I don't think there are enough sources given on Wikipedia, but I disagree that whether something is common knowledge to the editors has no bearing on the amount of evidence required. -Barry- 06:08, 20 May 2006 (UTC)

Bottom line on the popularity thing: popularity (or lack thereof) does not constitute a "criticism" of the lagnauge. Not in any way. I'm also not clear on how popularity even fits in as a notable item for a Wikipedia entry, other than to say that Perl is one of the more popular programming languages out there. Speculation beyond that would require visibility into many industries and many development processes. It's also impossible to separate enthusiasm from usage, which further makes popularity an unquantifiable item. Mature languages tend to have much less enthusiasm, this much is clear, but I'm not sure that there can be a reasonable argument that Perl (or any other language's) usage has moved up or down, as most companies don't disclose. -Harmil 22:13, 21 May 2006 (UTC)

Opinion section links

Does anyone really think this was a good reversion? Audrey Tang told me about the things Fish contributed to Perl 6, and even if the author description needs to be changed, the "it doesn't say anything interesting" complaint in the edit summary doesn't say much. Looks like a well written critique to me. -Barry- 06:27, 20 May 2006 (UTC)

Hmm... the link I mention above that was reverted was a pro-Perl link, but the diff page made it look like it's from the con section. I was thinking about the con link with all the sections, which looked impressive. I added the pro link mainly to balance things out. -Barry- 03:14, 21 May 2006 (UTC)

-Barry-, honestly I'm not sure that it's possible at this point to distinguish the value of your individual edits on this page as opposed to your overall campaign to modify the article to suit a personal sense of the worth of the language. The impact of your advocacy of other languages; attempts to portray Perl in a negative light; add flawed data to the page; your refusal to accept the feedback of other editors; and so on are becoming highly disruptive. You have been pushing your point long enough. Please stop, and consider contributing to articles about which you can be more neutral. Thanks. -Harmil 22:03, 21 May 2006 (UTC)

Ooo...that sounds really bad. Maybe you should be more specific and post that in the relevant thread so we could really get into whether my edits are bad. You probably already know about those threads, so I guess you just want to change the subject and bash me some more. Based on prior discussions, the odds are I still think my edits are good for the article. If there's something in particular that you think I shouldn't have changed, you're not making that clear, but I'm really not interested in reading your POV any more. I don't like associating with biased hypocrites. I honestly don't remember what you've said on this talk page, but I'm referring to this, on my talk page, which I responded to. -Barry- 22:25, 21 May 2006 (UTC)

Since we've been over those points many times before, I'm just going to assume this is trolling on your part. You have exceeded even my ability to assume any shred of good faith. Restore that faith if you wish, but otherwise, I'll just continue to review edits to Perl from all editors. -Harmil 16:07, 22 May 2006 (UTC)

More bias by Scarpia

In this revision, Scarpia removed the related links subsection of the Con section for no reason. His edit summary addresses his other reversions: "removing unverifiable IRC discussion. It's irrelevant what a single person says, even if he is a famous author. The commerce of Perl is irrelevant to the language itself"

BS.

Randal's nickname is registered on Freenode and everyone knows it's him. It's registered on Wikipedia too. On my talk page, putting himself in the position of an uninvolved observer, he said that he probably made the comments in frustration after a dispute with someone. Similar to how Scarpia put himself in the place of an observer when he denied knowing what his own slides were about. I apparently have a knack for bringing out the third person in people. I wonder if they make a condom for that.

Anyway, Randal's in the Perl business and probably wants to keep a decent relationship with O'Reilly and/or doesn't want to make it look like Perl's popularity is declining. If Scarpia thinks that Randal really doesn't believe what his own fingers typed in IRC -- about Perl not being interesting to O'Reilly any more -- he should add that to the article, but don't remove relevant information!

"The commerce of Perl..." -- I guess that refers to O'Reilly's interest in Perl. O'Reilly losing interest fits in the Con section because it's about Perl's popularity declining, and if you want to have useful skills and be able to find a good selection of people who could maintain your script in the future, you'll care about that. The article isn't just about functions and modules and the scientific stuff.

Scarpia, some of the editors here may not want me around, but I'm here for Wikipedia, not for Perl, and I believe you're a detriment to Wikipeda and even to those wanting to learn about Perl.

Adapted from Billy Madison: Everyone who's read the Perl article after your edits is now dumber for it. I award you no points, and may God have mercy on your soul." -Barry- 08:39, 22 May 2006 (UTC)

That edit was a good edit. Please refrain from adding your Anti-O'Reilly bias to the Perl article. Thanks! Steve_p 14:56, 22 May 2006 (UTC)

Agreed. I'll keep an eye out for such "bias removal" when I have time. -Harmil 16:09, 22 May 2006 (UTC)

So tell me what's wrong with the external link, or anything else! Say something! The link is anti-perl, but it's in the Con section! This was the entry that was reverted:

Related links

• "Usability" of the Perl Online World for Newcomers — by Shlomi Fish, critic and developer of Perl 6.

-Barry- 23:59, 22 May 2006 (UTC)

I just read about half of that site. The intro is substantially blogish and off-topic for "what's wrong with perl", but hey, it's an intro. The complaints about the documentation seem off-topic and almost whiny at times..feels like "the official docs suck and I don't feel like buying better ones, therefore the languages itself is bad". At most, does any of this speak to more than just "perl has a steep learning curve"? DMacks 01:01, 23 May 2006 (UTC)

And in all honesty, what language does not have a steep learning curve nowdays? If you want flexibility and functionality it comes at a price of complexity. I think gone are the days when any modern language is unnecessarily difficult to learn for no other reason than its the lanugage (as opposed to its paradigm or specific target technology). Sure it may be hard to read due to syntax, but the concepts are not new. Enigmatical 01:10, 23 May 2006 (UTC)

I just read the Fish article—all of it. There is nothing really bad about it, but I don't see that it brings enough value to the Perl page to justify a link. It is long, somewhat rambling, and it is hard in many places to work out what the author is really saying or advocating. As best I can tell, his main points are

• Perl is a great language
• Learning Perl is hard
• Newbies are liable to get flamed for asking elementary questions on IRC
• We should write on-line documentation and tutorials—the more the better
• Authors of introductory texts should make their books available on-line

And for all that, I can't say that it is an anti-Perl page. In particular, it doesn't support or illustrate the views presented in the Perl#Con section. So I can't see a case for linking to it from the Perl page. Swmcd 06:53, 23 May 2006 (UTC)

The link is only one of the several things that need to be put back in the Con section. This will likely go to mediation if all of the content isn't restored or the POV header isn't restored. Anyone reverting my POV heading is a vandal IMO, considering my points, and should be banned from Wikipedia.

About the link, the first two editors who actually made an argument about the article say it's anti-perl. Swmcd says it's not. I say it is. That's three against one. Here's the TOC:

..............

Table of Contents 1. Me as a Perl Newbie

2. The Story of Mel

3. The Situation Today

Concentration of Effort and Elitism

Lack of Adequate Online Resources

Lack of Adequate Mailing Lists

Substandard Standard Documentation

Too Much Hubris

4. What's the threat?

5. What we should do about it?

Independant Activitity

Become your biggest Perl Guru

Treat Beginners Nicely and Help Them

Think about Usability Issues

Create Archives of Perl Code and Documentation

Don't be afraid to charge money or say no

Revamp of the existing resources

6. Conclusion

..............

Read the section titles. Title 5 says "What should we do about it?" It obviously implies that problems were mentioned previously. -Barry- 12:27, 23 May 2006 (UTC)

Before you try to misread and misuse what I wrote any further, -Barry-, let me state clearly and unambiguously that I feel that the link does not belong in the article. DMacks 14:42, 23 May 2006 (UTC)

If you think that the Fish page supports or illustrates negative opinions of Perl, then add a direct quote from the page to the Perl#Con section, and link the page as the source of the quote. Then people can decide

* whether the quote is interesting, informative, and relevant

* whether Shlomi Fish is sufficient authority for a quote in the Perl article

Swmcd 15:22, 23 May 2006 (UTC)

Article removed from Wikipedia:Good articles

This article was formerly listed as a good article, but was removed from the listing because it no longer complies with good article criteria 4 (neutral point of view) and 5 (stability)

-Barry- 04:20, 23 May 2006 (UTC)

The problem of NPOV is largely under control as reasonable editors revert edits in Barry's avowed campaign to discredit Perl and people associated with it. His extreme social difficulties here and in other Perl communities has fueled obsession with the destruction of Perl, despite the input of many editors otherrwise. Barry has not operated in good faith, and his continued participation is detrimental to the Perl article on Wikipedia. Scarpia 05:23, 23 May 2006 (UTC)

This is the most outrageous thing I've seen in a long time. User:-Barry- comes along and tries to inject POV into Perl, and upon failing removes Perl from the Good Articles list because his revert wars have resulted in instability.[12] Amazing! I have to wonder at what point this becomes an outright bannable offense. -Harmil 05:39, 23 May 2006 (UTC)

I agree that Scarpias use of the word "vandalism" to describe the inclusion of a POV tag to be a bit extreme and certainly something which has a specifically non-neutral POV (which is exactly what the tag was put there to indicate). Enigmatical 05:41, 23 May 2006 (UTC)

If you are agreeing with me, don't. I'm talking about the actions of User:-Barry-. Review the history of his edits. He started off with glaring inaccuracy and POV, and has slowly tried to back it off and sneak in his (admitted) POV anywhere he can. He's resorted to using other pages, templates, and even de-listing Perl from the good articles list [13] with his own revert-wars with several editors as justification. I agree with User:Scarpia that tagging the entire article as POV because he doesn't think that his POV is being represented in a sub-sub-section (Opinion / Con), after revert warrning against all comers is an act of vandalism. Tag the section and be specific if you want to get anywhere with that so that we can come to a consensus on the specific changes (if any) needed to resolve the dispute. Sadly, -Barry- has not, as yet, been interested in such resolution. -Harmil 05:53, 23 May 2006 (UTC)

The choice of POV template is arbitrary sometimes. A POV template in the opinion section without an explanation looks like it's just telling people there's opinion there rather than fact, which is a no-brainer since it's called the opinion section. I needed to add an explanation to the template, and that's only available in a top-of-page template.

"Barry's avowed campaign to discredit Perl and people associated with it" I'd like to see a quote that shows me avowing that. -Barry- 05:56, 23 May 2006 (UTC)

-Barry-, you know as well as I that you have been POV-pushing and specifically targetting well known Perl contributors since you started editing this article.

• You have attempted to disrupt the Wikipedia articles of well-known Perl "personalities" (side note: the justification of an action by refering to barnstars that you put on your own user page is beyond silly) [14]
• You moved the "Humor" section up above all other links, and re-titled it "references" with the edit summary "Did a bunch of good stuff" [15]
• You edited in "co-" in front of "author" in reference to a popular Perl author who has both written and co-written Perl books with the summary "Demoting Randal." [16]
• Your injections of anti-perl rant links included articles where the author described his drinking to the point of incoherence WHILE writing the rant. [17]
• You have openly antagonized and POV-pushed your python bias in edit summaries. [18]
• You have used your own edit wars as justification for removing Perl from the Good Articles list [19]
• And when you couldn't make any progress on Perl, you branched out [20]

This is wanton vandalism, POV-pushing, and violation of WP:POINT. -Harmil 06:21, 23 May 2006 (UTC)

"I will be taking whatever action I deem reasonable to hurt O'Reilly. I'm not limiting it to not buying their books." -- http://www.perlmonks.org/?node_id=323467 Steve p 18:22, 23 May 2006 (UTC)

1. About disrupting "personalities": Was a response to an argumentative question about why my opinion matters. I don't see my actual opinion there as being a disruption.

2. About moving Humor: No I didn't. I moved links from the humor subsection of the external links section to a newly created "Related links" subsection in the Fun with Perl section. And more good stuff.

3. About Randal being an author: When it was reverted, I explained in an edit summary that adding the "co" was consistent with Wikipedia's article on Randal when referring to Perl books. If he's written more than one Perl book by himself, the co should be removed.

4. About drunk blogger: If you read that much of it and still think it's justified to pick on that one sentence, there must be some bias award for you. It was a long, well written article with many responses, including the first, which starts off with "Another terrific essay Steve. I'm citing your blog to potential new-hires as another reason to work at Amazon."

5. About Python being better than Perl: In AN edit summary, but only because Python really is better than Perl.

6. About removing article from good articles list: It's just as much your war, and I happen to be the good guy. Anyway, rules are rules, and I cited two valid reasons for this no longer being qualified as a good article.

7. About branching out: Thanks for linking to my edit summary with my explanation. There's more on that article's talk page. So, what's the problem exactly?

-Barry- 08:35, 23 May 2006 (UTC)

"It's just as much your war" Not at all. I have sought the consensus of the editors on this page; I have not tried to inject my own opinion; I have not tried to re-tool the article to my own preferences; and I have contributed compromises (such as the performance comparison section that I wrote and you reverted) where I did not always feel that a compromise was required.

Of the rest of the points, I concede that on #2, I mis-read the diff. I still don't think it was a particularly helpful edit, nor in the spirit of the rest of the article, but that's a preference, and you had not done what I thought you had. The rest of the points you make I would contest in two ways: 1) they are mostly factually inaccurate (the drunk blogger mentioned several times that he was drinking, and even made a joke out of it, and also referred to his writing as a rant; you have asserted that you are anit-perl and pro-python several times in several ways here, on your talk page and in the edit summary linked above; and so on), but 2) the overall tone of your response to this and every other criticism dismisses, as you have been doing from the start, the contributions or thoughts of any other editor in favor of your own opinions ("Python really is better than Perl", "I don't see my actual opinion there as being a disruption", etc).

I want to appologize. I appologize for the fact that you have been mistreated by some. I appologize for the fact that your contributions aren't meeting with the consensus, since I know how awful that can feel. I would like to see you contribute positively. I do, however, think that you need to walk away from Perl-related things for a while and get some perspective. Why don't you give us time to put Perl back into the state that it was in when you found it (that is, a "Good Article" according to Wikipedia's standards). If you insist on just charging forward with revisions to this and related pages, other authors like myself who would like to work with you as a peer, have no chance to do so, and we are left feeling as if you simply want to vandalize the article(s) of a language to which you have professed a dislike -Harmil 21:31, 23 May 2006 (UTC)

Where's the index on the talk page?

Where's the index on the talk page? -Barry- 08:03, 23 May 2006 (UTC)

User:Earle Martin had tried to use footnotes earlier and that removed the table of contents for some reason. I've changed the <ref> tags to parentheses. Imroy 08:31, 23 May 2006 (UTC)

It was a straight C&P of material out of the main article which included footnote links. I don't know why it broke the TOC. -- Earle Martin (talk, contribs) 10:32, 23 May 2006 (UTC)

Same problem with the main article. -Barry- 08:38, 23 May 2006 (UTC)

I went back through the history until the TOC reappeared, and checked the diff. The only thing that stood out was the <ref> tags. When I removed them the TOC showed up again. Weird. Imroy 11:05, 23 May 2006 (UTC)

I was on #wikipedia on IRC and it was a known issue today. It's been resolved. -Barry- 11:34, 23 May 2006 (UTC)

This might explain it in more detail. Jude (talk) 11:42, 23 May 2006 (UTC)

Mediation

I'm the new mediator for Wikipedia:Mediation Cabal/Cases/2006-05-23 Perl. I've created a page at Talk:Perl Mediation to separate the mediation from the rest of this. jbolden1517^Talk 15:47, 27 May 2006 (UTC)

• To support this, let it be known that interference with the mediation process is a form of trolling. Furthermore, people should not conduct personal attacks. We're working to build an encyclopedia here; let's keep this focus in mind. --Durin 12:38, 5 June 2006 (UTC)

Perl's OO model influenced by Python

In the Influenced by area in the infobox, this should be mentioned (that Python influenced Perl). Should there be a footnote to specify how, since it was probably minor? -Barry- 21:53, 2 June 2006 (UTC)

Please add it :), although I don't think any additional footnote is needed that it only influenced the Perl 5 OO. Just cite the source as it isn't common knowledge. Steve p 22:28, 2 June 2006 (UTC)

Oh, and add C++ as well. Steve p 23:15, 2 June 2006 (UTC)

Are you sure it was minor? I once heard Larry say that the Python OOP system ad seemed prety good to him, so he ripped it off entire. -- Dominus 22:30, 3 June 2006 (UTC)

brian d foy on percentages and the TIOBE data

Brian shows how using percentages can distort statistics - Don't compare percentages:

Percentages remove information to make things easier to see, but they aren't there to be compared to percentages from another measurement. If the total number stays the same, the trend in percentages might have meaning, but if I don't report the total size, the percentages don't have enough information for me to compare them across measurements.

Yet more reason to keep links to that deceptive information off of Wikipedia - any article. Imroy 11:14, 5 June 2006 (UTC)

Any particular reason you're not discussing that in this section of the mediation page? We've been focusing on the Tiobe data there.

Anyway, I don't agree with brian d foy, and I wonder if someone can provide another source for that belief or if you can tell me how brian d foy is qualified to know such a thing. The mediator lists several areas of mathematics as his areas of expertise. The mediation page would be a much better place for this.

I probably don't have any more experience with this than brian d foy, but I don't think you need the same total number. Depending on the situation, you may know the total number for each percentage being compared is approximately equal, and if both total numbers are large and account for, say, over 90 percent of a random sampling of people in an opinion comparison between two countries, then the percentage comparison could be accurate.

In Earle Martin's revision of the Tiobe data, his edit summary says "This TIOBE stuff is non-scientific and not worthy of a reference." Whether it's worthy of a reference is addressed on the mediation page too, by me:

Statistical inferences can be drawn from the Tiobe data too, and the Tiobe data is cited in several journals and books. For example, chapter 4 of Transforming IT education: Promoting a culture of excellence says:

"Postgraduate students are generally aiming to extend their current skill set and diversify their employment options, and most likely want to acquire programming skills they can put into practice immediately. This factor directed the language selection toward one of the languages currently popular in the "real world". According to the TIOBE Programming Community (TPC) Index (TIOBE Programming community index for March 2004, n.d.), the top three most popular languages currently in use, as at March 2004, are Java, C and C++. Java and C++ have both declined in their popularity over the last 12 months, whereas the use of C has slightly increased."

So stop hunting for a group of supporters for something that's not even in the article any more, and stop trying to get people to revert the Tiobe data if it's added again by misleading them, or whatever you're doing, and discuss this in mediation. -Barry- 12:03, 5 June 2006 (UTC)

mediation with a stick

This page has been protected. I'm starting another mediation page Talk:Perl/Mediation/GroundRules

Great. Someone who has no clue about any of what is going on, is stepping in and telling us what to do. Can we request a new moderator, one that actually understands, you know, things? Or is this one of those "personal attacks"? Not that I could care less what you call it; you've already proved, Herr Jbolden, that you are dishonest (willing to go against consensus despite claiming you would not) and that you lack any understanding of the actual issues (asserting that popularity can be quantified by things like book sales and job availability). You are absolutely unfit to do the job that no one actually wants you to do. 15:30, 5 June 2006 (UTC)