La parola efficienza, oggi, viene spesso usata come decorazione. Si parla di codice leggero, architetture snelle, framework moderni e performance come se bastasse scegliere lo stack giusto per essere virtuosi. Il VIC-20, invece, non lasciava spazio alla retorica: se avevi circa 3,5 KB di RAM disponibili per l’utente, ogni scelta diventava immediatamente concreta.
Il caso era molto semplice e molto reale. Mio zio Ottavio partecipava a Portfolio, il gioco a premi pubblicato da La Repubblica. Ogni giorno bisognava controllare i numeri usciti sul giornale e confrontarli con circa 200 schede. A mano era un lavoro lento, ripetitivo e incline agli errori. In casa, pero, c’era un Commodore VIC-20. Non una macchina potente, non una workstation, non un sistema “comodo”: un home computer con CPU MOS 6502 a circa 1 MHz, BASIC integrato e pochissima memoria libera.
Il punto non era scrivere “un programma”. Il punto era far stare insieme programma e dati dentro un limite ridicolo per gli standard attuali. Oggi una singola icona puo pesare piu di tutta la memoria di lavoro disponibile su quella macchina. Sul VIC-20, invece, bisognava ragionare come se ogni byte avesse un carattere, una funzione e una bolletta da pagare.
Il problema non era il calcolo, erano i dati
Controllare 200 schede non richiedeva un algoritmo esotico. Serviva leggere le combinazioni, inserire i numeri pubblicati dal giornale, confrontare e segnalare eventuali corrispondenze. Il vincolo vero era la rappresentazione. Se avessi sprecato memoria con strutture comode ma pesanti, il programma sarebbe morto prima ancora di iniziare.
La soluzione fu usare il BASIC nel modo piu diretto possibile: le schede vennero inserite nel programma come righe DATA, poi lette con READ. Niente database, niente file esterni, niente astrazioni inutili. I dati stavano nel codice, compressi nella forma piu accessibile per quella macchina e per quel linguaggio. Non era elegante secondo i canoni moderni, ma era esattamente il tipo di eleganza che conta quando il limite e fisico.
Il flusso era essenziale: il programma conteneva le schede, l’utente inseriva i numeri del giorno, il VIC-20 scorreva le combinazioni e segnalava quelle vincenti. Non c’era nulla da “scalare” nel senso moderno del termine, eppure c’era tutto quello che serve davvero a un sistema utile: input, modello dei dati, verifica, output.
Efficienza come progetto, non come slogan
Quell’esperienza insegna una cosa che molti ambienti moderni tendono a nascondere: l’efficienza non nasce alla fine, quando si “ottimizza”. Nasce all’inizio, quando si decide come rappresentare il problema. Su una macchina piccola, una scelta sbagliata non produce solo un programma piu lento. Produce un programma impossibile.
Il VIC-20 costringeva a domande che oggi restano validissime: quali dati servono davvero? Quante volte devo leggerli? Posso evitare copie inutili? Sto usando una struttura perche mi serve o perche mi rassicura? Il BASIC era limitato, certo, ma proprio per questo rendeva visibile il costo di ogni decisione. Una riga inutile era spazio rubato al programma. Una rappresentazione troppo larga era una scheda in meno. Una logica confusa era tempo perso a rileggere codice su uno schermo che non perdonava molto.
Questa non e nostalgia del disagio. Nessuno sano di mente rimpiange i limiti per sport. La lezione e un’altra: quando impari a programmare dentro un vincolo reale, ti resta addosso l’abitudine a distinguere tra complessita necessaria e complicazione ornamentale. Ed e una competenza che torna utile anche quando lavori su server moderni, database, automazioni, AI o CMS: il ferro cambia, ma l’entropia e sempre li che aspetta.
Dal gioco sul giornale al codice utile
Il momento importante non fu tecnico in senso stretto. Fu operativo. Quel programma non era un esercizio scolastico e non era una demo per far vedere che il computer “faceva cose”. Risolveva un problema domestico preciso: controllare molte schede Portfolio senza passare ogni giorno attraverso una piccola tortura manuale.
Questo cambia il modo in cui guardi il codice. Il computer smette di essere un oggetto affascinante e diventa una leva. Prendi un processo ripetitivo, lo descrivi, lo fai eseguire a una macchina e liberi tempo umano. In scala minuscola, era gia automazione. Con meno memoria di un frammento di pagina web moderna, il VIC-20 stava facendo quello che i sistemi utili fanno ancora oggi: prendere un lavoro noioso e renderlo verificabile.
RetroLab nasce anche per questo. Non per mettere le macchine vecchie sotto una campana di vetro, ma per ricordare che quei sistemi insegnavano con una durezza molto produttiva. Il VIC-20 non ti permetteva di coprire un progetto debole con librerie, RAM o interfacce generose. Ti chiedeva di capire il problema prima di scrivere. Se sbagliavi, non c’era un profiler a salvarti: c’era il cursore che lampeggiava e la memoria finita.
Cosa cambia davvero
La lezione del programma Portfolio non e che “una volta si programmava meglio”. Sarebbe una frase comoda e anche abbastanza falsa. La lezione e che i limiti rendono misurabile il pensiero tecnico. Su un VIC-20 inespanso, usare DATA e READ per memorizzare circa 200 schede non era una scelta romantica: era una strategia di sopravvivenza progettuale.
Portata nel presente, quella mentalita resta preziosa. Prima di aggiungere un framework, un servizio, una coda, un agente o un layer di AI, bisogna chiedersi se il modello del problema e gia chiaro. Il VIC-20 non insegnava solo a risparmiare byte. Insegnava a non mentire a se stessi sulla forma del problema. E questa, nel 2026, e ancora una forma molto concreta di efficienza.
In breve
- Il programma Portfolio su VIC-20 nasceva da un problema reale: controllare circa 200 schede ogni giorno.
- Il vincolo principale era la memoria: circa 3,5 KB disponibili per programma e dati.
- La soluzione usava righe
DATAe lettura conREAD, evitando strutture inutilmente pesanti. - La lezione tecnica non e la nostalgia del limite, ma la progettazione consapevole sotto vincoli reali.
- Efficienza significa scegliere bene la rappresentazione del problema prima ancora di ottimizzare il codice.