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?