Loading...

Grace Hopper and Grasshopper: what a coincidence!

Grace Hopper and Grasshopper: what a coincidence!

Grace Hopper and Grasshopper: what a coincidence!

This is a post I originally wrote in 2009, in Italian. I knew I was right when I first made the connection between Grasshopper for Rhino and Grace Murray Hopper. To me, her work on Automatic programming was an obvious inspiration for the development of Grasshopper! David Rutten has then confirmed my feeling by paying homage to Grace Murray Hopper every year, on 9th December, through the Grasshopper banner. Rutten is a clever guy! (See this post here).

Forse ci si ricorderà della Hopper principalmente per il suo contributo al bug del millennio, dovuto alla difficoltà dei programmi di accettare il passaggio dal 1999 al 2000, con la data di sole due cifre, piuttosto che il ritorno al 1900. Però in questo caso vorrei citare invece alcuni passaggi tratti da Paul. E. Ceruzzi, “Storia dell’informatica” che credo diano uno stimolo al dibattito sull’utilizzo di strumenti come GrassHopper al posto dei tradizionali linguaggi interpretati come Rhinoscript. Che sia una strana coincidenza o no l’assonanza tra il nome della Hopper e la nostra “cavalletta” di Rhino la storia insegna…

Un programmatore, Scott Kim, ha detto che “non c’è una differenza fondamentale fra programmare un computer e utilizzarlo”. Per lui si tratta di strati levigati e continui, dal microcodice incorporato nel firmware fino ai comandi di menu di un ATM, e il suo lavoro si colloca da qualche parte tra questi strati. (p.101)

Se queste sequenze venivano perforate su pacchi di schede, si poteva preparare un programma selezionando i pacchi opportuni, scrivendo e perforando su schede codici di collegamento e raggruppando i risultati in un nuovo pacco di schede. Questa attività venne chiamata “compilazione”. […] Grace Hopper svolse un ruolo cruciale nel trasferire quel concetto dal laboratorio di Howard Aiken ad Harvard al mondo commerciale. […] Per Hopper, un “compilatore” era “una routine generatrice di programmi, che produceva un programma specifico per un problema particolare” e chiamava “Programmazione Automatica” l’insieme delle attività legate all’utilizzo dei compilatori.

[…] I fautori della Programmazione Automatica si proponevano di sviluppare per il software quello che Henry Ford aveva concepito per la produzione delle automobili, un sistema basato su parti intercambiabili. Ma proprio perché il sistema di Ford funzionò al meglio quando venne impostato per produrre un solo modello di automobile, questi primi sistemi erano altrettanto rigidi, tentavano di standardizzare prematuramente e a un livello di astrazione sbagliato. Fa fu soltanto quando provarono a farlo che se ne resero conto.

Vedi Wilkes, Wheeler e Gill “The preparation of Programs fora n Electronic Digital Computer”, 26-37 e Martin Campbell-Kelly “Programming the EDSAC: Early Programming Activity at the University of Cambridge”, Annals of the History of Computing 2, 1980, 7-36.

Il successo iniziale di FORTRAN illustra con quale prontezza gli utenti accettarono un sistema che nascondeva I dettagli dei meccanismi interni della macchina, lasciandoli liberi di concentrarsi sulla risoluzione dei loro problemi e non di quelli della macchina. Nello stesso tempo, il fatto che si continui a usarlo ben addentro agli anni Novanta, in un’epoca nella quale sono disponibili linguaggi più nuovi, che nascondono molti altri strati di complessità, rivela i limiti di questa filosofia. Il linguaggio C, sviluppato presso i Bell Labs e uno dei più diffusi dopo il 1980, consente, come il FROTRAN, di accedere a funzionalità di basso libello quando si desidera farlo. I linguaggi per computer che hanno avuto successo e sono durati a lungo, ben pochi, sembrano avere in comune la caratteristica di nascondere ai programmatori alcuni dei meccanismi interni del computer, ma non tutti. (p.113)