💾 Archived View for it.omarpolo.com › articoli › literate-programming-dei-poveri.gmi captured on 2023-09-08 at 15:55:07. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

literal programming dei poveri

Il mio primo, nonchè unico fin'ora, contatto pratico con uno stile di programmazione "literate" è stato con il pacchetto Org-Mode di Emacs. L'idea di trasformare un programma in una sorta di "opera" letteraria mi subito intrigato.

Che i programmi siano scritti principalmente per essere letti, consultati, (possibilmente) capiti ed eventualmente estesi da altre persone piuttosto che solo per essere dati in pasto ad una macchina non mi è nuova, sebbene non sia male rifletterci ogni tanto, ma la literate programming, per me, introduce un cambio di focus piuttosto importante, sebbene magari leggero: il testo è principalmente scritto per gli umani, e solo come "scarto" dato in pasto alle macchine.

Dal profondo della mia ignoranza e poca esperienza, non penso sia qualcosa di usabile per tutto, e di sicuro non vorrei dover mantenere ogni singolo programma che scrivo in stile letterario. Non sono convinto che uno stile literate migliori necessariamente la qualità del codice anzi, temo che rischi di soffocare il senso del programma nascondendolo in un mare di parole, oltre che rendere il codice più difficoltoso da leggere dato che viene possibilmente presentato in un ordine diverso da quello che viene dato in pasto alla macchina.

Il punto che credo di voler esprimere è semplicemente che, nonstante sia importantissima la "consumazione" umana del codice, quello che fa testo alla fine è come la macchina lo esegue. Per verificare un programma mi interessa sì avere una dimostrazione degli algoritmi che usa, ma anche che il codice prodotto sia effettivamente corretto! Devo quindi mettermi sullo stesso piano della macchina e leggere.

Per un motivo simile trovo che l'uso frequente di commenti del codice sia similmente contro-produttivo: dovrebbero essere infrequenti e presenti solo dove veramente necessari. Il codice dovrebbe, in mia modesta opinione, essere il più chiaro possibile da sè, altrimenti non ci sono sistemi di documentazione che aiutino nel lungo periodo. Ma sto divagando.

Allo stesso tempo però, trovo che per una certa categoria di programmi, uno stile literate possa aiutare. Programmi piccoli, self-contained, dove si vuole discutere il design e l'implementazione in dettaglio.

Qualche tempo fa ho riorganizzato vari file di configurazioni, piccoli script e chi più ne ha ne metta in un unico repository e mi sono divertito a riorganizzarli usando uno stile di programmazione letterario.

Ho inventato un microscopico sistema di literate programming basato sull'indentazione delle righe: le righe che iniziano con un tab sono codice, tutte le altre testo. In questo modo esportare solo il codice (tangle) è banale:

% sed -n 's/^	//p' file.lp > codice

anche se poi l'ho riscritto in AWK facendogli aggiungere una riga vuota tra i blocchi di codice per migliorarne la leggibilità dei sorgenti generati:

#!/usr/bin/awk -f
#
# lpp - literate programming processor
# public domain

/^\t/ {
	if (!pre) {
		pre = 1
		if (did)
			print ""
		else
			did = 1
	}

	print substr($0, 2)
	next
}

// { pre = 0 }

Così armato, ho iniziato a riscrivere (ed inseguito scrivere nuovi) tutta una serie di script in ~/bin usando questo sistema di literate programming. Penso che diffstat e sshot siano i due venuti meglio:

diffstat: estrae statistiche da una patch

sshot: script per fare screenshot

Altri esempi sono alcuni post nel blog in inglese dove svisceravo piccoli programmi o implementazioni usando, sebbene non esattamente questo formato, qualcosa di simile.

Non ho una vera e propria conclusione da aggiungere in coda; alla fine questo come un po' tutto quello che faccio è in continua evoluzione e mi piace provare a cambiare un po' le cose di tanto in tanto. Un problema di questo "sistema" di literate programming è che non permette di aggiungere metadati (linguaggio di programmazione usato, se un blocco di codice è solo un esempio e non parte dell'output, eventuali descrizioni extra) ma tutto sommato non credo sia un enorme problema.

P.S.: No, `lpp' non sta per "literate programming [dei] poveri", ma per "literate programming processor". Mi piace l'ambiguità però.

$BlogIt: literate-programming-dei-poveri.gmi,v 1.2 2023/03/17 09:24:16 op Exp $