Talk:Perl

From Wikipedia, the free encyclopedia

↓    Skip to table of contents    ↓

This is the talk page for discussing improvements to the Perl article.
Article policies
Archives: 1, 2, 3, 4, 5, 6
Perl is included in the 2007 Wikipedia for Schools, or is a candidate for inclusion in future versions. Please maintain high quality standards, and make an extra effort to include free images, because non-free images cannot be used on the CDs.
Good article Perl has been listed as one of the Engineering and technology good articles under the good article criteria. If you can improve it further, please do. If it no longer meets these criteria, you can delist it, or ask for a reassessment.
December 14, 2005 Good article nominee Listed
User:-Barry- is banned indefinitely from editing this article or its talk page.
This ban was mandated in the arbitration case Wikipedia:Requests for arbitration/Pudgenet and is also registered on the administrators noticeboard.

Posted by User:Tony Sidaway for the Wikipedia:Arbitration Committee.
Archive
Archives
1, 2, 3, 4, 5, 6


Contents

[edit] Criticism

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

Oh goodness me, be careful with that box if you're going to open it. (Why? Have a read through /Archive03 to see the approach you shouldn't take.) -- Earle Martin [t/c] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Problems with the Interpreter

I have downloaded the perl interpreter, placed it in the "C:\Program Flies\Perl" directory, tried to run the Hello World program, but apparently it doesn't work. Does anyone know how to run the interpreter from that directory?  ~Steptrip You raise me up 13:41, 24 March 2007 (UTC)

This is not the place for this question. See http://www.perl.com/pub/q/FAQs http://www.perl.com/pub/q/resources or http://lists.cpan.org/ peterl 07:24, 26 March 2007 (UTC)
Thanks. Maybe you would like a template similar to the one at Talk:Wikitruth that says "This is not a forum about the article's subject, it is a place to discuss how to improve the article."  ~Steptrip 14:01, 3 April 2007 (UTC)
That's really the rule for all discussion pages on Wikipedia in the main article namespace. -Harmil 15:57, 3 April 2007 (UTC)

[edit] 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)

[edit] 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. -- Earle Martin [t/c] 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)

[edit] 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)

[edit] 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)

[edit] 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)

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)

[edit] 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.
Hope that helps. -Harmil 17:11, 12 November 2007 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Perl search engine link

Is this link appropriate for the External links section: http://brainworker.ru/ ? It's an experimental search engine through Perl related websites.

[edit] 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)