Digi Tales

Garibaldi e i linguaggi napoleonici

Mag
18

I programmatori, a differenza degli eroi, sono persone normali, anche se a volte non sembra. Come tutte le persone normali hanno preferenze, fastidi, passioni, fobie. Queste idiosincrasie del tutto umane vengono applicate ai linguaggi di programmazione, agli strumenti per scrivere programmi, agli stili in cui si scrivono. Per questo, forse, sono stati creati così tanti linguaggi di programmazione (circa 8.000).

Una delle discussioni che durano da più tempo è quella sul modo migliore per programmare. In breve, si tratta della metafora generale con cui si pensa al rapporto tra umano e computer durante la programmazione. Ci sono almeno questi quattro modi maggiori:

Napoleonicol’umano ordina e il computer esegue
Aristotelicol’umano definisce regole e fatti e il computer trae le conseguenze e dimostra teoremi
Leibnizianol’umano progetta funzioni e il computer le calcola
Shakespearianol’umano descrive una situazione in cui degli attori che hanno una conoscenza limitata del mondo sanno compiere alcune azioni e interagire tra loro; il computer sovraintende a questa sessione

Il primo modo è quello che si insegna di solito per primo, ed è anche quello che spesso viene usato per definire il significato di “computazionale”: ci si immedesima nel computer e si cerca di descrivere come farebbe a risolvere il problema con le informazioni che ha. Gli altri modi cercano di venire incontro agli umani, al nostro modo di pensare. Il vantaggio di questi altri paradigmi dal punto di vista didattico è che permettono di scrivere un programma in maniera più naturale, descrivendo il problema, anziché la soluzione. Sono i computer a dover avvicinarsi agli umani, non viceversa. E questo vale anche, e soprattutto, quando si fa coding con dei ragazzini.

Snap! permette molti modi (tranne quello Aristotelico), anche se i suoi autori mostrano una preferenza spiccata per il terzo modo, quello Leibniziano. Nota: il nome tradizionale per questi modi è “paradigma”, e di solito si usano etichette un po’ meno fantasiose per indicarli. Ma qui non stiamo facendo un corso di informatica.

Siccome queste sono parole un po’ astratte, facciamo qualche esempio.

Il contesto è la canzoncina “Garibaldi fu ferito” che una volta i bambini sapevano a memoria e cantavano sull’aria della Canzone dei Bersaglieri. Il gioco era quello di sostituire tutte le vocali delle parole con una sola, ottenendo ad esempio “Garabalda fa farata” oppure “Gurubuldu fu furutu”, eccetera. I bambini sanno farlo, anche se non sanno esattamente dire come. Prima di continuare potete provare anche voi, e interrogarvi su come avete fatto.

Come facciamo per far fare la stessa operazione ad un computer? Per quello che abbiamo detto sopra, non c’è un solo modo, né un modo “giusto” (questo è uno dei motivi per cui fare coding ha un senso forte solo se non ci si limita a ricopiare tutorial e eseguire esercizi). Possiamo provare a seguire almeno tre strade diverse, per poi magari valutarne la semplicità, l’utilità in termini didattici, e se fossimo informatici anche l’efficienza.

I blocchetti realizzati in Snap! delle varie versioni potete vederli e provarli direttamente da qui:

https://snap.berkeley.edu/project?user=stefano63&project=Garibaldi%20fu%20ferito

Prima versione, imperativa

  1. prendi il testo della canzoncina
  2. conta la lunghezza del testo il lettere (sono 90)
  3. prepara una variabile – vuota – dove andrà a finire la versione trasformata
  4. prepara una variabile che servirà a contare le lettere e mettici dentro 1
  5. ripeti novanta volte:
    1. prendi la lettera I del testo
    2. se è una vocale, sostituiscila con la A, e mettila all’inizio della variabile finale
    3. altrimenti, metti la lettera originale all’inizio della variabile finale
    4. aumenta I di 1
  6. quando hai finito, restituisci la versione trasformata

La parte da 5.2 a 5.3 può essere affidata ad una funzione a parte (l’abbiamo chiamata “cambia vocale con…”) per evitare di rendere i blocchetti troppo complicati da leggere. E’ una funzione molto semplice, che si limita a verificare che una lettera sia una di queste: a,e,i,o,u. Non tiene conto delle maiuscole né delle vocali accentate.

Seconda versione, ricorsiva

Un’altra versione possibile è quella che sfrutta una caratteristica di alcuni linguaggi di programmazione, cioè la possibilità di richiamare una funzione al suo stesso interno. In pratica, si usa la tecnica di dividere un problema in sotto-problemi sempre più piccoli finché non si arriva ad un problema risolvibile.

In questo caso, sappiamo come trasformare una lettera (con la funzione “cambia vocale con”) ma non sappiamo come trasformare un intero testo.

  1. se la frase ha lunghezza 1 (cioè è se è composta da una sola lettera) si applica la funzione “cambia vocale con” e si restituisce il risultato (questo è il passo in cui sappiamo come risolvere il problema);
  2. altrimenti, si chiama di nuovo la stessa funzione “cambia frase” ma passando due valori diversi:
  • la prima lettera della frase
  • tutto il resto della frase
  1. si unisce il risultato che proviene da queste due funzioni e lo si restituisce

Una volta superato lo shock di un programma che non si capisce come fa a funzionare, la soluzione è di una semplicità imbarazzante.

Terza versione, funzionale

In questo caso si sfruttano due caratteristiche di Snap!, tipiche dei linguaggi funzionali:

  • la possibilità di applicare una funzione su tutti gli elementi di una lista, uno per uno, ottenendo una nuova lista
  • la possibilità di ridurre una lista ad un solo elemento, applicando un’operazione agli elementi, due alla volta.

Anche in questo caso l’algoritmo è molto semplice ed è basato su una concatenazione di funzioni:

  1. si applica la funzione “cambia vocale ” alla lista ottenuta separando la frase ad ogni lettera
  2. si combinano gli elementi di questa lista in una nuova frase e la si restituisce

Preferenze per uno dei tre? Quale vi sembra più chiaro? Quale vi sta più simpatico?

A me, personalmente, l’ultimo. Proprio perché non si perde a misurare, a tenere il conto del punto in cui siamo arrivati, non ha bisogno di appoggiare il risultato parziale da qualche parte. In fondo non fa altro che trasformare in blocchetti quello che volevamo fare: applicare una trasformazione a tutte le vocali di un testo.

A proposito: che ne è di quel famoso adagio “I computer sono stupidi, sanno fare solo una cosa e la fanno sempre nello stesso modo”?

Ambiguità felice dei linguaggi

Feb
23

C’è una barzelletta che gira da tempo sui programmatori, esseri inadatti al mondo reale. Dice così:

La mamma dice a Pierino: vai al mercato e compra 2 litri di latte. Se ci sono le uova, comprane 6.
Pierino va e torna con 6 litri di latte.
La mamma: Perché hai comprato 6 litri di latte?
Pierino: Perché c’erano le uova.

Finite le risate per la risposta di Pierino (che immaginiamo essere il risultato di una specie di programma: IF ci sono le uova THEN comprane 6), ci accorgiamo che il problema è in quella particella “ne”, che è un riferimento pronominale. Di quelle cose che abbiamo detto prima. Un link, una URL relativa.
In Italiano, di solito, si riferisce all’ultimo sostantivo utilizzato. Quando ce ne sono più di uno (di che? di sostantivi) di solito con un minimo di interpretazione si capisce a quale ci si riferisce.
Se la mamma avesse detto:
[…] Se c’è lo zucchero, comprane 6 litri.
un parlante Italiano avrebbe capito che il riferimento era al latte, perché sa che lo zucchero non si vende a litri.

E’ uno degli aspetti tipici del linguaggio naturale: un riferimento generico può essere comodo in molti casi, ma può creare dubbi in altri. Dubbi che vanno risolti con delle ipotesi, oppure nell’interazione (“Scusa, mamma: 6 di cosa?”).

Si dice che i linguaggi di programmazione, essendo “formali”, non soffrono di queste malattie, anzi sono stati costruiti apposto per esserne immuni. La barzelletta prende in giro proprio questa ottusità dei computer, dei linguaggi, dei programmi. I computer non interpretano i programmi, ma li eseguono rigidamente. Per cui niente libertà, niente interpretazione, niente poesia, solo correttezza e efficienza.

Ma siamo proprio sicuri che sia così? Facciamo un gioco: traduciamo la storiella in un linguaggio molto usato per il web, ovvero PHP (tranquilli: il discorso può essere seguito da chiunque, anche senza nessuna competenza informatica).

$lista = Array (
 latte => 1,
 uova => 6
 );

In questo frammento di codice sorgente viene creato un dizionario ($lista), cioè una set di dati organizzati per coppie chiave/valore (latte=1, uova=6).
Ci si mettono dentro le informazioni e poi si possono estrarre quando servono.
Scrivendo così:

 print_r($lista);

possiamo vedere cosa c’è dentro $lista:

Array
(
    [uova] => 6
    [latte] => 1
)

Oppure, volendo andare più in dettaglio:

 
print_r($lista[latte]);

cioè: scrivi sullo schermo il valore della chiave “latte” nell’array $lista.
Che è, ovviamente, 1.

Se però guardiamo cosa succede dietro le quinte, ci accorgiamo che l’interprete ha segnalato due errori veniali:

PHP Notice: Use of undefined constant latte - assumed 'latte'
PHP Notice: Use of undefined constant uova - assumed 'uova'

E’ un nostro errore di scrittura: le chiavi sono state scritte come se fossero costanti (cioè senza le virgolette che invece accompagnano le stringhe di caratteri), ma non esiste nessuna costante che si chiama latte, né uova. Ma cosa ha fatto l’interprete PHP, oltre a segnalare l’errore? Ha fatto un’illazione, cioè ha supposto che si volesse scrivere:

'latte' =>1,
'uova' => 6

che sembra in effetti l’interpretazione più ragionevole.

Se siamo bravi programmatori e programmatrici, una volta letta la segnalazione correggiamo il codice, e tutto fila liscio.
Anzi, per essere ancora più precisini, creiamo una costante (visto che ci era stato chiesto), ma le diamo un valore un po’ bizzarro:

define('latte',uova);

Cioè: abbiamo definito una costante che ha come nome “latte”, ma come valore “uova”.
Vi sembra confondente? Ma il linguaggi di programmazione sono precisi, no? Quindi nessun problema: da un lato la costante, dall’altro la chiave.
E infatti, se avessimo lasciato le cose come stavano, non ci sarebbero stati problemi. Ma noi abbiamo voluto essere rigorosi e abbiamo creato la costante E messo gli apici intorno alle chiavi.
Ora se chiediamo:

print_r(latte);

(ovvero: qual è il valore della costante “latte”?), otteniamo la stringa “uova”, come prevedibile; mentre se chiediamo di nuovo:

print_r($lista[latte]);

il risultato non è né “uova”, né 1 ma …  6 !
Il che naturalmente ha una sua logica. Si potrebbe dire che l’interprete ha usato il riferimento pronominale nella nostra richiesta, e ha interpretato la chiave dell’array $lista[latte] come la costante “latte” che era stata definita prima. Ma non è quello che volevamo dire. Insomma, dal nostro punto di vista,  si confonde e restituisce 6, cioè interpreta il codice come se avessimo scritto:

print_r($lista[uova]);

Proprio come Pierino.

Ora cambiamo l’ordine delle chiavi:

$lista = Array (
 'uova' => 6,
 'latte' => 1
 );

e chiediamo di nuovo:

print_r($lista[latte]);

Dovrebbe essere uguale a prima, no?
Eh no, adesso il valore restituito è tornato ad essere 1!
Meglio, dite? Insomma… se provate a scrivere:

print_r($lista);

vi accorgete del pasticcio:

Array
(
    [uova] => 1
)

La chiave latte è stata sostituita da uova (con valore 1) e la chiave uova, che avevamo inserito con valore 6, è stata cancellata.

Certo PHP non è un modello di precisione, per un linguaggio di programmazione. Ma insomma: anche un linguaggio di programmazione è soggetto ad una forma di ambiguità referenziale. E questo dipende, come abbiamo visto, dall’ordine in cui vengono inserite le informazioni nel testo.
Come in una qualsiasi lingua naturale…