Il 12 ottobre è morto, in un colpevole e imbarazzante silenzio mediatico, (valutazione accentuata dal confronto con l’impatto mediatico generato della morte di Steve Jobs, avvenuta soltanto una settimana prima) Dennis Ritchie. Creatore e sviluppatore ai Bell Labs con il collega Ken Tomphson del linguaggio di programmazione C e del sistema operativo Unix, a cui dobbiamo le basi dei moderni sistemi operativi e degli attuali linguaggi di programmazione ad alto livello: una corposa fetta dell’informatica come oggi la conosciamo, fu premiato nel 1983 con il premio Turing insieme al collega, l’equivalente del premio Nobel per l’informatica. L’intero loro lavoro su Unix fu guidato da idee basate sul principio di semplicità che hanno poi preso il nome di filosofia Unix che, se nel contesto informatico da il meglio di sé per eleganza e concretezza, può essere portata con successo anche alla vita reale.
Panoramica
Non esiste una formulazione standardizzata e ufficialmente riconosciuta della filosofia e diverse personalità del mondo Unix ne hanno dato la propria interpretazione, pur onorandone sempre e comunque le caratteristiche basiliari di semplicità, modularità e portabilità: molto spesso la filosofia Unix viene riassunta in una lezione con KISS, Keep It Simple Stupid. Fra le varie esposizioni della filosofia, le più famose sono sicuramente quelle di Mcllroy, autore delle “pipe Unix, che la riassume in 3 punti chiave; Eric S. Raymond autore di The Art Of Unix programming che ne formula 17 regole e Mike Gancarz, autore del libro Unix Philosophy che la sintetizza in 9 punti.
Pur nelle varie forme, oltre ad aver costituito il principio di design e la linea guida per la scrittura di Unix, questa scuola di pensiero ha contribuito a definire anche la famiglia di quelli che vengono definiti sistemi operativi Unix-Like, ovvero che ne seguono i principi guida e che includono anche i sistemi operativi GNU/Linux e BSD.
Fare una cosa sola, farla bene
Questo è quello che possiamo identificare come il principio cardine, scrivere programmi altamente specializzati che siano in grado di risolvere un solo problema nella maniera migliore possibile, cercando di mantenerli piccoli e semplici, a meno di requisiti e necessita stringenti. Inutile aumentare la complessità diminuendo l’efficienza aggiungendo problemi da risolvere; piuttosto che aumentare la complessità e la quantita è bene lavorare sulla qualità. Nella vita reale questo principio può essere adottato, ed è stato ampiamente trattato e discusso, concentrandosi e focalizzandosi su un problema o attività alla volta ed evitando di disperdere le proprie energie e risorse in cambi continui di contesto fra un’attività e l’altra, con l’illusione che il multitasking sia in grado di aumentare la quantità senza impattare sulla qualità.
Interfacce semplici e universali
La complessità di problemi composti, piuttosto che venire affrontata con l’aumento della complessità dei singoli programmi, viene affrontato con la progettazione di interfacce chiare e universali, che permettano ai singoli programmi (magari riuniti in uno script) di collaborare fra loro, ognuno con la soluzione efficiente del proprio problema, nel nome della modularità e della divisione di responsabilità, alla soluzione finale e completa. Non stupisce a riguardo che l’interfaccia universale e flessibile per eccellenza indicata sia il semplice testo, sia salvato su file che scambiato tramite stream. Sempre a riguardo delle interfacce, con riferimento all’interazione utente, si indica come queste ultime debbano essere il meno sorprendenti e più silenziose possibile. Questo punto ci può insegnare come la collaborazione sia alla base della risoluzione di problemi complessi e come siano da preferire strumenti e sistemi aperti e universali che grazie alla loro flessibilità, immediatezza e portabilità, sono in grado di farci risparmiare in complessità.
L’efficienza non è tutto
Anche se può sembrare da una lettura superficiale che tutta la filosofia sia un po’ troppo sbilanciata verso la ricerca dell’efficienza a tutti i costi, essa viene indicata come desiderabile purchè non vada a scapito della semplicità, della modularità e portabilità delle soluzioni. Con questa idea si parla anche della differenza fra tempo del programmatore e tempo macchina e di come il valore del primo sia maggiore e per questo sia da preferire per il risparmio rispetto al secondo. Questa lezione fa riflettere su come l’efficienza sia un valore relativo ma non assoluto e che debba tenere sempre al centro le esigenze dell’utente e delle persone. La continua compulsione alla ricerca della massima efficienza, che molte persone sperimentano sul posto di lavoro e che addirittura alcuni applicano anche nella propria vita privata, non solo è inutile ma è dannosa, dal momento che si dimentica troppo spesso della relazione e della centralità della persona.
Unix is simple. It just takes a genius to understand its simplicity. – Dennis Ritchie