Traduzione in italiano di Claudio Boni dall’essay originale di Paul Graham "Coronavirus and Credibility" [Aprile 2020].

Ho recentemente visto un video in cui giornalisti TV e politici affermavano con sicurezza che il coronavirus sarebbe stato come un'influenza. Ciò che mi allibisce non è solo quanto in errore siano stati, ma la sicurezza con cui facevano tali affermazioni. Come potevano esser così sicuri dicendo quelle cose?

La risposta, ho capito successivamente, è che pensavano di non essere beccati. Non capivano che ci fosse del pericolo nel fare tali false previsioni. Queste persone fanno continuamente false previsioni e la fanno franca, perché gli argomenti su cui le fanno sono così fumosi che possono togliersi dai guai facilmente, oppure accadono così lontano nel futuro che pochi davvero se ne ricordano.

Un’epidemia è differente. Smaschera rapidamente e inequivocabilmente le tue previsioni.

Ma le epidemie sono così rare che queste persone non avevano ben realizzato che potesse anche essere una eventualità. Invece hanno continuato con il loro modus operandi ordinario, che, come l'epidemia ha reso ben chiaro, è parlare con sicurezza di cose che non si conoscono.

Un evento così è quindi una maniera potentissima per prendere le misure alle persone. Come ha detto Warren Buffett, "È solo quando la marea si ritira che capisci chi stava nuotando nudo." E la marea si è ritirata come mai prima nella storia.

Ora che abbiamo visto i risultati, ricordiamoci di cosa abbiamo visto, perché questo è il miglior test sulla credibilità che potremmo mai avere. Spero.

Traduzione in italiano di Daniele Monti dall’essay originale di Paul Graham "Black Swan Farming" [Settembre 2012].

Nel corso degli anni ho svolto diversi tipi di lavori, ma nessuno è controintuitivo come l'investire in startup.

Le due cose più importanti dell'investimento in startup come attività professionale, sono (1) che effettivamente tutti i rendimenti sono concentrati su pochi grandi vincitori e (2) che le idee migliori inizialmente sembrano cattive.

Avevo una conoscenza solo intellettuale della prima regola, ma non l'ho capita a fondo fino a quando non ci è capitata: il valore totale delle aziende che abbiamo finanziato è di circa 10 miliardi, i tre quarti però sono rappresentati da due sole di loro: Dropbox e Airbnb.

Nelle startup, i grandi vincitori lo sono in una misura tale che sfida le nostre aspettative sulla variabilità. Non so se queste aspettative siano innate o apprese ma - qualunque ne sia l’origine - non siamo preparati ad una variabilità di 1000 volte come quella che si riscontra negli investimenti in startup.

Questo produce strane conseguenze, ad esempio, in termini puramente finanziari, in ogni batch di YC c'è probabilmente al massimo una società che avrà un effetto significativo sui nostri rendimenti mentre le altre sono solo un costo di gestione. Non ho ancora assimilato questo fatto, in parte perché è così controintuitivo e in parte perché non lo facciamo solo per motivi finanziari. YC sarebbe un posto piuttosto solitario se dovessimo avere una sola azienda per batch, eppure la realtà è questa.

Per avere successo in un settore che va contro le vostre intuizioni, dovete essere in grado di spegnerle come fa un pilota quando vola tra le nuvole. Bisogna fare ciò che intellettualmente si sa essere giusto, anche se sembra sbagliato.

Per noi è una battaglia continua, è difficile costringersi a rischiare abbastanza. Quando si fa un colloquio con una startup e si pensa "è probabile che possa avere successo", è difficile non finanziarla, eppure, almeno dal punto di vista finanziario, c'è un solo tipo di successo: o diventerà uno dei grandi vincitori oppure no, e in questo caso non importa se la finanziate, perché anche se avrà un discreto successo l'effetto sui vostri rendimenti sarà insignificante. In una giornata di colloqui potreste incontrare alcuni diciannovenni intelligenti che non sono nemmeno sicuri su cosa vogliano lavorare. Le loro possibilità di successo sembrano minime, ma ancora una volta, non è importante la probabilità che abbiano un discreto successo ma quella che abbiano un successo veramente grande. La probabilità che un certo team abbia questo successo veramente grande è infinitamente piccola, ma la probabilità che questi diciannovenni abbiano successo potrebbe essere più alta di quella dell'altro gruppo, più sicuro.

La probabilità che una startup abbia un grande successo non è semplicemente una percentuale fissa della probabilità che abbia successo. Se così fosse, si potrebbero finanziare tutte le startup che sembrano poter avere successo e si otterrebbe quella percentuale di grandi successi. Sfortunatamente, scegliere i vincitori è più difficile di così. Bisogna ignorare l'elefante che ci sta di fronte, la probabilità che abbiano qualche successo, e concentrarsi invece sulla questione separata e quasi invisibilmente intangibile se avranno un successo realmente grande.

Più difficile

Questo è reso più difficile dal fatto che le migliori idee di startup inizialmente sembrano delle idee cattive. Ne ho già scritto in passato: se una buona idea fosse palesemente buona, qualcun altro l'avrebbe già realizzata. I fondatori di maggiore successo tendono quindi a lavorare su delle idee che pochi, a parte loro, sanno essere buone. Il che non è poi così lontano dalla descrizione della follia, finché non si arriva al punto in cui si vedono i risultati.

La prima volta che Peter Thiel ha parlato a YC ha disegnato un diagramma di Venn che illustra perfettamente questa situazione. Ha disegnato due cerchi che si intersecano, uno etichettato "sembra una cattiva idea" e l'altro "è una buona idea". L'intersezione è il punto di forza delle startup.

Questo concetto è semplice, eppure vederlo come un diagramma di Venn è illuminante. Ricorda che esiste un'intersezione, che ci sono buone idee che sembrano cattive. Ricorda anche che la stragrande maggioranza delle idee che sembrano cattive in effetti lo sono.

Il fatto che le idee migliori sembrino cattive rende ancora più difficile riconoscere i grandi vincitori. Significa che la probabilità che una startup diventi davvero grande non solo non è una percentuale fissa della probabilità che abbia successo, ma che le startup con un'alta probabilità della prima sembreranno avere una probabilità sproporzionatamente bassa della seconda.

La storia tende a essere riscritta dai grandi successi, tanto che a posteriori sembra ovvio che siano diventati grandi. Per questo motivo, uno dei miei ricordi più preziosi è di quanto mi sembrasse insulso Facebook quando ne ho sentito parlare per la prima volta. Un sito per studenti universitari dove buttare via il tempo? Sembrava la perfetta cattiva idea: un sito (1) per un mercato di nicchia (2) di clienti senza soldi (3) per fare una cosa di poca importanza.

Si sarebbero potute descrivere Microsoft e Apple esattamente negli stessi termini.

Ancora più difficile

Aspettate, c'è di peggio. Non solo dovete risolvere questo problema difficile, ma dovete farlo senza alcuna indicazione che ci stiate riuscendo. Quando sceglierete un grande vincitore, non lo saprete prima di due anni.

Nel frattempo, l'unica cosa che si può misurare è pericolosamente fuorviante. L'unica cosa che possiamo tracciare con precisione è il risultato ottenuto dalle startup di ogni batch nella raccolta di fondi dopo il Demo Day. Sappiamo che è una misura sbagliata. Non c'è alcuna correlazione tra la percentuale di startup che raccolgono fondi e la metrica che conta dal punto di vista finanziario, ovvero se quel gruppo di startup contiene un grande vincitore o meno.

Anzi c’è una correlazione inversa. Questo è l'aspetto spaventoso: la raccolta di fondi non è semplicemente una metrica inutile, ma è proprio fuorviante. Siamo in un settore in cui dobbiamo scegliere delle eccezioni poco promettenti, e l'enorme dimensione dei successi significa che possiamo permetterci di gettare la rete in modo molto ampio. I grandi vincitori potrebbero generare ritorni di 10.000 volte l’investimento. Ciò significa che per ogni grande vincitore potremmo scegliere mille società che non ci rendono niente e avere ancora un guadagno di dieci volte l’investimento. 

Se arrivassimo al punto in cui il 100% delle startup che abbiamo finanziato fosse in grado di raccogliere fondi dopo il Demo Day, significherebbe quasi certamente che siamo stati troppo prudenti.

È necessario uno sforzo consapevole per non farlo. Dopo 15 cicli di preparazione delle startup per gli investitori e di analisi dei loro risultati, ora vedo ogni gruppo che stiamo intervistando con gli occhi degli investitori del Demo Day. Ma sono gli occhi sbagliati!

Noi possiamo permetterci di correre un rischio almeno 10 volte superiore a quello degli investitori del Demo Day. E poiché il rischio è solitamente proporzionale alla ricompensa, se potete permettervi di rischiare di più dovreste farlo. Che cosa significa assumersi un rischio 10 volte superiore a quello degli investitori del Demo Day? Dovremmo essere disposti a finanziare un numero di startup 10 volte superiore al loro. Ciò significa che, se siamo generosi con noi stessi e ipotizziamo che YC possa in media triplicare il valore atteso di una startup, staremmo assumendo la giusta quantità di rischio se anche solo il 30% delle startup fosse in grado di raccogliere finanziamenti significativi dopo il Demo Day.

Non so quale frazione di esse riesca attualmente a raccogliere di più dopo il Demo Day. Evito deliberatamente di calcolare questo numero, perché se si inizia a misurare qualcosa si inizia a ottimizzarla, e so che è la cosa sbagliata da ottimizzare, ma la percentuale è certamente superiore al 30%. Francamente il pensiero di un tasso di successo del 30% nella raccolta di fondi mi fa stringere lo stomaco: un Demo Day in cui solo il 30% delle startup fosse finanziabile sarebbe un disastro, tutti sarebbero d'accordo nel dire che YC ha fatto un salto nel buio, noi stessi penseremmo che YC ha perso il suo smalto. Eppure ci sbaglieremmo tutti.

Nel bene e nel male, questo non sarà mai più di un esperimento intellettuale. Non riusciremmo a sopportarlo. Non sembra anche a voi un controsenso? Posso descrivere ciò che so essere la cosa giusta da fare, eppure non la faccio. Posso inventare ogni sorta di giustificazione plausibile: se investissimo in un gran numero di startup rischiose che poi falliscono, il brand YC ne risentirebbe (almeno tra i non addetti ai lavori), potrebbe diluire il valore della rete degli alumni, forse la cosa più convincente è che per noi sarebbe demoralizzante essere sempre sommersi dai fallimenti. Ma so che il vero motivo per cui siamo così conservatori è che non abbiamo ancora assimilato il fatto che i rendimenti si moltiplicano di 1000 volte.

Probabilmente non saremo mai in grado di assumerci rischi proporzionali ai rendimenti di questo settore. Il meglio che possiamo sperare è che quando intervistiamo un gruppo e ci troviamo a pensare "sembrano bravi fondatori, ma cosa penseranno gli investitori di questa idea folle?", continueremo a dire "chi se ne frega di cosa pensano gli investitori?". È quello che pensavamo di Airbnb, e se vogliamo finanziare altri Airbnb dobbiamo essere bravi a pensarlo.

Grazie a Sam Altman, Paul Buchheit, Patrick Collison, Jessica Livingston, Geoff Ralston e Harj Taggar per aver letto le bozze di questo articolo.

Note

Traduzione in italiano di Lucia Anastasi dall’essay originale di Paul Graham "Beyond Smart" [Ottobre 2021].

Se si chiedesse alle persone cosa c'è di speciale in Einstein, la maggior parte direbbe che era molto intelligente. Anche chi cercasse di dare una risposta più sofisticata, probabilmente lo penserebbe per primo. Fino a qualche anno fa avrei dato anch'io la stessa risposta. Ma non era questo l'aspetto speciale di Einstein. Ciò che era speciale in lui era che aveva idee nuove e importanti. Essere molto intelligenti era una condizione necessaria per avere quelle idee, ma le due cose non sono identiche.

Può sembrare una distinzione banale sottolineare che l'intelligenza e le sue conseguenze non sono identiche, ma non è così. C'è un grande divario tra le due cose. Chiunque abbia frequentato università e laboratori di ricerca sa quanto sia grande. Ci sono molte persone veramente intelligenti che non ottengono grandi risultati.

Sono cresciuto pensando che l'intelligenza fosse la cosa più desiderabile. Forse lo avete pensato anche voi. Ma scommetto che non è quello che volete davvero. Immaginate di poter scegliere tra essere molto intelligenti ma non scoprire nulla di nuovo ed essere meno intelligenti ma scoprire molte nuove idee. Sicuramente scegliereste la seconda. Io lo farei. La scelta mi mette a disagio, ma quando si vedono le due opzioni esposte esplicitamente in questo modo, è ovvio quale sia la migliore.

Il motivo per cui la scelta mi mette a disagio è che l'essere intelligente mi sembra ancora la cosa che conta, anche se so intellettualmente che non è così. Ho passato tanti anni a pensare che lo fosse. Le circostanze dell'infanzia sono una tempesta perfetta per alimentare questa illusione. L'intelligenza è molto più facile da misurare rispetto al valore delle nuove idee, e si viene costantemente giudicati in base ad essa. Mentre anche i bambini che alla fine scopriranno cose nuove di solito non le stanno ancora scoprendo. Per i ragazzi con questa inclinazione, l'intelligenza è l'unico gioco in città.

Ci sono anche ragioni più sottili, che persistono fino all'età adulta. L'intelligenza vince nelle conversazioni e diventa così la base della gerarchia di comando. Inoltre, avere nuove idee è una cosa così nuova storicamente, e ancora oggi è fatta da così poche persone, che la società non ha ancora assimilato il fatto che è questa la vera meta, e l'intelligenza solo un mezzo per raggiungere un fine.

Perché così tante persone intelligenti non riescono a scoprire nulla di nuovo? Vista da questa prospettiva, la domanda sembra piuttosto deprimente. Ma c'è un altro modo di vedere la questione che non è solo più ottimista, ma anche più interessante. È chiaro che l'intelligenza non è l'unico ingrediente per avere nuove idee. Quali sono gli altri ingredienti? Sono cose che possiamo coltivare?

Perché il problema dell'intelligenza, si dice, è che è per lo più innata. Le prove a sostegno di questa tesi sembrano abbastanza convincenti, soprattutto se si considera che la maggior parte di noi non vuole che sia vero, e le prove devono quindi affrontare un forte vento contrario. Ma non intendo entrare nel merito di questa questione, perché sono gli altri ingredienti delle nuove idee che mi interessano, ed è chiaro che molti di essi possono essere coltivati.

Ciò significa che la verità è molto diversa dalla storia che mi è stata raccontata da bambino. Se l'intelligenza è ciò che conta, ed è per lo più innata, la conseguenza naturale è una sorta di fatalismo alla Brave New World. La cosa migliore che si può fare è capire per quale tipo di lavoro si ha una "attitudine", in modo che l'intelligenza con cui si è nati venga almeno sfruttata al meglio, e poi lavorare il più possibile. Se invece l'intelligenza non è ciò che conta, ma solo uno dei vari ingredienti di ciò che conta, e molti di questi non sono innati, le cose si fanno più interessanti. Si ha molto più controllo, ma il problema di come organizzare la propria vita diventa molto più complicato.

Quali sono dunque gli altri ingredienti per avere nuove idee? Il fatto che io possa anche solo porre questa domanda dimostra il punto che ho sollevato prima: la società non ha assimilato il fatto che è questo che conta, e non l'intelligenza. Altrimenti tutti sapremmo rispondere a una domanda così fondamentale.

Non cercherò di fornire qui un catalogo completo degli altri ingredienti. È la prima volta che mi pongo la domanda in questo modo e credo che ci vorrà un po' di tempo per rispondere. Ma di recente ho scritto di uno dei più importanti: l'interesse ossessivo per un particolare argomento. E questo può essere sicuramente coltivato.

Un'altra qualità necessaria per scoprire nuove idee è l'indipendenza mentale. Non voglio affermare che questa sia distinta dall'intelligenza - sarei riluttante a definire intelligente una persona che non ha una mentalità indipendente - ma, sebbene sia in gran parte innata, questa qualità sembra essere qualcosa che in una certa misura può essere coltivata.

Esistono tecniche generali per avere nuove idee - per esempio, per lavorare sui propri progetti e per superare gli ostacoli che si incontrano con i primi lavori - e tutte queste possono essere apprese. Alcune possono essere apprese dalla società. Esistono anche raccolte di tecniche per generare tipi specifici di nuove idee, come le idee per startup e gli argomenti degli essay.

E naturalmente ci sono molti ingredienti abbastanza banali per scoprire nuove idee, come lavorare sodo, dormire a sufficienza, evitare certi tipi di stress, avere i colleghi giusti e trovare dei trucchi per lavorare su ciò che si vuole anche quando non è quello su cui si dovrebbe lavorare. Tutto ciò che impedisce alle persone di fare un ottimo lavoro ha un rovescio che le aiuta a farlo. E questa serie di ingredienti non è così noiosa come potrebbe sembrare all'inizio. Per esempio, avere nuove idee è generalmente associato alla giovinezza. Ma forse non è la giovinezza in sé a produrre nuove idee, bensì le caratteristiche specifiche della giovinezza, come la buona salute e la mancanza di responsabilità. L'analisi di questo aspetto potrebbe portare a strategie che aiutino le persone di qualsiasi età ad avere idee migliori.

Uno degli ingredienti più sorprendenti per avere nuove idee è la capacità di scrivere. C'è una categoria di nuove idee che si scoprono meglio scrivendo saggi e libri. E quel "scrivendo" è intenzionale: non si pensa prima alle idee e poi ci si limita a scriverle. C'è un tipo di pensieri che si fanno scrivendo, e se si è maldestri nello scrivere, o non ci si diverte a farlo, ciò sarà d'intralcio se si cerca di fare questo tipo di pensieri.

Prevedo che il divario tra intelligenza e nuove idee si rivelerà un terreno interessante. Se pensiamo a questo divario solo come a una misura del potenziale non realizzato, diventa una sorta di terra desolata che cerchiamo di attraversare frettolosamente con gli occhi sbarrati. Ma se capovolgiamo la questione e iniziamo a indagare sugli altri ingredienti delle nuove idee che la questione stessa implica debbano esistere, possiamo sfruttare questo divario per fare scoperte sulla scoperta.

Grazie a Trevor Blackwell, Patrick Collison, Jessica Livingston, Robert Morris, Michael Nielsen e Lisa Randall per aver letto le bozze di questo testo.

Note

Traduzione in italiano di Alessandro Collesano dall’essay originale di Paul Graham "The Real Reason to End the Death Penalty" [Aprile 2021]. La lettura dell'articolo è di Nataša Mandić.

Quando gli intellettuali parlano della pena di morte, si chiedono se sia ammissibile che lo Stato tolga la vita a qualcuno, se la pena di morte agisca come deterrente e se le condanne a morte vengano comminate ad alcuni gruppi piuttosto che ad altri. Ma in pratica il dibattito sulla pena di morte non riguarda se sia giusto uccidere degli assassini. Si tratta di stabilire se sia giusto uccidere delle persone innocenti, perché almeno il 4% delle persone nel braccio della morte sono innocenti.

Quando ero bambino, immaginavo che fosse insolito per le persone essere condannate per crimini che non avevano commesso, e che soprattutto nei casi di omicidio questo dovesse essere molto raro. Non è così. Oggi, grazie a organizzazioni come Innocence Project, assistiamo a un flusso costante di storie di condanne per omicidio annullate in seguito all'emergere di nuove prove. A volte la polizia e i pubblici ministeri sono stati semplicemente molto negligenti. A volte erano disonesti e sapevano benissimo che stavano condannando un innocente.

Kenneth Adams e altri tre uomini hanno trascorso 18 anni in prigione per una condanna per omicidio. Sono stati scagionati dopo che il test del DNA ha coinvolto tre uomini diversi, due dei quali hanno poi confessato. La polizia era stata informata degli altri uomini all'inizio dell'indagine, ma non aveva mai seguito quella pista.

Keith Harward ha trascorso 33 anni in prigione per una condanna per omicidio. Fu condannato perché degli "esperti" dissero che i suoi denti corrispondevano alle foto dei segni dei morsi su una vittima. È stato scagionato dopo che il test del DNA ha dimostrato che l'omicidio era stato commesso da un altro uomo, Jerry Crotty.

Ricky Jackson e altri due uomini hanno trascorso 39 anni in prigione dopo essere stati condannati per omicidio sulla base della testimonianza di un bambino di 12 anni, che in seguito ha ritrattato e ha detto di essere stato costretto dalla polizia. Diverse persone hanno confermato che il ragazzo era altrove all'epoca. I tre uomini sono stati scagionati dopo che il procuratore della contea ha ritirato le accuse, dicendo: "Lo Stato sta ammettendo l'ovvio".

Alfred Brown ha trascorso 12 anni in prigione per una condanna per omicidio, di cui 10 nel braccio della morte. È stato scagionato dopo che si è scoperto che un assistente procuratore distrettuale aveva nascosto i tabulati telefonici che dimostravano che non poteva aver commesso i crimini.

Glenn Ford ha trascorso 29 anni nel braccio della morte dopo essere stato condannato per omicidio. È stato scagionato dopo che nuove prove hanno dimostrato che non era nemmeno sulla scena del crimine quando avvenne il delitto. Gli avvocati d’ufficio incaricati di rappresentarlo non avevano mai difeso qualcuno davanti ad una giuria.

Cameron Willingham è stato giustiziato nel 2004 con un'iniezione letale. L'"esperto" che ha testimoniato che aveva deliberatamente appiccato il fuoco alla sua casa è stato nel frattempo screditato. Un riesame del caso ordinato dallo Stato del Texas nel 2009 ha concluso che "l’ipotesi di incendio doloso non poteva essere sostenuta".

Rich Glossip ha trascorso 20 anni nel braccio della morte dopo essere stato condannato per omicidio sulla base della testimonianza del vero assassino, che ha evitato l'ergastolo in cambio della sua chiamata in correità. Nel 2015 è arrivato a pochi minuti dall'esecuzione prima che emergesse che lo Stato dell’Oklahoma aveva pianificato di ucciderlo con una combinazione illegale di farmaci. L'Oklahoma ha ancora intenzione di procedere all'esecuzione, forse già quest'estate, nonostante le nuove prove che lo scagionano.

Potrei continuare. Ci sono centinaia di casi simili. Solo in Florida, finora sono stati scagionati 29 condannati a morte.

Lungi dall'essere rare, le condanne per omicidio erronee sono molto comuni. La polizia è sotto pressione per risolvere un crimine che ha attirato molta attenzione. Quando trovano un sospetto, vogliono credere che sia colpevole e ignorano o addirittura distruggono le prove che suggeriscono il contrario. I procuratori distrettuali vogliono essere visti come efficaci e duri contro il crimine e, per ottenere condanne, sono disposti a manipolare i testimoni e a nascondere le prove. Gli avvocati difensori nominati dal tribunale sono oberati di lavoro e spesso incompetenti. C'è un'ampia disponibilità di criminali disposti a testimoniare il falso in cambio di una pena più lieve, di testimoni suggestionabili che possono essere indotti a dire tutto ciò che la polizia vuole e di "esperti" fasulli desiderosi di affermare che la scienza dimostra la colpevolezza dell'imputato. E le giurie vogliono credere a loro, perché altrimenti qualche terribile crimine rimarrebbe irrisolto.

Questo circo di incompetenza e disonestà è il vero problema della pena di morte. Non arriviamo nemmeno al punto in cui le questioni teoriche sulla giustificazione morale o sull'efficacia della pena capitale cominciano ad avere importanza, perché molte delle persone condannate a morte sono in realtà innocenti. Qualunque cosa significhi in teoria, in pratica la pena capitale significa uccidere persone innocenti.

Si ringraziano Trevor Blackwell, Jessica Livingston e Don Knight per aver letto le bozze di questo articolo.

Contenuti correlati:

Will Florida Kill an Innocent Man?

Was Kevin Cooper Framed for Murder?

Did Texas execute an innocent man?

Traduzione in italiano di Tommaso Demarie dall’essay originale di Paul Graham "Organic Startup Ideas" [Aprile 2010].

Il modo migliore per concepire idee per una startup è porsi la domanda: cosa vorresti che qualcuno facesse per te?

Esistono due tipi di idee per le startup: quelle che nascono spontaneamente dalla vostra esperienza personale e quelle che decidete, da lontano, che saranno necessarie per una classe di utenti diversa da voi. Apple era il primo tipo. Apple è nata perché Steve Wozniak voleva un computer. A differenza della maggior parte delle persone che volevano un computer, lui era in grado di progettarne uno e lo fece. E poiché molte altre persone volevano la stessa cosa, Apple riuscì a venderne un numero sufficiente per avviare l'azienda. Tra l'altro, l'azienda si basa ancora oggi su questo principio. L'iPhone è il telefono che Steve Jobs vuole.

La nostra startup, Viaweb, era del secondo tipo. Realizzavamo software per la creazione di negozi online. Non avevamo bisogno di questo software. Non eravamo venditori diretti. Quando abbiamo iniziato non sapevamo nemmeno che i nostri utenti si chiamassero "direct marketer". Ma eravamo relativamente vecchi quando abbiamo avviato l'azienda (io avevo 30 anni e Robert Morris 29), quindi avevamo imparato abbastanza da sapere che gli utenti avrebbero avuto bisogno di questo tipo di software.

Non esiste una linea di demarcazione netta tra i due tipi di idee, ma le startup di maggior successo sembrano essere più vicine al tipo Apple che al tipo Viaweb. Quando scriveva il primo programma di interpretazione Basic per l'Altair, Bill Gates stava scrivendo qualcosa che avrebbe usato, così come Larry e Sergey quando hanno scritto le prime versioni di Google.

Le idee spontanee sono generalmente preferibili a quelle inventate, ma soprattutto quando i fondatori sono giovani. Ci vuole esperienza per prevedere cosa vorranno gli altri. Le idee peggiori che vediamo a Y Combinator sono quelle di giovani fondatori che creano cose che presumono che altri vorranno.

Quindi, se volete avviare una startup e non sapete ancora cosa fare, vi incoraggio a concentrarvi inizialmente su idee spontanee. Cosa manca o è rotto nella vostra vita quotidiana? A volte basta porre questa domanda per ottenere risposte immediate. A Bill Gates dev'essere sembrato palesemente sbagliato che si potesse programmare l'Altair solo in linguaggio macchina.

Potrebbe essere necessario uscire un po' da se stessi per vedere cosa manca, perché si tende ad abituarsi e a darlo per scontato. Tuttavia, si può essere certi che una frattura ci sia. Ci sono sempre grandi idee sotto il nostro naso. Nel 2004 era ridicolo che i laureandi di Harvard usassero ancora un Facebook stampato su carta. Sicuramente questo genere di cose avrebbe dovuto essere online.

Ci sono idee così ovvie in giro. Il motivo per cui le state trascurando è lo stesso per cui avreste trascurato l'idea di costruire Facebook nel 2004: le idee di startup spontanee di solito non sembrano buone idee all'inizio. Sono troppo scontate! Oggi sappiamo che Facebook ha avuto un grande successo, ma torniamo al 2004. Mettere online i profili dei laureandi non sarebbe sembrata un'idea da startup. E in effetti, all'inizio non era un'idea da startup. Quando Mark ha parlato a una cena di YC quest'inverno, ha detto che non stava cercando di fondare un'azienda quando ha scritto la prima versione di Facebook. Era solo un progetto. Così come l'Apple I quando Woz ha iniziato a lavorarci. Non pensava di fondare un'azienda. Se questi ragazzi avessero pensato di avviare un'azienda, avrebbero potuto essere tentati di fare qualcosa di più "serio", e sarebbe stato un errore.

Quindi, se volete proporre idee per startup spontanee, vi incoraggio a concentrarvi di più sull'idea e meno sulla parte di startup. Risolvete le cose che sembrano rotte, indipendentemente dal fatto che il problema sia abbastanza importante da costruire un'azienda. Se continuate a seguire questi filoni, sarà difficile non finire per creare qualcosa di valore per molte persone, e quando lo farete, sorpresa! Avrete un'azienda.

Non scoraggiatevi se ciò che producete inizialmente è qualcosa che gli altri considerano un giocattolo. Anzi, è un buon segno. Probabilmente è per questo che tutti gli altri hanno trascurato l'idea. I primi microcomputer sono stati liquidati come giocattoli. E i primi aerei e le prime automobili. A questo punto, quando qualcuno si presenta con qualcosa che piace agli utenti ma che noi possiamo immaginare che i troll dei forum online liquidino come un giocattolo, siamo particolarmente propensi a investire.

Se da un lato i giovani fondatori sono svantaggiati nel proporre idee ragionate, dall'altro sono la migliore fonte di idee spontanee, perché sono all'avanguardia della tecnologia. Utilizzano le ultime novità. Hanno appena deciso cosa usare, quindi perché non dovrebbero? E poiché usano le ultime novità, sono in grado di scoprire per primi i tipi di problemi risolvibili.

Non c'è niente di più prezioso di un bisogno non soddisfatto che sta diventando risolvibile. Se trovate qualcosa di rotto che potete risolvere per molte persone, avete trovato una miniera d'oro. Come nel caso di una vera e propria miniera d'oro, dovrete comunque lavorare sodo per ricavarne l'oro. Ma almeno sapete dove si trova il filone, e questa è la parte difficile.

Grazie a Sam Altman, Trevor Blackwell e Jessica Livingston per aver letto le bozze di questo articolo.

Note

Traduzione in italiano di Domenico Pastore dall’essay originale di Paul Graham "Succinctness is Power" [Maggio 2002].

"La quantità di significato compressa in un piccolo spazio dai segni algebrici è un'altra circostanza che facilita i ragionamenti che siamo abituati a portare avanti con il loro aiuto".

- Charles Babbage, citato nella conferenza del Premio Turing di Iverson. 

Nella discussione sui problemi sollevati da Revenge of the Nerds sulla mailing list LL1, Paul Prescod ha scritto qualcosa che mi è rimasto in mente.

    L'obiettivo di Python è la regolarità e la leggibilità, non la sinteticità. 

A prima vista, questa sembra un'affermazione piuttosto negativa per un linguaggio di programmazione. Per quanto ne so, sinteticità = potenza. Se così fosse, con le opportune sostituzioni, otterremmo

    L'obiettivo di Python è la regolarità e la leggibilità, non la potenza. 

E questo non sembra un compromesso (se di compromesso si tratta) che si voglia fare. Non è lontano dal dire che l'obiettivo di Python non è quello di essere efficace come linguaggio di programmazione.

Sinteticità = potenza? Questa mi sembra una domanda importante, forse la più importante per chiunque sia interessato alla progettazione di un linguaggio, e una domanda che sarebbe utile affrontare direttamente. Non sono ancora sicuro che la risposta sia un semplice sì, ma mi sembra una buona ipotesi da cui partire.

Ipotesi

La mia ipotesi è che la sinteticità sia la potenza, o che sia abbastanza vicina da poter essere considerata identica, tranne che in esempi patologici.

Mi sembra che la sinteticità sia lo scopo dei linguaggi di programmazione. I computer sarebbero altrettanto felici di sentirsi dire cosa fare direttamente in linguaggio macchina. Credo che il motivo principale per cui ci prendiamo la briga di sviluppare linguaggi di alto livello sia quello di ottenere un effetto leva, in modo da poter dire (e soprattutto pensare) in 10 righe di un linguaggio di alto livello ciò che richiederebbe 1000 righe di linguaggio macchina. In altre parole, lo scopo principale dei linguaggi di alto livello è quello di ridurre il codice sorgente.

Se la riduzione del codice sorgente è lo scopo dei linguaggi di alto livello, e la potenza è quanto bene raggiunge il suo scopo, allora la misura della potenza di un linguaggio di programmazione è quanto rende piccoli i vostri programmi.

Al contrario, un linguaggio che non rende piccoli i programmi fa un pessimo lavoro rispetto a ciò che i linguaggi di programmazione dovrebbero fare, come un coltello che non taglia bene o una stampa illeggibile.

Metriche

Piccolo in che senso? La misura più comune della dimensione del codice è rappresentata dalle linee di codice. Ma credo che questa metrica sia la più comune perché è la più facile da misurare. Non credo che nessuno creda davvero che sia il vero test della lunghezza di un programma. Linguaggi diversi hanno convenzioni diverse per quanto riguarda la quantità di codice da inserire in una riga; in C molte righe non contengono altro che uno o due delimitatori.

Un altro test facile è il numero di caratteri in un programma, ma anche questo non è molto buono; alcuni linguaggi (Perl, per esempio) usano identificatori più corti di altri.

Credo che una misura migliore della dimensione di un programma sia il numero di elementi, dove un elemento è qualsiasi cosa che costituirebbe un nodo distinto se si disegnasse un albero che rappresenta il codice sorgente. Il nome di una variabile o di una funzione è un elemento; un numero intero o in virgola mobile è un elemento; un segmento di testo letterale è un elemento; un elemento di uno schema o di una direttiva di formato è un elemento; un nuovo blocco è un elemento. Ci sono casi limite (-5 è un elemento o due?), ma credo che la maggior parte di essi sia uguale per tutte le lingue, quindi non influenzano molto i confronti.

Questa metrica deve essere perfezionata e potrebbe richiedere un'interpretazione nel caso di linguaggi specifici, ma credo che cerchi di misurare la cosa giusta, cioè il numero di parti di un programma. Penso che l'albero che si disegna in questo esercizio sia quello che si deve creare nella propria testa per concepire il programma, e quindi la sua dimensione è proporzionale alla quantità di lavoro che si deve fare per scriverlo o leggerlo.

Design

Questo tipo di metrica ci permetterebbe di confrontare linguaggi diversi, ma non è questo, almeno per me, il suo valore principale. Il valore principale del test di sinteticità è come guida nella progettazione delle lingue. Il confronto più utile tra le lingue è quello tra due potenziali varianti della stessa lingua. Cosa posso fare nel linguaggio per rendere i programmi più brevi?

Se il carico concettuale di un programma è proporzionale alla sua complessità, e un dato programmatore può tollerare un carico concettuale fisso, allora questo equivale a chiedersi: cosa posso fare per consentire ai programmatori di ottenere il massimo? E questo mi sembra identico alla domanda: come posso progettare un buon linguaggio?

(Per inciso, niente rende più evidente che la vecchia credenza "tutti i linguaggi sono equivalenti" è falsa quanto la progettazione di linguaggi. Quando si progetta un nuovo linguaggio, si confrontano costantemente due linguaggi - il linguaggio se facessi x e quello se non lo facessi - per decidere quale sia migliore. Se questa fosse davvero una domanda senza senso, tanto varrebbe lanciare una moneta).

Puntare alla sinteticità sembra un buon modo per trovare nuove idee. Se si riesce a fare qualcosa che accorcia molti programmi diversi, probabilmente non è una coincidenza: probabilmente si è scoperta una nuova astrazione utile. Potreste anche essere in grado di scrivere un programma che vi aiuti nella ricerca di schemi ripetuti nel codice sorgente. Tra gli altri linguaggi, quelli che hanno una reputazione di sinteticità sono quelli a cui guardare per trovare nuove idee: Forth, Joy, Icon.

Confronto

Il primo a scrivere su questi temi, per quanto ne so, è stato Fred Brooks nel Mese dell'Uomo Mitico. Egli scrisse che i programmatori sembravano generare più o meno la stessa quantità di codice al giorno, indipendentemente dal linguaggio. Quando lo lessi per la prima volta, all'inizio dei miei vent'anni, fu una grande sorpresa per me e mi sembrò che avesse enormi implicazioni. Significava (a) che l'unico modo per scrivere software più velocemente era usare un linguaggio più sintetico e (b) chi si prendeva la briga di farlo poteva lasciare nella polvere i concorrenti che non lo facevano.

L'ipotesi di Brooks, se fosse vera, sembra essere al centro dell'hacking. Negli anni successivi, ho prestato molta attenzione a tutte le prove che ho potuto ottenere sulla questione, da studi formali ad aneddoti su singoli progetti. Non ho visto nulla che lo contraddica.

Non ho ancora visto prove che mi sembrassero conclusive, e non mi aspetto di vederle. Studi come il confronto tra linguaggi di programmazione di Lutz Prechelt, pur generando il tipo di risultati che mi aspettavo, tendono a utilizzare problemi troppo brevi per essere test significativi. Un test migliore di un linguaggio è quello che accade nei programmi che richiedono un mese di tempo per essere scritti. E l'unico vero test, se si crede come me che lo scopo principale di un linguaggio sia quello di essere buono per pensare (piuttosto che per dire a un computer cosa fare una volta che lo si è pensato) è quali nuove cose si possono scrivere in esso. Quindi, qualsiasi confronto tra linguaggi in cui si debba soddisfare una specifica predefinita è un test leggermente sbagliato.

Il vero test di un linguaggio è la capacità di scoprire e risolvere nuovi problemi, non la capacità di usarlo per risolvere un problema già formulato da qualcun altro. Si tratta di due criteri molto diversi. Nell'arte, mezzi come il ricamo e il mosaico funzionano bene se si sa in anticipo cosa si vuole realizzare, ma sono assolutamente pessimi se non lo si sa. Quando si vuole scoprire l'immagine man mano che la si realizza - come si deve fare con qualsiasi cosa complessa come l'immagine di una persona, per esempio - è necessario usare un mezzo più fluido come la matita o la china o la pittura a olio. In effetti, il modo in cui si realizzano arazzi e mosaici è quello di creare prima un dipinto e poi di copiarlo. (La parola "cartone animato" era originariamente usata per descrivere un dipinto destinato a questo scopo).

Ciò significa che probabilmente non avremo mai confronti accurati sulla potenza relativa dei linguaggi di programmazione. Avremo confronti precisi, ma non accurati. In particolare, gli studi espliciti con lo scopo di confrontare i linguaggi, poiché probabilmente utilizzeranno problemi di piccole dimensioni e necessariamente predefiniti, tenderanno a sottostimare la potenza dei linguaggi più potenti.

I risultati sul campo, anche se necessariamente meno precisi degli studi "scientifici", sono probabilmente più significativi. Ad esempio, Ulf Wiger di Ericsson ha condotto uno studio che ha concluso che Erlang è da 4 a 10 volte più sintetico di C++ e proporzionalmente più veloce nello sviluppo di software:

    I confronti tra i progetti di sviluppo interni a Ericsson indicano una produttività simile in termini di linee/ore, comprese tutte le fasi di sviluppo del software, indipendentemente dal linguaggio utilizzato (Erlang, PLEX, C, C++ o Java). Ciò che differenzia i diversi linguaggi diventa quindi il volume del codice sorgente. 

Lo studio affronta anche esplicitamente un punto che nel libro di Brooks era solo implicito (dato che misurava le linee di codice debuggato): i programmi scritti in linguaggi più potenti tendono ad avere meno bug. Questo diventa un fine in sé, forse più importante della produttività dei programmatori, in applicazioni come gli switch di rete.

Il test del gusto

In definitiva, credo che si debba seguire il proprio istinto. Cosa si prova a programmare in quel linguaggio? Credo che il modo per trovare (o progettare) il miglior linguaggio sia quello di diventare ipersensibili al modo in cui un linguaggio vi permette di pensare, quindi scegliere/progettare il linguaggio che vi fa sentire meglio. Se qualche caratteristica del linguaggio è scomoda o limitante, non preoccupatevi, lo saprete.

Questa ipersensibilità avrà un costo. Scoprirete di non sopportare la programmazione in linguaggi goffi. Trovo estremamente restrittivo programmare in linguaggi senza macro, così come chi è abituato alla tipizzazione dinamica trova estremamente restrittivo dover tornare a programmare in un linguaggio in cui si deve dichiarare il tipo di ogni variabile e non si può fare un elenco di oggetti di tipo diverso.

Non sono l'unico. Conosco molti hacker Lisp a cui è successo. In effetti, la misura più accurata del potere relativo dei linguaggi di programmazione potrebbe essere la percentuale di persone che conoscono il linguaggio e che accetterebbero qualsiasi lavoro in cui si possa usare quel linguaggio, indipendentemente dal dominio applicativo.

Restrittività

Credo che la maggior parte degli hacker sappia cosa significhi che un linguaggio è restrittivo. Cosa succede quando lo sentite? Penso che sia la stessa sensazione che si prova quando la strada che si vuole percorrere è bloccata e si deve fare una lunga deviazione per arrivare dove si vuole andare. C'è qualcosa che vuoi dire, ma la lingua non te lo permette.

Credo che il vero problema sia che un linguaggio restrittivo non è abbastanza sintetico. Il problema non è semplicemente che non si può dire quello che si voleva dire. È che la deviazione che il linguaggio vi fa fare è più lunga. Provate a fare questo esperimento di pensiero. Supponiamo che si voglia scrivere un programma e che il linguaggio non permetta di esprimerlo nel modo previsto, ma costringa a scriverlo in un altro modo che sia più breve. Almeno per me, questo non sarebbe molto restrittivo. Sarebbe come se la strada che volevate percorrere fosse bloccata e il poliziotto all'incrocio vi indicasse una scorciatoia invece di una deviazione. Ottimo!

Credo che la maggior parte (il novanta per cento forse?) della sensazione di restrittività derivi dall'essere costretti a rendere il programma che si scrive nel linguaggio più lungo di quello che si ha in testa. La restrittività è soprattutto mancanza di sinteticità. Quindi, quando un linguaggio sembra restrittivo, ciò che (per lo più) significa è che non è abbastanza sintetico, e quando un linguaggio non è sintetico, si sentirà restrittivo.

Leggibilità

La citazione con cui ho iniziato cita altre due qualità, la regolarità e la leggibilità. Non sono sicuro di cosa sia la regolarità, né di quale vantaggio abbia, se ce n'è uno, un codice regolare e leggibile rispetto a un codice semplicemente leggibile. Ma credo di sapere cosa si intenda per leggibilità, e penso che sia anche legata alla sinteticità.

Dobbiamo fare attenzione a distinguere tra la leggibilità di una singola riga di codice e la leggibilità dell'intero programma. È la seconda che conta. Sono d'accordo che una riga di Basic è probabilmente più leggibile di una riga di Lisp. Ma un programma scritto in Basic avrà un numero maggiore di righe rispetto allo stesso programma scritto in Lisp (soprattutto quando si passa a Greenspunland). Lo sforzo totale di lettura del programma Basic sarà sicuramente maggiore.

    sforzo totale = sforzo per riga x numero di righe 

Non sono così sicuro che la leggibilità sia direttamente proporzionale alla sinteticità come lo sono della potenza, ma certamente la sinteticità è un fattore (in senso matematico; si veda l'equazione precedente) della leggibilità. Quindi potrebbe anche non avere senso dire che l'obiettivo di un linguaggio è la leggibilità, non la sinteticità; potrebbe essere come dire che l'obiettivo è la leggibilità, non la leggibilità.

Ciò che la leggibilità per riga significa, per l'utente che incontra il linguaggio per la prima volta, è che il codice sorgente avrà un aspetto non ostile. Quindi la leggibilità per riga potrebbe essere una buona decisione di marketing, anche se è una cattiva decisione di progettazione. È isomorfa alla tecnica di grande successo di far pagare a rate: invece di spaventare i clienti con un prezzo anticipato elevato, si comunica il basso pagamento mensile. I piani rateali, però, sono una perdita netta per l'acquirente, come probabilmente lo è la semplice leggibilità per riga per il programmatore. L'acquirente effettuerà molti pagamenti bassi, e il programmatore dovrà leggere molte di quelle righe leggibili singolarmente.

Questo compromesso è precedente ai linguaggi di programmazione. Se siete abituati a leggere romanzi e articoli di giornale, la prima esperienza di lettura di un documento di matematica può essere sconcertante. Potrebbe volerci mezz'ora per leggere una sola pagina. Eppure, sono abbastanza sicuro che il problema non sia la notazione, anche se può sembrare cosi'. Se si esprimessero le stesse idee in prosa (come dovevano fare i matematici prima di evolvere le notazioni sintetiche), non sarebbero più facili da leggere, perché il documento diventerebbe grande come un libro.

Fino a che punto?

Alcune persone hanno respinto l'idea che sinteticità = potenza. Credo che sarebbe più utile, invece di discutere semplicemente che sono o non sono la stessa cosa, chiedersi: fino a che punto la sinteticità = potenza? Perché è chiaro che la sinteticità è una parte importante dello scopo dei linguaggi di livello superiore. Se non è l'unica cosa a cui servono, allora a cos'altro servono e quanto sono importanti, relativamente, queste altre funzioni?

Non sto proponendo questo solo per rendere il dibattito più civile. Voglio davvero conoscere la risposta. Quando, se mai, un linguaggio è troppo sintetico per il suo fine?

L'ipotesi da cui sono partito è che, salvo esempi patologici, ritengo che la sinteticità possa essere considerata identica alla potenza. Intendevo dire che in qualsiasi linguaggio che si possa progettare, le due cose sarebbero identiche, ma che se qualcuno volesse progettare un linguaggio esplicitamente per smentire questa ipotesi, probabilmente potrebbe farlo. In realtà non ne sono nemmeno sicuro.

Linguaggi, non programmi

È bene chiarire che stiamo parlando della sinteticità dei linguaggi, non dei singoli programmi. È certamente possibile che i singoli programmi siano scritti in modo troppo denso.

Ne ho scritto in On Lisp. Una macro complessa potrebbe dover risparmiare molte volte la sua stessa lunghezza per essere giustificata. Se scrivere una macro complessa può far risparmiare dieci righe di codice ogni volta che la si usa, e la macro stessa è composta da dieci righe di codice, allora si ottiene un risparmio netto di righe se la si usa più di una volta. Ma potrebbe comunque essere una mossa sbagliata, perché le definizioni delle macro sono più difficili da leggere rispetto al codice ordinario. Si potrebbe dover usare la macro dieci o venti volte prima di ottenere un miglioramento netto della leggibilità.

Sono sicuro che ogni linguaggio ha dei compromessi di questo tipo (anche se sospetto che la posta in gioco diventi più alta man mano che il linguaggio diventa più potente). Ogni programmatore deve aver visto del codice che qualche persona intelligente ha reso marginalmente più breve utilizzando trucchi di programmazione discutibili.

Quindi non c'è alcuna discussione in merito, almeno non da parte mia. I singoli programmi possono certamente essere troppo sintetici per il loro bene. La domanda è: può un linguaggio esserlo? Può un linguaggio costringere i programmatori a scrivere codice breve (in elementi) a spese della leggibilità complessiva?

Uno dei motivi per cui è difficile immaginare un linguaggio troppo sintetico è che se ci fosse un modo eccessivamente compatto per formulare qualcosa, probabilmente ci sarebbe anche un modo più lungo. Per esempio, se ritenete che i programmi Lisp che utilizzano molte macro o funzioni di ordine superiore siano troppo densi, potreste, se preferite, scrivere codice isomorfo al Pascal. Se non si vuole esprimere il fattoriale in Arc come una chiamata a una funzione di ordine superiore 

(rec zero 1 * 1-)

è anche possibile scrivere una definizione ricorsiva:

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

Anche se non mi viene in mente nessun esempio, sono interessato alla questione se un linguaggio possa essere troppo sintetico. Ci sono linguaggi che costringono a scrivere codice in un modo che risulta incomprensibile? Se qualcuno ha degli esempi, sarei molto interessato a vederli.

(Ricordare: Quello che sto cercando sono programmi molto densi secondo la metrica degli "elementi" abbozzata sopra, non semplicemente programmi che sono brevi perché i delimitatori possono essere omessi e tutto ha un nome di un solo carattere).

Traduzione in italiano di Claudio Boni dall’essay originale di Paul Graham "Haters" [Gennaio 2020].

(Ho pensato originariamente questo scritto per i founder di startup , spesso sorpresi dall'attenzione che ottengono via via che le loro aziende crescono, ma in realtà si applica ugualmente a chiunque diventi famoso.)

Se diventi abbastanza famoso, avrai dei fan a cui piaci fin troppo.

Queste persone sono talvolta chiamate "fanboys", e anche se il termine non mi piace molto, qui comunque lo userò.

Abbiamo bisogno infatti di un termine che li definisca perché sono un fenomeno diverso rispetto a chi semplicemente apprezza il tuo lavoro.

Un fanboy è ossessivo e acritico. Il fatto che tu gli piaccia è parte della sua identità, e si creano un'immagine di te che è molto migliore della realtà.

Qualsiasi cosa tu faccia va bene, perché l'hai fatta tu.

Se fai qualcosa di sbagliato, trovano il modo di trasformarlo in giusto. Ed il loro amore per te non è di solito ne' privato ne' tranquillo. Vogliono che tutti sappiano quanto sei forte.

Potreste quindi pensare che si possa vivere serenamente senza questi tipi di persone. Sapendo che al mondo ci sono tutti i tipi di persone; se questa è la peggior conseguenza della fama, allora, non è poi così male.

Sfortunatamente però questa non è la peggiore conseguenza della fama. Come hai dei fanboys, hai anche degli haters, degli odiatori.

Un hater è ossessivo e acritico. Il fatto che tu non gli piaccia è parte della sua identità, e si crea un'immagine di te che è molto peggiore della realtà.

Qualsiasi cosa tu faccia è sbagliata, perché l'hai fatta tu.

Se fai qualcosa di giusto, trovano il modo di trasformarlo in sbagliato. Ed il loro odio per te non è di solito ne' privato ne' tranquillo. Vogliono che tutti sappiano quanto sei pessimo.

Se vi sembra di averlo già letto, vi risparmio la fatica. Il secondo ed il quinto paragrafo sono identici eccetto per "bene" cambiato con "male".

Ho passato anni ad interrogarmi sugli haters. Chi sono e da dove vengono? Finché un giorno ho realizzato. Gli haters sono solo fanboys al contrario.

Tenete conto che per hater non intendo un semplice troll. Non parlo quindi di persone che dicono brutte cose su di voi e se ne vanno. Parlo del più piccolo gruppo di persone per cui questo diventa un'ossessione e che lo fanno per un lungo periodo.

Come i fan, gli hater sembrano essere un effetto automatico della fama. Li avrà chiunque sia relativamente famoso. E ognuno di loro sarà galvanizzato dalla vostra fama.

Sentono la canzone di una cantante pop, ad esempio, e non gli piace granché. Se la cantante non è molto famosa, se ne scordano velocemente. Ma se invece continuano a sentirne il nome, allora questo li fa impazzire.

Tutti parlano di questa cantante ma fa schifo! È un’imbrogliona!

La parola imbrogliona, ciarlatana ("fraud") è molto importante. È la spettrale definizione di ogni hater per coloro che odiano. Non possono negarne la fama. Ma nella loro mente è davvero esagerata. Si accorgono di ogni citazione della cantante, perché ognuna di queste li fa arrabbiare ancora di più.

Nelle loro menti esagerano sia la fama della cantante che la sua carenza di talento, e l'unico modo per conciliare queste due contrastanti idee è concludere che ha ingannato tutti.

Ma che tipo di persona diventa un hater?

Chiunque può essere un hater?

Non sono molto sicuro ma ho notato degli schemi ricorrenti. Gli hater sono dei perdenti in un senso molto specifico: sebbene qualche volta abbiano del talento, non hanno mai combinato granché. E chiunque sia abbastanza famoso, sapendo quanto casuale sia la fama, sarà difficile che chiami impostore un'altra persona famosa.

Ma gli hater non sono completamente dei perdenti. Non sono quei tipi proverbiali che vivono nei seminterrati delle case dei genitori.

Cioè, molti lo sono, ma alcuni hanno comunque del talento. Sospetto infatti che la percezione di talento inespresso, frustrato, sia ciò che trasforma una persona in un hater.

Non dicono soltanto: "non è giusto che Tizio sia famoso" ma anche: "non è giusto che Tizio sia famoso ed io no".

Un hater può redimersi se raggiunge un qualche obiettivo importante?

È una domanda inutile perché non combineranno mai niente. Li ho osservati per lungo tempo e sono piuttosto sicuro che lo schema funzioni in ambedue le direzioni: non solo coloro che fanno qualcosa di importante non saranno mai hater, ma anche che nessun hater farà mai qualcosa di buono.

Sebbene non ami la parola "fanboy", è comunque evocativa di qualcosa che li accomuna agli hater.

Implica cioè che il fanboy è così banalmente prevedibile nella sua ammirazione incondizionata che ne viene sminuito come persona; è meno di un uomo.

Gli hater sembrano ancor più sminuiti dal loro atteggiamento. Posso infatti immaginare di essere un fanboy. Per le persone di cui ammiro le opere potrei anche umiliarmi davanti a loro in segno di assoluta gratitudine. Se P.G. Wodehouse fosse vivo, mi ci vedrei come suo fanboy.

Ma non mi posso immaginare come hater.

Sapendo quindi che gli haters sono l'opposto dei fanboy, risulta più semplice averci a che fare. Non serve cioè una teoria separata per gli hater. Possiamo usare le stesse tecniche che usiamo con i fan ossessivi.

La più importante della quale è non pensarci troppo. Se sei una persona che ha una fama tale da avere hater, la tua prima reazione sarà di smarrimento.

Perché quel tipo ce l'ha con me? Da dove viene tutta quella energia ossessiva e cosa lo rende così orribilmente cattivo?

Cos’ho fatto per farlo arrabbiare? C'è qualcosa che posso fare per ricomporre la situazione?

Ecco, l'errore è pensare ad un hater come qualcuno con cui ho avuto una discussione. Se hai una discussione, è spesso un'ottima idea cercare di capire il perché qualcuno ce l'abbia con te e cercare di rimediare in qualche modo. Le discussioni infatti distolgono l'attenzione.

Ma è un'analogia sbagliata pensare ad un hater come a qualcuno con cui hai una discussione. È un comprensibile errore se non hai mai incontrato prima un hater.

Ma nel momento in cui comprendiamo di avere a che fare con un hater e anche cos'è un hater, è chiaro che è una perdita di tempo anche solo pensarci.

Se hai un fan ossessivo, sprechi mai del tempo a cercare di capire perché ti ami così tanto? No, pensi soltanto che “la gente a volte è matta" e la finisci lì.

Quindi, se un fanboy ed un hater sono equivalenti, questo è il modo migliore per gestirli.

C'è stato probabilmente qualcosa che li ha scatenati.

Ma che non avrebbe scatenato una persona normale e quindi non c'è motivo di sprecare tempo a pensarci.

Non sei tu, sono loro.

Note

(le note nella versione originale non sono collegate a nessun punto del testo dell’essay)

[1] Ci sono ovviamente persone che sono autentiche truffe. Come puoi distinguere tra x che chiama y una "truffa" perché x è un hater e perché y è una truffa? Guarda l'opinione "neutrale". Gli imbroglioni veri di solito sono abbastanza evidenti. Le persone coscienziose di rado si fanno ingannare da loro. Quindi, se ci sono persone coscienziose che apprezzano y, di solito puoi presumere che y non sia un imbroglione.

[2] Farei un'eccezione per gli adolescenti, che a volte si comportano in modi così estremi che non sono letteralmente sé stessi. Posso immaginare un ragazzo adolescente che è un hater e poi , maturando, smettere di esserlo. Ma nessuna eccezione per chiunque abbia più di 25 anni.

[3] Ho una memoria molto peggiore per le cattive azioni rispetto a mia moglie Jessica, che è un intenditore dell'indole umana, ma non vorrei che questa fosse la cosa migliore. La maggior parte delle dispute è una perdita di tempo, anche se hai ragione, ed è facile fare pace con qualcuno se non ricordi perché eri arrabbiato con lui.

[4] Un hater competente non ti attaccherà solo individualmente, ma cercherà di attirare la folla contro di te. In alcuni casi potresti voler confutare qualsiasi affermazione falsa faranno. Ma fai attenzione, perché alla fine, probabilmente, sarà comunque irrilevante.

Grazie a: Austen Allred, Trevor Blackwell, Patrick Collison, Christine Ford, Daniel Gackle, Jessica Livingston, Robert Morris, Elon Musk, Harj Taggar, and Peter Thiel per aver letto le bozze di questo scritto.

Traduzione in italiano di Francesco Mottini dall’essay originale di Paul Graham "Java's Cover" [Aprile 2001].

Questo saggio è nato dalle conversazioni che ho avuto con diversi altri programmatori sul perché Java puzzasse di sospetto. Non è una critica a Java! È un caso di studio sul sesto senso degli hacker.

Nel corso del tempo, gli hacker acquisiscono un fiuto per la buona (e la cattiva) tecnologia. Ho pensato che sarebbe stato interessante provare a scrivere cosa mi ha fatto sembrare Java sospetto.

Alcune persone che hanno letto questo articolo pensano che sia un tentativo interessante di scrivere di qualcosa di cui non è mai stato scritto prima. Altri dicono che mi metterò nei guai in quanto verrò percepito come qualcuno che scrive di qualcosa che non capisce. Quindi, nel caso serva a qualcosa, lasciatemi chiarire che non sto scrivendo di Java (che non ho mai usato), ma del sesto senso degli hacker (su cui ho riflettuto molto).

L'aforisma "non si giudica un libro dalla sua copertina" ha avuto origine ai tempi in cui i libri venivano venduti in semplici copertine di cartone, per essere poi rilegati a cura di ciascun acquirente secondo i propri gusti. A quei tempi, non si poteva giudicare un libro dalla copertina. Rispetto ad allora, l'editoria è progredita: gli editori di oggi lavorano duramente per rendere la copertina qualcosa da cui si possa giudicare un libro.

Personalmente, trascorro molto tempo nelle librerie e mi sembra di aver ormai imparato a capire tutto quello che gli editori vogliono dirmi di un libro, e forse anche qualcosa di più. Il tempo che non ho passato in libreria l'ho passato per lo più davanti al computer e mi sembra di aver imparato allo stesso modo, in qualche misura, a giudicare anche la tecnologia dalla sua copertina. Potrebbe essere solo fortuna, ma mi sono salvato da alcune tecnologie che si sono rivelate essere delle vere schifezze.

Finora, Java mi sembra una schifezza. Non ho mai scritto un programma in Java, né ho mai dato più di uno sguardo ai libri in merito, ma ho la sensazione che non sarà un linguaggio di grande successo. Potrei sbagliarmi; fare previsioni sulla tecnologia è un'attività pericolosa. Ma per quello che vale, come una sorta di capsula del tempo, ecco perché non mi piace come Java si presenta:

* È stato esageratamente pubblicizzato. I veri standard tecnologici non hanno bisogno di essere promossi. Nessuno ha dovuto promuovere  C, o Unix, o HTML. Un vero standard tende a essere già affermato nel momento in cui la maggior parte delle persone ne sente parlare. Sullo schermo radar degli hacker, Perl è grande quanto Java, o più grande, solo grazie alla forza dei suoi meriti.

* Ha un obiettivo mediocre. Nel white paper originale su Java, Gosling dice esplicitamente che Java è stato progettato per non essere troppo difficile per i programmatori abituati al C. È stato progettato per essere un altro C++: C più alcune idee prese da linguaggi più avanzati. Come i creatori di sitcom o di cibo spazzatura o di pacchetti turistici, i progettisti di Java stavano consapevolmente progettando un prodotto per persone meno intelligenti di loro. Storicamente, i linguaggi progettati per essere utilizzati da altre persone si sono rivelati pessimi: Cobol, PL/I, Pascal, Ada, C++. I linguaggi decenti sono stati quelli progettati dai loro creatori per loro stessi: C, Perl, Smalltalk, Lisp.

* Ha secondi fini. Una volta qualcuno ha detto che il mondo sarebbe stato un posto migliore se le persone avessero scritto libri solo se avessero avuto qualcosa da dire, piuttosto che semplicemente perché vogliono scrivere un libro. Allo stesso modo, il motivo per cui sentiamo parlare sempre di Java non è perché ha qualcosa da dire sui linguaggi di programmazione. Sentiamo parlare di Java come parte di un piano di Sun per scalzare Microsoft.

* Nessuno lo ama. I programmatori di C, Perl, Python, Smalltalk e Lisp amano i loro linguaggi. Non ho mai sentito nessuno dire di amare Java.

* Le persone sono costrette a usarlo. Molte delle persone che conosco che utilizzano Java lo fanno perché si sentono obbligate. O perché ritengono di doverlo fare per ottenere un finanziamento, o perché pensano che i clienti lo vogliano, o perché gli è stato detto di farlo dai loro superiori. Sono persone intelligenti; se la tecnologia fosse buona, l'avrebbero usata volontariamente.

* Ci sono troppi sviluppatori coinvolti. I migliori linguaggi di programmazione sono stati sviluppati da piccoli gruppi. Java sembra essere gestito da un comitato. Se si dovesse rivelare un buon linguaggio, sarebbe il primo esempio nella storia di un buon linguaggio sviluppato da un comitato.

* È macchinoso. Da quel poco che so di Java, sembra che ci siano molti protocolli per ogni cosa. I linguaggi veramente buoni non sono così. Ti lasciano fare quello che vuoi e si tolgono di mezzo.

* È pseudo-hip. Sun ora finge che Java sia un linguaggio open-source di base, come Perl o Python. Si dia il caso che Java sia controllato da un'azienda gigantesca. Quindi è probabile che il linguaggio abbia la stessa squallida goffaggine di qualsiasi altra cosa che esce da una grande azienda.

* È progettato per le grandi organizzazioni. Le grandi organizzazioni hanno obiettivi diversi dagli hacker. Vogliono linguaggi che siano (o che siano ritenuti) adatti all'uso da parte di grandi gruppi di programmatori mediocri, linguaggi con caratteristiche che, come i limitatori di velocità dei camion U-Haul, impediscano agli sciocchi di fare troppi danni. Agli hacker non piacciono i linguaggi che li trattano con sufficienza. Gli hacker vogliono semplicemente potenza. Storicamente, i linguaggi progettati per le grandi organizzazioni (PL/I, Ada) hanno perso, mentre i linguaggi per hacker (C, Perl) hanno vinto. Il motivo: l'hacker adolescente di oggi è il CTO di domani.

* Piace alle persone sbagliate. I programmatori che ammiro di più non sono, nel complesso, affascinati da Java. A chi piace Java? Agli uomini d'affari, che non sanno distinguere un linguaggio dall'altro, ma che continuano a sentire di Java dalla stampa; ai programmatori delle grandi aziende, che si stupiscono di scoprire che esiste qualcosa di meglio del C++; e ai laureandi, pronti ad apprezzare qualsiasi cosa che possa far loro ottenere un lavoro (ci sarà questo nel test?). Le opinioni di queste persone cambiano a ogni piè sospinto.

* Il suo papà è in difficoltà. Il modello di business di Sun sta venendo compromesso su due fronti. I processori Intel a basso costo, dello stesso tipo utilizzato per le macchine desktop, sono ora veloci più che a sufficienza per i server. E FreeBSD sembra essere un sistema operativo per server almeno altrettanto valido quanto Solaris. La pubblicità di Sun implica che i server Sun siano necessari per applicazioni di livello industriale. Se questo fosse vero, Yahoo sarebbe la prima a comprare Sun; ma quando lavoravo lì, i server erano tutti Intel con FreeBSD. Questo non è di buon auspicio per il futuro di Sun. Se Sun si dovesse trovare in difficoltà, potrebbe trascinare con sé Java.

* Piace al Dipartimento della Difesa. Il Dipartimento della Difesa sta incoraggiando gli sviluppatori a utilizzare Java. Questo mi sembra il segno più incriminante tra tutti. Il Dipartimento della Difesa fa un ottimo lavoro (anche se costoso) per difendere il Paese, ma ama i piani, le procedure e i protocolli. La loro cultura è l'opposto di quella degli hacker; su questioni di software tendono a sbagliare. L'ultima volta che il Dipartimento della Difesa ha apprezzato un linguaggio di programmazione è stato Ada.

Tenete presente che questa non è una critica a Java, ma una critica alla sua copertina. Non conosco Java abbastanza bene da poterlo apprezzare o meno. Questa è solo una spiegazione del perché non sono desideroso di impararlo.

Può sembrare altezzoso scartare un linguaggio prima ancora di aver provato a scriverci dei programmi. Ma è una cosa che tutti i programmatori devono fare. Esistono troppe tecnologie per impararle tutte. Dovrete imparare a giudicare dai segni esteriori quali valgono il vostro tempo. Ho altezzosamente scartato allo stesso modo Cobol, Ada, Visual Basic, IBM AS400, VRML, ISO 9000, il protocollo SET, VMS, Novell Netware e CORBA, tra gli altri. Mi sapevano semplicemente di sbagliato.

Può darsi che nel caso di Java mi stia sbagliando. Potrebbe essere che un linguaggio promosso da una grande azienda per scalzare un'altra, progettato da un comitato per un pubblico "mainstream", pubblicizzato fino agli estremi e amato dal Dipartimento della Difesa, sia comunque un linguaggio pulito, bello e potente con cui mi piacerebbe programmare. Potrebbe essere, ma sembra molto improbabile.

Traduzione in italiano di Niccolò Ferrari dall’essay originale di Paul Graham "The Two Kinds of Moderate"[Dicembre 2019].

Ci sono due modi distinti di essere politicamente moderati: intenzionalmente e per caso. I moderati intenzionali sono coloro che adattano il loro pensiero, scegliendo deliberatamente una posizione intermedia tra gli estremi della destra e della sinistra. Moderati accidentali invece, sono coloro che solitamente si ritrovano a metà perché, dopo aver formulato il loro pensiero riguardo un tema, non si riconoscono né nella destra, né nella sinistra, le considerano anzi ugualmente sbagliate.

Potete distinguere i due analizzando la distribuzione delle loro opinioni. Se riguardo a un argomento, l’estrema sinistra equivale a uno 0 e l’estrema destra a un 100, l’opinione di un moderato intenzionale sarà sempre attorno al 50. Al contrario, l’opinione di un moderato accidentale sarà distribuita in maniera più ampia ma alla fine, come per il moderato intenzionale, la media sarà intorno al 50.

I moderati intenzionali sono simili ai rappresentanti dell’estrema destra e sinistra se si considera che le loro opinioni, in realtà, non appartengono originariamente ad essi. La caratteristica distintiva di un ideologo, indipendentemente dallo schieramento, consiste nell’appropriarsi ciecamente dell’opinione di qualcun altro. In maniera massiva, senza selezioni né filtri. Le vostre opinioni riguardo la tassazione possono essere previste da quelle che avete riguardo al sesso. E sebbene i moderati intenzionali possano sembrare l’opposto degli ideologi, ciò in cui credono (“posizione”, per essere più precisi) è definito massivamente. Se l’opinione media si sposta verso destra o sinistra, il moderato intenzionale si sposta con essa. Altrimenti smetterebbe di essere moderato.

I moderati per caso, al contrario, non solo decidono individualmente le loro risposte, ma anche i loro argomenti. Potrebbero non interessarsi affatto, ad esempio, di alcune questioni che sia la destra che la sinistra ritengono tassativamente importanti. Potete dunque misurare la politica di un moderato accidentale, solamente dall’intersezione degli argomenti a cui si interessano loro, e quelli ai quali si interessano la destra e la sinistra. Questa intersezione, a volte può essere davvero ristretta.

Dire “se non sei con noi, allora sei contro di noi” non è solamente un trucco di retorica manipolativa, ma spesso è essenzialmente falso.

I moderati, spesso vengono derisi come codardi, specialmente dagli estremisti di destra. Ma, sebbene gli intenzionali siano effettivamente dei codardi, gli accidentali, al contrario, dimostrano di avere un coraggio straordinario, perché sono costantemente attaccati sia da destra che da sinistra, e non hanno la protezione che avrebbe un fedele membro di un gruppo più grande.

Quasi tutte le persone più interessanti che Io conosca sono moderati accidentali. Se conoscessi persone del mondo dello spettacolo, o atleti professionisti però, sono convinto che la situazione potrebbe essere diversa. Far parte dell’estrema destra o sinistra non impattano su quanto forte voi possiate correre o quanto cantiate bene. Al contrario, chi lavora con le idee deve per forza avere un pensiero indipendente, per poter farlo bene.

Più precisamente, dovete essere indipendenti relativamente alle idee con le quali lavorate. Potreste essere indottrinati ciecamente dal punto di vista politico, ma eccellere comunque in matematica. Nel 20esimo secolo, parecchie persone brillanti erano Marxiste, semplicemente non erano brillanti per quanto riguardava gli argomenti che il Marxismo toccava. Ma, se le idee che utilizzate nel vostro lavoro si intersecano con le politiche del vostro tempo, avete due scelte: essere moderati accidentali, oppure essere mediocri.

Note

(le note nella versione originale non sono collegate a nessun punto del testo dell’essay)

[1] C'è la possibilità che un lato abbia ragione al 100% e l’altro no. Anzi, gli ideologi devono sempre credere che sia così. Ma, storicamente, non lo è quasi mai stato.

[2] Per alcune ragioni, l’estrema destra tende a ignorare i moderati, piuttosto che un traviato. Non sono sicuro del perché. Forse significa che l’estrema destra è meno ideologica della sinistra. O forse sono più sicuri, o più rassegnati, o semplicemente più disorganizzati. Semplicemente no lo so.

[3] Avere delle opinioni eretiche non significa che dobbiate esprimerle apertamente per forza. Anzi, è più facile che le abbiate se state in silenzio.

Traduzione in italiano di Domenico Pastore dall’essay originale di Paul Graham "The List of N Things" [Settembre 2009].

Scommetto che nel numero attuale di Cosmopolitan c'è un articolo il cui titolo inizia con un numero. "7 cose che lui non ti dirà sul sesso", o qualcosa del genere. Alcune riviste molto vendute presentano articoli di questo tipo sulla copertina di ogni numero. Non può essere un caso. Gli editori devono sapere che attirano i lettori.

Perché ai lettori piace tanto l'elenco delle n cose? Principalmente perché è più facile da leggere di un normale articolo. Strutturalmente, l'elenco di n cose è come un saggio degradato. Un saggio può andare ovunque lo scrittore voglia. In un elenco di n cose lo scrittore accetta di limitarsi a un insieme di punti di importanza approssimativamente uguale e dice esplicitamente al lettore quali sono.

Una parte del lavoro di lettura di un articolo consiste nel comprenderne la struttura: capire quello che al liceo avremmo chiamato "schema". Non in modo esplicito, ovviamente, ma chi capisce davvero un articolo probabilmente ha qualcosa nel suo cervello che corrisponde a questo schema. In un elenco di n cose, questo lavoro è fatto per voi. La sua struttura è un esoscheletro.

Oltre a essere esplicita, la struttura è caratterizzata dal tipo più semplice possibile: pochi punti principali con pochi o nessun punto subordinato e nessuna connessione particolare tra di essi.

Poiché i punti principali non sono collegati, l'elenco di n cose è ad accesso casuale. Non c'è un filo di ragionamento da seguire. Si può leggere l'elenco in qualsiasi ordine. E poiché i punti sono indipendenti l'uno dall'altro, funzionano come i compartimenti stagni di una nave inaffondabile. Se vi annoiate, o non riuscite a capire, o non siete d'accordo con un punto, non dovete rinunciare all'articolo. Potete semplicemente abbandonare quel punto e passare al successivo. L’elenco di n cose è parallelo e quindi tollera bene gli errori.

Ci sono casi in cui questo formato è quello che uno scrittore vuole. Ovviamente, uno di questi è quando ciò che si deve dire è effettivamente un elenco di n cose. Una volta ho scritto un saggio sugli errori che uccidono le startup e alcune persone mi hanno preso in giro per aver scritto qualcosa il cui titolo iniziava con un numero. Ma in quel caso stavo davvero cercando di fare un catalogo completo di una serie di cose indipendenti l’una dall’altra. In particolare, una delle domande a cui cercavo di rispondere era quanti ce ne fossero, di questi errori.

Ci sono altre ragioni meno legittime per usare questo formato. Per esempio, io lo uso quando mi avvicino a una scadenza. Se devo tenere un discorso e non l'ho iniziato con sufficiente anticipo, a volte vado sul sicuro e strutturo il discorso come un elenco di n cose.

L'elenco delle n cose è più facile sia per chi scrive che per chi legge. Quando si scrive un vero saggio, c'è sempre la possibilità di finire in un vicolo cieco. Un vero saggio è un treno di pensieri e alcuni treni di pensieri si fermano. È un'eventualità allarmante quando si deve tenere un discorso a distanza di pochi giorni. Cosa succede se si esauriscono le idee? La struttura a compartimenti stagni dell'elenco di n cose protegge lo scrittore dalla sua stessa stupidità, proprio come protegge il lettore. Se si è a corto di idee su un punto, non c'è problema: il saggio non verrà distrutto. Si può eliminare l'intero punto, se necessario, e il saggio sopravviverà comunque.

Scrivere un elenco di n cose è così rilassante. Si pensa a n/2 di esse nei primi 5 minuti. Quindi, ecco la struttura e dovete solo riempirla. Quando vi vengono in mente altri punti, li potete aggiungere alla fine. Magari ne togliete, riorganizzate o combinate alcuni, ma in ogni fase avete un elenco valido (anche se inizialmente grossolano) di n cose. È come il tipo di programmazione in cui si scrive una versione 1 molto velocemente e poi la si modifica gradualmente, ma in ogni punto si ha un codice funzionante, o lo stile di pittura in cui si inizia con uno schizzo completo ma molto sfocato fatto in un'ora, poi si impiega una settimana ad aumentare la risoluzione.

Poiché l'elenco delle n cose è più facile anche per gli scrittori, non è sempre un segnale negativo quando i lettori lo preferiscono. Non è necessariamente una prova che i lettori sono pigri; potrebbe anche significare che non hanno molta fiducia nello scrittore. L'elenco delle n cose è, da questo punto di vista, il cheeseburger dei saggi. Se state mangiando in un ristorante che sospettate sia scadente, la cosa migliore è ordinare un cheeseburger. Anche un pessimo cuoco può preparare un cheeseburger decente. E ci sono convenzioni piuttosto rigide su come dovrebbe essere un cheeseburger. Si può presumere che il cuoco non proverà a fare qualcosa di strano e artistico. L'elenco di n cose limita in modo analogo i danni che può fare un cattivo scrittore. Si sa che si parlerà di tutto ciò che il titolo dice, e il formato impedisce allo scrittore di abbandonarsi a qualsiasi volo di fantasia.

Poiché l'elenco di n cose è la forma di saggio più semplice, dovrebbe essere una buona forma per gli scrittori principianti. E in effetti è quello che viene insegnato alla maggior parte degli scrittori principianti. Il classico saggio di 5 paragrafi è in realtà un elenco di n cose dove n = 3. Ma gli studenti che lo scrivono non si rendono conto che stanno usando la stessa struttura degli articoli che leggono su Cosmopolitan. Non sono autorizzati a includere i numeri e ci si aspetta che colleghino le varie parti con passaggi non necessari ("Inoltre...") e che chiudano il tutto con paragrafi introduttivi e conclusivi, in modo da farlo sembrare all'apparenza un vero saggio.

Mi sembra una buona idea quella di far iniziare gli studenti con la scrittura di un elenco di n cose. È la forma più semplice. Ma se dobbiamo farlo, perché non farlo apertamente? Lasciate che scrivano liste di n cose come i professionisti, con i numeri e senza transizioni o "conclusioni".

C'è un caso in cui l'elenco di n cose è un formato disonesto: quando lo si usa per attirare l'attenzione sostenendo falsamente che l'elenco è esaustivo. Ad esempio, se si scrive un articolo che dichiara di parlare de “I 7 segreti del successo”. Questo tipo di titolo ricalca la provocazione mentale che si trova in un libro giallo. Dovete almeno dare un’occhiata all'articolo per verificare se sono gli stessi 7 che elenchereste voi. State trascurando uno dei segreti del successo? Meglio controllare.

Va bene mettere l’articolo prima del numero se si crede davvero di aver fatto un elenco esaustivo. Ma l'evidenza dimostra che la maggior parte degli articoli con titoli come questo sono clickbait.

La più grande debolezza dell'elenco di n cose è che c'è così poco spazio per un nuovo pensiero. Il punto principale della scrittura di un saggio, quando è fatto bene, sono le idee nuove che ti vengono mentre lo scrivi. Un vero saggio è dinamico: non si sa cosa si scriverà quando si inizia. Di che cosa si tratterà lo si scoprirà nel corso della stesura.

Questo può avvenire solo in modo molto limitato in un elenco di n cose. Prima si crea il titolo, e questo è l'argomento di cui si parlerà. Non si possono avere più idee nuove nella scrittura di quante ne entrino nei compartimenti stagni che si sono creati inizialmente. E il vostro cervello sembra saperlo: siccome non avete spazio per le nuove idee, non le avrete.

Un altro vantaggio di ammettere agli scrittori principianti che il saggio di 5 paragrafi è in realtà un elenco di n cose è che possiamo metterli in guardia da questo. Permette di sperimentare la caratteristica distintiva della scrittura di un saggio su scala ridotta: in pensieri di una o due frasi. Ed è particolarmente pericoloso che il saggio di 5 paragrafi seppellisca l'elenco di n cose all'interno di qualcosa che sembra un tipo di saggio più sofisticato. Se non sapete che state usando questa struttura, non sapete che dovete evitarla.

Note