Talk:Perl/Archive 2

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.

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

A sample Perl program

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

Latest comment: 18 years ago1 comment1 person in discussion

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?

Latest comment: 18 years ago1 comment1 person in discussion

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.

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

Latest comment: 18 years ago2 comments2 people in discussion

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

Latest comment: 18 years ago6 comments3 people in discussion

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

Latest comment: 18 years ago5 comments2 people in discussion

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)