La cattedrale e il bazaar/Qualche altra lezione da Fetchmail
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Fetchmail diventa adulto | Le pre-condizioni necessarie per lo stile bazaar | ► |
Prima di tornare alle questioni generali sul “software-engineering”, è il caso di considerare qualche altro insegnamento specifico a seguito di quest’esperienza con fetchmail.
La sintassi del file rc include una serie di parole-chiave facoltative completamente ignorate dall’analizzatore. La sintassi in “quasi-inglese” che si ottiene è notevolmente più leggibile delle semplici coppie nome/valore che si rimangono dopo aver eliminato le prime.
Tutto ebbe inizio come un esperimento a notte fonda dopo essermi accorto di quante fossero le dichiarazioni del file rc che cominciavano ad assomigliare a un minilinguaggio imperativo. (Per lo stesso motivo ho modificato in “poll” la parola-chiave “server” del popclient originale).
Mi venne da pensare che sarebbe stato più facile usare qualcosa di simile all’inglese comune piuttosto che quel minilinguaggio imperativo. Ora, pur essendo il sottoscritto un convinto fautore della scuola di design del tipo “trasformalo in linguaggio”, come esemplificato da Emacs, dall’HTML e da molti motori di database, generalmente non mi annovero tra i fan delle sintassi in “quasi-inglese”.
Tradizionalmente i programmatori hanno sempre avuto la tendenza a favorire sintassi molto precise e compatte, del tutto prive di ridondanza. Si tratta di un’eredità culturale del tempo in cui le risorse informatiche erano costose, così gli analizzatori dovevano risultare semplici ed economici al massimo grado. Allora l’inglese, con quel 50% di ridondanza, sembrava un modello poco appropriato.
Non è questa la ragione per cui generalmente io evito le sintassi in quasi-inglese; l’ho citata qui soltanto per demolirla. Con l’attuale economicità dei cicli e delle strutture, la pulizia non dovrebbe essere un obiettivo in sé. Al giorno d’oggi è più importante che un linguaggio sia conveniente per gli esseri umani anziché economico per il computer.
Esistono comunque buoni motivi per procedere con cautela. Uno è rappresentato dai costi della complessità dell’analizzatore – non è il caso di aumentare tale complessità fino a raggiungere il punto in cui produrrà bug significativi e confusione nell’utente. Un’altra ragione è che cercare di rendere un linguaggio in quasi-inglese spesso richiede un tale aggiustamento linguistico che le somiglianze superficiali con il linguaggio naturale generino confusione tanto quanto l’eventuale sintassi tradizionale. (Come si può notare con evidenza nei linguaggi di interrogazione dei database di “quarta generazione” e commerciali).
La sintassi di controllo di fetchmail riesce a evitare questi problemi perché il dominio riservato al linguaggio è estremamente limitato. Non si avvicina neppure lontanamente a un linguaggio di tipo generale; le cose che dice non sono affatto complicate, lasciando quindi poco spazio a potenziali confusioni, quando ci si sposta mentalmente tra un ristretto ambito d’inglese e il linguaggio di controllo vero e proprio. Credo qui si tratti di una lezione di più ampia portata:
16. Quando il linguaggio usato non è affatto vicino alla completezza di Turing, un po’ di zucchero sintattico può esserti d’aiuto.
Un’altra lezione riguarda la sicurezza “al buio”. Alcuni utenti di fetchmail mi avevano chiesto di modificare il software in modo che potesse conservare le password crittografate nel file rc, evitando così il rischio che qualche ficcanaso potesse scoprirle casualmente.
Non l’ho fatto perché in realtà ciò non aggiunge alcuna protezione. Chiunque sia stato autorizzato a leggere il file rc, sarebbe comunque in grado di far girare fetchmail – e se è la password che cerca, saprebbe come decodificarla tirandola fuori dallo stesso codice di fetchmail.
Qualsiasi possibile codifica della password operata da .fetchmailrc, non avrebbe fatto altro che fornire un falso senso di sicurezza a quelli che non vogliono spremersi le meningi.
La regola generale è:
17. Un sistema di sicurezza è sicuro soltanto finché è segreto. Meglio diffidare degli pseudo-segreti.