Talk:Perl/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Criticism & Bias

This article seems to be remarkably short on criticism of perl. —Ashley Y 00:38, 30 September 2006 (UTC)

In fact, I tried to add a section on criticism -- and it wasn't even hard criticism -- and it was instantly deleted. Therefore, I think it's clear that this entry is *biased*.—Preceding unsigned comment added by 76.118.23.40 (talk • contribs)

You mean this reversion of fluff? Why is this "discordant voice" relevant? Perl is designed for programmers, as is every other programming language. To quote the added text: "if you're not a programmer, you will download Perl and have absolutely no clue what is supposed to be happening". If you're not a programmer, then why download perl, then complain that you don't know what to do with it? It's an invalid complaint. Present something valid instead. Mindmatrix

Also, unsourced (as if finding criticism of Perl should be difficult ...), self-referential ("Regrettably, this article does not clarify things for them."), looking at first sight like original research, but upon closer inspection containing «no config or install programs to run, and no documentation or readme either», which is not even researched, but downright invented (I count 42 readme files in the top directory alone). Calling this "fluff" is too kind. — the Sidhekin (talk) 22:20, 25 November 2008 (UTC)

Oh goodness me, be careful with that box if you're going to open it. (Why? Have a read through the archives to see the approach you shouldn't take.) — Hex (❝?!❞) 00:47, 30 September 2006 (UTC)

I recommend citations of criticism from reputable sources. Did Dijkstra say anything about it, for instance? —Ashley Y 19:48, 12 October 2006 (UTC)

I agree that *if* notable criticisms are being made, they should be included. if. SirEelBiscuits (talk) 07:32, 13 May 2008 (UTC)

How about Eric S. Raymond's classic "Why Python?" article in Linux Journal, in which he makes a very compelling case against Perl's "There's more than one way to do it!" design philosophy, its lack of elegance and compactness, and its general ad hockery, all of which resulting in lack of code maintainability. "Naaah, not notable enough"??? OneAhead (talk) 23:47, 25 April 2011 (UTC)

I don't know how to write a proper, encyclopedic section on criticisms of Perl, but informally I have seen the same criticisms shared over and over again, and I concur:

• Perl code is unnecessarily hard to read, both because of cryptic, idiosyncratic syntactical choices, and because of the touted "There's more than one way to do it!" feature. And the language includes many features in the core language that belong in separate libraries.
• Perl support for objects is funky- incomplete, inconsistent and awkward.
• Perl's implementation of arrays within arrays and hashes within hashes is counter-intuitive and has an unreasonably steep learning curve.
• Due to deficiencies in the language design, Perl has an unreasonably steep learning curve.

and a few from http://www.prescod.net/perl/whynot.html:

• Many not-quite-integrated features are inherited from other languages.
• Behavior is frequently context sensitive.
• There are many implicit behaviors.
• Some built-in types and functions are magic.

And, as a combined result of many of these criticisms, Perl code is unreasonably difficult to maintain. 75.111.158.23 (talk) 01:51, 2 March 2009 (UTC)

Those are software engineering concerns: maintainability, training times, and so on. Unfortunately, those are the hardest criticisms to prove: features which increase training times might dramatically reduce development and maintainance costs, for instance, and usually vary quite a bit from person to person. "Informally", I'm a lot more productive in Perl than in any other language. Perl might work better for my company than it does for yours. There's enough Perl developers around that I'm reasonably confident that you can't prove that Perl is in all cases worse than another language; if such evidence exists, then certainly, let's create a new "In software engineering" section and put that into the article as well.

Software engineering aside, this article is about Perl the language and perl the Perl interpreter and programming tool.

• I'm not sure languages can have criticisms: just about everything you've listed as a criticism of Perl is something Perl developers appreciate, or follows from benefits we consider important (to take one example: the context sensitive grammar allows you to "word" your code to highlight important parts of it, rather than following a set pattern imposed by the language). It would be absurd for English language to complain that pronounciation doesn't always follow from spelling or that missing a dual number is a fatal fault, and either the language should be changed or everybody should move to French. English is the language it is because of its "faults", and so is Perl; there are plenty of people who don't use English because of its "features" which they dislike, and the same is true for Perl. I also note that Python (programming language) doesn't say anything about some developer's dislike of Python's whitespace, which is IMHO as it should be.
• Tools, such as perl, can have criticisms; a good example is Ruby programming language#Criticism, which specifically points out current problems with the most used implementation of Ruby.

-- Gaurav (talk) 04:11, 2 March 2009 (UTC)

I'm a fan of Perl and largely agree with the anon's complaints. We don't have reliable sources one way or the other, but that doesn't mean we can't talk about the potential for errors caused by implicit conversions (which I'm sure all of you have run across), the limited compile-time verification, the missing support for access specifiers in the object support, the efficiency issues compared to equivalent solutions in lower-level languages in scenarios like scientific computing, and so on. There's plenty of room for legitimate, constructive criticism and it doesn't have to all be sourced right away. Dcoetzee 04:42, 2 March 2009 (UTC)

A language is a tool, just a somewhat more abstract one. I love Perl, but I recognize many of the IP editor's complaints. Others are new to me. Some I rather consider a matter of taste – sort of like saying "the Beatles' music was too complex". Others are IMHO reasonable criticisms. (And most or all of it being addressed by way of Perl 6 – but I digress.) Thing is, Wikipedia being what it is, this information should be sourced. If no reference can be produced, what we have is original research. And for that, we have no room. — the Sidhekin (talk) 07:40, 2 March 2009 (UTC)

How come Java gets it's very own whole page of criticism but criticism of Perl barely gets a mention, let alone a section? (Note: I will not accept the assertion that there is no criticism of Perl[1]) peterl (talk) 06:28, 4 May 2011 (UTC)

The validity of such articles is currently unclear; see the last paragraph under WP:POVFORK. As for a section, if you want to write it, go for it. Update 04:03, 31 July 2011 (UTC)— I've revised my opinion on this; see below. Feezo (send a signal | watch the sky) 20:30, 11 May 2011 (UTC)

The problem is that that Perl receives a lot of criticism for it's 'philosophy'. I think that this shouldn't be part of a programming language's article, but instead in an article related to the particular 'philosophy'. Maybe it's sometimes better to call them paradigms. For example Object-oriented programming has criticism. Then there are design decisions, like a big core library. I don't really see how the amount of stuff one ships can really become criticism. It would be better to add this fact to the article at let the reader decide whether it is a good thing or not. Another topic is readability. Perl obfuscation is very popular, but this doesn't mean it's impossible or harder to write readable (well, that's very subjective anyway) code than it is in any comparable language. I think the default implementation of objects should is outdated for a scripting language. One could compare this to Lua (programming language), but there is Moose and with Devel::Declare it doesn't look to different from very object oriented languages, like Ruby for example. I think all this criticism should therefor be mentioned as facts inside there rest of the article. Some people prefer one way, while others prefer it the other. I think this would also be the only way to comply with Wikipedia's principle of neutrality. If we just add facts information also won't be deleted, because someone with a different opinion. --Athaba (talk) 18:43, 12 July 2011 (UTC)

"Quality" under-emphasised

Perl drawbacks are mentioned, but some of perls most important qualities are overlooked; for example - programmer errors (aka "Code Quality") and the high-level nature of perl make perl implementations more robust and considerably faster to reach a market and maintain afterwards.

It's unfair to discuss "performance" and consider only the speed that code runs - ignoring the speed it took programmers to write that code, the correctness of the code itself, and the time it's going to take more programmers in future to maintain it. Given modern CPU speeds and the pace of internet business (not to mention the lack of real problems actually needing rapid low-level CPU-intensive solutions), development performance is overwhelmingly more important anyhow. 203.45.103.88 (talk) 09:42, 10 December 2010 (UTC)

Agonising, eye-glazingly long syntax section

This isn't a tutorial. It shouldn't read like one. The syntax section does not need examples. This needs heavily whittled down, it's a whole article in itself. Chris Cunningham 16:26, 12 October 2006 (UTC)

I reluctantly agree. That's the problem with computer language pages; they get way too long and wordy, with people trying to explain how to perform. This is especially true with this one, Perl being so damn complicated. Perl's dogma, "There's more than one way to do it!" can lead to lengthy and overly-complicated explanations of the various minutiae of methodologies different people have. —The preceding unsigned comment was added by H3xx (talk • contribs) 17:27, 10 May 2007 (UTC).

I also agree. Parts of this page are rather immense, and really not what i was looking for when I looked the article up. SirEelBiscuits (talk) 07:32, 13 May 2008 (UTC)

Lead with Overview, not History

I think we should move the history section back down to the end of the article. It may be logical to begin any subject by reciting its history, that's not usually the first thing that people consulting an encyclopedia want to see. People reading the Perl article in WikiPedia want a basic overview and introduction, and that's what the Overview section is for. Swmcd 15:51, 13 October 2006 (UTC)

A quick glance at the linked languages in the infobox shows that every single one of them opens with the history section. In Perl's case there's an even stronger case what with the "overview" being well over a page long on a 1280x1024 display. Chris Cunningham 16:17, 13 October 2006 (UTC)

While I agree with your points, I think Swmcd's assumptions need close examination as well. An encyclopedia entry is not a reference manual, and it must be aimed at the broadest possible audience. For this article to be encyclopedic it needs to deal with the fact that, while some readers will understand the technical details of the langauge, most will want to place it in a non-technical context to understand its relation to other langauges in an abstract, historical sense. Leading with the history section accomplishes that. In fact, that was one of the first changes proposed when I put Perl 6 up for Good Article review. -Harmil 17:22, 13 October 2006 (UTC)

The problem is that the History section does not place the language in a non-technical context. The History section recounts the sequence of technical developments to the langauge. By the end of the Perl article, a non-technical reader will have some context for this, but at the very beginning, they don't. The new paragraph in the lead gives the reader some orientation, but I think it would simpler and clearer to move the History section back to the end of the article and rely on the Overview section to orient the user. Swmcd 21:36, 14 October 2006 (UTC)

Review of History section for technical ramp-up:

• "Wall began work..." Only the mention of "regular expressions" and "binary data" are technical at all, and both are too fundamental to do much more work on explaining.
• "Until 1991..." The mention of the documentation is a bit abrupt, and could use more context, but isn't technical at all.
• "Perl 4 went through..." About version numbering. Not technical other than in the use of fairly typical version numbering schemes.
• "Development of Perl 5..." Totally non-technical. Again, all about versions and communication channels.
• "Perl 5 was released..." Here, we mention a laundry-list of features. Some might need some context. Some don't. This paragraph could use work.
• "On October 26, 1995..." Nothing really technical, but more context about CPAN would not hurt. As I recall, CPAN's mission changed rapidly, and perhaps some mention of the early history would help.
• "As of 2006, Perl 5..." Some context here would be good. Nothing major, just some reduction in the jargon in favor of descriptive text. "Unicode" for example should be "international text processing features using the Unicode character set," which gives the reader who doesn't know Unicode, but doesn't want to follow the link more of a leg to stand on.

That's it. for the most part, I think it's in good shape as the first sub-section. There are certainly some stubby paragraphs, but when compared to many other language articles, I think it's good. -Harmil 00:50, 15 October 2006 (UTC)

Two "current" versions on ActiveState

Generally, there is one main version of a software program. It is the one with the highest version number, the "latest and greatest". Any version below that is not being actively maintained. Perl is differnt, in that, if someone looks at the ActiveState website, they will see both a 5.8 version and a 5.6 version. Perhaps we should add a paragraph or two describing how and why there are two versions of perl5 being maintained and updated. TakingUpSpace 01:59, 7 December 2006 (UTC)

This seems backwards

The article says:

"sigils...which identifies the data type being accessed (not the type of the variable itself)"

It seems sigils do identify variable type, whether it be array, hash or scalar variable, while the data type is based on context. If you call an array variable with a $ instead of a @, its not going read in scalar context and return the amount of elements, it just going to be empty, or give an error if using strict.--71.229.77.97 02:19, 31 December 2006 (UTC)

I agree. I always assumed (and I think this was written in The Llama too) that array variables existed in a separate namespace from scalars, hashes and functions. Testing this:

$ perl -we 'my @foo=(1,2,3); print "$foo\n"'
Name "main::foo" used only once: possible typo at -e line 1.
Use of uninitialized value in concatenation (.) or string at -e line 1.

--H3xx 16:22, 10 May 2007 (UTC)

I just noticed this. In the article it says "Importantly, sigils allow variables to be interpolated directly into strings." This is ONLY true for scalars and arrays (and hash/array slices, but that's beside the point).

my %hash = ('a' => 1, 'b' => 2);
print "%hash";

will produce "%foo"; the hash isn't interpolated. There IS, however, a way to interpolate a hash using a slice:

my %hash = ('a' => 1, 'b' => 2);
print "@hash{keys %hash}";
# -- OR --
print "@hash{qw/a b/}";

will produce "1 2". Does anyone think it should be changed to read "sigils allow some variables to be interpolated" or "sigils allow scalar and array variables to be interpolated"? --H3xx 16:35, 10 May 2007 (UTC)

In perl6, sigils refer to the data structure and not the data itself. For example, if you get something out of an array, in perl5 it would be prefixed by a $ (scalar) but in perl6 this is no longer the case. It would be prefixed by a @ in this case. I don't like it either. Laurensvh 00:22, 16 July 2007 (UTC)

What interpolates

There is a bit of confusion above, mixed in with some accurate statements. An extended example might help: Given the following scalar, array, hash and reference variables:

use strict;

my $one = 1;
my $sref = \$one; # scalar reference
my @digits = (1..9);
my $aref = \@digits; # array reference
my %cardinals = (one=>1, two=>2,three=>3);
my $href = \%cardinals; # hash reference

my $fsref = sub {return $sref;}; # sub reference; invoked sub returns scalar ref
my $faref = sub {return $aref;}; # sub reference; invoked sub returns array ref

the following things all interpolate (note that they all start with $ or @):

print "$one\n"; # scalar var
print "$$sref\n"; # dereferenced scalar reference
print "${&$fsref}\n"; # dereferenced sub invocation, returning scalar ref
print "@digits\n"; # array var
print "$digits[5]\n"; # array element
print "$aref->[4]\n"; # array element, via array reference
print "@digits[4..6]\n"; # array slice
print "@$aref\n"; # dereferenced array reference
print "@{&$faref}\n"; # dereferenced sub invocation, returning array ref
print "$cardinals{one}\n"; # hash element
print "@cardinals{'two','three'}\n";
 # hash slice
print "@cardinals{sort keys %cardinals}\n";
 # all values in alphabetical order by respective key

With anything that interpolates as a list the final format of the string that renders the list is affected by the $" ($LIST_SEPARATOR) special variable; this defines the glue character(s) interposed between each element of the list:

local $" = ', ';
print "@digits\n";
print "@digits[4..6]\n";
local $" = '; ';
print "@$aref\n";
print "@cardinals{'one','two'}\n";

Nothing that starts with any other character interpolates:

print %cardinals,"\n"; # hash 'unwound'
print "%cardinals\n"; # just a literal
print "{&$faref}->[3]\n"; # $faref (CODE ref.) interpolated as string
print *one,"\n"; # typeglob, recognised
print ${*one},"\n"; # not quite sure what this is, but not an error
print "*one\n"; # typeglob not interpolated
print "&$faref->[3]\n"; # run-time error as $faref not array ref

DBI tutorial

I wrote a short tutorial on using Perl DBI at Wikibooks: b:Perl Programming/DBI - Perl Database Inteface.

Currently it only has one example for Oracle. That's the only DBMS with which i had personal experience.

It would be great if someone could add a section about connection to a free database, such as MySQL.

Thanks in advance. --Amir E. Aharoni 11:20, 16 January 2007 (UTC)

DBI is one of the simplest, and at the same time one of the most versatile, Perl modules I've ever seen. Although you need to know a bit about the target database language, most databases are interchangeable (at least for simple things like inserts, selects and deletes)! I personally love the SQLite drop-in module for DBI. I tested it on a large query with a group by and an order by clause, and it's a LOT faster than using Berkeley databases (see dbmopen), which are NATIVE pseudo-hashes. Oh well -- I just wanted to say how much I love DBI and am with you 100% on including it. use DBI;! --H3xx 16:10, 10 May 2007 (UTC)

Clarification on namespaces

Again there seems to be a bit of confusion interspersed with true statements...more to come shortly. —Preceding unsigned comment added by 77.101.255.40 (talk) 12:30, 18 May 2009 (UTC)

Scalar variables, array variables, hash variables and reference variables can be either lexically scoped (declared with my) or package scoped (declared with our). If declared with my, they don't exist in a namespace as such.; if the same name, eg $x, is used in differently lexical scopes, they are differentiated by the compiler. If package scoped they exist in a namespace; internally package-scoped variables $a and @a in a package are connected by the typeglob a, which can be accessed (this is seldom required) as *a. Other named but sigil-less things (filehandles, directory handles, formats, subroutine) names are all package scoped, and also 'belong' to a typeglob; they are differentiated by the context (which is occasionally ambiguous); conventions also help: handles and formats should be all UPPER CASE, and maybe subs should have a leading cap. In any case, as regards variables, from the programmer's point of view, whether lexically or package scoped, the variables $a, @a and %a are all independent of each other (unless of course you make an explicit connection, eg $a = \@a).

Ivanberti (talk) 13:17, 18 May 2009 (UTC)

altered 'dynamically' to 'lexically' or 'declared with my' in the above paragraph, as the standard texts apply the term 'dynamic' to package variables. Actually there's still a bit of a problem with terminology here: our declarations are also lexical, in that the corresponding variable is only visible in the lexical scope(s) in which they are declared.

Ivanberti (talk) 07:34, 19 May 2009 (UTC)

Fun with Perl -> The Perl community

My reading of "Fun with Perl" was this: it was mostly about the community. Thus, I've re-written it as such, and added a number of details and references. I've also removed some examples that I dont' think actually helped any.

Please, let me know what you think. I'd really like to see the whole thing expanded on the community front to detail some of the growth of the community and the phases of involvement from Larry's daughter / Perl annoucement in 1987 on Usenet all the way up to the RFC process for Perl 6. -Harmil 23:57, 12 February 2007 (UTC)

enhancements

 16:38, 2007 February 28 Aristotle Pagaltzis (Talk | contribs) (→History - [...] enhancements aren’t necessarily minor)

Can we list the enhancements that aren't minor?

Swmcd 16:04, 1 March 2007 (UTC)

It would be nice, but it's not required. If there is even the possibility for disagreement on the point, then we need to be able to cite our sources to claim that any given change was or was not "minor" (an inherently subjective term). -Harmil 16:27, 1 March 2007 (UTC)

A sentence that is hard to understand

From the article:"All variables are marked by a leading sigil, which identifies the data type being accessed (not the type of the variable itself)"

I don't think the differnece between the data type being accessed and the type of the variable itself is clear.ori 18:28, 29 November 2006 (UTC)

I agree actually I think that the Data Types section needs work. Lists are NOT arrays are NOT lists. And there are more than four fundamental types and I think if we are going to discuss filehandles (IO) as one of them I think we should include subroutines (CODE) as one of them. Particularly as perl is a functional language with first class closures available. Demerphq 22:51, 6 December 2006 (UTC)

I added subroutines to the data type and removed references to "lists" when discussing variables. Lists are an abstract concept in perl and not a variable type. Demerphq 23:00, 6 December 2006 (UTC)

unfriendly takeover

i, the maintainer of the german perl article, have plans in mind to replace this article complete with a translation of my work because i think is much better structured and its more readable, but i dont want only destray your work. i think it would help if someone would agree here or help, since me english could heve some lesser flaws. no fear it wount happen next week. (but better i prepare you now huahahaha..)Lichtkind 20:55, 2 April 2007 (UTC)

Perhaps you have some specific comments about the current article? I'm not against an overhaul, but I'd have to know what it was that we were addressing. If it's purely stylistic concerns, then I see no reason to favor your aesthetic over anyone else's. However, if there are significant, tangible improvements to be had, then let us know.

That said, understand that your comments make it clear that there are editorial differences between the German Wikipedia and this one. Here, we don't tend to have a "maintainer" for articles. In fact WP:OWN exists because we've had a number of editors become over-protective of their own edits. Whatever Perl's article becomes, it will almost certainly have to change as a result of consensus, at least here on the English Wikipedia. -Harmil 21:12, 2 April 2007 (UTC)

no we dont have maintainer either, thats an international ground principle of the wp. i am the maintainer i the sense that i did most content work, and more single edits than any other in past 15 month. i have just figured out that somebody have to make up an plan that the article will be consistent. which leeds me to the answer of next question below. i had many nonetechnical revierwers, and for most of them it was fun to read because we have high info density and an quit entertaining flow thanks to lots of people who helped. most infos are in place you would expect from the topics. the topics itself follow a scheme. and so on. i also did shamelessly steal most of the thing that were better here. But to sum up in short no its not only the form its also more roundet up info-wise. thanks. Lichtkind 11:04, 3 April 2007 (UTC)

I too would like to know in what ways specifically is the German version 'much better'. peterl 21:59, 2 April 2007 (UTC)

see above.Lichtkind 11:16, 3 April 2007 (UTC)

Review of German Perl

On the de.wikipedia.org, I've been looking over the Perl article to see what improvements might be available. I don't read German, but being a native English speaker and this being a technical article about a primarily English-language subject, enough of the words and sentence structure is similar that I can get a sense of the article. Here are some things I noticed:

• The history on de clearly outlines the progression of versions of Perl and their highlights. This is something the en version does not do.
• There are three pictures of people... something I'm not SURE is required, and one of them is that horribly doctored picture of Audrey Tang (I like Audrey, but her picture on Wikipedia is horrible; has lens flare added; and is cropped in an oval).
• The Perl 6 info is covered in the history section right after Perl 5, rather than in a later "Future" section.
• The "Merkmale" section is structured in a way which is unique to Perl (that is, it is about Perl's point of view, and so that structure would not make sense for another language's article). For example, the "Mehrere Wege" sub-section is translated by Google Translation as "Several Ways" (as in, "There is more than one way to do it")
• There are a grand total of 6 citations... that's a deal-breaker on en.
• The "Kritik" is argumentative, and presents a strong Perl POV, refuting brief points with lengthy counter-arguments.

Overall, I'm not sure that I see that there's a huge value in adopting the German version, even given significant translation effort. I do think that there are useful lessons to be learned, and I'd invite anyone who speaks both languages to peruse both articles and merge improvements in either direction. -Harmil 23:34, 2 April 2007 (UTC)

I feel the best thing to do would be for Lichtkind to create a subpage here and place his/her translated article into it for the community to take a look at and discuss, rather than going so far as to replace the actual article. — Hex (❝?!❞) 23:36, 2 April 2007 (UTC)

Thanks, thats the discussion i wanted, shure the de article still isn't perfekt. but yes its a good style to sum up argumentnts in Kritik but your right i could write it a bit more neutral but see it please also as a counterreaction of a lot misinformed anti perl POV which is around. not today but i planned to translate it section wise. because you also said that the history section would be more useful for you than other parts. as far es i understand english history is always something in the past. geschichte has in german the conotation of a sory (his-story) which i thought fit perl6 perfectly in. germans always tend to more clear structures :). and yes i try to organize anotzer picture of audrey since i know her a bit. of course picts are not required but its a nicer read with pics and my goal is to make the article exellent and in de that is nearly impossible without pictures. and "Merkmale" means characteristics which can applied to any language only the structure of the first subparagraph was indeed made on perl design. its only 5 quotes now :). will see you. Lichtkind 11:10, 3 April 2007 (UTC)

Have you read the version here, in depth? I've read almost all of the German version using Google Translation, and I have to say, the two are about the same. The de version covers things in a different order, and stresses some things that the en version does not. In turn the en version stresses some things that the de version does not. One thing that I think the de version does is get into the language structure a bit more clearly. Some of that could be merged into this article. I've always disliked the fact that we lead "Language structure" with a hello-world example. That's fine for an instruction manual like The C Programming Language or Programming Perl, but doesn't really work for an encyclopedia. As for the section name, "History", I don't see any problem with moving the "Future" section on "en" into the "History" section and re-naming it "Perl 6". It's not, after all, about the future. It's about the last 6 years of effort that has gone into Perl 6.

As for the POV issue, I think de and en just have different ways of dealing with POV. What seems like a very one-sided POVish section here, might be acceptable there. I'm just saying that it's a clear example of how merging good elements from either de or en to the other makes sense, rather than whole-cloth replacing one with the other. -Harmil 13:15, 3 April 2007 (UTC)

like i said: i did many refinements, based on en version and will keep doing that because there are many pearls of expert level info here. on the other side i there are a lot of holes (missing infos that i consider more importan than some of the infos here) and the topic jumps sometimes from here to there inside a paragraph. i definitly miss there some consistency. The intro is made upon totally different standarts than i used to accept as good, so it makes a little make scratch my head. And it makes no sense to me to call a section future when it describes actions that where done in the past. :)

but the en Version is also in better shape than in times i first had the idea of translation and i never wanted here to patronize just help the article. I think the next days i will translate some parts of the de article and store it in my personal namespace and post link here.Lichtkind 22:43, 3 April 2007 (UTC)

Probably the best thing to do is to copy the entire existing, en article text to Talk:Perl/Proposed replacement from German (or a user sub-page, as you suggest... either way) and then modify it. That way, we can easily see what, exactly, you changed and evaluate the individual changes in order to have an informed discussion. -Harmil 18:24, 5 April 2007 (UTC)

Common to replace was only my first intend 1,5 years ago. i think best starting point is the intro. as the first contact with the reader it should provide a quick overview over most important aspects of perl. To improve that is the fastest and most visible way to improve the article. therefore i will translate first our version of it and we could change it that it will fit into this text. This first column requires always the highest standarts in info density and understandability, for people who dont want read the whole text or foreign to that subject. because this high standart it also stresses more the different views about how to write the article or different horizont of knowledge and we could get faster in sync, what would easy the work for the rest of article. hough. Lichtkind 11:35, 6 April 2007 (UTC)

German Review

So whe no more comments coming i will start this, i also started an review proces to better the style of the german. we have some very strict rules here what belongs where, which i mostly agree with. so maybe this article can profit from this action too. cu. Lichtkind 12:22, 5 April 2007 (UTC)

File handle type and other ramblings

The section on types is misleading, FOO in print FOO "bar" is not a file handle but a bareword that happens to resolve to a handle, it's actually short for print {*{__PACKAGE__ . "::FOO"}{IO}} "bar". Just like:

 @a = 1 .. 2; push a, 3; # 

Is actually short for:

 @a = 1 .. 2; push @{*{"main::a"}{ARRAY}}, 3;

Actually on the whole I feel that the explanation of Perl's data types would be much better if it started by explaining globs somewhat like Advanced Perl Programming's Introspection chapter does. It would then explain how package variables map to globs and later lexical variables (lexicals are really just scoped pseudo-globs) and magic types.

Anyway I was too lazy to change this myself, feel free to ignore this:)

-Ævar Arnfjörð Bjarmason 22:20, 23 April 2007 (UTC)

I disagree. For an introduction, what you have given is way too complicated. It would be relevant in the Advanced Perl part of the wikibooks article. peterl 07:45, 25 April 2007 (UTC)

It's complex because I'm explaining how barewords work, but storing file handles in normal variables (i.e. non-globs) has been supported for ages now. I guess my point is really that the article shouldn't be bothering with barewords at all. --Ævar Arnfjörð Bjarmason 00:44, 26 April 2007 (UTC)

Within the context of a Wikipedia article, I think it's fair to call "FOO" a filehandle, or at most "a bareword which is used to reference a filehandle." I'm not sure that there's any value in fully exploring the implemtation. Wikipedia is not a reference manual, and we do not have to explain the implementation to a level of detail that would allow arbitrary use of the language. -Harmil 15:24, 18 May 2007 (UTC)

Cpan status

I dispute all of the latest changes made by user:Aristotle Pagaltzis in there entirety. Cpan is more aptly described as an "online repository", than an FTP archive, largely because FTP has little to do with CPAN, and because Repository is already a wiki article to which CPAN is an example of.

In other news "created and improved upon by its 5,000 plus authors" is fundamentally different than "by over 5,000 authors," which is even deceptive. No conclusive data says CPAN has 5000 authors, only that Perl-pause has 5000+ members (to which every CPAN author must be.) This is a fallacy of equivocation, because all CPAN authors are Pause members, does not mean all Pause members are CPAN authors. I might revert the change. --EvanCarroll 09:37, 2 June 2007 (UTC)

The number of "current CPAN maintainers" (distinct PAUSE accounts that uploaded the most recent revision of each of the 17,000-18,000 packages) is slightly over 4,000 (4031 as I write this). This excludes people that have had modules taken over, died, etc. It also excludes multi-author distributions (such as BioPerl) where dozens of people work on the package and need PAUSE accounts for things like bug trackers etc. But as a point of reference, 4,000 is a reasonably accurate number to use -- Adam Kennedy (CPAN Admin) 9 Jul 2009 —Preceding unsigned comment added by 203.23.60.6 (talk) 01:39, 9 July 2009 (UTC)

I have two questions for Aristotle Pagaltzis. First, what makes CPAN an FTP archive "specifically"? Second, what is the benefit to readers of this article to be told that CPAN files are available via FTP? It makes about as much sense to me as reporting what filesystem their servers use. --Yath 18:25, 3 June 2007 (UTC)

I'm not saying that the protocol itself is important; that's indeed irrelevant. However, the structure (with the author directories under two-letter-prefix directories, the compressed lists of contents, etc.) is entirely dictated by its conception as an FTP archive. This affects anyone who looks at the CPAN in any other way than by using search.cpan.org. While most people equate CPAN with search.cpan.org, that came much later than the archive and isn't the only interface, or even the most important one (just an important one).

I don't see the "fundamental" difference between "created and improved upon by its 5,000 plus authors" and "by over 5,000 authors" because as far as I can see, the former suffers from the same fallacy of equivocation as the latter. It's just much more clumsily worded. But yeah, the fact that not all PAUSE IDs are CPAN authors is a very good point. I wouldn't object to wording that actually conveyed this. —Aristotle 07:49, 4 July 2007 (UTC)

Also, the article seems quite inconsistent with regard to CPAN - is it a proper noun ("CPAN") or not ("The CPAN"). I vote the former. LeoNerd (talk) 20:51, 15 March 2008 (UTC)

Post-modern

I've removed the reference to Perl being 'post-modern'. The post-modern page makes no reference to computers or programming. I don't see what benefit there is in calling Perl post-modern. If we call Perl post-modern, then so should virtually all languages since 1990. Is there any reference to Perl being called post-modern in any other text? peterl 19:35, 4 July 2007 (UTC)

I think it would make more sense to clarify that Larry Wall, author of Perl and linguist wrote an extensive essay claiming that Perl was, in fact, a postmodern language. It's not really up to us to say he was right or wrong, but rather to include the fact that that essay is part of Perl's history.

• Wall, Larry (1999-03-03). "Perl, the first postmodern computer language". O'Reilly Perl.com. {{cite web}}: Check date values in: |date= (help), from a talk at Linux World. Also on Larry Wall's Web site at http://www.wall.org/~larry/pm.html

Hope that helps. -Harmil 17:11, 12 November 2007 (UTC)

GA review needed

This article received its Good Article rating on 14 December 2005 from an editor who hearkened back to a kinder, gentler era when it was not outside of norms to just simply plonk down a Good Article tag for no other reason than WP:ILIKEIT. Alas, the standards for retaining this pretty green trinket have tightened over the year; in the present regime, someone unassociated with writing this article (a reviewer) should examine the article with respect to the good article criteria and, on the various standards cited, expresses up, down, or neutral sentiments, plus an aggregate sentiment, upon which retaining the pretty little trinket relies. By posting this remark here, I'm not suggesting that the article has gone bad or presently fails the criteria, but I am noting the absence of a review that is a hallmark of the present process, and, in the fullness of time, a review should be performed on this article. With the absence of a review, this article is a delisting candidate. Note that, for an editor to delist this article, the due-diligence of a good article review is required so that specific reasons for delisting can be given by the dislisting editor; or, for that matter, offering cogent reasons why the Good Article mark should remain. Anything short of a fair review is unfair to editors who contribute to this article regularly and in good faith. Drop any questions about this on my talk page. Take care — Gosgood 13:20, 28 July 2007 (UTC)

Where would a GA review go? I followed the link you gave but saw no list to add a link to a Perl review. --Ancheta Wis 10:57, 23 August 2007 (UTC)

Full disclosure: this is a good article, folks. I was pleased to see how it has improved. --Ancheta Wis 10:59, 23 August 2007 (UTC)

The GA review would go here, on this talk page, after someone actually reviews the article. Sad to say, Perl was reviewed some time ago, when reviewers were not obliged the to publish any aspect of their review at all, or state what standards they may have applied. As a consequence, the good article review that characterize many articles bearing the green marque was simply never written for this article, and the notice calls attention to that. However, to be aligned with current standards, a review should be done on this article at some juncture. When, or by whom, I have no idea. We are all volunteers, and we set our own timetables and priorities. Further remarks on your talk page. Take care. Gosgood 00:04, 31 August 2007 (UTC)

Lede expansion

In the interests of expanding the lead section I propose to add a third paragraph such as:

• Mark Jason Dominus, in Higher Order Perl (2005) notes that Perl's facilities actually allow a style of programming which is more akin to Lisp, than say, Java or C#. Dominus, upon reading Peter Norvig's Paradigms of AI Programming (1991), found a list of eight properties which made Lisp unique. Upon reviewing the list, Dominus found that Perl satisfies six of these features, while C satisfied none of the listed features. Thus instead of programming in C using Perl syntax (which is a natural tendency for former C programmers), it is possible to program in Lisp instead, which leads to Dominus' examples of higher order functions which can be implemented in Perl.

If no objection is raised, I propose adding this as the third paragraph of the lead. --Ancheta Wis (talk) 03:35, 10 January 2008 (UTC)

The lead should not contain arguments or references which are not advanced in the article body. This belongs in the body. It could be handily summarised by tacking an additional sentence onto the end of the current lead's second paragraph.

What the lead really needs is a summary paragraph dealing with perl's widespread use in a variety of fields. Chris Cunningham (talk) 12:27, 10 January 2008 (UTC)

I have edited the lead section and expanded it. If anyone finds any errors, please correct. Shekure (talk) 12:53, 23 July 2008 (UTC)

Good work. The new prose is a little advertish in places ("the ideal language for"?) but it's a big improvement. Chris Cunningham (not at work) - talk 14:00, 23 July 2008 (UTC)

Please add simplified explanation at start of article

I was only able to understand the first three words of this Wikipedia article. Could someone add a sentence that explains what Perl is/does that non professional computer users can understand? —Preceding unsigned comment added by Drstk (talk • contribs) 12:20, 16 March 2008 (UTC)

Syntax highlighting is broken; should be removed?

The syntax highlighting in the examples is using some kind of incredibly poor parser that doesn't understand basic Perl syntax, causing it to be misleading: for example, when illustrating $#, it formats everything after the # as a comment!

If whatever's being used here can't be fixed, I think the highlighting should be removed, because it is making the code harder to read, not easier. (Posting a comment rather than being bold and doing it myself because I'd probably just be taken for a vandal and reverted immediately if I did that...) 78.105.167.145 (talk) 22:17, 6 June 2008 (UTC)

The highlighting could probably be removed for just that specific example, but it seems to be working reasonably for the other examples. On the other hand, one of the goals of that example is to specifically show that perl syntax parsing can be difficult, so the syntax highlighting error might actually be illustrative of the problem. -- Bovineone (talk) 16:35, 17 June 2008 (UTC)

I wonder… does anyone know how the syntax highlighting can be fixed? How can one add syntax highlighting support for new languages? Ghettoblaster (talk) 17:38, 17 June 2008 (UTC)

See this about the technical side: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

I don't think that it should be removed. vi's highlighting isn't perfect either. --Amir E. Aharoni (talk) 20:42, 17 June 2008 (UTC)

[vi] does not have highlighting. Do you mean vim? In any case if an example in the page is breaking the syntax highlighting in the page, the page should include a note to say that. I've edited the page to include that. --Elijah (talk) 23:22, 17 June 2008 (UTC)

Here's another example of incorrect highlighting. I noticed it before I read this discussion and wondered why no one had fixed it:

$album = q(It's David Bowie's "Heroes");

Everything between the parentheses should be colored as a string literal, or not colored at all. One use of an encyclopedia is to teach those who don't already know the material, and misleading highlighting will only serve to further confuse those who are first exposed to this unusual quoting syntax.

I've read that only perl (the interpreter) can parse Perl (the language) so syntax highlighters that make the attempt are bound to fail. 72.208.56.42 (talk) 03:37, 24 August 2008 (UTC)

Semi-protected for one month.

I have applied semi-protection to this article for a period expiring on November 5, 2008. This is because point of view editorializing is being repeatedly inserted into the article by anonymous users, following my temporary blocking of User:Getly for doing the same and violating the three-revert rule. The users are all appearing within the 12.72.157.* range and I do not want to apply a range block that may inconvenience innocent users. — Hex (❝?!❞) 18:06, 5 October 2008 (UTC)

NASA 1987

in the beginning section there is:

"Perl was originally developed by Larry Wall, a linguist working as a systems administrator for NASA, in 1987"

after the content:

"Larry Wall began work on Perl in 1987, while working as a programmer at Unisys,[6] and released version 1.0 to the comp.sources.misc newsgroup on December 18, 1987."

If you read just the first one you will get impression that the Perl was "born" in NASA but that's not truth, or?

Jozef.kutej (talk) 13:48, 10 November 2008 (UTC)

Perl parsing is Turing-complete

On the subject of Perl parsing, I've published (in the Perl Review) a three part series containing rigorous proofs of Adam Kennedy's conjecture. Parts of the paragraph on this topic are wrong or misleading. The Perl Review articles are now available online.

I'm going make appropriate changes. I'm aware of WP:COS, and will try to stay within its confines.

--Jeffreykegler (talk) 18:46, 4 January 2009 (UTC)

C++-influence

Hello,

the infobox says perl was influenced by c++. Is there a reference for this? Curtis Newton (talk) 19:17, 15 January 2009 (UTC)

C(though almost all through AWK), sh, sed and AWK are pretty obvious, but those mentioned in the infobox are a little dubious: Smalltalk 80(maybe),C++,LISP,Pascal(!?). 84.222.239.67 (talk) 19:40, 5 February 2009 (UTC)

You can see the relevant section of Larry Wall's original Perl 1 manpage at [the archive]. Pascal is clearly mentioned there, so I've re-added it to the main page. --Randal L. Schwartz (talk) 23:48, 28 October 2009 (UTC)

An ambiguous "it"

Ambiguous pronouns can be acceptable: for example, in

The dog sniffed the plant, until it noticed a cat.

the reader can be expected to figure out that, of the two possible referents for "it", it was the dog that noticed the cat, not the plant. The reader does this using his semantic knowledge.

The discussion describing Perl run/compile phase vs. time contains difficult material about a counter-intuitive, unusual and often misunderstood and mistated aspect of Perl. The reader cannot be relied on to find ambiguous pronoun referents quickly and easily using semantic knowledge. Pronoun referents have to be completely unambiguous. Where that's not practical, we have to reword the sentence to eliminate the pronoun.

My original was

Perl is in compile time at most points during the compile phase, but can also be in compile time during the run phase.

Here the two coordinated predicates must have the same subject, so there is no ambiguity. However, the reader is required to see that the "but" coordinates two predicates, and that perhaps might be difficult.

Another editor's intermediate revision was

Perl is in compile time at most points during the compile phase, but it can also be in compile time during the run phase.

The "it" can refer to any of three things, with "Perl" and "the compile phase" being the most likely. Semantic knowledge will tell you that "Perl" must be the referent, but we can't safely assume that a reader can easily and accurately supply that degree of semantic knowledge.

My compromise is

Perl is in compile time at most points during the compile phase, but Perl can also be in compile time during the run phase.

--Jeffreykegler (talk) 18:22, 19 January 2009 (UTC)

Requested move

The following is a closed discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was not moved. Closed per WP:SNOW. 199.125.109.88 (talk) 18:10, 5 June 2009 (UTC)

Perl → Perl (programming language) — Note that the target name is already a redirect to this article. And after that, i think that Perl (disambiguation) should be moved/renamed to "Perl". A bot would have to be set up to update the thousands of links to this article. --Jerome Potts (talk) 08:26, 31 May 2009 (UTC)

• Oppose. The programming language is the primary topic for the search term "Perl", and thus should be allowed to retain the plain title. Dekimasuよ! 09:52, 31 May 2009 (UTC)
• Oppose. As soon as I had checked that WP:PRIMARYTOPIC still looked as I remembered it, and that Perl (disambiguation) didn't contain anything I'd missed. I may be biased, but even so, this seems a clear case of a primary topic. — the Sidhekin (talk) 11:02, 31 May 2009 (UTC)
• Oppose. Pretty clear primary topic, no evidence provided that any other topic is even close. older ≠ wiser 12:05, 31 May 2009 (UTC)
• Oppose. Clear primary topic. The only contender is Perl, Germany (the others listed on the dab page aren't probably referred to as just "Perl"), and the page view stats are rather convincing: 173 for Perl, Germany, 59249 for Perl. Any questions? Jafeluv (talk) 20:27, 31 May 2009 (UTC)
• Strongly oppose. Perl is a clear example of a thing which picked a genuinely unique name so that it can identified by its name alone, like Flickr, JRuby or Wikipedia. There is also no significant disambiguation-related need to distinguish Perl. -- Gaurav (talk) 05:11, 1 June 2009 (UTC)
• Oppose While in general I agree that the base level should be the disambiguation page, here, even as a non-programmer, I agree that Perl, the programming language, is far and away the primary topic, and that all else is well handled by the dab hatnote to Perl (disambiguation). --Bejnar (talk) 06:12, 1 June 2009 (UTC)
• Oppose. There seems no suggestion that the programming language isn't the primary usage, even by the nominator. Andrewa (talk) 15:11, 3 June 2009 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Version numbering downwards?

The article says in History: On December 18, 2007, [...] Perl 5.10.0 was released. [...] In December 2008, Perl 5.8.9 was released.. Do I understand that there was a backward-numbering, 5.10.0 --> 5.8.9? Was the earlier version depreciated? -DePiep (talk) 07:08, 9 October 2009 (UTC)

The article lumps all of the Perl 5 releases together, when in reality there have been several significant releases: the initial 5 release, 5.6, 5.8, and 5.10. The odd numbers have been reserved for development, so e.g. 5.9 was the precursor to 5.10. Also note that 5.12 is being worked on (presumably in a 5.11 branch of the code). The article should probably be expanded to explain this, as major new features have been added along the way, making Perl 5.005_03 very different from 5.10. Right now the 5.8 branch is probably the most popular, with 5.10 slowly being adopted. For example commercial Red Hat 5 has 5.8.8 in it and if the Fedora releases are any indication, Red Hat 6 will likely have 5.10. Similarly, Solaris 8 shipped with 5.005_03, Solaris 9 with 5.6.x, and Solaris 10 with 5.8.x (not sure what OpenSolaris will ship with). So, in answer to your question, the 5.8 and 5.10 branches are both being actively maintained. Argel1200 (talk) 22:41, 23 October 2009 (UTC)

I should add that 5.005_03 and 5.6.x should probably be considered deprecated as there is very little (if any) work being done on these releases; The Perl community has moved on to the 5.8 and 5.10 branches of the code. Argel1200 (talk) 22:46, 23 October 2009 (UTC)

Very clear now. I wouldn't mind you putting this in the article, because it describes the numbering, clearly and with the multiple used GA versions. For clearity imo, I suggest the text could stick to sequentional mentioning of the numbers. Again, here, to me it is crisp. -DePiep (talk) 21:08, 1 November 2009 (UTC)

The Iron Man Contest

The section on Community now has a new entry about an aggregation site at http://ironman.enlightenedperl.org/ . It makes the bold statement that "This is the main source of news for modern Perl". I hadn't heard of it before - can anyone apart from the original author support that statement? 'The main source' seems quite strong. I'm tempted to remove it, but wanted to get some other's feedback first. Thanks. peterl (talk) 03:42, 22 October 2009 (UTC)

As best I can tell, what the article states as fact is actually the goal of the Ironman challenge. The jury is still out on whether it has or is achieving this. I personally get most of my Perl news from PerlMonks. At the bare minimum it should be flagged citation needed, or, as you suggest, removed. Right now it looks more like an attempt to help promote the IronMan challenge, but that's not what Wikipedia is for. Or as another alternative the IronMan Challenge and it's stated goal(s) could be mentioned without the uncited bold claim.. Argel1200 (talk) 23:03, 23 October 2009 (UTC)

Yes, talk to me, I introduced this modification to the Perl wikipedia page. I can prove and give numerous sources that the Modern Perl movement(which every serious Perl programmer should know about) and basically almost all Perl news are tracked by this rss aggregator. A lot of people read it. Perlmonks is nice, I use it also, but Iron Man is about what happens now in the Perl community and it brings a lot of news. I think you classifying it as advertising isn't based on anything , personally I am pretty sure I made a very very good addition to the Perl wikipedia page, I'm sure if you would pay close attention to what happens in the Perl community you too would agree that Iron Man is something that everyone who's interested in Perl should know about. Stefan.petrea (talk) 21:52, 26 October 2009 (UTC)

Hi Stefan. Thanks for your contribution. Can you please give us some links/information on "the Modern Perl movement"? When you say 'A lot of people read it' - that needs support - how many people read it? How many compared with other Perl sites like Perl monks or perl.com? Phrases like 'almost all' needs clarification and support. Remember the issue is not whether the Iron Man Contest is something that people 'should' know about, but whether it is notable in the Perl community.

How is it more now than other Perl websites?

I have removed the unsupported statement 'This is the main source of news for modern Perl.', and reordered the sections. If you want to add it back in, get actual facts and support from the talk page first.

I am still waiting for other contributors to give feedback, and am still considering removing it altogether.

Please also be careful to refrain from personal attacks or suggestions that other editors are not as 'serious' as you.

peterl (talk)

Hi Peter. In order to shed some light on this, here's a map of the Perl community from July 2009. To make a comparison, http://ironman.enlightenedperl.org/ is almost as big as http://perlmonks.org and take into consideration that in the meantime a lot more content has been added. On Perlmonks there is a post that discusses Perl Ironman. And this also explains what Ironman is. About the Modern Perl movement, there is an entire blog about it, and you'll get plenty of Google results if you search for it. So, as you can see, this is not made up, this is not advertising, it's a true part of the Perl Community, so its place is in the article. Let me know if you need more links/information. Stefan.petrea (talk) 00:19, 27 October 2009 (UTC)

Perhaps there's a case to make that it's an aggregation sites of many contemporary Perl authors. But superlatives can sound a bit like advocacy... Mugwumpjism (talk) 00:48, 27 October 2009 (UTC)

I'm still not convinced IronMan should be in here. Of the links you provided:

1) here's a map of the Perl community from July 2009 has IronMan, but it's much smaller than other Perl sites like perlfoundation.org and perlbuzz.com

2) The fact that there is a post that discusses Perl Ironman means virtually nothing. A post? You mean just one? Out of how many gazillion posts on perlmonks? And the post actually discusses the competetion, not really IronMan, and then most of the post is about effective blogging.

3) That there is an entire blog about it doesn't count. Read wikipedia guidelines on the use of blogs.

4) How come there's no Modern Perl entry in wikipedia?

So to summarize, my argument is that Iron Man appears to be a valid web site about a movement in Perl. But I don't think it's anything like a core part of Perl. Maybe - maybe - it belongs in external links.

Anyone else in the community got anything to add?

peterl (talk)

right. Stefan.petrea (talk) 12:09, 27 October 2009 (UTC)

I know Google searches aren't an ultimate authority, but when I google for "Perl", I get Perlmonks on the first page, the Perl Foundation on the third page, and the "enlightened perl organization" doesn't show up until page 9. Hardly the "center" of the Perl community. And if it's any data point, I hadn't heard about it until this talk thread. --Randal L. Schwartz (talk) 20:29, 30 October 2009 (UTC)

Yeah, ok Randal, here's some more proof it exists. Stefan.petrea (talk) 00:29, 31 October 2009 (UTC)

I'm not denying its existance. I'm merely trying to understand its significance. It seems to be a few people who thought the Perl Foundation wasn't doing enough, and decided to take some of that into their own hands. I would have rather they worked with the foundation, instead of venturing out as a separate organization with more bureaucracy. Oh well. But anyway, minor player in a big game. --Randal L. Schwartz (talk) 03:18, 31 October 2009 (UTC)

Peterl please explain why you keep moving the modifications I've made and deleting parts of them ? Thanks Stefan.petrea (talk) 22:58, 1 November 2009 (UTC)

Hi Stefan. As per the above discussion, and input from one of the most notable Perl people around (Randal Schwartz), the Iron man contest does not appear to be as significant as you are making out or as the article warrants. I had not heard of it, and neither had Randal. That is not a definitive reason, but it contributes to it.

I have not 'kept on moving and deleting' the entry, but have refined it as other editors have given input. Note I am not saying the Iron man is not real, or that it is not useful. There are many, many websites devoted to Perl that have no mention in this article. To give Iron Man undue weight would be unfair to them. (Note I am not advocating that every website that is useful or relevant should be added here. Wikipedia is an encyclopedia, not a training manual and not an Open Directory. peterl (talk) 22:14, 2 November 2009 (UTC)

The Perl on IRC section

Anticipating the deletion of the IRC section I will add that the IRC channels mentioned can be found in a book "The Definitive Guide to Catalyst" and some other books as well. Stefan.petrea (talk) 00:59, 27 October 2009 (UTC)

History Section

The old history section was just awful - it jumped from 1994 to 2007 to 2009. A whole lot of Perl happened in between. I took what I could from the perldelta's, as well as the perlhist docs on perldoc.perl.org, and tried to summarize it as best I could. If there's anything I missed or if I'm incorrect anywhere, feel free to fix it. --Pepkaro (talk) 09:02, 17 November 2009 (UTC)

Glue Language

I have deleted the part of the article that says it's a glue language and it's good for sysadmins. This is not true and there are plenty of examples in this direction. A lot of people doing science use Perl for their work in bioinformatics and some other places as well. It's not a glue language. —Preceding unsigned comment added by Stefan.petrea (talk • contribs) 08:34, 26 November 2009 (UTC)

Stuff removed from Boolean data type article

The following section was removed from the article Boolean data type:
begin removed text

---

---

In the Perl programming language, there is no distinction between numbers, strings, and other non-aggregate data types. (They are all called "scalar".) Aggregate types without any elements, empty strings, numbers which equal a value of 0, the strings "" and "0", and undefined variables evaluate to "false" when used in a Boolean context. All other values (including strings such as 0.0 and 0E0 which are "zero but true") evaluate to "true".

Elements of aggregates may also be tested against "existence" or "non-existence"[2], and all variables may be evaluated as either "defined" or "undefined".[3] (An element of a hash or array that has been assigned the value undef exists but is undefined.) In Perl this distinction is important when evaluating scalars in a Boolean manner to prevent "false falses" where one of the above values should be considered "true".

There are no built-in true or false constants in Perl 5, however the values do exist internally in Perl6.

1 is traditionally used for true, and constructs such as ... while 1 are special-cased to avoid advisory warnings. Internally, recent versions of Perl 5 have a variety of predefined "yes" and "no" values, so the recommended way to provide a false value has recently shifted from undef to !1 .

---

---

end removed text
Is there a place for this text in the Perl-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:55, 30 December 2009 (UTC)

Data types

ThePilgrim (talk) 15:08, 15 October 2010 (UTC) The preamble on this section mentions hashes, the table has Associative array. one or other needs to be used consistently throughout the entry.

Did, thanks. —Mark Dominus (talk) 16:00, 15 October 2010 (UTC)

quote when quoting rather than cite

Shouldn't

The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal).[32]

which is found in the second paragraph of the Overview section say something like

According to the man page, "[t]he language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal)."

possibly citing that and including a link to an online manual page? But, as is, it looks like it might be original writing or paraphrase when it's a quote. --74.162.148.157 (talk) 20:30, 2 December 2010 (UTC)

Split language structure

I'd like to bring this article back to GA material. One of the comments on the 2009 reassessment was that "The Language structure section contains far too much detail and is written like a programming manual". I think the section should be split into Perl language structure, or possibly Perl syntax and semantics to follow the Python model. The section here could then be condensed into a more theoretical description of functional and object-oriented styles, and the use of regular expressions. (I'm taking the lead here again from the corresponding Python section, which has a very good summary of the language.) Feezo (Talk) 07:16, 2 January 2011 (UTC)

I've gone ahead and split it into Perl language structure. Feezo (Talk) 06:54, 8 January 2011 (UTC)

Thank you for doing this. It's been something that's on my list once I had the tuits. I wholeheartedly approve. Pepkaro (talk) 22:21, 22 February 2011 (UTC)

Pastimes

When I Google for "perl pastimes", out of the first 10 results, 5 are this article, 3 are a book by Adam Perl about non-Perl pastimes, one is a list of books and categories on Amazon.com, and a single result is "Programming Pastimes" which includes code in Perl (and I suspect that "pastimes" is being used generically, not to refer to some specific aspect of programming/Perl culture). The book, according to Amazon, contains 3 instances of "pastime", none of which refer to a specific cultural phenomenon. So in the absence of any evidence whatsoever I'm deleting the claim that "Perl's pastimes have become a defining element of the Perl community.". --holizz (talk) 17:28, 18 February 2011 (UTC)

I am having trouble following your reasoning here. Did you look at the cited source that you deleted? If your objection is only to the word "pastimes", why did you delete the entire section instead of retitling it with a better word? —Mark Dominus (talk) 18:38, 18 February 2011 (UTC)

It's great to see you here Mr. Dominus — your writings have been very helpful to me in my various Perl endeavors. I especially enjoyed Seven Useful Uses of local and You Can't Get There From Here. If you have any more comments on this article, I'd love to hear them. Feezo (Talk) 20:39, 23 February 2011 (UTC)

"Things that are different should look different"

Do my eyes deceive me? Did someone actually write, "Things that are different should look different" in reference to Perl??

Ha ha, that's a good one. I think that was a joke. Or, if not, then see if you can tell what this prints (without running it):

 for ($x=0; $x<10; $x++) {
    $x[$x] = $x+1;
    $x{$x[$x]} = $x;
 }
 print $x{5}; 

NCdave (talk) 10:31, 12 March 2011 (UTC)

Flippancy is not productive. The phrase is attributed to Larry Wall, and hence merits inclusion. Feezo (Talk) 03:45, 13 March 2011 (UTC)

IRC

The IRC section really could be better. Right now it's just a table of networks and channels, and doesn't explain further. Problem is, I very much doubt we can find reliable sources for even a third of them. We might have to pull that whole section, or just shorten it into a ref to http://www.irc.perl.org, unless someone has other ideas? Feezo (send a signal | watch the sky) 11:35, 16 May 2011 (UTC)

Open source

I was surprised to see Perl omitted from a list of open source software. It goes without saying that you have to understand Perl, etc. to even read its source code, but why is open source mentioned only tangentially in the article? If this is an unimportant detail for the article, it still would be pertinent to the Open source article. If you reply on this page, then I can edit the open source page appropriately. --Ancheta Wis (talk) 11:52, 11 September 2011 (UTC)

That is really strange. It's certainly open source...it's under two open source licenses (GNU and Artistic!) :) Please do add it. Pepkaro (talk) 17:22, 29 September 2011 (UTC)

"Examples" Section removed

Jcrypto, I've removed your Examples section from the main article. I think it has some good content, but almost all of that information already exists on the Perl language structure page. That page was broken out a few months ago because it just cluttered up the article. Almost all programming language articles on Wikipedia (at least, those of fairly notable languages like C or Python) only have very minor amounts of code or examples in them, relegating the specifics to a separate article. Some places where I think your suggestions could be added to the Perl language structure articles:

• Expand the OO section (as currently noted) with more information about low level operations with it (e.g., perltoot)
• Comparison operators (only talked about briefly in that article, not as extensively as yours had it)

But generally, remember that Wikipedia is not a reference manual. We don't need to go into complete details about how every little feature works. Code examples to illustrate points are good, but code by itself with little narrative is just cluttered.

IMHO, ofcourse.  :)

Pepkaro (talk) 17:33, 29 September 2011 (UTC)

Further, see the Talk:Perl#Split_language_structure section, above, which discusses more of the rationale behind keeping code out of the document. Pepkaro (talk) 17:35, 29 September 2011 (UTC)

I added a link to the language structure article in the hatnote a while ago, although another editor removed it. I think it would make it a bit easier to find the programming details, hopefully avoiding more situations like this. Feezo (send a signal | watch the sky) 18:34, 29 September 2011 (UTC)

Perl as a CGI language and improper edit summaries

I have tried--twice--to assert that PERL is declining in popularity as a CGI language. The edits were reverted twice. I am now reinstating the statement again, and I am writing to exhort the anonymous editor NOT to behave again as he did. Namely:

• you cannot call my edits vandalism; if you don't know what vandalism is, check it on WP:vandalism. Accusing proper edits of vandalism is, ironically, vandalism.
• you are not to make personal attacks. Calling editors "ignorant" or "overzealous" is a personal attack.
• as for the facts, my source clearly shows PERL is declining as a CGI language. It went from over 50% of all sites to less than 1%. In the same time, PHP went up to 78%, and Ruby and Python to about 1%; however, all three languages were virtually non-existant a few years back
• your source, on the other hand shows that PERL jobs are up 10%. Who-ho. The same source shows PHP jobs quadrupling and Python ones going up 10 times.

This is an encyclopedia, not a football forum. If you don't like PERL is not popular anymore for a certain application, I'm sorry, but don't try to mislead the public with insulting edit summaries, unjustified reverts and misleading sourcing. Thanks. Complainer (talk) 11:24, 10 December 2011 (UTC)

Thank you for bringing attention to this matter; I have reverted the page to a pre-edit war version and protected it for a period of 3 days. As this is an admin action, I take no position on the content dispute. You are also correct to protest 70.138.242.181's edit summary; feel free to issue the appropriate NPA warning. Feezo (send a signal | watch the sky) 12:44, 10 December 2011 (UTC)

I will, but I don't think IP'ers actually read their talk page. Besides, by having my edits removed and editing blocked, he has achieved all he wanted.Complainer (talk) 18:53, 10 December 2011 (UTC)

Only in the short term. If an editor doesn't come to the talk page during a protection period, they are generally in a much weaker position by having failed to demonstrate a willingness to collaborate. Feezo (send a signal | watch the sky) 04:42, 11 December 2011 (UTC)

As Complainer implied, I am not a full-time Wikipedia editor so I am not very familiar with the correct formal procedures in this situation, so I may be at a disadvantage here. However, I will state that I am questioning the accuracy and impartiality of Complainer's edit.

• Firstly, the language is written 'Perl', not 'PERL', as a self-proclaimed expert editor should easily be able to ascertain.
• Secondly, the disputed edit stated that Perl "is now in sharp decline for this application, where it is increasingly being replaced by more user-friendly CGI languages such as PHP, Ruby and Python", yet the Editor's own citation clearly shows the Perl usage (1.0%) is higher than Ruby (0.58%) and Python (0.25%)! I agree that PHP is the dominant language at present, but clearly Ruby and Python are not relevant to this discussion.
• I also question the subjective and unsupported usage of "more user-friendly" in the quoted passage.
• I would therefore suggest the following change to the disputed edit, to make it more justifiable: "Perl usage for websites has declined in recent years, being largely replaced by PHP".
• Finally, please reinstate my edit to the 'Further Reading' section, which I presume is not under dispute. Thanks. 70.138.242.181 (talk) 16:43, 12 December 2011 (UTC)

70.138.242.181 is correct on at least two points: the name of the language is Perl, not "PERL", and casual use of terms like "user-friendly" is editorialising. The same could be said of powerful descriptive terms like "sharp decline": it would be better to let the cited numbers speak for themselves. Feezo (send a signal | watch the sky) 20:26, 12 December 2011 (UTC)

• "User friendly" is used on at more than 7000 wikipedia pages, but I concede that the correct term seems to be "usable". I'll edit accordingly. Not using anything is just bad editing, as it makes it seem like people started changing CGI scripting language with no good reason. I can find any number of sources to the effect that PHP, Perl, Python, The Language Previously Known as ASP and pretty much every modern CGI language are more usable than Perl, but this is sourcing an obvious fact (and would lose the focus by sourcing each separately).
• The term "sharp" associated to the decline seems justified to me, seen that Perl went from being the most widespread of all CGI languages (that is, from having more than 50% of the market share) to some being in about 0.9% of all websites. Again, the reader who is not familiar with Perl history must be able to tell that we are not talking about a minor swing in the numbers. In this context, "sharp decline" is certainly less editorializing than the unchallenged "widely popular" at the beginning of the article.
• A language (or anything else) can lose ground to other languages before they surpass it. In fact, if it didn't, it would never be surpassed. Perl is losing ground to a plethora of modern CGI languages (note the term "such as" in the original edit), the main ones being PHP and TLFKA ASP; I avoided mentioning the latter in order to avoid getting into the "it is not called that"/"it's two different languages"/"it's a framework, not a language" discussion, which is sterile, and I bet would pop out within minutes of bringing it up. I mentioned Ruby because it's one of the fastest growing languages (+20% in one year) and Python because, in spite of its small market share, it is used on immensely high traffic sites (google, anyone?) and might be the most widespread language in term of scripts executed.
• If my impartiality is going to be questioned, which part would I be supporting, exactly? The world is not divided into a field for Perl and one against it; if anything, it is divided into Perl mod_jahideens, PHP zendlots, Microsoft mercenaries and Others. I certainly don't belong to any of the former, and don't think "Others" qualifies as a part.

As a final consideration, Perl is not a WP:BLP; nobody should get offended if we make it clear that the technology is, at least for CGI applications, senescent without describing the shape of each wrinkle. This is a wider problem, one which keeps people reading the various Amiga-related articles from understanding that the most modern hardware available on the platform ceased production years ago, and those reading about COBOL from understanding that nobody in his right mind would adopt it in the year 2011, just to give the first examples that come to mind. These are all misleading articles, which nobody dares edit out of fear of retaliatory bitching: it's got to stop. Complainer (talk) 22:28, 13 December 2011 (UTC)

Your own reference states that Perl is used for websites more than either Ruby or Python, which not only contradicts your personal opinion, but also demonstrates that Perl is not 'senescent'. As more people are *using* Perl for websites than either Ruby or Python, it is obviously incorrect to say that these other languages are more 'usable' than Perl! You are editorializing. 70.138.242.181 (talk) 02:11, 14 December 2011 (UTC)

And you are repeating yourself, on a point I have already answered. I read your post, please take the time to read mine instead of creeping NPOV accusations in: this is not constructive. In case you are missing a piece of the puzzle, the reference counts sites that run Perl. These include and, mostly consist of, sites written a long time ago. Also, I am not saying you do, but if you have a form of emotional attachment to Perl, you should abstain from editing this article. Complainer (talk) 09:14, 14 December 2011 (UTC)

Is 'interpreted' a property of the language of of the implementation ?

Isn't the fact , that perl is interpreted ,just an implementation detail? There exist (or can exist) other implementations of the language ,which can translate it to JVM bytecode or CIL etc. Perl 6 has a language specification,so it's possible theoretically to create a perl implementation , which is compiled.(or not interpreted) 78.90.139.102 (talk) 17:01, 26 December 2011 (UTC)

The pearl of great price

Will Coleda recently deleted the part of the article that claimed (without citation) that Perl was originally named "Pearl", after the "pearl of great price" of Matthew 13.

One source for this claim is Silberman, Steve (2000). "Scripting on the Lido Deck". WIRED magazine. 8 (5). {{cite journal}}: Unknown parameter |month= ignored (help), which says, in part:

Originally, Larry wanted to name his new language Pearl, a word with positive connotations. … Larry wanted to give Perl a name that suggested that it was worth treasuring.

Furthermore, Larry is a devout Christian - he's the son of a fundamentalist Mennonite preacher from a long line of preachers. In the 13th book of Matthew, Jesus tells the parable of a merchant "seeking goodly pearls, who, when he had found one pearl of great price, went and sold all that he had, and bought it" - "it" being the Kingdom of Heaven. But there was already another programming language called Pearl.

Perhaps the writer (who spoke at length with Larry) misunderstood what Larry was getting at. —Mark Dominus (talk) 21:05, 23 February 2012 (UTC)

I reformatted the Larry Wall citation you refer to. The year has got to be > 2000 since there is a 2001 date in the article, so I inferred the year for the online article was 2004. Please feel free to fix the year if you wish. --Ancheta Wis (talk) 23:37, 23 February 2012 (UTC)

No, the year was indeed 2000. The reference to 2001 is describing something that hadn't happened yet:

> Midway through the cruise, Steven hosted a seminar at which he sketched out his plans to sail two solar-powered, wired-to-the-hilt trimarans - the Io and the Europa - in March 2001 on a 15,000-mile river tour of the United States.

—Ruakh_TALK 02:05, 24 February 2012 (UTC)

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8