Quando il “C” fermò la ricerca

Piccola introduzione.
Da oggi l'amico Luca mi affiancherà nella pubblicazione di articoli su questo blog.


Luca è un programmatore , e ci racconterà il mondo della programmazione sotto l'aspetto storico, tecnico e sotto certi aspetti "filosofico".


Dopo aver ringraziato Luca per essersi unito a me vi lascio al primo articolo.
Buona lettura.

Quando il “C” fermò la ricerca

Siamo nei primi anni ’70. Frances Allen lavora all’IBM, anzi è a capo di un progetto molto 

ambizioso. Il progetto si chiama PTRAN e tratta di un ottimizzatore automatico per il 

compilatore Fortran ad alte prestazioni. La Allen ha capito come ottimizzare il codice 

generato dal compilatore Fortran in modo che automaticamente possa essere eseguito in 

modo efficiente sulle macchine IBM ad alto grado di parallelismo. Il progetto PTRAN ha un 

notevole successo, ma la strada verso l’ottimizzazione automatica del codice è appena 

iniziata. Ma ecco che ad una conferenza sui linguaggi e compilatori viene presentato un 

linguaggio nuovo e, a detta dei relatori che lo presentano, innovativo. Il linguaggio “C”. 

Questo linguaggio divide subito la comunità scientifica. Da un lato c’è chi lo ama, dall’altro 

chi intuisce che la ricerca sui compilatori è arrivata alla fine. Perché il C è così pericoloso? 

Perché nessuna ottimizzazione automatica è più necessaria. Tutto è demandato al 

programmatore che si dovrà occupare in prima persona di scrivere un codice adatto ad 

essere eseguito su più linee di elaborazione. Inoltre il programmatore dovrà scrivere 

codice sintatticamente e semanticamente perfetto, perché il compilatore C non farà 

nessun controllo statico del codice scritto. 

Ecco quindi che la ricerca sull’ottimizzazione automatica si è fermata quel giorno, quando 

il linguaggio C ha visto la luce (ed ha aperto la strada a tutti i linguaggi imperativi che oggi 

conosciamo) ed il progetto PTRAN è stato cancellato dall’IBM. Ma, come si dice, al peggio 

non c’è mai fine. Quarant’anni fa i “Supercalcolatori” con architettura parallela, li 

possedevano solo le grandi università o le grandi compagnie come la IBM, ma oggi, ogni 

computer, e persino quasi ogni smartphone, incorpora un processore con più di un “core” 

di elaborazione. Il calcolo parallelo è diventato una realtà che pervade ogni dispositivo. E il 

software? I programmatori, oggi si stanno rendendo conto di non possedere gli strumenti 

teorici per gestire la complessità derivante dalla programmazione parallela. 

Semplicemente non esiste la teoria per supportare questa enorme complessità. Si è 

tentato di equipaggiare i linguaggi di programmazione moderni con utility che avrebbero 

dovuto imbrigliare il multithreading e la programmazione parallela, ma la complessità da 

affrontare è troppo elevata e nessun programmatore è in grado oggi di affermare senza 

ombra di dubbio che il codice che ha scritto è assolutamente “thread-safe”. Se afferma il 

contrario, mente, o ha sottovalutato il problema all’origine.

Qualcosa però si sta muovendo. Consapevoli di questo empasse di 40 anni i ricercatori 

stanno cercando di recuperare terreno. Tecnologie di ottimizzazione automatica stanno 

nascendo sia a livello di sistema operativo (come la tecnologia GCD), sia a livello di 

compilazione come nel compilatore Clang (LLVM) di Apple o per il compilatore Haskell 

GHC che utilizza la tecnologia DPH (Data Parallel Haskell), o ancora con PLINQ 

incorporato nel framework .NET. Ma la strada è ancora lunga. Siamo appena all’inizio. 

Frances Allen, che nel 2006 ha ricevuto l’ACM Turing Award (il Nobel per chi pratica la 

nostra disciplina), ha fatto una considerazione interessante riguardo al futuro della 

Computer Science: “Se noi consideriamo che discipline come la Fisica o la Matematica 

hanno avuto secoli di evoluzione, se confrontata con una disciplina come la Fisica, la 

Computer Science è oggi ai tempi di Newton. Esistono interi orizzonti inesplorati verso i 

quali dobbiamo incamminarci senza paura.”

Luca Ciciriello.