The Joy of Scripting

This article is a draft, and is half here to test out things as I build this site.

Here’s a (potentially) controversial statement for 2025: I really like scripting languages. At my day job, I use a proprietary programming language called q, which you can imagine as a mix of APL, SQL, and Haskell, that’s designed for dealing with the massive amounts of timeseries data that one encounters working in finance. When at home, I’ll categorize my video game documentaries with Perl, make puzzles for my friends in Python, and sync music to my MP3 player with shell scripts.

There’s just something so visceral and alive about coding when the feedback I get is instant, when I’m able to develop and iterate and learn at the speed of thought, that makes me love using dynamically typed, interpreted languages, and that lets me use them to glue my system together.

Of course, if you’re an old-school unix-like power user, this is nothing new. But it feels like nowadays static compilation, bloated runtimes, and type safety is all the rage. Everything is built with TypeScript or Rust. Or research is being done in Jupyter Notebooks, which while certainly interactive, make me feel locked out of my terminal-based workflow. I feel like a dinosaur writing Perl in this day and age. Why is that?

To be clear, I’m not arguing that everything should be scripted together, or even that most things should. I actually love writing C and Rust. To be honest, I don’t even think that the lack of people scripting things together is a problem. I just want to write a love letter to an underappreciated, productive, and fun way of doing computer things.

The Values of Scripting#

To me, scripting isn’t really about a specific language, or paradigm, or environment (although sure, I wouldn’t consider writing C to be scripting). It’s really a philosophy of approaching problem solving with code, one characterized by the following four qualities:

1. Creativity#

()

Perl’s slogan – There’s More Than One Way To Do It – is a great expression of this.

()

2. Extensibility#

3. Expressivity#

()

Naturally, this means that good things for scripting are terrible for “production” software. The fact that I can write

my %dict;
$dict["apple"]++;
print $dict["apple"]; #=> 1

is, to me, really cool! I only have to write the code that actually expresses what I want to do.

Another feature of scripting is that you try to remove abstraction. Assume things about the

4. Conciseness#

Because you’re heavily optimizing for a specific use case, you don’t need to write boilerplate or error handling or whatever. In fact, I’d argue that the ability to be terse and run with little overhead is what makes something a “scripting language”¹

There’s very little mental overhead. ()

A consequence of this is that I rarely refactor scripts. When I have to test out an idea at work, I’ll open Neovim, connect to a REPL, copy in a bunch of code fragments from related scripts, and patch things together. Given the variable demands of quantitative research, this is way more productive than trying to design ().

Put this way, I think it’s clear why scripting as I’ve described it takes a lot from the Unix philosophy. It’s all about being clever, hacking things together, and then moving on. It views code as more ephemeral and alive than I often see. Sure, you don’t want, say, a database to be ephemeral, but philosophically, I think it’s good to not get attached to things.

Interactivity#

One of my favorite talks ever is Stop Writing Dead Programs, by Jack Rusher. I distinctly remember the first time I heard it, feeling like it reified so much of my frustrations with writing static, compiled code.

Gluing Things Together#

In my experience, the hard part of writing software kind of has nothing to do with code, but with data. Our job, as programmers, is to manipulate, process, extract, and understand data. The problem is that data is hard.