All’inizio del Pandemia di Covid-19, il governatore del New Jersey ha fatto un’ammissione insolita: period a corto di sviluppatori COBOL. I sistemi statali di assicurazione contro la disoccupazione erano scritti nel linguaggio di programmazione vecchio di 60 anni e dovevano essere aggiornati per gestire centinaia di migliaia di richieste di risarcimento. Il problema period che pochi dipendenti statali sapevano come farlo. E la crisi andò oltre il New Jersey, solo uno dei tanti stati che dipendevano da questi sistemi ingombranti. Secondo un calcolo approssimativo, le inefficienze del COBOL costano al PIL degli Stati Uniti 105 miliardi di dollari nel 2020.
Si potrebbe pensare che il New Jersey avrebbe sostituito il suo sistema dopo questo, e che il Covid sia stato l’ultimo sussulto del COBOL. Non proprio. Il nuovo sistema di disoccupazione dello stato ha comportato una serie di miglioramenti nella qualità della vita, ma, dal punto di vista finanziario, period ancora reso possibile da un mainframe che eseguiva l’antica lingua.
COBOL, abbreviazione di Widespread Enterprise-Oriented Language, è il linguaggio informatico più adottato nella storia. Dei 300 miliardi di righe di codice scritte entro il 2000, l’80% period in COBOL. È ancora ampiamente utilizzato e supporta un gran numero di sistemi governativi, come i registri dei veicoli a motore e l’assicurazione contro la disoccupazione; in un dato giorno, può gestire qualcosa nell’ordine di Valore 3mila miliardi di dollari delle transazioni finanziarie. Penso a COBOL come a una sorta di amianto digitale, quasi onnipresente un tempo e ora incredibilmente, pericolosamente difficile da rimuovere.
COBOL fu proposto per la prima volta nel 1959 da un comitato che comprendeva la maggior parte dell’industria informatica statunitense (inclusa Grace Hopper). Richiedeva “specifiche per un linguaggio commerciale comune per i pc digitali automatici” per risolvere un problema crescente: il costo della programmazione. I programmi venivano scritti su misura per macchine specifiche e, se si voleva eseguirli su qualcos’altro, ciò significava una riscrittura quasi totale. Il comitato si è rivolto al Dipartimento della Difesa, che ha accolto con gioia il progetto.
Il design di COBOL lo distingueva dagli altri linguaggi sia allora che adesso. Doveva essere scritto in un inglese semplice in modo che chiunque, anche i non programmatori, potesse usarlo; la notazione matematica simbolica fu aggiunta solo dopo un considerevole dibattito. La maggior parte delle versioni di COBOL consentono l’uso di centinaia di parole (Java ne consente solo 68), inclusi “is”, “then” e “to”, per facilitare la scrittura. Alcuni hanno addirittura affermato che COBOL period destinato a sostituire i programmatori di pc, che negli anni ’60 occupavano un posto esclusivo in molte aziende. Erano maestri di una tecnologia che la maggior parte delle persone riusciva a malapena a comprendere. I progettisti di COBOL speravano anche che generasse la propria documentazione, risparmiando tempo agli sviluppatori e rendendola più semplice. mantenere nel lungo periodo.
Ma cosa significava essere leggibile? I programmi non sono libri o articoli; sono insiemi condizionali di istruzioni. Sebbene COBOL potesse distillare la complessità di una singola riga di codice in qualcosa che chiunque potesse capire, quella distinzione andò in pezzi nei programmi che contenevano migliaia di righe. (È come un manuale di assemblaggio dell’Ikea: ogni passaggio è facile, ma in qualche modo il tutto ancora non funziona.) Inoltre, COBOL è stato implementato con una logica che è diventata disprezzata: l’istruzione GO TO, un meccanismo di ramificazione incondizionato che ti mandava a razzo da una sezione di un programma a un’altra. Il risultato è stato uno “spaghetti code”, come piace dire agli sviluppatori, che ha reso l’autodocumentazione fuori questione.
Molti scienziati informatici hanno avuto problemi con COBOL fin dall’inizio. Edsger Dijkstra lo detestava, come è noto, affermando: “L’uso del COBOL paralizza la mente; il suo insegnamento dovrebbe, pertanto, essere considerato un reato penale”. Allo stesso modo Dijkstra odiava l’istruzione GO TO, sostenendo che rendeva i programmi quasi impossibili da comprendere. C’period un certo grado di vero snobismo: COBOL veniva spesso considerato un linguaggio puramente utilitaristico destinato a risolvere problemi noiosi.
Jean Sammet, uno dei progettisti originali, la vedeva diversamente: il linguaggio aveva semplicemente il complicato compito di rappresentare cose complicate, come la sicurezza sociale. O come ha scritto un altro difensore: “Purtroppo, ci sono troppi programmi applicativi aziendali scritti da programmatori a cui non è mai stato insegnato bene il vantaggio del COBOL strutturato”. Un buon COBOL period effettivamente autodocumentante, ma molto dipendeva dal programmatore specifico. Fred Gruenberger, un matematico della Rand Company, la mette in questo modo: “COBOL, nelle mani di un maestro, è uno strumento meraviglioso, uno strumento molto potente. COBOL, poiché verrà gestito da qualche impiegato di basso livello, sarà un disastro miserabile.”
