C.CodeCompared.To/Perl

C requires an explicit #include, a typed int main(void) entry point, and an explicit return 0 on success. Perl needs none of that ceremony — a script is just a sequence of statements, and say (added in Perl 5.10, enabled here by use v5.38) prints with a trailing newline automatically, unlike C's printf, which needs an explicit \n.

Both languages simply execute statements top to bottom — a genuine structural match, since both are imperative languages with no special sequencing construct needed at all.

C has no sigil system at all — a variable's name alone identifies it. Perl prefixes every variable with a sigil indicating its access type: $ for a single (scalar) value, @ for an array, % for a hash — $count here means "the scalar value named count," not a special operator. This is one of the first genuinely new syntax ideas a C developer encounters in Perl.

Perl's my declares a lexically-scoped variable — confined to the enclosing block, exactly like a C variable declared inside { }. This is a closer match than a C developer might expect from a "scripting language": shadowing an outer $x inside a nested block behaves identically in both languages.

C checks add's argument and return types at compile time — passing a pointer where an int is expected is a compile error (or at least a warning). Perl has no compile-time type checking at all: add("two", 3) would run, silently coerce "two" to 0 during numeric addition, and produce 3 — no error, just quiet, possibly surprising, coercion.

A C variable's type is fixed permanently at compile time based on its declaration. A Perl scalar variable — despite always being declared the same way, with $ — can hold a number at one moment and a string the next, with no re-declaration or cast required; the sigil describes the ACCESS pattern (single value), not a fixed data type.

C string concatenation requires manually allocating a big-enough buffer and calling strcpy/strcat, with a buffer overflow if the destination is too small — a classic, genuinely dangerous C bug category. Perl's . operator concatenates directly, growing the result automatically, with no buffer to size or overflow at all.

C's printf requires a format string with type-specific placeholders (%s, %d) that must match the argument types exactly, with no compiler enforcement in older C standards — a real source of undefined behavior if they mismatch. Perl interpolates variables directly inside a double-quoted string, with no format specifiers or type matching to get wrong.

A C array's size is fixed at declaration and baked into the type — growing it means manually allocating a bigger block and copying every element over. Perl's @numbers array grows and shrinks dynamically at runtime with push/pop/shift/unshift, with no manual reallocation ever required from the programmer.

This is something a plain C array structurally cannot do at all: numbers[5] declares a fixed block of exactly 5 ints, full stop. Achieving the same growth in C means switching to a heap-allocated, manually-managed buffer with malloc/realloc and separately tracked size/capacity fields. Perl's push just works, handling the underlying reallocation invisibly.

C has no built-in way to ask an array its length at runtime — the common sizeof(arr) / sizeof(arr[0]) idiom only works for a genuine stack array still in scope, and silently breaks the moment that array decays to a pointer (e.g., when passed to a function). Perl arrays always know their own length; scalar @numbers (or simply using @numbers in numeric context) returns it directly, correct in every context.

This is a genuinely new capability for a C developer, not just different syntax for an old one. C's standard library has no hash table or map type at all — implementing one means writing the bucket array, hash function, and collision resolution yourself, or depending on a third-party library. Perl's % sigil and => syntax build a hash table directly into the language, with no data structure to implement.

exists checks for key presence without triggering autovivification (accidentally creating the key by looking it up), and keys returns every key so you can iterate — both routine, everyday Perl operations that would require substantial hand-written code in C.

This is one of the closest conceptual bridges on the whole site — Perl references were deliberately designed to echo C pointers. C's &value ("address of") becomes Perl's \$value (backslash, "reference to"); C's *pointer (dereference) becomes Perl's $$reference (double sigil, dereference). The underlying idea — a value that identifies another value's location rather than holding it directly — transfers almost unchanged.

Assigning through a dereferenced pointer/reference mutates the ORIGINAL value in both languages, with nearly identical syntax: *pointer = 99 in C, $$reference = 99 in Perl. Neither language copies the value first — both are genuinely operating on the same memory location the reference/pointer identifies.

A C array parameter silently decays into a bare pointer to its first element, losing all length information — a genuine, well-known C footgun requiring a separately-passed length parameter. Perl's [1, 2, 3] creates an explicit ARRAY REFERENCE, a single scalar value that always knows how many elements it points to — $numbers_ref->[0] dereferences and indexes in one step via the arrow operator, with no silent information loss.

This is likely the single biggest relief a C developer feels reading Perl: there is no malloc/free pair to manage, and no possibility of a memory leak from a forgotten free, a double-free, or a use-after-free dangling pointer. Perl tracks a reference count on every value and reclaims it automatically the instant nothing refers to it anymore — the programmer never manages memory lifetime directly.

Use-after-free in C is undefined behavior — the freed memory might be reused by something else entirely, producing garbage, a crash, or (worst of all) apparently correct output that later breaks under different conditions. Perl structurally cannot have this bug category: a value is only ever reclaimed once its reference count hits zero, meaning nothing anywhere still holds a reference to it — there is no way to "free early by mistake" the way a stray C free() call allows.

The structure is nearly identical — braces are mandatory in both languages (unlike some C style that permits omitting them for single statements) — with one small spelling difference: C's else if is two words; Perl contracts it to one, elsif.

C's idiomatic loop is index-based, since it has no built-in iteration protocol — you manage the counter and the bounds check yourself. Perl's for my $number (@numbers) iterates the elements directly, with no index variable, no bounds check, and no off-by-one risk to manage.

C declares a fixed, typed parameter list as part of the function signature. Perl subroutines have no parameter list syntax at all — every call's arguments arrive in the special array @_, and my ($x, $y) = @_; is the idiomatic first line unpacking them into named variables. This also means a Perl subroutine can be called with any number of arguments; nothing enforces exactly two the way C's int add(int x, int y) signature does.

C requires the explicit, error-prone <stdarg.h> machinery (va_list/va_start/va_arg/va_end, plus a separately-passed count since C cannot otherwise know how many arguments were passed) to accept a variable number of arguments. Every Perl subroutine already accepts any number of arguments for free via @_ — no special declaration or machinery needed at all.

Perl regular expressions are language syntax, not a library call: =~ applies a pattern directly, and a successful capture group is available immediately afterward as $1. C has no regex support in the language itself; POSIX's <regex.h> exists but requires explicitly compiling a pattern, executing it, and freeing it — three separate steps with their own lifecycle, a genuinely heavier-weight API than Perl's built-in operator.

Perl's s/// substitution operator finds a pattern and replaces it in one operation, resizing the string automatically. The equivalent in C means manually finding the match, computing the new total length, allocating a correctly-sized buffer, and copying the unchanged prefix, the replacement, and the unchanged suffix around it by hand — no single operation covers this the way s/// does.

A C struct has a fixed set of typed fields, declared once and enforced by the compiler for every instance — adding a field at runtime is impossible. Perl's hash-as-record idiom (%point with keys x/y) has no fixed shape at all: fields can be added or removed from any individual hash at runtime, with no compiler enforcing that every "point" hash actually has both an x and a y.

This is a genuine tradeoff, not just a syntax difference. C's struct Point guarantees every instance has the identical memory layout and size, checked at compile time — a real efficiency and correctness guarantee. Perl hashes trade that guarantee for flexibility: two hashes built with the same intent can end up with entirely different sets of keys, since nothing enforces a common "shape" across them the way a C struct type does.

C has no object system at all; the closest simulation is a struct holding data plus function pointers wired up by hand to act as "methods" — genuinely more manual than even Perl's explicit approach. Perl's bless associates a reference (usually a hash reference) with a package name, making it dispatchable via ->; my $self = shift is the idiomatic first line of every method, extracting the invocant the same way a hand-rolled C "method" would take self as its first parameter.

C signals failure through a special return value (here, a NULL file pointer) that the caller must remember to check, plus the global errno for details — nothing forces the check, and a forgotten one silently continues with invalid data. Perl's die raises an exception that propagates until caught by an enclosing eval { } block, with the error message landing in $@ — closer to exception handling in higher-level languages, and harder to silently ignore than a C return-code check.

C's -1 return value means "divide by zero" only by convention documented separately from the code itself — the caller must already know what each error code means. Perl's die "divide by zero\n" carries the actual error message directly, available verbatim in $@ at the catch site, with no separate lookup table or documentation needed to interpret it.

This is a real, well-known Perl surprise with no C parallel at all: the exact same @numbers expression means "how many elements" in scalar/numeric context (my $count = @numbers) but "the list of elements, destructured" in list context (my ($first) = @numbers). C has nothing like this — an expression's meaning never shifts based on the surrounding syntax the way Perl's context sensitivity does.

This is a genuinely surprising Perl-specific rule: the single-character string "0" is FALSE in a boolean context, even though it is a non-empty string — one of only a handful of falsy values in Perl (alongside undef, 0, and the empty string ""). C has nothing resembling this distinction: a C string is simply a pointer, and only a genuinely null/zero pointer or the integer 0 is false in a condition — string CONTENTS never factor into truthiness at all.