Martin Alderson ha scritto Which programming languages are most token-efficient?, un esperimento per capire quanti token servono a scrivere la stessa cosa in linguaggi diversi.

La premessa è semplice: “One of the biggest constraints LLMs have is on context length”, e quindi “a more token efficient language should allow longer sessions and require fewer resources”. Se il context è la risorsa scarsa, la verbosità del linguaggio diventa un costo operativo.

Come ha fatto

Ha preso RosettaCode — oltre 1.000 task implementati in quasi 1.000 linguaggi — e ha usato Claude Code per analizzare un mirror GitHub del dataset. Ha scelto 19 linguaggi popolari, tenendo solo i task che avevano un’implementazione in tutti e 19, e ha contato i token con il tokenizer Xenova/gpt-4 da Hugging Face.

I numeri

• Clojure: 109 token di media, il più efficiente del gruppo
• Haskell: ~110
• F#: ~111
• JavaScript: 128
• C: 283, il peggiore

Tra il migliore e il peggiore ci sono 2,6x. In un update ha aggiunto il linguaggio J, che si piazza a 70 token di media — quasi la metà di Clojure. APL sta a 110.

Due pattern:

• i linguaggi dinamici battono quelli tipizzati staticamente, semplicemente perché non devi scrivere le dichiarazioni di tipo;
• i funzionali con type inference forte (Haskell, F#) tengono il passo dei dinamici pur restando tipizzati. Questa è la parte che sorprende.

TypeScript è rimasto fuori: su RosettaCode non c’erano abbastanza esempi.

Il disclaimer, che conta

Alderson è esplicito: “There are many, many potential limits and biases involved in this dataset and approach! It’s meant as a interesting look at somewhat like-for-like solutions to some programming tasks, not a scientific study.”

E ha ragione. RosettaCode è crowdsourced, i task sono esercizi da manuale, il tokenizer è un port della community. Nessuno dovrebbe migrare a Clojure per risparmiare context.

Cosa mi porto a casa

Il numero in sé non mi serve. Mi interessa la direzione: se il context è la risorsa che si esaurisce per prima durante una sessione con un agent, allora la densità del codice smette di essere una questione di gusto e diventa un parametro operativo. La stessa cosa vale per tutto il resto che finisce nel context — file di configurazione, log, output dei tool.

La conclusione di Alderson è che la token efficiency “starts becoming a factor in language selection in the future”. Per un progetto nuovo, forse. Per il codice che ho già in produzione, la leva vera è un’altra: decidere cosa non far entrare nel context.