Talk:Perl/Archive 2

message: :""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)
replies: text: This seems to be the source, with a little bit of this thrown in for seasoning. --chocolateboy 17:38, 6 Mar 2004 (UTC)
thread_title:  Name 

message: 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)
thread_title:  Backronym in intro 

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

message: 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)
replies: text: Only 30K? You slackers. My talk page is longer than that! :)  --Maru  (talk) Contribs 20:27, 12 November 2005 (UTC)
thread_title:  Time to split the page? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Pro vs. Con 

message: 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)
thread_title:  Opinion is not advocacy 

message: 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)
thread_title:  Use of $a, $b in examples