Negli ultimi giorni Linus Torvalds, creatore di Linux e di Git, è tornato a far parlare di sé per i toni duri usati in una discussione tecnica. Al centro della polemica c’è una pull request (PR) inviata da un ingegnere di Meta, che Torvalds ha respinto con parole particolarmente severe.
Il fatto
Durante la finestra di merge del kernel Linux, un ingegnere di Meta ha inviato una PR contenente modifiche al codice. Torvalds ha reagito definendo il contributo «spazzatura», sottolineando due aspetti principali:
- Tempistica sbagliata: la PR è stata inviata troppo tardi rispetto alle richieste di Torvalds, che aveva chiesto sottomissioni anticipate a causa di impegni di viaggio.
- Qualità del codice: tra le modifiche contestate, Torvalds ha criticato in particolare l’aggiunta di una funzione di utilità chiamata
make_u32_from_two_u16(). Secondo lui, invece di semplificare, questa funzione introduceva ambiguità e rendeva il codice più difficile da leggere.
Torvalds ha spiegato che scrivere esplicitamente un’operazione come (a << 16) + b rende immediatamente chiaro quale sia la parte alta e quale la parte bassa del numero. L’uso di un “helper” generico, al contrario, crea incertezza e aumenta la possibilità di errori, oltre ad essere stato inserito in file di intestazione non specifici per l’architettura RISC-V.
Il principio in gioco: ridurre il carico cognitivo
Al di là dei toni, la critica di Torvalds tocca un punto importante nello sviluppo software: il codice dovrebbe ottimizzare per ridurre il carico cognitivo di chi lo legge.
Ogni volta che un programmatore deve saltare tra file o funzioni per capire cosa succede, compie un “micro–cambio di contesto” che richiede energia mentale. Lo stesso vale per i modelli di intelligenza artificiale che analizzano il codice: più funzioni e astrazioni ci sono, più aumenta la complessità da gestire.
Per questo, in alcuni casi, la ripetizione del codice può essere preferibile all’astrazione, perché mantiene l’operazione auto-contenuta e immediatamente comprensibile. Non sempre, ovviamente: helper e componenti condivisi restano utili quando bisogna garantire comportamenti coerenti in tutto il codicebase. Ma funzioni banali o ridondanti rischiano di complicare anziché semplificare.
L’equilibrio tra astrazione e chiarezza
Il dibattito si inserisce in una riflessione più ampia: con strumenti moderni come IDE avanzati e LLM (Large Language Models) sempre più capaci di leggere e rifattorizzare il codice, il “costo” della duplicazione si è abbassato. Invece, il costo del codice eccessivamente astratto — difficile da capire e da manutenere — rimane alto.
In questo senso, il principio “PRY – Please Repeat Yourself” può essere visto come una forma di locality of reference cognitiva: mantenere il codice vicino e leggibile dove serve, senza costringere chi legge a inseguire riferimenti tra file diversi.
La questione del tono
Un’ultima nota riguarda lo stile con cui Torvalds ha espresso le sue critiche. La sua durezza non è nuova, ma resta un punto delicato: essere troppo bruschi rischia di creare un clima di paura e sfiducia, disincentivando la collaborazione. Come osservano altri sviluppatori, “non costa nulla essere gentili” — e questo vale anche nel mondo open source.
Infatti, questo episodio non è isolato. Torvalds è famoso per il suo stile diretto, spesso definito brutale. Alcuni casi noti:
- Il “F* You, NVIDIA” del 2012**: durante una sessione di domande all’Università di Aalto in Finlandia, Torvalds mostrò il dito medio parlando di NVIDIA, criticandola duramente per la mancanza di supporto a Linux.
- Le discussioni sulle mailing list del kernel: negli anni, non sono mancati scambi accesi con sviluppatori e aziende, al punto che nel 2018 Torvalds decise di prendersi una pausa per riflettere sui suoi toni e introdurre un code of conduct nel progetto Linux.
Questi episodi hanno contribuito a costruire la sua immagine di leader tecnico inflessibile, ma anche di persona con uno stile comunicativo spesso divisivo.
Conclusione
L’episodio dimostra ancora una volta quanto la leggibilità del codice e la riduzione del carico cognitivo siano elementi centrali nello sviluppo software. La discussione non è solo tecnica: riguarda il modo in cui si scrive codice destinato a essere letto, mantenuto e migliorato da altre persone — e ora anche da sistemi di intelligenza artificiale.
