Perl (5.42)

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses Perl in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 28/100 · Ecosystem coupling 53/100 · Engineering readiness 65/100

1.1 Core coupling

1.1.1 Type

  • ❌ No type system: Dynamic, weakly typed
  • ❌ TIMTOWTDI: “There’s More Than One Way To Do It” creates inconsistency
  • ⚠️ Sigils: $scalar, @array, %hash provide some structure
  • ❌ Context-sensitive: Same code behaves differently in scalar/list context
  • ⚠️ Moose: Object system add-on provides types, not core
  • ⚠️ A method call resolves on the run-time object: $obj->method looks the name up in the object’s class when the call runs, so a rename breaks a caller only at run time (T3)
  • ❌ Regular expressions: Write-only code, couples understanding to expertise

1.1.2 Construction

  • ❌ Bless: Primitive object system, bless {} is manual
  • ❌ Core class syntax is experimental: use feature 'class' provides a core object system, but the implementation is still experimental, so a project cannot rely on it
  • ⚠️ Moose/Moo: Modern OOP libraries improve this significantly
  • ❌ Hash-based objects: No encapsulation enforcement
  • ❌ Global variables: $_, @_, %ENV everywhere
  • ❌ **Implicit $_**: Default variable creates hidden dependencies
  • ❌ Package variables: Global state pervasive

1.1.3 Memory

  • ✅ Reference counting: Deterministic deallocation
  • ⚠️ Cyclic references: Leak unless broken manually
  • ✅ Automatic: No manual malloc/free

1.1.4 Error

  • ❌ Die/eval: Exceptions not typed, eval catches everything
  • ❌ Return undef: Many functions return undef on error, silent failures
  • ⚠️ $!: Global error variable couples error state
  • ❌ Signatures declare parameters only: A sub’s signature does not state the errors it may raise, so the failure channel is invisible at the call

1.1.5 Concurrency

  • ⚠️ Threads: Available but discouraged, heavyweight
  • ⚠️ Fork: Process-based concurrency common
  • ❌ No modern concurrency: No async/await, no actors
  • ❌ Shared state: Manual locking, error-prone

1.1.6 Platform

  • ✅ No company owns the language: Perl 5 is released by the Perl 5 Porters under the Artistic License and the GNU General Public License, and no vendor controls it
  • ✅ The interpreter is portable: The same C source builds on Linux, macOS, the BSDs, Windows through Strawberry Perl, and OpenVMS
  • ✅ CPAN is vendor-neutral: The archive is mirrored worldwide and serves any Perl distribution, not one vendor’s package service
  • ✅ A base interpreter ships with most Unix systems: Many Linux distributions and the BSDs install perl as part of the base system, so a script needs no extra platform

1.1.7 Trade-offs (not coupling)

  • Regexes are woven into the grammar: Pattern matching is syntax rather than a library, which makes text handling concise and the language hard to read — a syntax decision, not a coupling mechanism
  • Sigils prefix every name: The leading $, @, or % encodes the noun in the identifier, a readability trade expressed in the name rather than in a type system
  • Scalars carry both a number and a string: The dual-valued scalar is why == and eq are separate operators, a convenience whose cost falls on every comparison
  • Backward compatibility is the default: Decades of behaviour remain in the language, and use strict and use warnings recover discipline one file at a time — a compatibility cost, not a forced dependency
  • The successor was released as another language: Raku was developed separately from Perl 5, so Perl 5 continues on its own line — a project decision, not a coupling

1.2 Ecosystem coupling

1.2.1 Performance

  • ⚠️ Interpreted: Slower than compiled, and the reference interpreter has no JIT
  • ✅ Regex engine: Very fast for text processing
  • ❌ Memory usage: Higher than C, lower than Ruby/Python

1.2.2 Ecosystem

  • ✅ CPAN: Comprehensive Perl Archive Network, massive
  • ⚠️ Aging: Fewer new modules than modern ecosystems
  • ⚠️ IDE support: Limited compared to modern languages
  • ✅ CPAN minus: Great dependency testing
  • ⚠️ Tooling dated: Perldoc, prove, but aging

1.2.3 Evolution

  • ❌ Perl 6 → Raku: Split into separate language
  • ⚠️ Perl 5 stable: Very conservative, few changes
  • ❌ Declining use: Community shrinking

1.2.4 Domain

  • ✅ Excellent for text processing: Regex, sed/awk replacement
  • ✅ Good for system admin: DevOps, automation
  • ⚠️ Web declining: CGI era passed, PSGI exists
  • ❌ Not for applications: Modern alternatives better
  • ✅ Bioinformatics: BioPerl still used

1.2.5 Learning

  • ❌ Steep: Sigils, context, special variables
  • ❌ Write-only code: Hard to read others’ code
  • ⚠️ Good docs: Perldoc comprehensive
  • ❌ Many gotchas: $_, context, references

1.2.6 Syntax

  • ❌ Sigils everywhere: $@% visual noise
  • ❌ Context sensitivity: Same code different results
  • ⚠️ Powerful: Can express complex logic concisely
  • ❌ Punctuation soup: Special variables like $!, $?, $@

1.2.7 Testing

  • ✅ Test::More: Good testing framework
  • ✅ Prove: Test runner works well
  • ⚠️ Debugger: Perl -d works but basic
  • ✅ Testing culture: CPAN requires tests

1.2.8 Security

  • ✅ Taint mode: Tracks untrusted data
  • ⚠️ Type confusion: Dynamic typing allows anything
  • ⚠️ Eval risks: Code injection if used carelessly
  • ✅ No memory bugs: GC prevents use-after-free

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Builds are not byte-reproducible by default.
  • ❌ Dependencies resolve without a lock by default.

1.3.2 Supply chain

  • ⚠️ Published packages carry no signed provenance by default.

1.3.3 Observability

  • ⚠️ No stable tracing and metrics standard.

1.3.4 Feedback

  • ✅ No charged mechanism in this dimension.

1.3.5 Interop

  • ⚠️ No maintained portable target.

1.3.6 Governance

  • ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ❌ Interpreted by default: the slowest class in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ⚠️ Moderate training data: models write it competently, with measurable language-specific weakness [7].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check ✅ −15
T2 weak static — 0
T3 dynamic/duck dispatch ✅ −8
T4 no sum types ✅ −4
T5 no generics ✅ −4
T6 no namespaces ✅ −8
T7 type erasure/reflection — 0
T8 operator overloading — 0
T9 inheritance required for polymorphism ✅ −4
T10 no null-safety ✅ −8
T11 no module boundary ✅ −8
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary ✅ −4
Type subtotal −15 (−71)
Construction C1 global mutable state by default ✅ −15
C2 no immutability by default ✅ −4
C3 constructors coupled to allocation — 0
C4 no constructor/validation ✅ −4
Construction subtotal −15 (−23)
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses — 0
M3 no RAII ✅ −4
M4 no ownership model ✅ −8
Memory subtotal −12
Error Er1 no structured path ✅ −15
Er2 unchecked exceptions only ✅ −8
Er3 errors ignored/non-exhaustive ✅ −4
Er4 no composable result type ✅ −4
Error subtotal −15 (−31)
Concurrency K1 GIL/no parallel ✅ −15
K2 shared mutable state default ✅ −8
K3 manual sync no race detection ✅ −8
K4 no structured concurrency ✅ −4
K5 no primitives — 0
Concurrency subtotal −15 (−35)
Platform P1 cannot function outside one vendor/domain — 0
P2 single-vendor but other uses — 0
P3 legacy/discontinued platform — 0
Platform subtotal 0

Core Dimensions score: 28/100 — total cost = −72 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT ✅ −8
R2 GC pauses — 0
R3 JIT warmup — 0
Performance subtotal −8
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued — 0
Ec4 proprietary — 0
Ec5 platform-locked tooling — 0
Ec6 monoculture — 0
Ec7 legacy burden — 0
Ecosystem subtotal 0
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in — 0
D2 poor domain fit — 0
D3 framework forces architecture — 0
Domain subtotal 0
Learning L1 steep ✅ −8
L2 large surface/multi-paradigm — 0
L3 sparse docs — 0
Learning subtotal −8
Syntax S1 verbose — 0
S2 inconsistent ✅ −8
S3 punctuation-heavy ✅ −4
Syntax subtotal −12
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors ✅ −4
Testing subtotal −4
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk ✅ −8
Q3 known vulnerability/injection ✅ −8
Security subtotal −15 (−16)

Meta Dimensions score: 53/100 — total cost = −47 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible ✅ −8
Y2 dependencies not pinned ✅ −8
Reproducibility subtotal −15 (−16)
Supply chain Y3 no signed provenance ✅ −8
Y4 registry without namespacing — 0
Supply chain subtotal −8
Observability Y5 no stable tracing standard ✅ −8
Y6 no structured logging — 0
Observability subtotal −8
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis — 0
Feedback subtotal 0
Interop Y9 no foreign-function interface — 0
Y10 no portable target ✅ −4
Interop subtotal −4
Governance Y11 single-vendor governance — 0
Y12 closed specification — 0
Governance subtotal 0

Readiness Dimensions score: 65/100 — total cost = −35 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: Perl is era before static analysis was common. TIMTOWTDI creates inconsistent coupling patterns. Context sensitivity couples behavior to call site. Implicit $_ creates hidden dependencies. Main strength: CPAN ecosystem, regex power, system administration tasks. Main weakness: “write-only” code couples maintenance to original author’s knowledge.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
Perl Foundation, “Perl documentation.” Perl Foundation, 2024. Available: https://perldoc.perl.org/
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[7]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.