Traduzione in italiano di Vera Tomaino dall’essay originale di Paul Graham "Design and Research" [Gennaio 2003]

(Questo articolo è tratto da un discorso di apertura tenuto in occasione della riunione autunnale del 2002 del NEPLS).

I visitatori di questo Paese sono spesso sorpresi di scoprire che agli americani piace iniziare una conversazione chiedendo "Che cosa fai?". Non mi è mai piaciuta questa domanda. Raramente ho avuto una risposta chiara. Ma credo di aver finalmente risolto il problema. Ora, quando qualcuno mi chiede cosa faccio, lo guardo dritto negli occhi e gli dico: "Sto progettando un nuovo dialetto di Lisp". Consiglio questa risposta a tutti coloro che non amano che gli si chieda cosa fanno. La conversazione si sposterà immediatamente su altri argomenti.

Non mi considero un ricercatore di linguaggi di programmazione. Ne sto solo progettando uno, nello stesso modo in cui qualcuno potrebbe progettare un edificio, una sedia o un nuovo carattere tipografico. Non sto cercando di scoprire nulla di nuovo. Voglio solo creare un linguaggio che sia bello da programmare. Per certi versi, questo presupposto rende la vita molto più facile.

La differenza tra design e ricerca sembra essere una questione di nuovo contro buono. Il design non deve essere nuovo ma deve essere buono. La ricerca non deve essere buona ma deve essere nuova. Credo che queste due strade convergano al vertice: il miglior design supera i suoi predecessori utilizzando nuove idee, e la migliore ricerca risolve problemi che non sono solo nuovi, ma che vale la pena risolvere. Quindi alla fine miriamo alla stessa meta avvicinandoci semplicemente da direzioni diverse.

Quello di cui parlerò oggi è come appare il tuo obiettivo visto da dietro.  Che cosa si fa di diverso quando si trattano i linguaggi di programmazione come un problema di progettazione invece che come un argomento di ricerca?

La più grande differenza è che ci si concentra maggiormente sull'utente. Il design inizia chiedendosi, per chi è questo e di cosa hanno bisogno? Un buon architetto, ad esempio, non inizia creando un progetto che poi impone agli utenti, ma studiando i destinatari e capendo di cosa hanno bisogno.

Notate che ho detto "quello di cui hanno bisogno", non "quello che vogliono". Non intendo dare l'impressione che lavorare come designer significhi lavorare come una sorta di cuoco a domicilio, facendo tutto ciò che il cliente ti dice di fare. Questo varia da un campo all'altro dell'arte, ma non credo che esista un campo in cui il lavoro migliore sia quello di chi si limita a fare esattamente quello che i clienti gli dicono di fare.

Il cliente ha sempre ragione, nel senso che il metro di misura di un buon design è quanto funziona bene per l'utente. Se fate un romanzo che annoia tutti o una sedia che è terribilmente scomoda da usare, avete fatto un pessimo lavoro, punto e basta. Non è una difesa dire che il romanzo o la sedia sono stati progettati secondo i principi teorici più avanzati.

Tuttavia, creare ciò che funziona per l'utente non significa semplicemente creare ciò che l'utente dice di fare. Gli utenti non conoscono tutte le possibilità di scelta e spesso si sbagliano su ciò che vogliono veramente.

La risposta al paradosso, a mio avviso, è che bisogna progettare per l'utente, ma bisogna progettare ciò di cui l'utente ha bisogno, non semplicemente ciò che dice di volere. È un po' come essere un medico. Non si possono curare solo i sintomi di un paziente. Quando un paziente vi dice i suoi sintomi, dovete capire cosa c'è di sbagliato in lui e curarlo.

Questa attenzione per l'utente è una sorta di assioma da cui può essere derivata la maggior parte della pratica del buon design e attorno al quale si concentrano la maggior parte dei problemi di progettazione.

Se il buon design deve fare ciò che serve all'utente, chi è l'utente? Quando dico che il design deve essere per gli utenti, non intendo dire che il buon design mira a una sorta di minimo comune denominatore. Si può scegliere qualsiasi gruppo di utenti che desideri. Se si progetta uno strumento, per esempio, lo si può progettare per chiunque, dai principianti agli esperti, e ciò che è un buon design per un gruppo potrebbe essere pessimo per un altro. Il punto è che bisogna scegliere un gruppo di utenti. Non credo che si possa parlare di progettazione buona o cattiva se non in riferimento a qualche utente previsto.

È più probabile che si ottenga un buon design se tra gli utenti previsti c'è anche il progettista stesso. Quando progettate qualcosa per un gruppo che non vi comprende, tendete a farlo per persone che considerate meno sofisticate di voi, non più sofisticate.

Questo è un problema, perché guardare dall'alto in basso l'utente, per quanto benevolo, sembra inevitabilmente corrompere il progettista. Sospetto che negli Stati Uniti pochissimi progetti abitativi siano stati progettati da architetti che si aspettavano di viverci. La stessa cosa si può notare nei linguaggi di programmazione. C, Lisp e Smalltalk sono stati creati per essere utilizzati dai loro stessi progettisti. Cobol, Ada e Java sono stati creati per essere utilizzati da altre persone.

Se pensate di progettare qualcosa per gli idioti, è probabile che non stiate progettando qualcosa di buono, nemmeno per gli idioti.

Anche se si sta progettando qualcosa per gli utenti più sofisticati, si sta comunque progettando per gli esseri umani. Nella ricerca è diverso. In matematica non si scelgono le astrazioni perché sono facili da capire per l'uomo; si scelgono quelle che rendono la prova più breve. Penso che questo sia vero per le scienze in generale. Le idee scientifiche non sono pensate per essere ergonomiche.

Nelle arti le cose sono molto diverse. Il design ha a che fare con le persone. Il corpo umano è una cosa strana, ma quando si progetta una sedia, è per questo che si progetta, e non c'è modo di evitarlo. Tutte le arti devono assecondare gli interessi e i limiti degli esseri umani. Nella pittura, per esempio, a parità di condizioni un quadro con delle persone sarà più interessante di uno senza. Non è solo un caso storico che i grandi dipinti del Rinascimento siano tutti pieni di persone. Se così non fosse, la pittura come mezzo non avrebbe il prestigio che ha.

Che ci piaccia o no, i linguaggi di programmazione sono anche per le persone, e sospetto che il cervello umano sia irregolare e idiosincratico quanto il corpo umano. Alcune idee sono facili da comprendere per le persone e altre no. Ad esempio, sembra che la nostra capacità di gestire i dettagli sia molto limitata. È questo fatto che rende i linguaggi di programmazione una buona idea: se fossimo in grado di gestire i dettagli, potremmo semplicemente programmare in linguaggio macchina.

Ricordate anche che i linguaggi non sono principalmente una forma per programmi finiti, ma qualcosa in cui i programmi devono essere sviluppati. Chiunque si occupi di arte potrebbe dirvi che per le due situazioni si possono usare mezzi diversi. Il marmo, ad esempio, è un mezzo piacevole e durevole per le idee finite, ma irrimediabilmente inflessibile per lo sviluppo di nuove idee.

Un programma, come una prova, è una versione potata di un albero che in passato ha avuto false partenze che si sono ramificate dappertutto. Quindi il test di un linguaggio non è semplicemente l'aspetto pulito del programma finito, ma quanto pulito è stato il percorso per arrivare al programma finito. Una scelta progettuale che dà vita a programmi finiti eleganti può non dare vita a un processo di progettazione elegante. Per esempio, ho scritto alcune macro di definizione piene di backquote annidate che ora sembrano piccoli gioielli, ma la loro scrittura ha richiesto ore di tentativi ed errori bruttissimi e, francamente, non sono ancora del tutto sicuro della loro correttezza.

Spesso ci comportiamo come se il test di un linguaggio fosse la qualità dei programmi finiti in esso. Sembra così convincente quando si vede lo stesso programma scritto in due linguaggi e una versione è molto più breve. Quando si affronta il problema dal punto di vista artistico, è meno probabile che dipende da questo tipo di test. Non vogliamo finire con un linguaggio di programmazione come il marmo.

Per esempio, nello sviluppo di software è un’enorme vittoria avere un livello superiore interattivo, quello che in Lisp si chiama ciclo di lettura-valutazione-stampa. E quando ne hai uno, questo ha effetti reali sulla progettazione del linguaggio. Non funzionerebbe bene per un linguaggio in cui si devono dichiarare le variabili prima di usarle, per esempio. Quando si digitano espressioni nel livello superiore, si vuole essere in grado di impostare x a un certo valore e poi iniziare a fare cose su x. Non si deve dichiarare prima il tipo di x. Si può contestare una delle premesse, ma se un linguaggio deve avere un livello superiore per essere conveniente, e le dichiarazioni di tipo obbligatorie sono incompatibili con un livello superiore, allora nessun linguaggio che renda obbligatorie le dichiarazioni di tipo può essere conveniente da programmare.

In pratica, per ottenere un buon design è necessario avvicinarsi e rimanere vicini agli utenti. Bisogna calibrare costantemente le proprie idee sugli utenti effettivi, soprattutto all'inizio. Uno dei motivi per cui i romanzi di Jane Austen sono così belli è che li leggeva ad alta voce alla sua famiglia. Ecco perché non si lascia andare a descrizioni artistiche e autocompiaciute di paesaggi o a filosofie pretenziose. (La filosofia c'è, ma è intessuta nella storia invece di essere incollata su di essa come un'etichetta). Se aprite un normale romanzo "letterario" e immaginate di leggerlo ad alta voce ai vostri amici come se l'aveste scritto voi, sentirete fin troppo bene quanto questo genere di cose sia un'imposizione per il lettore.

Nel mondo del software, questa idea è nota come "Peggio è Meglio". In realtà, nel concetto di "Peggiore è meglio" si mescolano diverse idee, ed è per questo che si discute ancora se peggiore sia effettivamente migliore o meno. Ma una delle idee principali di questo mix è che se si sta costruendo qualcosa di nuovo, si dovrebbe presentare un prototipo agli utenti il prima possibile.

L'approccio alternativo potrebbe essere chiamato strategia dell'Ave Maria. Invece di realizzare rapidamente un prototipo e di perfezionarlo gradualmente, si cerca di creare il prodotto completo, finito, in un lungo passaggio di touchdown. Per quanto ne so, questa è una ricetta per il disastro. Innumerevoli startup si sono distrutte in questo modo durante la bolla di Internet. Non ho mai sentito parlare di un caso in cui abbia funzionato.

Ciò che le persone al di fuori del mondo del software potrebbero non capire è che il Peggio è il Meglio si trova in tutte le arti. Nel disegno, ad esempio, l'idea è stata scoperta durante il Rinascimento. Oggi quasi tutti gli insegnanti di disegno vi diranno che il modo giusto per ottenere un disegno accurato non è quello di lavorare lentamente intorno al contorno di un oggetto, perché gli errori si accumulano e alla fine si scopre che le linee non si incontrano. È invece opportuno tracciare alcune linee veloci nel punto giusto, per poi perfezionare gradualmente lo schizzo iniziale.

Nella maggior parte dei settori, i prototipi sono stati tradizionalmente realizzati con materiali diversi. I caratteri tipografici da tagliare in metallo venivano inizialmente disegnati con un pennello su carta. Le statue da fondere in bronzo venivano modellate in cera. I motivi da ricamare sugli arazzi venivano disegnati su carta con lavaggi a inchiostro. Gli edifici da costruire in pietra venivano testati su scala ridotta in legno.

Ciò che rendeva così eccitante la pittura a olio, quando divenne popolare per la prima volta nel XV secolo, era la possibilità di realizzare l'opera finita partendo dal prototipo. Se si voleva, si poteva fare un disegno preliminare, ma non si era obbligati a rispettarlo; si potevano elaborare tutti i dettagli, e persino apportare modifiche importanti, man mano che si finiva il dipinto.

È possibile farlo anche nel software. Un prototipo non deve essere solo un modello, ma può essere perfezionato fino a diventare un prodotto finito. Credo che si debba sempre fare così, quando è possibile. Vi permette di trarre vantaggio dalle nuove intuizioni che avrete lungo il percorso. Ma forse, cosa ancora più importante, fa bene al morale.

Il morale è fondamentale nella progettazione. Mi sorprende che non se ne parli di più. Uno dei miei primi insegnanti di disegno mi disse: se ti annoi mentre disegni qualcosa, il disegno risulterà noioso. Per esempio, supponiamo di dover disegnare un edificio e di decidere di disegnare ogni singolo mattone. Potete farlo se volete, ma se a metà strada vi annoiate e cominciate a fare i mattoni meccanicamente invece di osservarli uno per uno, il disegno sembrerà peggiore di quello che si sarebbe avuto se vi foste limitati a suggerire i mattoni.

​​Costruire qualcosa perfezionando gradualmente un prototipo fa bene al morale, perché tiene impegnati. Nel software, la mia regola è: avere sempre del codice funzionante. Se state scrivendo qualcosa che potrete testare in un'ora, avete la prospettiva di una ricompensa immediata che vi motiva. Lo stesso vale per le arti, in particolare per la pittura a olio. La maggior parte dei pittori inizia con uno schizzo sfocato e lo perfeziona gradualmente. Se si lavora in questo modo, in linea di principio non si deve mai finire la giornata con qualcosa che sembra incompiuto. In effetti, tra i pittori esiste anche un detto: "Un dipinto non è mai finito, basta smettere di lavorarci". Questa idea è familiare a chiunque abbia lavorato su un software.

Il morale è un altro motivo per cui è difficile progettare qualcosa per un utente non sofisticato. È difficile rimanere interessati a qualcosa che non piace a se stessi. Per creare qualcosa di buono, bisogna pensare: "Wow, è davvero fantastico", non "Che schifezza; quegli sciocchi lo adoreranno".

Progettare significa realizzare oggetti per gli esseri umani. Ma non è solo l'utente a essere umano. Anche il designer è umano.

Notate che per tutto questo tempo ho parlato di "designer". Di solito il design deve essere sotto il controllo di una sola persona per essere valido. Eppure sembra possibile che più persone collaborino a un progetto di ricerca. Questa mi sembra una delle differenze più interessanti tra ricerca e design.

Ci sono stati casi famosi di collaborazione nelle arti, ma la maggior parte di essi sembrano essere stati casi di legami molecolari piuttosto che di fusione nucleare. In un'opera è comune che una persona scriva il libretto e un'altra la musica. E durante il Rinascimento, gli artigiani del Nord Europa venivano spesso impiegati per realizzare i paesaggi sugli sfondi dei dipinti italiani. Ma queste non sono vere collaborazioni. Sono piuttosto esempi dell'espressione di Robert Frost "I buoni steccati fanno buoni vicini". Si possono mettere insieme istanze di buon design, ma all'interno di ogni singolo progetto, una persona deve avere il controllo.

Non sto dicendo che un buon design richieda che una sola persona pensi a tutto. Non c'è niente di più prezioso del consiglio di qualcuno di cui ci si fida. Ma dopo aver parlato, la decisione sul da farsi deve spettare a una sola persona.

Perché la ricerca può essere fatta da collaboratori e il design no? È una domanda interessante. Non conosco la risposta. Forse, se il design e la ricerca convergono, la migliore ricerca è anche un buon design, e infatti non può essere fatta da collaboratori. Molti degli scienziati più famosi sembrano aver lavorato da soli. Ma non ne so abbastanza per dire se ci sia uno schema. Potrebbe essere semplicemente che molti scienziati famosi hanno lavorato quando la collaborazione era meno comune.

Qualunque sia la storia delle scienze, la vera collaborazione sembra essere sempre più rara nelle arti. Design by committee è sinonimo di cattiva progettazione. Perché è così? C'è un modo per superare questa limitazione?

Sono propenso a pensare che non esista, che il buon design richieda un dittatore. Uno dei motivi è che il buon design deve essere un tutt'uno. Il design non è solo per gli esseri umani, ma per i singoli esseri umani. Se un progetto rappresenta un'idea che si adatta alla testa di una persona, allora l'idea si adatta anche alla testa dell'utente.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit paulgrahamita.substack.com