Una ben nota affermazione di Phil Karlton recita: “Ci sono solo due cose difficili in informatica: invalidare la cache e nominare le cose.”

Tralasciando l’invalidazione della cache, su cui potremo tornare in un’altra occasione, perché nominare le cose dovrebbe essere così difficile? Dare nomi agli oggetti che ci circondano sembrerebbe essere un’attività innata nell’uomo. E’ tra le prime cose che fa il bambino quando inizia a parlare.

Dare un nome alle cose

Limitandoci all’ambito informatico, non possiamo negare che noi sviluppatori abbiamo delle difficoltà nell'assegnare nomi ai nostri artefatti: che si tratti di variabili, classi, funzioni o altro, spesso i nomi assegnati lasciano un po’ a desiderare.

Forse siamo troppo focalizzati nell’ottenere rapidamente una soluzione al problema che stiamo risolvendo e non prestiamo attenzione ad un effetto collaterale fondamentale del nostro lavoro: la comunicazione con gli altri.

Così, assegnare ad una variabile il nome x o y non ci fa perdere tempo prezioso a pensare cosa quella variabile possa comunicare ad un collega ignaro di quello che ci passa per la mente. Al massimo possiamo usare temp per una variabile temporanea o data per una variabile destinata a contenere un valore di tipo data.

Ma anche quando lo sforzo è considerevole, come può essere ad esempio nel caso di una variabile chiamata dataInizio, molto spesso ci dimentichiamo di adeguare il nome inizialmente dato alle mutate esigenze del contesto. E così può capitare che quella che era una variabile pensata per contenere la data di inizio di un contratto diventi una data di sottoscrizione ma continua a mantenere lo stesso nome dataInizio introducendo ambiguità che prima o poi daranno vita a bug.

Nomi e ambiguità

Ambiguità. E’ una parola che gli informatici dovrebbero conoscere molto bene. Uno dei requisiti per cui un linguaggio di programmazione funzioni correttamente è l’assenza di ambiguità: non possono esserci costrutti per cui un compilatore o un interprete non è in grado di riconoscere il significato univoco.

Noi umani siamo esperti in ambiguità. Molto spesso siamo in grado di risolverle e talvolta ci piace anche giocarci. Ma non le macchine. E nemmeno le intelligenze artificiali, che riescono a farlo in contesti molto ristretti, ma non credo siano ancora in grado di cogliere l’umorismo che talvolta si nasconde nelle ambiguità.

Nemmeno il cosiddetto pensiero formale gradisce le ambiguità. Il modo di ragionare delle discipline scientifico-matematiche, a cui l’informatica dovrebbe appartenere, pretende che i concetti siano ben definiti e possibilmente identificati da un nome. Nome che spesso sintetizza la definizione del concetto, quindi letteralmente significativo. Senza scomodare Platone, il nome deve richiamare la definizione del concetto, per cui, ad esempio, triangolo è un qualcosa che ha tre angoli, e non può averne quattro.

Nomi e comunicazione

Il fatto che un nome debba richiamare la definizione dell’oggetto o del concetto che descrive sembra una cosa ovvia. Purtroppo, al di fuori degli ambienti accademici, non è così scontato in ambito informatico.

Nella mia esperienza ho incontrato diverse occasioni di cattiva comunicazione dettata da ambiguità o di interpretazioni ad sensum dei nomi di oggetti e concetti informatici.

Vi è mai capitato di imbattervi in persone che confondono un dominio con un URL? A me spessissimo. Ma non parlo di junior, anche di senior con diversi anni di esperienza alle spalle.

Anche sul significato di sessione si può assistere ad innumerevoli diatribe: in tanti confondono il concetto di sessione con la sua implementazione (es., basata sull'uso dei cookie in ambito Web) o sulla persistenza dei dati associati ad essa (es., session storage).

Per non parlare di una delle tecnologie più fraintese: REST. La stragrande maggioranza degli sviluppatori non sa nemmeno cosa sia uno state transfer in questo contesto, che pure è parte fondamentale sia dell'acronimo che del paradigma architetturale.

I latini dicevano Nomen omen, cioè un nome porta con sé il suo destino, il suo significato ultimo. Ma se non riusciamo ad interpretare correttamente un nome, come possiamo comprenderne il significato?

Cosa c’è dietro un nome

Galileo scriveva: “I nomi e gli attributi si devono accomodare all’essenza delle cose, e non l’essenza a i nomi; perchè prima furon le cose, e poi i nomi.” Dare un nome è un’attività di adattamento del linguaggio alla realtà. E qui sta forse la natura della complessità di questa apparente semplice attività.

Mi ha sempre affascinato la storia che c’è dietro un nome. Il suo senso originario, la sua evoluzione sia nella forma che nel significato. Contribuisce a darmi l’idea che non si tratti soltanto di un’etichetta ma di un qualcosa di vivo.

Comprendo lo sforzo che c’è dietro la scelta di un nome: da quello per un bimbo a quello per un animale, da quello di un’azienda a quello di un prodotto. Una serie di tentativi, molti dei quali a vuoto, con l’intento di descrivere al meglio il concetto, il progetto o la persona che si ha in mente. O semplicemente un nome che sia piacevole e che ispiri un qualche sentimento.

Dare nomi alle cose non è semplice, ma fa parte dell’essenza umana. Dare un nome è un po’ come dare la vita, come segnare il destino. Non va fatto con leggerezza, perché quel nome identifica l’oggetto, e nome e oggetto diventano un tutt’uno.

Questo dovrebbe valere per tutto, incluse le variabili, dal momento che, come scriveva Albert Camus, “Dare un nome sbagliato alle cose contribuisce all’infelicità del mondo”.

Ma talvolta i nomi tendono a prendere un’esistenza propria, scollegata dall’oggetto reale. E in qualche caso, il nome è la sola cosa che ci rimane quando l’oggetto reale non esiste più.

“Stat rosa pristina nomine, nomina nuda tenemus”