Alcune riflessioni sulla programmazione al volo

Di leonardo maffi
Versione 1.0 dell'8 ottobre 2004

In alcune rare situazioni (per lo più di fantasia) ho visto persone che programmavano "al volo", cioè che lo facevano più o meno contemporaneamente al verificarsi di alcuni fenomeni che i programmi dovevano controllare. Ad esempio:
- programmazione al volo per la sintesi di musica in tempo reale (si veda in coda per i riferimenti);
- una puntata del cartone animato Neo Genesis Evengelion dove l'angelo era un virus che infettava i computer tre Magi;
- Il racconto "Luminous" di Greg Egan, tratto dalla raccolta omonima di racconti, dove veniva programmato questo mega computer.

- Può verificarsi il bisogno di programmare al volo?
- A che/chi può servire?
- Che linguaggio di programmazione usare? Presumo debba essere un linguaggio di livello molto alto.
- Come potrebbe essere fatto un linguaggio ideale progettato per tale scopo? Presumo dovrebbe essere interpretato (o compilato al volo, tipo compilatori Java "just in time"), dovrebbe avere una sintassi molto facile (e forse elastica e in grado di accettare qualche errore di battitura o ortografico), sintetico (forse potrebbe essere fatto di comandi di uno o pochi caratteri per ridurre il tempo di battitura, o forse i comandi potrebbero essere abbreviabili) potrebbe essere almeno in parte visuale, potrebbe usare una interfaccia a bottoni (virtuali sul monitor o anche reali, con una tastiera specializzata) per inserire comandi o operazioni, potrebbe avere un po' di intelligenza per capire cosa vuole realmente l'utente.

Il Mathematica è un linguaggio di livello molto alto, ed è anche piuttosto sintetico, ma a questi fini avrebbe bisogno di un nuovo editor, e comunque non ha una sintassi facilissima. Immagino che chi conosce già tutti i comandi del linguaggio, e ha fatto molta pratica, sarebbe molto avvantaggiato nella programmazione al volo. Comunque un sistema di programmazione al volo dovrebbe aiutare più possibile chi non conosce ancora tutto quanto, in modo anche che possa imparare.

Una interfaccia vocale potrebbe essere utile in sostituzione, o meglio in aggiunta, a quella a bottoni/visuale/testuale. Comunque l'uso di IRC mi ha mostrato che con la pratica possono diventare abbastanza veloci anche le comunicazioni testuali via tastiera (e hanno il vantaggio ad esempio di permettere più dialoghi contemporaneamente e di poter scrivere anche mentre si legge, mentre a voce è quasi impossibile parlare mentre l'altra persona sta parlando.) Ovviamente avere una buona velocità dattilografica potrebbe essere d'aiuto. Nel caso del riconoscitore vocale si noti che di recente (credo la IBM) ne è stato rilasciato uno GNU.

Dovrebbe essere un linguaggio di livello molto livello. (Forse potrebbe perfino essere un linguaggio di programmazione basato sulla lingua naturale, cioè capace di estrarre un algoritmo da normale testo/dialogo in italiano o inglese.) O forse potrebbe essere due linguaggi in uno:
- Un "linguaggio" (che potrebbe essere quello naturale in inglese o italiano, oppure una interfaccia visuale o una a bottoni) di altissimo livello per dire cosa fare e in che modo coordinare le varie cose;
- Un linguaggio di livello un poco più basso, e più vicino a quello di linguaggi tipo Mathematica o Logo o Python, che serva per specificare algoritmi veri e propri.
Per cui un "programma" scritto in questo sistema assomiglierebbe ad un liquido nel quale galleggiano delle patate più solide del liquido circostante :-)

A che può servire la programmazione al volo? Anche se al momento non ci siano molte applicazioni (o sono ad esempio solo nel campo musicale), dopo aver inventato un linguaggio adatto a questo tipo di programmazione penso che forse gli potrebbe venire trovato qualche utilizzo. Magari questo linguaggio/sistema potrebbe essere anche utile per scrivere programmi offline e non al volo, ma nelle situazioni nelle quali si ha comunque molta fretta, e nelle quali la manutenibilità e comprensibilità a lungo termine dei programmi non sono importanti. Un esempio che mi viene a mente è che talvolta nella vita di tutti i giorni sarebbe utile fare certe computazioni (cioè oltre che programmazione al volo sarebbe anche programmazione fatta su computer indossabili, e magari in parte automatica, cioè talvolta potrebbe essere il sistema stesso a suggerire quali cose fare), ad esempio per stimare delle probabilità, svolgere dei calcoli, ecc. (Cioè questo sistema potrebbe venire indossato insieme a telecamera e microfono e piccolo schermo, e ad esempio potrebbe leggere colonne di numeri visti su un foglio di carta e sommarli (automaticamente), ecc.). Questo tipo di programmazione al volo potrebbe essere utile quindi per chi si porta il computer dietro, ad esempio indossandolo (per risolvere esercizi di matematica ho talvolta scritto programmi (iterativi) al volo sulla calcolatrice HP48; questo forse è stato già un tipo semplice di programmazione al volo), (penso anche al nanosistema chakasa), ecc.

Durante l'uso di questo sistema (presumendo che si programmi in parallelo a fenomeni abbastanza veloci) non ci sarebbe tempo per salvare o caricare sorgenti, per cui la cosa migliore sarebbe non avere un sorgente da eseguire, ma un pool di procedure aggiornate e attivate al volo, come nelle sessioni in linguaggio Logo (che non è un linguaggio limitato, ed è della famiglia del Lisp) o Mathematica, nelle quali si può "insegnare al computer a fare qualcosa" e tale cosa rimane memorizzata.

Dato che in questo tipo di programmazione quello che conta è la velocità di chi programma, e che esprimersi nella propria lingua è più facile e veloce (ad esempio perché non serve soffermarsi sul compitare le parole), questo linguaggio/sistema potrebbe essere in qualche modo traducibile. Ad esempio potrebbe esserci un file di sintassi+grammatica+dizionario ortografico per chi usa l'inglese, un altro terzetto di file per chi usa l'italiano, ecc.

Potrebbe risultare utile far usare/analizzare un sistema in italiano ad una persona che usa l'inglese o viceversa, in tal caso si potrebbe pensare a qualche modo (anche automatico) per tradurre questi "sistemi funzionali". Comunque è possibile che (proprio come un romanzo) tali sistemi non siano al 100% traducibili in un'altra lingua (si tratterebbe sempre di traduzione automatica, perché quella manuale è forse troppo difficile o rischia di introdurre troppi errori).

Ci sarebbe ad esempio un bottone per definire un nuovo algoritmo, e ci sarebbe una biblioteca di funzioni e algoritmi utili e già pronti, con un motore di ricerca testuale che permetta ad esempio di trovare la funzione "fft" sulla base di parole in lingua naturale, anche senza ricordarsi il nome e uso esatto della funzione.

Il sistema potrebbe fare anche pre-computazioni: cioè ad esempio in presenza di una serie di numeri potrebbe automaticamente mostrarne la somma e alcuni grafici, in modo che talvolta l'utente possa limitarsi a scegliere cosa vuole fare sulla base dei lavori già svolti e presentati dal sistema. Ovviamente il sistema dovrebbe imparare; quindi se un utente ad esempio preme di solito un dato bottone dopo un altro, il sistema potrebbe precalcolare il risultato della pressione del secondo tasto, e presentarla come possibile comando successivo (o anche solo per avvantaggiarsi nel calcolo di cose che probabilmente verrebbero comunque richieste poco dopo). I processori sono diventati maestri nella esecuzione predittiva di comandi, ed esistono acceleratori web che pre-scaricano le pagine più significative lincate da quella visibile attualmente. Per prevedere il futuro si potrebbe usare un algoritmo di compressione tipo quelli del programma PAQAR, questo algoritmo potrebbe essere anche utile per prevedere i caratteri/bottoni che l'utente sta per battere, e quindi ad esempio rendere più grandi tali bottoni sullo schermo in base alla stima di quali siano in quel momento i più probabili. (Alcune di queste idee erano presenti in un progetto di un software di data mining che non ho mai sviluppato. Ma vedendo la elasticità e capacità dei linguaggi moderni come il Python, credo che ormai siano idee realizzabili.) Al posto del PAQAR potrebbe invece essere più utile un modello markoviano, tipo Ocamyd.

Nel linguaggio "più solido", per definire algoritmi, potrebbe ad esempio non esserci distinzione tra funzioni, classi e loro istanze (anche nel mitico futuro Python3000 forse ci saranno semplificazioni concettuali simili). Non ci sarebbe accesso al filesystem, il sistema userebbe automaticamente un DB per memorizzare le sessioni e le loro parti, per cui non ci sarebbe da caricare o scaricare nulla dopo che l'interprete è partito (e non ci sarebbero neppure comandi tipo gli "Import" del python). Il sistema non dimenticherebbe mai nulla, ma ovviamente in certi momenti certe cose potrebbe non ricordarle attivamente (per cui le sessioni rimarrebbero distinte e non dovrebbe esserci troppa confusione).

Questo ambiente di sviluppo sarebbe utente-specifico, cioè si adatterebbe molto ad un dato utente, e lentamente imparerebbe a capirlo. Per cui esisterebbe un "DB personale" (che potrebbe essere esportato ad esempio compresso in PPMD) che contiene tutti gli adattamenti personali. Un problema potrebbe essere dovuto al fatto che un utente diverso potrebbe venire messo a lavorare in un ambiente creato e adattato su un'altra persona. Oppure due persone potrebbero voler programmare insieme sullo stesso sistema, e magari usando lingue diverse!

I moduli (cioè le parti funzionali di cui è composto questo sistema) interagiscono tra loro, si inviano messaggi, ecc. Come potrebbe essere l'interfaccia tra questi processi di calcolo? Se si immagina di avere un computer molto veloce (molto più veloce degli odierni, oppure con hardware specifico per svolgere questo compito) si potrebbe immaginare di usare le interfacce "a contatto di immagine" (con tanto di messa in mostra dello stato interno). Oppure se ne potrebbero usare versioni più addomesticate, come lo scambio di immagini di 256x256 byte a toni di grigio, sulle quali ad esempio il modulo farebbe OCR per riconoscere il testo che gli ha inviato un altro modulo... Si potrebbe ridurre ad una matrice di 128^2 bit = 2048 byte. Oppure semplificando ancora si potrebbero usare pacchetti, che alla fine potrebbero essere normali pacchetti TCP/IP. La semantica dei dati sarebbe inclusa nel pacchetto stesso, o implicita nella comunicazione. Comunque questi sono dettagli implementativi.

In questo sistema di programmazione non ci sarebbe un debugger attivabile a parte, dato che in realtà il debugging è continuo e sempre attivo. Sarebbe un linguaggio con l'Undo, per cui qualunque cosa sarebbe memorizzata (o almeno ne sarebbe definito l'inverso), e potrebbe venire annullata. Per quanto l'idea di aggiungere un undo ad un linguaggio di programmazione sembri molto strana (ma per un linguaggio a script interattivo sembra utile, per annullare cose fatte), esistono già cose del genere, in Python: ^_^
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/306866
http://www.python.org/workshops/1997-10/proceedings/zukowski.html

Nota: il linguaggio "chuck" (il link è poco sotto) è "strongly typed and strongly timed"; questo è utile per un linguaggio che deve definire eventi musicali ed un rigido coordinamento temporale tra moduli che vengono eseguiti in parallelo. Il sistema di programmazione al volo potrebbe avere una tipizzazione temporale forte opzionale.
---------------

Dopo aver scritto queste note ho fatto una ricerca, e ho trovato che a questo tipo di programmazione sono già stati dati vari nomi: On-the-fly programming, Just In Time Programming, live coding, interactive programming. (La "real time programming" è una cosa diversa, e di solito si riferisce alla normale programmazione offline di sistemi realtime.)

>On-the-fly-programming is a paradigm that includes the programming activity itself in the program's operation. This means a program is not seen as a tool that is made first, then to be productive, but a dynamic construction process of description and conversation.<

Alcuni riferimenti reali relativi alla programmazione al volo per la musica:

Ne hanno parlato su Slashdot:
http://developers.slashdot.org/article.pl?sid=04/09/02/1257253&tid=145

TOPLAP is the Temporary Organisation for the Promotion of Live Algorithm Programming:
http://toplap.org/

Hacking Perl in Nightclubs (programmazione al volo per generazione di musica):
http://toplap.org/?Hacking_Perl_In_Nightclubs

On-the-fly programming is a style of programming in which the programmer/performer/composer augments and modifies the program while it is running, without stopping or restarting, in order to assert expressive, programmable control for performance, composition, and experimentation at run-time. Because of the fundamental powers of programming languages, we believe the technical and aesthetic aspects of on-the-fly programming are worth exploring.
http://on-the-fly.cs.princeton.edu/

Molte idee si possono prendere dal linguaggio Chuck progettato per la generazione audio live:
http://chuck.cs.princeton.edu/

Anche Audicle può essere un buon riferimento, soprattuto per l'interfaccia globale del sistema.

[Torna all'indice]