Circa due settimane fa ho seguito a Torino una lecture organizzata da cstem di Marc Fornes, architetto e guru di rhinoscript.
(http://www.cstem.it/artists_i.php)
Le slide che ha presentato sono state molto chiare e rappresentavano gli ultimi anni della sua ricerca nel campo dello scripting. Il design di Marc Fornes è controllato da una serie di codici definiti da variabili, regole matematiche e algoritmi che lavorano per creare un risultato inatteso e indeterminato.
Dai primi script di tesselazione fino agli ultimi per la realizzazione e il calcolo delle notches per la creazione di installazioni generate da algoritmi e quelli della struttura fatta di cavi per un ponte in Polonia, Fornes utilizza solo l' editor di testo di windows (notepad) per creare le sue sperimentazioni spaziali. Con il modellatore rhino e un semplice editor monkey crea delle evoluzioni spaziali uniche al mondo.
Uno dei principi fondamentali della ricerca è il ricostruire la superficie. La superficie nurbs è data da una serie di punti che corrono sulle linee u e v della stessa superficie. Il codice estrapola questa nuvola di punti più o meno fitta e da essi ottiene le coordiante cartesiani x,y, e z e il vettore normale alla superficie passante per il punto. Da questa nuvola di punti e quindi da un set di dati, Fornes ricostruisce la superficie creando nuove tesselazioni o relazioni tra i punti tramite regole algoritmiche o semplici costruzioni geometriche ottenendo dei risultati inattesi.
Qui di seguito un video di TheVeryMany (Skylar Tibbits & Marc Fornes): Partly Surface a New York, MIND08 Design and the Elastic Mind Symposium (New York).
http://www.mind08.com/
Le prime sperimentazioni che ho fatto dopo aver scoperto il suo fantastico blog theverymany sono state quelle di andare oltre il codice che fornes forniva, cercandolo di piegarlo a mio piacimento. Pian piano sono passato a correggere ( non sempre) e a modificare alcune stringhe di codice, ma solo ora sto scrivendo da zero i primi codici.
Apprendere la programmazione da autodidatta è molto duro, ma grazie all'acceso delle informazioni che abbiamo in rete tutto è molto facilitato.
Queste immagini risalgono a marzo 2007, durante la preparazione della mia tesi sul network e gli scripting applicati alla progettazione architettonica.
Credo che gli architetti in futuro disegneranno impostando le poche linee che saranno la base del progetto e tutto il resto sarà reso parametrico. Un altra rivoluzione sarà quella in cui l'architetto che avrà i suoi script preimpostati li andrà a modificare a seconda dei casi specifici.
Dopo l'uso della matita e del tecnigrafo siamo passati al mouse e agli strumenti cad, diventando dei cad monkeys. Il futuro sarà quello di creare i nostri disegni senza tracciare nemmeno una linea ma scriptnado i codici direttamente, diventeremo così dei code monkeys come i programmatori dei videogiochi.
Uno strumento che i coder usano è appunto monkey, lo script editor che ha la funzione molto utile di debugger e di help sui rhinoscript che inseriamo.
Il titolo del post è nato da una puntata che ho visto in tv su un nuovo cartoon x adulti.
"I due vengono definiti ‘Code monkey’, espressione che indica in termini dispregiativi i componenti più giovani e meno esperti di un team di programmatori ai quali tocca scrivere codici su codici per sopravvivere."
via http://portale.gfpoint.com/
Ho letto per la prima volta sul libro di Stefano Converso Shop: works il termine cad monkeys, un libro molto interessante e che forse nei prossimi post tratterò.
(http://www.cstem.it/artists_i.php)
Le slide che ha presentato sono state molto chiare e rappresentavano gli ultimi anni della sua ricerca nel campo dello scripting. Il design di Marc Fornes è controllato da una serie di codici definiti da variabili, regole matematiche e algoritmi che lavorano per creare un risultato inatteso e indeterminato.
Dai primi script di tesselazione fino agli ultimi per la realizzazione e il calcolo delle notches per la creazione di installazioni generate da algoritmi e quelli della struttura fatta di cavi per un ponte in Polonia, Fornes utilizza solo l' editor di testo di windows (notepad) per creare le sue sperimentazioni spaziali. Con il modellatore rhino e un semplice editor monkey crea delle evoluzioni spaziali uniche al mondo.
Uno dei principi fondamentali della ricerca è il ricostruire la superficie. La superficie nurbs è data da una serie di punti che corrono sulle linee u e v della stessa superficie. Il codice estrapola questa nuvola di punti più o meno fitta e da essi ottiene le coordiante cartesiani x,y, e z e il vettore normale alla superficie passante per il punto. Da questa nuvola di punti e quindi da un set di dati, Fornes ricostruisce la superficie creando nuove tesselazioni o relazioni tra i punti tramite regole algoritmiche o semplici costruzioni geometriche ottenendo dei risultati inattesi.
Qui di seguito un video di TheVeryMany (Skylar Tibbits & Marc Fornes): Partly Surface a New York, MIND08 Design and the Elastic Mind Symposium (New York).
http://www.mind08.com/
Le prime sperimentazioni che ho fatto dopo aver scoperto il suo fantastico blog theverymany sono state quelle di andare oltre il codice che fornes forniva, cercandolo di piegarlo a mio piacimento. Pian piano sono passato a correggere ( non sempre) e a modificare alcune stringhe di codice, ma solo ora sto scrivendo da zero i primi codici.
Apprendere la programmazione da autodidatta è molto duro, ma grazie all'acceso delle informazioni che abbiamo in rete tutto è molto facilitato.
Queste immagini risalgono a marzo 2007, durante la preparazione della mia tesi sul network e gli scripting applicati alla progettazione architettonica.
Credo che gli architetti in futuro disegneranno impostando le poche linee che saranno la base del progetto e tutto il resto sarà reso parametrico. Un altra rivoluzione sarà quella in cui l'architetto che avrà i suoi script preimpostati li andrà a modificare a seconda dei casi specifici.
Dopo l'uso della matita e del tecnigrafo siamo passati al mouse e agli strumenti cad, diventando dei cad monkeys. Il futuro sarà quello di creare i nostri disegni senza tracciare nemmeno una linea ma scriptnado i codici direttamente, diventeremo così dei code monkeys come i programmatori dei videogiochi.
Uno strumento che i coder usano è appunto monkey, lo script editor che ha la funzione molto utile di debugger e di help sui rhinoscript che inseriamo.
Il titolo del post è nato da una puntata che ho visto in tv su un nuovo cartoon x adulti.
"I due vengono definiti ‘Code monkey’, espressione che indica in termini dispregiativi i componenti più giovani e meno esperti di un team di programmatori ai quali tocca scrivere codici su codici per sopravvivere."
via http://portale.gfpoint.com/
Ho letto per la prima volta sul libro di Stefano Converso Shop: works il termine cad monkeys, un libro molto interessante e che forse nei prossimi post tratterò.
Posts
11 commenti:
Davide,
siamo nell'era dell'architetto autodidatta. L'università italiana intrappolata nelle sue beghe politiche non riesce a fornire gli strumenti (più sofisticati, escludendo le rare eccezioni) per la formazione degli studenti 'eccellenti'.
Il 'CAD monkey' ovvero l'architettura scritta implica una conoscenza multidisciplinare e una flessibilità che solo grazie alle nuove relazioni telematiche possiamo raggiungere.
Spero che con la creazione di una rete di blogger, autorevoli e preparati, si possano scuotere le istituzioni e i rancorosi/asfittici teorici del belpaese, quest'ultimi incapaci di leggere l'intelligenza e la fatica del fare 'Architettura' senza pasticci filologici/storicistici.
Salvatore D'Agostino
Caro Davide,
con riferimento alle tue previsioni sul futuro modo di lavorare degli architetti mi permetto di essere in disaccordo. Per cominciare, non credo si possa tracciare un’evoluzione degli strumenti dell’architetto così lineare e semplice come qui la descrivi. Quando comparvero i primi calcolatori, sia l’hardware che il software erano molto rozzi. Quindi era molto più istintivo approcciarsi ad essi come a mezzi flessibili da gestirsi praticamente da soli. Infatti lo sviluppo del software e in parte anche l’assemblaggio dell’hardware avveniva sempre ad hoc per risolvere dei problemi specifici. Nel campo dell’architettura questo è ben spiegato da Frazer nei suoi articoli e nel suo libro “An Evolutionary Architecture”. E si può ritrovare, seppur in certi casi anche solo come intenzione e modo di approcciarsi al computer, nei saggi di Graham, F.Kahn e Moretti, ad esempio.
Prendendo come presupposto quindi che il cosiddetto ‘scripting’ sia solo un modo di personalizzare e rendere più flessibile uno strumento (tra i tanti) a disposizione del progettista, vorrei affermare che questo diventa utile e sensato nel suo utilizzo unicamente quando è adatto a rispondere ad un problema specifico dell’architetto, prendendo per assodato che quest’ultimo sia ben formulato (vedi Popper, Congetture e confutazioni; Pera, Apologia del metodo). Seguendo quindi le affermazioni di Walter Ong in “Oralità e scrittura”, diventa chiaro che uno strumento più evoluto di un precedente non ne diventa comunque il sostituto. Non lo è stata la stampa per la scrittura a mano. Non lo è stata la scrittura per l’oralità. Quello che invece ritengo sia un tema importante sul quale indagare è il fatto di come l’uso di uno strumento condiziona il pensiero. Ritornando appunto ad Ong, che in maniera molto lucida descrive il modo di ragionare di culture ad oralità primaria, culture alfabetizzate e culture ad oralità secondaria, allora trasportando il discorso all’architettura possiamo riflettere anche sugli strumenti che a noi paiono tradizionali e consolidati nella pratica quotidiana. Penso al disegno a mano con carta e matita. Penso all’uso di squadre, righelli e compassi. Penso alle tecniche della rappresentazione. Solo per fare alcuni esempi.
Arrivo al dunque. In tutto questo quadro, come possiamo collocare le possibilità offerte da ambienti di programmazione user-friendly come Rhinoscript o dalla presenza di software commerciali parametrici e basati su potenti motori grafici NURBS? Immagino che si possano sempre più formulare problemi complessi, non risolvibili tramite gli strumenti ‘classici’, e cercare di ricercare l’innovazione e sperimentare nell’architettura confrontandosi sempre con problemi più complessi, ma direi anche sempre più gestibili.
Nutro invece parecchie perplessità sull’uso dello ‘scripting’ per pure ricerche espressive, tanto meglio se non prevedibili o attese. Il fascino di una forma inattesa o imprevista lo provo sicuramente di fronte al lavoro di Frei Otto, di Schlaich o di altri progettisti che hanno trovato un risultato formalmente inedito risolvendo un problema progettuale. Non per puro esercizio o ricerca della novitas.
Mi perdonerai la polemica e l’estrema sintesi con cui ti esprimo la mia posizione (tra l’altro già discussa con piacere anche con Andrea in giro al Castello) ma io credo sia importante indagare su questo tema più che sulle possibilità espressive di un software, nato e settato con regole ‘libere’, puramente a piacere del progettista.
Un saluto e a presto,
Alberto Pugnale
Ciao Alberto,
Grazie per il commento al post.
Sono d'accordo con te sul fatto che lo scripting sia solo uno strumento per fare architettura e non l'architettura. Quello che scrivo nel mio brevissimo post nato appunto dopo la lecture di Fornes sono delle mie considerazioni sul futuro e sul tipo di approccio che avremo nel nostro lavoro. Da qualche tempo ho avuto modo di lavorare con software parametrici che trovo di gran lunga superiori allo scripting per quanto riguarda la velocità e la praticità del loro uso.
Ho visto diverse applicazioni di questi software parametrici per la definizione preliminare di un progetto e ho constatato come la maggior parte delle volte ci siano stati dei risultati inattesi perchè non possibili da immaginare se non fino averli visti alla fine del processo.
Parlo del ws di generative fatto al poli poche settimane fa, dove è il software è stato piegato alle volontà del progettista. Sono stati creati dei diagrammi parametrici di analisi e di investigazione della forma che hanno prodotto dei risultati che diversamente si sarebbero raggiunti. Siamo lontanti dalle sperimentazioni di form finding di Frei Otto, ma lavorare in questo modo per me è un modo molto interessante e mi affascina il processo dei risultati inattesi. Il lavoro di Fornes, come lui stesso ha detto a seguito di una domanda, per lo più delle volte ha portato a risultati non immaginati e sicuramente inattessi sfiorando il campo dell'incertezza. Forse questo è un limite dell'utilizzo del software, lo strumento diventa il padrone e pilota il porgettista. Penso a software come sketchup che non gestiscono le curve e che vincolano molto la creatività degli studenti.
Il post che ho fatto è per lo più una sorta di critica in positivo dell'utilizzo dello scripting. Quello di cui parlo è una versione molto semplificata di una parte di lecture di Fornes a Torino ed è rivolta ad un pubblico anche di passaggio dal mio blog che non hanno mai sentito parlare di nurbs, codici ecc...Per me il futuro della progettazione rimarrà lo stesso di adesso, cioè disegnare a mano ( come continuo iop stesso a fare) sui fogli di carta e pilotare il mio modello parametrico o statico che sia a seconda dello schizzo che ho creato, uno schizzo che è ragionato ma purtroppo non completo come un software che crea modelli a seconda delle analisi e degli input che inseriamo. Il presente come il futuro è quello di negoziare tra i due approcci, quello più tradizionale e quello più da "coder".
La rivoluzione informatica trattata da Saggio è già arrivata ad una fase matura tale per cui in un progetto ha almeno uno script o una tool che hanno portato alla forma finale. Sono convinto che lo scripting sicuramente ci aiuterà a gestire meglio la complessità che caratterizza ogni progetto.
A presto,
D.
Sono d'accordo con te sul fatto che riguardo al futuro e all' attività professionale si formeranno studi che si occuperanno di parti specifiche di progetti tramite l'utilizzo di scripting.
E' una realtà giá esistente all' estero e ormai consolidata, vedi l' unità AGU di Arup o AKT.
Un esempio molto recente è la realizzazione del padiglione drl ten dove lo scripting è stato utilizzato nelle fasi di progetto esecutivo per definiree notches delle lamelle e non per la definizione della forma e quindi nel processo di indagine morfologica iniziale.
Quello che ho espresso è la mia impressione sul futuro dell' architetto professionista ché lavora nel proprio studio per i suoi progetti. Passare dalla matita al mouse e dal mouse al codice sarà secondo me una rivoluzione anche in termini di processo mentale e approccio al progetto. Lo script e' uno strumento sempre più assimilato negli studi e crea nuove possibilitá estetico-formali ma anche tecnologiche.
Questo sistema diventa in sintesi una tool personalizzabile e adattabile ai problemi specifici e sono convinto ché più dello script fatto e finito prenderanno sempre più piede i software parametrici e il ragionamento si sposterà sempre più su un discorso di variabili di progetto, che verranno sempre controllate facilmente grazie a questo tipo di software.
Dipende sempre dal tipo di lavoro che devi svolgere, dal tipo di problemi che ti pone e quindi da come vuoi tu porti per risolverli. Non credo si possa generalizzare. Probabilmente nella pratica professionale 'da combattimento' gran parte dei cambiamenti che tendono a consolidarsi sono dovuti principalmente ad un rapporto legato a risparmio di risorse e di tempo. Però nella pratica progettuale più evoluta non è detto che di volta in volta si debbano utilizzare strumenti diversi.
Come mai noi disegnamo utilizzando tastiera e mouse invece di tavolette grafiche e interfacce che simulano il disegno a mano? Perchè non ci servono. Utilizziamo il disegno CAD per altri motivi (precisione, semplicità di modifica, riproduzione e trasferimento, ecc) per fare un esempio. Perchè non prendono piede i videotelefoni? Perchè l'obiettivo di comunicare oralmente con un'altra persona è già soddisfatto col telefono tradizionale.
Quando una tecnologia viene utilizzata, o peggio creata, per uno scopo futile non potrà mai trovare accoglimento e diffusione. Perchè non ha utilità.
Personalizzare il software commerciale, come Rhino, e l'utilizzo di software parametrici funziona già oggi a pieno regime in studi dove questi strumenti servono. Servono a gestire, studiare e risolvere particolari problemi legati ad un progetto. Proprio perchè come dici tu cambiano il tuo modo di pensare e vedere il progetto. Ma in meglio rispetto ad altri strumenti. In altri casi non ha senso cambiare modo di pensare. E' come ragionare su una distribuzione interna di una residenza collettiva disegnando un prospetto, o in prospettiva. Trovo difficile immaginare un esempio nel quale questo genere di rappresentazione (strumento) possa aiutare piuttosto che aggiungere difficoltà all'operazione.
Per collocare con più esattezza sia lo scripting che il software parametrico dovremmo indagare anche gli strumenti che utilizziamo da sempre e che consideriamo consolidati (ma così sempre non sono, pensiamo ad esempio al disegno in proiezione ortogonale, che alcuni non hanno mai utilizzato in passato).
A presto!
Alberto
Ciao Davide,
se da un lato sono d'accordo con Salvatore in riferimento al giusto tentativo di fare architettura senza i cosidetti pasticci "filologici/storicistici" del belpaese, da un altro lato però non bisogna mai perdere di vista il grosso limite dello scripting: e cioè che chiunque che abbia un minimo di interesse verso l'informatica potrebbe riuscire a far spacciare le sue fantasiose iterazioni geometriche per sperimentazioni architettoniche pur non sapendo dove stia di casa l'architettura.
Con ciò voglio dire che l'idea che noi architetti ci facciamo governare dalle evoluzioni imprevedibili degli script(o anche programmi parametrici stile grasshopper dai risultati sempre non prevedibili) non mi piace assolutamente, perchè in primo luogo non mi piace l'idea di essere come degli informatici che stanno giocando con dei codici semplicemente per creare forme complesse alla Fornes per il gusto di stupire e farsi dire wow!!!that's modern architecture!!!
La diabolica tentazione di fare le "robe" più strane partorite da un gioco di codici, è grande, ed io ne so qualcosa...facciamolo però, ricordandoci ogni tanto che siamo degli architetti e dobbiamo noi governare e PREVEDERE quello che andremo a rappresentare.
Pierpaolo
PS. nei primi anni delle esplorazioni spaziali con equipaggio gli uomini che entravano nelle capsule, non decidevano nulla, dovevano solo ricordarsi di respirare, se accadeva un imprevisto erano nella mani delle macchine, addirittura non potevano neanche aprire a mano il portellone di uscita una volta atterrati sull'oceano;insomma delle vere e proprie scimmie da laboratorio...poi le cose fortunatamente cambiarono...
Penso che l' architetto operando con i cambiamenti che avvengono sia in campo architettonico, urbano, ambientale e a stretto contatto con la società debba allo stesso tempo adattarsi alla tecnologia.
E' naturale che l'architetto passi al codice e che lo scripting venga integrato con i metodi tradizionali per redigere un progetto. Negli studi sono spariti i tecnigrafi per fare spazio al computer, un giorno spariranno anche i software 2d come autocad per fare spazio ai programmi bim che creeranno automaticamente tutti gli elaborati necessari partendo da un modello tridimensionale parametrico.
Dal piccolo studio di provincia fino allo studio internazionale (anche se per quest' ultimo sara' più semplice e veloce) avverà questa rivoluzione per il semplice motivo che non si ha più tempo per disegnaree. L' avvento del dei sistemi CAD ha aumentato la velocità con cui si realizza un progetto e grazie al comando ctrl+c e ctrl+v le tasche di molti si sono riempite, molto spesso a scapito dell' architettura. Ci sono sicuramente i lati positivi, ad esempio anche il piccolo studio può essere competitivo e al passo con la concorrenza. Il parametrico sarà il prossimo step che aumenterà la velocità nel fare un progetto. Non è possibile che ogni volta che dobbiamo operare sul progetto con una modifica dobbiamo ridisegnare da capo e in questo senso il computer diventa solo uno strumento di poco evoluto rispetto al disegno tradizionale a mano. Lo scripting non verrà utilizzato per forza da tutti gli architetti, ma solo in casi in cui un'operazione troppo complessa o in cui si impiega troppo tempo si presenti al progettista. Qui nasce il risultato inatteso, che crea lo scripting. La mia critica del code Monkey intende sottolineare il fatto che non dobbiamo farci pilotare dal codice ma anzi dobbiamo sviluppare processi da noi controllati per risolvere determinati problemi che si presentano di volta in volta nel progetto. Pian piano sto cercando di assimilare la logica del parametrico perché mi evita di ridisegnare n volte da capo un modello. All' inizio implicherà sicuramente molto tempo a definire le variabili e allo stesso tempo scegliere quale sia il giusto sistema per rendere parametrico il progetto, ma investendo all'inizio guadagnerò sicuramente tempo in futuro. Se devo cambiare qualcosa lo farò modificando dei semplici punti resi parametrici che diventano la base dei legami che formano la stesura del progetto.
A volte si rimane affascinati da queste forme inattese, ma questo e il lato "sensuale" della ricerca. Ottenere dei risultati indeterminati a priori così affascinanti rende la ricerca un campo empirico che spinge il progettista a effettuare svariate sperimentazione per indagare la possibile variazioni e crescere con l'esperienza, anche se questo può trasformarsi in qualcosa di pericoloso che si allontana dal concetto di fare architettura per l'uomo.
Bisogna però, come dice Pierpaolo, fare i conti con la realtà riconoscendo il fatto ché ciò che disegniamo deve essere realizzabile, ma guardiamo a quello che ha fatto skylar tibbits per la sua tesi ad esempio, senza l' utilizzo dello strumento script di tesselazione che discretizza il suo modello e non sarebbe riuscito a creare quella superficie.
Io ripeto che credo si stiano mettendo insieme temi diversi nella stessa discussione, col rischio di generalizzare troppo. Quello che succede nel modo di lavorare degli studi di architettura (che è già un tema a se, da indagare in base a luogo, dimensione, tipi di lavori, ecc) non è significativo rispetto ad uno studio sul progetto di architettura e sui modi, metodi, tecniche e strumenti del progettista. Sono due cose ben distinte. E quindi non vorrei che alcuni pareri discordanti siano solamente dovuti al fatto che ci riferiamo anche a cose diverse. Approfondiremo appena possiamo.
Ciao!
Concordo pienamente Alberto e ti ringrazio per l'interesse che hai avuto per questo post. A presto.
---> Alberto,
le tue considerazioni sono molto interessanti (come i tuoi suggerimenti bibliografici), bisogna capire a fondo come l'uso degli strumenti (software) condizionano il pensiero architettonico.
Ma dai tempi di Collodi e l'automa Pinocchio questa domanda non può avere delle risposte certe. Siamo ormai nell’era della totale osmosi con l'evoluzione algoritmica dei software, quest'ultimi da considerare (come per il filosofo Derrick De Kerckhove) una vera e propria psicotecnologia, cioè un'estensione espressiva dell'architetto. L'architetto deve vacillare in questa fune del formale/informale anche rischiando operazioni di serendipità.
Non credo che sia opportuno imporre dei limiti, anzi a mio parere l'università dovrebbe aprire delle aree di ricerche (serie) per anticipare le dinamiche speculative in modo da sgombrare il campo dai superficiali buontemponi, ma questa come sappiamo è fanta/politica/universitaria.
Infine non credo che ci sia in atto un condizionamento unilaterale, “il software cambia il pensiero architettonico”, ma un'interazione reciproca. Questa simbiotica attività deve essere attraversata senza limiti culturali, magari riscoprendo, come dici tu, le proiezioni ortogonali.
---> Pier Paolo,
non credo che sia un problema che i non architetti si occupino di architettura, se quest'ultima fosse fatta bene, vedi Carlo Scarpa. Certo è da evitare qualsiasi deriva di formalismo.
Temo invece che in questo momento siamo come quegl'astronauti incapsulati che hai decritto, bisogna cominciare a cambiare gli eventi e governare le nostre macchine.
---> Davide,
la tua previsione sulla progressiva sostituzione dei software indipendenti a quelli dipendenti credo che sia giusta. Non mi convincono quelle sugli script, se quest’ultimi servono a generano solo delle forme.
Bisogna ritornare alla metaprogettazione cara ai tecnologi, ma filtrarla con il concetto diagrammatico, fondamentale per istituire i processi ideativi/architettonici. Abbandonare quindi le derive postmoderne, il compositivismo estremo delle nostre università e l’idea di un colloquio filologico con la città che fisiologicamente non accetta architetture nate vecchie.
Infine Ctrl C e Ctrl X sono operazioni che non possano essere evitate, vedi il 90% dell’edilizia attuale.
Salvatore D’Agostino.
E' solo un commento di precisazione e chiedo scusa se propongo citazioni lunghe. Ma non sono in grado di ripetere il concetto meglio o sintetizzarlo!
“Dipenderà quindi da noi se, nel futuro, vorremmo fare di questi mezzi, in nome di una ideologia della dematerializzazione universale, un uso alienante, oppure farne invece, come io ritengo che si dovrebbe, un uso che sfrutti al massimo il formidabile potenziale di interfaccia conoscitiva, progettuale e creativa dell’uomo con il mondo. Non una fuga mundi, ma una creatio mundi.” (Maldonado T. in Reale e virtuale, p.78). Maldonado rifletteva così in “Reale e virtuale” sulle nuove tecnologie e sui nuovi strumenti dell’architetto. Il riferimento era più che altro ai primi software di modellazione solida, che secondo lui riunivano in un unico “plastico virtuale” diverse informazioni prima studiate ed elaborate attraverso altre vie. Il primo vantaggio assoluto di questo genere di tecnologie, sempre secondo Maldonado, sta nel ridurre drasticamente i tempi del progetto “per prova ed errore”. Ed è questo il principale motivo per il quale nella sfera professionale alcuni strumenti diventano sostituti di altri.
La mia riflessione non voleva includere l’intero campo di tecnologie e il loro sviluppo nel lavoro progettuale e degli studi di architettura ma era esclusivamente limitato al rapporto tra strumenti e tecnologie nel lavoro progettuale dell’architetto. Magari l’ho dato per scontato, ma non mi interessava che questo fosse valido per l’architettura nella sua interezza, soprattutto guardando al mondo professionale. Non ho neanche intenzione di rimettere in pista vecchi strumenti e modi classici del fare l’architetto. Il mio invito era ad un’indagine comparata per riflettere anche su quello che noi diamo per scontato del nostro modo di fare. E citando Ong mi riferivo proprio a questo: “Le tecnologie non sono semplici aiuti esterni, ma comportano trasformazioni delle strutture mentali […]. La tecnologia, se propriamente interiorizzata, non degrada la vita umana, ma al contrario la migliora. L’orchestra moderna, ad esempio, è il risultato di un’alta tecnologia. Un violino è uno strumento, cioè un attrezzo. Un organo è una macchina enorme, con fonti di energia – pompe, soffietto, generatori elettrici – del tutto estranei a chi lo suona. Lo spartito della Quinta Sinfonia di Beethoven consiste di istruzioni precisissime per tecnici specializzati che indicano esattamente come essi dovranno usare i loro strumenti. […] Imparare ad utilizzare le potenzialità dello strumento richiede anni di esercizio, e questo certo non disumanizza. L’uso di una tecnologia può quindi arricchire la mente umana, espandere lo spirito, intensificare la vita interiore; e la scrittura è una tecnologia interiorizzata più profondamente della musica strumentale. Ma per poter capire cosa essa sia, il che significa intenderla in relazione al suo passato, cioè all’oralità, occorre onestamente riconoscere che è una tecnologia.” (Ong. W. In Oralità e scrittura, p.124-25). Quindi al fatto che personalmente mi interessa studiare le tecnologie e gli strumenti informatici ma anche sviluppare una consapevolezza nei confronti di tecnologie invece più interiorizzate, ma pur sempre tecnologie. E spero di trarre qualche conclusione anche da questa comparazione. Non vorrei includere in questo il pensiero architettonico, però il modo di ragionare sul progetto da parte dell’architetto sì. Mi immagino davanti ad un disegno in pianta, sezione ed alzato. Oppure davanti a un plastico. O ancora di fronte ad un modello sviluppato con software BIM. E’ chiaro che le informazioni che mi trasmettono i singoli elaborati (basati su strumenti e tecniche diverse) avranno i loro intrinseci potenziali ‘conoscitivi’ per me progettista. Ritengo dunque utile esserne sempre consapevoli per evitare di non sfruttarli al meglio. Per questo ho espresso la mia perplessità sul lavoro di Fornes, che non ritengo particolarmente interessante, quantomeno non tanto come le tecnologie di supporto che utilizza e che si potrebbero sfruttare ben meglio. Altre letture che personalmente ritengo molto interessanti e che aiutano a sviluppare curiosità sul tema sono “La società della mente” di Minsky e “Brainstorms” di Dennett. Ma anche il più conosciuto “Understanding Media” di Mc Luhan.
Il quadro a livello universitario, sia di ricerca che di didattica, non è comunque dei più rosei. A livello didattico le pubblicazioni più diffuse non presentano lavori molto diversi da quello che fa Fornes. Rimangono comunque molto utili per prendere dimestichezza con lo strumento. Cito alcune delle più recenti: ARANDA B., LASCH C., Tooling, Princeton Architectural Press, New York, 2006. Collana: Pamphlet architecture n°27. GIACONIA P., Script. Spot on Schools, Editrice Compositori, Bologna, 2005. LYNN G., RASHID H., Architectural laboratories, NAi Publisher, Rotterdam, 2002. TERZIDIS K., Algorithmic Architecture, Architectural Press, 2006. In quest’ultima, si trova un accenno ad una ricerca distributive con il supporto di script, ma non è chiaramente spiegata e neanche supportata da un codice che permetta di comprendere cosa si vuole fare e come. Da tutto questo sto escludendo le ricerche e la didattica prettamente volta al FileToFactory, che non è strettamente legata al nostro tema (quindi niente D’Amato & Company, Cache, ecc).
Il fatto è che diverse ricerche interessanti trovano difficile applicazione nella didattica e non hanno come principale sfogo la pubblicazione divulgativa rivolta agli studenti o agli appassionati ma vengono presentate in convegni o su riviste specialistiche (mi viene ad esempio in mente il lavoro di Sasaki). Anche la divulgazione attraverso le case produttrici di software non è una strada sempre percorsa. Se la MCNeel supporta alcuni personaggi legati alle ricerche con RhinoScript parecchi altri studiosi usano altri ambienti di programmazione, per esempio. Il tema della personalizzazione del software non è quindi legato solamente a Rhinoscript, sebbene per quel che interessa a noi sia il software direi più indicato a sviluppare codici.
Dall’ultimo paragrafo di Salvatore D’Agostino si percepisce uno sfondo di polemica con il metodo didattico di qualche facoltà italiana. Anzi, più che uno sfondo è abbastanza palese! Però che ci possiamo fare, ognuno ha i suoi baroni. Per quello è utile ragionare alla Popper, intorno a problemi piuttosto che ai saperi disciplinari. E’ l’unico modo di far fuori una suddivisione poco utile nella ricerca, sebbene sia frutto dell’opera di un razionalista critico!
Saluti,
Alberto Pugnale
Post a Comment