Avevo tredici anni, era l'inizio degli anni Ottanta e l'edicola era la mia porta d'ingresso a un universo parallelo. Tra figurine, fumetti e poster c'erano pagine fitte di testo: programmi in BASIC, stampati su riviste patinate.
Non erano semplici esempi, erano kit empirici per far funzionare qualcosa sullo schermo: un giochino, una simulazione, un generatore di suoni. Prendevi la rivista, trovavi il listato, e ti mettevi lì — davanti a un Commodore 64, uno Sinclair ZX Spectrum o un MSX — a trascrivere riga per riga quel codice sull'interprete BASIC.
cat /memoria/1983/listato.bas --explain
Copiare codice era tradurre intenzioni
La pratica era rituale e formativa. Copiare significava più che trasferire caratteri. Un errore di battitura, uno spazio in più o un numero sbagliato in un DATA cambiavano tutto: un PRINT che non restituiva nulla, un GOTO che mandava il flusso in loop infinito, sprite che comparivano storti perché le coordinate erano off-by-one. Dopo il primo RUN lo schermo restituiva un messaggio criptico — Syntax error, Overflow, Bad line number — e da lì partiva un ciclo di debugging ante litteram: leggere con calma, confronto riga per riga, correggere, rilanciare.
Quel processo era una scuola di pensiero computazionale: imparavi a scomporre i problemi, testare ipotesi e sviluppare un senso del trade-off tra eleganza e spazio in memoria.
Il vero retro-engineering
Non era solo correggere typo. Molti listati usavano routine in machine code o colonne di DATA che rappresentavano bitmap e tabelle di sprite: decine di numeri separati da virgole che traducevi in pixel. Capire perché uno sprite appariva storto significava interpretare una sequenza di byte, ricalcolare offset e coordinate, usare PEEK per leggere la memoria video e POKE per modificarla al volo. Il listato BASIC spesso era solo un loader: un SYS o un CALL che saltava a una routine in machine code.
Tecniche artigianali — il PRINT di debug per stampare variabili e contatori, le pause temporanee e i GOSUB per isolare sequenze, la riduzione della risoluzione del frame buffer per capire le collisioni — erano all'ordine del giorno. E la latenza del ciclo (digitare, LOAD da nastro, RUN, aspettare) forgiava pazienza e precisione: imparavi a pensare in bit e in tempi di refresh, in poche decine di kilobyte.
git log --abstraction --order=asc
La traiettoria: dal codice che si toccava a quello che scompare
Guardo a quel passato alla luce dell'evoluzione attuale e vedo una traiettoria coerente: dal codice che si leggeva e si toccava con mano, a un codice sempre più astratto, generato e manipolato tramite interfacce di alto livello, fino a un futuro dove il "codice" potrebbe sparire alla vista e diventare consuetudine la sola interazione in linguaggio naturale. Quattro punti chiave.
Astrazione crescente
Librerie, framework, DSL e generatori traducono intenti in implementazioni. Non digitiamo più POKE: scriviamo componenti React, configuriamo pipeline, dichiariamo intenti in YAML o in un prompt. Ogni strato porta produttività — e rischio di perdere la comprensione profonda.
Tooling e osservabilità
Un tempo il monitor di memoria era l'unica finestra. Oggi abbiamo logging, APM, tracing distribuito e visualizzazioni che rendono il sistema interrogabile. Ma la complessità degli stack moderni chiede nuovi modi di "leggere" il sistema, inclusi metodi per spiegare modelli e codice generato.
Automazione e generazione
I modelli di codice e gli AI assistant producono in fretta. Come quando correggevo DATA e sprite, oggi bisogna saper correggere l'output generato: interpretare prompt, valutare bias, validare sicurezza e performance.
Invisibilità e linguaggio naturale
Andiamo verso interfacce in cui "programmare" sarà conversare: descrivi cosa vuoi e il sistema costruisce, testa, mette in produzione. Il rischio è perdere la capacità di leggere il dietro le quinte. Il vantaggio è che più persone potranno trasformare idee in prodotti senza barriere di sintassi.
diff --lost --gained
Cosa perdiamo e cosa guadagniamo
Per un developer abituato a toccare il codice riga per riga, è la domanda centrale.
La familiarità meccanica con il basso livello
Questo può rendere più difficile diagnosticare problemi sistemici, exploit o inefficienze. La conoscenza dei why a basso livello resta critica per performance, sicurezza e debugging profondo.
Astrazione e velocità di iterazione
Possiamo concentrarci su design, esperienza utente e governance del sistema. Emergono lavori più strategici: progettare prompt efficaci, definire contratti, strutturare osservabilità e policy.
run integrate.eighties-wisdom --into=modern-craft
Integrare la saggezza degli anni Ottanta nel mestiere moderno
Non per nostalgia, ma perché alcune abitudini di allora restano una bussola tecnica. Quattro, nell'ordine in cui le metto in pratica.
Mantieni il "leggimi la macchina"
Studia ogni tanto il livello sottostante — assembly, memory map, bus — per preservare una bussola tecnica quando l'astrazione ti allontana dai dettagli.
Tratta i generatori come collaboratori, non come autorità
Verifica, testa, scrivi unit e property test che confermino le assunzioni. L'output va validato, non accettato sulla fiducia.
Investi in osservabilità e spiegabilità
Quando il codice è invisibile, gli strumenti che lo rendono interpretabile diventano la tua lente d'ingrandimento.
Documenta intenti e trade-off, non solo il risultato
Il codice generato può scomparire, ma le ragioni di progetto e le decisioni architetturali devono restare leggibili.
assert nostalgia == patrimonio-cognitivo
Leggere e correggere la macchina è un patrimonio
La nostalgia per quelle pagine stampate in BASIC non è solo un sentimento retro: è la consapevolezza che imparare a leggere e correggere la macchina è un patrimonio cognitivo. E insieme riconosco l'eccitazione del nuovo orizzonte — un mondo in cui le idee diventano prototipi in minuti, dove la creatività è meno limitata dalla curva di apprendimento sintattica e più guidata da strategia e design.
Hai un'idea da trasformare in prototipo, tenendo il controllo sul "dietro le quinte"?
scrivimi su whatsapp →