steve's

Critical Code Studies

Gen
20

Critical Code Studies è un’etichetta che copre le attività di discussione e studio del codice sorgente che si svolgono presso l’Università della Southern California (Humanities and Critical Code Studies Lab, HaCCS).

Oggetto di studio sono i codici sorgente, cioè quella cosa scritta da umani (per lo più) e che poi viene eseguita dai computer, telefoni, satelliti, droni, etc. Solo che, avete letto bene, non è il dipartimento di Computer Science che se ne occupa.

“Critical” è un termine chiave. Si può leggere in due modi: il primo è come parallelismo alla critica letteraria, cioè come richiamo all’utilizzo di approcci e tecniche che finora sono state applicate ai testi tradizionali (digitalizzati o meno). Significa che i codice sorgenti vengono trattati come opere, con una dignità che va oltre quella di pure macchine strumentali fatte di codici binari. Un codice sorgente è scritto in un linguaggio (uno dei circa 2500 censiti), e viene non solo scritto per essere “interpretato” dal computer, ma anche per essere letto, discusso, modificato, copiato. E – come è normale per ogni prodotto di scrittura – presenta aspetti estetici, stilistici, retorici. Se esistono poesie scritte in linguaggi di programmazione (la prestigiosa e serissima Stanford University fa annualmente un concorso, http://stanford.edu/~mkagen/codepoetryslam/), virus presentati come opere d’arte http://0100101110101101.org/biennale-py/, programmi scritti per sfidare il lettore alla loro comprensione http://ioccc.org/, linguaggi in cui si programma usando i colori in omaggio a Mondrian http://progopedia.com/language/piet/, significherà pure qualcosa.

L’altro senso di “Critical” è più forte: indica che non ci si vuole limitare a studiare i testi, ma anche i contesti della loro produzione e uso. Significa che l’approccio usato vuole tener conto anche delle questioni di genere, di cultura, di divario economico. Perché non basta allenare i bambini al pensiero algoritmico: il software è qualcosa di ben più complesso di un algoritmo che muove un pupazzetto su uno schermo.

Per farsi un’idea, si può leggere questa introduzione di Mark Marino, del 2006: http://www.electronicbookreview.com/thread/electropoetics/codology

Trovate tanti riferimenti alle persone che hanno riflettuto su questo tema: da John Cayley a Florian Cramer, Loss Pequeño Glazier, Geoff Cox, Alex McClean, Adrian Ward.

A partire dal 2010, viene tenuto annualmente un Working Group (http://haccslab.com/) dove si possono discutere online frammenti di codice. Quello di quest’anno è appena cominciato.

Tutto questo accade a Los Angeles, USA.

Qui da noi, sono anni – almeno dal 1999 – che cerco di impostare un lavoro simile (con seminari, articoli, slide, wiki: http://ada.lynxlab.com/staff/steve/public/docu/lidia/), ma ahimé senza molto successo. Ma sono io che ho sbagliato Paese.

 

Perche’ i bambini devono imparare a programmare

Dic
18

Mi sono avvicinato al tema “applicazioni didattiche del digitale” per ragione emotive, estetiche. Cioè perché mi affascinava l’idea. Non avevo nessuna conoscenza e nessuna competenza. Venivo da studi classici e da una laurea in Filosofia. Fine anni ottanta.

Ho comprato un PC (senza sistema operativo) e ho cercato di vedere quello che si poteva fare. Ho letto il leggibile, ho riflettuto, ho sperimentato.

Il primo risultato della riflessione è stato: per usare i computer per l’educazione bisogna prima capire cosa è l’educazione. E prima ancora, cos’è l’apprendimento, visto che l’educazione si suppone serva a migliorare e favorire l’apprendimento.

Sono arrivato (attraverso Dewey e altre letture) all’idea che l’apprendimento non è un fenomeno di introiezione di informazioni, ma nemmeno di costruzione di strutture mentali. E’ una ristrutturazione dell’ambiente, proprio quello esterno. Nel mondo reale è difficile farlo; l’ambiente educativo è invece uno spazio/tempo progettato apposta per permettere questa ristrutturazione, e per gestirla insieme a chi apprende. Ristrutturazione che si scontra con limiti, che vengono spinti sempre più oltre. Ma che nel mondo fisico, ben presto diventano ostacoli insormontabili.

A questo punto viene in aiuto il digitale, che ha molti meno limiti. Come parte di un ambiente educativo, gli artefatti digitali (programmi, dispositivi) devono essere costruiti in modo da facilitare questa modifica dell’ambiente. Devono essere modificabili da chi li usa. Quindi come minimo si deve dare all’utente (ma che brutta parola!) la possibilità di capire come cambiarli per adeguarli. Quindi interfacce riconfigurabili a piacere, modalità operative che si possono incrementare.

L’attività di modifica di un oggetto digitale in generale si chiama programmazione. E a differenza della modifica degli oggetti fisici non ha praticamente limiti.

Quest’attivita è – o dovrebbe essere – la maniera fondamentale, in un ambiente educativo, per interagire con il software. Qualsiasi software: che sia un gioco o un programma di videoscrittura (sono i campi dove ho fatto un po’ di esperimenti), o per fare calcoli, o simulazioni, etc etc. E i software devono essere costruiti in modo da permetterlo, a diversi livelli. Tecnicamente e legalmente. Trascinando pannelli o programmando.

 

L’obiettivo non è imparare a programmare, né per assicurarsi un futuro, né per sviluppare abilità logico-matematiche. L’obiettivo è imparare meglio con strumenti che sono pensati apposta per questo.

Creative computing from scratch

Dic
13

Scratch è ormai diventato una moda. Quando si parla di “coding”, di programmazione per bambini, si parla inevitabilmente di Scratch. Questa equazione mi infastidisce un po’, come se non si potesse giocare con la programmazione in altro modo, come se Scratch avesse una patente speciale e tutto il resto non fosse mai esistito. Questo naturalmente non è colpa di Scratch e dei suoi creatori, ma è una miopia tutta nostra. Probabilmente in Italia non è chiaro nemmeno il significato del nome: “scratch” è la linea di partenza di una corsa. Costruire qualcosa “from scratch” significa cominciare da zero.

Penso di fare un servizio utile provando a fare un po’ di chiarezza intorno al tema, all’oggetto Scratch e al suo modello didattico. Credo che chiunque voglia organizzare un pomeriggio di gioco con Scratch – ma come ho già scritto in precedenza, non basta un pomeriggio – dovrebbe almeno riflettere un po’ su questi argomenti.

 

Perché Scratch? Cosa ha di particolare? Almeno due aspetti mi sembrano alla base della sua fortuna. Ed entrambi meritano analisi e discussione.

  1. Il fatto che intorno a Scratch ci sia una comunità internazionale. Scratch è una “online community where children program and share interactive stories, games, and animations”. Bisogna quindi essere necessariamente connessi per programmare? In realtà esiste un editor offline, basato su Adobe Air. E’ una scelta strana per il MIT; né Adobe Air né l’editor offline sono OpenSource (a differenza di quasi tutti gli altri ambienti dello stesso genere). Non ho idea di quanti usino la versione offline, talmente è più facile utilizzare la versione online. In ogni caso c’erano, e ci sono ancora, anche altre comunità dello stesso genere. Quasi ognuno degli ambienti di programmazione per bambini ha un team di sviluppo che mantiene un sito con esempi, suggerimenti, guide. La comunità intorno a Scratch è la più recente, probabilmente la più attiva, non necessariamente la più interessante. Potrebbe valere la pena andare a curiosare anche nelle altre.
  2. Il fatto che non sia necessario scrivere codice sorgente (il che è piuttosto curioso, visto l’uso continuo del termine “coding”). La questione è rilevante. Uno dei passaggi chiave nella storia degli ambienti di programmazione per bambini è proprio il passaggio dalla scrittura di codice alla programmazione visuale. Significa che invece di scrivere “if questo then quest’altro” il programmatore deve trascinare oggetti grafici, disporli in un certo ordine, e scrivere solo dati all’interno di buchi (le variabili). La sintassi è affidata alla posizione degli oggetti, la semantica alla scrittura. Ci sono enormi vantaggi: il rischio di commettere errori di sintassi è annullato, la struttura del codice è rappresentata in forma visuale ed è più comprensibile con uno sguardo d’insieme. Si introduce però uno iato forte tra l’attività presente (visuale) e quella futura (scrittura). Infatti gli ambienti di programmazione visuale per adulti professionisti sono piuttosto pochi, dedicati di solito a domini specifici come il multimedia e, nel 99% dei casi, un programmatore scrive o modifica codice scritto. Ci sono degli evidenti vantaggi anche nell’uso della scrittura: un codice scritto in qualsiasi epoca e in qualsiasi linguaggio può essere modificato con un editor di testo (se la licenza lo permette). E abituarsi a leggere e rileggere, vale per un testo scritto in una lingua naturale come per un codice sorgente, non è un’attività poco utile nella vita.

Scratch nasce al MIT nel 2003 con un grant della NSF, in collaborazione con diverse altre università statunitensi (Pennsylvania, Harvard, Washington e altre). Tra i ringraziamenti, vengono citati Seymour Papert e Alan Kay, ovvero l’autore del LOGO e uno degli inventori della programmazione orientata agli oggetti e delle finestre, nonché di Squeak, Etoys e Tweak.

La storia degli ambienti di programmazione per bambini – in cui Scratch affonda le radici – è infatti molto lunga. A partire dal LOGO (1967 !) e i suoi derivati (StarLogo/NetLogo, 1999) passando per ToonTalk (1992), Stagecast Creator  (1996),  SmallTalk/Squeak/ (1996), Etoys (1997), Alice (1999),  fino al recente AppInventor per Android (2010). Una lista completa la trovate qui: http://en.wikipedia.org/wiki/Visual_programming_language.

Ognuno ha delle particolarità interessanti. Ad esempio Alice era basata sul modello della programmazione orientata agli oggetti, NetLogo sugli agenti concorrenti, Stagecast Creator sulle programmazione per regole. Sono tutti modelli alternativi alla programmazione “imperativa” (che è la più vecchia, quella in cui si comanda il computer con istruzioni e test, IF_THEN_ELSE), modelli che oggi sono studiati ed adottati su larga scala.

L’autorità principale dietro Scratch, Mitch Resnik (LEGO professor al MIT Media Lab), parla degli obiettivi del progetto in questi termini: “Quando qualcuno impara a programmare con Scratch impara allo stesso tempo importanti strategie per risolvere problemi, creare progetti e comunicare le proprie idee.” Le stesse idee sono espresse nella guida del 2011 pubblicata dall’Università di Harvard (http://scratched.gse.harvard.edu/sites/default/files/CurriculumGuide-v20110923.pdf). La guida è una miniera di idee e contenuti, declinati in 20 sessioni didattiche. Nell’introduzione si dice fra l’altro:

“Engaging in the creation of computational artifacts prepares young people for more than careers as computer scientists or as programmers. It supports young people’s development as computational thinkers – individuals who can draw on computational concepts, practices, and perspectives in all aspects of their lives, across disciplines and contexts.”

Il pensiero computazionale (traduzione dubbia; ma in questi casi è difficile resistere al calco) è quindi visto come una maniera di affrontare i problemi della vita, attraverso concetti come sequenze, cicli, parallelismo, eventi, condizioni, operatori e dati. Le pratiche che vengono incoraggiate come più adatte sono “essere iterativi e incrementali, verificare e correggere, riusare e mescolare, astrarre e modulare”.

Da un lato questa visione mi attrae, dall’altra devo confessare un po’ di spavento. Davvero i problemi reali vanno affrontati in termini di algoritmi formalizzabili? Davvero le azioni nei complessi contesti quotidiani vanno regolate in funzione di condizioni, operatori e dati? I bambini devono giocosamente imparare a comportarsi nella vita come automi perfettamente informati?

Persino l’idea dell’introduzione giocosa alla programmazione, per preparare i futuri sviluppatori di cui avremo bisogno nei prossimi dieci anni, andrebbe esaminata un po’ di più prima di essere accettata come una verità incontestabile. Non solo perché nel comparto informatico ci serviranno molte figure professionali diverse dagli sviluppatori; e non solo perché la programmazione richiede tanta creatività nell’inventare quanta abilità nel portare a termine l’idea.

Il punto centrale, il fulcro, è la strategia didattica.

Che “chi impara prima, impara meglio”, sembra essere un proverbio uscito dalla saggezza popolare, e quindi poco discutibile. Per diventare un musicista, un ballerino, un calciatore, un cantante, bisogna cominciare da bambini. Vale anche per le lingue straniere, vale anche per la matematica. Lo sappiamo per esperienza. Vale anche per la programmazione dei computer? Beh, qui troppi dati statistici non ci sono, dobbiamo procedere per analogia; e le analogie vanno tenute sotto controllo perché tendono a sfuggire.

Come si insegna ad un bambino una materia complessa, composta di tecnica e conoscenze, senza che le difficoltà impediscano i progressi?

Tradizionalmente, abbassando il livello della qualità richiesta, semplificando gli obiettivi, ma lasciando intatti gli elementi e le regole. Non si insegna ad una bambina di sei anni a suonare il violino con uno strumento con due sole corde, ma con un violino ¾, che ha la stessa complessità di uno 4/4 . Ma c’è una sterminata letteratura didattica composta per guidare lo studente dal facile al difficile. Non si semplifica il contesto, si modulano le richieste. La strategia didattica è lineare: c’è una gradazione infinita di modi di far vibrare una corda, e chi apprende procede lungo questo sentiero infinito. Limiti: la bambina si annoia, soprattutto se non capisce dove la porterà questa lunga strada, perché i risultati iniziali non sono troppo incoraggianti. Finirà probabilmente per abbandonare.

C’è un altro modo, più moderno: si crea un ambiente “didattico”, semplificato, in cui elementi e regole sono ridotti rispetto all’originale. Un flauto con i tasti invece dei fori; un toy piano diatonico. Qui i risultati gradevoli si raggiungono presto, la motivazione è rafforzata.

Questi giocattoli educativi non sono in continuità con il mondo reale. C’è una cesura netta: da un lato il giocattolo, dall’altro lo strumento vero, da un lato gli spartiti colorati, dall’altro i pentagrammi.

Questa strategia è senz’altro più efficace per iniziare, è più “democratica”, ha successo nella quasi totalità dei casi. Non serve a preparare musicisti professionisti, ma a comunicare l’amore per la musica (per esempio, io ho cominciato a suonare su un pianoforte giocattolo, e da allora amo disturbare il vicinato con ogni tipo di strumento – per questo vivo in campagna). E’ molto chiaro che non c’è un passaggio graduale dal modo “semplificato” a quello “avanzato”. Sono due mondi diversi, che si assomigliano in alcune parti, ma che non sono in connessione diretta. Alcuni degli studenti arrivati ai confini di uno si affacceranno sull’altro, si accorgeranno che la complessità è enormemente più elevata, ma decideranno di entrare lo stesso; altri si fermeranno nel primo mondo, come ho fatto io.

Tra gli ambienti di programmazione per bambini, però, alcuni sono stati pensati proprio come un raccordo, una via di mezzo tra i giocattoli e le cose serie. Sono ambienti dinamici, modificabili, evolutivi, in cui il bambino può iniziare in un contesto semplice e poi aggiungere complessità fino ad arrivare all’editor testuale di codice sorgente che è identico a quello del programmatore professionista. Questo è uno dei motivi per cui gli oggetti digitali sono più potenti di quelli fisici.

Ora, quali sono gli obiettivi di Scratch? Apparentemente, due: preparare futuri programmatori e iniziare i bambini all’amore per il computational thinking.

E la strategia didattica dietro Scratch, di quale delle due categorie delineate sopra fa parte? Direi della seconda, visto che l’ambiente che si propone è giocoso, facile, divertente, ma non ha le stesse regole del “mondo adulto” della programmazione. Non si scrive e legge codice. Non ci si preoccupa della correttezza sintattica. Non ci si preoccupa dell’efficienza, della velocità, della comprensibilità, della standardizzazione, dello stile, etc etc. Non c’è niente di male, come non c’è niente di male in un toy piano. Ma solo nei fumetti Schroeder suona Beethoven con quello.

Il problema nasce proprio quando si immagina che entrambi gli obiettivi possano essere raggiunti con una sola strategia, ovvero quando questa differenza di approcci strategici non viene proprio percepita,  cioè quando si pensa che iniziare a programmare con Scratch sia solo il gradino più basso di una scala che porta, gradualmente, alla produzione dei software che usiamo ogni minuto. E questo è tipicamente un errore di chi non ha una grande esperienza della programmazione.

Programmare non è solo un po’ più difficile di creare un gioco con Scratch, è enormemente più complesso; come realizzare un film o registrare un concerto non è solo un po’ più difficile di girare un video con uno smartphone.

Personalmente ho visto tanti bambini (studenti, figli, figli di amici) giocare con ambienti di programmazione fatti apposta per costruire giochi. Di tutti questi, solo uno, che io sappia, ha avuto la voglia e la costanza di continuare. Gli altri, quando hanno capito che programmare è difficile, si sono arresi e sono tornati a giocare.

____

Ci sono infine alcune domande che credo sia importante porsi quando si inizia un progetto didattico con Scratch.

1. Possono condurre un curriculum (nel senso di un progetto didattico) basato su Scratch anche docenti che non sono informatici di estrazione? Non è ovvia la risposta. Nel senso che le competenze tecniche per usare e far usare Scratch sono ovviamente molto basse. Ma non avere il background necessario potrebbe essere un limite grosso quando si cerca di espandere le idee e i concetti di Scratch e applicarle al mondo quotidiano (gli smartphone, il web, i programmi per PC). Non significa che solo i laureati in informatica possono condurre un laboratorio Scratch. Servono competenze pedagogiche, capacità di giocare insieme ai bambini e competenze informatiche.

2. Le idee dietro Scratch hanno una lunga storia, quasi tutta scritta negli Stati Uniti, quindi legata a quel modello educativo e sociale. Possiamo prenderle in prestito così come sono o possiamo/dobbiamo pensare ad un adattamento europeo e italiano? Ad esempio, se il peso delle attività di scrittura/lettura è diverso nei curricula statunitensi e italiani dei primi anni scolastici, non dobbiamo tenerne conto?

3. Perché dobbiamo sempre ricominciare “from scratch”? Ci sono, in tutto il mondo, migliaia di esperienze di introduzione alla programmazione con altri linguaggi e ambienti, in Italia almeno a partire dagli anni ’80. Possiamo ritrovarli, studiarli, verificarne i risultati? Potremmo, ad esempio, andare a vedere quali effetti hanno avuto nel tempo sui bambini coinvolti (quanti hanno scelto l’informatica come professione, quanti riconoscono un valore a quelle esperienze)?

Insomma, mi sembra che ci sia ancora tanto da fare e tanto su cui riflettere.

Cos’e’ la programmazione

Nov
15

Dopo la lettura di un articolo di El País (tradotto e ripubblicato sul Venerdì di Repubblica di questa settimana) sul recupero dei giovani cinesi videogame-dipendenti, in cui si cerca di spiegare  il desiderio dei diciassettenni maschi, figli unici di dipendenti pubblici, di perdersi nei meandri virtuali di un universo dove finalmente qualcuno ne riconosca le qualità facendo ricorso alla eccessiva durezza dell’educazione familiare tradizionale e il poco affetto ricevuto, ho capito finalmente cos’è la programmazione. Un attimo di pazienza e lo dico anche a voi.

Il (anche la, certo, ma molto più spesso il) programmatore è un tizio che passa molte ore davanti ad un  monitor. Però va detto che quando ha un problema da risolvere continua a pensarci ininterrottamente, anche se visto da fuori sta facendo altro, come mangiare o dormire o parlare con voi. Non è un teorico, non cerca l’intuizione essenziale, ma proprio la soluzione pratica. E  dopo averla trovata ne subisce l’incantamento narcisistico e  la raffina e ritocca e la ottimizza finché qualcuno non lo scuote e lo invita  a passare ad altro.

Non ama lavorare in batteria, ma gli piacciono i team stretti dove spalla a spalla si arriva più in alto, come nelle piramidi umane del circo.

Il programmatore costruisce universi,  dà un nome alle cose e le porta all’esistenza. Stabilisce genealogie, crea discendenze e parentele. Ma disegna anche gli scenari dove questi nuovi enti dovranno dispiegare le loro azioni. Storia, geografica, fisica: tutto dipende da lui, niente gli sfugge, o almeno così pensa.

Perché il programmatore sente il bisogno irrefrenabile di controllare l’universo che ha costruito, di cui è l’unico Demiurgo. E non si contenta di stare a guardare da fuori: lancia il programma in modalità debug  e lo segue, letteralmente passo dopo passo, anzi lo spia, fino a immaginarsi avatar,  di qua e di là dello schermo (“per ora va bene, ho tutto quello che mi serve, ora vado avanti, vediamo che succede”). Cerca il bug, ma non con lo spirito dell’entomologo, piuttosto come un regista che impersoni  direttamente sulla scena un personaggio per vedere cos’è che non funziona delle sue battute.

Cosa farebbe se non potesse programmare? come darebbe sfogo a questa esigenza viscerale, forse infantile, di possedere un universo tutto suo, sicuro,  senza imposizioni esterne, senza competizioni, senza delusioni e tradimenti?

Programmare è il suo modo di soddisfare questo bisogno, tutto sommato senza fare troppi danni, almeno paragonati a quelli che combina chi si mette in testa di fondare un impero. E’ un’attività riconosciuta come socialmente utile, perciò si viene anche pagati – limitatamente. Mentre si evita che il disturbo esploda, si ottengono anche sottoprodotti, a volte pregevoli, detti “programmi”.

Insomma, è chiaro: la programmazione è una terapia.

Che significa Code Week? (in difesa della conoscenza della lingua del digitale)

Ott
18

C’è una certo fastidio diffuso, per lo meno tra i miei amici e conoscenti, per l’esterofilia linguistica e gli stranierismi (leggi anglicismi, leggi meglio americanismi) usati nell’universo educativo.

Ci sono due aree linguistiche fondamentali che sono responsabili di questo male endemico: il business (americanismo) e l’informatica (“computer science” da noi non ha attecchito). In entrambi i casi si tratta di parole che viaggiano insieme ai discorsi, ed entrambi questi discorsi sono nati e si sono sviluppati da sempre in ambiente angloamericano.

Che questi due discorsi, insieme alle loro parole-vessillo, si impongano anche in un ambito diverso, quello educativo, è in effetti un problema grave. Pensare l’educazione in termini di competitività, di target, di budget, è indice di un più generale assetto di valori che si può criticare. Usare le parole dell’informatica in lingua originale anche dentro la scuola forse è meno grave perché finora non si è assistito ad un ripensamento dell’educazione in termini algoritmi, programmi e architetture di rete. Tuttavia anche qui c’è chi si domanda perché usare email invece di posta elettronica, streaming invece di diretta, BYOL invece di PITC (Porta Il Tuo Computer), etc… Chi usa il termine originale vuole mostrare di essere aggiornato, e vuole concedere all’ascoltatore la stessa patente (“qui siamo tra esperti, sappiamo tutti cos’è il digital divide”). E a volte invece l’uso di queste espressioni è proprio causa di divisione e genera incomprensioni; ma nessuno ammetterebbe di non sapere esattamente cosa significa HTTP, parola che digita tutti i giorni.

Ora però – anche alla luce delle riflessioni che facevo qualche giorno fa sullo stesso tema, anche se forse non era troppo evidente – vorrei provare ad approfondire un po’ il discorso.

Alcune delle parole sotto accusa sono difficili da tradurre in maniera sintetica (provate con “debriefing”), ma d’altra parte non sempre essere sintetici è un valore. Altre sembrano proprio un esercizio gratuito di pigrizia (“screensaver” non è un termine tecnico). In altri casi la traduzione italiana esiste, ma non è detto che abbia proprio lo stesso valore.

Per esempio confrontiamo i vocaboli “calcolatore” e “computer”. Hanno esattamente lo stesso significato, nel senso che dovunque si usa il primo si potrebbe usare il secondo. Non indicano due oggetti diversi.

Ma se vi rotolate nelle bocca queste parole sentite cose diverse. Uno sa di università, di laboratorio, l’altro di Euronics.

La diffusione lessicale è ovviamente molto diversa: calcolatore viene usato solo dai pochi che hanno appreso l’informatica almeno trent’anni fa, computer da tutti gli altri. L’etimologia è poi interessante: “calcolatore” viene, dopo vari passaggi, da calculus, il sassolino che si usava per contare, magari disposto in scanalature di una tavoletta o su fili diversi come nel pallottoliere; “computer” da com-puto, il verbo delle operazioni aritmetiche (la somma, in particolare). Uno punta sul supporto materiale, sull’ausilio tecnologico, l’altro sull’operazione mentale di trarre una conclusione da una situazione complessa.

Naturalmente l’etimologia non partecipa alla determinazione dell’uso di un termine, almeno quando è ignota. Ma saperne di più aiuta a modulare l’uso dei termini, a scegliere. C’è chi non capisce il successo del nome (prima dell’oggetto) Whatsapp, principalmente perché non coglie il nesso con “what’s up?”, che succede? O chi non sa che “tube” significa “televisione” (dal tubo catodico), e quindi non collega Youtube con “fai la tua televisione”.

Un altro esempio che è sotto i riflettori in questi giorni (Code Week): “coding” potrebbe essere tradotto con “programmare, programmazione”. Ma esiste “programming”, che equivale a “programmare”. Nel quadrilatero che possiamo immaginare, uno dei vertici è vuoto. I due termini inglesi hanno – nella mia mente, sulla base delle mie esperienze –  due sfumature diverse: coding è “codificare”, cioè trasporre uno schema operativo in un certo codice linguistico, partendo da una versione astratta o da un altro codice. Programmare è “costruire un programma”, un artefatto digitale che viene eseguito da un calcolatore. Il primo termine sottolinea il processo, l’attività linguistica; l’altro il fine e l’utilizzo del prodotto finale. Uno si presta bene a sviluppare gli aspetti narrativi, l’altro quelli ingegneristici. Quando dico “un programma è la materializzazione in un linguaggio specifico di un algoritmo che risolve un problema”, ho in mente il risultato, non il processo di scrittura. Quando dico “coding is fun”  ho in mente l’avventura di trovare dentro di me le parole giuste per dirlo.

“That is why I enjoy computer programming more than anything I have encountered in this life. Not because of the boring “move, modify, store, repeat” routine of the daily work, but in studying how I write code and from the knowledge and insight I get into the code, I also get into myself.” Mark Janssen qui parla evidentemente di coding, non di programming.

Ora non giurerei che chi parla oggi di “Code Week” intenda una cosa diversa da “Settimana della Programmazione”; però sarebbe bello se i corsi di “coding” e quelli di “programmazione” fossero riconosciuti come cose diverse e un potesse iscriversi all’uno o all’altro con cognizione di causa. Sarebbe bello se chi parla di certi argomenti avesse una conoscenza meno superficiale; conoscenza (non solo competenza) che non deriva solo dalla pratica di una disciplina, ma anche dalla riflessione sulle proprie esperienze e dallo studio delle parole di quella disciplina, del loro uso non solo qui ed ora. Mi rendo conto che  è una posizione che può apparire retrograda. D’altra parte, penso ancora che ci siano più parole che cose, e che rinunciare alla parole in favore delle cose sia almeno altrettanto rischioso dell’inverso.

 

Il problema, secondo il mio modesto parere (IMHO), è quindi non tanto nell’usare un termine straniero per ossequio ad una potenza nemica, ma usarlo inconsapevolmente senza cercare di coglierne tutti i significati e i sapori. Come per la zappa.

Anche in questo caso, un’educazione all’uso delle parole, trasversale a tutte le discipline, sarebbe benvenuta.