il confronto

Shell vs Siri: perché un vecchio linguaggio informatico può fare ancora la differenza

Nonostante i progressi nel campo delle interfacce grafiche e dell’interazione vocale con le macchine, ancora oggi, appena si vuole fare qualcosa di un po’ complicato in un computer, bisogna aprire un terminale. Ecco perché, allora, imparare ad usare una shell è un buon investimento (anche per la vita coniugale)

04 Nov 2019
Giovanni Salmeri

Università degli Studi di Roma Tor Vergata


I piccoli eventi famigliari possono suggerire profonde riflessioni sul futuro dell’informatica.

L’altro giorno mia moglie mi si è avvicinata e mi ha chiesto: «Senti, ho una cartella suddivisa in un numero enorme di sottocartelle, ognuna delle quali contiene moltissimi file; ora, vorrei spostare tutti questi file nella cartella principale. C’è un modo per farlo senza dover fare con una sottocartella alla volta?».

«Si può descrivere esattamente ciò che vuoi ottenere? Se sì, allora si può fare»

«E come?»

Ci ho pensato qualche secondo e ho risposto: «Il modo più semplice è con una riga di shell». Ovviamente mia moglie non era molto propensa ad ascoltare una spiegazione esauriente su che cosa sia una shell.

La storia della shell

Eppure, si tratta di uno dei costituenti più importanti di un computer, dalla storia affascinante. Coloro che hanno usato un computer negli anni 80 sanno esattamente che cos’è una shell o, come anche si dice, un «interprete di comandi»: quando si accendeva un computer con il sistema operativo DOS, compariva uno schermo nero con un brevissimo messaggio (in genere C:>, ma i più anzianotti ricorderanno A:>) che segnalava che il computer era pronto per eseguire comandi: ecco, una shell (come si usa sempre chiamarlo nei sistemi operativi simili a Unix) è il programma che esegue questi comandi. Per esempio, per far partire il glorioso sistema di videoscrittura WordStar si scriveva il comando WS. Alcuni comandi (quelli cosiddetti «interni») non avevano bisogno di un programma separato, perché venivano eseguiti direttamente dall’interprete: per esempio DIR che mostrava l’elenco dei file contenuti in una cartella.

Fin qui le cose sono abbastanza banali: scrivere un comando equivale a ciò che nelle interfacce grafiche è fare un clic su un icona. Tutto in effetti si sarebbe fermato qui se qualcuno non avesse avuto l’idea di arricchire la shell di quelle caratteristiche che ne fanno un vero e proprio linguaggio di programmazione. Per esempio: «se le cose stanno così e cosà, allora fa’ questo». L’idea geniale venne nel 1976 a John Mashey, che in questo modo trasformò l’originario interprete di comandi di Unix scritto da Ken Thompson, aggiungendo le variabili e i tradizionali controlli di struttura: if, switch, while, goto, exit.

La shell che così risultò fa oggi parte dell’archeologia informatica, ma quella che appena tre anni dopo venne scritta da Stephen Bourne è sostanzialmente ancor oggi usata nella stragrande maggioranza dei computer che usano un derivato di Unix: Linux, BSD, MacOS, Android. Per essere più esatti: nell’era delle onnipresenti interfacce grafiche la shell è soprattutto usata internamente dal sistema operativo per una miriade di compiti di servizio, ma comunque sta sempre lì a disposizione di chi se ne vuole servire. L’interprete di comandi del DOS, pubblicato poco tempo dopo, fu sostanzialmente un’imitazione molto semplificata della shell di Unix. Ancora oggi Windows 10 lo include.

Ma che cosa c’era di tanto rivoluzionario nell’idea di Mashey, apparentemente banale? C’era l’idea che la programmazione non fosse una delle tante operazioni che il computer potesse compiere, ma il modo in cui il computer dovesse apparire all’esterno. Nel mio computer c’è un programma di posta elettronica? Allora devo essere in grado di poter codificare per esempio questa operazione: «se oggi è un giorno feriale aprimi il programma di posta elettronica» (altrimenti, sottinteso, è festa e voglio stare in pace), e ciò deve avvenire non come una funzione del programma di posta elettronica, ma come una funzione generale del computer. (L’esempio ovviamente è mio.) Non per niente Mashey intitolò l’articolo in cui descrisse la sua idea: «Usare un interprete di comandi come linguaggio di programmazione di alto livello», dove «alto livello» significa vedendo le cose dall’alto, nel modo più vicino alle esigenze umane.

Dopo un paio di minuti di scribacchiamento, tornai da mia moglie con la riga di shell che faceva esattamente ciò che le serviva: for d in */; do mv “$d”/* .; done. Tentai di appassionarla raccontandole la storia di quello strano «done» finale, che da solo meriterebbe un articolo, ma il mio tentativo non andò a buon fine. Riuscii però a strappare un grande sguardo di ammirazione quando, dopo aver aperto un terminale tutto nero nel suo computer e aver scritto il comando, si rese conto che i centinaia di file erano stati spostati in una frazione di secondo: quanto tempo risparmiato! Ovviamente, tutto stava in quel piccolo for all’inizio: la parola chiave che indica la ripetizione di un comando (in questo caso mv, «muovi») su una certa categoria di oggetti.

La morale della storia

Una morale di questa storia è abbastanza ovvia. Uno strumento vecchio di quarant’anni aveva fatto, probabilmente nella maniera più efficiente possibile, ciò che è impossibile a qualsiasi modernissimo sistema grafico. Consolazione non piccola per chi comincia ad avere i primi capelli bianchi! Un paradosso? Niente affatto. Quello della shell è un linguaggio: se gli uomini sono definiti, da Aristotele in poi, come esseri essenzialmente parlanti, un motivo pur ci sarà.

Il fatto è che il linguaggio riesce a descrivere stati di fatto, intenzioni, processi, che in nessun modo si potrebbero semplicemente indicare con un dito. Ora, le interfacce grafiche nascono dall’idea che un computer debba essere usato appunto indicando e manipolando immagini di oggetti: un’idea geniale, che semplifica le cose semplici… ma rende impossibili quelle appena più complesse. Basti vedere la storia dei cosiddetti «linguaggi di programmazione visuali»: è una storia anch’essa affascinante, ma questa volta perché è una sequenza impressionante di fallimenti. La parola è parola, al massimo si possono creare simboli visuali che rappresentano parole, ma questo significa solo aggiungere uno strato da decifrare in più. È per questo che ancora oggi, appena si vuole fare qualcosa di un po’ complicato in un computer, bisogna aprire un terminale, che è come dire: non ti posso mostrare ciò che voglio, ma te lo posso descrivere a parole.

Dalla parola all’interfaccia grafica e ritorno: gli assistenti vocali

C’è anche però un’altra considerazione da fare. È vero che i computer oggi sono dominati dalle interfacce grafiche, ma è anche vero che lentamente stiamo assistendo al ritorno della parola: gli assistenti vocali! «Gli assistenti vocali sono delle piattaforme basate su algoritmi di intelligenza artificiale che permettono alle persone di poter interagire con la voce in maniera quasi naturale con degli operatori virtuali»: così dice la prima definizione che ho trovato in Rete.

Insomma, se l’aspetto più appariscente è qui il riconoscimento della parola pronunciata, quello più rilevante è senza dubbio il fatto che i comandi vengono di nuovo dati con la parola, proprio come in una shell. In fondo, il comando scritto per mia moglie è solo la trascrizione in un codice formale di queste parole: «Per ogni sottocartella che c’è qui, sposta qui i file che vi si trovano». Similmente, se voglio telefonare a Matteo Renzi, posso dire al mio iPhone: «Ehi Siri, chiama Matteo Renzi!»: la chiamata parte e Aristotele può festeggiare! Ma che cosa accade se, per esempio, introduciamo una condizione? Proviamo: «Ehi Siri, se uno più uno fa due, chiama Matteo Renzi!» La chiamata parte! «Ehi Siri, se uno più uno fa tre, chiama Matteo Renzi!» Delusione terribile: la chiamata parte anche in questo caso. Insomma, Siri non riconosce affatto la forma più elementare di connessione di proposizioni, quella condizionale. Semplicemente estrae ciò che riconosce come un comando, e lo esegue. Siri è molto indietro rispetto alla shell di John Mashey del 1976, non sa interpretare nessuna delle cinque strutture di controllo con cui questa se la cavava egregiamente. Alla faccia dell’intelligenza artificiale.

Può essere recuperato questo ritardo? Ovviamente tutto è più facile quando si ha a che fare con un linguaggio formale esattamente definito, come appunto quello di una shell. Le cose sono molto più difficili quando si voglia interpretare un linguaggio naturale, pieno di tutte le ambiguità che spesso dobbiamo risolvere chiedendo esplicitamente spiegazioni. Che cosa accadrebbe se mentre detto un messaggio dicessi: «Ehi Siri, cancella tutto!», e Siri interpretasse questo comando nel contesto dell’intero iPhone? E più un linguaggio diventa ricco, più aumentano le possibilità di equivoco. I problemi sono insomma tanti: ma già capire dove stanno è importante.

Nel frattempo, imparare ad usare una shell è un buon investimento, per l’uso del computer e soprattutto per la vita coniugale.

@RIPRODUZIONE RISERVATA

Articolo 1 di 2