{"id":34075,"date":"2025-09-23T12:57:56","date_gmt":"2025-09-23T10:57:56","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=34075"},"modified":"2025-09-23T15:13:45","modified_gmt":"2025-09-23T13:13:45","slug":"linus-torvalds-contro-un-ingegnere-di-meta-quando-il-codice-diventa-spazzatura","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/linus-torvalds-contro-un-ingegnere-di-meta-quando-il-codice-diventa-spazzatura\/","title":{"rendered":"Linus Torvalds contro un ingegnere di Meta: quando il codice diventa \u201cspazzatura\u201d"},"content":{"rendered":"\n

Negli ultimi giorni Linus Torvalds<\/strong>, creatore di Linux <\/a>e di Git, \u00e8 tornato a far parlare di s\u00e9 per i toni duri usati in una discussione tecnica. Al centro della polemica c\u2019\u00e8 una pull request<\/em> (PR) inviata da un ingegnere di Meta, che Torvalds ha respinto con parole particolarmente severe.<\/p>\n\n\n\n

Il fatto<\/h2>\n\n\n\n

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 \u00abspazzatura\u00bb, sottolineando due aspetti principali:<\/p>\n\n\n\n

    \n
  1. Tempistica sbagliata<\/strong>: la PR \u00e8 stata inviata troppo tardi rispetto alle richieste di Torvalds, che aveva chiesto sottomissioni anticipate a causa di impegni di viaggio.<\/li>\n\n\n\n
  2. Qualit\u00e0 del codice<\/strong>: tra le modifiche contestate, Torvalds ha criticato in particolare l\u2019aggiunta di una funzione di utilit\u00e0 chiamata make_u32_from_two_u16()<\/code>. Secondo lui, invece di semplificare, questa funzione introduceva ambiguit\u00e0 e rendeva il codice pi\u00f9 difficile da leggere.<\/li>\n<\/ol>\n\n\n\n

    Torvalds ha spiegato che scrivere esplicitamente un\u2019operazione come (a << 16) + b<\/code> rende immediatamente chiaro quale sia la parte alta e quale la parte bassa del numero<\/strong>. L\u2019uso di un \u201chelper\u201d generico, al contrario, crea incertezza e aumenta la possibilit\u00e0 di errori, oltre ad essere stato inserito in file di intestazione non specifici per l\u2019architettura RISC-V.<\/p>\n\n\n\n

    Il principio in gioco: ridurre il carico cognitivo<\/h2>\n\n\n\n

    Al di l\u00e0 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<\/strong>.<\/p>\n\n\n\n

    Ogni volta che un programmatore deve saltare tra file o funzioni per capire cosa succede, compie un \u201cmicro\u2013cambio di contesto\u201d che richiede energia mentale. Lo stesso vale per i modelli di intelligenza artificiale che analizzano il codice: pi\u00f9 funzioni e astrazioni ci sono, pi\u00f9 aumenta la complessit\u00e0 da gestire.<\/p>\n\n\n\n

    Per questo, in alcuni casi, la ripetizione del codice pu\u00f2 essere preferibile all\u2019astrazione<\/strong>, perch\u00e9 mantiene l\u2019operazione 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\u00e9 semplificare.<\/p>\n\n\n\n

    L\u2019equilibrio tra astrazione e chiarezza<\/h2>\n\n\n\n

    Il dibattito si inserisce in una riflessione pi\u00f9 ampia: con strumenti moderni come IDE avanzati e LLM (Large Language Models)<\/strong> sempre pi\u00f9 capaci di leggere e rifattorizzare il codice, il \u201ccosto\u201d della duplicazione si \u00e8 abbassato. Invece, il costo del codice eccessivamente astratto \u2014 difficile da capire e da manutenere \u2014 rimane alto.<\/p>\n\n\n\n

    In questo senso, il principio \u201cPRY \u2013 Please Repeat Yourself\u201d pu\u00f2 essere visto come una forma di locality of reference<\/em> cognitiva: mantenere il codice vicino e leggibile dove serve, senza costringere chi legge a inseguire riferimenti tra file diversi.<\/p>\n\n\n\n

    La questione del tono<\/h2>\n\n\n\n

    Un\u2019ultima nota riguarda lo stile con cui Torvalds ha espresso le sue critiche. La sua durezza non \u00e8 nuova, ma resta un punto delicato: essere troppo bruschi rischia di creare un clima di paura e sfiducia, disincentivando la collaborazione<\/strong>. Come osservano altri sviluppatori, \u201cnon costa nulla essere gentili\u201d \u2014 e questo vale anche nel mondo open source.<\/p>\n\n\n\n

    Infatti, questo episodio non \u00e8 isolato. Torvalds \u00e8 famoso per il suo stile diretto, spesso definito brutale. Alcuni casi noti:<\/p>\n\n\n\n

      \n
    • Il \u201cF<\/strong>* You, NVIDIA\u201d del 2012**: durante una sessione di domande all\u2019Universit\u00e0 di Aalto in Finlandia, Torvalds mostr\u00f2 il dito medio parlando di NVIDIA<\/strong>, criticandola duramente per la mancanza di supporto a Linux.
      <\/li>\n\n\n\n
    • Le discussioni sulle mailing list del kernel<\/strong>: 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<\/em> nel progetto Linux.<\/li>\n<\/ul>\n\n\n\n

      Questi episodi hanno contribuito a costruire la sua immagine di leader tecnico inflessibile, ma anche di persona con uno stile comunicativo spesso divisivo.<\/p>\n\n\n\n

      \n