C’e’ una cosa che la programmazione insegna molto bene: il valore della chiarezza. Un valore esiste o non esiste.
Una condizione e’ vera o falsa.
Un flusso entra da una parte ed esce da un’altra.
Una funzione restituisce un risultato, oppure fallisce.
Un sistema puo’ anche essere complesso, ma per funzionare deve restare, almeno in qualche punto decisivo, leggibile.

Il codice non ama l’ambiguita’.

L’ambiguita’ puo’ anche entrare, ma appena entra cominciano i problemi. Un requisito scritto male produce interpretazioni diverse. Un nome vago genera confusione. Un comportamento non definito prima o poi diventa un bug. La programmazione costringe continuamente a fare una cosa che nella vita reale facciamo molto meno: scegliere un significato e tagliare via il resto.

Da questo punto di vista, scrivere software e’ una scuola molto severa. Ti abitua a diffidare delle parole troppo elastiche. Ti abitua a chiedere: cosa vuol dire esattamente? Quando succede? In quali casi? E se invece accade quest’altro? Qual e’ il confine? Dove finisce una cosa e dove ne inizia un’altra?

Il punto e’ che il mondo reale non collabora.

Il mondo reale non si lascia modellare cosi’ facilmente. Le persone non hanno stati chiari come gli oggetti delle classi. Le intenzioni non sono booleane. Le relazioni non sono funzioni pure. Le decisioni umane non seguono sempre un flusso lineare, e spesso nemmeno un flusso coerente. Una persona puo’ dirti una cosa e sentirne un’altra. Puo’ volere due cose incompatibili insieme. Puo’ cambiare idea senza riuscire a spiegarti davvero quando e’ successo. Puo’ essere sincera e contraddirsi nello stesso momento.

Il codice soffre tutto questo.

Per poter funzionare deve decidere che cosa conta e che cosa no. Deve trasformare la continuita’ in stati, la sfumatura in categorie, il movimento in regole. Deve prendere qualcosa di vivo e renderlo trattabile.

In questo senso, ogni software e’ una semplificazione del mondo. Anche quando e’ fatto bene. Anzi, soprattutto quando e’ fatto bene.

Quando programmi, a un certo punto devi decidere che cos’e’ davvero un utente, che cos’e’ un ordine, che cos’e’ un pagamento riuscito, che cosa significa che qualcosa e’ attivo, scaduto, valido, annullato. Sembrano definizioni tecniche, ma sotto c’e’ sempre un gesto piu’ profondo: stai imponendo una forma a qualcosa che, fuori dal sistema, forma non ne ha una sola.

Un pagamento, nel mondo, puo’ essere iniziato, promesso, tentato, autorizzato, fallito, ripetuto, contestato, rimborsato in parte, chiuso solo formalmente ma ancora ambiguo sul piano umano o commerciale. Nel software, prima o poi, devi decidere come chiamarlo. Devi scegliere uno stato. Devi dare un nome al punto in cui per il sistema una cosa e’ vera.

Ed e’ proprio li’ che si vede il limite e insieme la forza del codice.

La forza e’ che ti costringe a essere chiaro.
Il limite e’ che la chiarezza che ottieni non coincide mai del tutto con la realta’ che stai cercando di rappresentare.

Forse e’ per questo che, con gli anni, mi convince sempre meno l’idea che programmare significhi semplicemente scrivere istruzioni. Programmare e’ anche negoziare con il disordine. E’ decidere quanta parte del mondo vuoi sacrificare per far stare il resto dentro una struttura coerente.

A volte il sacrificio e’ piccolo.
A volte e’ enorme.

E non e’ detto che ce ne accorgiamo sempre.

Un software puo’ funzionare perfettamente dal suo punto di vista e restare comunque povero rispetto alla realta’ che pretende di descrivere. Puo’ essere corretto e insieme cieco. Puo’ essere elegante e insieme ingiusto. Puo’ dare risposte coerenti a domande formulate male.

Questo, secondo me, e’ uno dei punti in cui la programmazione smette di essere solo tecnica e si avvicina alla filosofia.

Perche’ la filosofia, almeno per come la sento io, comincia spesso quando ti chiedi che cosa resta fuori dal modello. Non solo se qualcosa funziona, ma che cosa taglia via per funzionare. Non solo se una definizione e’ utile, ma che cosa perde mentre semplifica. Non solo se una regola regge, ma a quale prezzo regge.

Il codice, da solo, non si pone queste domande. Le esegue e basta. Siamo noi, eventualmente, a doverle porre prima.

E forse e’ proprio questo il punto piu’ interessante: chi programma passa molto tempo a costruire ordine, ma se lavora abbastanza a lungo capisce anche che quell’ordine non e’ il mondo. E’ una sua versione. Una traduzione. Una riduzione necessaria, ma pur sempre una riduzione.

Il mondo e il codice non parlano la stessa lingua.

Il codice chiede definizioni, il mondo tollera contraddizioni.
Il codice vuole stati chiari, il mondo vive di transizioni confuse.
Il codice pretende coerenza, il mondo spesso procede per approssimazioni, esitazioni, compromessi.
Il codice ha bisogno di confini, il mondo li attraversa continuamente.

Forse anche per questo programmare puo’ deformare un po’ lo sguardo. Ti abitua a cercare chiarezza anche dove chiarezza non c’e’. Ti abitua a pensare che ogni problema, con abbastanza rigore, possa essere scomposto, formalizzato, risolto. E questa abitudine, sui sistemi tecnici, e’ potentissima. Sui sistemi umani, molto meno.

Le persone non si debuggano bene.

Le relazioni non hanno log leggibili.
Le decisioni non sempre hanno cause tracciabili.
Le crisi non restituiscono stack trace.
E soprattutto, molte delle cose piu’ importanti della vita non possono essere ridotte senza perdere quasi tutto.

Questo non rende la programmazione meno interessante. Semmai il contrario. La rende piu’ umile, almeno se la si guarda bene.

Perche’ a un certo punto capisci che scrivere codice non significa catturare la realta’. Significa costruire uno strumento che ne trattiene una parte, nel modo piu’ utile possibile, sapendo che una parte restera’ sempre fuori. Non per negligenza, ma per natura.

E forse la maturita’ tecnica sta anche qui: non innamorarsi troppo del proprio modello. Non confondere la precisione interna di un sistema con la verita’ del mondo che gli sta intorno. Non credere che una cosa, solo perche’ e’ formalizzata bene, sia anche descritta fino in fondo.

Alla fine, forse, il codice non ci insegna solo a essere rigorosi.

Ci insegna anche, indirettamente, che il rigore ha un confine.

E che oltre quel confine comincia un territorio piu’ instabile, piu’ ambiguo, meno trattabile, ma non per questo meno reale.

Il mondo resta li’, eccedente, impreciso, spesso refrattario alle nostre strutture.

Il codice fa quello che puo’.

E forse una parte della saggezza, sia tecnica sia umana, consiste proprio nel non dimenticare la distanza tra i due.