Experimental design for non-compliance, and Perl arcania

We learn a little experimental design for when subjects opt out of the treatment branch we have planned for them. We also learn about an extremely un-useful Perl feature.

I hope your week is going well!

New articles

Intention-to-Treat Experiments

If we have randomly selected some days to listen to music, and recorded our mood on the days we've listened to music, and music days are associated with improved mood, can we conclude that music improves mood? It depends on how well we managed to stick with the random assignments we set out to follow. In this article, we learn how to handle non-compliance with random assignment – important in self-experimentation, medicine, and product development.

Full article (5–10 minute read): Intention-to-Treat Experiments

Flashcard of the week

We haven't seen a Perl one, so let's look into one of the less well-known features of Perl: prototypes.

In Perl versions greater than 5.36, we can define functions much like we would in any other dynamically-typed language, i.e.

sub scream ($greeting) {
  uc("$greeting!!!!");
}

When called with e.g. scream("hello") this would return "HELLO!!!!". In earlier Perl versions (and indeed in most Perl code I write still, for compatibility reasons), we had to rely on the arguments being passed implicitly in the @_ array, meaning we often start the function by destructuring this array:

sub scream {
  my ($greeting) = @_;
  uc("$greeting!!!!");
}

However, these earlier versions of Perl had a confusing syntax that looked sort of like a signature, but is not: prototypes. The following code defines a function that is subtly different:

sub scream ($) {
  my ($greeting) = @_;
  uc("$greeting!!!!");
}

The flashcard asks,

What is the difference between (scream "hello", scream "world") when scream is declared with a ($) prototype vs. the default prototype of (@)?

This is not something I expect any of my readership to know, but it has to do with precedence. When a function in Perl is declared with a ($) prototype, it is treated as a unary operator. In other words, (scream "hello", scream "world") would be interpreted as two function calls in a list, resulting in the list ("HELLO!!!!", "WORLD!!!!"). With the default prototype, Perl reads everything up to the end-of-expression as part of the argument list for the function, so it would read the same list as (scream ("hello", scream ("world"))), and our scream implementation throws away everything except the first argument, so the result would be the singleton list ("HELLO!!!!").

This is why, even if one finds an apparent unary operator, it is unsafe in Perl to add the ($) prototype to formally make it a unary operator. Some existing code may rely on it being interpreted the other way around! (And vice versa, of course.)

These days, I think most people agree prototypes were a mistake, or at least not as useful as they initially seemed. Hence why modern Perl replaces the prototype syntax with more normal function signatures. But it's a fun bit of arcane knowledge!

Premium newsletter

Once I've forecast on all questions in the ACX 2025 competition (six to go!), I will send out the next premium newsletter. It will contain three great links, two book recommendations (covering investing and polar expeditions), a link to a future article that's not yet published, and the ACX 2025 forecast rationales.

If any of this sounds interesting, you should upgrade to a premium subscription! If you upgrade now, you will pay only $2/month – as interest increases and I learn to hit my stride with publishing these, the price will be set higher for future subscribers. As always, you can cancel at any time.

To upgrade, click the subscription link at the top of this newsletter and fill in your email again.

If you subscribe now, you should also get access to the previous premium newsletter which went out a couple of weeks ago. It contained three great links, and nearly three full-length articles, on topics as diverse as:

• How to talk to children (and uncooperative adults),

• How insurance companies buy insurance, and

• How I made my forecasts in the 2025 Vox Future Perfect forecasting competition.

Your opinions

I cannot improve without feedback. Reply to this email to share your thoughts on any of the topics above, or anything else!