Grace Hopper and Grasshopper, what a coincidence (or “What does history teach us?”)

This is just a thought I wrote in Italian in 2009. I believe I was right when I made the connection between Grasshopper and Grace Murray Hopper (probably because of her work on Automatic programming). The Grasshopper banner confirms me that on 9 December, every year. Rutten is a clever guy! (For further info follow 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)

0 2409

8 Comments

  1. Alberto,
    interessante questo gioco di parole Grace/Grass – Hopper.
    Ho inserito il libro di Paul. E. Ceruzzi, “Storia dell’informatica”, nella lista dei desideri di aNobii, sarà il prossimo acquisto. Grazie del suggerimento.
    In questo momento sarebbe anacronistico nascondere i meccanismi interni dei computer poiché ci avvinciamo al Cloud Computing . A mio avviso l’evento che metterà in crisi il sistema ‘baronale’ delle nostre università.
    Saluti,
    Salvatore D’Agostino

  2. Salvatore, sei ottimista… 🙂

  3. Probabilmente il gioco di parole non è stato voluto, non saprei. Però era comunque l’occasione per riproporre alcuni bei paragrafi dal libro di Ceruzzi.
    Per quel che riguarda i meccanismi interni dei computer loro si riferivano al linguaggio macchina e alla ancora predominante architettura dell’hardware per la programmazione del software. Per noi è talmente consolidata l’architettura del personal computer che, attraverso lo scripting e grazie agli ambienti di programmazione interpretati forniti dai software commerciali, iniziamo almeno a capire come è fatto un po’ del software, il ragionamento per lo meno.
    Per l’anacronismo non sono sicurissimo. Infatti appena escono software come Grasshopper che aiutano con l’interfaccia grafica, permettendo sostanzialmente di scrivere senza sapere una lingua, nasce subito l’entusiasmo. Probabilmente per compiti molto semplici diventa facile, comodo e sicuramente utile. Per compiti più difficili? Intrecci di funzioni e subroutines che formano un flow chart complesso? Forse è meglio vederlo scritto e basta…
    Però possiamo provare. In questi giorni posterò l’intero pseudo codice per costruirsi un algoritmo genetico in Rhinoscript ad esempio o Grasshopper, funzione per funzione. Se qualcuno ha voglia di provare Grasshopper mi piacerebbe vedere i risultati, io non ci ho mai provato.
    E poi nascondere i meccanismi, hardware e software che siano, è quasi naturale per chi nasce sostanzialmente con interfacce grafiche potenti ed efficaci…
    Per il sistema baronale non saprei. Immagino che queste cose si risolvano solo con una nuova educazione, sperando nel cambio generazionale, o più cambi.
    Grazie dei continui stimoli!
    Saluti,
    Alberto

  4. —> Peja,
    lo sono, non possiamo andare avanti con dei professori che chiedono agli alunni come si fanno le cose al computer.
    Almeno questa è la mia speranza.
    Saluti,
    Salvatore D’Agostino

  5. —> Alberto,
    seguirò il tuo scripting.
    I software CAD sempre più intuitivi alimentano l’idea – dei tardivi digitali – che l’architettura possa essere generata da semplici operazioni di disegno automatico, ma sappiamo bene che occorre andare oltre i codici del software e riprogrammarlo: architettura dopo architettura.
    Da qualche tempo le generazioni si stanno restringendo. Speriamo bene.
    Saluti,
    Salvatore D’Agostino

  6. Speriamo allora in bene nel passaggio da generazione a generazione! Pensavo di proporre qualche pseudocodice che sto mettendo a posto per la tesi, ora da luglio a dicembre devo chiudere e magari postare qualcosa mi aiuta a tenere i ritmi!
    A presto,
    Alberto

  7. tomás méndez

    Ciao Alberto,

    Io da un paio di mesi ho iniziato a tirare fuori un paio di soluzioni con grasshopper. Non faccio Algoritmi genetici come quelli fatti al politecnico, e probabilmente hai ragione nel fatto che risulti difficile farlo esclusivamente con i moduli di grasshopper. Molto probabilmente si dovranno fare moduli di vb script insieme ai moduli già esistenti di grasshopper. Comunque ti riccordo che noi utilizziamo comunque i comandi di rhino senza conoscere necessariamente i meccanismi come dici tu. Quindi mi risulta “simile” programmare con rhinoscript o con grasshopper.

    Quello che inceve si faccio con GH è un po mettermi nella produzione di forme irregolari con machine di controllo numerico. GH viene adoperato principalmente per questo, seccondo quello che ho visto nella www e sentito in conferenze ad esempio del FAB LAB di Barcelona. GH risulta molto semplice e quindi ce pure una comunità enorme in rete condividendo soluzioni e aggiornamenti, il potrebbe risultare in una massificazione di tecniche spinte, chi sa cosa possa succedere alla produzione architettonica.

    Si tratta si sapere a cosa serve ogni software.

    Complimenti ancora per le discussioni e saluti

    Tomás Méndez

    • maarten jansen

      Ciao Alberto,

      interessante tuo blog e interessante questa discussione:
      per me che sono progettista e non tecnico, grasshopper è sperimentazione e possibilità di altri strati nel processo progettuale (a basso costo !)
      poi per gli studenti apre la visione ristretta e può stuzzicare creatività.
      per voi ‘tecnici dello scripting’ sembrerà un’invasione nel vostro campo dei pochi eletti ma ti invito di provare il programma e i moduli di scripting interni.
      giovani architetti delle nuove leve creano pezzi grasshopper in vbscript molto interessanti. il lessico dei linguaggi non dev’essere un limite come lo è questa discussione in italiano (il fortran del passato 😉
      saluti e complimenti !
      maarten

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.