Python on Melabit

Antigravity: l'LLM lo fa meglio

Mon, 16 Mar 2026 18:00:00 +0000

Nelle ultime settimane ho scritto delle mie esperienze con Antigravity, o meglio con gli agenti (più o meno) intelligenti integrati in questo editor. I risultati sono stati contrastanti: a volte gli agenti si sono dimostrati molto efficaci, alleviando con precisione alcuni compiti complessi o ripetitivi, in altri casi non hanno combinato niente di buono facendo solo perdere una montagna di tempo.

Programmare male con l’LLM

Fra tutti gli impieghi più o meno utili degli LLM, uno dei più controversi è l’idea che chiunque possa usare un LLM per programmare, anche quando di programmazione non se ne sa una cippa. È il cosidetto vibe coding, un concetto che si può riassumere così: “vedo cose, dico cose, copio e incollo cose, e nella maggior parte dei casi funziona”. Non è una citazione da Nanni Moretti, lo dice Andrej Karpathy, uno dei fondatori di OpenAI.

Ora, mettendo da parte le tante questioni relative alla sicurezza, alla manutenibilità di codice prodotto senza sapere bene cosa fa, alla deriva verso la media che implica che la qualità del codice prodotto dall’IA tenderà inevitabilmente a crollare, basta sperimentare un po’ in prima persona, anche con progetti semplici, per accorgersi che l’idea del coding per tutti non funziona, e che se vuoi ottenere qualcosa di buono dall’IA devi sapere bene cosa vuoi e come lo vuoi.

Ci ho provato io stesso a fare vibe coding: ho chiesto a Gemini di scrivere un driver per una videocamera Arducam, spiegandogli solo le cose indispensabili a aspettando che facesse tutto da solo.¹

Questo approccio però non ha funzionato. Ci sono volute ore ed ore di lavoro, di errori, di risposte inconcludenti, di correzioni e di consigli per raggiungere un risultato accettabile.

E questo solo perché a un certo punto ho buttato alle ortiche l’idea di far fare tutto a Gemini e gli ho dato dei consigli su come procedere. Senza quelli sarebbe stato solo un sacco di tempo buttato via inutilmente.

Anche Mimmo ha provato, in modo del tutto indipendente da me, a far scrivere a Lumo un programma in Micropython per gestire la mia Arducam Mini 5MP Plus con il Pico. E anche Lumo, che è senza dubbio uno dei migliori chatbot in circolazione, non ce l’ha fatta da solo.

– Immagine generata da Google Gemini.

Programmare meglio con lo stesso LLM

Tutto questo però non significa che un LLM non possa essere prezioso quando si programma, basta solo usarlo come si deve. Bisogna spiegargli per filo e per segno cosa deve fare, mettergli a disposizione tutto il materiale che gli serve per lavorare, e piazzargli dei paletti entro cui deve muoversi.

In poche parole, bisogna trattarlo come un tesista o una stagista, con poca esperienza ma tanta voglia di imparare.

Sono bastati infatti due prompt scritti con criterio, il primo che definiva la struttura delle directory del progetto e istruiva l’agente ad usare fin dall’inizio git per il controllo di versione del codice e uv per installare i pacchetti Python che gli sarebbero potuti servire,

Prompt

Start a new project and name it project13-pico-camera5mp-reprise.

Read the AGENTS.md file that defines your basic behaviour.

Create a new directory with this name and initialize an empty git repository using git init Use uv for managing Python packages. All the code must stay in the code directory, with no subdirectories within it. This project does not need a data directory and the output directory must be renamed as images.

e il secondo che conteneva tutto quello che mi è venuto in mente per aiutarlo a lavorare,

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html).

I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

The main documentation for the camera can be found at these links:

The code to drive this camera with the Pico is written in C (i.e., for Arduino) and CircuitPython, and can be found here: https://github.com/ArduCAM/PICO_SPI_CAM. You can download all the files you need from this repository. In particular, the files for CircuitPython are in the Python directory:

Arducam.py, which contains the functions to drive the camera,
OV5642_reg.py which, as far as I have understood, defines the resolutions allowed when taking pictures, and
boot.py , but I don’t know what it does. In the same directory there is also the script ArduCAM_Mini_5MP_Plus_VideoStreaming.py which sends the video captured by the camera to a Windows application and that is of no use here.

Please write a basic CircuitPython script that uses the functions defined in Arducam.py to test that the camera works and can take photos.

per permettere a Gemini 3 Flash di generare rapidamente uno script in CircuitPython che gira direttamente sul Pico e che fa tutto quello che gli è stato chiesto.

In verità, la primissima versione dello script non funzionava, ma è bastato a Gemini modificare una sola riga del driver Arducam.py fornito dal produttore per mettere tutto a posto (ha tolto uno zero al valore della frequenza).²

– La linea evidenziata in azzurro indica l’unica modifica effettuata da Gemini al file Arducam.py; a sinistra il file originale, a destra quello modificato da Gemini.

Tutti gli altri file forniti dal produttore sono rimasti intatti.

Alla prova dei fatti, il driver del produttore funzionava benissimo con il Pico e Gemini si è limitato ad imparare ad usarlo per scrivere lo script che cattura l’immagine direttamente dal microcontroller (una cosa che con un po’ di pazienza avrei potuto fare anch’io).

Guidare l’LLM o lasciarlo fare da solo?

La differenza rispetto al vibe coding della volta scorsa è abissale.

In quel caso Gemini aveva lavorato furiosamente per ore, combinando dei tali casini da costringermi a riavviare per ben due volte il Mac. E nel frattempo si era convinto (e mi aveva convinto) che il driver Arducam.py fosse incompatibile con Il Pico e l’aveva riscritto da zero, buttando via una libreria essenziale per interloquire con la videocamera (quella indicata dalla freccia rossa),

– Modifiche alle prime righe del file Arducam.py; a sinistra il file originale, a destra come appare lo stesso file dopo le modifiche di Gemini. La freccia indica una libreria importante che viene rimossa di peso da Gemini.

e togliendo senza nessun motivo, e senza nemmeno un guadagno reale in termini di efficienza o di funzionalità (anzi!), la maggior parte delle funzioni definite nello stesso file (si noti nell’immagine qui sotto la differenza nella lunghezza del codice originale, a sinistra, rispetto a quello modificato, a destra).

– Modifiche al file Arducam.py. I rettangoli rossi mettono in evidenza la differenza fra il numero di righe del codice originale (a sinistra) e di quello modificato da Gemini (a destra).

E non contento di tutto ciò, aveva pure stravolto il file OV5642_reg.py contenente i dati di configurazione della videocamera, adducendo dei presunti problemi di memoria. Problemi che evidentemente non esistevano, visto che in questo secondo esperimento tutto è filato liscio usando il file originale del produttore.

– Modifiche al file OV5642_reg.py, contenente i dati di configurazione della videocamera. La configurazione originale (a sinistra) è stata totalmente stravolta da Gemini (a destra).

E Arduino?

Arrivato a questo punto era inevitabile che chiedessi a Gemini di generare anche il driver per Arduino, usando le stesse informazioni che gli avevo già fornito per CircuitPython.

Questa volta Gemini ha penato di più, ma soprattutto perché gli avevo imposto di effettuare solo delle modifiche minime alle librerie originali Arducam. Un vincolo che questa volta era impossibile da soddisfare, perché queste librerie non supportano nativamente il Raspberry Pi Pico.

Risposta

Researching Arducam Library Compatibility I’ve thoroughly inspected both the original ArduCAM library and the Arducam_mini library. Neither version contains native support for the RP2040/RP2350 (Pico) architecture. Specifically, both libraries are missing the necessary definitions for regtype, regsize, cbi, and sbi for this platform, which is the root cause of the compilation errors.

Una volta allentato questo vincolo le cose sono filate lisce e in poco tempo anche il driver modificato ad hoc per il Pico ed il relativo programma di acquisizione delle immagini erano pronti.

Gratis o a pagamento?

C’è chi sostiene che i modelli a pagamento sono molto meglio di quelli gratuiti. Di conseguenza, i miei problemi con il vibe coding sarebbero scomparsi se avessi pagato per usare Gemini o Claude.

Non è proprio così. Nel corso delle prove ho usato prevalentemente la versione gratuita di Gemini, proprio per verificare cosa succedeva all’utente non professionale che voleva provare a giocare un po’ con questi strumenti. Ma quando finivano i token sono passato alla versione a pagamento di Gemini fornita dall’università, e non ho mai notato differenze significative. Su Claude non posso dire niente, perché dover pagare 200 dollari al mese per usarlo in modo serio non ha senso per chi, come il sottoscritto, non è un programmatore professionista.

Ho notato però che Claude Opus e Claude Sonnet si sono sempre dimostrati molto più bravi di Gemini a risolvere i problemi che si presentavano nel corso dello sviluppo del codice. Ma poiché li ho utilizzati sempre a lavoro inoltrato, potrebbero solo essere stati facilitati da quello che Gemini aveva già fatto.

Conclusioni

È inutile dire che sia questo esperimento che quello precedente non hanno nulla di scientifico. Per essere tale, dovrei almeno utilizzare tipi diversi di microcontroller e di moduli collegati, stabilire un set di prompt ben definito e misurare in qualche modo come cambia la risposta dell’agente di turno al variare delle condizioni sperimentali.

Ma nonostante questo, l’esperimento ha un pregio: è riproducibile. Chiunque, con una spesa ridotta, può provare a ripeterlo usando lo stesso hardware e gli stessi prompt, in modo do verificare di persona se quello che ho trovato io è corretto o no.³

Una cosa che gli apostoli del vibe coding da decine di milioni di letture evitano sempre accuratamente di proporre. I loro articoli sono pieni di certezze e di previsioni roboanti, ma mancano sempre di fornire il sia pur minimo appiglio che permetta di verificare i loro claim.

Nessuno, oggi, può ancora negare che gli LLM possano essere di grande aiuto durante la programmazione, ma è difficile credere che riescano davvero a farlo senza nessun intervento umano. E questo almeno finché gli apostoli di cui sopra non si degneranno di fornirci dati chiari e ripetibili a supporto delle loro affermazioni.

Pur sapendo qualcosa di programmazione, non avevo la minima idea di come si potesse sviluppare un driver e non avevo nessuna voglia di passare dei giorni a studiare come si fa. ↩︎
Tecnicamente questo file è una libreria di funzioni, ma i microcontroller non hanno un sistema operativo e quindi queste funzioni accedono direttamente all’hardware, proprio come fanno i driver che controllano i componenti di un computer. Di conseguenza, in questo caso i termini libreria e driver sono interscambiabili. ↩︎
Dico spesa ridotta ma ormai la penuria di componenti elettronici ha fatto impazzire i prezzi del Pico e ancor di più della Arducam Mini 5MP Plus. Quest’ultima, dai 40 euro di pochi mesi fa ora si trova su Amazon o AliExpress a più del triplo. Per fortuna alcuni rivenditori mantengono (almeno per ora) dei prezzi più onesti. ↩︎

Antigravity: un driver scritto dall'IA

Wed, 04 Mar 2026 18:00:00 +0000

Fra tutti i modelli di Raspberry Pi e di Arduino con cui al momento passo la giornata, il mio preferito è senza dubbio il Raspberry Pi Pico, un microcontrollore piccolo ma potente, in grado di essere programmato non solo in C/C++ tramite l’IDE di Arduino, ma anche in MicroPython e CircuitPython, due versioni diverse (e concorrenti) di Python specifiche per i microcontrollori.

A differenza degli altri modelli di Raspberry Pi, il Pico non dispone di una connessione dedicata alla videocamera, ma può utilizzare quelle con interfaccia SPI,¹ come ad esempio la Arducam Mini 5MP Plus.

In teoria non dovrebbe essere un lavoro difficile. Dopo aver dato una occhiata alla documentazione ufficiale, si tratta solo di collegare la videocamera al Pico, scaricare il driver e i programmi di test dal repository GitHub del produttore, copiarli sul Pico dopo aver installato la versione di Python supportata, e infine provare a scattare qualche foto.

Non avrei potuto sbagliarmi di più.

Ci vuole un driver

Gli unici due programmi di di test disponibili, uno per Arduino e l’altro per CircuitPython, prevedevano di utilizzare Windows per visualizzare il video prodotto dalla videocamera, una cosa insolita dato che la stragrande maggioranza di chi lavora con questi dispositivi usa Linux o macOS. CircuitPython, poi, è meno diffuso di MicroPython, e io avrei preferito usare quest’ultimo per compatibilità con gli altri componenti già collegati al Pico.

Con un po’ di pazienza, e avendo a disposizione un programma che insegna ad usare le funzioni principali per gestire il dispositivo, si può provare a tradurre il codice CircuitPython in MicroPython (e viceversa),² ma in questo caso non c’era nulla del genere a disposizione.

Altra guide trovate sul web sembravano promettenti, ma alla prova dei fatti non funzionavano. L’unica opzione rimasta era quella di bypassare i tool ufficiali e di scriversi da solo un driver per la videocamera.

Una parola!

Io so come scrivere il codice per risolvere una equazione differenziale o per analizzare dei dati di misura. Me la cavo anche con la programmazione di microcontrollori ed affini per catturare i dati dei sensori collegati. Ma qui si tratta di ben altro. Si tratta di studiare nei dettagli come funziona a basso livello la comunicazione fra il Pico e la videocamera. Un lavoro da ingegneri specializzati, che scrivono i driver che poi permettono a noi umani di eseguire operazioni complesso come scattare una foto con poche righe di codice Python.

E allora perché non mettere al lavoro uno degli agenti integrati in Antigravity per fargli fare quello che io non sono capace di fare?

Non sarei stato obbligato ad usare Antigravity, anche Claude Code, Google Gemini, Deepseek o uno degli altri mille LLM che abbiamo a disposizione avrebbe potuto tranquillamente lavorarci su. Ma, come ho già scritto, usare uno degli agenti integrati in Antigravity permette di lavorare direttamente nell’editor e di accedere al sistema operativo sottostante, una vantaggio enorme quando si deve provare e riprovare mille volte il codice prodotto.

L’IA al lavoro

Quando si leggono tanti articoli entusiastici sul vibe coding, ovvero sullo sviluppo del software eseguito dall’intelligenza artificiale senza nessun intervento o quasi da parte del programmatore umano, sembra tutto facile (tanto per citarne qualcuno, questo articolo che ha avuto milionate di letture oppure questo senza dimenticare il tweet che ha iniziato tutto).³ In sostanza, scrivi due-tre righe chiedendo all’LLM o all’agente di turno di fare questo o quello, te ne vai a pranzo o a fare una passeggiata e quando torni è tutto pronto.⁴

Proviamo per una volta a fare lo stesso con Gemini, dandogli solo le informazioni essenziali e verificando cosa riesce a fare davvero. In questo caso queste informazioni si riducono al link alla pagina web della videocamera e a una tabella che descrive come sono collegati i pin della videocamera al Pico (sono più di tre righe, lo so, ma io sono prolisso).

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html). I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

Please write a basic Micropython code to test that everything is right and that the camera can take photos

Gemini ci lavora su furiosamente, tira fuori codice MicroPython che non funziona, si ingegna a correggerlo in base ai miei suggerimenti e finisce sempre per fare nuovi errori (dico sempre Gemini per semplicità, ma sono passato anche a Gemini 3.1 Pro, Claude Opus 4.6 e Claude Sonnet 4.6 via via che finivano i token).

A un certo punto, non sapendo più che pesci prendere, Gemini ipotizza anche che ci sia un problema hardware, come un collegamento sbagliato o una videocamera difettosa (ma interrogando i singoli pin della videocamera è facile verificare che tutto funziona correttamente).

Dopo ore ed ore di lavoro e dato che con MicroPython non riesce a combinare niente di buono, gli chiedo di passare ad Arduino, che è una piattaforma software più matura. Ci vogliono altre ore di lavoro ma alla fine, testardamente, ce la fa, e quella qui sotto è la prima immagine in assoluto scattata con il codice Arduino generato da Gemini (l’immagine originale era al contrario e io mi sono limitato a ruotarla di 180°).

Va detto che subito dopo faccio un errore gravissimo che mi, anzi ci, costringe a rifare tutto da capo. Ma questo è argomento di un’altra storia.

Epilogo

Una volta generato un programma funzionante in Arduino, chiedo a Gemini di rifare tutto per CircuitPython. Anche questo port richiede parecchie ore di lavoro, inframmezzate da un paio di riavvi forzati del Mac che, dopo qualche bug di troppo, è stato obbligato a disabilitare la comunicazione fra le porte USB e il Pico.

In teoria dovrei ripetere il ciclo per la terza volta con MicroPython. Ma l’idea di perdere chissà quanto altro tempo a guardare Gemini che lavora mi fa venire i brividi e lascio perdere, almeno per ora.

Conclusioni

Non so cosa usano quelli che scrivono gli infiniti articoli che proclamano che chiunque, anche se non sa un tubo di programmazione, può farsi scrivere dall’IA in poco tempo un programma perfettamente funzionante.

Anche se di programmazione ne so qualcosa, a me è successo solo per gli esperimenti più semplici descritti nei due articoli precedenti. E men che meno è successo in questo caso. Va detto, però, che sono in buona compagnia.

– Immagine generata da Google Gemini.

È vero, seguendo alla lettera i dettami del vibe coding, qui non ho scritto nemmeno una riga di codice e ho fatto eseguire a Gemini perfino i comandi di Terminale che potrei scrivere ad occhi chiusi. Ma è altrettanto vero che se non avessi dialogato di continuo con l’agente, se non lo avessi guidato passo passo, se non avessi corretto i suoi tanti tanti errori, a volte davvero banali, Gemini non sarebbe andato da nessuna parte.

E ci sono volute molte ore di lavoro ininterrotto, fin troppe ore secondo me, per ottenere qualcosa di utilizzabile.

Altro che programmazione rapida ed intuitiva. Altro che codice basato sulle buone vibrazioni stile anni ‘60. Altro che programmazione for dummies!⁵

Se non ti rimbocchi le maniche e non ti dai da fare in prima persona con il codice, anche quello prodotto da un agente più o meno intelligente, non vai da nessuna parte. Sarebbe bello essere smentito.

L’interfaccia SPI (Serial Peripheral Interface) è una interfaccia di comunicazione seriale, molto utilizzata per collegare un microcontrollore (master) ad uno o più dispositivi periferici (slave) in modo veloce ed affidabile. ↩︎
Mentre scrivevo l’articolo ho trovato questo video, che spiega come mescolare nello stesso script codice MicroPython e CircuitPython. Se funzionasse anche in casi più complicati di accendere e spegnere un LED sarebbe davvero una svolta. ↩︎
Sarà un caso che sono sempre post lunghissimi ma senza mai uno straccio di prova, un prompt, qualche brano di codice, dei link a supporto delle tante affermazioni non verificate e non verificabili? ↩︎
Mai nessuno, da vero nerd, dice che va a fare un po’ di sesso. ↩︎
Dal titolo di una famosa serie di guide introduttive agli argomenti più svariati, che spaziavano da come usare il DOS a come giocare a scacchi. ↩︎

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. ↩︎

JuliaCon 2021

Fri, 23 Jul 2021 12:00:00 +0000

Julia è l’ultimo arrivato fra i linguaggi di programmazione scientifici, che ambisce a combinare la velocità del Fortran con la semplicità sintattica e l’interattività di Python.

Un’altra particolarità molto interessante di Julia è il supporto nativo agli ambienti: ciascun progetto scritto in Julia può avere un suo ambiente specifico, contenente il compilatore,¹ le librerie e gli eventuali package aggiuntivi necessari, nelle versioni che garantiscono il perfetto funzionamento del progetto. La gestione degli ambienti è ancora oggi una delle principali debolezze di Python, averli integrati direttamente nel linguaggio di programmazione dovrebbe rendere più semplice la scrittura di codice riproducibile, il Santo Graal del software scientifico odierno.

– Fonte: JuliaCon 2021.

Perché parlo di Julia? Perché la settimana prossima inizia il JuliaCon 2021, un’ottima occasione per iniziare a conoscere questo interessante linguaggio di programmazione. La registrazione è gratuita per cui non ci sono rischi, nemmeno per il portafoglio.

In attesa dell’inizio della Conferenza, si stanno tenendo dei workshop preliminari molto interessanti che possono già essere visti su YouTube (o potranno essere visti in diretta nei prossimi giorni), senza nemmeno la necessità di installare l’ennesimo sistema di videoconferenza. Per quanto mi riguarda, finito il post mi guarderò Statistics with Julia from the ground up, mentre lunedì mi aspetta Introduction to Bayesian Data Analysis.

Per chi preferisce leggere, consiglio questo articolo generale del sempre bravissimo Jeffrey Perkel, Julia: come for the syntax, stay for the speed, e questo post su Towards Data Science, Bye-bye Python. Hello Julia!.

Buona visione (o buona lettura)!

Julia è un linguaggio compilato ma funziona anche in modo interattivo. ↩︎

Python, il Visual Basic del XXI secolo?

Mon, 19 Apr 2021 06:00:00 +0000

– Microsoft Visual Basic 1.0 per Windows 3.0 (e versioni successive). Fonte: WinWorld.

Ho appena letto l’articolo Is Python the Spiritual Successor to Visual Basic? di Matthew MacDonald e non potrei essere più d’accordo, tanto più che ho fatto esattamente lo stesso percorso, Visual Basic nei primi anni ‘90 e Python (assieme ad R) oggi.

Visual Basic è stato un linguaggio davvero rivoluzionario, il primo che permetteva di aggiungere in modo semplice una interfaccia grafica ai programmi scritti in BASIC, un linguaggio di programmazione ben noto a tutti coloro che avevano vissuto la stagione degli home computer come il Commodore 64 o lo Spectrum.¹

A me, abituato ad usare il Fortran o uno dei vari linguaggi Turbo-qualcosa e Quick-qualcosa che all’epoca spopolavano, Visual Basic sembrò all’inizio come una ventata di aria fresca e lo usai subito per un progetto a cui tenevo moltissimo (e che merita di essere raccontato più in dettaglio).

Ma dopo questa prima volta lo abbandonai senza remore, non solo perché nel frattempo avevo scoperto la potenza di UNIX e Windows era diventato improvvisamente troppo stretto per le mie esigenze, ma soprattutto perché avevo cozzato contro uno dei problemi più seri del linguaggio (almeno per me), l’incompatibilità fra le varie versioni, che impediva di eseguire il codice sviluppato per Visual Basic 1.0 già nella versione successiva della piattaforma di sviluppo. Ma dato che Microsoft già allora era maestra nel mettere i bastoni fra le ruote dei suoi utenti, nemmeno la compatibilità fra il Visual Basic 1.0 per Windows e la versione corrispondente per DOS era garantita al 100% (e questo era proprio il mio caso).

Non sapevo ancora nulla di free software o di open source, ma l’idea di dover dipendere dai capricci di una azienda di software mi sembrava già allora incomprensibile.

Visual Basic è considerato un prodotto Microsoft, ma in realtà è l’adattamento di un linguaggio di programmazione visuale per Windows 3.x, sviluppato in proprio da Alan Cooper (che lo aveva chiamato Ruby). L’idea originale di Cooper era di creare uno strumento con cui costruire con facilità delle interfacce grafiche che aiutassero gli utenti ad utilizzare al meglio il nuovo sistema operativo, interfacce che potevano essere diversificate in base al livello di esperienza di chi le usava.² Tramite dei buoni agganci Alan Cooper riuscì a presentare il proprio prodotto a Bill Gates, che ne rimase entusiasta e decise immediatamente di acquistarne i diritti. Ruby però finì subito in un limbo, ostaggio delle strategie aziendali e delle rivalità fra i diversi gruppi di sviluppatori, per essere associato solo in un secondo momento al QBasic, il vecchio interprete Basic della Microsoft, diventando così il Visual Basic che conosciamo.

L’ambizioso obiettivo iniziale si ridusse così alla semplice riproposizione di un vecchio linguaggio di programmazione in una forma graficamente più accattivante. Alan Cooper sarà quindi anche considerato il padre del Visual Basic, ma la sua idea originale ha ben poco a che fare con il prodotto finale!

Date le premesse non ci si può stupire che Visual Basic abbia avuto una vita travagliata e relativamente breve, descritta con grande abbondanza di dettagli nell’articolo Visual Basic: Early Beginnings, pubblicato in uno dei blog più interessanti in assoluto sulla storia del Personal Computer.

Python oggi è uno dei linguaggi di programmazione più popolari, e con buona ragione. Python e Visual Basic sono praticamente coetanei: il primo ha festeggiato trent’anni a febbraio di quest’anno,³ mentre Visual Basic è stato pubblicato pochi mesi dopo, a maggio del 1991.

Ma Python, a differenza del Visual Basic, dopo una partenza lenta ha conosciuto negli ultimi anni un successo travolgente dovuto, a mio avviso, a due aspetti fondamentali del linguaggio:

Leggibilità. Python non è infarcito di parentesi e di segni di interpunzione come JavaScript, C/C++ o Java, e questo lo rende molto più leggibile dei linguaggi concorrenti. Se per un programmatore esperto questo può essere un dettaglio di poco conto, di sicuro aiuta i neofiti ad avvicinarsi al linguaggio. Anche il fatto che le istruzioni contenute all’interno dei cicli for e while o delle istruzioni condizionali if debbano essere indentate rispetto al resto del codice contribuisce moltissimo alla sua leggibilità, perché permette di afferrare “ad occhio” la struttura del programma. Questa caratteristica obbliga anche a rispettare una certa disciplina nella scrittura del codice (se non si rispetta la giusta indentazione il codice, anche se corretto dal punto di vista sintattico, si rifiuta di funzionare), che è sempre una cosa positiva quando si programma.
Flessibilità. Si può programmare in Python utilizzando indifferentemente un approccio procedurale, ad oggetti o funzionale, riuscendo spesso a mescolare senza troppi problemi i diversi metodi di programmazione all’interno dello stesso programma. Il linguaggio quindi si adatta facilmente alle abitudini dei singoli programmatori e consente di far evolvere il codice in base alle esigenze del momento. È abbastanza usuale, almeno per i programmatori dilettanti come me, cominciare a scrivere un programma in Python buttando giù le idee alla bell’e meglio, per passare solo in un secondo momento ad organizzare le parti principali in funzioni autonome, arrivando magari a creare una struttura di classi e metodi o a spingersi verso le asprezze della programmazione funzionale (in cui dati e funzioni diventano un tutto unico) quando serve un approccio più robusto.

La flessibilità del linguaggio viene sfruttata all’estremo dalle interfacce a notebook come Jupyter, che consentono di costruire dei veri e propri documenti programmabili, dove le parti di testo che descrivono il problema o i dettagli di funzionamento del codice si mescolano alle istruzioni Python e perfino ai dati e agli stessi risultati delle elaborazioni, dando all’utente la possibilità di sperimentare in modo interattivo e di eseguire il codice in modo non lineare (una pratica non sempre raccomandabile, ma che se tenuta sotto controllo è molto comoda).

Jupyter può essere utilizzato direttamente dal web, senza installare nulla sulla proprio computer e senza dover gestire le mille dipendenze dei pacchetti di terze parti che permettono a Python di essere usato in settori diversissimi, che spaziano dalle analisi scientifiche alla finanza o all’arte. Bisogna ammettere che la gestione dei pacchetti esterni è l’aspetto più complesso del linguaggio ed anche la sua principale debolezza, e che ancora oggi non esiste uno strumento universale per farlo.

Grazie a Colab di Google si può persino utilizzare una GPU (e in certi casi persino una TPU) per velocizzare i programmi su Jupyter, una cosa fantascientifica fino a pochissimi anni fa.

Sul fronte opposto, Python è in grado di girare anche su microcomputer da poche decine di euro, come le varie incarnazioni del Raspberry Pi, e perfino su alcuni microcontroller, come il recentissimo Raspberry Pi Pico, dei veri e propri computer ridotti all’osso.

Dal Visual Basic per Windows al Python di oggi se ne è fatta di strada!

– Immagine generata da un testo mediante le reti neurali BigGAN e CLIP. Fonte: Reddit.

– Immagine generata da un testo mediante le reti neurali BigGAN e CLIP. Fonte: Sabino Maggi.

Prima del Visual Basic mi viene in mente solo LabView (sviluppato originariamente per MacOS), che però era un linguaggio iper-specializzato (e iper-costoso!) per la gestione della strumentazione elettronica di misura (e per l’automazione industriale in generale) e l’analisi dei dati acquisiti. ↩︎
LabView (ancora!) perseguiva lo stesso scopo (e lo fa tuttora) nell’ambito, ben più ristretto, dell’automazione industriale. ↩︎
Il codice originale di Python si trova qui, adattato in modo che possa essere ancora compilato sulle macchine moderne. ↩︎

Imparare Python

Sun, 16 Feb 2020 06:00:00 +0000

– Fonte: David Clode su Unsplash.

Di strumenti per imparare ad usare Python ce ne sono a iosa. Fra libri e corsi online come Think Python: How to Think Like a Computer Scientist e la relativa edizione interattiva, i più tradizionali Full Stack Python e Python Practice Book, o il corso online del MIT Introduction to Computer Science and Programming Using Python, c’è solo l’imbarazzo della scelta.

E poi, quando si inizia a masticare i rudimenti del linguaggio, c’è il favoloso Python Tutor, che mostra in modo interattivo quello che succede quando si esegue ogni singola linea di codice.

Senza dimenticare Real Python, che negli ultimi anni è diventato il sito di riferimento per il programmatore in Python, pieno di tutorial scritti benissimo, utili sia per il programmatore alle prime armi che per il professionista scafato che passa le giornate (e spesso anche le notti) davanti al monitor del computer. Il professionista non può farsi farsi sfuggire anche The Python Corner, un sito scritto in inglese (come tutti gli altri citati qui) ma italiano al 100%, e nemmeno Python Tricks: The Book, un libro pieno di trucchi fantastici, indispensabili per utilizzare Python al pieno delle sue potenzialità.

Insomma, per imparare Python non c’è che l’imbarazzo della scelta.

Ma la chicca me la sono lasciata per ultimo. Perché c’è chi non si accontenta di tutto questo ben di Dio e tanto fa che riesce ad avere accesso al corso di Python utilizzato internamente dalla NSA, l’agenzia USA che si occupa della raccolta e dell’elaborazione di dati e informazioni da tutto il mondo, nonché della sicurezza delle reti di comunicazione degli Stati Uniti. Evidentemente anche alla NSA pensano che Python sia un linguaggio di programmazione molto ben fatto, e ora anche noi comuni cittadini possiamo renderci conto di come l’insegnano, scaricando il corso introduttivo alla programmazione in Python scritto dai loro stessi insegnanti.

Non so voi, ma io sono curioso di dargli una occhiata. E poi è bello sapere che c’è in giro qualcuno molto più tignoso di me!

Script per tutti i giorni: semplici modifiche alle stringhe di testo

Fri, 23 Nov 2018 18:00:00 +0000

– Foto: telwink su Flickr.

Succede più spesso di quanto mi renda conto. Devo rinominare dei file, modificare un testo o fare altri pasticci con i miei documenti. Potrei usare una delle tante applicazioni ad hoc fatte per fare proprio quello. Ma perché perdere tempo ad installare ed imparare ad usare l’ennesima applicazione se con il Terminale posso fare prima (e meglio)?

Basta qualche comando ben piazzato nel Terminale, a volte qualche piccolo script in bash o in python, e si possono fare cose bellissime con poco sforzo.

E una volta fatte, perché tenerli per se e non condividerli, magari proprio qui? L’impulso iniziale me l’ha dato Federico “frix” Morchio durante una discussione sul canale Goedel di Slack gestito dal sempre ottimo Lucio Bragagnolo (aka… oops, noto anche come Lux, Loox e tanti altri alias).

Attenzione! Questo e i futuri post sull’argomento non saranno delle introduzioni a bash, a python, al Terminale di macOS (tendo sempre a dimenticare che non si chiama più OS X!), per quelle ci sono un sacco di ottime guide in rete. Chi vuole fare in fretta può iniziare leggendo la mia piccola guida a bash di qualche anno fa, Script di shell in OS X e magari anche Compleanno con permessi, la ripresa di un vecchio post sull’ormai defunto Ping che di fatto mi ha fatto iniziare l’esperienza di blogger.

Cominciamo con un antipasto veloce, una cosa apparentemente inutile (o quasi), ma che serve a dare una idea delle potenzialità di bash e di come, partendo da un’idea semplice, si possa trasformarla a poco a poco in qualcosa di più pratico e adatto ad un uso quotidiano.

Manipolare i nomi dei file

La prima cosa che faccio quando inizio a scrivere un nuovo post è creare un file Markdown con i metadati (titolo, data di pubblicazione, categoria e tag, chi usa Jekyll o Octopress sa di cosa parlo), a cui assegno un nome temporaneo. Una volta deciso il titolo definitivo, rinomino il file in un modo più razionale, in modo che possa ritrovarlo facilmente.

Per farlo seguo la convenzione sui nomi dei file di Jekyll,¹ secondo la quale il nome del file deve essere scritto come YYYY-MM-DD-titolo-del-post.md, dove YYYY indica l’anno, MM il mese e DD il giorno di pubblicazione (espressi rispettivamente con quattro e due cifre) e parole e numeri vanno separati con un trattino invece che con uno spazio. Sembra una cosa inutilmente complicata, ma permette di tenere ordinati i file in base alla data anche quando se ne modifica il contenuto in un secondo tempo. E comunque, evitare di utilizzare gli spazi nei nomi dei file è ancora oggi la cosa più razionale da fare nei sistemi basati su Unix come macOS.

Per la data non ci sono problemi, nei metadati è già scritta nel formato giusto, per cui è sufficiente copiarla ed incollarla direttamente nel nome del file tramite il Finder. Ma il titolo? Potrei usare il Finder anche per il titolo, inserendolo dopo la data nel nome del file e sostituendo a mano gli spazi con i trattini. Però è facile sbagliare, soprattutto quando il titolo è lungo. Ancora più facile è non essere consistenti, usando ogni volta una forma leggermente diversa e mandando a pallino i vantaggi dati dall’utilizzare nomi di file ben definiti.

E poi, vuoi mettere il divertimento di farlo fare a bash?

Un pezzo alla volta

Prendiamo come esempio il titolo di un post di qualche mese fa, “La privacy al tempo dell’Internet of Things: gran finale”. Per trasformare il titolo originale in una sequenza di parole separate da trattini è sufficiente lanciare il Terminale ed eseguire il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/ /-/g"

dove echo scrive la stringa nel Terminale e la invia tramite il | (pipe) a sed, che si occupa di cercare tutti gli spazi e di sostituirli con un trattino, ottenendo

La-privacy-al-tempo-dell'Internet-of-Things:-gran-finale

Non male, ma ci sono due o tre cosette da sistemare.

Problema numero 1 (banale). Il formato di Jekyll prevede implicitamente che il nome del file sia scritto tutto in minuscolo. Personalmente trovo che questa forma sia più gradevole, ma è anche utile a semplificare e a rendere univoco l’ordinamento dei file (una fissazione, lo so, ma quando si maneggiano tantissimi file ogni giorno diventa una cosa fondamentale per lavorare meglio). Si può fare così

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]"

dove tr trasforma i caratteri maiuscoli ([:upper:]) in minuscoli ([:lower:]), ottenendo

la privacy al tempo dell'internet of things: gran finale

Domanda #1: cosa succede se nel comando precedente si usa tr "[:lower:]" "[:upper:]"?

Problema numero 2 (importante). Nei nomi dei file è preferibile usare solo lettere non accentate, numeri e alcuni caratteri di separazione: trattino, underscore e (se proprio dobbiamo) spazio. Se possibile è meglio evitare di usare il punto, che normalmente serve per separare il nome del file vero e proprio dall’estensione (caratteristica che è stata usata parecchio per distribuire file contenti virus ma che apparivano legittimi). Tutto gli altri caratteri devono essere rigorosamente evitati, perché spesso hanno significati speciali per il sistema operativo e creano solo guai.

Per togliere la punteggiatura possiamo usare la stessa tecnica di sopra,

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/[[:punct:]]//g"

dove in questo caso sed cerca tutti i caratteri di punteggiatura ([[:punct:]]) e li sostituisce con… niente (cioè li toglie), ottenendo in uscita

La privacy al tempo dellInternet of Things gran finale

Problema numero 3 (specifico). Il comando di prima rimuove anche gli apostrofi (che è sempre bene evitare di mettere nei nomi dei file, perché potrebbero dare problemi su sistemi operativi meno liberali di macOS).² Piuttosto che buttarli via, è preferibile però sostituirli con un trattino, usando ancora una volta sed

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/'/-/g"

che da in uscita

La privacy al tempo dell-Internet of Things: gran finale

Mettiamo tutto insieme

Usare bash (o qualunque altra shell di Unix) è un po’ come usare il Lego dove, mettendo insieme dei piccoli mattoncini di forme e colori diversi, si può costruire una portaerei (o quasi). Con bash si prendono dei semplici comandi come quelli visti prima, si mettono nell’ordine giusto, si collega l’output di un comando con l’input di quello successivo tramite il | (pipe), e alla fine si riescono a fare delle cose anche piuttosto sofisticate.

In questo caso, il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

genera la stringa

la-privacy-al-tempo-dell-internet-of-things-gran-finale

pronta per essere utilizzata come nome del file.

Domanda #2: Cosa succede se cambio l’ordine dei comandi? Perché questo è l’ordine migliore per convertire un titolo nel formato desiderato?

Domanda #3: Perché nel primo sed questa volta ho sostituito l’apostrofo ' con uno spazio (mentre nella descrizione del problema numero 3 avevo usato un trattino)?

Chi ha avuto la pazienza di leggere fin qui, si starà chiedendo che senso abbia complicarsi la vita con il Terminale e con bash, quando è molto più veloce modificare il titolo a mano nel Finder.

Tutto vero, ma è altrettanto vero che il post è stato più che altro una scusa per introdurre due comandi come sed e tr, molto utili ma anche molto poco conosciuti. E poi, partendo da questa base si possono costruire delle cose molto più utili, ma questo lo vedremo la prossima volta.

Revisioni

3-12-2018: Corretta una incongruenza nel testo originale, nel quale veniva usato una volta sed e un’altra tr per rimuovere i caratteri di punteggiatura.

Che poi è praticamente la stessa convenzione che usa Wordpress per generare i nomi dei post. ↩︎
La gestione generale dei caratteri accentati nei nomi dei file è un problema molto più complesso, che è meglio rimandare ad un post specifico sull’argomento, ammesso che ci sia interesse per l’argomento. ↩︎

La settimana di Python

Tue, 13 Oct 2015 18:00:00 +0000

La solita Packt sta celebrando da ieri la settimana di Python, nel corso della quale offrirà uno sconto del 20% sui suoi libri su Python e un volume gratuito al giorno sull’argomento.

Python è a mio modesto parere il linguaggio di programmazone più interessante che ci sia in giro, facile da imparare ma anche veloce, potente ed estensibile. Un aspetto non trascurabile è che può essere utilizzato sia in modo procedurale, come il Fortran o il C, che nella più moderna modalità ad oggetti (e perfino in modo misto), rendendo più semplice padroneggiare i concetti, piuttisto astrusi a dire il vero, della programmazione orientata agli oggetti.

Non voglio fare sempre pubblicità a Packt, ma trovo molto lungimirante la sua politica di offrire gratis tanti volumi stimolanti e che coprono uno spettro di interessi molto vasto. Prendi quelli gratis ma prima o poi qualcuno lo compri pure.

Mi sembra una occasione da non farsi sfuggire.

Setacciare numeri con il serpente (parte 2)

Mon, 15 Dec 2014 06:00:00 +0000

Caught me crawlin’, baby, Crawlin’ ‘round your door,
Seein’ everything I want, I’m gonna crawl on your floor.
– The Doors, Crawlin’ King Snake.

Nel post di qualche mese fa, Setacciare numeri con il serpente, avevo preso lo spunto da un semplice programma che calcolava i numeri primi mediante il famoso Crivello di Eratostene, traducendo il programma dal BASIC originale in Python, che considero il linguaggio di programmazione più interessante, oggi.

Nella traduzione in Python avevo cercato di lasciare il più possibile inalterato il codice originale, aggiungendo solo alcune righe per mostrare i risultati del calcolo, righe che mancavano del tutto nel programma BASIC di partenza.

Questa volta voglio rendere il codice più moderno e facile da usare, facendo anche in modo che l’output del programma sia più immediatamente comprensibile.

Ecco quindi la versione rivista del programma in Python per il calcolo dei numeri primi. Poiché questo non vuole essere un corso di Python, ma solo una introduzione generale alla bellezza ed alle potenzialità del linguaggio, non entrerò negli aspetti specifici del codice, che possono essere approfonditi utilizzando i link forniti nella bibliografia.

from math import sqrt, ceil

num_max = 256
root = int(ceil(sqrt(num_max)))

flags = {}
for num in range(1, num_max + 1):
    flags[num] = "P"

for num in range(2, root):
    if flags[num] == "P":
        for mult in range(num**2, num_max + 1, num):
            flags[mult] = "-"

print("Sieve of Eratosthenes between 1 and %d (PYTHON-style): true/false map" %(num_max))
print flags
print

print("Sieve of Eratosthenes between 1 and %d (PYTHON-style): prime numbers" %(num_max))
for key,val in flags.items():
    if val == "P":
        print key,
    else:
        print "-",

Per provare il programma si può copiare il codice in un editor di testo (i soliti TextWrangler, TextMate, Atom, Brackets o editor analoghi), salvarlo sul disco rigido come “sieve_v2.py”, ed eseguirlo dal Terminale con il comando

$ python sieve_v2.py

Nella versione originale, prima di ogni esecuzione bisogna inserire a mano nel codice del programma sia il massimo numero intero fino a cui calcolare la lista dei numeri primi (num_max) sia la sua radice quadrata (root), arrotondata al primo intero più grande.

Ma i due numeri sono collegati, perché non far fare questi calcoli al computer?

Per svolgere le operazioni matematiche il Python ha bisogno di caricare esplicitamente la libreria esterna math. Questo meccanismo serve per rendere il più compatto possibile il codice di base dell’interprete Python, aumentandone potenza e capacità di svolgere operazioni particolari solo in caso di effettiva necessità.

Alla riga 1 viene quindi caricata la libreria matematica math, importando solo le funzioni che ci servono veramente, la radice quadrata (sqrt) e quella che effettua l’arrotondamento all’intero superiore (ceil) (per caricare l’intera libreria matematica, basta trasformare la riga 1 in import math).

Queste funzioni vengono usate alla riga 3, che deve essere letta dall’interno all’esterno. Per prima cosa si calcola la radice quadrata di num_max e il risultato è un numero con la virgola (float in Python). La funzione ceil() lo approssima al primo numero intero maggiore o uguale alla radice quadrata, lasciandolo però in formato di numero con la virgola. Infine int() converte il risultato in un vero numero intero.

Avrei anche potuto scrivere questa riga in modo più esplicito

...
temp1 = sqrt(num_max)
temp2 = int(temp1)
root = int(temp2)
...

introducendo due variabili temporanee, temp1 e temp2, che servono solo a memorizzare i risultati intermedi di calcolo, ma credo che questa forma sia persino meno comprensibile di quella originale.

Nella riga 5 la variabile flags, che nel codice originale è una variabile di tipo lista, cioè una serie ordinata di valori identificati da un indice numerico (un array in C) viene trasformata in un dizionario, un tipo di dati (detto anche array associativo) molto utile e caratteristico del Python e di (pochi) altri linguaggi.

...
flags = {}
for num in range(1, num_max + 1):
    flags[num] = "P"
...

Il vantaggio di usare un dizionario rispetto ad una lista sta nel fatto che gli elementi di un dizionario possono essere identificati da indici costituiti non solo da numeri interi ma anche da stringhe. Questo tipo di dati equivale quindi ad una lista non ordinata di dati, in cui ogni elemento di un dizionario è identificato da una chiave (key) e dal valore (val) corrispondente.

In questo caso particolare gli indici sono costituiti dai numeri interi da 1 fino a num_max, e a ciascuno elemento del dizionario viene inizialmente associato un valore costituito dalla stringa “P”.

Il resto del codice è quasi immutato, a parte il fatto che ogni volta che l’algoritmo determina che il numero in esame non è primo, impone il valore dell’elemento corrispondente del dizionario alla stringa “-”, invece che al valore logico False com’era in origine (riga 13).

La lista finale dei numeri primi viene stampata in due modi diversi. Nel primo (riga 16), la stampa della variabile dizionario flags mostra automaticamente la chiave (il numero intero) e la stringa associata (“P” se è primo, “-” altrimenti).

[caption id=“attachment_1305” align=“aligncenter” width=“605”] Output della versione rivista del programma in Python per il calcolo dei numeri primi.[/caption]

Nel secondo, viene usato un metodo standard per accedere ai dizionari in Python

for key,val in flags.items():

con il quale si può accedere alle singole coppie chiave e valore di ciascun elemento di un dizionario (riga 20).

Qual’è il più veloce?

Ma è più veloce usare una lista o un dizionario? Per scoprirlo, misuriamo il tempo di esecuzione delle due versioni del codice Python, la versione originale sieve.py e la versione modificata mostrata sopra sieve_v2.py, per valori crescenti di num_max. Per evitare di influenzare le misure è consigliabile cancellare (o commentare) la sezione finale del codice contenente i comandi di stampa dei risultati, comandi molto più lenti rispetto al codice di calcolo vero e proprio.

Con il mio iMac del 2008 ottengo i risultati mostrati nella tabella seguente

num_max	sieve.py	sieve_v2.py
10.000	0.048	0.038
1.000.000	0.852	1.018
4.000.000	3.650	4.215
9.000.000	8.171	9.574
16.000.000	14.676	19.142
25.000.000	23.311	30.104

(chi fosse interessato può scaricare da questo link un foglio elettronico in formato Excel contenente una versione estesa della tabella con il relativo grafico).

I dati mostrano che in Python una lista è più veloce di un dizionario ma che la differenza non è comunque particolarmente significativa, almeno nei casi normali. Per gestire un dizionario, infatti, il Python deve eseguire una serie di processi di sistema che finiscono per incidere sempre di più sul tempo totale di esecuzione del programma, al crescere del numero massimo entro il quale calcolare i numeri primi.¹

Guardando la tabella (o il grafico Excel) si nota che con entrambi i programmi i tempi di calcolo crescono linearmente all’aumentare del valore massimo da calcolare. Tecnicamente si dice che l’algoritmo utilizzato è di ordine O(n), dove n indica in modo simbolico il valore massimo da raggiungere nel corso del calcolo.

Una crescita lineare del tempo di calcolo con n è un caso quasi ideale. Nella maggior parte dei casi i tempi di calcolo aumentano molto più rapidamente all’aumentare di n. Non è un caso quindi che la ricerca di metodi di calcolo sempre più efficienti sia uno dei campi più fecondi della matematica applicata e dell’informatica (che sono oggi più o meno la stessa cosa).

Bibliografia

La migliore introduzione a Python è senza dubbio How to Think Like a Computer Scientist: Learning with Python (è preferibile usare la seconda edizione per Python 2.x).

Ne esiste anche una versione nella nostra lingua, Pensare da informatico: Imparare con Python, disponibile sul sito ufficiale italiano di Python.

Mi piacciono anche Learn Python The Hard Way e il wiki PyTrieste, che ha il vantaggio di essere relativamente sintetico.

Uno strumento utilissimo è l’Online Python Tutor perché permette di osservare cosa succede veramente quando si esegue il codice Python che abbiamo scritto. Imperdibile.

Quanto detto è evidente dai dati della tabella Excel, dove, per le due versioni del programma, è elencato il tempo di calcolo vero e proprio (colonna “user”), il tempo impiegato ad eseguire i processi del sistema operativo (colonna “sys”) e la somma dei due tempi (colonna “user+sys”). I valori della colonna “user” sono abbastanza simili nelle due versioni del programma (cerchi aperti), mentre l’incremento progressivo dell’incidenza dei processi di sistema determina una divergenza crescente nel tempo totale di calcolo all’aumentare di num_max fra le due versioni del programma (cerchi chiusi). ↩︎

Setacciare numeri con il serpente

Mon, 29 Sep 2014 06:00:00 +0000

Anche se ho una collezione molto ampia di scansioni in pdf di vecchi numeri di BYTE Magazine, mi piace ogni tanto leggere qualche fascicolo preso in prestito dalla biblioteca dell’Istituto (del resto qualche tempo fa li ho salvati da una fine stile Fahrenheit 451).

Nonostante la mia passione per la tecnologia, infatti, ci sono dei casi in cui preferisco ancora l’analogico al digitale. Fra cui ci sono i libri e le riviste.

Sfogliando un numero di BYTE dell'89 dedicato a Unix, mi ha incuriosito una lettera sul famoso Crivello di Eratostene, un algoritmo per calcolare i numeri primi che ha più di 2200 anni. L’algoritmo funziona come un setaccio (da cui il nome): elimina uno dopo l’altro i numeri composti lasciando alla fine soltanto i numeri primi.

La lettera su BYTE introduceva all’algoritmo standard e ad una ottimizzazione ben nota, con la quale era possibile velocizzare il calcolo dei numeri primi senza complicarne più di tanto l’implementazione in BASIC.

Il BASIC è stato il linguaggio di programmazione più popolare degli anni 80, gli anni della rivoluzione del personal computer. A quei tempi il BASIC era usato per interagire con il computer stesso – ne costituiva di fatto il sistema operativo vero e proprio – ed ha contribuito a formare le prime generazioni di programmatori che sviluppavano software per il nascente mondo dell’informatica personale. Non è un caso che sia la Apple che la Microsoft abbiano basato i primi prodotti proprio sul BASIC [1,2].

Il listato originale in BASIC è mostrato qui sotto, in una forma (spero) più leggibile rispetto a quanto consentito dall’impaginazione di BYTE (oltre che dall’abitudine di quei tempi di compattare all’estremo i programmi per ridurre il più possibile l’occupazione della memoria). Il programma determina i numeri primi da 1 fino al valore impostato nella variabile max. Per usarlo, bisogna anche impostare il valore di root alla radice quadrata di max (arrotondata ad un numero intero).

max=8192
root=90
DIM flags (max)

FOR num=1 TO max
	flags(num)=TRUE
NEXT num

FOR num=2 TO root
	IF flags (num) THEN
		FOR mult=num*num TO max STEP num
			flags(mult)=FALSE
		NEXT
	END IF
NEXT num

Appena ho visto il programma ho pensato che sarebbe stato immediato tradurlo in Python, un linguaggio che mi piace moltissimo e che considero il migliore compromesso fra potenza e facilità d’uso. Python può essere usato a più livelli, da linguaggio puramente procedurale fino a linguaggio orientato agli oggetti, e quindi si presta bene ad essere usato per imparare i fondamenti delle programmazione.

Nella prima traduzione in Python ho lasciato il più possibile inalterato il codice originale. Le piccole differenze sono dovute alle particolarità sintattiche dei due linguaggi. In Python esiste la funzione max() e non si può usare lo stesso nome per una variabile, gli indici degli array iniziano da 0 e la funzione range(0, N) crea una lista di numeri interi da 0 fino a N-1, e non fino ad N come sarebbe immediato pensare.

num_max = 256
root = 16

flags = []
for num in range(0, num_max + 1):
    flags.append(True)
    
for num in range(2, root):
    if flags[num] == True:
        for mult in range(num**2, num_max + 1, num):
            flags[mult] = False

print("Sieve of Eratosthenes between 1 and %d (BYTE-style): true/false map" %(num_max))
print flags[1:num_max + 1]
print
print("Sieve of Eratosthenes between 1 and %d (BYTE-style): prime numbers" %(num_max))
for num in range(1, num_max + 1):
    if flags[num] == True:
        print num,
    else:
        print "-",

Alla fine ho aggiunto il codice per stampare i risultati del calcolo, mostrando prima il contenuto grezzo dell’array (o meglio della lista) usato per determinare se ciascun numero è primo o meno, e poi convertendo l’output in una forma più leggibile.

Per provare il programma, basta copiare il codice in un editor di testo (come i soliti TextWrangler, TextMate, Atom, Brackets, o analoghi), salvarlo sul disco rigido con un nome qualsiasi (diciamo “sieve.py”), ed eseguirlo dal Terminale con il comando

$ python sieve.py

[caption id=“attachment_1305” align=“aligncenter” width=“605”] Output della traduzione in Python del programma originale in BASIC per il calcolo dei numeri primi.[/caption]

Si può provare a misurare il tempo di esecuzione del programma impostando la variabile num_max ad un valore relativamente grande (e ricordando di modificare anche il valore di root, che deve essere la radice quadrata di num_max).

$ time python ./sieve.py

Per evitare di influenzare la misura è bene cancellare (o commentare) la sezione del codice contenente i comandi di stampa dei risultati, che sono molto lenti rispetto al puro codice di calcolo.

Il mio iMac del 2008 impiega 0.025 secondi per calcolare i numeri primi fino a 10.000, e ben 22.5 secondi per arrivare fino a 25.000.000.

Ma di questo parleremo più diffusamente un’altra volta.

[1] Il primo software prodotto dalla Micro-Soft di Bill Gates e Paul Allen fu proprio un interprete BASIC per l’Altair 8800, il primo microcomputer personale in assoluto. La storia è raccontata nel bel libro di Paul Freiberger e Michael Swaine, “Fire in the Valley: The Making of the Personal Computer”, McGraw-Hill, 2000, ed è riassunta molto bene in questa pagina su Wikipedia (per una volta la versione in italiano di un articolo è allo stesso livello di quella originale).

[2] Steve Wozniak, la mente geniale della Apple degli inizi, scrisse da zero un interprete BASIC per l’Apple I e II, che diventò il più diffuso interprete BASIC degli anni ‘80, un vero riferimento a cui tutti gli altri interpreti BASIC cercavano di ispirarsi.

I limiti di Wordpress.com: generatori di siti web statici

Sat, 09 Aug 2014 06:00:00 +0000

Come ho già scritto qualche giorno fa, ci sono letteralmente decine di generatori di siti web statici, quasi quante sono le distribuzioni di Linux. Io nei miei bookmark ne ho una trentina.

Come orientarsi in questa moltitudine?

Per le distribuzioni di Linux esiste Distrowatch, un sito popolarissimo che cerca di classificarle tutte. Analogamente, esistono almeno due siti che cercano di elencare tutti i generatori di siti web statici: StaticGen e Static Site Generators. L’approccio dei due è totalmente diverso anche se le informazioni riportate sono praticamente le stesse.

Il primo ordina di default i generatori di siti statici in base alla popolarità, ma si possono applicare vari filtri basati sul linguaggio di programmazione, la valutazione degli utenti e persino gli issue, i problemi riscontrati dagli utenti.

L’altro è apparentemente una tabella ordinata alfabeticamente (in questo momento elenca ben 289 sistemi diversi!), ma cliccando sulle intestazioni si può ordinarla in base al linguaggio di programmazione, alla valutazione degli utenti o alla data in cui il sistema è stato aggiornato per l’ultima volta. Quest’ultima è una informazione utilissima, se un sistema non è aggiornato da anni non vale la pena perderci tempo.

Provando ad applicare un po’ di filtri si copre che esiste perfino un generatore, StatiKiss Framework, basato su Bash, ma il sito web ufficiale contenente la documentazione non risponde. In realtà esisteva un’altro sistema interessante basato su Bash, NanoBlogger, il cui sviluppo è stato però sospeso all’inizio del 2013. Evidentemente Bash non va bene per sviluppare siti web.

Si può trovare anche Zodiac, un generatore di siti statici scritto in AWK, un linguaggio perfetto per la manipolazione di file di testo, sviluppato fra gli altri da Brian Kernighan, uno dei padri di Unix e del linguaggio C. A leggere il README Zodiac sembra semplice da usare, supporta markdown e la struttura delle directory in cui sono organizzati i documenti utilizzati per generare il sito è ragionevole. Ma purtroppo la popolarità di Zodiac è scarsa, scarsissima. Si potrebbe di certo usare per un progetto personale e soprattutto per imparare, ma è impensabile volere sostituire Wordpress con qualcosa come Zodiac. A chi rivolgersi, dove cercare aiuto e documentazione se si volesse fare qualcosa di non previsto dal programmatore, ad esempio gestire un sistema di commenti?

Fra i generatori di siti web statici ci sono persino due sistemi scritti in .NET. Ma vogliamo farci veramente del male?

Ma lasciamo perdere le curiosità. Quali sono invece i top player? Quali sono i sistemi più popolari, più diffusi e, si spera, più affidabili? Facile, il primo in assoluto è Jekyll, un generatore sviluppato in Ruby, un linguaggio di programmazione che è più o meno la risposta giapponese a Python, molto diffuso per sviluppare applicazioni web. Seguono Octopress (un derivato semplificato di Jekyll, il cui sviluppo però è fermo dal 2011), Pelican in Python, Middleman ancora in Ruby e Hexo in JavaScript.

Ci sono comunque altri generatori interessanti, alcuni con nomi veramente curiosi, Ruhoh, Hugo, Pico, Calepin, DropPages, Pancake, Anchor CMS, Hyde, Sculpin, HTMLy,Dropplets, Chronicle. Esiste persino il venerabile (ha quasi 10 anni!) Dir2web, l’unico prodotto italiano che conosca.

Non mancato anche i prodotti a pagamento come Kirby e Statamic. O come Cactus, che è pure specifico per il solo Mac.

Per questi ultimi no grazie, il web nasce e deve rimanere multipiattaforma, sistemi sviluppati per uno specifico sistema operativo non mi vanno bene a priori. E trovo pure irragionevole cercare di vendere questi prodotti: se devo pagare per Statamic, quanto dovrei dare agli sviluppatori di Apache? Sei uno sviluppatore e vuoi guadagnarci? Distribuisci gratis il prodotto, dimostra nei fatti che è buono, fai in modo che diventi il più popolare possibile e poi vendi il supporto. Cercare di vendere software come questi, che subiscono la concorrenza di sistemi equivalenti, gratuiti e di qualità analoga se non migliore, è veramente sciocco.

L’ebook in offerta oggi

Tue, 04 Feb 2014 10:00:00 +0000

Dopo alcuni giorni di stanca, oggi Packt Publishing offre un nuovo ebook allettante: wxPython 2.8 Application Development Cookbook di Cody Precord, pubblicato nel 2010.

Python… sempre Python… Forse anche alla Packt lo considerano un grande strumento di sviluppo.

L'ebook del 26 gennaio

Sun, 26 Jan 2014 06:00:00 +0000

Ancora Python!

Oggi Packt Publishing offre gratis l’ebook Python 2.6 Graphics Cookbook di Mike Ohlson de Fine, pubblicato nel 2010. Mi ripeto lo so, ma anche questo è imperdibile.

L'ebook del 23 gennaio

Thu, 23 Jan 2014 06:00:00 +0000

Anche l’ebook gratis di oggi della Packt Publishing sembra interessante:

Jacob Perkins, Python Text Processing with NLTK 2.0 Cookbook (2010)

Scaricatelo finché siete in tempo. Python è secondo me il miglior linguaggio di programmazione, oggi, e vale sempre la pena imparare qualcosa su questo bellissimo linguaggio.

Senza fretta

Fri, 27 Dec 2013 06:00:00 +0000

Ho scoperto solo di recente questo interessante articolo sulla programmazione: Teach Yourself Programming in Ten Years di Peter Norvig. Purtroppo la traduzione in italiano non è più disponibile direttamente ma può essere ritrovata, tramite il benemerito sito archive.org, alla pagina Impara a Programmare in Dieci Anni.

Questo articolo è una lettura fondamentale per chiunque voglia avvicinarsi al mondo affascinante della programmazione ed insegna fondamentalmente a… non avere fretta.

Imparare a programmare è una attività intellettuale simile a imparare a suonare uno strumento musicale, a parlare una nuova lingua o a cucinare. Ci vuole dedizione, tempo ed esperienza. Bisogna sperimentare, sbagliare, ed imparare a correggere i propri errori. Tutte cose che non si possono fare in pochi giorni né, beninteso, in pochi mesi. Ci vogliono anni di lavoro.

Per fortuna i primi frutti possono essere ottenuti in tempi relativamente brevi, in modo da essere stimolati a proseguire lo studio. Ma bisogna avere pazienza. Iniziare dalle cose basilari, preferibilmente usando un linguaggio di programmazione semplice ma potente come Python, e non porsi obiettivi troppo ambiziosi per le proprie capacità del momento.

Fatto questo, le soddisfazioni non mancheranno.