Battere i mediocri

Posted on 10 March 2012 by Paolo Bernardi

Mentre sistemavo alcuni vecchi file, ho ritrovato questa traduzione del celebre saggio di Paul Graham “Beating the averages”. Sono sicuro di averla scritta per farla leggere a qualcuno: pubblicandola sul mio blog forse arriverà anche al suo destinatario iniziale, sebbene non mi ricordi più chi sia. In ogni caso è un’ottima lettura.

Battere i mediocri

Nell’estate 1995, il mio amico Robert Morris ed io abbiamo fondato una startup chiamata Viaweb. Il nostro piano era scrivere un software che permettesse agli utenti finali di creare i propri negozi online. La novità riguardo questo software, all’epoca, era che girava sui nostri server, usando comuni pagine Web come interfaccia.

Un sacco di persone potrebbero aver avuto quest’idea nello stesso periodo, ovviamente, ma per quanto io sappia, Viaweb è stata la prima applicazione basata sul Web. Sembrava un’idea così innovativa che abbiamo chiamato la startup con lo stesso nome dell’applicazione: Viaweb, perché il nostro software funzionava effettivamente via Web, invece di girare sul tuo computer.

Un’altra cosa inusuale riguardo questo software è che era stato scritto principalmente in un linguaggio di programmazione chiamato Lisp. Era una delle prime applicazioni utente di dimensioni notevoli ad essere scritta in Lisp, che fino ad allora era stato usato per lo più soltanto nelle università e nei laboratori di ricerca1.

L’arma segreta

Eric Raymond ha scritto un saggio intitolato “Come diventare un hacker” (n.d.t. How To Become A Hacker) e nello stesso, tra le altre cose, dice agli aspiranti hacker quali linguaggi dovrebbero imparare. Egli suggerisce di iniziare con Python e Java, perché sono semplici da imparare. L’hacker serio vorrà poi imparare anche il C, al fine di “hackerare” Unix, ed il Perl per l’amministrazione del sistema e script CGI. Infine, l’hacker con intenzioni veramente serie dovrebbe considerare di imparare il Lisp:

Il Lisp è degno di essere appreso per l’esperienza profondamente illuminante che avrai quando riuscirai infine a comprenderlo; quest’esperienza ti renderà un programmatore migliore per il resto dei tuoi giorni, anche se non userai il Lisp molto spesso.

Si tende a sentire la stessa argomentazione circa l’apprendimento del latino. Non ti procurerà un lavoro, eccetto forse come professore di materie classiche, tuttavia migliorerà la tua mente e ti renderà uno scrittore migliore nei linguaggi che vorrai usare, come l’inglese (n.d.t. o l’italiano: parlo per esperienza personale).

Ma aspetta un momento: questa metafora non può essere stiracchiata così tanto. La ragione per cui il latino non ti procurerà un lavoro è che nessuno lo parla. Se scrivi in latino, nessuno potrà comprenderti. Ma il Lisp è un linguaggio per computer ed il computer capisce qualsiasi linguaggio che tu, il programmatore, gli dici di capire.

Perciò se il Lisp ti rende un programmatore migliore, come dice Eric, perché non usarlo? Se ad un pittore venisse offerto un pennello che lo rendesse un pittore migliore, credo che vorrebbe usarlo in tutti i suoi dipinti, non è vero? Non sto cercando di ridicolizzare Eric Raymond. Nel complesso, il suo suggerimento è buono. Ciò che dice riguardo il Lisp è saggezza comune. Ma c’è una contraddizione in questa saggezza comune: il Lisp ti renderà un programmatore migliore, eppure non lo userai.

Perché no? I linguaggi di programmazione sono soltanto strumenti, dopo tutto. Se il Lisp consente veramente di creare programmi migliori, dovresti usarlo. E se non lo consente, allora chi ne ha bisogno?

Questa domanda non è solo teorica. Il business del software è altamente competitivo e propenso a monopoli naturali. Un’impresa che scrive software migliore più velocemente degli altri, a parità di condizioni, spingerà i suoi concorrenti fuori mercato: quando stai fondando una startup sei molto sensibile a questo fatto. Le startup tendono ad essere proposizioni del tipo tutto o niente. Puoi diventare ricco oppure non guadagnare niente. Se in una startup scommetti sulla tecnologia sbagliata, i concorrenti ti distruggeranno.

Sia Robert che io conoscevamo bene il Lisp e non potevamo vedere alcun motivo per non fidarci dei nostri istinti ed usarlo. Sapevamo che tutti gli altri scrivevano i loro software in C++ o Perl, tuttavia ciò non significava nulla. Se scegli una tecnologia da usare in questo modo, useresti Windows. Quando scegli una tecnologia devi ignorare ciò che gli altri stanno facendo e considerare solo ciò che funziona meglio.

Ciò è specialmente vero in una startup. In una grande compagnia puoi fare tutto quello che le altre grandi compagnie stanno già facendo, ma in una startup non puoi fare ciò che le altre startup stanno facendo. Non credo che molte persone si rendano conto di questo fatto, persino nelle startup.

La tipica grande compagnia cresce circa del 10% l’anno. Perciò se stai guidando una grande compagnia e fai ciò che le altre tipiche grandi compagnie fanno, puoi aspettarti di ottenere i risultati tipici proprio delle grandi compagnie: crescere del 10% l’anno, appunto.

La stessa cosa accade nel caso in cui tu stia guidando una startup, ovviamente: se fai tutto allo stesso modo della startup media, dovrai aspettarti delle prestazioni mediocri. In questo caso il problema è che avere prestazioni mediocri significa andare fuori mercato. Il tasso di sopravvivenza delle startup è assai minore del 50%. Perciò se stai guidando una startup ti conviene fare qualcosa di inusuale. Se non lo fai, sei nei guai.

Tornando al 1995, eravamo a conoscenza di qualcosa che non credo fosse chiaro ai nostri concorrenti, soltanto pochi di essi lo capiscono perfino oggi: quando scrivi del software che deve girare solo nei tuoi server, puoi usare qualsiasi linguaggio tu voglia. Quando scrivi software desktop invece c’è un forte pregiudizio circa l’usare lo stesso linguaggio con cui è stato scritto il sistema operativo. Dieci anni fa scrivere applicazioni significava scrivere applicazioni in C. Ma con il software basato sul Web, specialmente quando hai il codice sia del linguaggio di programmazione che del sistema operativo, puoi usare qualsiasi linguaggio tu voglia.

Questa nuova libertà è una lama a doppio taglio, tuttavia: ora che puoi usare qualsiasi linguaggio, devi pensare bene a quale usare. Le compagnie che pretendono di andare avanti come se se non fosse successo niente rischiano di trovarsi di fronte al fatto che i loro concorrenti hanno cambiato rotta.

Se puoi usare qualsiasi linguaggio, quale dovresti usare? Noi abbiamo scelto il Lisp. Innanzitutto, era ovvio che la rapidità di sviluppo sarebbe stata importante in questo tipo di mercato. Dovevamo partire da zero, perciò una compagnia che avesse potuto aggiungere delle nuove caratteristiche al proprio software prima dei suoi concorrenti avrebbe avuto un grosso vantaggio. Sapevamo che il Lisp era un linguaggio veramente buono per scrivere software rapidamente e le applicazioni server-based amplificano gli effetti della rapidità di sviluppo, perché puoi rilasciare il software nello stesso istante in cui è stato fatto.

Se le altre compagnie non volevano usare il Lisp, tanto meglio. Questa situazione ci avrebbe dato un vantaggio tecnologico e avevamo bisogno di tutti gli aiuti possibili. Quando abbiamo fondato Viaweb non avevamo alcuna esperienza di business. Non sapevamo nulla sul marketing, sull’assunzione del personale, sull’accumulare denaro o su come procurarci clienti. Nessuno di noi avrebbe mai voluto ciò che viene chiamato “un lavoro vero”. L’unica cosa che eravamo bravi a fare era scrivere software. Speravamo che ciò ci avrebbe salvati, pertanto avremmo sfruttato ogni vantaggio che potevamo ottenere per quanto riguarda il software.

Quindi si potrebbe dire che usare il Lisp è stato un esperimento. La nostra ipotesi era che se avessimo scritto il nostro software in Lisp saremmo stati in grado di aggiungervi caratteristiche più rapidamente dei nostri concorrenti, oltre a rendere il nostro software in grado di fare cose che i loro non potevano fare. Proprio perché il Lisp era così di alto livello non avevamo bisogno di un grande team di sviluppo software, perciò i nostri costi sarebbero stati bassi. Per questo motivo, potevamo offrire un prodotto migliore a prezzo più basso e comunque ricavarci del profitto. Alla fine saremmo arrivati al punto in cui avremmo avuto tutti gli utenti, mentre i nostri concorrenti non ne avrebbero avuto più nessuno e sarebbero usciti dal mercato. Queste erano le nostre speranze, almeno.

Quali sono stati i risultati di questo esperimento? Abbastanza sorprendentemente, ha funzionato. Abbiamo avuto parecchi concorrenti, circa venti o trenta, ma nessuno dei loro software poteva competere col nostro. Avevamo un creatore di negozi online WYSIWYG (n.d.t. What You See Is What You Get, quello che vedi è effettivamente il prodotto finito) che veniva eseguito su un server ma sembrava un’applicazione desktop. I nostri concorrenti avevano script CGI, e li superavamo sempre per quanto riguarda le caratteristiche del software. Qualche volta, come segno di disperazione, i nostri concorrenti provavano ad introdurre nei loro software caratteristiche che il nostro non aveva. Ma usando il Lisp il nostro ciclo di sviluppo era così veloce che potevamo duplicare tali caratteristiche nel giro di uno o due giorni dopo l’annuncio da parte di un concorrente in un comunicato stampa. Quando arrivava il momento in cui i giornalisti pubblicavano articoli basati su tali comunicati, anche noi avevamo le stesse novità.

Probabilmente i nostri concorrenti credevano che avevamo qualche sorta di arma segreta, che stavamo decifrando le loro comunicazioni basate su Enigma o qualcosa del genere. Infatti avevamo un’arma segreta, ma era più semplice di quel che pensavano. Nessuno ci spifferava le loro novità in anticipo, semplicemente eravamo in grado di sviluppare software più rapidamente di quanto chiunque avesse ritenuto possibile.

Quando avevo più o meno nove anni mi è arrivata tra le mani una copia de “Il giorno dello sciacallo”, di Frederick Forsyth. Il protagonista è un assassino ingaggiato per uccidere il presidente della Francia. L’assassino deve superare la polizia per arrivare ad un appartamento proprio sopra la strada in cui sarebbe passato il presidente. Per fare ciò è semplicemente passato attraverso il cordone di polizia vestito come un vecchio con le stampelle e nessuno ha sospettato di lui.

La nostra arma segreta era simile: scrivevamo il nostro software in uno strano linguaggio usato per la ricerca sull’intelligenza artificiale, con una sintassi bizzarra piena di parentesi. Per anni mi seccava sentire il Lisp descritto in questo modo, ma ora la cosa era a nostro vantaggio. Nel business non c’è niente che abbia più valore di un vantaggio tecnico che i tuoi concorrenti non sono in grado di capire. Nel business, come in guerra, la sorpresa conta tanto quanto la forza.

Perciò, anche se confessarlo mi imbarazza un po’, non abbiamo mai detto nulla pubblicamente riguardo il Lisp mentre stavamo lavorando su Viaweb. Non l’abbiamo mai menzionato alla stampa e se avessi fatto ricerce sul Lisp nel nostro sito tutto ciò che avresti trovato sarebbero stati i titoli di due dei miei libri nella mia bibliografia. Ciò non è stato casuale. Una startup dovrebbe dare ai propri concorrenti meno informazioni possibili. Sia che non fossero a conoscenza del linguaggio con cui scrivevamo il nostro software o che non se ne preoccupassero, volevo mantenere la situazione in questo modo2.

Le persone che hanno meglio compreso la nostra tecnologia erano i clienti. Non gli importava in quale linguaggio Viaweb fosse stato scritto, ma notavano che funzionava veramente bene. Gli permetteva di creare dei bellissimi negozi online letteralmente in pochi minuti. Perciò, grazie al passa parola abbiamo ottenuto sempre più utenti: alla fine del 1997 ne avevamo 500. Sei mesi dopo, quando Yahoo ci ha comprato, avevamo 1070 utenti. Oggi, con il nome di Yahoo Store, questo software continua a dominare la sua nicchia di mercato. È uno dei rami più remunerativi di Yahoo ed i negozi creati con esso sono stati alla base di Yahoo Shopping. Ho lasciato Yahoo nel 1999, perciò non so esattamente quanti utenti abbiano attualmente, ma l’ultima volta che avevo controllato erano circa 20000.

Il paradosso del Blub

Cos’ha il Lisp di così fantastico? E se il Lisp è così fantastico, perché non lo usano tutti? Queste domande potrebbero sembrare retoriche, tuttavia hanno una risposta immediata. Il Lisp non è così fantastico perché ha una qualche caratteristica magica visibile soltanto ai suoi devoti, ma perché è semplicemente il più potente linguaggio disponibile. E la ragione per cui non è usato da tutti è che i linguaggi di programmazione non sono mere tecnologie ma anche abitudini mentali, e niente cambia più lentamente di quest’ultime. Ovviamente, entrambe le risposte che ho appena dato hanno bisogno di spiegazioni.

Inizierò con un’affermazione incredibilmente controversa: i linguaggi di programmazione hanno potenzialità differenti.

In pochi obbiettano, almeno, che i linguaggi di alto livello sono più potenti dei linguaggi macchina. La maggior parte dei programmatori odierni sarebbero d’accordo sul non voler, quando possibile, programmare in linguaggio macchina. Dovresti invece programmare in un linguaggio di alto livello ed avere un compilatore che traduca ciò che hai scritto in linguaggio macchina al posto tuo. Quest’idea è stata perfino inclusa nell’hardware, ad oggi: a partire dagli anni 80, gli instruction set sono stati progettati per facilitare il lavoro dei compilatori, piuttosto che quello dei programmatori umani.

Chiunque sa che è un errore scrivere il proprio programma completamente a mano in linguaggio macchina. Ciò che è spesso meno compreso invece è che c’è un principio più generale basato sull’affermazione precedente: se puoi scegliere tra diversi linguaggi è un errore, a parità di fattori, programmare con qualsiasi altra cosa che non sia la più potente.3

Ci sono molte eccezioni a questa regola: stai scrivendo un programma che deve funzionare a stretto contatto con un’altro programma scritto in un certo linguaggio potrebbe essere una buona idea usare proprio tale linguaggio. Se stai scrivendo un programma che deve fare soltanto qualcosa di molto semplice, come calcoli prettamente numerici o manipolazioni di bit, potresti tranquillamente usare linguaggi meno astratti, specialmente perché il risultato potrebbe essere più veloce. E se stai scrivendo un piccolo programma usa e getta potresti tranquillamente usare qualsiasi linguaggio che abbia la libreria col miglior supporto per il compito che devi svolgere. Ma in generale, per software applicativo, dovresti usare il linguaggio più potente (e ragionevolmente efficiente) su cui puoi mettere le mani, usare qualsiasi altra cosa sarebbe uno sbaglio esattamente come, anche se forse un po’ meno di, programmare in linguaggio macchina.

Puoi tranquillamente renderti conto di come il linguaggio macchina sia di basso livello. Tuttavia, almeno come convenzione sociale, i linguaggi di lato livello vengono spesso trattati come equivalenti: non lo sono. Tecnicamente, la definizione di “linguaggio di alto livello” non ha un significato molto ben definito. Non c’è una separazione netta tra i linguaggi macchina da una parte ed i linguaggi di alto livello dall’altra. I linguaggi sono posizionati nel continuum4 dell’astrazione, dal più potente fino al linguaggio macchina e ciascuno ha potenzialità differenti.

Considera il Cobol. Il Cobol è un linguaggio di alto livello nel senso che viene compilato in linguaggio macchina. Esiste forse qualcuno che vorrebbe dire che il Cobol è potente tanto quanto, diciamo, Python? Probabilmente è più vicino al linguaggio macchina che a Python.

Oppure, riguardo Perl 4? Nel passaggio tra Perl 4 e Perl 5 sono state aggiunte le chiusure lessicali al linguaggio. La maggior parte degli hacker sarebbe d’accordo sul fatto che Perl 5 è più potente di Perl 4. Ma una volta fatta questa ammissione hai anche ammesso che un linguaggio di alto livello può essere più potente di un’altro. Da ciò segue inesorabilmente che, eccetto in casi speciali, dovresti usare il più potente che hai a disposizione.

Quest’idea è raramente seguita fino alla sua conclusione, comunque. Dopo una certa età è raro che i programmatori cambino volontamente i linguaggio che usano. Qualsiasi cosa si siano abituati ad usare, tendono a considerarla abbastanza buona.

I programmatori si affezionano molto ai propri linguaggi preferiti e poiché non voglio urtare la loro sensibilità, spiegherò le mie ragioni usando un linguaggio ipotetico di nome Blub. Blub cade esattamente nel mezzo del continuum dell’astrazione. Non è il linguaggio più potente, ma è sicuramente più potente del Cobol e del linguaggio macchina.

Infatti il nostro ipotetico programmatore Blub non vorrebbe usare nessuno di quei due. Oviamente non vorrebbe programmare in linguaggio macchina: per quello ci sono i compilatori. Per quanto riguarda il Cobol, non si capacita di come qualcuno possa riuscire a farci qualcosa. Non ha nemmeno x (dove x è una caratteristica di Blub a tua scelta).

Fino a quando in nostro programmatore ipotetico guarda in basso nel continuum dell’astrazione, è conscio di guardare in basso. I linguaggi meno potenti di Blub sono ovviamente meno potenti, perché mancanti di alcune caratteristiche cui egli è abituato. Ma quando il nostro ipotetico programmatore Blub guarda nell’altra direzione, verso la parte alta del continuum, non si rende conto di cosa stia veramente osservando. Quello che vede sono soltanto linguaggi strani. Probabilmente li considera tutti più o meno potenti come Blub, ma con un sacco di roba strana e spaventosa in più. Per lui Blub è abbastanza poiché pensa in Blub.

Quando invece assumiamo il punto di vista di un programmatore che usa un qualsiasi linguaggio posizionato più in alto nel continuum, tuttavia, vediamo che egli guarda in basso verso Blub: come può qualcuno fare qualcosa con Blub? Non ha neanche y.

Per induzione, gli unici programmatori nella posizione di vedere tutte le differenze nel potere dei vari linguaggi sono quelli che capiscono il più potente (è questo probabilmente che Eric Raymond intendeva dire circa il fatto che il Lisp ti rende un programmatore migliore). Non puoi fidarti delle opinioni degli altri a causa del paradosso di Blub: essi sono soddisfatti dei linguaggi che gli capita di usare perché questi plasmano il modo in cui pensano riguardo i programmi che scrivono.

Ho avuto conferma di questa fatto nella mia esperienza come ragazzino delle superiori che scriveva programmi in Basic. Quel linguaggio non supportava neanche la ricorsione. È dura immaginare di scrivere programmi senza la ricorsione, ma a quel tempo non ne sentivo la mancanza. Pensavo in Basic, ed ero un mago nell’usarlo. Ero il padrone di tutto ciò su cui posavo lo sguardo.

I cinque linguaggi che Eric Raymond raccomanda agli hacker ricadono in diversi punti del continuum del potere di astrazione. Dove ricadano esattamente l’uno rispetto all’altro è un’argomento delicato. Ciò che dirò è che ritengo che il Lisp sia in cima. E per supportare quest’affermazione ti dirò quali caratteristiche ritengo mancare quando guardo gli altri quattro linguaggi: come puoi fare qualsiasi cosa con questi, penso, senza le macro?5

Molti linguaggi hanno qualcosa chiamata macro, ma le macro del Lisp sono uniche. E, che tu ci creda o meno, ciò che fanno è in relazione con le parentesi. I progettisti del Lisp non hanno messo tutte quelle parentesi nel linguaggio per farlo sembrare strano. Al programmatore Blub il codice Lisp sembra strano, tuttavia quelle parentesi sono lì per un motivo. Sono la principale manifestazione esteriore di una differenza fondamentale tra il Lisp e gli altri linguaggi.

Il codice Lisp è composto di oggetti dati Lisp. E non nel banale senso che il codice sorgente contiene caratteri, e le stringhe sono uno dei tipi di dato supportati dal linguaggio. Il codice Lisp, dopo che è stato letto dal parser, è composto da strutture dati che puoi scorrere.

Se comprendi il funzionamento dei compilatori, noterai che in realtà il Lisp non ha una sintassi un po’ strana: non ha proprio alcuna sintassi. Quando scrivi programma in Lisp in realtà stai scrivendo l’albero sintattico (n.d.t. “parse tree”) che di norma è generato dal compilatore negli altri linguaggi all’atto del parsing. Ma poiché questi alberi sintattici sono completamente accessibili nei tuoi programmi, puoi scrivere programmi che li manipolano. In Lisp i programmi di questo tipo sono chiamati macro. Sono programmi che scrivono altri 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. In questo caso sarebbe conveniente se ti fornissi una potente macro di esempio e, perché no? Ma se lo facessi, sembrerebbe semplicemente spazzatura agli occhi di chi non conosce il Lisp; non c’è abbastanza spazio, qui, per spiegare tutto ciò che dovresti sapere per comprendere cosa intendo. In Ansi Common Lisp o provato ad introdurre le macro il prima possibile, eppure non sono riuscito a farlo prima di pagina 160.

Ma credo di poter fornire un tipo di ragionamento che potrebbe essere convincente. Il sorgente dell’editor di Viaweb era probabilmente circa il 20-25% composto di macro. Le macro sono più difficili da scrivere rispetto alle funzioni Lisp ordinarie ed è considerato pessimo stile usarle quando non sono necessarie. Perciò ogni macro nel codice è lì perché deve esserci. Ciò che significa è che almeno il 20-25% del codice in questo programma sta facendo cose che non puoi facilmente fare in altri linguaggi. Per quanto scettico il programmatore Blub possa essere nei confronti delle mie affermazioni circa i misteriosi poteri del Lisp, questo dovrebbe incuriosirlo. Non stavamo scrivendo codice per divertirci. Eravamo una piccola startup, programmavamo il più duramente possibile al fine di inserire delle barriere tecniche tra noi e i nostri concorrenti. Una persona sospetta potrebbe chiedersi se c’è una correlazione: un bel pezzo di codice è stato scritto facendo cose che sono molto difficili da fare in altri linguaggi e il software risultante è stato qualcosa che i nostri concorrenti non potevano fare. Probabilmente c’era una qualche connessione. Ti incoraggio a seguire quella trama, potrebbe esserci qualcosa di più di quel che sembra in quel vecchio uomo con le stampelle che zoppica.

Aikido per le startup

Non mi aspetto di convincere qualcuno (che abbia superato i 25 anni di età) ad imparare il Lisp. Lo scopo di questo articolo non è cambiare i pensieri di nessuno, ma di rassicurare le persone che sono già interessate nell’usare il Lisp, persone che sanno che il Lisp è un linguaggio potente ma si preoccupano perché non è molto usato. Il potere del Lisp è amplificato dal fatto che i tuoi concorrenti non lo comprendono.

Se hai intenzione di usare il Lisp in una startup non dovresti preoccuparti del fatto che non è ampiamente compreso. Dovresti anzi sperare che le cose rimangano in questo modo, e molto probabilmente sarà così. È nella natura dei linguaggi di programmazione il rendere soddisfatti gli utenti di quello che stanno li stanno usando in questo momento. L’hardware dei computer cambia molto più velocemente delle abitudini personali al punto che le pratiche di programmazione sono 10 o 20 anni indietro rispetto ai processori. In posti come il MIT stavano scrivendo programmi in linguaggi di alto livello in dai primi anni 60, tuttavia molte ditte hanno continuato a scrivere codice in linguaggio macchina fino agli anni 80. Scommetto che un sacco di persone hanno continuato a scrivere in linguaggio macchina fino a quando i processori, come un barista ansioso di chiudere e tornare a casa, li hanno cacciati via passando da un set di istruzioni CISC ad uno di tipo RISC.

Ordinariamente la tecnologia cambia velocemente. Tuttavia i linguaggi di programmazione sono diversi: i linguaggi di programmazione non sono solo tecnologia, ma ciò in cui i programmatori pensano. Sono metà tecnologia e metà religione.6 Perciò il linguaggio medio, ovvero qualsiasi linguaggio usato dal programmatore medio, si muove lento come un iceberg. La garbage collection, introdotta nel Lisp negli anni 60, ora è considerata generalmente una buona cosa. Allo stesso tempo, la tipizzazione a runtime sta crescendo di popolarità. Le chiusure lessicali, cresciute nel Lisp nei primi anni 70, sono ora, a malapena, sugli schermi dei radar. Le macro, introdotte nel Lisp a metà degli anni 60, sono ancora terreno inesplorato.

Ovviamente il linguaggio medio ha un enorme slancio. Non sto proponendo di combattere questa forza potente. Ciò che sto proponendo è esattamente l’opposto: come un praticante dell’Akido, puoi usarla contro i tuoi avversari.

Se lavori per una grossa azienda questo potrebbe non essere facile. Avrai vita dura nel convincere il boss dai capelli a punta (n.d.t. vedi i fumetti di Dilbert) a lasciarti creare cose con il Lisp, mentre questi ha appena letto su un giornale che c’è qualche altro linguaggio pronto, come lo era Ada venti anni fa, a conquistare il mondo. Ma se lavori per una startup che non ha un boss dai capelli a punta puoi, come abbiamo fatto noi, sfruttare il paradosso di Blub a tuo vantaggio: puoi usare la tecnologia che i tuoi concorrenti, incollati irremovibilmente al linguaggio medio, non saranno mai in grado di emulare.

Se mai ti trovassi a lavorare in una startup, ecco un consiglio pratico per valutare i concorrenti. Leggi le loro proposte di lavoro. Qualsiasi cosa abbiano sul loro sito potrebbe essere copiata da qualche parte ma negli annunci di lavoro devono necessariamente essere specifici circa quello che vogliono, o si ritroveranno coi candidati sbagliati.

Durante gli anni che ho lavorato su Viaweb ho letto un sacco di annunci di lavoro. Un nuovo concorrente sembrava emergere dal nulla ogni mese o giù di lì. La prima cosa che facevo, dopo controllare se avessero una demo online, era controllare i loro annunci di lavoro. Dopo aver fatto questo per diversi anni sono stato in grado di discernere le compagnie di cui preoccuparmi da quelle di cui non dovevo avere timore. Più un annuncio di lavoro aveva un aspetto IT, meno pericolosa era la compagnia. Le più innocue erano quelle che volevano esperienza su Oracle. Non dovevi mai preoccuparti di quelle. Inoltre eri al sicuro nel caso in cui cercavano sviluppatori C++ o Java. Se avessero cercato programmatori Perl o Python, sarebbe stato un po’ spaventoso: avrebbero dato l’impressione di essere una compagnia dove il comparto tecnico, almeno, era guidato da veri hacker. Se poi avessi mai visto un annuncio di lavoro per la ricerca di hacker Lisp, mi sarei veramente preoccupato.

Note

Nel gennaio 2003, Yahoo ha rilasciato una nuova versione dell’editor scritta in C++ e Perl. È dura dire se il programma sia ancora scritto in Lisp o meno, però, perché per tradurre il programma in C++ hanno dovuto letteralmente riscrivere un interprete Lisp: i file sorgenti dei template per la generazione delle pagine sono, per quanto ne so, ancora codice Lisp (vedi la regola di Greenspun).


  1. Viaweb era composto di due parti: l’editor, scritto in Lisp, che permettava agli utenti di creare il loro sito, e il sistema di ordinazione, scritto in C, che gestiva gli ordini. La prima versione era principalmente scritta in Lisp poiché il sistema di ordinazione era piccolo. Più in avanti abbiamo aggiunto due moduli, un generatore di immagini scritto in C e una gestione del back-office scritta per lo più in Perl. ↩︎

  2. Robert Morris dice che non avevo bisogno di mantenere la segretezza perché anche qualora i nostri concorrenti avessero saputo che stavamo usando il Lisp non avrebbero capito perché lo facevamo: “Se fossero stati così intelligenti avrebbero già scritto i loro programmi in Lisp”. ↩︎

  3. Tutti i linguaggi sono egualmente potenti nel senso di essere Turing equivalenti, però non è questo il senso della definizione che importa ai programmatori (nessuno vorrebbe programmare una macchina di Turing). Il tipo di potere che importa ai programmatori potrebbe non essere definibile formalmente, ma un modo di spiegarlo potrebbe essere quello di riferirsi alle caratteristiche ottenibili nei linguaggi meno potenti soltanto riscrivendo un interprete per il linguaggio più potente. Se il linguaggio A possiede un operatore per rimuovere gli spazi dalle stringhe e il linguaggio B non ce l’ha, probabilmente questo non rende A più potente di B perché puoi sempre scrivere una funzione in B che faccia la stessa cosa. Ma se A supporta, diciamo, la ricorsione, e B non lo fa, non è qualcosa che puoi correggere semplicemente scrivendo una funzione. ↩︎

  4. Nota per i nerd: o possibilmente un reticolo, che si stringe verso l’alto; non è la forma che conta ma l’idea che ci sia almeno un ordinamento parziale. ↩︎

  5. È un po’ fuorviante trattare le macro come una caratteristica separata. In pratica la loro utilità è enormemente potenziata da altre caratteristiche del Lisp come le chiusure lessicali e la possibilità di avere funzioni con un numero indefinito di parametri. ↩︎

  6. Come risultato, una comparazione dei linguaggi di programmazione può aver luogo o come guerra di religione o come libri per studenti delle superiori così determinatamente neutrali da essere in realtà lavori di antropologia. Chiunque tenga alla propria pace, o voglia mantenere il proprio impiego, stia lontana dall’argomento. Ma la domanda è soltanto religiosa per metà; c’è anche qualcosa che è degno di essere studiato, specialmente se vuoi progettare nuovi linguaggi. ↩︎

Get in touch

Thank you for contacting me, I will be in touch with you as soon as possible.
There was an error while trying to send the comment, please try again later.