Python, reluctantly

I am a humanist, not an engineer or computer scientist: I make no apology for coding all of my work in a single programming language at any given moment. Let the engineers choose the best language for a given task. My scholarly contribution comes from my understanding of the material I study, so I happily, eagerly, assiduously give up the cognitive load of working in multiple programming languages simultaneously.

For a number of years, I genuinely enjoyed writing in Scala (and got really good at recursion, in the process). In the traumatic circumstances of the COVID-19 pandemic, I discovered and adopted Julia, as I described here. I gave up the ideological purity of writing side-effect free code in exchange for the mind-bending power of Julia’s multiple dispatch model, and the best environment and tooling I had ever experienced in 40 years of trying to get computers to bend to my will.

But now it’s 2026. Claude actually writes most of my code, and the research problems that most interest me center on how we can tease out of contemporary language models the extraordinarily rich encoding of natural languages lurking in their vectors of weights. And that means I really have to use Python.

There is not a single moment of joy for me in reading or writing Python code. Python’s syntax is a constant irritant, like an open wound that won’t heal. In the 1980s, I lost irretrievable hours of my life editing makefiles with semantically significant alignment of white space characters. How could I ever have imagined that I would voluntarily re-enter that hell in 2026? But I have, and now must agonize every time a simple copy and paste of Python code fails because of a space too many or too few. And yet, even though line breaks are already semantic, we have to add logically otiose trailing colons to all sorts of blocks. Why? And while there’s no arguing over tastes, I personally would much rather read code with explicit, symmetrical beginning and ending markers for hierarchically contained structural units, than try to guess how deeply indented a Python expression is. (Who can tell, when all you see is white space?) I don’t care if the markers are curly brackets, begin..end keywords, or some other convention. Explicit symmetric tokens make structure clear at glance, and have an aesthetic elegance I personally prefer. Python’s embedded structures just drift off further and further to the right. They always seem to me like a sloppy student’s first draft that was turned in without revision.

But we stand on the shoulders of giants, and the giants working with language models have decided that Python is where the work will happen. While this may reinforce my scepticism about the “wisdom of crowds,” the fact is that the libraries I want to use and the examples I want to study are virtually all in Python. Some of them really are wonderful, and I’ll be blogging about my work using DSPy in particular. But all in all, I’m happiest that Claude writes Python reliably and without complaint, so that I don’t have to.