Ibm on Melabit

70 anni di Fortran (più o meno)

Sun, 06 Oct 2024 06:00:00 +0000

Pochi giorni fa, il 20 settembre per essere precisi, il Fortran ha compiuto 70 anni.¹ La data scelta per il compleanno è un po’ anomala, per i software di solito si celebra la data in cui vengono presentati al pubblico,² mentre per il Fortran è stato scelto il giorno in cui gli sviluppatori dell’IBM hanno eseguito il primo programma scritto in questo linguaggio, ben tre anni prima della presentazione ufficiale.

Ad alto livello

Ed è una decisione pienamente giustificata, poiché il 20 settembre del 1954 accade qualcosa che avrebbe fatto la storia: per la prima volta un computer esegue un programma scritto in un linguaggio ad alto livello, molto più vicino al modo di pensare di un uomo, invece che in un linguaggio comprensibile solo alle macchine come l’assembler.

Un evento cruciale, che avrebbe reso la programmazione accessibile ad un numero sempre maggiore di persone, aprendo la strada alla diffusione capillare dei computer e innescando una trasformazione radicale della società e della nostra vita quotidiana. Non a caso David Padua³ sostiene che

è quasi universalmente riconosciuto che l’evento più importante del XX secolo nel campo dei compilatori – e in quello dell’informatica [in generale, ndt] – è stato lo sviluppo del primo compilatore Fortran tra il 1954 e il 1957. Dimostrando che è possibile generare automaticamente codice macchina di qualità a partire da descrizioni ad alto livello, il team IBM guidato da John Backus aprì le porte all’era dell’informazione.

Il primo programma?

Per quanto abbia cercato non sono riuscito a trovare il codice di questo primo programma in Fortran, ma non dovrebbe essere troppo diverso da questo,

– IBM 704 Fortran Programmer’s Reference Manual, 1956.

che cerca il numero più grande in una lista di numeri fornita dall’utente. Il programma è molto semplice e può analizzare non più di 999 numeri ma, quando l’unica alternativa era scorrere a mano colonne e colonne di numeri, doveva essere un bel passo in avanti.

Da notare la presenza dell’istruzione FREQUENCY, rimossa nelle versioni successive e più efficienti del compilatore, con la quale il programmatore poteva stimare il numero di volte in cui ciascun ciclo DO o test logico IF poteva essere eseguito, dando modo al compilatore di ottimizzare il codice macchina generato. L’ottimizzazione si basava sul nuovo (per l’epoca) metodo Monte Carlo, che non è per niente difficile da padroneggiare, ma che deve essere piuttosto difficile da programmare in un linguaggio a basso livello come l’assembler. Tanto di cappello per gli sviluppatori del primo Fortran!

Ottimizzare ottimizzare ottimizzare

La questione dell’ottimizzazione del codice generato dal compilatore era essenziale per il successo del nuovo compilatore Fortran. I computer di allora erano estremamente lenti e costosi, e i programmi dovevano essere molto efficienti per riuscire ad eseguire le operazioni richieste senza inutili sprechi di risorse. Il team IBM era consapevole che

se il Fortran, nei suoi primi mesi di vita, fosse in grado di tradurre qualsiasi programma sorgente scientifico ragionevole in un programma oggetto con una velocità pari alla metà di quella della sua controparte codificata a mano, l’accettazione del nostro sistema sarebbe in serio pericolo.

E ci sono riusciti. Un programma scritto in Fortran e tradotto in codice macchina attraverso il primo compilatore risultava effettivamente più lento di uno equivalente scritto in assembler, ma molto meno di quanto avessero temuto inizialmente gli sviluppatori.

Il grande vantaggio di poter programmare utilizzando un linguaggio ad alto livello, con una sintassi molto vicina all’inglese, compensava ampiamente questa perdita di prestazioni. Non a caso, in pochi anni l’uso dei linguaggi ad alto livello si diffuse così tanto da mandare l’assembler nel dimenticatoio.

Notarelle finali

Il manuale della prima versione del Fortran era davvero smilzo, appena 54 pagine. Niente a che vedere con i giganteschi tomi odierni, che riempiono 4-500 pagine per insegnare i rudimenti di un linguaggio di programmazione o di uno strumento software.

Negli anni ‘80 il Fortran era così popolare in ambito scientifico che poteva essere usato non solo sui grossi mainframe o sulle workstation e i minicomputer tanto diffusi in ambito universitario, ma perfino sui microcomputer economici come il Commodore 64 e lo Spectrum 48K, oppure (c’è bisogno di dirlo?) sul più potente Apple II. Certo, su queste macchinette non si poteva pensare di far girare una simulazione meteorologica o di generare un frattale in tempo reale, ma per imparare nella comodità di casa propria potevano essere più che sufficienti.

È curioso che i tre principali linguaggi di programmazione sviluppati negli anni ‘50, Fortran (1954), LISP (1958) e COBOL (1959) siano ancora in uso oggi, dividendosi in modo netto i campi di applicazione: il Fortran per il calcolo scientifico ed ingegneristico, il COBOL in campo finanziario e bancario. E il LISP? Beh, il LISP sta ben nascosto in tante cose odierne, fra cui emacs e Julia, e comunque rimane sempre il più affascinante dei tre.

Bibliografia

Qualche link per chi volesse approfondire:

Il sito di riferimento del linguaggio Fortran, fortran-lang.org.
A Brief History of FORTRAN/Fortran.
David Padua, The Fortran I Compiler, Computing in Science & Engineering, 2000.
Lee Phillips, Scientific computing’s future: Can any coding language top a 1950s behemoth?, Ars Technica, 2014.
Rud Merriam, This Is Not Your Father’s FORTRAN, Hackaday, 2015.
Liam Tung, This old programming language is suddenly hot again. But its future is still far from certain, ZDNET, 2021.

Lo so, ormai non sono più tanto pochi, ma negli ultimi tempi sono stato assorbito dal trasloco imprevisto del nostro istituto a causa di urgenti lavori di ristrutturazione. ↩︎
Anche in modo informale, come è successo per Linux, presentato per la prima volta su un newsgroup dedicato ad un sistema operativo ormai dimenticato. ↩︎
David Padua è professore emerito presso il Dipartimento di Informatica dell’università dell’Illinois a Urbana-Champaign. ↩︎

Schede perforate: Dal sottosuolo

Sun, 23 Oct 2022 06:00:00 +0000

– Fonte: What obsolete computer punch cards reveal about the history of information design in today’s era of unseen data.

Sono stato combattuto a lungo sul nome da dare a questa serie. In un primo momento avevo scelto “Racconti dal sottosuolo”. I primi computer che ho usato stavano proprio sotto terra, prima sotto il vecchio Dipartimento di Fisica di Torino e l’anno dopo nella dependance sotterranea del centro di calcolo dell’Università (ora c’è un supermercato), dove riuscivo ad entrare di straforo grazie all’aiuto di un amico che studiava informatica. Stare sottoterra, quindi, è stato per me all’inizio una condizione naturale per usare un computer.

Ma ripensandoci “Racconti dal sottosuolo” era un titolo troppo altisonante, quasi dostojevskiano, e anche troppo personale per essere comprensibile ai più.

E allora è diventato quasi ovvio scegliere “Schede perforate”. Sono abbastanza vecchio da averle usate per un anno, proprio in quel primo anno passato molto spesso nel sotterraneo di Fisica, e per me rimangono ancora associate in modo indissolubile al computer. Ne ho ancora alcune nella mia piccola collezione di vecchie glorie del computing, un paio di schede continuano ancora ad emergere ogni tanto da una montagnola di carte accanto mia scrivania, ma non mi decido mai a metterle in un posto più adatto.

Usare un computer con le schede perforate era un bell’affare. Bisognava scrivere con pazienza il programma sulle schede, una riga di codice per scheda, usando una specie di macchina da scrivere elettrica accoppiata ad un grosso macchinario che prendeva le schede nuove da una pila, le bucava nei punti giusti e infine spostava la scheda finita su una seconda pila, pronta per essere letta dal computer.

– Perforatrice modello IBM 029. Fonte: Columbia University Computing History.

Di queste perforatrici, tutte IBM naturalmente, allora IBM era la dominatrice indiscussa del mercato dei computer “seri”, nel piccolo sotterraneo di Fisica ce ne saranno state almeno una decina e il rumore che facevano era infernale. Pochi giorni fa un membro giovane del gruppo si lamentava del ronzio del server nella sua stanza, avrei voluto fargli sentire cosa c’era laggiù!

Una volta pronte le schede, bisognava prendere la pila e portarla nella stanzetta del lettore, aspettando pazientemente il proprio turno per farle leggere ed elaborare. A questo punto era solo una questione di fortuna, se il computer centrale era scarico o se per qualche combinazione astrale il proprio job riusciva a passare davanti agli altri, si poteva avere una risposta in pochi minuti, altrimenti potevano passare benissimo delle ore. Sempre sperando che il programma non finisse in un loop infinito e dovesse essere interrotto di brutto da un qualche sacerdote in camice bianco che stava chissà dove, una circostanza che veniva annunciata a piena voce nella stanzetta del lettore, a pubblico ludibrio del colpevole. Chiaro che, dopo un paio di volte che succedeva si stava bene attenti a non sottomettere un job prima di averlo controllato più che bene.

Se invece il programma si concludeva correttamente, prima o poi uscivano i risultati dell’elaborazione, stampati su degli enormi fogli perforati che bisognava imparare a tagliare alla perfezione senza mai interrompere il flusso di carta della stampante. Magari ci si era dimenticati di una virgola, e tutto quello che si otteneva era un messaggio di errore indecifrabile. Nel qual caso bisognava tornare alla perforatrice, correggere le schede sbagliate e ripetere tutto il processo.

Una vera tortuna, ma anche una scuola impareggiabile di precisione e di cura maniacale dei dettagli.

Un problema non da poco con le schede perforate è che bisognava portarle da una stanza all’altra, districandosi fra gli studenti che andavano e venivano. Io per fortuna usavo il FORTRAN e le mie pile di schede erano maneggiabili con facilità, ma per gli informatici che usavano il COBOL erano dolori. Non so niente di COBOL ma so benissimo da quegli anni che è un linguaggio di programmazione molto verboso, per cui le sue pile di schede erano molto, molto alte. Non ho mai dimenticato la ragazza buttata per terra a piangere dopo che aveva fatto cadere per terra una pila di centinaia e centinaia di schede perforate in COBOL per la tesi.

E non oso nemmeno immaginare cosa avrebbe fatto la signora fotografata qui sotto se fosse successo a lei.

– Il programma (presumibilmente) più lungo scritto con le schede perforate occupa ben 62.500 schede, corrispondenti a 5 MB di dati. Fonte: Computer Hope, Punch card.