Episode Details

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