Ancora sui file di testo

Una precisazione. La mia non vuole essere una campagna contro i file di testo, nè verso il loro utilizzo come mezzo per la memorizzazione del codice sorgente. La mia critica è che anche linguaggi e strumenti di programmazione di alto livello portano ancora oggi il fardello del legame con la rappresentazione fisica del sorgente. Vorrei un maggiore disaccoppiamento tra ciò che lo sviluppatore manipola e la sua rappresentazione fisica. Tale disaccoppiamento darebbe forti vantaggi a entrambi gli aspetti.

Linguaggi di programmazione e file di testo

Nella stragrande maggioranza dei contesti di sviluppo software programmare significa scrivere testo. Non è sorprendente, visto che il codice sorgente è un mezzo per comunicare. L’evoluzione della programmazione è passata dal linguaggio macchina puramente binario a un linguaggio, ancora macchina, basato su mnemonici che ricordavano quanto meno l’operazione svolta. Il salto verso linguaggi di successive generazioni non ha fatto altro che alzare l’astrazione, avvicinando le espressioni e i termini utilizzati dai programmatori verso concetti più vicini al modo di esprimersi umani (ho detto esprimersi volutamente, anzichè pensare). l’evoluzione è rimasta finora legata alla parola e credo ci siano forti motivazioni per questo.

negli anni il testo del codice sorgente del sw è stato inserito all’interno di file di testo, con indubbi vantaggi. i file di testo si editano facilmente con programmi elementari che si trovano ovunque. i file di testo possono essere manipolati facilmente dai compilatori e dagli analizzatori sintattici.

l’osservazione che voglio fare è che la rappresentazione fisica del testo del codice sorgente è da sempre il file di testo, ma oggi non c’è più una motivazione a questo e il tempo è maturo per eliminare vincoli e side effect di questo legame. gli strumenti utilizzati dagli sviluppatori sono sempre più grafici e la potenza di calcolo consente di gestire una vera astrazione tra cio’ con cui lo sviluppatore ha a che fare (il testo o quel che sia il sorgente) e la sua rappresentazione fisica.

Quel che voglio discutere è che l’utilizzo di un file di testo per rappresentare il codice sorgente è stato in passato una scelta obbligata dai mezzi utilizzati dagli sviluppatori per creare il codice. Oggi questo vincolo è giustificato solo dalla storia.

Scrivere codice in un file di testo ha portato a un sacco di conseguenze che molti sviluppatori danno, senza motivo, per scontate:

• il codice viene letto dallo sviluppatore sequenzialmente. non interamente, ma comunque si viene portati a leggerlo dall’alto verso il basso. Strutture non sequenziali (condizioni, cicli) vengono per forza appiattite. metodi e funzioni vengono messi involontariamente in ordine.
• L’eredità dei parser di file di testo è che la posizione nel file di testo (non nella struttura come sarebbe più corretto) di un comando spesso determina un comportamento diverso.
• Gli sviluppatori si sono creati nel tempo convenzioni di tabulazione per facilitare la lettura e best practice di leggibilità (80 caratteri!!!!!) determinate dai display di 20 anni fa.
• Le grammatiche stesse dei linguaggi di programmazione impongono l’utilizzo dei file di testo per demarcare porzioni di codice e della struttura del software.
• alcuni linguaggi di programmazione hanno fatto di regole di tabulazione delle regole grammaticali vere e proprie.
• i limiti degli strumenti di sviluppo sono spesso legati alla struttura dei file di testo del codice

se oggi dovessimo inventare uno strumento per sviluppare software (attenzione, non ho detto per scrivere codice!) cosa proporremmo? il testo è indubbiamente un canale di comunicazione estremamente immediato per l’essere umano, ma dobbiamo per forza legarci a un file di testo? non è possibile pensare al codice sorgente come un mare indistinto di porzioni piccole di testo che si integrano a formare la base di codice di un sw? non cadremmo sicuramente nell’errore di considerare il confine del file di testo come un confine del sw, come spesso accade. certo perderemmo la possibilità di utilizzare uno stupido editor di testi per lavorare sul codice, ma non è forse meglio è più efficace avere un ambiente di sviluppo che dia tutti gli strumenti necessari a navigare nel codice, facendoci dimenticare della rappresentazione fisica del sorgente?

lancio quindi la proposta: proviamo a elencare gli scenari e le possibilità che si potrebbero avere abbandonando il vincolo legato alla memorizzazione su file di testo?

io e il sw

Inauguro questa nuova categoria con una giustificazione. Chiedo venia se sfioro un nuovo meta.

Ho iniziato la mia carriera nello sviluppo del sw nel 1995. Non proprio la carriera, poichè ci sono entrato da studente all’istituto tecnico. ok, i primi 5 anni sono passati con poca significatività. Sufficienti a formarmi su Turbo Pascal e Assembler. Good. I fondamenti di ciò che so ora li ho appresi in quel momento. Gran finale con una tesina di maturità (vecchia maniera) sull’Object Orientation. Col senno di poi, non ci avevo capito granchè. Bertrand Meyer non era facile come autodidatta. L’ho apprezzato solo in seguito.

I primi due anni di università ho rischiato di retrocedere. Si esce dalle superiori pensando di saper tutto, si trova un’università che non riesce a smentirti. Tristezza. Una inutile esperienza in Modula2 e una inesistente preparazione su C++.

Terzo anno, un corso su Java, il primo progettino serio. Oh. Negli anni seguenti infilo tutti gli esami possibili con un progettino di sviluppo. Gioco con il Lisp. Conosco il mondo del web sviluppato in Java con le servlet e le jhtml (quando ancora le jsp si chiamavano così).

Inizio a lavorare alla ME&S, una microsocietà di sw specializzata in strumenti di eLearning che lavora con Toolbook, una piattaforma di RAD per elearning con un linguaggio di scripting estremamente vivace. Evviva, imparo cosa significa lavorare nell’informatica e cos’è la consulenza. è il 1998. Qui proseguirò a sviluppare in Java. Qui nel 1999/2000 ci convertiamo tutti al Javascript. Venivamo dal mondo di Toolbook, interattivo, multimediale (era un concorrente di Director, l’antesignano di Flash). Non potevamo che cercare di fare altrettanto con Javascript. Ed ecco che in quei lontani anni sviluppiamo applicazioni Javascript che farebbero impallidire una applicazione AJax moderna. Qui nasce tutto il mio sapere Javascript e tutto cio’ che oggi mi consente di parlare a braccio di come funziona un browser.

Dopo aver mollato una tesi mezza iniziata di intelligenza artificiale, mi infilo in una tesi sul sw testing, per la quale anzichè far testing devo sviluppare una gran applicazione in C++. Un tool per la generazione automatica di casi di test che integra un pre-compilatore, un esecutore simbolico, un valutatore di espressioni algebriche, un analizzatore di grafi e forse altro che ho rimosso.

Sviluppo la tesi in contemporanea con il master IT del CEFRIEL e mi guadagno due titoli con una fava. a fine master, inizio a lavorare al CEFRIEL nell’area di Ingegneria del Software. Coltivo una specializzazione sulla piattaforma Java Enterprise, su cui tengo un po’ di corsi sia in CEFRIEL sia in Politecnico. Approfitto di un progetto per giocare anche con la piattaforma Eclipse e prendermi un po’ di competenze anche nello sviluppo su architetture a plugin.

Col tempo, perdo dimestichezza col C++. Nel 2005 però derivo dal mondo Java per circa 4 mesi, sviluppando in C# una architettura per l’integrazione di strumenti di domotica sul Windows Media Center. Si parla di Universal Plug & Play.

Lascio il C# e mi infilo nel Python per un po’ di 2006. si sviluppa (giocando anche con Scrum) una piattaforma per la predizione di flussi di traffico sulla rete di milano. Non male.

Ultimamente ho perso un po’ il ritmo, poichè son passato dalla parte oscura della forza (sono PM). Non mi va di aspettare oltre a dir la mia. Oltre suonerebbe solo come un rimpianto. Spero valga il penny.