Ciao, e benvenuto nella settima puntata della cinquantaquattresima stagione. Oggi affrontiamo il capitolo più delicato e più onesto della storia di MySQL, quello che per anni gli è costato le critiche più severe, e che spiega meglio di ogni altro sia il suo pregio sia il suo difetto. Oggi parliamo di quando il buon senso tace: la storia della permissività.
Partiamo dal principio, perché è ambiguo. Abbiamo detto che MySQL è pragmatico: pur di non fermarti, di lasciarti andare avanti, di non essere d'intralcio. Sembra una bella qualità, e spesso lo è. Ma spinta troppo in là, questa qualità si rovescia in un difetto pericoloso. Perché a volte la cosa più utile che uno strumento può fare è proprio fermarti, e dirti aspetta, questo è sbagliato. E MySQL, per anni, ha scelto troppo spesso di non fermarti, nemmeno quando avrebbe dovuto.
Voglio darti gli esempi, perché sono impressionanti. Ecco cosa faceva il vecchio MySQL, quello permissivo. Se cercavi di mettere in una casella un testo troppo lungo per starci, non ti dava errore: lo tagliava, buttava via la parte in eccesso, e salvava il resto, in silenzio. Se cercavi di salvare una data impossibile, tipo il trentesimo di febbraio, non protestava: la trasformava in una data vuota, tutti zeri, e andava avanti. Se un calcolo produceva un numero troppo grande per la casella, lo tappava al massimo consentito, senza dirtelo. In ogni caso, i tuoi dati venivano alterati, silenziosamente, e tu non lo sapevi. Nessun avviso, nessun errore, nessun segnale luminoso: solo un dato diverso da quello che credevi di aver salvato, nascosto tra milioni di altri, pronto a mordere molto più tardi.
Voglio dirti perché è così grave, perché non è un dettaglio tecnico. Il problema non è che i dati fossero rifiutati: è che venivano accettati sbagliati, senza un fiato. Un errore rumoroso è un fastidio, ma è onesto: ti fermi, guardi, correggi. Un errore silenzioso è un tradimento: tu credi che sia tutto a posto, il programma continua sereno, e intanto, nel profondo, la verità dei tuoi dati si sta sgretolando. Scoprirai il disastro mesi dopo, quando quel nome tagliato a metà, quella data azzerata, quel numero tappato, causeranno un problema di cui non capirai l'origine. Il silenzio, qui, non è gentilezza: è danno rimandato.
Voglio raccontarti la redenzione, perché è la parte importante. Ma la storia ha un lieto fine, ed è la vera lezione di questa puntata. MySQL ha introdotto quella che si chiama modalità rigorosa: un comportamento in cui, davanti a un dato sbagliato, si ferma e protesta, invece di aggiustarlo di nascosto. E, cosa fondamentale, col tempo l'ha resa il comportamento predefinito. Oggi il MySQL che ti ritrovi appena installato non ti tradisce più in silenzio: ti ferma, come dovrebbe. Ha rinunciato a un pezzo della sua vecchia arrendevolezza per guadagnare la fiducia che quella arrendevolezza gli aveva fatto perdere. È maturato, di nuovo. E lo ha fatto sapendo di rischiare: rendere il comportamento più severo significa che qualche programma vecchio, che si appoggiava alla vecchia arrendevolezza, smette di funzionare finché non lo sistemi. MySQL ha deciso che valeva la pena: meglio un fastidio oggi, alla luce del sole, che un tradimento domani, nel buio.
Voglio collegarlo alla rivale e a un tema di sempre, perché chiude il cerchio. Ricordi il guardiano della verità di cui parlammo per Postgres? Postgres era severo dall'inizio: rifiutava i dati sbagliati per principio, fin dal primo giorno. Era, se vuoi, meno comodo, ma più onesto. MySQL ci è arrivato dopo, imparando che la comodità che nasconde i problemi non è vera comodità. È lo stesso spirito di quando parlavamo di sicurezza: non fidarti ciecamente, verifica, e preferisci un no chiaro a un sì ingannevole. Un errore onesto vale più di un successo falso.
Voglio trarre la lezione generale, perché vale per tutto ciò che costruiamo. La lezione è che il silenzio non è sempre una virtù, e la permissività non è sempre gentilezza. Uno strumento che non ti contraddice mai, che accetta tutto quello che gli dai, sembra amichevole, ma ti sta lasciando sbagliare senza avvertirti. Gli strumenti migliori, come le persone migliori, sanno dirti di no quando serve. E vale anche per te che costruisci: quando scrivi qualcosa che altri useranno, chiediti se, davanti a un errore, è meglio proseguire in silenzio o fermarsi e parlare chiaro. Quasi sempre, parlare chiaro è il regalo più grande.
Per oggi ci fermiamo qui. Abbiamo raccontato il capitolo più onesto di MySQL: la permissività. Il pragmatismo, spinto troppo in là, diventava un difetto: il vecchio MySQL, pur di non fermarti, accettava dati sbagliati in silenzio, tagliava i testi troppo lunghi, azzerava le date impossibili, tappava i numeri troppo grandi, senza dire niente. E un errore silenzioso è peggio di uno rumoroso, perché è un tradimento rimandato. Poi la redenzione: la modalità rigorosa, che si ferma e protesta, resa il comportamento predefinito. Come il guardiano di Postgres, ma imparato dopo, per esperienza. La lezione: il silenzio non è gentilezza, e gli strumenti migliori sanno dire di no. Nella prossima puntata: facile da iniziare, ovunque tu guardi, l'ubiquità. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.