The Perl Philosophy

# 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. [http://perldoc.perl.org/](http://perldoc.perl.org/) hosts recent versions of the Perl documentation. CPAN indexes at [http://search.cpan.org/](http://search.cpan.org/) and [http://metacpan.org/](http://metacpan.org/) provide documentation for all CPAN modules. Other distributions such as ActivePerl and Strawberry Perl provide local documentation in HTML formats. 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. How to Read the Documentation Perl has lots of documentation. Where do you start? `perldoc perltoc` displays the table of contents of the core documentation, and `perldoc perlfaq` displays the table of contents for Frequently Asked Questions about Perl. `perldoc perlop` and `perldoc perlsyn` document Perl's symbolic operators and syntactic constructs. `perldoc perldiag` explains the meanings of Perl's warning messages. `perldoc perlvar` lists all of Perl's symbolic variables. Skimming these files will give you a great overview of the language. 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 `...` Operator Perl 5.12 introduced the triple-dot (`...`) operator as a placeholder for code you intend to fill in later. Perl will parse it as a complete statement, but will throw an exception that you're trying to run unimplemented code if you try to run it. See `perldoc perlop` for more details. ### 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`. `readline` Perl's `<$fh>` operator is the same as the `readline` builtin. `readline $fh` does the same thing as `<$fh>`. As of Perl 5.10, a bare `readline` behaves just like `<>`, so you can now use `readline` everywhere. For historic reasons, `<>` is still more common, but consider using `readline` as a more readable alternative. (What's more readable, `glob '*.html'` to `<*.html>`? The same idea applies.) `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.