Diverting trains of thought, wasting precious time
Sat, 31 Jan 2026
Enabling monoglot programming
“Polyglot programming” is a wrong metaphor. It's taken me about fifteen years to realise this.
In his keynote at <Programming> back in June last year, Thomas Wuerthinger made an intriguing comment, something like “people don't actually like polyglot programming, because programming in one language is hard enough already”. He was talking about GraalVM and the considerable efforts made within that project to support multi-language programming. In hindsight, to him the effort did not seem so well-spent.
This reminded me of Python CFFI's onetime stated selling point, that to using it “requires user to know only Python and C”. It never sounded right to me. Surely that's one language too many?!
There's a conceptual muddle at the heart of “polyglot programming”. Polyglots are people conversant in multiple languages. One more time: they're people conversant in multiple languages. We want to lessen the need for this, not increase it! We want to do it by making the programming environment itself conversant in multiple languages, so that the programmer doesn't have to be.
In a programming environment with the ideal multi-language support, the programmer could be a happy monoglot. In particular, the programmer would have access to a wide universe of code, regardless of its implementation language, and be free to use that code from their language of choice. They would observe few or no artifacts of the unfamiliar implementation language. That's the true challenge worth solving: polyglot systems—not polyglot programmers, and not polyglot programming experiences that require the programmer to grapple with awkward mashups of multiple languages.
It's hard! Although I've done bits and bobs in this space for years now, in collaboration with others, so far we have only got as far as buildings some hypothetically useful foundations. A few years ago Guillaume Bertholon did an excellent project using these to enable wrapper-free use of native libraries from CPython—with various caveats and implementation defects remaining to be addressed, but much promise. My current PhD student Zoltan Meszaros is working on extending this in various ways, including handling the converse direction: allowing C (or other traditional toolchain code) to link directly against Python (or other VM-hosted code), and addressing some of the remaining resource management difficulties. One of the hard parts is making languages (or rather their implementations) peers of each other, rather than one trying to dominate (contain, wrap around, “host”, extend, embed) others. There is an unmet need for a thin userspace “bottom layer” that makes the process environment a truly federated, multi-tenant space. It would be a bit like a dynamic linker, but provide foundations usable not only by traditional toolchain but JIT compilers and the like. I am trying to get some thoughts together on this... more soon!
[/research] [all entries] permalink contact
