seguito concettuale della Turing Machine

La macchina di Turing ha segnato a fondo il concetto di cosa sia un computer. I programmi venivano codificati come una lunghissima sequenza d’istruzioni. Tali sequenze vengono eseguite sequenzialmente, spostandosi in una casella a destra o a sinistra nel caso di un nastro magnetico. Nel caso di una memoria ad accesso arbitrario l’ordine di esecuzione delle istruzioni è “avanti per default” altrimenti salta verso una specifica istruzione anche non adiacente. Questo default consente ad esempio di risparmiare memoria cosa che non avviene in una mia variante RESM dove ogni istruzione ha due e sempre due istruzioni successive. Il processore e i linguaggi C-like hanno ovviamente preso la scelta del “avanti per default” + “salti qualora bisogni”. E così vengono in essere istruzioni quali il GOTO del BASIC e ancor prima il JUMP del linguaggio macchina di cui sono importanti specialmente le varianti condizionali ovvero che avvengono soltanto a particolari condizioni.

Il GO TO, “vai a” … e la sequenza di istruzioni lineare divenne non lineare. Si pose il problema dello spaghetti code ovvero di tessiture indecifrabili di programmi che fecero nascere la programmazione strutturata che trovò la sua accettazione anche grazie al supporto nei linguaggi come Pascal e C …

Come nota dell’autore io tendo a conservare i pezzi d’informazione che permettono una comprensione storica ed evolutiva.

Queste sono le basi dei linguaggi e dei processori odierni. Nessuno ha mai pensato cose come rendere un programma non una sequenza d’istruzioni con salti, non una sequenza d istruzioni con salti disciplinati in gerarchie strutturate, ma un grafo di grafi ma non sarò io a introdurlo. In ogni caso vedo la necessità di mezzi visuali per definire i programmi. E non soltanto come testo decorato e “assistito” (come in VisualStudio con IntelliSense), ma come abbandono o integrazione della definizione di programmi mediante testo sequenziale, in oggetti grafici manipolabili e configurabili che esemplifichino il funzionamento del programma anche a fini di debug o refactoring. E già esistono varie notazioni e vari tipi di diagrammi ma non so perché i programmi debbano venire ancora scritti come files di testo semplice, poi elaborato.