When I first introduced Marlin, it seemed the only OO framework which could beat its constructor in speed was the one generated by the new Perl core class keyword. Which seems fair, as that’s implemented in C and is tightly integrated with the Perl interpreter. However, I’m pleased to say that Marlin’s constructors are now faster.

(Though also I forgot to include Mouse in previous benchmarks, so I’ve rectified that now.)

         Rate  Plain   Tiny    Moo  Moose   Core Marlin  Mouse
Plain  1357/s     --    -1%   -48%   -55%   -73%   -77%   -78%
Tiny   1374/s     1%     --   -48%   -54%   -72%   -77%   -78%
Moo    2617/s    93%    91%     --   -13%   -47%   -56%   -58%
Moose  3001/s   121%   118%    15%     --   -39%   -50%   -52%
Core   4943/s   264%   260%    89%    65%     --   -17%   -21%
Marlin 5976/s   340%   335%   128%    99%    21%     --    -4%
Mouse  6237/s   359%   354%   138%   108%    26%     4%     --

The main way I’ve squeezed out a bit of improved performance is by improving how Class::XSConstructor keeps its metadata.

Previously, if you called Local::Person->new(), the XS constructor would look up the list of supported attributes for the class in @Local::Person::__XSCON_HAS and loop through that array to initialize each attribute like "name", "age", etc. If the attribute had a type constraint, it would need to fetch the coderef to validate the value from $Local::Person::__XSCON_ISA{"name"}, and so on. All these involved looking things up in the class’s stash, which isn’t exactly slow when done via XS, but could be faster.

I’ve changed it so that the first time the constructor is called, the XS code pulls together all the data it needs into C structs.

typedef struct {
    char   *name;
    I32     flags;
    char   *init_arg;
    char  **aliases;
    I32     num_aliases;
    SV     *default_sv;
    SV     *trigger_sv;
    CV     *check_cv;
    CV     *coercion_cv;
} xscon_param_t;

typedef struct {
    char   *package;
    bool    is_placeholder;
    xscon_param_t *params;
    I32     num_params;
    CV    **build_methods;
    I32     num_build_methods;
    bool    strict_params;
    char  **allow;
    I32     num_allow;
} xscon_constructor_t;

Rather than having to deal with attribute names being Perl SVs, they’re just simple C strings (char*).

The flags field does a lot of heavy lifting. It is a bit field with booleans indicating whether an attribute is required or optional, whether it should be a weaken reference, and other features. A lot of common defaults (attributes which default to common values like undef, true, false, 0, 1, the empty string, an empty arrayref, or an empty hashref) and common type constraints (Str, Num, Int, ArrayRef, etc) are also encoded into the flags field, so the constructor can often skip even having to look at default_sv and check_cv.

At the same time, the number of features Class::XSConstructor supports has increased, so Marlin now never needs to fall back to generating Pure Perl constructors. (The code for generating Perl constructors has now been deleted!)

A second trick is one I learned from Mouse in how it implements its strict constructor check. As a reminder, a strict constructor check is like the ones implemented by MooseX::StrictConstructor, MooX::StrictConstructor, and MouseX::StrictConstructor, along these lines:

sub new {
  # Unpack @_
  my $class = shift;
  my %args  = ( @_ == 1 and ref($_[0]) eq 'HASH' ) ? %{+shift} : @_;

  # Create new object
  my $object = bless( {}, $class );

  # Initialize each attribute
  if ( exists $args{name} ) {
    $object->{name} = $args{name};
  }
  if ( exists $args{date} ) {
    $object->{date} = $args{date};
  }

  # Strict constructor check
  for my $key ( %args ) {
    die "Unrecognized key: $key" unless $key =~ /^(name|date)$/;
  }

  return $object;
}

Strict constructors are a really useful feature as a protection against mistyped attributes. But they do come with a speed penalty, which I guess is why Moose and Moo don’t have this feature built in. (Mouse does actually have the feature built in, but requires an extension (MouseX::StrictConstructor) to toggle it on.)

Mouse’s strict constructor check has virtually zero performance impact. I took a look at the source code to figure out how, and it is pretty smart. It just counts the number of arguments the constructor has used to initialize attributes, and only bothers with the strict constructor check if the total number of arguments is greater than that. Something like this:

sub new {
  # Unpack @_
  my $class = shift;
  my %args  = ( @_ == 1 and ref($_[0]) eq 'HASH' ) ? %{+shift} : @_;

  # Create new object
  my $object = bless( {}, $class );
  my $used_keys = 0;

  # Initialize each attribute
  if ( exists $args{name} ) {
    $object->{name} = $args{name};
    $used_keys++;
  }
  if ( exists $args{date} ) {
    $object->{date} = $args{date};
    $used_keys++;
  }

  # Strict constructor check
  if ( keys(%args) > $used_keys ) {
    for my $key ( %args ) {
      die "Unrecognized key: $key" unless $key =~ /^(name|date)$/;
    }
  }

  return $object;
}

Genius!

With these changes, Marlin is now significantly faster than the Perl core class keyword.

Mouse still has around 10% faster accessors than Marlin, which I think might be largely down to having an integrated type system allowing pure C function calls for type constraints instead of needing to use call_sv to call an XS or Perl type check function.

Marlin does however beat Mouse significantly (around 70% faster) when it comes to delegated methods. Things like:

use v5.36;

package API_Client {
  use Marlin
    -modifiers,
    _log => {
      isa          => 'ArrayRef[HashRef]',
      default      => [],
      handles_via  => 'Array',
      handles      => {
        add_to_log   => 'push',
        responses    => 'all',
      },
    },
    ua => {
      isa          => 'HTTP::Tiny',
      default      => sub { HTTP::Tiny->new },
      handles      => {
        http_get     => 'get',
        http_post    => 'post',
      },
    };

    around 'http_get', 'http_post' => sub ( $next, $self, @args ) {
      my $response = $self->$next( @args );
      $self->add_to_log( $response );
      return $response;
    };
}

my $client = API_Client->new;
$client->http_get( ... );
$client->http_get( ... );
$client->http_get( ... );
my @responses = $client->responses;

Marlin outperforms all other OO frameworks in this kind of method.

If you want a fast, concise OO framework, consider using Marlin.

So over the past few days I've built a new addition to the Perl ecosystem: the Claude Agent SDK. It's a library that brings the agentic capabilities of Claude Code into your Perl applications.

At its core, the SDK enables you to build AI agents that can read files, run shell commands, search the web, edit code, and interact with external systems. All orchestrated from familiar Perl code. Whether you're automating code reviews, building intelligent DevOps tooling, or integrating AI capabilities into legacy systems, this SDK provides the foundation you need.

The architecture is built around a streaming JSON Lines protocol (using my JSON::Lines module) that communicates with the Claude Code CLI, supporting both synchronous operations and fully asynchronous patterns via IO::Async and Future::AsyncAwait. Although we send valid JSON lines, the CLI doesn't always return valid JSON lines, so some extension to my module was needed to handle malformed responses gracefully. Here's what a simple interaction looks like:

use Claude::Agent qw(query);
use Claude::Agent::Options;

my $options = Claude::Agent::Options->new(
    allowed_tools   => ['Read', 'Glob', 'Grep'],
    permission_mode => 'bypassPermissions',
);

my $iter = query(
    prompt  => "What files in ./lib need the most refactoring?",
    options => $options,
);

while (my $msg = $iter->next) {
    if ($msg->isa('Claude::Agent::Message::Result')) {
        print $msg->result;
        last;
    }
}

The real power emerges when you explore the SDK's advanced features: custom MCP tools that can run directly in your Perl process with full access to your application state, a subagent system for spawning specialised AI workers with isolated contexts, session management for resuming or forking conversations, and structured output with JSON Schema validation for automation-ready responses.

The SDK is complemented by two separate distributions I wrote that showcase what's possible: a Code Review module for AI-powered analysis with severity-based issue detection and Perlcritic integration, and a Code Refactor module that implements an automated review-fix-repeat loop until your codebase is clean.

Let's dive into how it all works.

Custom MCP Tools That Run in Your Process

One of the most powerful features of the Claude Agent SDK is the ability to create custom MCP tools that execute directly in your Perl process. Unlike external MCP servers that run as separate services, SDK tools have full access to your application's state: your database connections, configuration, session data, and any Perl modules you're already using.

This architecture enables significant functional extensibility. To permit Claude to execute queries against production databases, retrieve customer records, or access inventory data, these operations can be exposed as callable tools within the conversational interface. All tool invocations adhere to JSON Schema validation, ensuring type safety and structural integrity throughout the execution pipeline.

You define a tool with four components: a name, a description (which helps Claude understand when to use it), an input schema (JSON Schema defining the parameters), and a handler (your Perl code that does the actual work):

use Claude::Agent qw(tool create_sdk_mcp_server);

my $find_user = tool(
    'find_user',                              # Tool name
    'Find a user by their email address',    # Description for Claude
    {                                         # JSON Schema for inputs
        type       => 'object',
        properties => {
            email => {
                type        => 'string',
                description => 'Email address to search for'
            },
        },
        required => ['email'],
    },
    sub {                                     # Handler (runs in your process!)
        my ($args) = @_;
        # Your code here with full access to application state
        return {
            content => [{ type => 'text', text => 'Result goes here' }],
        };
    }
);

The magic is in that handler. It's not running in some sandboxed external process. It's running right in your Perl application, with access to everything you've already set up. Let's build a complete database query tool to see this in action:

#!/usr/bin/env perl
use 5.020;
use strict;
use warnings;

use Claude::Agent qw(query tool create_sdk_mcp_server);
use Claude::Agent::Options;
use IO::Async::Loop;
use DBI;

# Your existing database connection. The tool handler can use this directly
my $dbh = DBI->connect(
    'dbi:SQLite:customers.db',
    '', '',
    { RaiseError => 1, AutoCommit => 1 }
);

# Tool 1: Find a customer by email
my $find_customer = tool(
    'find_customer',
    'Look up a customer record by email address. Returns their name, plan, and signup date.',
    {
        type       => 'object',
        properties => {
            email => {
                type        => 'string',
                description => 'Customer email to search for'
            },
        },
        required => ['email'],
    },
    sub {
        my ($args) = @_;

        # Direct database access with no external API, no serialisation overhead
        my $customer = $dbh->selectrow_hashref(
            'SELECT name, email, plan, created_at FROM customers WHERE email = ?',
            undef,
            $args->{email}
        );

        if ($customer) {
            return {
                content => [{
                    type => 'text',
                    text => sprintf(
                        "Found customer: %s <%s>\nPlan: %s\nMember since: %s",
                        $customer->{name},
                        $customer->{email},
                        $customer->{plan},
                        $customer->{created_at}
                    ),
                }],
            };
        }

        return {
            content => [{
                type => 'text',
                text => "No customer found with email: $args->{email}"
            }],
        };
    }
);

# Tool 2: Get aggregate statistics
my $customer_stats = tool(
    'customer_stats',
    'Get statistics about customers, optionally filtered by plan type',
    {
        type       => 'object',
        properties => {
            plan => {
                type        => 'string',
                enum        => ['free', 'pro', 'enterprise'],
                description => 'Filter by plan type (optional)'
            },
        },
        required => [],  # No required params so Claude can call this with no arguments
    },
    sub {
        my ($args) = @_;

        my ($sql, @bind);
        if ($args->{plan}) {
            $sql = 'SELECT COUNT(*) as count, plan FROM customers WHERE plan = ? GROUP BY plan';
            @bind = ($args->{plan});
        } else {
            $sql = 'SELECT COUNT(*) as count, plan FROM customers GROUP BY plan ORDER BY count DESC';
        }

        my $rows = $dbh->selectall_arrayref($sql, { Slice => {} }, @bind);

        my @lines = map { "$_->{plan}: $_->{count} customers" } @$rows;
        return {
            content => [{
                type => 'text',
                text => join("\n", @lines) || "No customers found"
            }],
        };
    }
);

Now bundle these tools into an SDK MCP server and use them in a query:

# Create the MCP server
my $server = create_sdk_mcp_server(
    name    => 'customerdb',
    tools   => [$find_customer, $customer_stats],
    version => '1.0.0',
);

# Configure the agent to use our tools
my $options = Claude::Agent::Options->new(
    mcp_servers     => { customerdb => $server },
    allowed_tools   => $server->tool_names,  # ['mcp__customerdb__find_customer', ...]
    permission_mode => 'bypassPermissions',
    max_turns       => 10,
);

# Now Claude can query your database naturally
my $loop = IO::Async::Loop->new;
my $iter = query(
    prompt  => 'How many customers do we have on each plan? ' .
               'Also, look up the customer with email alice@example.com',
    options => $options,
    loop    => $loop,
);

# Stream the response
while (my $msg = $iter->next) {
    if ($msg->isa('Claude::Agent::Message::Assistant')) {
        for my $block ($msg->content_blocks) {
            print $block->text if $block->isa('Claude::Agent::Content::Text');
        }
    }
    elsif ($msg->isa('Claude::Agent::Message::Result')) {
        print "\n\nQuery complete.\n";
        last;
    }
}

When you run this, Claude will intelligently call both tools to answer your question. It might first call customer_stats with no arguments to get the plan breakdown, then call find_customer with email => 'alice@example.com' to look up that specific record. You'll see output like:

Let me check our customer data for you.

We have the following customers by plan:
- pro: 1,247 customers
- free: 3,892 customers
- enterprise: 89 customers

For alice@example.com, I found:
- Name: Alice Chen
- Plan: enterprise
- Member since: 2024-03-15

Behind the scenes, the SDK creates a Unix socket for communication between your main process and a lightweight MCP protocol handler. When Claude calls a tool, the request flows through the socket to your handler, which executes synchronously with full access to $dbh and any other state in scope. The result flows back to Claude, and the conversation continues.

This pattern is incredibly useful for building AI-powered interfaces to your existing systems. You're not building a new API. You're exposing capabilities that your Perl code already has, with Claude handling the natural language understanding and your handlers doing the actual work. The JSON Schema validation ensures Claude passes the right parameters, and your handlers can return structured results or friendly error messages.

A few things to note about handler implementation:

• Return structure: Always return a hashref with a content array. Each element should have type => 'text' and a text field.
• Error handling: Set is_error => 1 in your return value when something goes wrong. Claude will understand the operation failed.
• Input validation: The SDK validates inputs against your JSON Schema, but you may want additional business logic validation in your handler.
• Security: Be thoughtful about what you expose. The enum constraint in customer_stats limits which plans can be queried. You can use similar patterns to restrict what data Claude can access.

The Hook System for Fine-Grained Control

When you're running AI agents in production, you need visibility. What tools is Claude calling? With what parameters? How long did each operation take? Did anything get blocked? The Claude Agent SDK's hook system gives you complete control over the agent's tool execution lifecycle, letting you intercept, inspect, modify, or block any operation.

Think of hooks as middleware for AI agent operations. Every time Claude wants to call a tool, whether it's reading a file, running a bash command, or calling one of your custom MCP tools: your hooks get first dibs. You can log the operation, check it against security policies, modify the parameters, or shut it down entirely. And you get hooks for multiple lifecycle points: before execution, after success, after failure, and more.

The system is built around matchers that bind patterns to callbacks:

use Claude::Agent::Hook::Matcher;
use Claude::Agent::Hook::Result;

my $matcher = Claude::Agent::Hook::Matcher->new(
    matcher => 'Bash',           # Tool name pattern (regex or exact match)
    timeout => 60,               # Hook execution timeout in seconds
    hooks   => [                 # Array of callback subroutines
        sub {
            my ($input, $tool_use_id, $context) = @_;
            # Your logic here
            return Claude::Agent::Hook::Result->proceed();
        },
    ],
);

Each hook callback receives three arguments: $input (a hashref with tool_name and tool_input), $tool_use_id (a unique identifier for this specific invocation), and $context (a Claude::Agent::Hook::Context object with session metadata like session_id and cwd).

Your hooks return decisions using the Claude::Agent::Hook::Result factory:

# Let the operation proceed unchanged
return Claude::Agent::Hook::Result->proceed();

# Allow but modify the input parameters
return Claude::Agent::Hook::Result->allow(
    updated_input => { command => 'sanitized_command' },
    reason        => 'Modified for security',
);

# Block the operation entirely
return Claude::Agent::Hook::Result->deny(
    reason => 'This operation violates security policy',
);

The available hook events cover the tool execution lifecycle:

These three events are the workhorses of the hook system, giving you complete visibility into tool execution. The SDK also defines additional event types (SessionStart, SessionEnd, SubagentStart, SubagentStop, PermissionRequest, Notification, Stop, PreCompact, UserPromptSubmit) that cover session lifecycle, subagent management, and user interactions.

# Security hook, only fires for Bash tool
my $bash_security = Claude::Agent::Hook::Matcher->new(
    matcher => 'Bash',  # Exact match on tool name
    hooks   => [sub {
        my ($input, $tool_use_id, $context) = @_;

        my $command = $input->{tool_input}{command} // '';

        # Define blocked patterns
        my @dangerous_patterns = (
            qr/\brm\s+-rf\s+[\/~]/,      # rm,rf against root or home
            qr/\bsudo\b/,                 # No sudo commands
            qr/\bchmod\s+777\b/,          # World-writable permissions
            qr/>\s*\/etc\//,              # Redirecting to /etc
            qr/\bcurl\b.*\|\s*\bbash\b/,  # Piping curl to bash
            qr/\beval\b/,                 # Command eval
        );

        for my $pattern (@dangerous_patterns) {
            if ($command =~ $pattern) {
                write_audit_log({
                    timestamp   => scalar(gmtime) . ' UTC',
                    event       => 'TOOL_BLOCKED',
                    tool_use_id => $tool_use_id,
                    tool_name   => 'Bash',
                    reason      => 'Matched dangerous pattern',
                    pattern     => "$pattern",
                    severity    => 'CRITICAL',
                });

                return Claude::Agent::Hook::Result->deny(
                    reason => 'This command has been blocked by security policy.',
                );
            }
        }

        return Claude::Agent::Hook::Result->proceed();
    }],
);

• Hook execution order matters. When you provide multiple matchers for the same event, they run in array order. Within a single matcher, if any hook returns allow or deny, subsequent hooks in that matcher don't execute. The decision is final.

• Matcher patterns are flexible. Use an exact string like 'Bash' to match a specific tool, a regex pattern like 'mcp__.*' to match all MCP tools, or omit the matcher entirely to catch everything. The SDK includes ReDoS protection to prevent pathological regex patterns from hanging your process.

• Hooks are exception-safe. If your callback throws, the SDK catches it and returns { decision => 'error' }. Your agent keeps running, and you can enable CLAUDE_AGENT_DEBUG=1 to see the full stack trace.

• The context object is your friend. The $context parameter gives you the session ID (essential for correlating logs across a conversation), the current working directory, and the tool details. Use this metadata to make intelligent decisions about what to allow.

Subagents for Specialised Tasks

Sometimes a single agent isn't enough. Maybe you need to run multiple analyses in parallel, checking for security vulnerabilities while simultaneously reviewing code style. Maybe you want to isolate a complex task so it doesn't pollute your main conversation context. Or maybe you need specialised expertise: one agent focused purely on security, another on performance, each with tailored instructions and tool access.

This is what subagents are for. The Claude Agent SDK lets you define specialised agent profiles that your main agent can spawn on demand. Each subagent runs in its own isolated context with its own system prompt, tool permissions, and even model selection. Think of them as expert consultants your agent can call in when it needs help.

The architecture is elegant. You define subagents as configuration objects with four properties:

use Claude::Agent::Subagent;

my $subagent = Claude::Agent::Subagent->new(
    description => '...',   # When should Claude use this agent?
    prompt      => '...',   # System prompt defining expertise
    tools       => [...],   # Allowed tools (optional, inherits if not set)
    model       => '...',   # Model override (optional, 'sonnet', 'opus', 'haiku')
);

The description is key. Claude uses this to decide when to delegate. Write it like you're explaining to a colleague: "Expert security reviewer for vulnerability analysis" tells Claude exactly what this agent does. The prompt is the system prompt that shapes the subagent's behaviour, giving it the specialised knowledge and instructions it needs.

The subagent architecture provides several powerful capabilities:

Context isolation. Each subagent starts fresh with only its system prompt. There is no accumulated context from earlier in the conversation. This prevents context pollution and keeps analyses focused.

Tool restriction. Notice how secrets_detector doesn't have Bash access. It can only read files. This is defense in depth: even if the AI were to malfunction, a secrets-scanning agent physically cannot execute commands.

Model selection. Use Opus for complex security analysis where you need the strongest reasoning. Use Haiku for straightforward pattern-matching tasks. Your main agent can be Sonnet as the orchestrator. This optimises both cost and capability.

Parallel potential. While Claude currently executes subagents sequentially, the architecture supports parallel execution. When you spawn multiple subagents, their isolated contexts mean results can be combined without interference.

Async Tool Handlers

For tools that perform I/O operations—HTTP requests, database queries, file operations—blocking the event loop is wasteful. The SDK supports async tool handlers that return Futures, enabling true non-blocking execution.

Your handler receives the IO::Async::Loop as its second parameter. Use it to perform async operations and return a Future that resolves with your result:

use Future::AsyncAwait;
use Net::Async::HTTP;

my $fetch_url = tool(
    'fetch_url',
    'Fetch content from a URL asynchronously',
    {
        type       => 'object',
        properties => {
            url => { type => 'string', description => 'URL to fetch' },
        },
        required => ['url'],
    },
    async sub {
        my ($args, $loop) = @_;

        my $http = Net::Async::HTTP->new;
        $loop->add($http);

        my $response = await $http->GET($args->{url});

        return {
            content => [{
                type => 'text',
                text => sprintf("Status: %d\nBody: %s",
                    $response->code,
                    substr($response->decoded_content, 0, 1000)),
            }],
        };
    }
);

The same pattern works for hooks. Your hook callback can return a Future for async validation:

my $async_security_hook = Claude::Agent::Hook::Matcher->new(
    matcher => '.*',
    hooks   => [
        async sub {
            my ($input, $tool_use_id, $context, $loop) = @_;

            # Async check against a security policy service
            my $http = Net::Async::HTTP->new;
            $loop->add($http);

            my $resp = await $http->POST(
                'https://security.internal/check',
                content => encode_json($input),
            );

            if ($resp->code == 403) {
                return Claude::Agent::Hook::Result->deny(
                    reason => 'Blocked by security policy',
                );
            }

            return Claude::Agent::Hook::Result->proceed();
        },
    ],
);

One powerful pattern enabled by the shared event loop: spawning nested queries from within a tool handler. Your tool can invoke Claude as a sub-agent:

my $research_tool = tool(
    'deep_research',
    'Spawn a sub-agent to research a topic',
    {
        type       => 'object',
        properties => {
            topic => { type => 'string' },
        },
        required => ['topic'],
    },
    sub {
        my ($args, $loop) = @_;

        # Spawn a sub-query using the shared event loop
        my $sub_query = query(
            prompt  => "Research thoroughly: $args->{topic}",
            options => Claude::Agent::Options->new(
                allowed_tools   => ['Read', 'Glob', 'WebSearch'],
                permission_mode => 'bypassPermissions',
                max_turns       => 5,
            ),
            loop => $loop,
        );

        my $result = '';
        while (my $msg = $sub_query->next) {
            if ($msg->isa('Claude::Agent::Message::Result')) {
                $result = $msg->result // '';
                last;
            }
        }

        return {
            content => [{ type => 'text', text => $result }],
        };
    }
);

Sync handlers continue to work unchanged. The SDK automatically wraps synchronous return values in Futures, so you can mix sync and async tools freely.

Wrapping Up

The Claude Agent SDK for Perl brings agentic AI capabilities directly into your existing infrastructure. From custom MCP tools that access your application state, to a flexible hook system for security and observability, to specialised subagents for parallel expertise—the toolkit is designed for real-world automation. Whether you're building intelligent code review pipelines, DevOps automation, or AI-powered interfaces to legacy systems, the SDK provides the primitives you need while keeping you in control. The code is available on CPAN, and I look forward to seeing what you build with it.

https://metacpan.org/pod/Claude::Agent

Here are some extensions I've built already using the SDK:

https://metacpan.org/pod/Claude::Agent::Code::Review

https://metacpan.org/pod/Claude::Agent::Code::Refactor

https://metacpan.org/pod/Wordsmith::Claude

https://metacpan.org/dist/Acme-Claude-Shell/view/bin/acme_claude_shell

Weekly Challenge 355

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. It's a great way for us all to practice some coding.

Challenge, My solutions

Task 1: Thousand Separator

Task

You are given a positive integer, $int.

Write a script to add thousand separator, , and return as string

My solution

Both Perl and Python have modules do this. There is absolutely no need to reinvent a perfectly round wheel. As int is a reserved word in Python, I use the variable number instead. The Python solution is as follows.

def thousand_separator(number: int) -> str:
    return f"{number:,}"

The Perl solution uses the Number::Format module.

use Number::Format 'format_number';

sub main ($int) {
    say format_number($int);
}

It should of course be noted that not all countries use the comma to separate grouping of digits. Some countries use the dot character instead. India also groups numbers by the hundred after the first thousand (e.g. 12,45,67,890).

Examples

$ ./ch-1.py 123
123

$ ./ch-1.py 1234
1,234

$ ./ch-1.py 1000000
1,000,000

$ ./ch-1.py 1
1

$ ./ch-1.py 12345
12,345

Task 2: Mountain Array

Task

You are given an array of integers, @ints.

Write a script to return true if the given array is a valid mountain array.

An array is mountain if and only if:

1. arr.length >= 3, and
2. There exists some i with 0 < i < arr.length - 1 such that:
   • arr[0] < arr[1] < ... < arr[i - 1] < arr[i]
   • arr[i] > arr[i + 1] > ... > arr[arr.length - 1]

My solution

This turned out to be harder than I thought it would be. I'm not sure if this is the best solution. I advantage of this solution is I loop over the list once.

These are the steps I take.

1. Check that there are at least three items in the ints list (array in Perl). Return False if there are not.
2. Set the variable last_int to the first item in the ints list, and the variable direction to up.
3. Check that the second item is higher than the first, and return False if it is not. This ensures that descents won't return the wrong result.
4. Loop through the remaining items in ints setting the value to current_int.
   1. If current_int and last_int are the same, return False.
   2. If direction is up and the current_int value is less than last_int, set direction to down.
   3. If direction is down and the current_int value is higher than last_int, return False.
   4. Set last_int to the current_int value.
5. If direction is still up, return False. This ensures ascents won't return the wrong result.
6. Return True.

def mountain_array(ints: list) -> bool:
    if len(ints) < 3:
        return False

    direction = 'up'
    last_int = ints[0]

    if ints[1] <= last_int:
        return False

    for current_int in ints[1:]:
        if current_int == last_int:
            return False
        if direction == 'up':
            if current_int < last_int:
                direction = 'down'
        else:
            if current_int > last_int:
                return False

        last_int = current_int

    if direction == 'up':
        return False

    return True

The Perl solution follows the same logic.

Examples

$ ./ch-2.py 1 2 3 4 5
False

$ ./ch-2.py 0 2 4 6 4 2 0
True

$ ./ch-2.py 5 4 3 2 1
False

$ ./ch-2.py 1 3 5 5 4 2
False

$ ./ch-2.py 1 3 2
True

$ ./ch-2.py 1 3 
False

Originally published at Perl Weekly 754

Hi there,

Happy New Year, everyone (albeit a belated one).

Any New Year's resolutions this time? For me, none. I'm too old for such customs. However, I always have a full plate, which is nice.

Normally, you expect the new year to bring new energy but that rarely happens. Instead you often already feel tired from a busy schedule, gift shopping, and attending parties. How was yours?

I luckily had an extended break this time, so I used it to work on my upcoming book on DBIx::Class. I have a habit of getting deep into the skin of a subject, and this time was no different. When I shared updates on social media, I received many positive reviews. One suggestion to add asynchronous operation support to DBIx::Class. I must admit that before this book, I had barely touched it, although my current work place uses it extensively. In the past, I mostly worked with an in-house ORM written in Perl.

While working on the book, I decided to share my initial draft for supporting async operations in DBIx::Class and released DBIx::Class::Async on the first day of 2026. It's still experimental, but I received a few suggestions from big shots, which led to another quick update to address their feedback. I wrote a blog post to introduce the new creation and am working on another post to discuss further improvements since the initial release. I had hoped to have it ready for this newsletter, but not everything goes according to plan. Never mind - in a couple of days - I will share it with you.

Two major blockers I encountered during my research were transactions and searches with prefetch. I will continue working on these until I find a satisfactory solution. I also come across another new distribution on the same subject, DBIx::Quick. I'm happy to see the sudden renewed interest in ORM in general.

Today is my first working day of 2026, so I'm very excited. Please share your experiences.

Enjoy rest of the newsletter.

--
Your editor: Mohammad Sajid Anwar.

Announcements

The Underbar, episode 8

As preparations are underway for the Perl Toolchain Summit 2026, this short episode is the last excerpt recorded during PTS 2025 (as a tangent during the CPAN Testers interview, published as episode 6). BooK starts by explaining the selection process for the Perl Toolchain Summit and some of the history, and then Doug, Ruth, Breno and Ferki reminisce about what makes the event so special.

Articles

App::HTTPThis: the tiny web server I keep reaching for

Dave shares his long-time favorite tool for static site work: App::HTTPThis. This Perl module is a friction-free command-line web server that instantly serves any directory over HTTP, perfect for testing links, assets, and real browser behavior without the overhead of Apache or nginx.

DBIx::Class::Async

A gentle tntroduction to DBIx::Class::Async. Please share your suggestions.

Episode 9: Perl, the Language That Refuses to Die (And Honestly, Good for It)

A very interesting read, unfortunately it is behind Medium's paywall, marked as members only.

jq-lite: A jq Alternative for Legacy and Restricted Systems

jq-lite is a jq-compatible JSON processor written in pure Perl. It is designed for legacy, restricted, and minimal environments where installing jq is not possible.

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 - 355

Welcome to a new week with a couple of fun tasks "Thousand Separator" and "Mountain Array". 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 - 354

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Min Abs Diff" and "Shift Grid" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

MAD Shift

The post showcases excellent problem-solving skills and clear pedagogical explanations. The implemented code for the first challenge and the conceptual solution for the second are both technically sound and well-justified.

Shifted Differences

This is a competent Perl implementation that demonstrates strong algorithmic thinking, particularly for the grid rotation problem. Jorg shows good understanding of Perl's array manipulation capabilities and mathematical optimisation.

Perl Weekly Challenge 354

Expert-level PDL implementation that leverages specialized numerical libraries for concise, high-performance solutions. This approach is optimal for numerical computing contexts but requires deep PDL knowledge.

Min Abs Diff Shift Grid. What??

Matthias demonstrates both theoretical knowledge (complexity analysis) and practical skill (performance optimisation), making this an exemplary technical solution.

Some Grids

This is a well-written and highly educational post. Packy successfully demonstrates how to solve algorithmic problems using the distinct styles of different programming languages. The solutions are correct, clearly explained, and follow good practices.

Mad numbers and shifty grid

Peter demonstrates a pragmatic, straightforward approach to solving the weekly challenge #354. The code is clear, functional, and focuses on delivering correct results with minimal complexity.

The Weekly Challenge #354

This solution set takes a functional but brute-force approach to the problems. While correct, it prioritizes straightforward implementation over algorithmic optimisation.

Min Grid Diffs the Shift

This is a sophisticated, well-optimized solution that correctly identifies and implements the most efficient algorithms for both challenges. Roger demonstrates strong understanding of algorithmic complexity and language-specific optimizations.

New Year, New Challenges

High-quality, production-ready solutions with excellent algorithm choices, clean implementations, and thoughtful language-specific optimizations. Simon demonstrates strong command of both algorithmic thinking and practical coding.

Rakudo

2025.52 Release #188 & State of the Onion

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

The corner of Gabor

A couple of entries sneaked in by Gabor.

The new pull-request challenge (club)

Recently I saw that the PullRequest.Club closed on January 1st. It's a pity as it was a good idea. But don't worry, the new PRC is here. Less organized but here. The challenge is to send a PR to any CPAN module once a week and share the link to it on this issue. (see my first comments on that issue). If you have never contributed to an open source project or if you have never sent a PR, don't worry. I organize live online sessions where I demonstrate the whole process as I am working on a project. You can watch. You can ask question. You can learn. Then you can implement and send your own PRs. Check the events here!

Events

Perl Maven online: Live Open Source contribution

January 08, 2025

Boston.pm - online

January 13, 2025

Perl Maven online: Live Open Source contribution

January 24, 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.

Whenever I’m building a static website, I almost never start by reaching for Apache, nginx, Docker, or anything that feels like “proper infrastructure”. Nine times out of ten I just want a directory served over HTTP so I can click around, test routes, check assets, and see what happens in a real browser.

For that job, I’ve been using App::HTTPThis for years.

It’s a simple local web server you run from the command line. Point it at a directory, and it serves it. That’s it. No vhosts. No config bureaucracy. No “why is this module not enabled”. Just: run a command and you’ve got a website.

Why I’ve used it for years

Static sites are deceptively simple… right up until they aren’t.

• You want to check that relative links behave the way you think they do.

• You want to confirm your CSS and images are loading with the paths you expect.

• You want to reproduce “real HTTP” behaviour (caching headers, MIME types, directory handling) rather than viewing files directly from disk.

Sure, you can open file:///.../index.html in a browser, but that’s not the same thing as serving it over HTTP. And setting up Apache (or friends) feels like bringing a cement mixer to butter some toast.

With http_this, the workflow is basically:

• cd into your site directory

• run a single command

• open a URL

• get on with your life

It’s the “tiny screwdriver” that’s always on my desk.

Why I took it over

A couple of years ago, the original maintainer had (entirely reasonably!) become too busy elsewhere and the distribution wasn’t getting attention. That happens. Open source is like that.

But I was using App::HTTPThis regularly, and I had one small-but-annoying itch: when you visited a directory URL, it would always show a directory listing - even if that directory contained an index.html. So instead of behaving like a typical web server (serve index.html by default), it treated index.html as just another file you had to click.

That’s exactly the sort of thing you notice when you’re using a tool every day, and it was irritating enough that I volunteered to take over maintenance.

(If you want to read more on this story, I wrote a couple of blog posts.)

What I’ve done since taking it over

Most of the changes are about making the “serve a directory” experience smoother, without turning it into a kitchen-sink web server.

1) Serve index pages by default (autoindex)

The first change was to make directory URLs behave like you’d expect: if index.html exists, serve it automatically. If it doesn’t, you still get a directory listing.

2) Prettier index pages

Once autoindex was in place, I then turned my attention to the fallback directory listing page. If there isn’t an index.html, you still need a useful listing — but it doesn’t have to look like it fell out of 1998. So I cleaned up the listing output and made it a bit nicer to read when you do end up browsing raw directories.

3) A config file

Once you’ve used a tool for a while, you start to realise you run it the same way most of the time.

A config file lets you keep your common preferences in one place instead of re-typing options. It keeps the “one command” feel, but gives you repeatability when you want it.

4) --host option

The ability to control the host binding sounds like an edge case until it isn’t.

Sometimes you want:

• only localhost access for safety;

• access from other devices on your network (phone/tablet testing);

• behaviour that matches a particular environment.

A --host option gives you that control without adding complexity to the default case.

The Bonjour feature (and what it’s for)

This is the part I only really appreciated recently: App::HTTPThis can advertise itself on your local network using mDNS / DNS-SD – commonly called Bonjour on Apple platforms, Avahi on Linux, and various other names depending on who you’re talking to.

It’s switched on with the --name option.

http_this --name MyService

When you do that, http_this publishes an _http._tcp service on your local network with the instance name you chose (MyService in this case). Any device on the same network that understands mDNS/DNS-SD can then discover it and resolve it to an address and port, without you having to tell anyone, “go to http://192.168.1.23:7007/”.

Confession time: I ignored this feature for ages because I’d mentally filed it under “Apple-only magic” (Bonjour! very shiny! probably proprietary!). It turns out it’s not Apple-only at all; it’s a set of standard networking technologies that are supported on pretty much everything, just under a frankly ridiculous number of different names. So: not Apple magic , just local-network service discovery with a branding problem.

Because I’d never really used it, I finally sat down and tested it properly after someone emailed me about it last week, and it worked nicely, nicely enough that I’ve now added a BONJOUR.md file to the repo with a practical explanation of what’s going on, how to enable it, and a few ways to browse/discover the advertised service.

(If you’re curious, look for _http._tcp and your chosen service name.)

It’s a neat quality-of-life feature if you’re doing cross-device testing or helping someone else on the same network reach what you’re running.

Related tools in the same family

App::HTTPThis is part of a little ecosystem of “run a thing here quickly” command-line apps. If you like the shape of http_this, you might also want to look at these siblings:

• https_this : like http_this, but served over HTTPS (useful when you need to test secure contexts, service workers, APIs that require HTTPS, etc.)

• cgi_this : for quick CGI-style testing without setting up a full web server stack

• dav_this : serves content over WebDAV (handy for testing clients or workflows that expect DAV)

• ftp_this : quick FTP server for those rare-but-real moments when you need one

They all share the same basic philosophy: remove the friction between “I have a directory” and “I want to interact with it like a service”.

Wrapping up

I like tools that do one job, do it well, and get out of the way. App::HTTPThis has been that tool for me for years and it’s been fun (and useful) to nudge it forward as a maintainer.

If you’re doing any kind of static site work — docs sites, little prototypes, generated output, local previews — it’s worth keeping in your toolbox.

And if you’ve got ideas, bug reports, or platform notes (especially around Bonjour/Avahi weirdness), I’m always happy to hear them.

The post App::HTTPThis: the tiny web server I keep reaching for first appeared on Perl Hacks.