Il Paradosso di Python // The Python Paradox

Traduzione in italiano di Salvatore Sanfilippo dall’essay originale di Paul Graham "The Python Paradox" [Agosto 2004]. La lettura dell'articolo è di Irene Mingozzi.In un recente intervento, ho detto qualcosa che ha fatto arrabbiare in molti: che puoi ottenere programmatori più scaltri per un progetto scritto in Python rispetto a quelli che puoi ottenere per un progetto in Java.Con questo non voglio dire che i programmatori Java siano stupidi. Piuttosto che i programmatori Python sono particolarmente furbi. Per imparare un nuovo linguaggio, servono un sacco di sforzi. Le persone non imparano Python per ottenere un lavoro; lo imparano perché amano davvero programmare e non sono soddisfatte coi linguaggi che conoscono già.E ciò rende queste persone esattamente il tipo di programmatori che le aziende dovrebbero voler assumere. Da qui quello che chiamerò, in mancanza di un nome più appropriato, Il Paradosso di Python: se una società sceglie di scrivere il proprio software in un linguaggio piuttosto inusuale, essa riuscirà a ingaggiare programmatori migliori, perché potrà attrarre a sé coloro a cui la programmazione interessa abbastanza da imparare tale linguaggio. Per i programmatori il paradosso è ancora più pronunciato: il linguaggio da imparare per avere un buon lavoro è un linguaggio che gli altri non imparano al solo scopo di ottenere un lavoro.Finora solo poche aziende sono state abbastanza furbe da capire tutto ciò. Ma anche qui sta avvenendo una sorta di selezione naturale: si tratta proprio delle aziende per cui i programmatori vorrebbero lavorare. Google, ad esempio. Quando pubblicizzano posizioni libere per programmatori in Java, chiedono anche esperienze pregresse con Python.Un mio amico, che conosce praticamente tutti i linguaggi più utilizzati, usa Python per la gran parte dei suoi progetti. Dice che la ragione principale è che apprezza l’aspetto del codice sorgente. Sembra una ragione frivola per scegliere un linguaggio al posto di un altro. Ma non è banale come può sembrare: quando si programma si spende più tempo a leggere il codice che a scriverlo. Si spostano in giro pezzi di codice come farebbe uno scultore con una manciata di creta. Un linguaggio che rende il codice sorgente brutto fa infuriare un programmatore scrupoloso, così come un'argilla piena di grumi farebbe infuriare uno scultore.A sentir parlare di codice brutto, la gente penserà ovviamente a Perl. Ma la bruttezza superficiale di Perl non è il tipo di bruttezza a cui alludo. La vera bruttezza non è una sintassi che sembra pasticciata, ma quella che ti fa creare i programmi per mezzo dei concetti sbagliati. Il codice scritto in Perl potrà anche somigliare ai caratteri che appaiono quando un personaggio dei cartoni impreca, ma ci sono casi in cui sorpassa persino Python concettualmente.Almeno per il momento, perché entrambi i linguaggi sono in continua evoluzione. Eppure condividono, assieme a Ruby (e a Icon, a Joy, a J, a Lisp e SmallTalk) il fatto che sono stati creati e usati da gente a cui programmare interessa davvero. E questa gente, di solito, è la stessa che sa programmare bene. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit paulgrahamita.substack.com