Perché COBOL è definito l'amianto dei linguaggi di programmazione

Una parte rilevante dell’infrastruttura digitale mondiale continua a dipendere da software scritto più di 60 anni fa. Programmi storici scritti in COBOL, acronimo di Common Business-Oriented Language, continuano a resistere presso banche, assicurazioni, sistemi previdenziali, motorizzazione civile, reti di pagamento e piattaforme fiscali: per di più sono utilizzati quotidianamente ancora oggi per elaborare transazioni che valgono migliaia di miliardi di euro.

Durante il periodo pandemico, il problema è emerso in modo clamoroso negli USA, quando responsabili statali del New Jersey ammisero pubblicamente di non avere abbastanza programmatori COBOL per aggiornare il sistema di gestione dei disoccupati. Le richieste aumentarono in poche settimane a livelli mai previsti; il software, scritto decenni prima, non riusciva ad adattarsi con rapidità.

Perché COBOL nacque e perché ebbe tanto successo

Una quantità enorme di servizi essenziali dipende ancora da codice difficile da mantenere, scarsamente documentato e spesso legato a mainframe IBM che eseguono applicazioni sviluppate tra gli anni ’70 e ’90. Quei sistemi, per quanto antiquati, continuano a funzionare con una stabilità impressionante.

Paradossalmente, proprio questa affidabilità ha rallentato la loro sostituzione. Finché un sistema elabora stipendi, pensioni o bonifici senza errori evidenti, molte aziende preferiscono rimandare la migrazione: il risultato è una dipendenza tecnologica enorme; una sorta di debito accumulatosi lungo decenni di attività.

Alla fine degli anni ’50 il software rappresentava un problema economico serio: ogni produttore hardware utilizzava strumenti differenti e spostare un’applicazione da un computer a un altro richiedeva quasi una riscrittura completa. Nel 1959 un gruppo composto da aziende informatiche statunitensi e rappresentanti governativi, con figure come Grace Hopper, iniziò a progettare un linguaggio comune destinato alle applicazioni gestionali.

L’idea era radicale per l’epoca: creare un linguaggio leggibile quasi come inglese naturale. COBOL utilizzava istruzioni molto dettagliate e scritte in modo esteso, progettate per essere facilmente leggibili anche da persone senza competenze tecniche avanzate; parole chiave come IF, THEN, MOVE, PERFORM e DIVIDE. La sintassi cercava di avvicinare il codice a un testo amministrativo: anche personale non tecnico avrebbe potuto comprendere almeno il flusso logico di un programma.

La leggibilità funzionava bene solo su piccola scala: un frammento COBOL di poche righe risultava intuitivo; un’applicazione bancaria da centinaia di migliaia di linee molto meno. Molti progetti finirono rapidamente in una spirale di complessità difficile da governare.

Il problema strutturale del codice COBOL

Una parte delle critiche storiche contro COBOL nasceva dalla sua architettura: il linguaggio favoriva l’uso massiccio del comando GO TO, un salto incondizionato che trasferiva l’esecuzione in sezioni lontane del programma. Nei sistemi più grandi questa tecnica generava quello che gli sviluppatori chiamano spaghetti code: flussi logici intricati, difficili da seguire e quasi impossibili da modificare senza effetti collaterali.

Il matematico Edsger Dijkstra criticò duramente proprio questo approccio. Secondo lui il problema non era solo stilistico; il codice con salti incontrollati diventava troppo complesso da verificare mentalmente. E in un software finanziario, dove basta un errore minimo per alterare movimenti economici reali, la manutenibilità conta quanto le prestazioni.

Un altro limite storico riguardava la modularità. Le prime implementazioni COBOL non supportavano bene il passaggio parametrico dei dati tra moduli indipendenti: molte sezioni dell’applicazione condividevano aree di memoria comuni. Così, una modifica locale poteva propagarsi in modo imprevedibile all’intero programma.

La crisi dei programmatori COBOL e l’illusione della conversione automatica con l’AI

La scarsità di sviluppatori esperti rappresenta uno dei problemi più concreti poiché gran parte dei professionisti che hanno lavorato su questi sistemi si sta ritirando. Molte università hanno smesso di insegnare COBOL già negli anni ’90; di conseguenza il ricambio generazionale quasi non esiste.

Il problema non consiste solo nel conoscere il linguaggio: serve esperienza sui mainframe, comprensione dei processi amministrativi, familiarità con database storici come IMS o DB2 e capacità di lavorare con procedure batch stratificate nel tempo.

Negli ultimi due anni aziende come IBM, Fujitsu e diversi vendor specializzati hanno iniziato a proporre strumenti basati su AI generativa per tradurre applicazioni COBOL in Java o altri linguaggi moderni.

Il fatto è che tradurre sintatticamente il codice non basta: un’applicazione COBOL enterprise contiene dipendenze implicite, workflow amministrativi, strutture dati EBCDIC, file VSAM, job schedulati e logiche transazionali costruite nel corso di decenni. Un modello AI può convertire istruzioni; capire davvero il comportamento operativo di un’applicazione COBOL complessa è tutta un’altra storia.

Molti esperti parlano ormai di JOBOL: codice Java che replica fedelmente la struttura COBOL originale, mantenendone però rigidità e complessità. Il risultato spesso produce software difficile da mantenere, più costoso da eseguire e non necessariamente più sicuro.

Perché sostituire COBOL costa così tanto

L’AI sta comunque mostrando risultati utili: alcuni strumenti riescono a generare documentazione tecnica, mappare dipendenze tra moduli e identificare procedure ridondanti.

Fujitsu sostiene di ridurre drasticamente il tempo necessario per comprendere vecchie codebase; IBM lavora su piattaforme AI dedicate alla conversione assistita.

Anche AWS offre servizi di assessment per analizzare e valutare i workload COBOL eseguiti su mainframe, con l’obiettivo di comprenderne struttura, dipendenze e complessità prima di eventuali attività di modernizzazione o migrazione.

Il limite principale resta la verifica: un errore introdotto durante una migrazione potrebbe alterare pagamenti previdenziali, transazioni bancarie o calcoli fiscali. Per questo molte organizzazioni preferiscono approcci graduali.

COBOL continuerà a esistere ancora a lungo

L’idea di una scomparsa imminente di COBOL circola da almeno 30 anni. Eppure il linguaggio continua a gestire una parte rilevante della finanza mondiale: secondo diverse stime, una larga quota delle transazioni con carta di credito e ATM passa ancora attraverso sistemi COBOL eseguiti su mainframe IBM.

Il motivo è concreto: quei sistemi funzionano, scalano bene e raramente si fermano. Il problema nasce quando serve modificarli rapidamente oppure integrarli con architetture moderne basate su API, cloud e servizi distribuiti.

La vera sfida dei prossimi anni probabilmente non sarà eliminare COBOL del tutto; sarà renderlo interoperabile senza distruggere infrastrutture che milioni di persone usano quotidianamente senza nemmeno saperlo.