Traduzione in italiano di Emmanuela Alesiani dall’essay originale di Paul Graham "Five Questions about Language Design" [Maggio 2001].

(Queste sono alcune note che ho scritto per una tavola rotonda sulla progettazione dei linguaggi di programmazione al MIT il 10 maggio 2001.)

1. I linguaggi di programmazione sono per le persone.

I linguaggi di programmazione sono creati per essere utilizzati dalle persone. Essi permettono di comunicare con i computer, che sarebbero disposti a "parlare" qualsiasi lingua, purché sia chiara e univoca. Tuttavia, abbiamo bisogno di linguaggi ad alto livello perché non siamo in grado di gestire direttamente il linguaggio macchina. L'obiettivo dei linguaggi di programmazione è di proteggere le nostre fragili menti umane dall'essere sopraffatte dalla complessità e dai dettagli.

Gli architetti sanno che alcuni tipi di problemi progettuali riguardano più da vicino le caratteristiche individuali, le esigenze e le preferenze delle persone. In altre parole, alcune sfide nella progettazione richiedono una maggiore attenzione alle differenze tra gli individui e a come queste influenzano il modo in cui interagiscono con l'oggetto o il sistema progettato.

Ad esempio, progettare ponti è un compito astratto in cui il principale obiettivo è coprire una distanza con il minor materiale possibile. D'altra parte, progettare sedie richiede di concentrarsi sulle esigenze e le caratteristiche fisiche degli esseri umani.

Anche il software presenta simili sfumature. Progettare algoritmi per instradare i dati attraverso una rete è un compito astratto, simile alla progettazione dei ponti. Tuttavia, progettare linguaggi di programmazione è più simile alla progettazione delle sedie, poiché implica tenere conto delle limitazioni e delle differenze umane.

Molti di noi non amano ammettere che debbano considerare queste debolezze. Infatti, l'idea di progettare soluzioni efficienti, comprensibili e ben strutturate, sembra molto più attraente. Tuttavia, è importante rendersi conto che questo non è un fine in sé.

Quando si parla di adattare i linguaggi di programmazione alle differenze umane, non si intende che debbano essere creati solo per i programmatori meno esperti. Al contrario, bisognerebbe progettare pensando ai migliori programmatori, che comunque hanno delle limitazioni. Nessuno, infatti, apprezzerebbe un linguaggio in cui tutte le variabili fossero rappresentate dalla lettera "x" seguita da indici numerici.

2. Progetta per te stesso e per i tuoi amici

Se si osserva la storia dei linguaggi di programmazione, molti dei migliori sono stati progettati per essere utilizzati dai loro stessi autori, mentre molti dei peggiori sono stati progettati per essere usati da altre persone.

Quando i linguaggi vengono progettati per gli altri, si tratta sempre di un gruppo specifico di persone: persone meno intelligenti rispetto al progettista del linguaggio. Così si ottiene un linguaggio che sembra parlare dall'alto in basso. Cobol è il caso più estremo, ma molti linguaggi sono pervasi da questo spirito.

Questo non ha nulla a che fare con quanto astratto sia il linguaggio. Il linguaggio C è piuttosto a basso livello, ma è stato progettato per essere utilizzato dai suoi autori, ed è per questo che gli hacker lo apprezzano.

L'argomento per la progettazione di linguaggi per programmatori scadenti è che ci sono più programmatori scadenti che bravi programmatori. Può darsi. Ma quei pochi bravi programmatori scrivono una percentuale sproporzionatamente alta del software.

Sono interessato alla domanda: come si progetta un linguaggio che piacerà ai migliori hacker? Io ritengo che questa domanda sia identica a "come si progetta un buon linguaggio di programmazione?", ma anche se non lo fosse, è comunque una domanda interessante.

3. Dare al programmatore il massimo controllo possibile

Molti linguaggi (specialmente quelli progettati per altre persone) hanno l'atteggiamento di una governante: cercano di impedirti di fare cose che ritengono non siano buone per te. Io preferisco l'approccio opposto: dare al programmatore il massimo controllo possibile.

Quando ho imparato Lisp per la prima volta, ciò che mi piaceva di più era che mi considerava un partner alla pari. Negli altri linguaggi che avevo appreso fino ad allora, c'era il linguaggio e c'era il mio programma, scritto nel linguaggio, e i due erano molto separati. Ma in Lisp, le funzioni e le macro che scrivevo erano proprio come quelle che componevano il linguaggio stesso. Potevo riscrivere il linguaggio se lo desideravo. Aveva lo stesso fascino del software open-source.

4. Mira alla brevità

La brevità è sottovalutata e persino disprezzata. Ma se guardi nei cuori degli hacker, vedrai che in realtà la adorano. Quante volte hai sentito gli hacker parlare con affetto di come, ad esempio, in APL, potessero fare cose sorprendenti con solo un paio di righe di codice? Penso che qualsiasi cosa che le persone davvero intelligenti amano davvero valga la pena di essere presa in considerazione.

Credo che quasi tutto ciò che si può fare per rendere i programmi più brevi sia positivo. Dovrebbero esserci molte funzioni di libreria; tutto ciò che può essere implicito dovrebbe esserlo; la sintassi dovrebbe essere concisa fino all'eccesso; anche i nomi delle cose dovrebbero essere brevi.

E non sono solo i programmi che dovrebbero essere brevi. Anche il manuale dovrebbe essere sottile. Una buona parte dei manuali è occupata da chiarimenti, riserve, avvertenze e casi speciali. Se ti costringi a ridurre il manuale, nel migliore dei casi lo fai correggendo le cose nel linguaggio che richiedevano così tante spiegazioni.

5. Ammetti cos'è l'hacking

Molte persone vorrebbero che l'hacking fosse una scienza. Penso che l'hacking sia più simile all'architettura. Gli architetti devono progettare edifici che non crollano, ma l'obiettivo effettivo degli architetti è realizzare grandi edifici, non fare scoperte relative allo studio delle forze interne ed esterne che agiscono su un'opera di ingegneria civile!

Quello che agli hacker piace fare è creare ottimi programmi. E penso che, almeno nelle nostre menti, dobbiamo ricordare che è una cosa ammirevole scrivere ottimi programmi, anche quando questo lavoro non si traduce facilmente nella valuta intellettuale convenzionale degli articoli di ricerca. Intellettualmente, è altrettanto valido progettare un linguaggio che i programmatori ameranno quanto progettare uno orribile che incorpora un'idea su cui è possibile pubblicare un articolo.

PROBLEMI APERTI

1. Come organizzare grandi librerie

Le librerie stanno diventando un componente sempre più importante dei linguaggi di programmazione. Stanno anche diventando più grandi, e questo può essere pericoloso. Se ci vuole più tempo per trovare la funzione della libreria che fa ciò che vuoi rispetto a quanto ne impiegheresti per scriverla da solo, allora tutto quel codice non fa altro che rendere il tuo manuale voluminoso (un esempio erano i manuali Symbolics). Quindi, penso che dovremo lavorare su modi per organizzare le librerie. L'ideale sarebbe progettarle in modo tale che il programmatore possa indovinare quale chiamata alla libreria faccia la cosa giusta.

2. Le persone hanno davvero paura della "sintassi prefissa"?

La domanda pone il dubbio se le persone abbiano timore di un tipo di scrittura, chiamata "sintassi prefissa", usata in alcuni linguaggi di programmazione come Lisp.

In parole semplici, la sintassi prefissa è un modo di scrivere le operazioni, in cui il simbolo dell'operazione viene messo prima degli elementi su cui agisce. Questo può sembrare strano o complicato per alcune persone, specialmente se confrontato con il modo in cui si scrivono solitamente le operazioni matematiche e in altri linguaggi di programmazione più diffusi.

Non è facile dire se le persone abbiano davvero paura di questo tipo di scrittura, poiché dipende dai gusti e dall'esperienza di ciascuno. Tuttavia, è possibile che una parte della scarsa popolarità di Lisp sia dovuta al fatto che la sua scrittura è diversa e meno familiare per chi proviene da altri linguaggi di programmazione.

Se bisogna o meno affrontare questo problema è una questione aperta e personale. Dipende da vari fattori, come l'ambito in cui si utilizza il linguaggio di programmazione, a chi è rivolto e quali obiettivi si vogliono raggiungere con quel linguaggio.

3. Cosa serve per il software basato su server?

Credo che molte delle applicazioni più interessanti che verranno sviluppate nei prossimi vent'anni saranno basate sul Web, ovvero programmi che risiedono sul server e comunicano con l'utente tramite un browser. Per scrivere questo tipo di programmi, potremmo aver bisogno di alcune novità.

Un aspetto di cui avremo bisogno è il supporto per il nuovo modo in cui le app basate su server vengono rilasciate. Invece di avere una o due grandi versioni all'anno, come nel caso del software per desktop, le app basate su server vengono rilasciate come una serie di piccoli aggiornamenti. Potrebbero esserci anche cinque o dieci rilasci al giorno. Di solito, tutti utilizzano sempre l'ultima versione disponibile.

Sapete come si possono progettare programmi che possano essere facilmente corretti in caso di errori? Allo stesso modo, il software basato su server deve essere progettato per essere facilmente modificabile. Bisogna essere in grado di cambiarlo facilmente o, quantomeno, sapere quali modifiche sono piccole e quali sono invece di grande impatto.

Un'altra cosa che potrebbe rivelarsi utile per il software basato su server, sorprendentemente, sono le continuazioni. Nel software basato sul Web, si può utilizzare qualcosa di simile allo stile "continuation-passing" per ottenere l'effetto delle sottoprocedure nel mondo intrinsecamente senza stato di una sessione Web. Forse sarebbe utile avere vere e proprie continuazioni, purché il costo non sia eccessivo.