Il builtin @xkcdRandom per Zig restituisce sempre il numero 4

Un incidente di sicurezza citato dall’autore fa da miccia: in un sistema reale qualcuno ha usato valori fissi, tra cui 4, al posto di byte casuali generati correttamente. Da qui la provocazione: un builtin per Zig che rende esplicita quella cattiva pratica, in forma di gag tecnica chiamata @xkcdRandom¹.

Il riferimento è il fumetto “Random Number” di xkcd. Lì una funzione C, spacciata per generatore casuale, stampa sempre lo stesso risultato. L’autore collega la vignetta a quell’errore in produzione e commenta: “la satira tende a diventare realtà”¹.

La proposta arriva con tono secco. “Esiste una chiara domanda tra gli sviluppatori per il generatore xkcd”, si legge nel post. Se c’è domanda, i linguaggi dovrebbero offrire un’implementazione integrata. Per “dare l’esempio”, l’autore presenta @xkcdRandom per Zig. Chiede al lettore di indovinarne il comportamento, poi rivela l’ovvio. La funzione restituisce sempre 4. Chiude con una battuta che fa il paio: “Ora andate a fondare una startup da miliardi di dollari su questa idea geniale”¹.

Il post non si limita alla punchline. Racconta il percorso che conduce alla prova. Dopo avere completato gli esercizi di Ziglings e avere “programmato mentalmente” un minesweeper, l’autore cerca un’occasione per entrare in contatto con codice Zig “da produzione”. Vuole capire come si incastrano i pezzi del linguaggio. Sceglie quindi un target minimo, ma reale: un builtin. Così può toccare API, naming, integrazione con il compilatore e cicli di build, senza perdersi in un progetto grande¹.

La chiave sta nella frizione tra cultura pop tecnica e prassi di sviluppo. Il nome viene da xkcd, l’ispirazione da un errore capitato davvero, l’esecuzione da un esercizio controllato sul linguaggio. L’oggetto è elementare e dichiarato, non promette entropia né tenta di imitarla. Serve da dimostrazione esplicita. E da promemoria su come l’ironia, quando entra nel codice, può scoprire abitudini pericolose che le procedure dovrebbero intercettare¹.

Nelle parole dell’autore non c’è ambiguità: non si tratta di un’alternativa a una sorgente di casualità. È un costrutto deliberato, costruito per mostrare cosa succede quando si confonde comodità e sicurezza. La battuta funziona perché poggia su un caso concreto, non su un paradosso astratto¹.

Per chi scrive Zig, la lezione è pratica: un nome chiaro e una semantica trasparente evitano fraintendimenti, anche quando si gioca. Per chi fa revisione del codice, un esperimento del genere può aiutare a riconoscere subito le scorciatoie travestite da “random”. Se salta fuori un 4 dove servono byte imprevedibili, non è un incidente buffo. È un bug che ha già avuto precedenti, come ricorda il post¹.