Talk:Perl/Archive02

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 A sample Perl program 2 [Pp]erl 2.1 Name 3 Perl - Practical Extraction and Report Language 3.1 Backronym in intro 4 Explanation of for/foreach Syntax 5 Sample code formatting 6 Merits and demerits of Perl as a programming language 7 Data types and Variables 8 Time to split the page? 9 Language Design Philosophy 10 Intro paragraph 11 Perl is not (really) an interpreted language 12 Pro vs. Con 12.1 Opinion is not advocacy 13 Use of $a, $b in examples 14 Context-free 15 Hello world 16 Perlscript 17 The lead 18 Perl is interpreted 19 Semicolons used inconsistently in one line scripts 20 Regex examples 21 Page reorganization 21.1 Redraft 1 22 Listed as a .Net Language? 23 processor-bound tasks???

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)