The Perl Philosophy

Perl gets things done—it's flexible, forgiving, and malleable. Capable programmers use it every day for everything from one-liners and one-off automations to multi-year, multi-programmer projects.

Perl is pragmatic. You're in charge. You decide how to solve your problems and Perl will mold itself to do what you mean, with little frustration and no ceremony.

Perl will grow with you. In the next hour, you'll learn enough to write real, useful programs—and you'll understand how the language works and why it works as it does. Modern Perl takes advantage of this knowledge and the combined experience of the global Perl community to help you write working, maintainable code.

First, you need to know how to learn more.

Perldoc

Perl has a culture of useful documentation. The perldoc utility is part of every complete Perl installation However your Unix-like system may require you to install an additional package such as perl-doc on Debian or Ubuntu GNU/Linux.. The perldoc command-line utility displays the documentation of every Perl module installed on the system—whether a core module or one installed from the Comprehensive Perl Archive Network (CPAN)—as well as thousands of pages of Perl's copious core documentation.

Use perldoc to read the documentation for a module or part of the core documentation:

    $ perldoc List::Util
    $ perldoc perltoc
    $ perldoc Moose::Manual

The first example displays the documentation embedded within the List::Util module. The second example displays a pure documentation file, in this case the table of contents of the core documentation. The third example displays a pure documentation file included as part of a CPAN distribution (Moose). perldoc hides these details; there's no distinction between reading the documentation for a core library such as Data::Dumper or one installed from the CPAN. This consistency is a benefit to you—Perl culture values documentation so much that even external libraries tend to follow the good example of the core language documentation.

The standard documentation template includes a description of the module, demonstrates sample uses, and then contains a detailed explanation of the module and its interface. While the amount of documentation varies by author, the form of the documentation is remarkably consistent.

The perldoc utility has many more abilities (see perldoc perldoc). To search the Perl FAQ, use the -q option with a keyword. For example, perldoc -q sort returns three questions: How do I sort an array by (anything)?, How do I sort a hash (optionally by value instead of key)?, and How can I always keep my hash sorted?.

The -f option displays the documentation for a builtin Perl function. perldoc -f sort explains the behavior of the sort operator. If you don't know the name of the function you want, browse the list of available builtins in perldoc perlfunc.

The -v option looks up a builtin variable. For example, perldoc -v $PID displays the documentation for the variable which contains the current program's process id. Depending on your shell, you may have to quote the variable appropriately.

The -l option causes perldoc to display the path to the documentation file rather than the contents of the documentation Be aware that a module may have a separate .pod file in addition to its .pm file..

The -m option displays the entire contents of the module, code and all, without performing any special formatting.

Perl uses a documentation format called POD, which is short for Plain Old Documentation, or POD. perldoc perlpod describes how POD works. Other POD tools include podchecker, which validates the structure of POD documents, and the Pod::Webserver CPAN module, which displays local POD as HTML through a minimal web server.

Expressivity

Larry Wall studied linguistics and human languages. Then he designed Perl. Unlike other languages designed around a mathematical notion, Perl takes into account how people communicate. In return, you get the freedom to decide how to arrange your programs to meet your needs. You may write simple, straightforward code or combine many small pieces into larger programs. You may select from multiple design paradigms, and you may eschew or embrace advanced features.

Where other languages claim that there should be only one best way to solve any problem, Perl allows you to decide what's most readable, most useful, most appealing, or most fun.

Perl hackers have a slogan for this: TIMTOWTDI, pronounced "Tim Toady", or "There's more than one way to do it!"

Though this expressivity allows master craftworkers to create amazing programs, it also allows the unwary to make messes. Experience and good taste will guide you as you design your code, but the choice is always yours. Express yourself, but be mindful of readability and maintainability, especially for those who come after you.

Learning Perl is like learning any spoken language. You'll learn a few words, then string together sentences, and then enjoy simple conversations. Mastery comes from practice of both reading and writing code. You don't have to understand every detail of Perl to be productive, but the principles in this chapter are vital to your growth as a programmer.

Perl novices often find certain syntactic constructs opaque. These idioms (Idioms) offer great (if subtle) power in the hands of experienced programmers, but it's okay to avoid them until you're comfortable with them.

As another design goal, Perl tries to avoid surprising experienced (Perl) programmers. For example, adding two variables ($first_num + $second_num) is obviously a numeric operation (Numeric Operators); the addition operator must treat both as numeric values to produce a numeric result. No matter the contents of $first_num and $second_num, Perl will coerce them to numeric values (Numeric Coercion). You've expressed your intent to treat them as numbers by using a numeric operator. Perl happily does so.

Perl adepts often call this principle DWIM, or do what I mean. You could just as well say that Perl follows the principle of least astonishment. Given a cursory understanding of Perl (especially context; Context), it should be possible to understand the intent of an unfamiliar Perl expression. You will develop this skill as you learn Perl.

Perl's expressivity allows novices to write useful programs without having to understand the entire language. This is by design! Experienced developers often call the results baby Perl. This is a term of endearment, because everyone begins as a novice. Through practice and learning from more experienced programmers, you will understand and adopt more powerful idioms and techniques. It's okay for you to write simple code that you understand. Keep practicing and you'll become a native speaker.

An experienced Perl hacker might triple a list of numbers with:

    my @tripled = map { $_ * 3 } @numbers;

... and a Perl adept might write:

    my @tripled;

    for my $num (@numbers)
    {
        push @tripled, $num * 3;
    }

... while a novice might try:

    my @tripled;

    for (my $i = 0; $i < scalar @numbers; $i++)
    {
        $tripled[$i] = $numbers[$i] * 3;
    }

Every program does the same thing, but each uses Perl in a different way.

As you get more comfortable with Perl, you can let the language do more for you. With experience, you can focus on what you want to do rather than how to do it. Even so, Perl will happily run baby Perl just as well as expert Perl. You can design and refine your programs for clarity, expressivity, reuse, and maintainability, in part or in whole. Take advantage of this flexibility and pragmatism: it's far better to accomplish your task effectively now than to write a conceptually pure and beautiful program next year.

Context

In spoken languages, the meaning of a word or phrase may depend on how you use it; the local context helps clarify the intent. For example, the inappropriate pluralization of "Please give me one hamburgers!" The pluralization of the noun differs from the amount. sounds wrong, just as the incorrect gender of "la gato" The article is feminine, but the noun is masculine. makes native speakers chuckle. Other words do double duty; one sheep is a sheep just as two sheep are also sheep.

Context in Perl is similar. It describes the amount as well as the kind of data to use. Perl will do what you mean to do to data if you choose the appropriate context for that data.

For example, several Perl operations produce different behaviors when you expect zero, one, or many results. A specific construct in Perl may do something different if you write "Do this, but I don't care about any results" compared to "Do this and give me multiple results." Other operations allow you to specify whether you expect to work with numeric data, textual data, or true or false data.

Context can be tricky if you try to write or read Perl code as a series of single steps in isolation. That's not how Perl works! Every expression is part of a larger context. You may find yourself slapping your forehead after a long debugging session when you discover that your assumptions about context were incorrect. If instead you're aware of context, your code will be more correct—and cleaner, flexible, and more concise.

Void, Scalar, and List Context

Amount context governs how many items you expect from an operation. The English language's subject-verb number agreement is a close parallel. Even without knowing the formal description of this linguistic principle, you probably understand the error in the sentence "Perl are a fun language" In terms of amount context, you could say that the verb "are" expects multiple nouns.. In Perl, the number of items you request determines how many you get.

Suppose the function (Declaring Functions) called find_chores() sorts your household todo list in order of task priority. The number of chores you expect to read from your list determines what exactly the function will do. If you expect nothing, you're just pretending to be busy. If you expect one task, you have something to do for the next fifteen minutes. If you have a burst of energy on a free weekend, you could get all of the chores.

When you call a function on its own and never use its return value, you've used void context:

    find_chores();

Assigning the function's return value to a single item (Scalars) enforces scalar context:

    my $single_result = find_chores();

Assigning the results of calling the function to an array (Arrays) or a list, or using it in a list, evaluates the function in list context:

    my @all_results             = find_chores();
    my ($single_element, @rest) = find_chores();

    # list of results passed to a function
    process_list_of_results( find_chores() );

The parentheses in the second line of the previous example group the two variable declarations (Lexical Scope) into a single unit so that assignment assigns to both of the variables. Note that a single-item list is still a list, however. You could also correctly write:

    my ($single_element)   = find_chores();

.... in which case the parentheses give a hint to the Perl parser that you intend list context for the assignment even though you assign only one element of a list. This is subtle, but now that you know about it, the difference of amount context between these two statements should be obvious:

    my $scalar_context = find_chores();
    my ($list_context) = find_chores();

Evaluating a function or expression—except for assignment—in list context can produce confusion. Lists propagate list context to the expressions they contain. Both of these calls to find_chores() occur in list context:

    process_list_of_results( find_chores() );

    my %results =
    (
        cheap_operation     => $cheap_results,
        expensive_operation => find_chores(), # OOPS!
    );

The latter example often surprises novice programmers, as initializing a hash (Hashes) with a list of values imposes list context on find_chores. Use the scalar operator to impose scalar context:

    my %results =
    (
        cheap_operation     => $cheap_results,
        expensive_operation => scalar find_chores(),
    );

Why does context matter? A context-aware function can examine its calling context and decide how much work it must do. In void context, find_chores() may legitimately do nothing. In scalar context, it can find only the most important task. In list context, it must sort and return the entire list.

Numeric, String, and Boolean Context

Perl's other context—value context—governs how Perl interprets a piece of data. You've probably already noticed that Perl can figure out if you have a number or a string and convert data between the two forms. In exchange for not having to declare (or at least track) explicitly what type of data a variable contains or a function produces, Perl's value contexts provide hints about how to treat that data.

Perl will coerce values to specific proper types (Coercion), depending on the operators you use. For example, the eq operator tests that strings contain the same information as strings:

    say "Catastrophic crypto fail!" if $alice eq $bob;

You may have had a baffling experience where you know that the strings are different, but they still compare the same:

    my $alice = 'alice';
    say "Catastrophic crypto fail!" if $alice == 'Bob';

Where the eq operator treats its operands as strings by enforcing string context on them, the == operator imposes numeric context. In numeric context, both strings evaluate to 0 (Numeric Coercion). Be sure to use the proper operator for the type of context you want.

Boolean context occurs when you use a value in a conditional statement. In the previous examples, if evaluated the results of the eq and == operators in boolean context.

In rare circumstances, you may need to force an explicit context where no appropriately typed operator exists. To force a numeric context, add zero to a variable. To force a string context, concatenate a variable with the empty string. To force a boolean context, double up the negation operator:

    my $numeric_x =  0 + $x;  # forces numeric context
    my $stringy_x = '' . $x;  # forces string  context
    my $boolean_x =    !!$x;  # forces boolean context

Value contexts are easier to identify than amount contexts. Once you know which operators provide which contexts (Operator Types), you'll rarely make mistakes.

Implicit Ideas

Programmers who understand Perl's linguistic shortcuts can glance at code and instantly understand its most important characteristics. Besides context, Perl has default variables—the programming equivalent of pronouns.

The Default Scalar Variable

The default scalar variable (also called the topic variable), $_, is most notable in its absence: many of Perl's builtin operations work on the contents of $_ in the absence of an explicit variable. You can still use $_ as the variable, but it's often unnecessary.

Many of Perl's scalar operators (including chr, ord, lc, length, reverse, and uc) work on the default scalar variable if you do not provide an alternative. For example, the chomp builtin removes any trailing newline sequence from its operand See perldoc -f chomp and $/ for more precise details of its behavior.:

    my $uncle = "Bob\n";
    chomp $uncle;
    say "'$uncle'";

$_ has the same function in Perl as the pronoun it in English. Without an explicit variable, chomp removes the trailing newline sequence from $_. Perl understands what you mean when you say "chomp"; Perl will always chomp it. These two lines of code are equivalent:

    chomp $_;
    chomp;

Similarly, say and print operate on $_ in the absence of other arguments:

    print;  # prints $_ to the current filehandle
    say;    # prints "$_\n" to the current filehandle

Perl's regular expression facilities (Regular Expressions and Matching) default to $_ to match, substitute, and transliterate:

    $_ = 'My name is Paquito';
    say if /My name is/;

    s/Paquito/Paquita/;

    tr/A-Z/a-z/;
    say;

Perl's looping directives (Looping Directives) default to using $_ as the iteration variable. Consider for iterating over a list:

    say "#$_" for 1 .. 10;

    for (1 .. 10)
    {
        say "#$_";
    }

... or while:

    while (<STDIN>)
    {
        chomp;
        say scalar reverse;
    }

... or map transforming a list:

    my @squares = map { $_ * $_ } 1 .. 10;
    say for @squares;

... or grep filtering a list:

    say 'Brunch time!'
        if grep { /pancake mix/ } @pantry;

As English gets confusing when you have too many pronouns and antecedents, so does Perl when you mix explicit and implicit uses of $_. If you use it in multiple places, one piece of code may silently override the value expected by another piece of code. For example, if one function uses $_ and you call it from another function which uses $_, the callee may clobber the caller's value:

    while (<STDIN>)
    {
        chomp;

        # BAD EXAMPLE
        my $munged = calculate_value( $_ );
        say "Original: $_";
        say "Munged  : $munged";
    }

If calculate_value() or any other function changed $_, that change would persist through that iteration of the loop. As of Perl 5.10, you can declare $_ as a lexical variable (Lexical Scope) with my to prevent clobbering an existing instance of $_:

    while (my $_ = <STDIN>)
    {
        ...
    }

Unfortunately, this construct has a few edge cases related to how existing functions behave when they expect $_ to be a global variable. As of Perl 5.18, the Perl 5 Porters consider this feature experimental. Use it with caution. Besides, using a named lexical may be even clearer:

    while (my $line = <STDIN>)
    {
        ...
    }

Use $_ as you would the word "it" in formal writing: sparingly, in small and well-defined scopes.

The Default Array Variables

Perl also provides two implicit array variables. Perl passes arguments to functions (Declaring Functions) in an array named @_. Array manipulation operations (Arrays) inside functions operate on this array by default. These two snippets of code are equivalent:

    sub foo
    {
        my $arg = shift;
        ...
    }

    sub foo_explicit_args
    {
        my $arg = shift @_;
        ...
    }

Just as $_ corresponds to the pronoun it, @_ corresponds to the pronouns they and them. Unlike $_, Perl automatically localizes @_ for you when you call other functions. The builtins shift and pop operate on @_, if provided no explicit operands.

Outside of all functions, the default array variable @ARGV contains the command-line arguments to the program. Perl's array operations (including shift and pop) operate on @ARGV implicitly outside of functions. You cannot use @_ when you mean @ARGV.

ARGV has one special case. If you read from the null filehandle <>, Perl will treat every element in @ARGV as the name of a file to open for reading. (If @ARGV is empty, Perl will read from standard input.) This implicit @ARGV behavior is useful for writing short programs, such as a command-line filter which reverses its input:

    while (<>)
    {
        chomp;
        say scalar reverse;
    }

Why scalar? say imposes list context on its operands. reverse passes its context on to its operands, treating them as a list in list context and a concatenated string in scalar context. If the behavior of reverse sounds confusing, your instincts are correct. Perl arguably should have separated "reverse a string" from "reverse a list".

If you run it with a list of files:

    $ perl reverse_lines.pl encrypted/*.txt

... the result will be one long stream of output. Without any arguments, you can provide your own standard input by piping in from another program or typing directly. That's a lot of flexibility in a small program, but Perl's only getting started.