Smettetela di pensare che l’inglese sia una lingua strutturata come un buon file JSON; è più simile a un vecchio codice legacy scritto da uno stagista sotto caffeina, pieno di bug semantici e condizioni edge-case che non hanno alcun senso logico.
Se state scrivendo un generatore procedurale di testo (o magari un bot che deve scrivere recensioni di gadget tech senza sembrare un bot), vi sarà capitato di scontrarvi con il dilemma eterno: «a» o «an»? La soluzione pigra, quella che tutti noi vorremmo implementare per chiudere la pratica in due secondi, sarebbe controllare se la parola successiva inizia con una vocale. Semplice, no? Un `if (word[0].isVowel())` e via. Ma ecco che arriva l’universo a ricordarti che non sei il padrone del codice.
Se usi la logica delle lettere, scriverai «an unicorn» invece di «a unicorn». Perché? Perché la ‘u’ di unicorn ha un suono consonantico (quello della ‘y’). E viceversa, con parole come «hour», dove la ‘h’ è muta e il suono è tutto vocale, la tua funzione crasherebbe logicamente restituendo «a hour».
Recentemente, il team di Red Blob Games ha deciso di affrontare questo nonsense con l’approccio giusto: niente intuizioni vaghe, ma analisi dei dati. Hanno scavato nel dataset CMUdict (una roba seria per la fonetica) per capire quanto fosse grave il problema. Il risultato è sorprendente: su oltre 32.000 parole, solo 129 presentano queste eccezioni bastarde. In pratica, la lingua è quasi coerente, è solo che quei pochi bug rimasti sono quelli che ti fanno fare la figura del principiante.
La cosa che amo di questo approccio è la totale assenza di fuffa. L’autore non ha provato a venderti un modello di AI da miliardi di parametri per risolvere un problema che si risolve con un po’ di analisi statistica e una buona visualizzazione in D3.js. Anzi, ammette pure lo stesso errore che compiamo tutti: ha perso troppo tempo a ottimizzare un algoritmo di semplificazione dei trie invece di concentrarsi sul parsing dei dati. È la classica trappola del maker: perderci ore su un dettaglio tecnico insignificante mentre il vero problema è altrove.
Non è una notizia che cambierà il modo in cui scriviamo codice in Italia (anche se, tra l’altro, la nostra grammatica è decisamente più lineare e meno ‘ottimizzata male’), ma è un promemoria fondamentale per chiunque faccia debugging o automazione: a volte la realtà non è ciò che leggi nel file di configurazione, ma ciò che l’output finale produce effettivamente. E se il suono non torna, il codice è rotto, punto.
Source: English: A vs. An