Diciassette giorni fa ho fatto il primo commit di PDF Side Viewer. Oggi il programma è alla 0.9.0, sono circa quattordicimila e ottocento righe di C++ divise in trentanove file, e da stamattina sa mostrare tre documenti affiancati invece di due.

La domanda che mi farei se leggessi questo post da fuori è perché mai, nel 2026, uno si metta a scrivere un’applicazione desktop in Win32 puro con Direct2D per il disegno, C++20 e la libreria di rendering PDF compilata dentro l’eseguibile. Non c’è un framework, non c’è un runtime da installare, non c’è uno strato web da nessuna parte.

Scrivere trecento pagine di matematica da solo pone un problema pratico: chi rilegge. Non ho un editor, non ho un correttore di bozze, e i miei capitoli sono lunghi abbastanza da esaurire la pazienza di chiunque glieli chieda per cortesia.

La risposta ovvia, oggi, è far rileggere il testo a un modello. La risposta ovvia, però, funziona male, e vale la pena spiegare perché. Se chiedo un parere sul capitolo allo stesso assistente con cui l’ho scritto, ottengo quasi sempre una delle due patologie: il timbro di approvazione, perché il testo è già passato dalla sua idea di buono, oppure una lista di problemi inventati, perché gli ho chiesto di trovarne e lui è servizievole. In tutti e due i casi ho perso un’ora e non ho imparato niente sul capitolo.

Il primo tentativo l’ho fatto come lo farebbe chiunque: prendo la posizione della barra di scorrimento di sinistra, la copio in quella di destra, fine. Ha funzionato per una decina di minuti, cioè finché ho provato con due documenti davvero diversi.

Il problema è che la posizione di scorrimento non è una posizione nel documento. È una misura in pixel che dipende dal fattore di zoom, dall’altezza della finestra e dalle dimensioni fisiche delle pagine. Due edizioni dello stesso libro con formati pagina diversi hanno altezze totali diverse, quindi la stessa percentuale di scorrimento cade in due punti diversi del testo. E la deriva non è costante: cresce man mano che scendi, che è il modo peggiore in cui un difetto possa comportarsi, perché all’inizio sembra tutto a posto.

Il libro esiste in italiano, in inglese e in ungherese. L’edizione italiana è quella pubblicata, l’inglese è arrivata in fondo alla revisione di stile, l’ungherese è tradotta per intero e revisionata fino a metà. Vengono dallo stesso impianto, ma non sono lo stesso libro, e la differenza non sta nelle frasi.

La cosa che ho imparato per prima è che di un manuale tecnico non traduci il testo. Traduci le convenzioni.

Mi serviva una cosa sola: tenere aperti due PDF affiancati e farli scorrere insieme. L’edizione italiana del mio libro a sinistra, quella inglese a destra, e la possibilità di scendere lungo il testo senza perdere l’allineamento.

Sembra una funzione che esiste da sempre. Non esiste.

Ho passato una sera a cercarla come si cerca una libreria prima di riscriversela, cioè con l’aspettativa di trovarla e la fretta di tornare al lavoro vero. Il primo posto dove ho guardato è il visualizzatore che uso tutti i giorni, SumatraPDF, che è veloce, leggero e scritto bene. La vista affiancata è stata chiesta lì per la prima volta nel 2011, e poi di nuovo, e poi ancora, in tre richieste distinte nell’arco di dieci anni. Sono state tutte respinte, e la posizione del manutentore è coerente e legittima: quel programma vuole restare quello che è.

Sono iscritto all’università telematica con una formula che si chiama all inclusive: incluso nella retta c’è la possibilità di sostenere cinque esami per sessione. Le sessioni sono quattro in un anno accademico, quindi venti tentativi d’esame in dodici mesi. I tentativi non si accumulano: quelli che non usi entro la sessione sono persi. Viene quindi spontaneo chiamare “sprecato” un esame che non hai dato… e questo dovrebbe già bastare come indizio su che genere di prodotto sia.

Quando dico che sto scrivendo un libro, chi mi ascolta immagina un documento. Nella mia testa invece c’è un repository con dei profili di build, e il PDF non è il libro: è l’artefatto che esce quando il libro compila.

La differenza si vede subito nella regola più rigida che ho: non lancio mai il compilatore a mano. Passo sempre da latexmk con i profili che stanno versionati nel repo. Non è pedanteria, è che invocare il motore direttamente rompe la corrispondenza tra sorgente e PDF, e quella corrispondenza è ciò che mi permette di cliccare su una formula nel PDF e ritrovarmi sulla riga esatta del sorgente che l’ha prodotta. È esattamente la stessa ragione per cui in un progetto software non compili a mano un file per poi chiederti perché il debugger non trova più i simboli.

Nel repository del libro c’è un file che si chiama STILE.md ed è cresciuto fino a sessantasei kilobyte di sole regole di scrittura. Non contiene matematica. Contiene i divieti che mi sono imposto, e la parte più lunga è l’elenco delle parole che non ho il permesso di usare.

La prima riga della lista è “banale”. Poi vengono “ovvio”, “chiaramente”, “trivialmente” e la formula più insidiosa di tutte, “è facile vedere che”.

Sto studiando per un esame di ingegneria del software, per la laurea triennale in informatica, il che significa reimparare UML un’altra volta. Lo conosco da 25 anni e l’ho usato professionalmente per 15, da quando un mio vecchio datore di lavoro automotive mi mandò a un corso su Enterprise Architect.

Ricordo ancora chi ne era entusiasta: i formatori EA, il cui stipendio dipendeva da quanto io amassi lo strumento (o meglio, da quanto lo amasse il mio capo), e un tipo particolare di architetto: quelli promossi in silenzio lontano dal codice perché a programmare non erano granché, e che come architetti si rivelavano poi esattamente altrettanto bravi. UML dava loro qualcosa che la codebase non aveva mai concesso: un deliverable che nessuno poteva falsificare. Il codice viene testato. Il codice va in produzione oppure no. Un diagramma se ne sta lì, con l’aria di essere lavoro.

Ho scritto un libro di matematica. Si chiama Fondamenti di matematica per studenti di informatica, sono 316 pagine, quindici capitoli, novantotto esercizi e cinquantotto figure, e in copertina c’è una riga che riassume tutto il progetto meglio di quanto sappia fare io: scritto da un informatico, per informatici.

Non era il piano. Il piano era dare tre esami.

A diciannove anni la matematica del primo anno di ingegneria mi aveva fatto mollare tutto, e quando sono tornato a studiare me la sono ritrovata davanti identica: Analisi, Algebra, Calcolo delle probabilità. La differenza è che a venti e passa anni di distanza avevo un metodo, cioè la stessa cosa che faccio al lavoro quando un sistema non mi entra in testa: lo riscrivo. Ho cominciato a rimettere in ordine per iscritto ogni argomento che studiavo, in LaTeX, perché la matematica scritta a mano non si rifattorizza.