Perl.CodeCompared.To/PHP

PHP requires the <?php opening tag before any PHP code — without it, the file is served as literal HTML. echo is the direct equivalent of Perl's print: it does not append a trailing newline, so "\n" must be included explicitly, unlike Perl's say. declare(strict_types=1); is PHP's closest analog to Perl's use v5.38; preamble — both opt a file into stricter, more modern behavior.

Both languages are interpreted with no separate compile step, so php hello.php and perl hello.pl run identically. PHP additionally ships a built-in development web server (php -S) with no external module needed — a Perl programmer would typically reach for plackup or a CPAN-distributed web framework to get the same convenience.

PHP supports three comment styles: // and # for single-line comments (both valid — // is by far the more common convention), and C-style /* ... */ for real multi-line block comments. Perl's # is the only inline form, and Perl has no true block-comment syntax at all — the =begin/=end Pod markers are a workaround borrowed from documentation tooling, not a first-class comment construct.

PHP's echo is close to Perl's print — neither appends a newline automatically, unlike Perl's say. echo accepts multiple comma-separated arguments (echo "a", "b";) but does not implicitly stringify numbers the way string interpolation does, so numeric values are usually concatenated with .. PHP's var_dump plays the same debugging role as Ruby's p or Perl's Data::Dumper: it shows the type and full structure of a value, not just its printed form.

PHP flattens Perl's three sigils ($ for scalars, @ for arrays, % for hashes) into one: every variable, regardless of what it holds, is prefixed with $. This is a genuine simplification of the sigil system, but it comes at a cost a Perl programmer will notice immediately: PHP has no separate array and hash sigil-driven type, because it has no separate array and hash type at all — see the Arrays section for what that unification actually means.

Perl's my creates a genuinely new lexical variable scoped to the enclosing block, so an inner my $count shadows an outer one. PHP has no declaration keyword for local variables at all — a bare assignment creates or reassigns a variable in the enclosing function scope, and if/while/for blocks do not introduce a new scope, exactly like Ruby. Only function bodies (and, separately, closures via use) create new variable scopes in PHP.

Perl's use v5.38 preamble automatically enables strict (mandatory variable declarations) and warnings (diagnostics for questionable constructs), but it does not add compile-time type checking — Perl remains fully dynamically typed with automatic numeric-string coercion. PHP's declare(strict_types=1); is orthogonal: it only affects type-hinted function signatures, forbidding PHP's usual implicit type coercion (an int parameter will reject a passed string rather than silently converting it) for calls within that file. Without it, PHP coerces arguments the way Perl coerces values everywhere.

Both languages let a variable hold a value of any type at any time by default — neither requires a type declaration for a plain variable. PHP additionally supports optional type hints on function parameters, return values, and (since PHP 7.4) typed properties, giving a Perl programmer an opt-in static-checking layer that Perl has no built-in equivalent for (Perl relies on CPAN modules like Type::Tiny for anything similar).

PHP has two ways to define a top-level constant: the define() function, evaluated at runtime (closer to Perl's use constant, which is also evaluated when the pragma is processed), and the const keyword, evaluated at compile time and preferred for simple scalar values. Unlike every other PHP variable, a constant defined either way is referenced with no $ sigil at all — a rare case where PHP drops its otherwise-universal sigil rule, landing closer to how Perl's use constant names read as bareword function calls.

PHP's truthiness rules track Perl's almost exactly — this is one of the strongest resemblances between the two languages' semantics, and a pleasant surprise for a Perl programmer used to other languages diverging here. Both treat 0, the empty string "", and the single-character string "0" as falsy, while "00" and a lone space " " are truthy in both. PHP additionally treats an empty array [] as falsy (Perl has no unified array/hash type to compare against directly, but an empty Perl array in boolean context is also falsy) and null plays the role Perl's undef plays.

PHP's list destructuring, written with either list(...) or the shorthand [...] syntax on the left-hand side, mirrors Perl's list-assignment destructuring, including the temp-free swap idiom both languages share. PHP has no direct equivalent to Perl's my ($head, @tail) = (...) "soak up the rest" pattern — there is no splat-style remainder capture in list destructuring, so grabbing "the first element and everything else" needs array_shift plus the remaining array rather than a single destructuring assignment.

PHP double-quoted strings interpolate a bare $name exactly like Perl, and the same single-vs-double-quote distinction applies: single-quoted PHP strings interpolate nothing, just like Perl's single-quoted strings. Where the two diverge is arbitrary-expression interpolation — Perl's awkward @{[ expression ]} trick has no PHP equivalent at all, because PHP interpolation only ever substitutes a variable's value (optionally wrapped in {} for array/property access), never evaluates an arbitrary expression like $age + 1 inline.

Like Perl, PHP's string operations are mostly standalone functions that take the string as an argument (strlen($text), strtoupper($text)) rather than methods called on a string object — this is a genuine similarity, since neither language treats a string as an object with a method table by default. Unlike Perl, PHP does provide a built-in trim() function directly, with no regex substitution needed, and str_contains() (PHP 8.0+) replaces the older, more awkward strpos($text, "World") !== false idiom for a simple substring check.

PHP's heredoc (<<<LABEL) is essentially Perl's squiggly heredoc (<<~LABEL) — both strip the closing marker's indentation from every line so the source can be indented naturally, and both interpolate variables by default. PHP additionally names the non-interpolating variant a "nowdoc" (<<<'LABEL', with the label single-quoted), which maps directly onto Perl's single-quoted heredoc terminator (<<~'LABEL') for suppressing interpolation.

PHP's sprintf and printf take the exact same format-specifier syntax as Perl's — both languages inherited this format-string mini-language directly from C, so field widths, precision, padding, and hex/octal formatting all transfer with zero changes needed. This is one of the most portable pieces of syntax between the two languages.

PHP's explode/implode pair map directly onto Perl's split/join, but explode only splits on a literal separator string, not a regex pattern — Perl's split(/,/, ...) happens to use a trivial regex, but PHP requires preg_split for anything beyond a fixed delimiter. Perl's special-cased split ' ', $string form (splitting on runs of whitespace and discarding leading empty fields) has no single-function PHP equivalent; preg_split with PREG_SPLIT_NO_EMPTY is the closest match.

PHP distinguishes integer and double (its name for float) as genuinely separate internal types, unlike Perl's single undifferentiated scalar. Both languages, however, silently promote an integer computation to a floating-point value once it overflows the native integer range — PHP's 64-bit integer overflows to a double just as Perl's scalar does, so neither offers Ruby's arbitrary-precision integer arithmetic without an external library (PHP's GMP or BCMath extensions, Perl's Math::BigInt).

Both languages check parity and sign with inline comparison expressions rather than dedicated predicate methods, and both provide abs() as a standalone function — this is a close match. PHP's C-style for loop (for ($count = 0; $count < 3; $count++)) is the idiomatic counting loop, mirroring Perl's own C-style for more closely than Ruby's range-based 3.times; PHP does support ranges via range(0, 2) combined with foreach as an alternative.

PHP's / operator behaves exactly like Perl's — always floating-point division regardless of operand types — but PHP provides a dedicated intdiv() function for truncating integer division rather than Perl's int(10 / 3) workaround. The two languages disagree on modulo sign convention with a negative operand: Perl's % takes the sign of the right operand (-7 % 3 is 2), while PHP's % takes the sign of the left operand, C-style (-7 % 3 is -1) — a genuine behavioral trap worth checking carefully when porting arithmetic.

PHP supports the same implicit numeric-string coercion Perl does when strict_types is off ("42" + 0 works in both), but explicit cast operators — (int), (float), (string) — are the idiomatic and, under declare(strict_types=1);, often required way to convert. PHP's hexdec()/dechex() pair replaces Perl's hex()/sprintf("%x", ...) for base-16 conversion, with matching functions for octal (octdec/decoct) and binary (bindec/decbin) that Perl handles through oct() and sprintf format specifiers instead.

This is the single biggest structural difference between the languages. Perl keeps arrays (@array, integer-indexed, ordered) and hashes (%hash, string-keyed, unordered) as two genuinely distinct data types with distinct sigils. PHP has exactly one array type — internally an ordered hash map — that serves both roles: a PHP array with sequential integer keys starting at 0 behaves like Perl's @array, while the same type with string keys behaves like Perl's %hash, and it can even freely mix both kinds of keys in one array. There is no PHP equivalent to Perl needing a reference to nest an array inside a hash — it is already the same type.

This is a real gap for a Perl programmer: PHP arrays do not support negative indexing ($numbers[-1] looks for a literal key of -1, which does not exist here, rather than "the last element"). Getting the last element needs end($numbers) or array_slice($numbers, -1)[0], and general slicing uses array_slice($array, $offset, $length) — a start-and-length form like Perl's @array[$start, $length] alternative, not Perl's inclusive-range slice syntax.

PHP's array_push, array_pop, array_shift, and array_unshift are named almost identically to Perl's built-in functions of the same purpose and behave the same way. PHP also offers the terser $items[] = 4; append syntax as an idiomatic alternative to array_push — pushing a single element this way is the more common style and avoids a function-call for the simplest case, something Perl has no equivalent shorthand for.

PHP's array_map and array_filter correspond directly to Perl's map and grep — both transform and filter with a callback, using PHP's arrow-function syntax where Perl uses an implicit-$_ block. A subtle gotcha: unlike Perl's grep, PHP's array_filter preserves the original keys of surviving elements rather than renumbering them, so the result often needs array_values() to get a clean sequential array back — a direct consequence of PHP's single unified array type not distinguishing "list" from "map" the way Perl's array and hash types do.

Perl needs the CPAN-distributed core module List::Util to get reduce and sum0 — these are not built into arrays and use the implicit $a/$b package variables rather than named parameters. PHP's array_sum and array_reduce are always-available built-in functions requiring no import, and array_reduce takes an explicit initial value as its third argument (matching the accumulator idiom, just as a named-parameter callback rather than Perl's special variables).

Both languages default to comparing numbers incorrectly as strings unless told otherwise: Perl's sort needs an explicit { $a <=> $b } comparator for numeric order, and PHP's sort() actually does the right thing for a purely numeric array by default (it uses "smart" comparison), though an explicit SORT_NUMERIC flag or a comparator callback via usort is safer for mixed data. A sharp difference: PHP's sort()/rsort() mutate the array in place and return a boolean, unlike Perl's sort, which always returns a new list leaving the original untouched.

A PHP associative array is not a separate type from a PHP indexed array — it is the exact same underlying ordered hash map, just populated with string keys instead of sequential integers. This means a Perl programmer's %scores and @fruits map onto the same PHP type, using the same [] literal and [key] access syntax; PHP's fat-arrow => for key-value pairs directly echoes Perl's own fat-comma => hash literal syntax, which PHP borrowed the symbol from.

Perl's exists keyword and PHP's array_key_exists() function serve the identical purpose of checking key presence without triggering a warning. PHP's ?? null-coalescing operator (added in PHP 7.0) is a near-exact match for Perl's // defined-or operator — both supply a fallback only when the left side is missing or explicitly undef/null, unlike ||, which would also trigger on any other falsy value.

PHP's foreach ($array as $key => $value) yields both the key and value in one step, exactly matching the ergonomics a Perl programmer would get from writing a helper to zip keys and values together — Perl's idiomatic loop instead iterates keys %hash alone and looks up each value by key inside the loop body. array_keys() and array_values() map directly onto Perl's keys and values functions.

Perl's autovivification lets $word_count{$_}++ spring a missing key into existence and treat undef as 0 for the increment. PHP does not autovivify a scalar the way Perl does here — incrementing a genuinely missing key raises a warning under strict settings, so the explicit ?? 0 default is idiomatic PHP rather than optional. PHP does autovivify nested array structures on assignment ($data["a"]["b"] = 1; creates both levels), which is closer to Perl's nested-hash autovivification. array_merge mirrors Perl's list-flattening merge idiom, with later keys winning in both.

This is the single biggest conceptual difference between the two languages, exactly as it is for Ruby. In Perl, the same expression evaluates differently depending on whether it appears in scalar or list context — assigning an array to a scalar silently gives its length, while assigning a literal list (1, 2, 3) to a scalar gives its last element, not its count. PHP, like PHP's C-family relatives, has no context sensitivity whatsoever: an expression always evaluates to exactly one thing, and a count always requires an explicit count() call. A Perl programmer moving to PHP loses this expressiveness but also every context-related surprise it can cause.

Perl's wantarray lets a subroutine inspect the context it was called in and return a different value depending on whether the caller wants a list, a scalar, or nothing at all (void context). PHP has no equivalent mechanism — a function always returns the same value regardless of how the caller intends to use it, exactly like Ruby. The caller is responsible for extracting what it needs (contextAware()[0] for the first element), rather than the callee adapting its return shape.

Perl offers several implicit ways to coerce an array into its count — numeric context, string concatenation, or the explicit scalar() function all work. PHP offers none of these shortcuts: concatenating an array directly with . triggers a warning ("Array to string conversion") rather than silently substituting a count, so count($items) must always be called out explicitly, in a string or anywhere else.

PHP's middle branch is spelled elseif as one word (though the two-word else if also works when each branch is its own nested block) — a small spelling difference from Perl's elsif, which drops the "e". Everything else about the construct is identical: parenthesized conditions, curly-brace bodies, and the same short-circuit evaluation order.

This is a genuine loss for a Perl programmer: PHP has neither an unless keyword nor a postfix statement-modifier form for if at all. Every conditional guard must be written as a full if (...) { ... } block, even for the simplest one-line guard clause that Perl or Ruby would express as statement unless condition;. This makes short validation-guard code measurably more verbose in PHP than in either Perl or Ruby.

PHP's range() function generates the same kind of numeric or character sequence Perl's 1..5 and "a".."e" range operator produces, including character ranges — but in PHP it is a function call producing a real array up front, not a lazy first-class Range object the way Ruby has, nor Perl's built-in operator syntax. foreach is the idiomatic PHP iteration keyword and maps directly onto Perl's foreach (Perl's for and foreach are interchangeable keywords for this form; PHP reserves for strictly for the C-style three-clause loop).

Both languages have an identical while loop and a do { ... } while (...) form that guarantees at least one execution before checking the condition — this is one of the more directly portable control-flow constructs between Perl and PHP, syntax and semantics both. PHP has no built-in until keyword (unlike Perl and Ruby), so "loop while false" always needs a negated while condition instead.

Perl once had an experimental given/when construct but removed it due to design problems with smart matching, leaving Perl programmers to fake it with a for ($topic) { if (...) { ...; last } } loop. PHP 8.0's match expression is a clean, permanent replacement with real advantages over Perl's workaround: it is an expression that returns a value directly (no intermediate variable assignment inside the loop needed), it uses strict (===) comparison with no implicit type coercion, and an unmatched value with no default arm throws UnhandledMatchError rather than silently falling through.

Perl subroutines receive all arguments bundled into the single array @_ and must manually unpack them with my ($number) = @_; — there is no way to name parameters directly in the widely-used, portable sub syntax. PHP functions declare named parameters directly in the signature, optionally with type hints (int $number), so there is no unpacking step at all — matching the ergonomics Perl programmers will recognize as a real upgrade from manual @_ handling.

Perl has no default-parameter syntax in a sub signature — the idiomatic approach is unpacking positionally from @_ and using //= to fill in a default afterward. PHP supports default values directly in the function signature (string $greeting = "Hello"), evaluated once at the point the function is declared for simple literal defaults — much closer to Ruby's ergonomics here than to Perl's.

Perl simulates keyword arguments by unpacking a flat key-value list into a hash inside the subroutine (my (%args) = @_;) — there is no way for the signature itself to declare which keywords exist or provide defaults. PHP 8.0's named arguments (name: "Alice") are a real language feature layered directly onto ordinary positional parameters: any parameter can be called by name in any order, required parameters with no default must be supplied, and defaults are declared in the signature — no manual hash unpacking needed, much like Ruby's keyword arguments.

PHP's ...$items splat parameter (the "spread"/"variadic" operator) collects any number of trailing positional arguments into a plain indexed array, directly matching Perl's my (@items) = @_; idiom for "gather everything into an array." PHP has no equivalent to Perl's hash-unpacking variadic pattern for arbitrary named arguments, though — real named arguments (shown in describe) cover that use case instead, requiring each parameter to be declared up front rather than accepted as an open-ended set of keys.

Perl has no return-type declaration syntax at all — a sub can return any value of any shape, and the caller has no compile-time guarantee about what comes back. PHP's : int return-type hint (available since PHP 7.0) is checked at call time under declare(strict_types=1);, so a function declared to return int that tries to return a string raises a TypeError — real type safety a Perl programmer would otherwise need a CPAN module like Function::Parameters or Type::Tiny to approximate.

Perl's anonymous subroutine (sub { ... }) must be explicitly created and invoked with an arrow (->()), just like PHP's anonymous function, which is invoked by calling the variable it is stored in directly ($callback($name)) or, immediately, with a parenthesized call right after the definition. Neither language has Ruby's dedicated trailing-block syntax (each do |name| ... end) built into every iteration method — both PHP's array_map/foreach and Perl's map/for take an explicit callback or use dedicated loop syntax rather than a lightweight block-passing convention.

Both languages require a callback-taking function to accept the callable as an explicit parameter — neither has Ruby's implicit yield mechanism for attaching a block with no parameter declared in the signature. PHP's callable type hint documents the parameter's intent (any anonymous function, named function string, or invokable object satisfies it), while Perl typically just documents "expects a code reference" in a comment, since Perl's type system has no equivalent hint for code references.

This is a real behavioral difference worth calling out for a Perl programmer: Perl closures capture every enclosing lexical variable automatically and always by reference, so a later change to $multiplier outside the closure is visible inside it. PHP anonymous functions capture nothing automatically — every outer variable a closure needs must be listed explicitly in a use (...) clause, and by default that capture is by value at definition time (a later outer change is invisible inside), unless the variable is prefixed with & in the use clause to opt into capture-by-reference, matching Perl's default behavior.

PHP 7.4's arrow function syntax (fn($number) => expression) is the closest PHP equivalent to Perl's single-expression anonymous sub, and — unlike PHP's longer function closure syntax — it does automatically capture outer variables by value, with no use clause needed, closer to Perl's automatic capture (though still by value, not by reference, so it still cannot see later updates to $multiplier the way a Perl closure would). Arrow functions are limited to a single expression body with an implicit return, much like Ruby's stabby lambda.

Both languages support a true closure-factory pattern: a function returns an anonymous function that keeps its own private state across calls, and each call to the factory produces an independent closure with its own copy of that state. The key difference is explicitness: Perl's closure captures $count automatically by reference with no extra syntax, while PHP requires the by-reference use (&$count) clause spelled out — without the &, each call to the returned function would see a fresh copy of $count starting at 0 every time, since PHP's default capture is by value.

This is a genuinely three-way contrast worth pausing on. Perl requires an explicit backslash to create any reference and an explicit sigil to dereference it ($$ref). Ruby has no distinction at all: every value except a few immediates is always an implicit reference, so assigning one variable to another always shares the underlying object. PHP sits in between: arrays and scalars are copied by value on assignment (no explicit reference needed, and no accidental aliasing — a real convenience over Perl's explicit-everything model for these types), while objects are always implicit references, exactly like Ruby. A Perl programmer needs to remember which PHP behavior applies to which kind of value.

PHP has one place where it genuinely resembles Perl's explicit-reference model rather than Ruby's implicit one: a function parameter can be declared by reference with &$parameter, letting the function mutate the caller's original scalar — something Ruby cannot do for a plain number or string at all (Ruby's integers are immutable and reassignment inside a method never affects the caller's variable). Where Perl requires the caller to pass an explicit \$count reference, PHP's reference parameter is transparent at the call site — the & lives only in the function signature, not in each call — but the effect (mutating a scalar the caller can see) is the same feature.

Perl's [...] and {...} literals create anonymous references that must always be accessed through the arrow operator ($array_ref->[1]) or an explicit dereferencing sigil (@$array_ref). PHP's [...] literal creates the array value directly, with plain bracket access ($array[1]) and no arrow or dereferencing sigil ever needed — much closer to Ruby's uniform object model here than to Perl's reference ceremony, since a PHP array is a value in its own right rather than something that needs to be dereferenced through a pointer-like reference.

Both languages' regex engines are PCRE-descended and share nearly identical pattern syntax, character classes, and quantifiers — a Perl programmer's pattern-writing intuition transfers directly. The calling convention differs, though: Perl builds regex matching into the language itself via the =~ binding operator and true regex literals, while PHP wraps the (literal, C-library) PCRE engine in ordinary functions — preg_match, preg_match_all, preg_replace — that take the pattern as a delimited string argument (commonly /pattern/, though any matching delimiter pair works) and write captured groups into a variable passed by reference rather than into $1/$2 globals.

Perl's s/pattern/replacement/ needs the /g flag to replace every occurrence rather than just the first, and always returns a new copy in this non-destructive form (the destructive s/// without a copy mutates the original). PHP's preg_replace always returns a new string too, but flips the default: with no limit argument it replaces all occurrences (matching Perl's /g behavior by default), and passing an explicit limit of 1 is what restricts it to the first match only — the opposite default from Perl's bare s///.

Named captures use the identical PCRE (?<name>...) syntax in both languages, since both sit directly atop PCRE-compatible engines. The retrieval mechanism differs from Perl's special %+ hash: PHP's preg_match writes both the numbered and named captures into the same $matches array passed by reference, so $matches['year'] and $matches[1] refer to the same captured value side by side.

Perl relies on context sensitivity for "find every match": the same =~ /pattern/g returns all matches in list context, or advances an internal position pointer one match at a time in scalar context inside a while loop. PHP has one dedicated function instead — preg_match_all — which always populates every match into the $matches array in one call, with $matches[0] holding the full matches and $matches[1], $matches[2], and so on holding each capture group across all matches — no context-dependent behavior to reason about, matching PHP's consistent no-context-sensitivity story throughout.

PHP uses the same PCRE modifier letters Perl does, in the same position after the closing delimiter — i for case-insensitive, m for multiline anchors, x for extended mode. This is unsurprising, since both languages' regex engines are literally built on (or, in PHP's case, directly wrap) the same PCRE library — a Perl programmer's regex modifier intuition transfers to PHP with no translation needed at all, more directly than almost any other piece of syntax covered in this cheatsheet.

This is where a Perl programmer will feel real envy. Perl OOP is built manually from two separate primitives: a package to hold the namespace, and bless to associate a plain hash reference with that package so it is recognizable as an object — every constructor is hand-written. PHP has a genuine native class keyword with constructor property promotion (PHP 8.0+): declaring a constructor parameter with a visibility modifier like private string $name both declares the property and assigns it from the argument in one line, collapsing what would be several lines of bless-and-assign Perl into a single parameter declaration.

Perl has no built-in accessor generation at all — every getter and setter is hand-written, often using the combined pattern shown here where the same method acts as both getter and setter depending on whether an argument was passed. PHP's public properties need no accessor methods whatsoever: $person->name and $person->age = 31 read and write the property directly, and PHP 8.1's readonly modifier enforces Perl-style "settable once, in the constructor, then immutable" semantics with a single keyword — no hand-written guard logic needed. This is more direct than even Ruby's attr_accessor, which still generates method calls under the hood; PHP's public properties are true direct field access.

Perl declares inheritance by populating the special array @ISA with parent package names (or, in modern Perl, the more readable use parent 'Animal'; pragma). PHP uses the extends keyword directly in the class definition — a single-inheritance declaration built into the syntax, closer to Ruby's < than to Perl's array-based mechanism. PHP's instanceof operator replaces Perl's isa method call for checking class ancestry, and both languages support calling the parent's overridden method — Perl's SUPER::method, PHP's parent::method().

PHP has no true operator-overloading protocol for a custom class — unlike Perl's use overload pragma, there is no way to make PHP's built-in + operator invoke a method on a custom object; addition between two Money objects must be an explicit method call like add() rather than $a + $b. Where the languages do align is stringification: PHP's __toString() magic method plays exactly the role Perl's '""' overload entry plays, and PHP needs no separate pragma to opt in — any class simply defining __toString() is automatically used wherever the object is treated as a string.

die is Perl's throw; a bare eval { } block is the try-block equivalent of PHP's try/catch. PHP's error-handling ergonomics land close to Ruby's and are a real improvement over Perl's global-variable-based approach: the caught exception object is bound directly to a local variable at the point of the catch clause (catch (Exception $error)), with no equivalent of Perl's easy-to-forget or easy-to-accidentally-clear $@ global to check manually.

A naming trap for a Perl programmer: PHP has no warn() function that behaves like Perl's — PHP's error-reporting equivalent is trigger_error(), which raises a PHP-level warning (visible depending on the configured error-reporting level and handler) without halting execution, matching Perl's warn in spirit if not in name. PHP also has real E_WARNING/E_NOTICE diagnostic levels the runtime itself emits for things like undefined-array-key access — closer to Perl's own built-in warnings pragma output than to a user-triggered message.

Perl can die with a blessed object instead of a plain string, but the caller must manually check ref($error) && $error->isa('AppError') to determine what was thrown. PHP has a dedicated exception hierarchy rooted at Throwable (with Exception and Error as the two main branches), and catch (AppError $error) filters by class directly in the catch clause — no manual instanceof check needed, and multiple catch blocks can handle different exception types in sequence, tried in order, exactly like Ruby's multiple rescue clauses.

Perl has no dedicated "always run this" block keyword — guaranteed cleanup requires a nested eval with careful manual saving of $@ before a subsequent statement can overwrite it, or a CPAN module like Scope::Guard. PHP's finally clause is a first-class part of try/catch/finally, running whether the try block succeeded, threw, or even used return early — no manual state juggling required, matching Ruby's ensure almost exactly in both placement and guarantee.

Perl's three-argument open takes a mode string ('>' for write, '>>' for append, '<' for read) and a lexical filehandle, and requires an explicit close when finished. PHP's file_put_contents is a one-line convenience function for the common "write this whole string to this path" case, directly analogous to Ruby's File.write; for finer control PHP's fopen/fwrite/fclose trio mirrors Perl's explicit-handle style closely, including the same requirement to close the handle manually. Both examples are marked norun because the sandboxed execution backends for both languages have no real filesystem.

Perl reads a file line by line with the diamond operator <$filehandle> inside a while loop, and slurping the whole file requires localizing $/ (the input record separator) to undef — an obscure special-variable trick. PHP has two direct, purpose-built functions instead: file(), which reads the whole file into an array of lines in one call (the FILE_IGNORE_NEW_LINES flag strips trailing newlines, similar to Perl's chomp), and file_get_contents() to slurp the entire contents into one string — no special-variable manipulation needed for either case, matching Ruby's File.foreach/File.read pair closely.

Perl's $_ is a pervasive implicit topic variable: many built-in functions (uc, print, chomp) operate on it with no argument, and constructs like for, map, and grep set it automatically. PHP has no equivalent implicit variable at all — every foreach loop variable and every closure parameter must be named explicitly ($word), which is more verbose for quick one-off transformations but leaves no ambiguity about which value a function call is operating on, exactly matching Ruby's stance on the same trade-off.

Perl's @ARGV excludes the script name itself ($ARGV[0] is the first real argument), while PHP's $argv array includes the script name as element 0, so the first real argument is $argv[1] — a common off-by-one trap when porting command-line scripts. Environment access differs too: Perl's %ENV is a plain hash read and written with ordinary hash syntax, while PHP requires the getenv()/putenv() function pair (the $_ENV superglobal also exists but is populated only when the variables_order ini setting includes E, so getenv() is the more portable choice).

Perl exposes process identity through terse punctuation variables: $0 for the script name, $$ for the process ID. PHP provides the same information through self-describing names instead: the magic constant __FILE__ for the current file's path, getmypid() for the process ID, and PHP_VERSION for the interpreter version — closer to Ruby's $PROGRAM_NAME/Process.pid/RUBY_VERSION naming style than to Perl's punctuation-heavy variables.

CPAN (the Comprehensive Perl Archive Network) predates Composer and Packagist by roughly fifteen years and pioneered the idea of a centralized, versioned package archive with a consistent module-distribution format. Composer plays the equivalent role for PHP, pulling packages from Packagist and — critically — generating a PSR-4 autoloader file that resolves class names to file paths automatically, whereas Perl programmers write explicit use lib statements or rely on the module's own use declaration to load each dependency by name. Like Ruby, PHP ships JSON encoding in its standard library with no external dependency needed, where Perl reaches for a CPAN module (JSON::PP or similar) even for this common task.