Originally published at Perl Weekly 775

Hi there!

I try to keep track of the Perl-related events. You can find them listed at the bottom of each edition of the newsletter and on the events page on the Perl Weekly web site. There you can also find a link to embed the calendar in your calendar program. There are a number of events scheduled for this month. Most of them online, so if your time-zone permits, you can join those events. The big in-person event is at the end of the month The Perl and Raku Conference in Greenville, South Carolina, USA.

In the last couple of weeks I have been using various AI tools extensively. It still needs some hand-holding, but it already writes code that seems to be way better than the average code I've seen. So I wonder, would it be possible to ask one of the AI tools to convert Python libraries to Perl? You know, we have been complaining for many years that companies provide implementation for their SDK/API/client in several language, but not in Perl. We also saw that CPAN could not keep up with the growth of PyPI, npm and the other 3rd party library registries. So maybe some of you would like to explore the idea of converting some of these libraries to Perl using AI.

Finally a personal note, I am planning a trip to Korea and Japan in September-October. If you live there and would have any travel recommendations, I'd love to get that.

Enjoy your week!

--
Your editor: Gabor Szabo.

Articles

Introducing ZuzuScript

Toby Inkster created a programming language which blends a fairly JavaScript-like syntax with fairly Perl-like semantics, and a few other features that he hasn't really seen in many programming languages.

ANNOUNCE: Perl.Wiki V 1.47, JSTree copy V 1.21

Teaching AI About the British Monarchy with MCP

The site already exposes information through a traditional web interface and a JSON API. But those interfaces were designed for humans and developers respectively. MCP gives AI systems a much cleaner integration point.

ANNOUNCE: Perl.Wiki V 1.46 & other news

TPRC Schedule Posted - Time to Submit Lightning Talks

Discussion

Dist::Zilla::PluginBundle::Starter: Use Readme::Brief instead of Pod2Readme?

Perl eval question

Oh, the evil eval.

Perl

This week in PSC (226) | 2026-05-25

The Weekly Challenge

The Weekly Challenge by Mohammad Sajid Anwar will help you step out of your comfort-zone. You can even win prize money of $50 by participating in the weekly challenge. We pick one champion at the end of the month from among all of the contributors during the month, thanks to the sponsor Marc Perry.

The Weekly Challenge - 376

Welcome to a new week with a couple of fun tasks "Chessboard Squares" and "Doubled Words". If you are new to the weekly challenge then why not join us and have fun every week. For more information, please read the FAQ.

RECAP - The Weekly Challenge - 375

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Single Common Word" and "Find K-Beauty" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

Common Beauty

This is an excellent example of how to use Raku's idiomatic style to perform frequency analysis with a very elegant way of using Bag data type and to make use of the %% operator for nice clean checks of divisibility by using Raku's built in primitives instead of having to write complex manual logic.

Perl Weekly Challenge: Week 375

It provides an excellent, straightforward exhibition on how to solve the problems associated with Weekly Challenge 375 in Raku and Perl. In addition to showing off some of the more sophisticated, expressive data types that Raku supports (i.e., Bag) Jaldhar shows how they were able to implement clever, easy-to-read workarounds in Perl to accomplish essentially the same thing.

Common Beauty

This blog post does a great job of examining and comparing the practical solutions using Perl and an advanced version of programming with the J language. The way Jorg has generalised the different types of problems he presented creates a sophisticated solution for someone that will accept any number of bases and/or arrays as inputs, and produces results that would be considered to be of a high standard.

Perl Weekly Challenge 375

This post shows a clear-cut way to address a problem and demonstrate a solid grasp of Perl's function-based capabilities. It uses expressive one-line Perl statements to demonstrate how small, readable, and consistent code can be written to transform data.

A Single Beauty

This is an exemplary work featuring high-quality code that has a high degree of maintainability, uses excellent error check techniques and provides high levels of readability. In addition to using excellent reading technique, his solutions include well-documented logic and complete test suites.

You’ve got to get up every morning…

Packy has created an outstanding multi-language deep dive post comparing different implementations of Raku, Perl, Python, and Elixir. In addition to providing many details about each language's implementation, his approach is to focus on making it easy to read and easy to follow the logic behind each one in spite of their technical complexities. He shows us how we can take the same data structure using different paradigms to create different implementation solutions for the same problem.

Single and beautiful

This solution exemplifies how effective algorithms can be designed, using math formulas as a way of running multiple sets of frequencies over a single array. It’s an example of a very concise method of solving complex state-tracking issues, using the least amount of code as possible while maintaining a high degree of readability.

The Weekly Challenge - 375: Single Common Word

A clear and systematically organised method for resolving this issue is provided within this post, as well as a very easy to read content style, making it simple to see the reasoning behind the solution. Among other things, this post displays a good presentation of example test cases and has a good way of providing technical explanations to both new to experienced software programmers alike.

The Weekly Challenge - 375: Find K-Beauty

This blog post exemplifies well-designed code that solves the "Find K-Beauty" problem in a strong manner. Reinier does an excellent job of providing clear, modular logic and using the least amount of code to implement those solutions. This allows the reader to see how the sliding window method works to find divisors in the number's format.

The Weekly Challenge #375

This post presents an incredibly complete and conversational analysis of the obstacles, illustrated with sophisticated technical knowledge through a thoroughly well-organised, educational format. Robbie's skill at blending solid, production-level Perl code with detailed explanation of the rationale behind it provides readers with an excellent foundation for either becoming familiarized with this form of problem solving or gaining greater depth of understanding regarding the "how" and "why" of idiomatic Perl.

Uncommon Beauty

Roger produced a very thorough, well-organised explanation of the problem, using techniques such as hash frequencies and sliding windows to create solutions that are both clean and accurate. By comparing the two different languages Perl and Scala, Roger shows that they clearly understand how to approach solving problems using multiple programming languages.

The Common Beauty

This is an excellent example of a bilingual coding approach. It contrasts high-level data structures in Python with Perl's more flexible but lower-level data manipulation. Simon offers a clear explanation of the two different languages used to explain how one would move algorithmic logic from one programming paradigm to another by providing step-by-step instructions and side-by-side examples.

Videos

JSON Schema at the Toronto Perl Mongers

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

Events

Exploring Perl Modules + using AI (online)

June 3, 2026

Boston Perl Mongers virtual monthly

June 9, 2026

Paris.pm monthly meeting

June 10, 2026

Purdue Perl Mongers (HackLafayette) - TBA

June 11, 2026

Berlin.pm - Naumanns Biergarten

June 24, 2026

Toronto.pm - June Social Evening

June 25, 2026

The Perl and Raku Conference 2026

June 26-29, 2026, Greenville, SC, USA

You joined the Perl Weekly to get weekly e-mails about the Perl programming language and related topics.

Want to see more? See the archives of all the issues.

Not yet subscribed to the newsletter? Join us free of charge!

(C) Copyright Gabor Szabo
The articles are copyright the respective authors.

Weekly Challenge 375

Each week Mohammad S. Anwar sends out The Weekly Challenge, a chance for all of us to come up with solutions to two weekly tasks. My solutions are written in Python first, and then converted to Perl. Unless otherwise stated, Copilot (and other AI tools) have NOT been used to generate the solution. It's a great way for us all to practice some coding.

Challenge, My solutions

Task 1: Single Common Word

Task

You are given two array of strings.

Write a script to return the number of strings that appear exactly once in each of the two given arrays. String comparison is case sensitive.

My solution

For input from the command, I take two space separated strings to generate the two arrays.

For this task, I start by counting the frequency of words in each list (array in Perl).

from collections import Counter

def single_common_word(array1: list[str], array2: list[str]) -> int:
    freq1 = Counter(array1)
    freq2 = Counter(array2)

I then create two sets of words which only appear once in each list.

    unique1 = {word for word in freq1 if freq1[word] == 1}
    unique2 = {word for word in freq2 if freq2[word] == 1}

Finally, I return the length of the intersection of both sets.

    return len(unique1 & unique2)

The Perl solution follows a similar logic. Using the scalar function will return the number of items in the array.

use Array::Utils 'intersect';

sub main ( $str1, $str2 ) {
    my @array1 = split /\s+/, $str1;
    my @array2 = split /\s+/, $str2;

    my ( %freq1, %freq2 );
    $freq1{$_}++ foreach @array1;
    $freq2{$_}++ foreach @array2;

    my @unique1 = grep { $freq1{$_} == 1 } keys %freq1;
    my @unique2 = grep { $freq2{$_} == 1 } keys %freq2;

    say scalar( intersect( @unique1, @unique2 ) );
}

Examples

$ ./ch-1.py "apple banana cherry" "banana cherry date"
2

$ ./ch-1.py "a ab abc" "a a ab abc"
2

$ ./ch-1.py "orange lemon" "grape melon"
0

$ ./ch-1.py "test test demo" "test demo demo"
0

$ ./ch-1.py "Hello world" "hello world"
1

Task 2: Find K-Beauty

Task

You are given a number and a digit k.

Write a script to find the K-Beauty of the given number. The K-Beauty of an integer number is defined as the number of substrings of given number when it is read as a string has length of k and is a divisor of given number.

My solution

This is relatively straight forward. Python treats integers and strings as different types (and methods that can be called). The first thing I do is convert num to a string called s.

def k_beauty(num: int, k: int) -> int:
    s = str(num)

I then generate all possible substrings of length k and check if it is evenly divisible from the original number. If it is I increment the count variable. At the end, I return the final count value.

    count = 0
    for start in range(len(s) - k + 1):
        if num % int(s[start:start+k]) == 0:
            count += 1

    return count

Perl doesn't care (most of the times) about integers vs strings. This makes the code a little more straight forward.

sub main ( $num, $k ) {
    my $count = 0;

    foreach my $start ( 0 .. length($num) - $k ) {
        if ( $num % substr( $num, $start, $k ) == 0 ) {
            ++$count;
        }
    }

    say $count;
}

Examples

$ ./ch-2.py 240 2
2

$ ./ch-2.py 1020 2
3

$ ./ch-2.py 444 2
0

$ ./ch-2.py 17 2
1

$ ./ch-2.py 123 1
2

Originally published at Perl Weekly 774

Hi there,

I know you all are patiently waiting for the release of Perl v5.44. Recently I joined the mailing list of perl5-porters. You get all the latest update straight in your inbox. This is where I found out, the v5.44 would be out end of next month if everything goes as per the plan. I get excited during this time of the year to see what is new added to the core class feature. I am still waiting for the support of creating roles. I am also aware there are other high priority features in the list. No pressure to Paul Evans and his team, we are happy to see the progress in the language under your guidance.

Well you don't have to wait for the big release to get your hand dirty. For me, I am busy exploring things like Big O Notation, JSON Web Token (JWT), OAuth2, gRPC. There are plenty in the pipelines too.

If you are looking for something new then you should check this out, Aspire in Perl. While going through the post, I came across another gem, OpenTelemetry SDK for Perl, thanks to JJ Atria. It's going in my TODO list. One day, I will take a closer look.

Web development in Perl has seen it all since the CGI Era (1990s). First came PSGI/Plack, the middleware revolution, followed by the rise of frameworks like Catalyst, Dancer2 and Mojolicious. Dave Cross has written a very detailed post about The Long Road From CGI To Containers.

Plenty of posts this week to keep you busy all day, enjoy.

--
Your editor: Mohammad Sajid Anwar.

Announcements

TPRC is about 30 days from now!

Nearly a month from today, TPRC is happening. A quick reminder to everyone about early bird discount. If you are planning to attend TPRC then you must avail the discounts.

Articles

This week in PSC (225) | 2026-05-18

Announcement of 5.43.11 dev release is the hightlight of this week update.

The Camel Cometh

Find out the story behind the support of Perl in Aspire. It is very inspiring and honest story. I wouldn't say, I understood everything but it created an interest inside me. You must checkout yourself.

The Long Road from CGI to Containers

What a journey CGI had. The post reminds me some of my past encounters with CGI, like printing html tags inside the script. Although, it is not recommeded these days in raw form for web development, I am still one of the maintainers of CGI::Simple.

Big O Notation

This story is for all non-computer science background techie who have yet to crack the mystery of time/space complexity. I really enjoyed the journey and I am sure you will love it too.

JWT with Dancer2

JSON Web Token (JWT) is something that came up in discussion many times in the past but I never had chance to look at it in details. Last week finally I found time to get to the bottom of it. This post details how and what is it actually.

OAuth2 with Dancer2

Now OAuth2 is nothing new to many techie but I stayed away from it for so long. I found it too complex topic and kept delaying to explore. Now that I have seen it inside out, it seems like a walk in a park.

Strategy Design Pattern

Every time I talk about design patterns, I get excited like a little boy who found his favourite toy. Whenever I feel down, I pick up my book, Design Patterns in Modern Perl and read a design pattern. My all time favourite is Singleton design pattern. How about yours?

REST vs gRPC

gRPC was something I wanted to explore for a long time. In this post, I shared my investigation so far. I know, I have only scratched the surface and there are still plenty to explore.

CPAN

App::Test::Generator v0.39

Plenty of bug fixes and enhancements in this release as shared by Nigel. The Changes file list the details.

Grants

Maintaining Perl 5 Core (Dave Mitchell): April 2026

PEVANS Core Perl 5: Grant Report for April 2026

I noticed the mention of optional chaining PPC in the report. If it is what I think it is then I am super happy that it is in safe hand now. I can't wait to see the end result. Thank you Paul.

Maintaining Perl (Tony Cook) April 2026

The Weekly Challenge

The Weekly Challenge by Mohammad Sajid Anwar will help you step out of your comfort-zone. You can even win prize money of $50 by participating in the weekly challenge. We pick one champion at the end of the month from among all of the contributors during the month, thanks to the sponsor Marc Perry.

The Weekly Challenge - 375

Welcome to a new week with a couple of fun tasks "Single Common Word" and "Find K-Beauty". If you are new to the weekly challenge then why not join us and have fun every week. For more information, please read the FAQ.

RECAP - The Weekly Challenge - 374

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Count Vowel" and "Largest Same-digits Number" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

Largest Vowel

This is an excellent post describing a different way of using Raku. It demonstrates the effectiveness of Raku by utilising such features as 'gather/take' and powerful sequence grouping to make complex string processing simpler than ever before. In addition to being a great way to learn about Raku, this post is also an opportunity for developers to see how the author has reused existing code to produce a clean, modular program.

All Vowels Are Equal

The post demonstrates an extremely sophisticated work to the challenge. It uses advanced Perl's regex features, look-ahead assertions and the (?{...}) code block.

The Weekly Challenge 374

The code provided is a highly legible and clear way of handling the challenge resolution process, making use of commonly used data structures to simplify complex string processing tasks. It is very pleasing to see this clean, parallelised logic presented in both Perl and Python, which helps improve the maintainability of the two codes and provides a great deal of educational value as well.

Perl Weekly Challenge 374

This fantastic example on how to reduce large scale problems into highly efficient solutions using half-lines of codes, showcases Perl’s ability to allow us to write complex, yet very succinct, solutions of difficult problems. It also serves as a great example of how to use regex backreference in a creative way, using regular expressions to locate and manage repeating patterns while minimising the amount of code required.

Hey, won’t you play…

This post showcases some great, multi-lingual solutions to this week's challenge by providing clean and idiomatic code examples in Perl, Raku, Python, and Elixir. Packy explains the thought process and the differences between lookaheads in regular expressions. This makes the article a great teaching tool for discovering how various languages solve equivalent algorithm problems.

Lots of repetition

Peter provides a well-reasoned and pragmatic assessment of the problem at hand and presents readable, non-complex code. He broke up all vowel characters in the string into separate chunks prior to applying a sub-substring check which provides an excellent example of performance optimisation by successfully processing very long strings with a relatively low number of vowels in that string to produce an acceptable processing time.

The Weekly Challenge - 374: Count Vowel

This post takes an insightful and interesting view of the vowel-counting challenge by making an interesting analogy of programming logic and music theory from the 18th century. The "Prefix/Cell/Suffix" model is a unique and clear technical explanation of the 'use of bitmasks for tracking vowel completion', making the bitmask solution to this challenge feel elegant and well thought out.

The Weekly Challenge - 374: Largest Same-digits Number

In this post, you'll find a brief yet highly efficient method of solving the "Largest Same-digits Number" challenge. The method relies on a single-pass regular expression as an elegant means to perform pattern matching with maximum effectiveness, and exemplifies good understanding of the high performance features of Perl.

The Largest Count

The post show how to solve problems using both Rust and Perl languages. It also demonstrates how one can take advantage of the strengths of each language (type-safe collections in Rust vs concise string searches in Perl) to carry out the tasks, but do so efficiently.

Vowels and numbers

The post explains the need to clearly specify the task requirements for the "Largest Same-digit Number" challenge. It shows that an ambiguous requirement has caused different solutions to develop and serves to remind us that "coding to the examples" can be just as important as "coding to the original problem description."

Rakudo

2026.20 Slangification

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

Events

Toronto.pm - online - JSON Schema: language-agnostic typing / May TPM meeting

May 29, 2026

Exploring Perl Modules + using AI

June 3, 2026

Boston Perl Mongers virtual monthly

June 9, 2026

The Perl and Raku Conference 2026

June 26-29, 2026, Greenville, SC, USA

You joined the Perl Weekly to get weekly e-mails about the Perl programming language and related topics.

Want to see more? See the archives of all the issues.

Not yet subscribed to the newsletter? Join us free of charge!

(C) Copyright Gabor Szabo
The articles are copyright the respective authors.

Weekly Challenge 374

Each week Mohammad S. Anwar sends out The Weekly Challenge, a chance for all of us to come up with solutions to two weekly tasks. My solutions are written in Python first, and then converted to Perl. Unless otherwise stated, Copilot (and other AI tools) have NOT been used to generate the solution. It's a great way for us all to practice some coding.

Challenge, My solutions

Task 1: Count Vowel

Task

You are given a string.

Write a script to return all possible vowel substrings in the given string. A vowel substring is a substring that only consists of vowels and has all five vowels present in it.

My solution

It seems many Team PWC users sent Mohammad "so many emails" when the examples did not match the expected output. As I follow TDD when completing the challenges, I also picked this up.

For this task, I have two loops to generate all possible substrings. The variable start goes from 0 to 5 less than the length of the string. This is because a valid answer needs to have at least five letters. The variable end goes from start + 5 to the length of the string.

I then check if the substr contains each vowel and does not contain any non-vowels. If it does, I add it to the solution list.

def count_vowel(input_string: str) -> list[str]:
    l = len(input_string)
    vowels = ["a", "e", "i", "o", "u"]
    solution = []

    for start in range(l - 4):
        for end in range(start+5, l+1):
            substr = input_string[start:end]
            if (
                all(v in substr for v in vowels) and
                not any(c not in vowels for c in substr)
            ):
                solution.append(substr)

    return solution

The Perl logic uses a variable length instead of end to reflect how the substr function works.

use List::Util 'any';

sub main ($input_string) {
    my $l        = length($input_string);
    my @vowels   = (qw/a e i o u/);
    my @solution = ();

    foreach my $start ( 0 .. $l - 4 ) {
        foreach my $length ( 5 .. $l - $start ) {
            my $substr = substr( $input_string, $start, $length );

            if ( $substr !~ /^[aeiou]+$/ ) {
                next;
            }

            if ( any { index( $substr, $_ ) == -1 } @vowels ) {
                next;
            }

            push @solution, $substr;
        }
    }

    say "(" . join( ", ", map { qq{"$_"} } @solution ) . ")";
}

Examples

The order in the output differs from the examples.

$ ./ch-1.py aeiou
("aeiou")

$ ./ch-1.py aaeeeiioouu
("aaeeeiioou", "aaeeeiioouu", "aeeeiioou", "aeeeiioouu")

$ ./ch-1.py aeiouuaxaeiou
("aeiou", "aeiouu", "aeiouua", "eiouua", "aeiou")

$ ./ch-1.py uaeiou
("uaeio", "uaeiou", "aeiou")

$ ./ch-1.py aeioaeioa
()

Task 2: Largest Same-digits Number

Task

You are given a string containing 0-9 digits only.

Write a script to return the largest number with all digits the same in the given string.

My solution

I always look at the examples to fill in answers that aren't mentioned in the task description. One thing I wasn't sure if the numbers had to be consecutive or not. In this instance, the examples don't help answer that question. I made the decision that they didn't need to be.

My first thought was to sort by the frequency of the numbers and the number if it had the same frequency. But this would work with numbers like 100 (where 0 appears most often).

The solution I came up with was to count the frequency of each number using the Counter function. I then loop through the dict (hash in Perl) to find the highest number.

from collections import Counter
import re

def largest_number(input_string) -> int:
    if not re.search(r'^\d+$', input_string):
        raise ValueError("String should only contain numbers")

    largest_number = 0
    freq = Counter(input_string)

    for digit, count in freq.items():
        number = int(digit * count)
        if number > largest_number:
            largest_number = number

    return largest_number

The Perl solution follows the same logic.

Examples

$ ./ch-2.py 6777133339
3333

$ ./ch-2.py 1200034
4

$ ./ch-2.py 44221155
55

$ ./ch-2.py 88888
88888

$ ./ch-2.py 11122233
222

One of the defining characteristics of a good programmer is an instinct for keeping implementation details in the correct layer of an application.

That sounds abstract, but it turns out to explain a huge amount of the progress we’ve made in software development over the last twenty-five years.

And nowhere is that clearer than in Perl web development.

Many of us who built web applications during the dotcom boom spent years learning this lesson the hard way.

We wrote CGI programs that:

• parsed HTTP requests
• generated HTML by hand
• connected directly to databases
• embedded SQL inline
• mixed business logic with presentation
• relied on Apache behaviour
• assumed specific filesystem layouts
• and often only worked on one particular server configuration

It all worked. Until it didn’t.

The history of Perl web development is, in many ways, the history of gradually moving implementation details into more appropriate architectural layers.

The Early CGI Years

Early Perl CGI applications were often a single giant script.

You’d open a file and see:

• request handling
• authentication
• HTML generation
• SQL queries
• business logic
• configuration
• deployment assumptions

…all mixed together in a glorious ball of mud.

Something like this:

#!/usr/bin/perl

use CGI;
use DBI;

my $cgi = CGI->new;

print $cgi->header;
print "<html><body>";

my $dbh = DBI->connect(
  "dbi:mysql:test",
  "user",
  "pass"
);

my $sth = $dbh->prepare(
  "select * from users where id = ?"
);

$sth->execute($cgi->param('id'));

while (my $row = $sth->fetchrow_hashref) {
  print "<h1>$row->{name}</h1>";
}

print "</body></html>";

At the time, this felt perfectly normal.

And to be fair, it was a huge step forward from static HTML sites.

But the design had a fundamental problem:

Everything knew too much about everything else.

The application logic knew:

• how HTTP worked
• how HTML worked
• how Apache launched CGI scripts
• how the database worked
• how the operating system was configured

Every concern leaked into every other concern.

That made systems:

• hard to test
• hard to reuse
• hard to deploy
• hard to scale
• and terrifying to change

The First Big Lesson: Put Logic in Libraries

One of the first signs of a developer maturing is the realisation that application logic should live in reusable modules, not in front-end scripts.

Instead of this:

if ($user->{status} eq 'gold') {
  $discount = 0.2;
}

being embedded directly in a CGI script, it becomes:

my $discount = $user->discount_rate;

That sounds like a small change, but architecturally it’s enormous.

Now the business logic lives in a library.

And once that happens, several good things follow automatically.

Multiple Interfaces Become Possible

If the logic is in modules, then:

• a web front-end
• a CLI tool
• a REST API
• a cron job
• a queue worker

…can all use the same underlying code.

The interface layer becomes thin.

The application itself becomes independent of how users interact with it.

That’s a huge increase in flexibility.

Testing Becomes Easier

Testing CGI scripts was always awkward.

Testing modules is straightforward.

You can instantiate objects, call methods, and inspect results without needing a web server or HTTP requests.

The easier code is to test, the more likely it is to be tested.

And tested code tends to survive longer.

Deployment Becomes Safer

Once the core behaviour is isolated from the interface layer, replacing the interface becomes far less risky.

You can redesign the UI without rewriting the application.

That separation is one of the foundations of maintainable software.

The PSGI Revolution

The next big architectural leap in Perl web development came with PSGI and Plack.

Younger developers may not fully appreciate how painful web deployment used to be.

In the early 2000s, moving an application between hosting environments could require substantial rewrites.

• A CGI application worked one way.
• A mod_perl application worked another way.
• FastCGI had its own quirks.
• Embedded Apache handlers behaved differently again.

Many Perl developers spent years repeatedly rewriting applications simply because deployment environments changed.

That was madness.

The deployment model is an operational concern.

It should not affect application architecture.

PSGI fixed this by defining a standard interface between web applications and web servers.

The core idea was beautifully simple:

A web application is just a function that receives an environment and returns a response.

Once that abstraction existed, applications no longer cared whether they were running:

• as CGI
• under mod_perl
• inside FastCGI
• under Starman
• behind nginx
• on a development laptop
• or inside a cloud container

The deployment details moved down a layer.

Exactly where they belonged.

This was one of the most important architectural improvements Perl web development ever made.

And it reflected a broader truth:

Good abstractions stop lower-level implementation details leaking upward.

The Transitional Era: FatPacker and cpanfile

There was also an interesting intermediate stage between traditional Perl deployments and full containerisation.

For years, one of the hardest parts of deploying Perl applications was dependency management.

You’d move an application to a new server and discover:

• the wrong module version
• missing XS libraries
• incompatible Perl versions
• or an entire dependency tree that worked perfectly on the developer’s machine and nowhere else

Large parts of Perl deployment culture evolved around coping with this problem.

Tools like cpanfile improved things by making dependencies explicit and reproducible.

Instead of vaguely documenting requirements in a README, applications could formally declare:

requires 'Dancer2';
requires 'DBIx::Class';
requires 'Template';

That may seem obvious now, but it was a major improvement in deployment reliability.

Then tools like App::FatPacker went even further by packaging dependencies directly alongside applications.

Instead of relying on the target server’s Perl environment, applications could carry much of their runtime context with them.

These tools didn’t completely solve deployment portability:

• system libraries still mattered
• Perl versions still mattered
• operating system differences still mattered

…but they represented an important shift in thinking.

The industry was gradually realising that:

• deployment environments were part of the application
• reproducibility mattered
• and infrastructure assumptions needed to be controlled

Containers eventually pushed this idea to its logical conclusion by packaging not just Perl dependencies, but the entire runtime environment.

In hindsight, tools like cpanfile and FatPacker were stepping stones toward modern container-based deployment models.

Containers Are the Same Idea Again

Docker and containers are simply the same architectural principle repeated one layer lower.

Before containers, deployments were often fragile and highly environment-specific.

Applications depended on:

• particular Linux distributions
• specific Perl versions
• installed system libraries
• hand-configured servers
• undocumented setup steps

Developers became experts in “works on my machine”.

Operations teams became experts in swearing.

Containers changed the model.

Instead of deploying:

• source code

…you deploy:

• a complete runtime environment

Now the application no longer cares whether it runs:

• on bare metal
• on a VPS
• in Kubernetes
• in ECS
• in Cloud Run
• or on someone’s laptop

Again:

• infrastructure concerns move downward
• application concerns stay upward

The boundaries become cleaner.

The Pattern Repeats Everywhere

Once you notice this pattern, you see it throughout software engineering.

Templates

Template systems separate:

• presentation

from

• application logic

HTML should not contain database code.

Business logic should not contain giant blobs of HTML.

ORMs and Database Layers

DBI separates applications from database engines.

ORMs separate applications from raw SQL structure.

Again:

• implementation details move downward

Configuration

Configuration belongs outside code.

Deployment-specific values should not be embedded in applications.

APIs

Clients should not care whether data comes from:

• PostgreSQL
• Redis
• another service
• a queue
• flat files
• or magic elves

That’s the implementation’s problem.

The Goal Is Not Abstraction for Its Own Sake

Of course, experienced developers also know that abstractions can become ridiculous.

Some abstractions simplify systems.

Others merely hide complexity behind six additional layers of YAML.

Joel Spolsky’s “Law of Leaky Abstractions” remains painfully relevant.

The goal is not abstraction itself.

The goal is to isolate genuinely volatile details.

Good abstractions protect systems from change.

Bad abstractions merely obscure reality.

The Real Skill

The deeper lesson here is that software architecture is largely about deciding:

“What belongs where?”

Experienced developers develop an instinct for:

• which details are likely to change
• which layers should know about which concerns
• and where boundaries should exist

That instinct is often more important than language choice, frameworks, or technology stacks.

And if you spent the early 2000s rewriting CGI applications to run under mod_perl, you probably learned that lesson the hard way.

The post The Long Road from CGI to Containers first appeared on Perl Hacks.