La codifica come una sorta di scrittura

May 10 2023

Cosa possono imparare gli sviluppatori di software dagli autori di prosa

C'è un posto dove il fiume Snake nel Wyoming piega verso nord, si allarga e rallenta. Le alci curiosano tra le ninfee, i pellicani pescano, le lontre giocano.

C'è un posto dove il fiume Snake nel Wyoming piega verso nord, si allarga e rallenta. Le alci curiosano tra le ninfee, i pellicani pescano, le lontre giocano. Quindi il fiume si arriccia su se stesso e riprende il suo viaggio verso ovest verso le montagne.

Vedrai lo stesso percorso ad anello se guardi alla mia carriera fino ad ora. Sono uno sviluppatore di software diventato insegnante di discipline umanistiche che è tornato a essere uno sviluppatore di software. Tra l'ingegneria e le discipline umanistiche c'è una distanza ben nota, ma l'ho percorsa abbastanza da sapere che è più breve di quanto la gente pensi. Lungo la strada, ho notato che alcuni dei consigli che gli autori di prosa dispensano potrebbero essere preziosi anche per gli autori di software, quasi come se scrivere codice fosse una forma di scrittura.¹

Una volta, avevo bisogno di creare una piccola funzione che aggiungesse un elemento a un array, ma rimuovesse l'elemento se era già presente. Come questo:

toggle([], 1) // should return [1]
toggle([1], 1) // should return []

import _ from "lodash";
const toggle = (arr, item) => _.xor(arr, [item]);

Presto, però, mi sono ricordato di alcune parole di consiglio: "Rileggi le tue composizioni e ogni volta che incontri un passaggio che ritieni particolarmente bello, cancellalo". Questo è un suggerimento di Samuel Johnson, saggista del diciottesimo secolo.³ Il formicolio dell'intelligenza, mi resi conto, era un indizio che avrei dovuto semplificare la mia funzione. l'ho cambiato in:

const toggle = (arr, item) =>
   arr.includes(item) ?
   arr.filter((x) => item !== x) :
   [...arr, item];

Secondo me: no.⁴ Anche se più complessa sotto certi aspetti, la nuova funzione era comunque più chiara per il programmatore medio, e quindi più facile da mantenere. Una riga di codice può essere sintatticamente semplice ma poco chiara, oppure chiara ma sintatticamente complessa. Proprio come una linea di prosa. Pensa alla frase: "Cosa hai portato quel libro per il quale non voglio che mi si legga?"⁵ Ha una sintassi contorta, ma è molto più comprensibile rispetto, ad esempio, alla frase sintatticamente semplice, " Il mirmecobio si è absquatulato. Sebbene non più laconica, la mia nuova funzione era più facile da leggere.

Se avesse conosciuto JavaScript, lo stesso re della prosa laconica avrebbe disapprovato la versione più concisa di toggle. "Hemingway" - il re in questione - "non ti porta al dizionario", disse una volta F. Scott Fitzgerald con apprezzamento.⁶ Se avesse usato xor, la mia funzione avrebbe portato la maggior parte dei lettori alla documentazione. Senza di essa, la funzione è più articolata, esplicita e, per questo motivo, più autoesplicativa.⁷

Il termine laconico deriva dagli spartani dell'antichità, che vivevano in una regione chiamata Laconia e non sprecavano parole. Un nemico una volta scrisse loro: "Se invado la Laconia, ti caccerò dalla terra". Risposero: "Se".

Un precetto sulla scrittura che ammiro non viene da un romanziere o da un giornalista, ma da un progettista di musei. Una buona scrittura, secondo Edwin Schlossberg, "crea[s] un contesto in cui altre persone possono pensare."⁹ Li aiuta a immaginare, rimuginare, rispondere. Dà loro lo spazio per farlo, come una mostra in un museo. In modo simile, un buon codice fa spazio ai lettori, per così dire. Li aiuta a ragionare.

Di solito ha senso, quindi, che un autore di codice segua schemi che il lettore medio comprende già bene. Sebbene la maggior parte degli sviluppatori JavaScript abbia familiarità con il ternario (il punto interrogativo e i due punti) usato sopra, molti sono ancora più a loro agio con un blocco if-else, come questo:

const toggle = (arr, item) => {
   if (arr.includes(item)) {
      return arr.filter((x) => item !== x);
   } else {
      return [...arr, item];
   }
}

Gli autori devono provare empatia per i loro lettori e anche tu devi avere empatia per le persone che manterranno, eseguiranno il debug o adatteranno il tuo codice. Dal momento che sei l'autore, però, è normale avere difficoltà a mettersi nei panni dei tuoi lettori. Prova due tecniche prese in prestito dai migliori scrittori.

Innanzitutto, Helen Sword suggerisce di "visualizzare persone specifiche che ti guardano alle spalle mentre scrivi". Dopotutto, "gli scrittori più coinvolgenti sono quasi invariabilmente quelli che prestano la massima attenzione alle persone reali - specialisti e non specialisti, colleghi e sconosciuti - nelle cui orecchie risuoneranno le loro stesse parole".¹¹ Saggi consigli anche per i programmatori.

Una seconda tecnica: metti da parte il tuo codice per un giorno o due, se puoi, poi tornaci. "Finisci il racconto, stampalo, poi mettilo in un cassetto e scrivi altre cose", disse una volta Neil Gaiman a un aspirante scrittore. “Quando sei pronto, prendilo e leggilo, come se non l'avessi mai letto prima. Se ci sono cose di cui non sei soddisfatto come lettore, entra e aggiustale come scrittore: questa è la revisione.

in modo che quando ci torneremo dopo un intervallo avrà l'aria di novità e di essere opera di un altro; poiché così possiamo impedirci di considerare i nostri scritti con tutto l'affetto che prodighiamo per un neonato. ¹³

Non è troppo sorprendente che la guida dello scrittore possa essere adattata a simboli di tipo diverso. Le aree di conoscenza spesso si infiltrano l'una nell'altra, o come afferma magnificamente il romanziere Charles Johnson:

Una forma di espressione artistica e intellettuale nutre e nutre le altre. Qualunque cosa chiamiamo creatività e immaginazione - questi due grandi misteri - possono essere per alcuni creatori vissuti come "globali" nelle loro vite, non localizzati in una singola forma di espressione, ma piuttosto diffusi o traboccanti da un genere all'altro, uno artistico o disciplina intellettuale all'altra, poiché tutte le discipline umanistiche (insieme alle scienze) sono correlate, interconnesse. ¹⁴

Sperimentare nella propria codifica con gli approcci consigliati qui potrebbe richiedere un cambiamento nella routine. Una deviazione, perché tu possa, come il fiume, rallentare e diventare più riflessivo, più generoso. Quindi prendi una pagina dal fiume. Non segue un percorso lineare.

L'analogia codifica-scrittura ha i suoi limiti, certo. Ad esempio, le contraddizioni sono quasi vietate nel codice sorgente, ed è nell'arte, in particolare nella poesia, che trovano giustizia. C'è una poesia di Fernando Pessoa che mi piace leggere ad alta voce anche se non conosco il portoghese. Inizia:

O poeta é um fingidor
Finge tão completamente
Que chega a fingir que é dor
A dor que deveras sente.

Un poeta è colui che finge.
Finge così completamente il reale
che finge persino i terribili dolori
e le sofferenze che prova.¹⁵

Pessoa ci invita a mettere momentaneamente da parte le idee convenzionali di vero e falso. Sta affermando senza scusarsi una contraddizione: i poeti si nascondono dietro le loro poesie e, così facendo, diventano visibili attraverso di esse. Lasciandosi alle spalle la logica booleana, Pessoa inventa una sua logica. “Poeta è colui che finge”: cosa vuol dire, se non “mi invento tutto quello che dico, è tutto falso, comprese queste stesse parole”? Questa è un'affermazione autoconfutante, una falsità logica. Ma se guardi attraverso le parole alle loro radici etimologiche, "O poeta é um fingidor" significa "Un creatore è un creatore". Una verità logica. Come il dolore simulato che menziona, l'affermazione del poeta è falsa in superficie, vera sotto. Codice e poesia offrono strategie complementari per far fronte a un mondo spesso illogico: l'una offre rifugio dalle contraddizioni,

Note a piè di pagina

[1]: L'analogia della codifica-scrittura è stata fatta prima, anche se in modo diverso, da Brian Kernighan e PJ Plauger , Donald Knuth , Richard Gabriel , James Devlin , Jeff Atwood e Rebecca Sutton Koeser , tra gli altri. Steve McConnell critica l'analogia.

[2]: Ecco un esempio della funzione lodashdella biblioteca xorin azione. In Boggle cerchi le parole in una griglia di lettere. Se trovi una parola che nessun altro ha trovato, ottieni punti per essa. Supponi di creare una versione del gioco in JavaScript. Hai questi dati:

const wordsFoundByPlayerOne = ["apple", "peel"];
const wordsFoundByPlayerTwo = ["apple", "leap"];
const wordsFoundByPlayerThree = ["apple", "able"];

_.xor(
   wordsFoundByPlayerOne,
   wordsFoundByPlayerTwo,
   wordsFoundByPlayerThree
); // Output: ["peel", "leap", "able"]

[4]: Possiamo anche creare un'alternativa altamente leggibile con l'aiuto di Set:

const toggle = (arr, item) => {
  const set = new Set(arr);
  if (set.has(item)) set.delete(item);
  else set.add(item);
  return Array.from(set);
}

[6]: Citato dall'allenatore Gary Gilson in un articolo del 2019 .

[7]: Al contrario, il blogger Jeff Atwood ha promosso la " programmazione spartana ".

[8]: Plutarco, Sulla loquacità .

[9]: Citato dal fisico Konstantin Likharev in un libro del 2021 .

[10]: Nel suo discorso del 2012 "Simplicity Matters", Rich Hickey sostiene che i programmatori non dovrebbero temere le difficoltà , in parte perché rendono il nostro lavoro interessante. Ma il nostro lavoro sarà più interessante se cade nella zona di Riccioli d'oro tra noioso e faticoso, come nel caso delle lezioni scolastiche .

[11]: Helen Sword, Stylish Academic Writing (2012), p. 44. Per migliorare la loro chiarezza, molti scrittori leggono le loro opere ad alta voce, ascoltando se stessi. Il filosofo Jonathan Bennett scrive : “Gilbert Ryle una volta mi disse: 'Ciò che non si legge bene all'orecchio non si legge bene agli occhi', e questo ha cambiato la mia vita. Più di ogni altra cosa, quell'intuizione mi ha mostrato come iniziare a salire dalla fossa della spazzatura fino alla pianura della prosa decente. Kernighan e Plauger offrono una visione simile sulla programmazione: “Un modo utile per decidere se un pezzo di codice è chiaro o meno è il 'test del telefono'. Se qualcuno può capire il tuo codice quando viene letto ad alta voce al telefono, è abbastanza chiaro. In caso contrario, è necessario riscriverlo” ( Elements of Programming Style , p. 21).