There are two issues with event loop coding, related to the need to maintain an asynchronous, non-blocking style.
It's harder to write and maintain than linear, blocking code.
Despite all the asynchronous behaviour, it's still single threaded.
You can break out of the async/non-blocking mode by forking, of course, but it's not a lightweight operation and creates the risk of orphaned processes even if most of the IPC work is hidden by a good library.
Wouldn't it be nice if you could simply write subs in the plain old linear, blocking style and then call them asynchronously, letting them run in parallel to your main thread until they're ready, no forking required? After all, you're probably already using some kind of async result mechanism like callbacks, or promises, or AnyEvent condition variables, or Future objects to manage existing async behaviour. Wouldn't it be nice if you could just call a sub and deal with it using one of those mechanisms instead of the usual synchronous behaviour?
Foswiki 2.1.10 can now be downloaded - landing right before Christmas, a full year since the last version dropped. Please be advised that this release includes several security fixes that require your attention. We would like to express our gratitude to Evgeny Kopytin of Positive Technologies for conducting a thorough audit of Foswiki and providing a comprehensive vulnerability report. Despite adhering closely to our security procedures, we were unable to obtain a response from the CVE Assignment Team regarding the allocation of official CVE-IDs. It is for this reason that the new security alerts covered by the 2.1.10er release had to be documented with a "CVE-2025-Unassigned" tag, since no better option was available.
Does the Perl world need another object-oriented programming framework?
To be honest, probably not.
But here’s why you might want to give Marlin a try anyway.
Most of your constructors and accessors will be implemented in XS and be really, really fast.
If you accept a few basic principles like “attributes should usually be read-only”, it can be really, really concise to declare a class and its attributes.
In my previous post, in February, I announced the overhaul of the MailBox software. The MailBox suite of distributions implement automatic email handling processes. I started development back in 1999, so it had aged a bit. And I can now proudly tell you that the work has been completed!
As you may have experienced yourself: software ages. It's not directly that it does not work anymore, however your own opinion about programming, the features of the language and libraries you use, and the source specifications keep on changing. Basic maintenance picks some of the low-hanging fruits as refreshment, but you usually stay away from major rewrites. Well, the marvelous NLnet Foundation helped me to realize just that!
A working link for Tom Christiansen's slides on "Unicode, The Good, the Bad, and the (mostly) Ugly" is at https://web.archive.org/web/20121224081332/https://98.245.80.27/tcpc/OSCON2011/gbu.html. (We are writing a book on debugging at home, and I needed a usable link to Tom's talk.)
It is an unfortunate fact of life reflected in the stages of man, that
we start off facing problems looking to others to solve these problems.
Later we learn to solve these problems ourselves, we teach others to do the
same. After that we delegate problem solving to those we have taught
but find that as our own capacity diminishes, those that come after us
simply ask an AI to do that which we struggled to learn in the past. A
steady spiral ensuring future humanity’s cognitive decline, fuelled by
the genius of its ancestors. We had become masters of our destiny
only to hand it over to machines, because we hope machines will do it
better. Perhaps they will.
The stars aligned and all three of us managed to get together.
We mostly talked about PPCs, both in the general shape of the process, and specifically the latest proposal, PPC0034.
Given how the PPC process has worked out in practice, we discussed how much sense it makes and whether it solves a problem we actually have. We agreed that the steering council - and Perl overall - would still benefit from having some sort of declared process by which people can suggest and discuss new features, as separate from implementing them.
The process at the moment doesn’t align very well with existing practice; at the same time, existing practice is not particularly structured. Rather than trying to define a new process, we think it better to clarify the documented process to more obviously match what we actually do, and try to iterate that way.
PPC0034 is concerned with refalias parameters in signatures. Both the refalias and declared_refs features are still currently marked as experimental, though it is not immediately clear in their overview tickets why. We should clarify the status of these before we fully commit to PPC0034.
That aside, the overall document of PPC0034 seems good and we’re happy to merge it as a basis for ongoing experiment and a trial implementation.
We're really excited about this line up. We've got some well know returning speakers and some very exciting new contributors. This is a hybrid conference, we encourage local and remote attendees and speakers/contributors to participate.
A plenv plugin to show which Perl versions have a particular module.
I use plenv daily to manage the many Perl configurations which I use for different projects. Sometimes I have to install huge collections of Perl modules for some specific use case. And then I forget which Perl installation under plenv it was where I installed them.
So I wrote this plugin to fix that.
Example use cases:
$ plenv where Dist::Zilla
5.24.4
5.28.2
5.34.1-dzil
5.39.2
It can also report the actual path and/or the module version:
The refalias draft PPC on the mailing list is looking good. We encourage Gianni to turn it into a full PPC doc PR
We still would like more automation around making real CPAN distributions out of dist/ dirs. Paul will write an email requesting assistance on that subject specifically
Briefly discussed the subject of the meta module handling signatures with named parameters. Further discussion will continue on the email thread.
When we publish our Perl module repository on GitHub, we might notice something peculiar in the "About"
section of our repository: GitHub doesn't recognize the Perl 5 license. This can be a bit
confusing, especially when we've explicitly stated the licensing in our LICENSE file.
Without properly defined license, GitHub ranks the quality of a repository lower. This is also unfortunate because it limits the "searchability" of our repository. GitHub cannot index it according to the license and users cannot search by license. This is today more important than ever before as many enterprises rule out open source projects purely on the grounds that their license is poorly managed.
The Problem: Two Licenses in One File
The standard Perl 5 license, as used by many modules, is a dual license: Artistic License (2.0) and GNU
General Public License (GPL) version 1 or later. Often, this is included in a single LICENSE file
in the repository root.
The tech world changes quickly, but some tools stand the test of time. Perl is one of them — a programming language that quietly powers countless systems behind the scenes. While the spotlight often falls on Python or Go, Perl continues to run financial systems, automate infrastructure, and parse massive data sets.
In 2025, Perl developers are still in demand. But finding the right opportunity requires more than typing a keyword into a job board. It’s about understanding where Perl fits today, who needs it most, and how to present yourself as the professional that businesses can rely on.
1. Understand Where Perl Is Thriving
To begin your job search, you first need to understand where Perl is alive and kicking. Contrary to the outdated belief that it’s a “legacy” language, Perl is still critical in several industries.
Finance and banking – Many risk analysis and trading systems were built on Perl decades ago and still rely on it for their daily operations.
Get them from the usual place.
And no, I have still not had time to update CPAN::MetaCustodian so that it properly parses these wikis. But that time is approaching...
wir laden Euch herzlich ein
zum Deutschen Perl/Raku Workshop 2026.
Der Workshop findet nächstes Jahr vom Montag 16. März bis
Mittwoch 18. März in der Heilandskirche in Berlin. statt.
Die Webseite und der Call for Papers sind bereits online. Wir freuen uns auf viele interessante
Vorträge!
Über Unterstützung durch Sponsoren freuen wir uns immer. Wenn Ihr bzw. Eure
Firma den Workshop unterstützen möchtet, wendet Euch gerne an uns. Wir finden gemeinsam sicher eine Möglichkeit!
Wenn Ihr Fragen an die Organisatoren habt, erreicht Ihr uns am besten
direkt unter orga2026@german-perl-workshop.de .
Wir freuen uns auf Eure Teilnahme,
Max Maischein für die Organisatoren und Frankfurt.pm
Wir arbeiten noch an
Hotelempfehlungen und veröffentlichen diese auf der Webseite.
---
Hello everybody,
we cordially invite you
to the German Perl/Raku Workshop 2026.
The workshop will take place next year from Monday 16th May to
Wednesday 18th March in the Heilandskirche in Berlin..
The website and the call for papers are already online.
We are looking forward to many interesting
presentations!
I thought it might be fun to write a "polymorphic virus", but that would involve learning executable file formats and machine code, which sounds like a lot of effort. So instead I went for the next best thing: Perl instead of machine code, and self-replicating code in the form of a quine rather than "infecting" other executables.
When you run this code, it will output a new version of itself, which you can run again to get another version, etc. Unlike a regular quine, which will produce an exact copy of its source code, this program is polymorphic: Its output is functionally identical to the original, but the code might look completely different. This is just a proof-of-concept, but it does try to introduce variations in all parts that a simple static scanner might use for detection (such as signatures in an antivirus). There are still fixed parts, but they're small and generic (such as ; or =) and can be found in most any perl script.
On my last post I asked Gemini to create a product requirement document to outline a plan to improve the overall state of the ev-calc-pricing application. In this blog entry I will discuss my interaction with Gemini and how it increased code coverage of the ev-calc-pricing application. Below is an example of the prompts:
----
> review PRD.md for @ev-calc-pricing
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ ReadFile PRD.md │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ The PRD.md outlines a plan to refactor the ev-calc-pricing application to improve maintainability, data accuracy, and
robustness.
Key issues identified:
* Manual, hardcoded electricity rate data in StateRates.pm.
* Minimal test coverage.
* Unused scripts and lack of input validation.
The plan focuses on four epics:
1. Automated Data Pipeline: To fetch, process, and load electricity rate data automatically.
2. Comprehensive Test Suite: To ensure accuracy and stability of calculations and data loading.
3. Code Refactoring and Cleanup: To remove hardcoded data, unused scripts, and consolidate data files.
4. Enhanced User Experience: To add input validation and better user feedback.
