strumenti
linea
Zen e arte della programmazione
Contributo per gli atti del THUG di Stefano Penge

  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Introduzione

Questo scritto è dedicato ai programmatori, professionisti o autodidatti, soggetti completamente trascurati dalla saggistica non tecnica (per esempio quelle pedagogica), in quanto generalmente considerati troppo lontani da interessi teorici.
Si riconosceranno, spero, in molti luoghi del testo, visto che molte frasi sono state scritte all'alba di nottate passate a cercare l'uscita da foreste condizionali, attraversando vortici ricorsivi e arrampicandosi su pareti di cicli da i all'infinito. E forse acquisteranno essi stessi una coscienza più alta del loro stesso "mestiere".
L'idea di base è quella di affrontare il rapporto con la programmazione da una prospettiva apparentemente paradossale, cioè appunto quella del pensiero orientale di matrice genericamente taoista, che qui da noi ha avuto più fortuna sotto l'etichetta dello Zen.
Zen che, come in tutti i casi letterari paralleli a questo almeno nel titolo (da Robert Pirsig a Eugene Herrigel, da Fritjof Capra fino a Jacopo Fo), c'entra solo fino ad un certo punto, come pretesto, come artificio di straniamento, come rimando continuo ad un'altra sponda. Ma è un rimando necessario, se si vuole evitare di rimanere invischiati nella visione dualista, tecnicistico-umanistica.
Ho cercato in giro sulla rete per vedere se questa operazione era già stata tentata, e ho trovato dozzine di "Zen e l'arte di ..." (dalla programmazione parallela al web mastering, dalla programmazione grafica al supporto tecnico); purtroppo nessuno di questi parla di Zen, né ha a che fare con lo Zen nemmeno lontanamente. Il significato del termine "zen" in quei contesti è semplicemente "vertice assoluto della perfezione".

Personalmente, sono rimasto sempre affascinato dalla letteratura zen (almeno da quella trodatta in italiano, da "La porta senza porta" a "101 storie zen") proprio per questa visione integrale dell'universo: il distacco dall'io senza il distacco dal mondo, una proposta di seguire la "via" che non richiede accecamenti mistici, ma passa per le cose di tutti i giorni.
Anni dopo, leggendo Lo Zen e l'arte della manutenzione della motocicletta , quello che mi ha colpito è che questo atteggiamento può essere esteso anche a ciò che è artificiale, compresi i computer e il nostro contorto rapporto con essi.
In questa prospettiva, bisogna anzitutto fare piazza pulita dei pregiudizi, e riconoscere che costruire programmi (le cose che rendono i computer diversi dai frigoriferi) è un'attività complessa, ricca, artistica, che richiede altrettanta unificazione della persona del tiro con l'arco e della cerimonia del tè e che promette altrettanta pace interiore, per quanto paradossale possa sembrare.


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Il Manuale del Programmatore Zen

La programmazione secondo loro
Programmare è un'attività che viene in generale sopravvalutata dai programmatori e sottovalutata da tutti gli altri. Vista dall'esterno, è un'attività ripetitiva, fredda, legata alla logica e alla matematica. Fino a poco tempo fa, nella scuola dell'obbligo l'informatica era considerata una parte della matematica, e se ne occupavano solo gli insegnanti di materie tecnico-scientifiche. Gli altri la guardavano con sospetto.
E anche fuori le cose non vanno meglio. Dal telaio meccanico al PC, l'immaginario collettivo associato con le macchine è diviso in una parte positiva (il miraggio del servo meccanico che svolge rapidamente tutti gli incarichi più gravosi) e una negativa (lo spettro sociale del licenziamento, ma anche del prosciugamento dei rapporti all'essenziale/utile).
Questo immaginario è comune tanto agli apocalittici che agli integrati. Persino quella categoria particolare di utenti che vive in un rapporto di dipendenza quotidiana dalla macchina (i programmatori di computer) spesso coltivano un'immagine di questo tipo. Per il programmatore, ufficialmente il computer è la parte materiale di un algoritmo di calcolo. Fili, transistor, circuiti stampati che corrispondono a funzioni matematiche. "Il computer fa solo quello che gli si dice di fare."
Ci si aspetterebbe quindi che i programmatori fossero tutti ingegneri in camice bianco.

Invece la figura classica del programmatore è ben descritta in "Microservi": single, trascurato nel vestire - nella migliore delle ipotesi, con pessime abitudini alimentari (dalle patatine country alle caramelle sintoblob), nessuna coscienza sociale o politica e in generale un'identità personale piuttosto slavata. Vive di notte ed è abituato a lavorare ininterrottamente anche per due o tre giri della lancetta corta. Poi sprofonda in un dormiveglia di sogni a finestre che non riesce a chiudere. La prima cosa che fa al risveglio è premere, con gli occhi semichiusi, il pulsante On.
Non tutti i programmatori sono (sempre) così. Ma alzi la mano chi non si riconosce in almeno uno di questi tratti.

La programmazione secondo noi
Vista dall'interno, la programmazione è un'arte.
E infatti ne presenta le caratteristiche tipiche:
Contrariamente a quello che si pensa, la buona programmazione richiede un grandissima dose di intuizione, molta fantasia, moltissima pazienza (e un minimo indispensabile di logica).
Cosa si intende per buona? Non è una domanda facile.

Tradizionalmente, la qualità del codice viene valutata secondo tre parametri:
  1. Efficienza: occupazione di memoria, velocità di esecuzione
  2. Robustezza: capacità di gestire situazioni eccezionali, compresi gli errori
  3. Manutenibilità: possibilità di mettere le mani sul codice in un secondo tempo o da parte di altri
Un buon programma è senz'altro un programma efficiente, robusto e manutenibile.
Ma questi sono solo aspetti pratici, effetti collaterali anche se vantaggiosi, della qualità vera.
Nel seguito proveremo ad adottare altri punti di vista. Il che non vorrà dire che questo punto di vista si rivelerà errato, ma solo che è necessario saper cambiare punto di vista, o saperne adottare più di uno contemporaneamente.


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Ecologia del codice

Un punto di vista più avanzato è quello che valuta il codice da un punto di vista "ecologico", cioè lo inserisce in un sistema più vasto che può essere il computer dell'utente o la rete intera. I parametri significativi diventano allora economia delle risorse, velocità e riciclabilità.

Economia delle risorse
Ai tempi dei Vic 20 e dei Commodore 64, la lunghezza dei nomi delle variabili era un parametro sigificativo dell'occupazione di memoria di un programma e della sua velocità d'esecuzione. Questo portava ad un codice molto compatto ma non commentato e pochissimo comprensibile. Quei tempi sono ricordati con nostalgia dai "vecchi", che storcono il naso di fronte al disprezzo delle risorse altrui dimostrato da chi occupa megabyte e su megabyte del vostro hard disk senza neanche chiedervelo.
Per loro è un principio ovvio, che non richiede dimostrazione: occorre usare strutture di dati non ridondanti. Un dato deve essere rappresentato dal più piccolo contenitore possibile. Non è solo questione di etichetta: più RAM viene occupata, più è probabile che il sistema lavori in situazioni limite e quindi vada in crash.
Oggi che RAM, HD e tempo processore sono in svendita, il bene che scarseggia - e quindi il valore - è la larghezza di banda. E la netiquette vuole che non si occupi la banda inutilmente. Dalle raccomandazioni ai webmaster sulla leggerezza delle pagine, a quelle dei moderatori delle liste sugli attachments duplicati all'infinito, il principio è chiaro: occupare meno banda possibile.

Velocità degli algoritmi
Bisogna ottimizzare tempo d'uso del processore. Anche oggi che il time sharing non esiste più e ognuno può disporre del suo processore personale per tutto il tempo che crede? Anche oggi che i milioni di cicli di istruzione al secondo cominciano a diventare unità di misura insufficienti?
Un programma veloce non solo riduce i tempi di attesa da parte dell'utente, e quindi dà l'impressione del rapporto causa/effetto tra un click e un'animazione (mentre si tratta sempre di una triangolazione tra un evento e un pezzo di programma che gestisce quell'evento), ma consuma meno cicli macchina e quindi meno elettricità (meno uranio, meno carbone, etc.).

Riciclabilità: la programmazione orientata agli oggetti
L'informazione, come pochissime altre materie prime, può e deve essere riciclata. Il tempo necessario per scrivere un algoritmo (tradotto in ore di vita, consumo di ossigeno, etc.) può essere risparmiato molte volte se l'algoritmo viene incorporato in un oggetto riusabile in un punto diverso del programma o in un altro programma o da un altro programmatore.
Qui si tocca un punto delicato, quello della possibilità di duplicare più o meno liberamente un pezzo di codice. Non me ne occupo qui, ma chi fosse interessato, può seguire le piste seguenti : Stallman, licenza GNU, copyleft, opensource...


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Zen e qualità

Gli aspetti fondamentali della qualità
Ma ancora non siamo arrivati alla qualità vera, precedente e indipendente dai suoi effetti pratici, ma loro presupposto necessario. Questa è la Qualità di cui parla Robert Pirsig nei suoi due libri (Lo Zen e l'arte della manutenzione della motocicletta e Lila, entrambi tradotti presso Adelphi), e ai quali rinvio. Sono libri seri, a dispetto dei titioli, che hanno poco a che fare con lo zen ma molto con la Qualità e con il rapporto dell'Occidente con la tecnologia.
Ci sono due tipi di qualità di un software: una qualità visibile (che ha a che fare col disegno dell'interfaccia, con la scelta di una metafora adeguata...) e una qualità nascosta, che è quella relativa al codice.
La qualità visibile è quella relativa all'interazione con l'utente, che rende il programma facile o difficile da usare. La qualità nascosta è quella relativa all'interazione con il programmatore, e che rende la sua vita un inferno o un paradiso.
Per quanto si possano scrivere anche programmi brutti ma efficaci, il fatto che un programma sia anche un testo che deve essere letto e riletto da almeno una persona (il programmatore) oltre al compilatore implica che un programma leggibile, chiaro, equilibrato, si capisca meglio e venga modificato più volentieri, quindi meglio.
In realtà, così come un compositore può giudicare un pezzo musicale anche solo guardando la partitura, così un programma può essere valutato "leggendolo", a prescindere dall'esecuzione.

Il primo patriarca venuto dall'occidente
Da noi (in occidente) le divisioni tra estetica e etica, tra intuizione e intelletto hanno prosperato per anni. È difficile trovare le sorgenti di questa divisione. Platone è uno degli maggiori responsabili (l'anima tripartita), ma più in generale tutta la filosofia greca presuppone questa divisione o meglio si fonda su essa.
Ma non è stato sempre così e non è dovunque così.

Il buddismo zen è una forma giapponese di buddismo. È un incrocio, o meglio il frutto di una rielaborazione successiva attraverso tre culture.
Proveniente originariamente dall'India (sesto secolo a.C.), il buddismo si è spostato verso est, in Cina, intorno al primo secolo d.C. dove ha fatto i conti con Confucianesimo e Taoismo; quindi dalla Cina nel tredicesimo secolo passò ancora più a est, al Giappone. "Zen" infatti è la parola giapponese che corrisponde al cinese "chan", e viene tradotto con meditazione.
Il suo viaggio da occidente verso oriente lo ha portato negli Stati Uniti e quindi - attraverso l'atlantico - in Europa.

Zen e té
La fortuna dello zen è dovuta probabilmente ad una grande semplicità e ad un atteggiamento "rilassato" nei confronti della dialettica mezzo-fine. La non-definizione classica di Zen di Po-Chang "Quando ho fame mangio, quando ho sonno dormo" ha il fascino disarmante di una verità che però si capisce solo a metà.
Qui non ho intenzione di descrivere compiutamente teoria e pratica dello Zen. Non ne sarei in grado e forse non interesserebbe a nessuno. Oltre ai testi in italiano già citati, ci sono scuole ovunque e persino siti più o meno ufficiali (date un occhiata a "Zen Stories", a "List of available IRIZ Zen Text Files" dell'International Research Institute for Zen Buddhism o a "Dark Zen".
Più note dello zen stesso sono le applicazioni dello zen alla vita quotidiana, dalla cerimonia del tè alla calligrafia, dalla progettazione di giardini alle arti marziali. Questo folclore giapponese ha portato alla convinzione che sia "zen" tutto quello che è perfetto, semplice, naturale, ecologico, mentre è vero esattamente il contrario. Lo zen deve e può essere applicato soprattutto alle situazioni difficili, complesse, anche a quelle più artificiali.

Koan
Un koan è un indovinello paradossale, apparentemente senza soluzione. Viene usata dalla scuola Rinzai Zen per liberare la mente dello studente dalle pastoie della logica intellettuale (quella che da noi si chiamerebbe aristotelico-tomista).
Questa situazione è di casa tra programmatori: il problema irrisolvibile è loro pane quotidiano. Un vero programmatore è annoiato dalle attività di routine (scrivere semplicemente programmi), e se è sufficientemente raffinato scrive programmi che le svolgano per lui. Ma il problema lo affascina e lo cattura anche di notte, fino all'illuminazione. Quel momento - in cui improvvisamente tutto quello che era oscuro diventa ovvio - ripaga dei mesi di buio vagare.


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Zen e computer

Scuole
Come le scuole di Buddismo sono diverse e anche molto lontane tra loro, così negli anni si sono susseguite varie scuole di programmazione, ognuna con un proprio decalogo e con un modello sottostante. Dal modello imperativo a quello funzionale, da quello logico a quello orientato agli oggetti. Ogni modello porta con sé caratteristiche psicologiche non indifferenti: adottare l'uno o l'altro non è mai una questione di pura efficienza, ma di preferenze estetiche, etiche o politiche. Perciò prima ancora di cominciare a scrivere codice occorre scegliere - almeno provvisoriamente - il modello di riferimento. A ciascuno il suo.

Istruzioni per il montaggio della bicicletta giapponese
"Il montaggio della bicicletta giapponese richiede una grande pace mentale" (questo aforisma è tratto da Lo Zen e l'arte della manutenzione della motocicletta di Robert Pirsig). Sembra uno scherzo, invece è una raccomandazione seria. In Giappone non vale solo per le biciclette.
Per un programmatore dovrebbe essere il primo comandamento. Nessuno inizia a lavorare ad un nuovo programma analizzando i dati e gli obiettivi. Quello che serve è una visione d'insieme della situazione problematica che il programma è chiamato a risolvere. Da questa rappresentazione chiara emerge quasi automaticamente, o in ogni caso senza che si sappia bene in che modo, un'ipotesi di strategia di programmazione.
La meditazione dovrebbe essere il primo passo nell'affrontare un programma nuovo.
In questo contesto, meditare significa affidarsi alle proprie conoscenze implicite, all'esperienza precedente non codificata, che è sicuramente più ampia di quella cosciente chiamata in causa direttamente dal problema. Nella base di conoscenza globale la probabilità di trovare una strategia applicabile a questo problema è molto più alta. Croce e delizia della programmazione è la flessibilità della stessa descrizione del problema.
C'è sempre un altro modo di vedere il problema, in cui la base diventa il tetto e il tetto la base.

Un motto che si applica bene a questo stadio di lavoro è "Appoggiatevi saldamente ai vostri principi, in modo che cadano presto".

I sogni del programmatore
Ogni programmatore, se chiude gli occhi, si rappresenta l'opera a cui sta lavorando secondo una qualche metafora. Come spazio fisico, come organismo, come macchina, come sistema politico, come musica. È su questa rappresentazione interna che lavora realmente.
È questa visione che è difficile comunicare e che rende così difficile continuare il lavoro di un altro. Quasi sempre, si preferisce ricominciare da capo, per avere la possibilità di crearsi la propria rappresentazione.

Ritmo: la forma degli algoritmi
Il ritmo è un elemento fondamentale della qualità del codice. È un elemento del tutto non significativo dal punto di vista dell'efficienza e dell'ecologia, eppure si potrebbe anche dire che è la caratteristica che più resta impressa di una porzione di codice.
Capita a tutti di cercare - e di trovare - un pezzo di codice di cui si ricorda la forma visiva, il ritmo, anche se non si è in grado di ricordare esattamente cosa contiene.
Quando il programmatore rilegge un programma segue gli accapo, i termini riservati che segnano le strutture; in altre parole, tiene il tempo.
Per esempio:
un ritmo binario è semplice ma ossessivo;
un ritmo ternario è mosso ma permette di porre accenti;
un ritmo quaternario è riposante ma pesante, noioso;
un ritmo quinario è aperto ma inquietante;
eccetera...

Provate a leggere, a voce alta, questo:

ask "What is your Number?"
number = it
if number is 10
  beep 4
else
  if number is 7
    beep 3
  else
    if number is 5
      beep 2
    else
      if number is 3
        beep 1
      end if
    end if
  end if
end if

e adesso questo:

ask "Number, please?"
number = it
conditions
when number is 10
  beep 4
when number is 7
  beep 3
when number is 5
  beep 2
when number is 3
  beep 1
end

Non è solo questione di efficienza o di leggibilità. La prima soluzione, grazie all'uso dell'indentazione, è leggibile quanto la seconda. Ma se provate a leggerla a voce alta . Il when è binario, l'if ternario. La prima versione è drammatica: c'è un crescendo, un fortissmo (beep 1) e un finale. La seconda versione è leggera come una filastrocca: non enfatizza nessun punto particolare e la fine arriva a sorpresa.
Scegliere l'una o l'altra dipende da gusti letterari, esperienze musicali. Oppure da preferenze grafiche: la prima versione ha il profilo diagonale di una vela, la seconda di una colonna compatta.
A proposito dell'indentazione: uno standard ormai universale al cui inventore non saremo mai abbastanza grati. È un micromodello che riportando in orizzontale la gerarchia dei livelli logici di una porzione di codice fornisce un appiglio visuale. Non si tratta solo di un aiuto visivo per non scordare parentesi aperte. Il modello sottostante, anche se implicito, è chiaro: il flusso del programma scende sui gradini delle tabulazione e degli accapo, fino ad un punto da dove non può far altro che risalire.
Eppure non è raro vedere codice (anche scritto da professionisti) del tipo:

if numero = 10; beep 3; else beep 1; end

che è più compatto ed equivalente per l'interprete, ma fa male alla pancia.

Equilibrio: le strutture di dati
Un programma resta in attesa dei dati, come un samurai in attesa dell'attacco dell'avversario. Attesa significa equilibrio. Ma se il suo equilibrio è statico, un flusso di dati superiore a quello previsto può causare un trabocco.
Invece un equilibrio dinamico significa capacità di adattarsi alle situazioni sconosciute.
Dichiarare le variabili all'inizio dell'handler è una prassi raccomandata da tutti. Ancora meglio se si dichiara anche il tipo della variabile, soprattutto quando così facendo si limita la quantità di risorse che il sistema deve riservare per quella variabile.
Per esempio, usare una string per memorizzare un valore logical (che può essere solo vero o falso) è uno spreco di risorse. O usare un real per rappresentare un intero.
Un altro esempio: un array statico è più efficiente e più ecologico di uno dinamico, perché alloca esattamente la memoria necessaria. Questo è il livello di qualità ecologico.
Da un altro punto di vista, le strutture rigide sono costose a crearsi e a modificarsi, anche se sono economiche durante l'uso quotidiano. Le strutture flessibili invece permettono al programma di adattarsi alla situazione, anche se richiedono risorse supplementari.
La struttura dati più dinamica è la lista. In alcuni linguaggi (il LISP ma anche il bistrattato LOGO, che da questo punto di vista è un signor linguaggio) è praticamente l'unico tipo di dati complesso. Una volta detto che le funzioni in LISP sono esse stesse liste, si capisce la potenza di questa impostazione.
Una lista non ha dimensioni predefinite, può contenere qualsiasi tipo di dato, anche mescolati fra loro. Openscript fornisce diverse primitive per accedere alle liste, tra cui i classici push e pop (il loro nome è dovuto alla funzione standard in uso negli anni '60), che sono molto più veloci di put e get. La limitazione più grossa all'uso delle liste è il fatto che il separatore debba per forza essere una virgola, il che impedisce di inserire stringe che contengono virgole all'interno di liste.

Un programma deve essere in condizione di risolvere le situazioni problematiche che si possono presentare nel corso della sua vita: dati di tipo errato, flusso di dati eccessivo, inattività prolungata, scarsezza di risorse, eccetera. Non è possibile prevedere tutte queste situazioni. Sarebbe anche contrario alla logica stessa della programmazione.

Il programmatore non deve risolvere tutti i problemi, ma costruire un programma che sia in grado di sbrigarsela da solo.

Flusso: il passaggio del controllo
Un buon programmatore si cura che il flusso del controllo nei suoi programmi sia regolare, forte, che tocchi tutti i punti del sistema, che fluisca attraverso di esso come il respiro.
La prima onda è l'inizializzazione. Alla partenza si eseguono tutte le operazioni che "risvegliano" il programma e lo preparano ad affrontare una nuova giornata.
Poi l'attesa - indefinita - di un evento; e in seguito all'evento, il flusso di messaggi che comunicano l'evento al sistema (su su su ...).

Come un boomerang torna al punto di partenza, così il messaggio dovrebbe tornare, in qualche forma, al mittente. C'è una ragione pratica, come al solito: così ci si assicura che tutto sia andato per il suo verso. Per questo spesso le funzioni ritornano, se non altro, almeno un codice d'errore. Ma c'è anche una ragione zen, per spiegare la quale mi lascerò andare a un po' di personalizzazione e animismo.
Immaginare un programma che respira aiuta a sentirsi uniti a lui; e la separazione, soprattutto affettiva, del programmatore dal programma (e in generale dal computer ) è il vizio di fondo che rende impossibile qualsiasi risultato pratico positivo nell'interazione con i computer. Un programmatore che miri a "fregare" il programma non farà mai un buon lavoro.
È lo stesso problema delle parti di codice commentate come test e poi lasciate per sempre lì, come cicatrici mai rimarginate. Non fanno male all'interprete, che le salta, ma dicono a chi legge che quel programma non è stato mai ripulito, è stato abbandonato non appena ha mostrato di reggersi sulle sue gambe. Come avrebbe detto Pirsig, c'è un solo modo di aggiustare una motocicletta: tenerci.

Torniamo al boomerang.
Ci sono due versioni di questo ritorno.
In pratica i due modelli possono essere implementati in openscript tanto con funzioni (to get) che con messaggi (to handle). La differenza sta più nel fatto che una funzione ha senso se il valore che torna è utilizzato Per esempio, l'algoritmo classico ricorsivo per l'inversione di una lista lavora su di un elemento della lista per volta e richiede che il lavoro sul resto della lista venga fatto da qualcun altro; alla fine la funzione restituisce un assemblaggio del proprio lavoro e di quello dell'altra funzione.
In questo caso particolare, la funzione passa il testimone a se stessa, ma questo affascinante avvitamento sul posto non crea nessun problema all'interprete, come potrete vedere se seguite l'esecuzione nella finestra di debug.

to get rovesciaFN lista
if itemcount(lista) is 1
  return lista
else
  pop lista into primo
  nuovalista = rovesciaFN(lista) &","& primo
  return nuovalista
end
end

Dal punto di vista dell'informatica tradizionale, il processore esegue una operazione alla volta (prefetch escluso). Nel modello classico, un processore ha una coda di istruzioni e indirizzi in ingresso e fornisce in uscita indirizzi.

Dal punto di vista del programmatore, il programma è fermo, ed è lo scenario, la mappa del territorio dove si svolge l'azione . In altre parole, c'è un punto di vista che si sposta in tutto il programma, in base ai percorsi che sono stati predisposti dal programmatore e in base al verificarsi di eventi.
In questo senso una rete ipertestuale non è un'applicazione particolare dell'informatica, è un modello della stessa programmazione.

La programmazione è un'opinione
Un problema può avere molte soluzioni diverse. E le soluzioni possono avere qualità diversa, dal punto di vista dell'efficienza, dell'ecologia e della qualità profonda.

Esempio: trovare il numero d'ordine di una lettera.
Confrontate queste tre soluzioni:

1. conditions
when lettera is "a"
  set numero to 1
when lettera is "b"
  set numero to 2
......

2.
set numero to (CharToAnsi(lettera) - 43)

3.
set numero to ItemOffset(lettera,"a,b,c,...")

La versione 1 è di comprensione immediata. Si può scrivere usando a ripetizione CTRL+C / CTRL+V. Però è ripetitiva, soggetta ad errore e poco manutenibile.
La 2 è efficiente, compatta, ma non evidente; si basa su di una proprietà (la tabella di codici ANSI) che è fortemente convenzionale e fissa.
La 3 è naturale, elegante e veloce. Si basa sull'ordine alfabetico, che è un fatto noto. Ma può essere modificata facilmente. Per esempio, se si dovesse usare un alfabeto diverso da quello americano (usato nell'ASCII) sarebbe facile modificarla. Crea un modello naturale della situazione (l'alfabeto) e manipola il modello.
Un programmatore esperto userebbe quasi sicuramente la 2. Questa soluzione consiste essenzialmente nel realizzare una black box, una macchina che risolva un problema dato.
La 3 invece è una rappresentazione di una situazione e la progettazione di una strategia per muoversi all'interno di questo spazio. Se cambia la situazione problematica, può essere facilmente modificata tanto la rappresentazione quanto la strategia.


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Toolbook è un linguaggio zen?

Un esercizio zen
In questo capitolo vi propongo un esercizio di qualità: provare a vedere TB come un linguaggio Object Oriented e usarlo il più possibile consistentemente con questa interpretazione.

Nella programmazione tradizionale si parte dagli obiettivi che si vogliono raggiungere, si studiano i dati disponibili e si cerca di costruire una macchina -astratta - che trasformi questi in quelli.
La programmazione a oggetti consente invece di rappresentare direttamente la maniera in cui una persona vede una situazione (oggetti dotati di proprietà e connessi fra loro).
Sui vantaggi in termini di efficienza ed ecologia di un approccio del genere non voglio entrare. Il vantaggio che mi interessa non è, ancora una volta, nel codice di per sé, ma nella maniera di interagire con il codice da parte del programmatore.
Se posso pensare al mio programma come una versione ridotta del mondo, posso anche utilizzare tutta la mia esperienza reale per inventare soluzioni.

Di sicuro TB non è un ambiente di programmazione completamente ad oggetti, come C++ o più ancora Smalltalk.
Tuttavia, la struttura di dati principale offerta dal sistema lo è: i libri possono essere pensati come classi di sfondi, gli sfondi come classi di pagine, le pagine come classi di oggetti.
Il sistema stesso potrebbe essere visto come un browser di classi di oggetti.
Naturalmente ci sono grosse limitazioni. Per esempio, non è possibile creare una nuova classe, ma solo istanze di classi già esistenti. Le classi non possono essere distrutte indipendentemente dai propri componenti. Eccetera.
Un modo semplice per simulare meglio le classi in TB è costituito invece dai gruppi di oggetti.

Gruppi come classi
I gruppi si comportano come classi da diversi punti di vista:
Si comportano come sottoclassi delle pagine o dei background, nel senso che non possono contenere oggetti di pagine o background diversi.
Inoltre, possono contenere solo oggetti grafici (bottoni, campi, rettangoli, linee, etc.)
Ma è sempre meglio di niente.

Per estendere il meccanismo dell'ereditarietà delle proprietà di sistema anche a proprietà utente, si può usare un handler ricorsivo di questo tipo:

to handle heritate propertyP,valueP
get my objects
while it is not null
    pop it into destVL
if object of destVL is group
    send heritate propertyP,valueP to destVL
else
    execute ("set"&& propertyP &&"of"&& destVL&&" to"&& valueP)
end
end
end

Normalmente, TB gestisce i messaggi secondo la regola "se non sai come fare, chiedi a tuo padre", ovvero un messaggio che non può essere gestito viene passato automaticamente alla classe superiore.
Un comportamento utile da simulare è quello per cui per inviare un messaggio a tutti gli oggetti di una classe è sufficiente inviarlo alla classe stessa.

to handle broadcast messageP
get my objects
while it is not null
    pop it into destVL
if object of destVL is group
    send broadcast messageP to destVL
else
    execute "send"&& messageP&& "to"&& destVL
end
end
end

Polimorfismo e altre diavolerie
A questo punto, se si vuole si può gestire il polimorfismo.
Per esempio, per assegnare una stringa agli oggetti di un gruppo, a prescindere dal fatto che siano bottoni o field, si può inserire il seguente handler nel gruppo.

to set mytext to stringaP
conditions
when object of target = button
    set caption of target to stringaP
when object of target = field
    set text of target to stringaP
end
end

L'uso di questo handler diretto è semplice:

set mytext of selection to "Questo è il mio testo"

ma va fatto per tutti gli oggetti, uno ad uno.
Per eseguirlo in una sola volta su tutti gli oggetti del gruppo invece:

send heritate mytext, "Questo è il mio testo" to group G1

È possibile anche mandare un messaggio a tutti i componenti di una classe, anche senza conoscerli esplicitamente.

Per esempio, se si volessero muovere tutti gli oggetti del gruppo a saltelli, uno per volta, si potrebbe scrivere questo handler:

to handle salta
x = 100
y = 100
move target by x,y
move target by -x,-y
move target by x,y
end

Ma invece di inviarlo oggetto per oggetto, è possibile passarlo a tutti gli oggetti del gruppo in una sola volta:

send broadcast hitch to group G1

Tutti questi handlers usano il comando execute, che invoca l'interprete su una stringa. Execute è molto lento, ma ha l'enorme vantaggio di permettere di eseguire codice openscript fornito dall'utente oppure generato a runtime.
In teoria, questo vuol dire che se il programma incontrasse una difficoltà per la quale non è stato adeguatamente attrezzato, potrebbe costruirsi da solo il codice necessario.

Si apre qui la possibilità di insegnare le zen non più ai programmatori ma direttamente ai programmi ;)


  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni

Conclusioni

Questo testo non ha la pretesa di oggettività di un contributo tecnico. Ma non è neanche un divertissement fine a se stesso. La sua natura leggera è in parte dovuta al tema e in parte agli eventi: durante il THUG il seminario non si è tenuto, a causa di una défaillance del suo relatore. Se ci fosse stato, alcune delle tesi proposte avrebbero potuto essere discusse direttamente, gli esempi sarebbero stati scritti a più mani e si sarebbe potute fare osservazioni sulle somiglianze e differenze.
Ma se questo testo avrà suscitato interesse o dubbi, allora se ne potrà parlare al prossimo THUG, nel corso del seminario - reale, questa volta - sullo "Zen e l'arte della programmazione".

  Introduzione - Il Manuale del Programmatore Zen
  Ecologia del codice - Zen e qualità - Zen e computer
  Toolbook è un linguaggio zen? - Conclusioni