Battere la media

Traduzione italiana di Beating the Averages di Paul Graham

Aprile 2001

(Questo articolo deriva da un discorso tenuto in occasione del Franz Developer Symposium nel 2001).

Nell’estate del 1995, io ed il mio amico Robert Morris abbiamo avviato una startup chiamata Viaweb. Il nostro piano era quello di scrivere un software che permettesse agli utenti finali di costruire negozi online. La novità di questo software, all’epoca, era che funzionava sul nostro server, utilizzando le normali pagine web come interfaccia.

Ovviamente molti avrebbero potuto avere questa idea contemporaneamente, ma per quanto ne sappia io, Viaweb è stata la prima applicazione basata sul web. Ci sembrava un’idea talmente innovativa che abbiamo chiamato l’azienda così, Viaweb, perché il nostro software funzionava via web, anziché sul computer desktop. Un’altra cosa insolita di questo software era che era scritto principalmente in un linguaggio di programmazione chiamato Lisp. È stata una delle prime grandi applicazioni per utenti finali ad essere scritta in Lisp, che fino ad allora era stato utilizzato principalmente nelle università e nei laboratori di ricerca. [1]

L’arma segreta

Eric Raymond ha scritto un saggio intitolato “How to Become a Hacker” (Come diventare un hacker), in cui, tra le altre cose, dice ai potenziali hacker quali linguaggi dovrebbero imparare. Suggerisce di iniziare con Python e Java, perché sono facili da apprendere. Inoltre, l’hacker serio deve imparare C, per poter hackerare Unix, e Perl per l’amministrazione di sistema e script cgi. Infine, l’hacker veramente serio dovrebbe prendere in considerazione l’apprendere Lisp:

vale la pena di imparare Lisp per la profonda e illuminante esperienza che proverai quando finalmente riuscirai a farlo tuo. Questa esperienza ti renderà un programmatore migliore per il resto dei tuoi giorni, anche se non lo utilizzerai poi molto.

È la stessa argomentazione che si usa rispetto all’apprendimento del latino. Non ti procurerà un lavoro, se non forse come professore di materie classiche, ma ti aprirà la mente e ti renderà uno scrittore migliore nelle lingue che invece vuoi usare, ad esempio l’inglese.

Aspetta un momento, però. Questa metafora non é poi così adatta. Il motivo per cui il latino non ti farà avere un lavoro è che nessuno lo parla. Se scrivi in latino, nessuno può capirti. Invece Lisp è un linguaggio informatico e i computer parlano qualsiasi linguaggio il programmatore dica loro di parlare.

Quindi se Lisp ti rende un programmatore migliore, come dice lui, perché non vorresti usarlo? Se a un pittore venisse proposto un pennello che lo rendesse un pittore migliore, secondo me vorrebbe usarlo in tutti i suoi quadri, non ti pare? Non sto cercando di prendere in giro Eric Raymond. Nel complesso, il suo consiglio è buono. Quello che dice di Lisp è più o meno la saggezza popolare. Ma c’è una contraddizione nella saggezza popolare: Lisp ti renderà un programmatore migliore, eppure non lo userai.

Perché no? I linguaggi di programmazione sono, dopotutto, solo strumenti. Se Lisp producesse davvero programmi migliori, dovresti usarlo. E se così non fosse, allora chi ne avrebbe bisogno?

La mia non è solo una domanda teorica. Il software è un business molto competitivo, soggetto a monopoli naturali. Un’azienda che scrive software più velocemente e meglio, a parità di altre condizioni, farà fallire i suoi concorrenti. E quando si avvia una startup, questo si percepisce molto profondamente. Le startup tendono ad essere una proposta “tutto o niente”. O diventi ricco, o non ottieni niente. In una startup, se scommetti sulla tecnologia sbagliata, i tuoi concorrenti ti schiacceranno.

Robert ed io conoscevamo bene Lisp, e non vedevamo alcun motivo per non fidarci del nostro istinto e usarlo. Sapevamo che tutti gli altri stavano scrivendo il loro software in C++ o Perl. Ma sapevamo anche che non significava nulla. Se si scegliesse la tecnologia in questo modo, si userebbe Windows. Quando si sceglie la tecnologia, bisogna ignorare ciò che fanno gli altri e considerare solo ciò che funziona meglio.

Ciò è particolarmente vero in una startup. In una grande azienda, puoi fare quello che fanno tutte le altre grandi aziende. Ma una startup non può fare quello che fanno tutte le altre startup. Non credo che molti se ne rendano conto, nemmeno nelle startup.

La grande azienda media cresce di circa il 10% l’anno. Quindi, se si gestisce una grande azienda e si fa tutto come fanno le grandi aziende medie, ci si può aspettare di fare come la grande azienda media, cioè di crescere di circa il dieci per cento l’anno.

Ovviamente succederà la stessa cosa se gestisci una startup. Se si fa tutto nel modo in cui lo fa la startup media, ci si dovrebbero aspettare prestazioni medie. Il problema in questo caso è che prestazioni medie significano bancarotta. Il tasso di sopravvivenza delle startup è molto inferiore al cinquanta per cento. Quindi, se gestisci una startup, è meglio che tu faccia qualcosa di particolare. Altrimenti, sei nei guai.

Nel 1995, sapevamo qualcosa che non credo i nostri concorrenti capissero e che pochi capiscono ancora oggi: quando si scrive un software che deve funzionare solo sui propri server, si può usare qualsiasi linguaggio si voglia. Quando si scrive software per desktop, la forte tendenza è di scrivere applicazioni nello stesso linguaggio del sistema operativo. Dieci anni fa, scrivere applicazioni significava scrivere applicazioni in C. Con il software basato sul web, tuttavia, soprattutto quando si dispone del codice sorgente sia del linguaggio, sia del sistema operativo, è possibile utilizzare qualsiasi linguaggio si desideri.

Tuttavia, questa nuova libertà è un’arma a doppio taglio. Ora che puoi usare qualsiasi linguaggio, devi pensare a quale usare. Le aziende che cercano di fingere che nulla sia cambiato rischiano di scoprire che i loro concorrenti non lo fanno.

Se puoi usare qualsiasi linguaggio, quale usi? Noi abbiamo scelto Lisp. Da un lato, era ovvio che un rapido sviluppo sarebbe stato importante in questo mercato. Partivamo tutti da zero, quindi un’azienda che potesse realizzare nuove funzionalità prima dei suoi concorrenti avrebbe avuto un grande vantaggio. Sapevamo che Lisp era un ottimo linguaggio per scrivere software rapidamente e le applicazioni basate su server amplificano l’effetto dello sviluppo rapido, perché è possibile rilasciare il software nel momento in cui viene fatto.

Se altre aziende non volevano usare Lisp, tanto meglio. Avrebbe potuto darci un vantaggio tecnologico e avevamo bisogno di tutto l’aiuto possibile. Quando abbiamo avviato Viaweb, non avevamo esperienza negli affari. Non sapevamo niente di marketing, di assunzioni, di raccolta fondi, o di clienti. Nessuno di noi aveva mai avuto quello che si può definire un vero lavoro. L’unica cosa in cui eravamo bravi era scrivere software. Speravamo che questo ci avrebbe salvati. Qualsiasi vantaggio potessimo ottenere nel reparto software, lo avremmo sfruttato.

Quindi si potrebbe dire che usare Lisp è stato un esperimento. La nostra ipotesi era che se avessimo scritto il nostro software in Lisp, saremmo stati in grado di ottenere funzionalità più velocemente rispetto ai nostri concorrenti, e anche di fare nel nostro software cose che loro non potevano fare. E poiché Lisp era di così alto livello, non avremmo avuto bisogno di un grande team di sviluppo, quindi i nostri costi sarebbero stati inferiori. Se fosse stato così, avremmo offerto un prodotto migliore per meno soldi realizzando comunque un profitto. Avremmo ottenuto tutti gli utenti, i nostri concorrenti non ne avrebbero avuti e alla fine sarebbero falliti. Era quello che speravamo sarebbe accaduto, in ogni caso.

Quali sono stati i risultati di questo esperimento? Sorprendentemente, ha funzionato. Alla fine avevamo molti concorrenti, nell’ordine di venti o trenta, e nessuno dei loro software poteva competere con il nostro. Avevamo uno store builder online WYSIWYG che girava sul server, eppure sembrava un’applicazione desktop. I nostri concorrenti avevano script CGI. E noi eravamo sempre molto più avanti di loro in termini di funzionalità. A volte, per disperazione, i concorrenti cercavano di introdurre funzionalità che noi non avevamo. Ma con Lisp il nostro ciclo di sviluppo era talmente veloce che a volte potevamo duplicare una nuova funzione in un giorno o due da quando un concorrente la annunciava in un comunicato stampa. Nel momento in cui i giornalisti che si occupano del comunicato stampa iniziavano a chiamarci, anche noi avevamo la nuova funzionalità.

Ai nostri concorrenti deve essere sembrato che avessimo una specie di arma segreta, che stessimo decodificando il loro traffico Enigma o qualcosa del genere. In effetti avevamo un’arma segreta, ma era più semplice di quanto pensassero. Nessuno stava facendo trapelare notizie sulle loro funzionalità. Semplicemente, eravamo in grado di sviluppare software più velocemente di quanto si credesse possibile.

Quando avevo circa nove anni mi è capitata tra le mani una copia de Il giorno dello Sciacallo, di Frederick Forsyth. Il protagonista è un assassino assunto per uccidere il Presidente francese. L’assassino deve superare la polizia per raggiungere un appartamento che si affaccia sul percorso del Presidente. Si avvicina ai poliziotti, travestito da vecchio con le stampelle, e non sospettano mai di lui.

La nostra arma segreta era simile. Abbiamo scritto il nostro software in uno strano linguaggio per l’intelligenza artificiale, con una sintassi bizzarra piena di parentesi. Per anni mi aveva infastidito sentir descrivere Lisp in questo modo. Ma ora funzionava a nostro vantaggio. Nel mondo degli affari, non c’è niente di più prezioso di un vantaggio tecnico che i concorrenti non capiscono. Negli affari, come in guerra, la sorpresa vale quanto la forza.

E così, mi vergogno un po’ a dirlo, non ho mai detto niente pubblicamente su Lisp mentre lavoravamo su Viaweb. Non ne abbiamo mai parlato con la stampa e, se cerchi Lisp sul nostro sito web, tutto quello che troverai sono i titoli di due libri della mia biografia. Non è stato un caso. Una startup dovrebbe fornire ai concorrenti la minore quantità possibile di informazioni. Se non sapevano in che linguaggio era scritto il nostro software, o se non gli importava, volevo che rimanesse così [2].

Le persone che hanno compreso meglio la nostra tecnologia sono stati i clienti. A loro non importava in quale linguaggio fosse scritto Viaweb, ma si sono accorti che funzionava molto bene. Permetteva loro di costruire ottimi negozi online letteralmente in pochi minuti. E così, soprattutto per passaparola, abbiamo avuto sempre più utenti. Alla fine del 1996 avevamo circa 70 negozi online. Alla fine del 1997 ne avevamo 500. Sei mesi dopo, quando Yahoo ci comprò, avevamo 1070 utenti. Oggi, come Yahoo Store, questo software continua a dominare il proprio mercato. È uno degli elementi più redditizi di Yahoo, e i negozi costruiti in questo modo sono le fondamenta di Yahoo Shopping. Ho lasciato Yahoo nel 1999, quindi non so esattamente quanti utenti abbiano ora, ma l’ultima volta che ne ho sentito parlare erano circa 20.000.

Il paradosso di Blub

Cosa c’è di tanto eccezionale in Lisp? E se Lisp è tanto meraviglioso, perché non lo usano tutti? Sembrano domande retoriche, ma in realtà hanno risposte semplici. Lisp è eccezionale non per una qualche qualità magica visibile solo ai devoti, ma perché è semplicemente il linguaggio più potente disponibile. E il motivo per cui non tutti lo usano è che i linguaggi di programmazione non sono solo tecnologie, ma anche abitudini mentali, e niente cambia più lentamente. Naturalmente, entrambe queste risposte devono essere spiegate.

Inizierò con un’affermazione sorprendentemente controversa: i linguaggi di programmazione variano di potenza.

Pochi contesterebbero, almeno, che i linguaggi di alto livello siano più potenti del linguaggio macchina. La maggior parte dei programmatori oggi sarebbe d’accordo sul fatto che di solito non sia opportuno programmare in linguaggio macchina. Invece, si dovrebbe programmare in un linguaggio di alto livello e disporre di un compilatore che lo traduca in linguaggio macchina. Questa idea è ormai integrata anche nell’hardware: dagli anni ‘80, i set di istruzioni sono progettati per i compilatori anziché per i programmatori umani.

Tutti sanno che è un errore scrivere l’intero programma a mano in linguaggio macchina. Ciò che si capisce meno spesso è che in questo contesto esiste un principio più generale: se si ha la possibilità di scegliere tra diversi linguaggi, a parità di altre cose, è un errore programmare in tutto tranne che in quello più potente. [3]

Ci sono molte eccezioni a questa regola. Se si scrive un programma che deve lavorare a stretto contatto con un programma scritto in un certo linguaggio, potrebbe essere una buona idea scrivere il nuovo programma nello stesso linguaggio. Se si scrive un programma che deve fare solo qualcosa di molto semplice, come calcoli o manipolazione di bit, si può anche usare un linguaggio meno astratto, soprattutto perché può essere leggermente più veloce. E se si sta scrivendo un breve programma usa e getta, potrebbe essere più utile utilizzare qualsiasi linguaggio abbia le migliori funzioni di libreria per l’attività. Tuttavia, in generale, per il software applicativo, è opportuno usare il linguaggio più potente (ragionevolmente efficiente) che si possa ottenere e utilizzare qualsiasi altra cosa è un errore simile, anche se forse di minore impatto, alla programmazione in linguaggio macchina.

Si può vedere che il linguaggio macchina è di livello molto basso. Ma, almeno come una sorta di convenzione sociale, i linguaggi di alto livello sono spesso tutti trattati come equivalenti. Ma non è così. Tecnicamente il termine “linguaggio di alto livello” non significa nulla di molto definito. Non esiste una linea di demarcazione con i linguaggi macchina da un lato e tutti i linguaggi di alto livello dall’altro. I linguaggi ricadono lungo un continuum [4] di astrattezza, dai più potenti fino ai linguaggi macchina, che a loro volta variano di potenza.

Considera Cobol. Cobol è un linguaggio di alto livello, nel senso che viene compilato in linguaggio macchina. Qualcuno sosterrebbe seriamente che Cobol abbia una potenza equivalente, per esempio, a Python? Probabilmente è più vicino al linguaggio macchina di Python.

Oppure, che dire di Perl 4? Tra Perl 4 e Perl 5, sono state aggiunte le chiusure. La maggior parte degli hacker di Perl sarebbe d’accordo sul fatto che Perl 5 sia più potente di Perl 4. Ma una volta ammesso questo, si ammette che un linguaggio di alto livello può essere più potente di un altro. E ne consegue inesorabilmente che, tranne in casi particolari, si dovrebbe usare il più potente possibile.

Tuttavia, questa idea è raramente seguita fino in fondo. Dopo una certa età, i programmatori raramente cambiano linguaggio volontariamente. Qualunque sia il linguaggio a cui le persone sono abituate, tendono a considerarlo sufficientemente buono.

I programmatori si affezionano molto ai loro linguaggi preferiti, e non voglio ferire i sentimenti di nessuno, quindi per spiegare questo punto userò un ipotetico linguaggio chiamato Blub. Blub cade proprio nel mezzo del continuum dell’astrattezza. Non è il linguaggio più potente, ma è più potente del linguaggio Cobol o del linguaggio macchina.

E infatti, il nostro ipotetico programmatore Blub non userebbe nessuno dei due. È normale che non programmi in linguaggio macchina. È a questo che servono i compilatori. E per quanto riguarda Cobol, non sa sinceramente come ci si possa fare qualcosa. Non ha nemmeno x (funzionalità che Blub ha).

Finché il nostro ipotetico programmatore Blub osserva il continuum di potenza dall’alto verso il basso, sa di guardare giù. I linguaggi meno potenti di Blub lo sono ovviamente perché mancano alcune funzionalità a cui è abituato. Ma quando il nostro ipotetico programmatore di Blub guarda nell’altra direzione, verso l’alto del continuum di potenza, non si rende conto di guardare in su. Ciò che vede sono solo linguaggi strani. Probabilmente li considera quasi equivalenti in potenza a Blub, ma con tant’altra roba inutile in aggiunta. Blub per lui è sufficientemente buono, perché pensa in Blub.

Quando passiamo al punto di vista di un programmatore che utilizza uno dei linguaggi più alti del continuum di potenza, tuttavia, troviamo che questi a sua volta guarda Blub dall’alto verso il basso. Come si riesce fare qualcosa in Blub? Non ha nemmeno y.

Per induzione, gli unici programmatori in grado di vedere tutte le differenze di potenza tra i vari linguaggi sono quelli che capiscono il più potente. (Questo è probabilmente ciò che Eric Raymond intendeva sul fatto che Lisp rendesse un programmatore migliore). Non ci si può fidare delle opinioni degli altri, a causa del paradosso di Blub: gli altri sono soddisfatti del loro linguaggio perché definisce proprio il modo con cui ideano software.

Lo so per esperienza personale, quando ero un liceale e scrivevo programmi in Basic. Quel linguaggio non supportava nemmeno la ricorsione. È difficile immaginare di scrivere programmi senza utilizzare la ricorsione, ma all’epoca non mi mancava. Pensavo in Basic. Ed ero un mago. Padrone di tutto ciò che studiavo.

I cinque linguaggi che Eric Raymond raccomanda agli hacker ricadono in vari punti del continuum di potenza. Dove ricadono l’uno rispetto all’altro è un argomento delicato. Dirò soltanto che credo che Lisp sia in cima. E a sostegno di questa affermazione ti dirò una delle cose che ritengo manchino quando osservo gli altri quattro linguaggi. Penso, come ci si può realizzare qualcosa senza macro? [5]

Molti linguaggi hanno una cosa chiamata macro. Ma le macro di Lisp sono uniche. E che tu ci creda o no, quello che fanno è legato alle parentesi. I designer di Lisp non hanno messo tutte quelle parentesi nel linguaggio solo per essere diversi. Agli occhi del programmatore di Blub, il codice Lisp sembra strano. Ma quelle parentesi sono lì per un motivo. Sono la prova evidente di una differenza fondamentale tra il lisp e gli altri linguaggi.

Il codice Lisp è composto da Lisp data objects. E non è scontato che i file di origine contengono caratteri e che le stringhe sono uno dei tipi di dati supportati dal linguaggio. Il codice Lisp, dopo essere stato letto dal parser, è costituito da strutture di dati che è possibile attraversare.

Conoscendo il funzionamento dei compilatori, ciò che succede non è tanto che Lisp abbia una strana sintassi, quanto che Lisp non ha una sintassi. Si scrivono programmi negli alberi di analisi che vengono generati all’interno del compilatore mentre vengono analizzati altri linguaggi. Ma questi alberi di analisi sono completamente accessibili dai propri programmi. È possibile scrivere programmi che li manipolino. In Lisp, questi programmi sono chiamati macro. Sono programmi che scrivono programmi.

Programmi che scrivono programmi? Quando mai vorresti fare una cosa del genere? Non molto spesso, se pensi in Cobol. Sempre, se pensi in Lisp. Sarebbe comodo ora se potessi fare un esempio di una macro potente e dire: eccola! cosa ne pensi? Ma se lo facessi, sembrerebbe un’assurdità per qualcuno che non conosce Lisp; non c’è spazio qui per spiegare tutto quello che dovresti sapere per capire cosa significa. In Ansi Common Lisp ho cercato di procedere il più velocemente possibile, e anche così non sono arrivato alle macro fino a pagina 160.

Ma credo di poter fornire un tipo di argomentazione che potrebbe essere convincente. Il codice sorgente dell’editor di Viaweb era probabilmente circa il 20-25% di macro. Le macro sono più difficili da scrivere rispetto alle normali funzioni Lisp, ed è considerato cattivo stile usarle quando non sono necessarie. Quindi ogni macro in quel codice è lì perché deve esserci. Ciò significa che almeno il 20-25% del codice di questo programma fa cose che non si possono fare facilmente in qualsiasi altro linguaggio. Per quanto scettico possa essere il programmatore di Blub riguardo alle mie affermazioni sui misteriosi poteri di Lisp, questo dovrebbe incuriosirlo. Non stavamo scrivendo questo codice per divertimento. Eravamo una minuscola startup, che programmava il più duramente possibile per mettere barriere tecniche tra noi e i nostri concorrenti.

Una persona sospettosa potrebbe cominciare a chiedersi se ci sia una qualche correlazione. Una grossa parte del nostro codice faceva cose che sono molto difficili da fare in altri linguaggi. Il software che ne risultava faceva cose che il software dei nostri concorrenti non poteva fare. Forse c’era una qualche connessione. Ti invito a seguire questo filo. Quel vecchio che zoppica con le stampelle potrebbe essere qualcosa di più di ciò che sembra.

Aikido per startup

Tuttavia, non mi aspetto di convincere nessuno (oltre i 25 anni) a imparare Lisp. Lo scopo di questo articolo non è quello di far cambiare idea a qualcuno, ma di rassicurare le persone già interessate ad usare Lisp. Persone che sanno che Lisp è un linguaggio potente, ma si preoccupano perché non è molto usato. In una situazione competitiva, questo è un vantaggio. La potenza di Lisp è moltiplicata dal fatto che i concorrenti non lo capiscono.

Se si pensa di utilizzare Lisp in una startup, non ci si dovrebbe preoccupare del fatto che non sia ampiamente compreso. Dovresti sperare che rimanga così. Ed è probabile che accada. È la natura dei linguaggi di programmazione che rende la maggior parte delle persone soddisfatte di qualsiasi cosa utilizzino attualmente. L’hardware del computer cambia così velocemente rispetto alle abitudini personali che la pratica di programmazione di solito è di dieci-vent’anni indietro rispetto al processore. In posti come il MIT scrivevano programmi in linguaggi di alto livello nei primi anni ‘60, ma molte aziende hanno continuato a scrivere codice in linguaggio macchina fino agli anni ‘80. Scommetto che molte persone hanno continuato a scrivere il linguaggio macchina fino a quando il processore, come un barista desideroso di chiudere e tornare a casa, alla fine li ha buttati fuori passando a un set di istruzioni RISC.

Normalmente la tecnologia cambia velocemente. Ma i linguaggi di programmazione sono diversi: i linguaggi di programmazione non sono solo tecnologia, ma il modo in cui pensano i programmatori. Sono per metà tecnologia e per metà religione. [6] E così il linguaggio medio, vale a dire qualunque sia il linguaggio usato dal programmatore medio, si muove lento come un iceberg. La Garbage Collection (GC, letteralmente raccolta di rifiuti), introdotta da Lisp intorno al 1960, ora è ampiamente considerata come una cosa positiva. Idem per la digitazione in runtime, la cui popolarità sta aumentando. Le chiusure, introdotte da Lisp nei primi anni ‘70, ora sono a malapena sullo schermo radar. Le macro, introdotte da Lisp a metà degli anni ‘60, sono ancora terra incognita.

Ovviamente, il linguaggio medio ha un enorme slancio. Non sto proponendo di combattere questa potente forza. Quello che propongo è esattamente il contrario: che, come un praticante di Aikido, si possa utilizzare questo vantaggio contro gli avversari.

Se lavori per una grande azienda, potrebbe non essere facile. Farai fatica a convincere il capo dai capelli alla moda a lasciarti costruire cose in Lisp, quando ha appena letto sul giornale che qualche altro linguaggio è pronto a conquistare il mondo, come Ada vent’anni fa. Ma se lavori per una startup che non ha ancora capi con acconciature alla moda, puoi, come abbiamo fatto noi, capovolgere il paradosso di Blub a tuo vantaggio: puoi utilizzare una tecnologia che i tuoi concorrenti, incollati in modo immobile al linguaggio medio, non potranno mai eguagliare.

Se mai dovessi trovarti a lavorare per una startup, ecco un consiglio pratico per valutare i concorrenti. Leggi i loro annunci di lavoro. Sul loro sito tutto il resto possono essere foto di repertorio o l’equivalente di una prosa, ma gli annunci di lavoro devono essere specifici su ciò che vogliono, o riceveranno le candidature sbagliate.

Nel corso degli anni in cui abbiamo lavorato su Viaweb ho letto molte descrizioni di mansioni. Ogni mese circa un nuovo concorrente sembrava uscire allo scoperto. La prima cosa che facevo, dopo aver controllato se avevano una demo online dal vivo, era guardare i loro annunci di lavoro. Dopo un paio di anni ero in grado di dire di quali aziende preoccuparsi e di quali no. Più le descrizioni delle mansioni avevano un carattere IT, meno l’azienda era pericolosa. Quelle più innocue erano quelle che volevano esperienza in Oracle. Non ci si doveva mai preoccupare di quelle. Erano innocue anche se dicevano che volevano sviluppatori C++ o Java. Se volevano programmatori Perl o Python, poteva essere un po’ pericoloso: cominciava a sembrare un’azienda dove l’aspetto tecnico, almeno, era gestito da veri e propri hacker. Se avessi mai visto un annuncio di lavoro per la ricerca di hacker Lisp, sarei stato davvero preoccupato.

Note

[1] Viaweb inizialmente aveva due parti: l’editor, scritto in Lisp, che le persone usavano per costruire i loro siti, e il sistema di ordinazione, scritto in C, che gestiva gli ordini. La prima versione era per lo più Lisp, perché il sistema di ordinazione era piccolo. Successivamente abbiamo aggiunto altri due moduli, un generatore di immagini scritto in C e un gestore di back-office scritto principalmente in Perl.

Nel mese di gennaio 2003, Yahoo ha rilasciato una nuova versione dell’editor scritta in C++ e Perl. È difficile dire se il programma sia ancora scritto in Lisp, perché per tradurre questo programma in C++ hanno dovuto letteralmente scrivere un interprete Lisp: i file sorgente di tutti i modelli di generazione di pagine sono ancora, per quanto ne so, codice Lisp. (Si veda la decima regola di Greenspun).

[2] Robert Morris dice che non avevo bisogno di essere riservato, perché anche se i nostri concorrenti avessero saputo che stavamo usando Lisp, non avrebbero capito il perché: “Se fossero stati così intelligenti, avrebbero già programmato in Lisp”.

[3] Tutti i linguaggi sono ugualmente potenti nel senso di essere equivalenti Turing, ma non è questo il senso della parola che interessa ai programmatori. (Nessuno vuole programmare una macchina di Turing). Il tipo di potere a cui tengono i programmatori potrebbe non essere formalmente definibile, ma un modo per spiegarlo sarebbe dire che si riferisce a funzionalità che si possono solo ottenere nel linguaggio meno potente se si scrive al suo interno un interprete per il linguaggio più potente. Se il linguaggio A ha un operatore per rimuovere gli spazi dalle stringhe e il linguaggio B no, questo probabilmente non rende A più potente, perché presumibilmente si può scrivere una subroutine per farlo in B. Tuttavia, se A supporta, diciamo, la ricorsione, e B no, questo non è probabile che si possa risolvere scrivendo funzioni di libreria.

[4] Nota per i nerd: o forse un reticolo, che si restringe verso l’alto; non è la forma che conta qui, ma l’idea che ci sia almeno un ordine parziale.

[5] È un po’ fuorviante trattare le macro come una funzionalità separata. In pratica la loro utilità è notevolmente migliorata da altre funzionalità di Lisp come le chiusure lessicali e i parametri REST.

[6] Di conseguenza, i confronti tra i linguaggi di programmazione assumono la forma di guerre religiose o di libri di testo universitari così decisamente neutri da essere davvero opere di antropologia. Le persone che vogliono stare in pace, o vogliono una carica, evitano l’argomento. Tuttavia, la questione è solo per metà religiosa; c’è qualcosa che vale la pena di studiare, soprattutto se si vuole progettare nuovi linguaggi.