R on Melabit

Swift contro Python, ovvero mele contro pere

Mon, 03 Oct 2022 06:00:00 +0000

– Fonte: Martina Leuderalbert su Unsplash.

Alle elementari la maestra mi aveva insegnato a non sommare le mele con le pere, cioè a non mettere insieme (o paragonare) cose e fatti molto diversi fra loro. Non ha quindi senso sommare 3 litri di acqua con 5 chilogrammi di farina o chiedersi se 40 metri sono più o meglio di 20 secondi.

Quello che diceva la mia maestra lo dicono, sono sicuro, le maestre di tutto il mondo, ma c’è sempre qualcuno assente a queste lezioni.

Il Golia della programmazione moderna

Uno di questi è stato di sicuro Ari Joury che, nonostante il suo dottorato in fisica delle particelle, non si è fatto scrupoli a pubblicare su Medium questo Swift was poised to replace Python. Then it tanked.

Cosa dice l’articolo? Che nel mondo del machine learning i linguaggi di programmazione più usati sono Matlab, R, Julia e soprattutto Python. Quest’ultimo, nato originariamente per sviluppare dei piccoli script senza troppe pretese, è diventato oggi un vero “Golia della programmazione moderna”, tanto da essere usato estensivamente da aziende come Dropbox, Instagram e Pinterest per i loro servizi online.

Grazie alla disponibilità di librerie come TensorFlow o PyTorch (nonché, aggiungo io, di librerie di base come Pandas o NumPy), Python è diventato anche il linguaggio di elezione di chi si occupa di machine learning e di analisi dei dati.

La crescita di Python sembra bloccata da un paio di anni, ma la sua enorme diffusione lo farà rimanere comunque un attore centrale anche nel prossimo futuro.

Entra in scena Swift

Fin qui tutto vero e condivisibile. Magari si potrebbe eccepire qualcosina sull’importanza di R nell’ambito dell’analisi dei dati, ma non voglio essere puntiglioso.

Il guaio è che se uno si limita a scrivere queste cose non se lo fila nessuno, chi vorrà mai leggere l’ennesimo articolo generico sulle virtù di Python per il machine learning (e non) o su quale linguaggio è destinato a soppiantarlo?¹ Ci vuole un colpo d’ala.

Per fortuna c’è sempre Apple che, come il nero, va bene su tutto e, soprattutto, garantisce sempre un bel po’ di click. E allora perché non mettere in mezzo Swift?

Swift è un linguaggio di programmazione sviluppato da Apple con l’obiettivo specifico di sostituire Objective-C come linguaggio di elezione per lo sviluppo delle applicazioni per iOS e per macOS. Swift è facile da imparare e la sua sintassi leggibile ricalca quella di Python, è vero, così come quella di Julia e di tanti altri linguaggi di programmazione moderni.²

Swift però non ha mai preteso di essere, come sostiene il nostro Ari, il nuovo “Re della Programmazione”. Ad Apple non interessa posizionare Swift come uno strumento di programmazione general purpose, le interessa solo che venga usato per programmare le applicazioni per i suoi sistemi operativi. Del resto, il fatto che manchi di una versione per Windows taglia fuori una fetta così importante di potenziali utenti da rendere impossibile a priori una pretesa tanto assurda.

A maggior ragione Swift non ha mai preteso di essere il nuovo strumento principe per il machine learning, come il buon Ari sotto sotto ci vuole far intendere. È vero che Google ha provato a supportare Swift all’interno di TensorFlow (di cui Google è il principale sviluppatore), ma questo esperimento, come succede con tanti altri prodotti dell’azienda di Mountain View, è stato interrotto nel 2021. È ragionevole pensare, infatti, che chi sviluppa in Swift preferisce usare gli strumenti per il machine learning integrati in macOS/iOS piuttosto che prodotti di terze parti.

Io sono più popolare di te

Ma la cosa più sconcertante è pretendere di confrontare la popolarità (o meno) dei linguaggi di programmazione utilizzando una metrica fasulla come la percentuale di domande poste ogni mese su StackOverflow relativamente ad uno o ad un altro linguaggio. In base a questa percentuale, la popolarità di Python è cresciuta costantemente fino alla fine del 2020, per poi stabilizzarsi al 16% del totale delle domande su StackOverflow, mentre quella di Swift dopo aver raggiunto un massimo del 3% è in declino e ora si aggira nei dintorni dell'1.5%.

Perché è una metrica fasulla? Perché finché siamo sui grandi numeri e confrontiamo la popolarità di Python con quella di JavaScript può anche avere senso basarsi sul numero di domande poste su StackOverflow per valutarne la diffusione.

Ma se buttiamo nel calderone anche la terna HTML, CSS e PHP, che sono ancora oggi tre strumenti fondamentali per chi fa sviluppo web, troviamo che questi ultimi sono in costante declino, senza però che la decadenza (su StackOverflow) di PHP venga compensata da un incremento corrispondente nell’interesse verso JavaScript.

Anche Wordpress, che piaccia o non piaccia sta dietro il 40% dei siti web, secondo la metrica di StackOverflow sarebbe in calo. Idem per MySQL.

E allora la spiegazione può essere un’altra: più che la diffusione, le domande su StackOverflow ci fanno vedere la complessità del linguaggio e la qualità della sua documentazione: HTML, CSS e PHP (o Wordpress e MySQL) sono prodotti ben assestati, per loro esistono ottime guide sul web che ne spiegano diffusamente i segreti. Di conseguenza non è necessario cercare risposte più o meno occasionali su StackOverflow, e comunque quelle che ci sono già bastano ed avanzano.

Python e JavaScript, al contrario, hanno una sintassi di base piuttosto semplice ma per essere usati al meglio hanno bisogno di un gran numero di librerie aggiuntive, che sono spesso più complesse del linguaggio base e che vengono aggiornate ed espanse di continuo. La documentazione relativa non tiene sempre il passo dello sviluppo, per cui il modo migliore per imparare ad usare al meglio le centinaia e centinaia di API disponibili è quello di rivolgersi a qualche esperto su StackOverflow, spingendo così in alto la popolarità dei due linguaggi.³

Secondo la logica basata sul numero di domande su StackOverflow anche C e C++, i linguaggi usati per la programmazione di sistema (e non) su Linux e Windows, sarebbero in declino, e lo stesso succede a concetti di base come algoritmo, architettura, classe o database. Ma sono in declino perché c’è davvero poco interesse o solo perché anche per loro c’è abbondanza di documentazione di ottimo livello, senza doversi ridurre a porre sempre delle nuove domande su StackOverflow?

Nel mio piccolo lo faccio anch'io: quando programmo in R uso pochissimo StackOverflow, perché posso usare l'ottimo help in linea di RStudio e perché la documentazione che accompagna le librerie aggiuntive di R è centralizzata sul [CRAN](https://cran.r-project.org/) (_The Comprehensive R Archive Network_) ed è di altissima qualità. E quando tutto questo non basta, posso trovare decine di siti e di blog che spiegano benissimo gli aspetti più ostici del linguaggio. Quando passo a Python (un linguaggio che, sia chiaro, mi piace parecchio), StackOverflow diventa quasi una necessità, perché la frammentazione e la mancanza di sistema di gestione centralizzata delle librerie di Python rendono molto più complicato trovare documentazione aggiornata di qualità.

Decaduto o semplice?

Swift è un linguaggio semplice con una ottima documentazione ufficiale, un eccellente strumento di apprendimento del linguaggio (e non solo) come Swift Playgrounds e un numero relativemente ridotto di librerie aggiuntive, c’è davvero bisogno di passare un sacco di tempo su StackOverflow per usarlo al meglio?

Guardando il grafico relativo al numero di domande relative a Swift ci si accorge che i picchi di interesse corrispondono alle date di presentazione della versione 1.0 (giugno 2014) e al rilascio delle versioni 2.0 (settembre 2015), 3.0 (settembre 2016) e 5.0 (marzo 2019) e, come è naturale, dopo ogni presentazione l’interesse tende a decadere, proprio perché per usare il linguaggio c’è davvero poco da chiedere su StackOverflow.

A supporto di questa tesi c’è il risultato di questa semplice query SQL, con la quale ho provato a calcolare il numero di domande poste su StackOverflow ogni anno. Di SQL ne so pochissimo per cui dovete prendere i risultati con le pinze, ma sembra che il numero di domande su StackOverflow sia in progressiva diminuzione, da un massimo di 2.2 milioni di domande nel 2016 a 1.6 milioni nel 2021.

Una volta raggiunta una base di conoscenza sufficientemente ampia non ha molto senso porre sempre delle nuove domande (che su StackOverflow sono fortemente scoraggiate) ma ci si può limitare ad utilizzare il materiale già esistente. Questo almeno per le tecnologie più stabili, come possono essere HTML, CCS, PHP, Wordpress, MySQL… oppure Swift. Quando invece abbiamo a che fare con strumenti in rapidissima evoluzione, come Python o JavaScript, StackOverflow diventa davvero il modo migliore per imparare.

Conclusioni

C’è bisogno di dilungarsi ancora? Non credo, dico solo che basarsi su ipotesi fantasiose o metriche poco affidabili per ipotizzare scenari catastrofici per Swift (o, al contrario, scenari entusiasmanti per Julia⁴) mi pare francamente insensato.

– Fonte: Dilbert di Scott Adams.

Capo: Non si possono confrontare mele e arance.

Dilbert: È chiaramente sbagliato, perché li hai appena confrontati e dichiarati diversi.

Wally: Mele e arance sono entrambi alimenti che crescono sugli alberi. Sarebbe assolutamente valido confrontarli dal punto di vista nutrizionale.

Dilbert: Ho notato che molte delle cose che escono dalla tua bocca non hanno senso.

Capo: Parli come mia moglie.

Wally: Non puoi paragonare tua moglie al tuo subordinato. Sono mele e arance.

Capo: Cosa sta succedendo qui?

Wally: Non lo so, ma non lo paragonerei a lavoro.

Ari sembra avere le idee un po’ confuse sul futuro di Python, dato che su Medium ha anche pubblicato Why Python is not the programming language of the future, oppure Bye-bye Python. Hello Julia! e perfino Why TensorFlow for Python is dying a slow death. ↩︎
E non è un caso, perché alla base di tutti questi linguaggi c’è sempre il buon vecchio BASIC, il primo linguaggio di programmazione davvero per tutti, che è stato il linguaggio di base dei computer personali degli anni ‘80 su cui si sono fatti le ossa tutti i grandi nomi dell’informatica di quegli anni. ↩︎
Le sole domande sulla libreria pandas di Python (una libreria fondamentale per chi usa Python per l’analisi dei dati) assommano al 3% del totale, le principali librerie per il machine learning (TensorFlow, Keras, PyTorch, scikit-learn, OpenCV, NLTK) fanno un altro 2%, mentre quelle su Django e Flask (le principali librerie Python per lo sviluppo di applicazioni per il web) sono quasi al 2.5% del totale generale. Chiaramente queste domande vengono anche conteggiate come domande relative a Python. ↩︎
Perché sì, l’interesse per Julia sembra essere in aumento su StackOverflow, ma parliamo di non più dello 0.16% (1/10 dei valori di Swift) e anche in questo caso i picchi corrispondono al rilascio delle varie versioni del linguaggio. ↩︎

Il CNR è anche questo: un po' di codice

Tue, 01 Dec 2020 06:00:00 +0000

XKCD, Good code.

Per concludere nel miglior modo possibile questa serie di articoli (qui la prima e la seconda parte), cosa ci può essere di meglio di un po’ di codice?

Estrarre il testo da un file PDF

Cominciamo dallo script in R, pdf2csv.R, che estrae il testo da un file PDF, (che in questo caso specifico ho usato per estrarre i dati dalla domanda di partecipazione ad un concorso precedente). Qui sotto trovate l’immagine dello script, realizzata con Carbon (perché così è molto più bello), su GitHub c’è il sorgente vero e proprio, per chi voglia provare ad usarlo.

Per eseguire lo script è necessario aver installato sul proprio computer, non importa se è un Mac o un PC con Linux o Windows, l’ambiente R (in questo momento è disponibile la versione 4.0.3), meglio ancora se accompagnato da RStudio Desktop, che è di gran lunga il migliore sistema integrato di sviluppo (IDE) che abbia mai usato, oltre che uno strumento efficacissimo per affacciarsi all’uso di R.

Il codice è molto semplificato, ho tolto tutto ciò che non è strettamente necessario a far funzionare lo script. La chiave di tutto è la libreria pdftools per R. Di librerie per estrarre dati dai file PDF ne ho provate moltissime, sia per R che per Python, ma pdftools le batte tutte per potenza, semplicità e velocità. Ci sono dei tool che convertono un PDF in testo al ritmo di una pagina al minuto, pdftools riesce a convertire (molto bene, peraltro) un file di 400 pagine come questo in appena 5-6 secondi. C’è altro da aggiungere?

Lo script può essere utilizzato dalla linea di comando (per capirci, dal Terminale), lasciandolo esattamente com’è ed eseguendo il comando pdf2csv.R seguito dal nome dal file da convertire (se il nome del file contiene degli spazi va scritto fra virgolette),

	./pdf2csv.R file-da-convertire.pdf

che produrrà due file .csv contenenti il testo estratto dal file PDF. Il primo, con lo stesso nome del file di partenza, ha le righe numerate e cerca di riprodurre per quanto è possibile il layout del file originale. Nel secondo, salvato con il suffisso -clean, mancano i numeri di linea e vengono rimossi tutti gli spazi in eccesso, rendendolo più adatto ad una analisi automatica, in particolare quando il testo si estende per tutta la pagina (il primo file, invece, è molto più utile quando il testo è organizzato in colonne).

Prima di usare per la prima volta pdf2csv.R bisogna renderlo eseguibile tramite il comando chmod (ne ho già scritto diffusamente qui).

	chmod u+x pdf2csv.R

In alternativa si può lanciare lo script tramite il comando Rscript installato con R, senza che sia necessario renderlo eseguibile.

	Rscript ./pdf2csv.R file-da-convertire.pdf

È preferibile che il file PDF da convertire si trovi nella stessa cartella di pdf2csv.R. In caso contrario il testo estratto viene comunque salvato nella cartella dove si trova la script (ve l’avevo detto che lo script era molto semplificato!).

Per eseguire pdf2csv.R all’interno di RStudio bisogna commentare la linea 12 (basta aggiungere un # all’inizio della riga) e attivare la riga 14 o 15 (ma solo da una delle due) togliendo il # iniziale. Se si attiva la riga 14, si deve anche modificare la stringa file-da-convertire.pdf, sostituendola con il nome del file da convertire. Se invece si attiva la riga numero 15, al momento dell’esecuzione dello script comparirà una finestra grafica da cui selezionare il file PDF desiderato.

Nel repository su GitHub di questo articolo ho inserito dei file PDF di complessità crescente con cui fare qualche prova, fra cui un documento di quasi 1000 pagine (un vecchio manuale di riferimento del formato PDF, potevo scegliere qualcosa di diverso?), che può essere utile per valutare la velocità di conversione dello script. Non è necessario farlo a mano, il tempo di esecuzione di un qualunque programma o script si può misurare in modo preciso dal Terminale anteponendo il comando di sistema time, come mostrato qui sotto.¹

	time ./pdf2csv.R PDFReference.pdf

Come piccola chicca finale, ho aggiunto al repository su GitHub un file PDF contenente del testo (apparentemente) nascosto, provate a convertirlo e vi accorgerete di quanto sia banale recuperare il testo completo.

Generare automaticamente dei documenti con AWK

Tirar fuori il testo contenuto in un file PDF è quasi sempre solo il primo passo del lavoro, perché quello che vogliamo veramente è filtrare il contenuto del documento mantenendo solo le informazioni che ci interessano. Nel caso specifico, io avevo bisogno di selezionare dalla domanda di concorso precedente solo i dati relativi ad una specifica tipologia di attività (ad esempio tutti gli articoli scientifici pubblicati), salvandoli in un file ad hoc. E, già che c’ero, volevo anche costruire una tabella LaTeX per ciascun articolo. Una cosa abbastanza facile da fare con AWK.

Di AWK ho già parlato tempo fa e non mi ripeterò, dirò solo che è un linguaggio ideale per analizzare un file di testo una riga alla volta, verificando se si presentano determinate condizioni ed eseguendo le operazioni programmate corrispondenti.

Nonostante i suoi tanti pregi, AWK ha una limitazione piuttosto seria: per come è strutturato, AWK deve per forza di cose esaminare tutto il file senza poter tornare indietro, e quindi è piuttosto difficile fargli eseguire delle operazioni basate su condizioni multiple complesse. È molto meglio (quando è possibile) scrivere più script AWK, da eseguire in sequenza sullo stesso file di partenza o sull’output generato dallo script precedente, piuttosto che cercare di combattere con le limitazioni del linguaggio, complicando a dismisura il codice.

In una prima versione di questo articolo avevo pensato di utilizzare un breve estratto della mia domanda di concorso precedente per descrivere il funzionamento degli script in AWK. Ma mentre scrivevo mi sono accorto che il discorso sarebbe stato così specifico da essere quasi inutile. Ho preferito quindi preparare un piccolo file PDF tratto dagli ultimi post pubblicati su Melabit, con l’intestazione in YAML² di ciascun post seguita dalla prima frase del testo in Markdown e, quando c’è, dal link all’immagine iniziale. L’ho scelto perché la struttura di questo file assomiglia moltissimo a quella della mia domanda di concorso ma, allo stesso tempo, può essere uno schema di partenza applicabile a casi più generali.

Questo file PDF può essere considerato come la stampa di un piccolo _database_ di informazioni correlate, dove ogni post è un _record_, suddiviso a sua volta nei vari _campi_, rappresentati dalle righe di intestazione e dalla frase di testo.

Il file PDF si chiama Melabit ultimi post.pdf e, come gli altri file PDF, è disponibile nel repository su GitHub di questo articolo. Se lo aprite con Anteprima, noterete subito che ci sono delle righe vuote che separano chiaramente un post (nel linguaggio dei database, un record) dall’altro. Ma convertendo il file in testo,

	./pdf2csv.R "Melabit ultimi post.pdf"

(le virgolette sono necessarie perché il nome del file contiene degli spazi), le righe vuote scompaiono e le uniche interruzioni presenti nei due file CSV prodotti dallo script di conversione corrispondono al cambio pagina. Non so se questo sia un baco o una caratteristica voluta di pdftools, ma sta di fatto che è una particolarità con la quale dobbiamo fare i conti se vogliamo analizzare il testo con AWK.

Sembra una sciocchezza, ma senza le giuste interruzioni non è immediato riconoscere la fine di un record prima di iniziare ad esaminare quello successivo, in modo da chiudere correttamente la tabella LaTeX corrispondente al record appena esaminato e ad aprire quella relativa al record successivo. Inoltre, mentre in questo caso specifico la struttura del file PDF è volutamente molto semplice e ripetibile, nella maggior parte dei casi reali il documento da cui estrarre i dati può contenere informazioni strutturate in modi diversi, i campi da analizzare possono essere distribuiti in modo irregolare o mancare del tutto e ci possono essere incongruenze nella loro denominazione. Gestire tutti i casi possibili con un unico script lo renderebbe rapidamente troppo complesso.

Molto meglio affrontare il problema un pezzetto alla volta, utilizzando uno script specifico per ciascun tipo di informazione da estrarre (io ho avuto bisogno di 6 script AWK per eseguire tutto il lavoro di esportazione dei dati, o meglio quasi tutto il lavoro, perché per i casi meno frequenti ho preferito il buon vecchio copia-incolla manuale). In fondo è la stessa logica di Unix, che mette a disposizione un gran numero di strumenti semplici che messi insieme, come tanti mattoncini Lego, riescono a fare cose incredibili.

Un primo script, addblanklines.awk, può servire per inserire nel file CSV di partenza una riga vuota prima di ogni record (una cosa piuttosto semplice da fare in questo caso, dato che ogni post inizia sempre con la stringa “layout: post”). Lo script, appena quindici linee di codice, lo trovate “in bella” nell’immagine qui sotto (ma anche in questo caso il sorgente è su GitHub).

Bastano solo due linee di codice, la #4 e la #9, per aggiungere le righe vuote al posto giusto. Ma già che ci siamo, è conveniente dare anche una ripulita al file CSV togliendo le righe inutili, come quelle che contengono il numero di pagina o la stringa --- che segna l’inizio e la fine dell’intestazione in YAML (linee #5 e #12). Eseguendo lo script sul file CSV originale, si ottiene un nuovo file CSV con i vari record ben separati uno dall’altro.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv

Fatto questo, il passo successivo è semplice. Basta scansionare il file CSV appena generato, file-con-righe-vuote.csv, in cerca della stringa target layout: post e, ogni volta che se ne trova una, generare una nuova tabella LaTeX riempiendola con i dati tratti dalle voci (o più propriamente campi) successive. Il codice del secondo script, cvs2table.awk, è visibile nell’immagine qui sotto (mentre il sorgente è sempre su GitHub).

Lo script è relativamente lungo, sono più di 80 linee di codice, compresi commenti e righe vuote, ma una gran parte serve per implementare la funzione (linee #3-25) che riarrangia le informazioni presenti su più linee consecutive del file CSV in modo che vengano stampate su un’unica riga, e per generare la struttura di base del documento LaTeX (linee #35-42 e #83).

Tolte queste, il resto del codice è semplice, si tratta più che altro di scrivere le stringe giuste al momento giusto e di tenere conto dei casi in cui le informazioni si estendono su più linee consecutive (come succede ad esempio alle linee #61-62 e #66-73). Non entrerò nei dettagli di come funziona lo script, questo non è un corso di AWK (né tantomeno di R), basterà per ora dire che è scritto in modo da essere facilmente adattato a gestire esigenze analoghe. Per usarlo, si deve eseguire lo script usando come file di input file-con-righe-vuote.csv e salvando il risultato dell’elaborazione in un file LaTeX, che qui sotto ho chiamato (con la mia solita scarsa fantasia) lista-articoli.tex.

	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Mettere tutto insieme

Proviamo allora ad eseguire tutti insieme gli script presentati in questo articolo, in modo da ottenere il risultato finale desiderato. Dobbiamo prima di tutto convertire il file PDF in CSV con

	./pdf2csv.R "Melabit ultimi post.pdf"

che genera automaticamente il file “Melabit ultimi post-clean.csv”. Fatto questo, si eseguono in sequenza i due script AWK, salvando l’output del primo in un file intermedio.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv
	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Il risultato finale è un file LaTeX ben ordinato con una tabella per ogni articolo, come quello mostrato nella figura qui sotto la cui regolarità, messa in evidenza dai colori delle parole chiave, fa pensare ad uno spartito musicale.

Ma ha senso creare un file intermedio solo per trasferire l’output del primo script al secondo? Molto meglio usare il meccanismo di piping tipico in Unix, con il quale si può trasferire automaticamente il risultato dell’esecuzione di un comando all’ingresso di quello successivo, collegandoli con il carattere | (pipe)?³ Con il piping, i due comandi AWK precedenti possono essere eseguiti uno dopo l’altro in questo modo,

	./addblanklines.awk "Melabit ultimi post-clean.csv" | ./cvs2table.awk > lista-articoli.tex

evitando l’uso di un file intermedio. In questo caso non fa molta differenza, ma quando si devono trattare file molto grossi, il piping è molto più efficiente (con i velocissimi dischi SSD odierni non ce ne accorgiamo più, ma ai tempi dei dischi meccanici la scrittura di grossi file sul disco era un vero collo di bottiglia) e, cosa che non guasta mai, evita di intasare il disco rigido con un gran numero di file inutili.

E poi il piping è un meccanismo intrinsecamente elegante, che non a caso è stato adottato anche in alcuni linguaggi di programmazione odierni, come si può vedere nello script R mostrato nella prima parte di questo articolo (linee #24-25 e #35-37), dove il simbolo | usato in Unix è sostituito dalla strana combinazione di caratteri %>%, piuttosto fastidiosa da scrivere con una tastiera italiana (io almeno sbaglio sempre qualcosa).

Conclusioni

Chi ha l’occhio allenato si accorgerà facilmente che il file LaTeX risultante contiene alcuni errori piuttosto evidenti. Li ho lasciati apposta non solo per non complicare ulteriormente il codice, ma anche per mostrare quanto sia complicato il lavoro di estrazione automatica dei dati da file strutturati in modo non perfettamente regolare. Non è certo un caso che in questo campo ci sia una grossa attività di ricerca che prova a superare gli ostacoli e a rendere il tutto il più semplice e il più efficiente possibile.

Il comando time è presente di default nei sistemi operativi Unix come Linux e macOS. Su Windows time non esiste, ma si possono usare degli strumenti equivalenti. ↩︎
YAML è un linguaggio di markup particolarmente adatto per definire dei file di configurazione e, in generale, per rappresentare informazioni strutturate in modo semplice e leggibile, molto più facile da usare di strumenti più noti come XML e JSON. ↩︎
Il piping è uno dei meccanismi principali che rendono Unix una specie di Lego informatico. ↩︎

Il CNR è anche questo: concorsi in LaTeX

Sun, 08 Nov 2020 06:00:00 +0000

Nella puntata precedente ho raccontato della mia corsa contro il tempo dell’estate, una prova assurda come quelle di Giochi senza frontiere, ma senza allegria.

Inutile però dilungarsi ancora in dettagli poco comprensibili ai non addetti ai lavori. Meglio parlare invece di cosa ho fatto io per superare questa prova, cercando di sfruttare quel poco che so di LaTeX e di programmazione.

Perché, l’ho già detto ma mi ripeto, qualche nozione di programmazione può aiutare a cavarsela meglio con le tante rotture di cabasisi che dobbiamo affrontare ogni giorno.

Se c’è una cosa sulla quale sin dal primo momento non ho avuto il minimo dubbio, è che non avrei usato Word per preparare il curriculum professionale. Word non mi piace, si sa, ma in questa scelta non c’era nessuna prevenzione, era solo un modo per preservare la mia salute mentale.

Word ha grosse difficoltà a gestire strutture complesse come le tabelle. Una, due, tre, dieci tabelle vanno ancora bene, ma qui si trattava di creare centinaia e centinaia di tabelle diverse, una per ogni titolo – articolo, progetto, software, brevetto, insegnamento, incarico – inserito nel curriculum professionale. Dopo un po’ Word sarebbe letteralmente impazzito nel maneggiare tutte quelle tabelle, facendomi perdere un sacco di tempo prezioso.

Con LaTeX il problema non si pone. Un documento LaTeX è un normale file di testo e il fatto che contenga tabelle, liste o semplici paragrafi non fa molta differenza, sono solo delle porzioni di testo strutturate in modo diverso. Il peggio che può capitare è che il compilatore LaTeX impieghi qualche secondo in più a convertire il documento LaTeX in PDF.

Il fatto che i documenti LaTeX siano dei file di testo mi permetteva anche di generare automaticamente le tabelle relative a ciascun titolo inserito nel curriculum professionale, una cosa impossibile da fare con Word e che ha velocizzato moltissimo tutto il lavoro.

Già perché, non l’ho detto prima, il curriculum professionale andava sì scritto in Word, ma poi la sottomissione andava fatta in PDF,¹ utilizzando (ci credete?) la piattaforma online per i concorsi dismessa così improvvidamente. In pratica il modello in Word fornito dall’amministrazione serviva solo come indicazione di massima di come dovesse essere organizzato il curriculum, ma niente impediva di utilizzare altri strumenti. L’unica cosa davvero importante è che il layout del file PDF corrispondesse a quello previsto dall’amministrazione.

Riprodurre in LaTeX il modello originale in Word non è stato difficile: la classe memoir è molto flessibile ed è particolarmente adatta a produrre tutti quei documenti che escono dai canoni classici di LaTeX, mentre i package geometry, booktabs, multirow e titlesec permettono di regolare finemente i dettagli del documento finale.

Sia chiaro, preparare un modello di documento LaTeX partendo da zero non è mai facile, a meno di non essere dei veri esperti. Per fortuna avevo già fatto delle cose simili in passato e mi è bastato modificare qualche dettaglio per ottenere quello che mi serviva.²

Il modello LaTeX era però il problema minore, ciò che importava davvero era riuscire a riutilizzare il più possibile il lavoro fatto in passato. Come già detto nel post precedente, i soloni che ci governano non avevano previsto nessuna possibilità di esportare i dati già presenti sulla piattaforma online. L’unica possibilità era quella di partire dal curriculum in PDF preparato per un concorso precedente (del 2013, ben sette anni fa).

Per fortuna ho una certa esperienza nell’estrazione di dati dai documenti PDF, un problema molto attuale dato che tante istituzioni, non solo nazionali ma anche internazionali, sono molto restie a condividere i loro dati in formati standard utilizzabili da chi, come me, si occupa di estrarre informazioni dalle serie temporali di misure. Quando va bene il meglio che si riesce ad ottenere sono dei file PDF contenenti delle tabelle mal strutturate, che bisogna ingegnarsi a convertire in formati usabili per le analisi. Mi è bastato quindi adattare uno script in R sviluppato per altri scopi per riuscire a convertire la domanda in PDF in un file CSV ben ordinato.

Partendo dal file CSV e con qualche semplice script in AWK (un’altro tool di base di cui non potrei mai fare a meno) è stato quasi un gioco da ragazzi estrarre i dati relativi ai titoli già presentati in quel concorso, salvandoli in file differenti in base alla tipologia in modo che poi fosse più semplice aggiungere uno ad uno i titoli mancanti (dal 2013 ad oggi ce ne sono state di novità!). Il modello LaTeX si occupava poi di importare questi file nella sequenza corretta producendo il curriculum completo.

Già che c’ero, con gli stessi script potevo anche costruire automaticamente le tabelle LaTeX dove incasellare ciascun titolo. È una cosa più difficile da spiegare che da fare, ma che ha rappresentato un vantaggio incomparabile rispetto a creare le tabelle una ad una con Word.

Devo ammettere che gli script AWK non erano perfetti, purtroppo me ne sono accorto solo dopo aver iniziato il lavoro di inserimento dei nuovi titoli. Ma dato che questi script mi servivano solo una volta, ho preferito correggere a mano gli errori piuttosto che perdere altro tempo a perfezionarli.

Lavorare con file diversi per ciascuna tipologia (o fattispecie, il termine preferito dai nostri vertici amministrativi) aveva un altro grosso vantaggio. Avendo separato il modello LaTeX, che gestiva l’aspetto generale del curriculum professionale, dai dati riportati nei diversi file, potevo velocizzare parecchio la fase di (diciamo così) debugging del documento finale. In altre parole, se lavoravo sugli articoli scientifici scritti nel corso della mia carriera, potevo importare nel modello generale LaTeX solo il file relativo, lasciando fuori tutto ciò che riguardava le altre attività svolte. Analogamente per le altre tipologie di documenti. Sembra una cosa da niente, ma quando si passano le giornate ad inserire i dati di decine di nuovi documenti, avere a disposizione un file PDF più snello e poter controllare più rapidamente di non aver fatto errori e di non aver dimenticato niente può davvero fare la differenza.

Un altro aspetto chiave dell’usare LaTeX al posto di Word è stato il fatto di poter numerare a piacere le singole tabelle. Su questo la confusione era massima. Il principio generale era chiaro, i vari titoli delle Categorie A e B andavano inseriti rispettando un ordine temporale inverso, dal più recente al più vecchio, assegnando un numero progressivo a ciascuna tabella. Quello che non era affatto chiaro era il come.

Modello di curriculum professionale: titoli della Categoria A.

Modello di curriculum professionale: titoli della Categoria B.

C’era chi affermava che si dovessero numerare progressivamente i documenti della Categoria A, gli ormai famosi Prodotti della Ricerca, indipendentemente dalla loro tipologia ma tendendo conto solo della data, ricominciando la numerazione dal principio una volta passati ai titoli della Categoria B, dove invece i titoli andavano raggruppati in base alla tipologia. Altri pensavano che fosse preferibile raggruppare tutti i titoli della Categoria A per tipologia (prima tutti gli articoli, poi i capitoli di libri e gli atti di congressi, poi i brevetti, e così via), ordinandoli dal più recente al più vecchio e numerandoli progressivamente, continuando la numerazione con gli stessi criteri una volta passati alla Categoria B. Altri volevano numerare anche le tipologie, un po’ come si fa con i capitoli di un libro tecnico. Insomma, ogni partecipante al concorso aveva la sua idea.

Come ha scritto qualcuno in un gruppo WhatsApp, “le migliori menti del Paese non riuscivano a interpretare le istruzioni del bando di concorso”. Non so se al CNR ci siano davvero le migliori menti del Paese, ma è evidente che tutta questa confusione derivava dalla difficoltà di interpretare un gergo burocratico astruso e inconsistente, incomprensibile per chi è abituato per professione ad essere preciso e rigoroso. A ciò si aggiungeva un motivo più banale, il timore di fare degli errori nella stesura del curriculum e di essere penalizzati per questo dalle commissioni di valutazione.

Io non avevo scelta. Avendo raggruppato tutti i miei titoli in file differenti in base alla tipologia e importando i file uno dopo l’altro nel modello generale LaTeX, non potevo fare altro che numerare tutti i titoli della stessa tipologia in base alla data (dal più recente al più vecchio), proseguendo la numerazione una volta passato ad un’altra tipologia e continuando a numerare progressivamente allo stesso modo anche i titoli della Categoria B.

Mi sembrava anche la cosa più logica da fare, perché questo ordinamento facilitava il lavoro della commissione, che così trovava raggruppati prima tutti gli articoli scientifici (che sono senza ombra di dubbio i titoli più importanti per un ricercatore), poi tutti i capitoli di libri o gli atti di congresso, poi i brevetti, e così via. Se l’ordinamento primario per tipologia era previsto esplicitamente per la Categoria B, perché non fare lo stesso anche per la Categoria A? Se poi alla commissione non piacerà, pazienza!

Inutile dire che ho usato git – il sistema di controllo delle versioni che è ormai uno standard di fatto nel mondo dello sviluppo – per gestire le revisioni di tutti i file che mi servivano per produrre il curriculum professionale finale: il modello generale in LaTeX, gli script in R e AWK e tutti i file CSV e LaTeX generati dagli script.

Con il sistema di controllo delle versioni potevo aggiornare i vari file LaTeX dei titoli sapendo di poter tornare indietro anche in caso di errori troppo gravi per essere recuperati a colpi di undo. Per fare un esempio, a un certo punto mi sono accorto che avrei dovuto scambiare due righe in tutte le tabelle del file relativo agli articoli (si veda la figura qui sotto). Con un buon editor di testo è una cosa che si fa in cinque minuti, ma sapere di poter usare git anche per annullare ogni singola modifica è una cosa che si apprezza solo dopo essersi spupazzati una ad una un migliaio di righe di codice LaTeX.

Interfaccia grafica di git con la quale è possibile accettare o annullare ogni singola modifica ad un file.

Git è troppo complicato? Può darsi, ma un sistema di controllo delle versioni è come un backup, finché va tutto bene non si capisce a cosa serva, ma quando si presenta un problema si ringrazia il cielo di averlo usato.

Guardando a ritroso mi accorgo che la preparazione di questo curriculum professionale è stata in parte un lavoro di programmazione, tutto sommato abbastanza divertente, seguita da una lunga e noiosissima fase di inserimento dei nuovi dati e di controllo che tutto fosse a posto, una cosa che sembrava non dovesse finire mai. Lavorando una decina di ore al giorno ho impiegato quasi un mese per completare il lavoro, un pelo in anticipo rispetto alla scadenza prevista. Uno spreco di tempo assurdo per quello che dovrebbe essere un evento normalissimo nella vita professionale di chi fa questo mestiere.

La versione finale del mio curriculum ha 248 pagine, un numero che per un matematico (o un programmatore) ha un certo significato.³ Chissà se la commissione che lo giudicherà sarà dello stesso avviso.

(Continua…)

Una cosa più che ragionevole, visto che un file PDF è molto più difficile da manipolare del corrispettivo in Word. ↩︎
Detto fra parentesi, se c’è interesse per l’argomento, potrei scrivere dei post specifici su LaTeX e dintorni, toccando non solo le basi ma anche argomenti più avanzati come questo. ↩︎
Ammetto che arrivare a 271 o a 314 pagine sarebbe stato meglio, ma ci proverò la prossima volta. ↩︎

Statististica con R ed RStudio

Wed, 20 May 2015 16:00:00 +0000

Da quasi un mese Packt sta offrendo ogni giorno gratis solo robetta quasi inutile. Non valeva nemmeno la pena menzionare la cosa in questo blog.

Oggi però Packt si riscatta con una vera prelibatezza, l’ebook Learning RStudio for R Statistical Computing di Mark van der Loo e Edwin de Jonge, che normalmente costa 17 euro, nemmeno tanto.

Non fatevi spaventare, R è un software utilissimo anche per chi non conosce la statistica ed RStudio è il miglior modo per usare R tramite una interfaccia semi-grafica potente ed efficace. Io ormai uso R ed RStudio ormai quasi ogni giorno, sono diventati rapidamente dei compagni di lavoro indispensabili.

Bisogna affrettarsi però. L’offerta scade all’una di questa notte, mancano solo poche ore.