Musical Interlude

The movie version of Wicked is in theaters right now, so I am reminded of the song For Good -- but I'm gonna link to the Broadway version, because I'm classy like that. It's relevant to programming in Perl because "I don't know if I've been changed for the better, but I have been changed for good." For part two, Lido Shuffle by Boz Scaggs.

Task 1: Good Substrings

The Task

You are given a string. Write a script to return the number of good substrings of length three in the given string. A string is good if there are no repeated characters.

• Example 1: Input $str = "abcaefg", Output: 5
  • Good substrings of length 3: abc, bca, cae, aef and efg
• Example 2: Input: $str = "xyzzabc", Output: 3
• Example 3: Input: $str = "aababc", Output: 1
• Example 4: Input: $str = "qwerty", Output: 4
• Example 5: Input: $str = "zzzaaa", Output: 0

The Think-y Part

There's probably a regular expression for this, but I'm not going to find it. Do the simplest thing that works: take three characters at a time and see if they're different.

The Code-y Part

sub goodSubstring($str)
{
    my $good = 0;
    my @s = split(//, $str);
    for ( 0 .. $#s - 2 )
    {
        my ($first, $second, $third) = @s[$_, $_+1, $_+2];
        $good++ if ( $first ne $second && $first ne $third && $second ne $third );
    }
    return $good;
}

Notes:

• Start by turning the string into a list of characters. It could be done with substr, but that would be untidy.
• @s[$_, $_+1, $_+2] -- With a nod to readability, I'll extract three consecutive characters with an array slice. It occurs to me that I'll always have two of the next three characters in hand at the bottom of the loop, so doing a complete splice every time could probably be optimized, but I declare it "good" enough.
• Since there's exactly three characters in play, check for uniqueness in the most obvious way.

Task 2:Shuffle Pairs

The Task

If two integers A <= B have the same digits but in different orders, we say that they belong to the same shuffle pair if and only if there is an integer k such that A = B * k. k is called the witness of the pair. For example, 1359 and 9513 belong to the same shuffle pair, because 1359 * 7 = 9513.

Interestingly, some integers belong to several different shuffle pairs. For example, 123876 forms one shuffle pair with 371628, and another with 867132, as 123876 * 3 = 371628, and 123876 * 7 = 867132.

Write a function that for a given $from, $to, and $count returns the number of integers $i in the range $from <= $i <= $to that belong to at least $count different shuffle pairs.

• Example 1:
  • Input: $from = 1, $to = 1000, $count = 1
  • Output: 0
  • There are no shuffle pairs with elements less than 1000.

• Example 2:

  • Input: $from = 1500, $to = 2500, $count = 1
  • Output: 3
  • There are 3 integers between 1500 and 2500 that belong to shuffle pairs.
    • 1782, the other element is 7128 (witness 4)
    • 2178, the other element is 8712 (witness 4)
    • 2475, the other element is 7425 (witness 3)

• Example 3:

  • Input: $from = 1_000_000, $to = 1_500_000, $count = 5
  • Output: 2
  • There are 2 integers in the given range that belong to 5 different shuffle pairs.
    • 1428570 pairs with 2857140, 4285710, 5714280, 7142850, and 8571420
    • 1429857 pairs with 2859714, 4289571, 5719428, 7149285, and 8579142

• Example 4:

  • Input: $from = 13_427_000, $to = 14_100_000, $count = 2
  • Output: 11
  • 6 integers in the given range belong to 3 different shuffle pairs,
  • 5 integers belong to 2 different ones.

• Example 5:

  • Input: $from = 1030, $to = 1130, $count = 1
  • Output: 2
  • There are 2 integers between 1020 and 1120 that belong to at least one shuffle pair:
    • 1035, the other element is 3105 (witness k = 3)
    • 1089, the other element is 9801 (witness k = 9)

Deliberations

It takes a minute to digest this one.

I first wondered if there's some algebraic number theory trick that would cut the search space way down, but that made my head hurt, so I moved to doing what computers do best: grinding through a lot of possibilities.

A bad first thought was to try all combinations of the digits, but that's going to die an excruciating slow death on the crucifix of combinatorics, not to mention that we'd be completely wasting our time on all but a few combinations.

A better thought is to look only at the multiples of a given number. There are at most 8 multiples of a number in play: the 10th would add a digit, and therefore can't possibly be a reordering. Examples 3 and 4 have a lot of numbers to grind through, but how long can it take, really? It's one banana, Michael; how much could it cost, ten dollars?

How will I decide that a number is a re-ordering? I think I'll reduce each number to a canonical form where the digits are sorted, then use string compare to see if a multiple has the same canonical form.

To the bat-editor, Robin!

First, a little function to turn a number into a canonical form with its digits in sorted order. Turn the number into a list of digits, sort, and then join the digits back into a string.

sub canonical($n)
{
    join("", sort split(//, $n));
}

Now the main course. I'll want to examine every number in the range $from to $to, inclusive. For each number, I'll want to examine its multiples to see if they have the same digits. I need to count the ones that work so that I can check that there are at least $count of them.

sub shufflePair($from, $to, $count)
{
    my $answer = 0;

    for my $n ( $from .. $to )
    {
        my $base = canonical($n);
        my $max = (9 x length($n))+0;
        my $pair = 0;
        for ( 2 .. 9 )
        {
            my $multiple = $n * $_;

            next if $multiple > $max
                 || index($base, substr($multiple,  0, 1)) < 0
                 || index($base, substr($multiple, -1, 1)) < 0;

            if ( canonical($multiple) eq $base )
            {
                $pair++;
            }
        }
        $answer++ if $pair >= $count;
    }
    return $answer;
}

Notes:

• my $base = canonical($n) -- hang on to this for comparison.
• my $max = (9 x length($n))+0; -- An optimization. The maximum number we need to be concerned with is one that has the same number of digits, but is all 9s. For example, if $n is 480, then we are dealing with 3-digit numbers, so the largest possible is 999. That's less than 480*3=1440, so we don't have to examine any of the multiples beyond 480*2.
• for ( 2..9 ) -- These are the only multiples of $n that could possibly have the same number of digits.
• next if ... -- Besides the check on $max, we can make cheap checks on a single digit. If the first or last digit isn't one of the possible digits, we can avoid the overhead of canonical(), which isn't horrendous, but it does involve allocating lists and a sort.
• canonical($multiple) eq $base -- This string compare is where we decide if we have a shuffle pair.
• $answer++ if $pair >= $count -- We increment the answer if this number has at least $count shuffle pairs.

This solution takes a few seconds to run the examples. My optimizations to bail early in many cases cut the run time approximately in half (from about 8 seconds to about 4.5).

Introducing PAGI: Async Web Development for Perl

TL;DR: PAGI (Perl Asynchronous Gateway Interface) is a new specification for async Perl web applications, inspired by Python's ASGI. It supports HTTP, WebSockets, and Server-Sent Events natively, and can wrap existing PSGI applications for backward compatibility.

The Problem

Modern web applications need more than traditional request-response cycles. Real-time features like live notifications, collaborative editing, and streaming data require persistent connections. This means:

• WebSockets for bidirectional communication
• Server-Sent Events for efficient server push
• Streaming responses for large payloads
• Connection lifecycle management for resource pooling

PSGI, Perl's venerable web server interface, assumes a synchronous world. While frameworks like Mojolicious have built async capabilities on top, there's no shared standard that allows different async frameworks and servers to interoperate.

PAGI aims to fill that gap.

What is PAGI?

PAGI defines a standard interface between async-capable Perl web servers and applications. If you're familiar with Python's ecosystem, think of it as Perl's answer to ASGI.

A PAGI application is an async coderef with three parameters:

use Future::AsyncAwait;
use experimental 'signatures';

async sub app ($scope, $receive, $send) {
    # $scope   - connection metadata (type, headers, path, etc.)
    # $receive - async coderef to get events from the client
    # $send    - async coderef to send events to the client
}

The $scope->{type} tells you what kind of connection you're handling:

A Simple HTTP Example

Here's "Hello World" in raw PAGI:

use Future::AsyncAwait;

async sub app ($scope, $receive, $send) {
    die "Unsupported: $scope->{type}" if $scope->{type} ne 'http';

    await $send->({
        type    => 'http.response.start',
        status  => 200,
        headers => [['content-type', 'text/plain']],
    });

    await $send->({
        type => 'http.response.body',
        body => 'Hello from PAGI!',
        more => 0,
    });
}

Run it:

pagi-server --app app.pl --port 5000
curl http://localhost:5000/
# => Hello from PAGI!

The response is split into http.response.start (headers) and http.response.body (content). This separation enables streaming—send multiple body chunks with more => 1 before the final more => 0.

WebSocket Support

WebSockets are first-class citizens in PAGI:

async sub app ($scope, $receive, $send) {
    if ($scope->{type} eq 'websocket') {
        await $send->({ type => 'websocket.accept' });

        while (1) {
            my $event = await $receive->();

            if ($event->{type} eq 'websocket.receive') {
                my $msg = $event->{text} // $event->{bytes};
                await $send->({
                    type => 'websocket.send',
                    text => "Echo: $msg",
                });
            }
            elsif ($event->{type} eq 'websocket.disconnect') {
                last;
            }
        }
    }
    else {
        die "Unsupported: $scope->{type}";
    }
}

The event loop pattern is consistent across all connection types: await events from $receive, send responses via $send.

PSGI Compatibility

One of PAGI's key features is backward compatibility with PSGI. The PAGI::App::WrapPSGI adapter lets you run existing PSGI applications on a PAGI server:

use PAGI::App::WrapPSGI;

# Your existing Catalyst/Dancer/Plack app
my $psgi_app = MyApp->psgi_app;

my $wrapper = PAGI::App::WrapPSGI->new(psgi_app => $psgi_app);
$wrapper->to_app;

The wrapper handles all the translation: building %env from PAGI scope, collecting request bodies, and converting responses back to PAGI events.

This means you can:

• Run legacy applications on a PAGI server
• Add WebSocket endpoints alongside existing routes
• Migrate incrementally from PSGI to PAGI
• Share connection pools between old and new code

PAGI::Simple Micro-Framework

For rapid development, PAGI ships with a micro-framework inspired by Express.js:

use PAGI::Simple;

my $app = PAGI::Simple->new(name => 'My API');

$app->get('/' => sub ($c) {
    $c->text('Hello, World!');
});

$app->get('/users/:id' => sub ($c) {
    my $id = $c->path_params->{id};
    $c->json({ user_id => $id });
});

$app->post('/api/data' => sub ($c) {
    my $data = $c->json_body;
    $c->json({ received => $data, status => 'ok' });
});

$app->to_app;

WebSockets are equally clean:

$app->websocket('/chat' => sub ($ws) {
    $ws->on(message => sub ($data) {
        $ws->broadcast("Someone said: $data");
    });
});

PAGI::Simple includes:

• Express-style routing with path parameters
• JSON request/response helpers
• Session management
• Middleware support (CORS, logging, rate limiting, etc.)
• Static file serving
• WebSocket rooms and broadcasting
• SSE channels with pub/sub

Current Status

PAGI is currently in early beta. The test suite passes, the examples work, but it hasn't been battle-tested in production.

What exists today:

• Complete PAGI specification
• Reference server implementation (PAGI::Server)
• PAGI::Simple micro-framework
• 13 example applications
• PSGI compatibility layer
• 483 passing tests

What it needs:

• Developers willing to experiment and provide feedback
• Real-world testing
• Framework authors interested in building on PAGI
• Performance profiling and optimization

Getting Started

git clone https://github.com/jjn1056/pagi.git
cd pagi
cpanm --installdeps .
prove -l t/

# Try the examples
pagi-server --app examples/01-hello-http/app.pl --port 5000
pagi-server --app examples/simple-01-hello/app.pl --port 5000

Why This Matters

Perl has excellent async primitives (IO::Async, Future::AsyncAwait), but no shared specification for async web applications. Each framework implements its own approach, which limits interoperability.

PAGI provides that shared foundation. By standardizing on a common interface:

• Servers can focus on performance and protocol handling
• Frameworks can focus on developer experience
• Middleware becomes portable across implementations
• The ecosystem can grow together rather than in isolation

If you're interested in the future of async Perl web development, I'd love your feedback. Check out the repository, try the examples, and let me know what you think.

Repository: github.com/jjn1056/pagi

PAGI is not yet on CPAN. It's experimental software—please don't use it in production unless you really know what you're doing.

Originally published at Perl Weekly 749

Hi there!

The big announcement is that Mohammad Sajid Anwar who runs The Weekly Challenge and who is the other editor of the Perl Weekly newsletter, has published his first book called Design Patterns in Modern Perl. You can buy it both on Amazon and on Leanpub. Leanpub gives you the option to change the price so you can also use this opportunity to give a one-time donation to him. As far as I know, Leanpub also gives a much bigger part of the price to the author than Amazon does. You can also ask them to send the book to your Kindle or you can upload it yourself. I already bought it and started to read it. Now you go, buy the book!

In just a few hours we are going to have the online meeting Perl Code-reading and testing. You can still register here.

Perl on WhatsApp: I am part of a lot of WhatsApp groups about Python and Rust and other non-tech stuff. I figured I could create one for Perl as well. If you are interested join here. There are also two groups on Telegram. One is called Perl 5 that has 141 members and the other one is called Perl Maven community that I created, because I did not know about the other one. The latter has 59 members. You are invited to join any or all of these channels.

I started a poll in the Perl Community Facebook group. There are already 63 votes. It would be nice if you answered too.

Enjoy your week!

--
Your editor: Gabor Szabo.

Announcements

Design Patterns in Modern Perl

Manwar, congratulations! Everyone else, go buy the book! (comments)

Articles

ANNOUNCE: Various updated wikis, including Perl.Wiki

Dotcom Survivor Syndrome – How Perl’s Early Success Created the Seeds of Its Downfall

I like the sentiment, but as one of the commenters pointed out there was PHP as well.

GitHub and the Perl License

In a nutshell, if you'd like to use 'the Perl license' you probably should include two separate license files. (comments)

Showcase: Localised JSON Schema validation in Perl + JavaScript (CodePen demo included!)

A small project that might interest anyone in dealing with form validation, localisation, and JSON Schema in their Perl web applications / REST API.

Web

Catalyst::Request body issues with the file position pointer

For those using the Perl Catalyst web framework in ways involving structured request bodies (e.g. API POSTs)...

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 Lance Wicks.

The Weekly Challenge - 350

Welcome to a new week with a couple of fun tasks "Good Substrings" and "Shuffle Pairs". 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 - 349

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Power String" and "Meeting Point" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

TWC349

Both solutions use a straightforward, single-pass approach that is perfectly suited for the problem. They process the input string only once, making them very efficient (O(n)) and demonstrating a solid grasp of fundamental algorithmic thinking.

Power Pointing

The post is an excellent, practical demonstration of Raku's expressiveness and built-in functionality. It successfully showcases how Raku allows a programmer to transition from a straightforward, imperative approach to a concise, idiomatic, and highly readable functional solution.

More complex than it has to be

The post presents a fascinating and honest case study of over-engineering. Bob deliberately explores a complex, "enterprise-grade" solution to a simple problem, contrasting it with the obvious simple solution.

Meeting Strings

This is an exceptionally well-crafted post. It demonstrates a deep understanding of Raku's idioms and standard library, transforming simple problems into masterclasses in concise, expressive, and functional programming.

moving and grepping

This is an exemplary post that demonstrates exceptional technical breadth, deep practical knowledge, and a clear, effective pedagogical style. It transcends being a mere solution set and serves as a masterclass in polyglot programming and database extensibility.

Perl Weekly Challenge 349

The post demonstrates both deep Perl knowledge and strong pedagogical skills, making complex solutions accessible while showcasing advanced language features.

Power Meets Points

This post demonstrates expert-level Perl programming with deep language knowledge and thoughtful engineering considerations. Matthias combines elegant solutions with practical performance analysis.

The Power of String

This is a high-quality technical post that successfully demonstrates how to solve the same problems in multiple programming languages while maintaining algorithmic consistency.

Powering to the origin

This post demonstrates creative problem-solving with elegant regex decrementing for Task 1 and a clever eval-based dispatch system for Task 2. Peter shows strong analytical thinking by carefully distinguishing between final-position and intermediate-position checks, and makes practical engineering trade-offs between cleverness and performance.

The Weekly Challenge #349

This is a well-structured, professional-grade solution with excellent documentation and robust code organization. Robbie demonstrates strong analytical thinking by carefully addressing potential ambiguities in the problem statement and explicitly warning against common algorithmic pitfalls.

Power Meeting

Roger demonstrates strong analytical skills by questioning the problem statement itself and providing robust solutions for different interpretations, showing both practical implementation skills and deeper algorithmic thinking.

Power Meeting

This is a clean, practical, and well-explained approach to the weekly challenges. Simon demonstrates strong fundamentals with a clear, step-by-step problem-solving methodology.

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

Events

Perl Maven online: Code-reading and testing

December 1, 2025

Toronto.pm - online - How SUSE is using Perl

December 6, 2025

Paris.pm monthly meeting

December 10, 2025

German Perl/Raku Workshop 2026 in Berlin

March 16-18, 2025

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.

If you were building web applications during the first dot-com boom, chances are you wrote Perl. And if you’re now a CTO, tech lead, or senior architect, you may instinctively steer teams away from it—even if you can’t quite explain why.

This reflexive aversion isn’t just a preference. It’s what I call Dotcom Survivor Syndrome : a long-standing bias formed by the messy, experimental, high-pressure environment of the early web, where Perl was both a lifeline and a liability.

Perl wasn’t the problem. The conditions under which we used it were. And unfortunately, those conditions, combined with a separate, prolonged misstep over versioning, continue to distort Perl’s reputation to this day.

The Glory Days: Perl at the Heart of the Early Web

In the mid- to late-1990s, Perl was the web’s duct tape.

• It powered CGI scripts on Apache servers.

• It automated deployments before DevOps had a name.

• It parsed logs, scraped data, processed form input, and glued together whatever needed glueing.

Perl 5 , released in 1994, introduced real structure: references, modules, and the birth of CPAN , which became one of the most effective software ecosystems in the world.

Perl wasn’t just part of the early web—it was instrumental in creating it.

The Dotcom Boom: Shipping Fast and Breaking Everything

To understand the long shadow Perl casts, you have to understand the speed and pressure of the dot-com boom.

We weren’t just building websites.

We were inventing how to build websites.

Best practices? Mostly unwritten.

Frameworks? Few existed.

Code reviews? Uncommon.

Continuous integration? Still a dream.

The pace was frantic. You built something overnight, demoed it in the morning, and deployed it that afternoon. And Perl let you do that.

But that same flexibility—its greatest strength—became its greatest weakness in that environment. With deadlines looming and scalability an afterthought, we ended up with:

• Thousands of lines of unstructured CGI scripts

• Minimal documentation

• Global variables everywhere

• Inline HTML mixed with business logic

• Security holes you could drive a truck through

When the crash came, these codebases didn’t age gracefully. The people who inherited them, often the same people who now run engineering orgs, remember Perl not as a powerful tool, but as the source of late-night chaos and technical debt.

Dotcom Survivor Syndrome: Bias with a Backstory

Many senior engineers today carry these memories with them. They associate Perl with:

• Fragile legacy systems

• Inconsistent, “write-only” code

• The bad old days of early web development

And that’s understandable. But it also creates a bias—often unconscious—that prevents Perl from getting a fair hearing in modern development discussions.

Version Number Paralysis: The Perl 6 Effect

If Dotcom Boom Survivor Syndrome created the emotional case against Perl, then Perl 6 created the optical one.

In 2000, Perl 6 was announced as a ground-up redesign of the language. It promised modern syntax, new paradigms, and a bright future. But it didn’t ship—not for a very long time.

In the meantime:

• Perl 5 continued to evolve quietly, but with the implied expectation that it would eventually be replaced.

• Years turned into decades , and confusion set in. Was Perl 5 deprecated? Was Perl 6 compatible? What was the future of Perl?

To outsiders—and even many Perl users—it looked like the language was stalled. Perl 5 releases were labelled 5.8, 5.10, 5.12… but never 6. Perl 6 finally emerged in 2015, but as an entirely different language, not a successor.

Eventually, the community admitted what everyone already knew: Perl 6 wasn’t Perl. In 2019, it was renamed Raku.

But the damage was done. For nearly two decades, the version number “6” hung over Perl 5 like a storm cloud – a constant reminder that its future was uncertain, even when that wasn’t true.

This is what I call Version Number Paralysis :

• A stalled major version that made the language look obsolete.

• A missed opportunity to signal continued relevance and evolution.

• A marketing failure that deepened the sense that Perl was a thing of the past.

Even today, many developers believe Perl is “stuck at version 5,” unaware that modern Perl is actively maintained, well-supported, and quite capable.

While Dotcom Survivor Syndrome left many people with an aversion to Perl, Version Number Paralysis gave them an excuse not to look closely at Perl to see if it had changed.

What They Missed While Looking Away

While the world was confused or looking elsewhere, Perl 5 gained:

• Modern object systems (Moo, Moose)

• A mature testing culture (Test::More, Test2)

• Widespread use of best practices (Perl::Critic, perltidy, etc.)

• Core team stability and annual releases

• Huge CPAN growth and refinements

But those who weren’t paying attention, especially those still carrying dotcom-era baggage, never saw it. They still think Perl looks like it did in 2002.

Can We Move On?

Dotcom Survivor Syndrome is real. So is Version Number Paralysis. Together, they’ve unfairly buried a language that remains fast, expressive, and battle-tested.

We can’t change the past. But we can:

• Acknowledge the emotional and historical baggage

• Celebrate the role Perl played in inventing the modern web

• Educate developers about what Perl really is today

• Push back against the assumption that old == obsolete

Conclusion

Perl’s early success was its own undoing. It became the default tool for the first web boom, and in doing so, it took the brunt of that era’s chaos. Then, just as it began to mature, its versioning story confused the industry into thinking it had stalled.

But the truth is that modern Perl is thriving quietly in the margins – maintained by a loyal community, used in production, and capable of great things.

The only thing holding it back is a generation of developers still haunted by memories of CGI scripts, and a version number that suggested a future that never came.

Maybe it’s time we looked again.

The post Dotcom Survivor Syndrome – How Perl’s Early Success Created the Seeds of Its Downfall first appeared on Perl Hacks.

OK, so...

For those using the Perl Catalyst web framework in ways involving structured request bodies (e.g. API POSTs)...

$c->req->body is a string, unless Content-Type is application/x-www-form-urlencoded, text/xml, or multipart/form-data (or in fact application/json, which isn't in the docs), in which case it's a File::Temp (an overloaded file handle), and $c->req->body_data gets you the deserialised body.

For various reasons, largely to do with the idiosyncrasies of one particular module, I need to read the raw body data from the $c->req->body file handle to process a Stripe webhook payload. For various other reasons, as part of the API call logging, I need to call $c->req->body_data to get at the deserialised body in another module.

You may imagine my delight when adding the latter caused the former to fail.

An afternoon of bad language and extra debug eventually revealed that $c->req->body_data doesn't clean up after itself, and I have to seek( $c->req->body, 0, 0) before I can read any data from the body file handle.

If this is useful to anyone else, you have my sympathies.