Perl Language
Perl Language
Created by LarryWall in 1987, Perl was initially an efficient interpreted language optimized for processing text files. Nowadays it is a complete language, not only a ScriptingLanguage.
My first impression of Perl - which lasted over several years using it - is LarryWall must be a very fast, accurate, typist. --PhlIp
Perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding. It has various BackroNyms, including "Practical Extraction and Report Language" or "Pathologically Eclectic Rubbish Lister". However, LarryWall has said that you can expand "Perl" either way if you are so inclined, even though "Perl" is not an acronym.
Uses:
* See http://groups.google.com/groups?threadm=uk91p4zfgr.fsf%40kelly.teleport.com or http://groups.google.com/groups?selm=ukag9tdacc.fsf%40linda.teleport.com
On Wiki:
That's difficult, because Perl does everything. Going to http://www.perl.com doesn't give any obvious hints to the starter, and going to http://www.perl.org shows you some neat T-shirts you can buy. Contrast this with RubyLanguage, and especially PythonLanguage, where the home page at http://www.python.org challenges you to "learn Python in an afternoon!" But Perl isn't so hard to learn, or learn about. There just isn't a single obvious path to take for LearningPerl (which is very apt, as ThereIsMoreThanOneWayToDoIt is a key theme in perl ;) ). You can take a course in Perl from many colleges nowadays, or you can buy O'Reilly Media's "Learning Perl," one of the DefinitivePerlBooks.
''Try this description on for size: DESCRIPTION Perl is a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks. The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). http://perldoc.com/perl5.8.0/pod/perlintro.html''
Perl is the glue that binds the web together -- TimOReilly
And while it's not the only language used on the web (by far), the key word is glue. Perl is great for taking two applications, and gluing them together to get the job you want done, done. These applications might be console/stdin/stdout-, database-, web-, or IP- based (and others), but Perl makes it easy to get them to communicate and share data, making a new "uber-application".
If you're looking for advocacy, well, Perl is too comfortably established for that, but perhaps WhyLovePerl and WhyHatePerl pages will spring up.
Perl is brilliant for fairly thin tasks, tasks that involve ripping through data files and juggling text in messy ways. But it is not strong as an algorithmic language. Attempting to do coursework from Data Structures 101 in Perl would be ugly. Just look at the section on references in the Camel book and run away screaming.
You think? C like structs map easily to hashrefs. So to insert a new node in a linked list, say, you'd do something like:
my $new_node = { NEXT => $cur_node->{NEXT},
CONTENT => $content };
$cur_node->{NEXT} = $new_node;
I say this as someone who loves the power and flexibility of perl: the syntax is just heinous. The syntax sugar for eliding quotes in hashes is nice, yes, but having to use all of the sigil, the arrow, AND the curly braces just to dereference an element is just wrong on so many levels. I feel javascript got it right, making the dot and subscript operators equivalent. But not only do you not get that with perl, due to perl's nasty little context rules, you don't even get the same subscript brackets for arrays and hashes. I do use $$cur_node{NEXT} myself (which is always perfectly safe with 'use strict' on), but I am really tired of leaning on my shift key to write perl.
If people want to do 'proper' Computer science with Perl, they should check out MasteringAlgorithmsWithPerl. This isn't an ad - I'm just a humble biologist trying to spread the word.
Except of course you'd wrap all that up in an object. And implementing a linked list in perl is generally a silly thing to do since perl arrays grow and shrink as required and allow insertion/deletion of data in the middle of the array and generally do all the things you'd want a linked list for in the first place. Heaps, BTrees, Tries and all the rest of the data structure menagerie can be done in perl and have often been implemented already in CPAN (I recently grabbed a rather useful Heap implementation, making my priority queue a doddle to implement...)
Perl's basic data types (scalars, arrays and hashes) are quite advanced compared to other so-called industry-standard languages such as C++. Once you get familiar with the concepts and the notation, the benefits become visible. Just try to convert one of your recent Perl programs to C, C++ or Java to be convinced! In addition, the language has additional builtins like *map* and *grep* which enables the programmer to code simple tasks in a concise way, avoiding loops and explicit coding. Those functions come from idioms encountered in the real world and which have been incorporated in the language because programmers have a need for them. See for example the defined-or operator (//=) for which a patch is already available. -- PhilippeCausse More info at: http://www.perlmonks.org/?node_id=294171
You can do it all in Perl, but there comes a point where it simply becomes a lot of trouble. It's common, for example, to end up with lists of lists or arrays of hashes, but then you get into reference hell and you're constantly having to think about whether something needs to be referenced or dereferenced. I've been coding in Perl for years (on and off, RubyLanguage is my fave these days) and the referencing game still trips me up.
The trouble, I'd wager, is that people tend to think in terms of 'lists of lists' or 'arrays of hashes' instead of the more appropriate "lists of reference-to-a-list's" and "lists of reference-to-a-hash's". Unfortunately, most of the Perl literature helps to perpetuate this sort of confusion - at least initially. I've found that retooling my understanding of what is actually stored in a list (or in the value of a hash, for that matter) has cleared up nearly all of my confusion. I now find references no more confusing (and in fact, less so) than pointers in C. Which, depending on the reader, may not be much encouragement...
Personally, I find them "no more confusing" than references (although the VM wants to tell you they're pointers) in Java. ;)
They aren't pointers unless you can do arithmetic on them. Which is impossible in both Java and Perl, because that really screws up garbage collection. References, well-behaved little opaque data types that they are, can be counted and followed and used to find things that aren't referred to by anything still living. C and C++ don't provide a garbage-collected runtime, so they give you pointers. Perl and Java do, so all they give you are references.
Design Patterns
http://patternsinperl.com/designpatterns/decorator/ only found in WayBackMachine?. Any new links for a list of Perl based patterns? -- DavidLiu
Yes: http://www.perldesignpatterns.com -- RutgerVos?
I've been programming in perl for about 10 years and I keep forgetting about autovivication whenever I'm building a nested hash structure, and keep testing for membership, creating an empty list (or hash) if necessary, then assigning to it. Probably because the other languages I've worked with don't support autovivication. -- lastedit (remove next time)
The other thing I see lots of perl hackers do is fail to use the 'method object" syntax and only ever use 'object->method". The justifications for this that the former is ambiguous just don't fly with me -- in any one context, you shouldn't be using ambiguous types anyway, and anything that can reduce the syntactic noise is a really good thing. -- lastedit (remove next time)
The indirect object syntax is ambiguous to Perl's parser; it's too sensitive to the order in which you've defined barewords. Perl 6 fixes this by requiring a postfix notation on invocants in ambiguous cases. In Perl 5, unless you know when and how indirect invocation can fail, you oughtn't use it.
Perl has its faults, but it certainly is very powerful compared with more pedestrian languages. Usually it's more a question of what you program, than which language you use. My last big struggle in perl was adapting AliceBot to a whole new application area (i.e. changing both its "database" and also changing/adding lots of perl code to it, while giving it an interactive web interface), and although painful, it was fairly stimulating. I was helping someone out, wouldn't have done it by myself. Learned a lot more about Perl in the process. I am not so much inclined to sneer at it anymore, it has some very strong points.
http://www.perldoc.com/perl5.8.0/ definitely demands a look at.
Is it just me, or does Perl's official logo look unmistakably similar to the official logo of the OnionNewsNetwork?? Compare:
against:
SimplifiedWrapperAndInterfaceGenerator (SWIG) can be used to make calls to CeeLanguage or CeePlusPlus code.
Also see: ProgrammingLanguageQuotes PerlGolf PerlPoetry ArtisticLicense ComprehensivePerlArchiveNetwork (CPAN)
EditText of this page
(last edited June 22, 2013)
or FindPage with title or text search