Creare un ambiente RAD in BASIC nell’era dell’AI sembra una follia. Ecco perché lo sto facendo.

La domanda sul perché abbia deciso di creare McBasic è più che legittima, soprattutto considerando il momento in cui lo sto facendo. Non siamo più negli anni Novanta, quando Visual Basic rappresentava per moltissimi sviluppatori uno dei modi più semplici e veloci per creare un’applicazione Windows. Oggi abbiamo una quantità enorme di linguaggi, framework e ambienti di sviluppo, molti dei quali eccellenti, esistono già diversi prodotti basati su BASIC o comunque sulla stessa filosofia di sviluppo visuale e, come se non bastasse, è arrivata l’intelligenza artificiale, alla quale ormai possiamo chiedere di scrivere buona parte di un’applicazione.

Quindi la domanda non è se BASIC sia ancora un linguaggio utilizzabile nel 2026. Direi che questo è abbastanza evidente e non ho particolare interesse a difenderlo per ragioni storiche o nostalgiche. Le domande che mi interessano sono altre: perché scegliere oggi un ambiente basato su BASIC, perché scegliere McBasic invece di uno degli strumenti simili che esistono già, perché utilizzarlo al posto di un ambiente di sviluppo moderno e, soprattutto, che senso ha cercare di rendere la programmazione più semplice proprio adesso che l’AI sembra essere in grado di scrivere praticamente qualsiasi cosa le chiediamo.

È proprio quest’ultima domanda che, secondo me, rende il progetto più interessante oggi di quanto sarebbe stato cinque o dieci anni fa.

Per molti anni abbiamo associato la produttività di un programmatore soprattutto alla velocità con cui riusciva a scrivere codice. Linguaggi più espressivi, librerie, framework, generatori di codice e IDE sempre più sofisticati servivano, tra le altre cose, a ridurre il tempo necessario per trasformare un’idea in codice funzionante. L’intelligenza artificiale sta cambiando radicalmente questa parte del lavoro perché oggi posso descrivere una funzione in linguaggio naturale e ottenere in pochi secondi una quantità di codice che avrei impiegato molto più tempo a scrivere manualmente.

Il problema è che scrivere codice e costruire software non sono esattamente la stessa cosa.

Anche quando il codice viene scritto dall’AI rimangono il progetto, il framework, le librerie, le dipendenze, il sistema di build, le configurazioni, il database, le risorse, i certificati, i permessi e tutto quello che serve per trasformare quel codice in un’applicazione che possa essere eseguita e distribuita. Rimane inoltre un problema ancora più importante: prima o poi qualcuno deve riuscire a capire quello che è stato costruito, soprattutto quando qualcosa smette di funzionare o quando, sei mesi dopo, bisogna modificarlo.

Da questo punto di vista l’AI ha ridotto enormemente il costo della produzione del codice, ma non ha necessariamente ridotto nella stessa misura la complessità del software. In alcuni casi rischia semplicemente di nasconderla meglio, perché oggi è possibile produrre sistemi relativamente complessi senza comprendere completamente tutto quello che è stato generato.

Ed è qui che, almeno per me, BASIC torna ad essere interessante.

Non perché sia tecnicamente superiore a Swift, C#, Kotlin o qualsiasi altro linguaggio moderno. Sarebbe difficile sostenere seriamente una cosa del genere. Mi interessa perché è semplice, leggibile e relativamente prevedibile. Se l’AI genera del codice per me, voglio avere una ragionevole possibilità di leggerlo e capire cosa sta facendo senza dover attraversare cinque livelli di astrazione. Se qualcosa non funziona, voglio poter seguire il flusso del programma. Se apro il progetto dopo sei mesi, preferisco che il codice continui ad assomigliare a qualcosa scritto per essere letto da un essere umano.

Una banalissima istruzione come:

If Customer.Balance > CreditLimit Then
    ShowWarning("Credit limit exceeded")
End If

non vincerà probabilmente nessun premio per l’eleganza del linguaggio, ma ha un vantaggio piuttosto evidente: è difficile non capire cosa faccia. Nel momento in cui sempre più codice verrà prodotto automaticamente, credo che questa caratteristica possa diventare più importante e non meno importante.

A questo punto arriva però la seconda domanda: se voglio utilizzare BASIC, perché McBasic? Di implementazioni moderne ne esistono già parecchie e alcune sono prodotti maturi che vengono sviluppati da molti anni. PureBasic è multipiattaforma, produce eseguibili molto compatti ed ha una comunità consolidata. FreeBASIC è un compilatore estremamente capace. Xojo offre un ambiente RAD completo e probabilmente è uno dei prodotti contemporanei più vicini, almeno concettualmente, al tipo di esperienza che sto cercando. Ci sono poi QB64, twinBASIC e diversi altri progetti che affrontano il problema da prospettive differenti.

Non ho quindi iniziato McBasic perché mancasse un compilatore BASIC. Se quello fosse stato il problema, sarebbe stato molto più intelligente utilizzare uno dei prodotti esistenti.

Il problema è che non riuscivo a trovare esattamente l’ambiente che volevo usare.

Volevo prima di tutto un ambiente pensato per il Mac, nel quale il Mac non fosse semplicemente una delle piattaforme supportate insieme ad altre, ma il punto di partenza del progetto. Volevo inoltre recuperare quel modello di sviluppo visuale che rendeva ambienti come Visual Basic estremamente produttivi: creo un Form, aggiungo i controlli, modifico le proprietà, faccio doppio click su un controllo e scrivo il codice relativo al suo evento. Se voglio capire com’è fatta una finestra, guardo la finestra nel designer; se voglio sapere cosa succede quando premo un pulsante, guardo il relativo evento Click.

Questa distinzione è importante perché McBasic non nasce principalmente come tentativo di inventare un altro dialetto BASIC. Il linguaggio è una parte del progetto, ma probabilmente non è nemmeno la parte più importante. Quello che sto cercando di costruire è un ambiente completo nel quale linguaggio, IDE, Form Designer, debugger, controlli, database, componenti e sistema di build facciano parte dello stesso modello di sviluppo.

Visual Basic, del resto, non diventò popolare semplicemente perché BASIC era facile. Esistevano BASIC molto prima di Visual Basic. Una parte fondamentale del suo successo derivava dal fatto che permetteva di passare dall’idea all’applicazione molto rapidamente. Non pensavi separatamente alla libreria grafica, al sistema degli eventi e al modo in cui creare una finestra. Disegnavi il Form, scrivevi il codice necessario e continuavi a lavorare sul problema che volevi risolvere.

Naturalmente oggi possiamo fare tutto questo con strumenti molto più moderni. Posso creare un’applicazione Mac con Swift e Xcode, oppure utilizzare C#, Avalonia, Flutter, Electron, Qt e una lunga lista di altre tecnologie. Le utilizzo anch’io e McBasic stesso è costruito utilizzando tecnologie moderne, quindi non avrebbe molto senso impostare la questione come una battaglia tra vecchio e nuovo.

La differenza che mi interessa è piuttosto quella tra la complessità necessaria e quella che ci portiamo dietro perché lo strumento che abbiamo scelto è stato progettato per risolvere una classe di problemi molto più grande del nostro.

Se devo costruire un’applicazione destinata a milioni di utenti, con diversi servizi, team di sviluppo e requisiti complessi, accetterò volentieri una certa quantità di architettura perché probabilmente ne ho bisogno. Ma se devo creare un piccolo gestionale, un’applicazione per lavorare con un database, uno strumento interno per un’azienda, un programma per gestire un inventario o un’utility che automatizza un particolare processo, non sono convinto che la complessità dell’ambiente debba essere necessariamente proporzionata alle capacità massime del framework invece che al problema che sto cercando di risolvere.

È uno spazio che per molti anni è stato occupato molto bene da strumenti come Visual Basic, Access e FileMaker e che continua ad esistere. Ci sono ancora moltissime situazioni nelle quali un foglio Excel non basta più, ma costruire un’applicazione utilizzando uno stack completo sembra un salto sproporzionato. Ci sono inoltre applicazioni che non devono diventare prodotti, non devono essere offerte come SaaS e non devono servire centomila utenti. A volte un programma deve semplicemente risolvere bene un problema per una persona, per un ufficio o per una piccola azienda.

Per questo motivo sto trattando database, API, file e altre operazioni comuni come parti normali dell’ambiente McBasic. Se voglio utilizzare SQLite, visualizzare dei record, modificarli e salvarli, non dovrebbe essere necessario trasformare l’accesso al database in un progetto dentro il progetto. Dietro le quinte la complessità continuerà naturalmente ad esistere, ma uno degli scopi di uno strumento di sviluppo è proprio quello di assorbirne una parte invece di trasferirla interamente a chi lo utilizza.

Lo stesso ragionamento vale per il sistema dei componenti. Uno dei grandi vantaggi del vecchio ecosistema Visual Basic era la possibilità di aggiungere funzionalità senza doverle necessariamente costruire da zero. Installavi un componente, questo appariva nella Toolbox e da quel momento potevi utilizzarlo come qualsiasi altro controllo, con le sue proprietà, i suoi metodi e i suoi eventi. È un modello che continua a sembrarmi estremamente sensato e che voglio riprendere in McBasic.

Non avrebbe senso cercare di inserire nell’IDE qualsiasi controllo o funzionalità immaginabile. Preferisco che esista un nucleo sufficientemente completo per costruire una normale applicazione e che il resto possa essere aggiunto attraverso componenti. Grafici avanzati, reporting, controlli database specializzati, editor, protocolli o integrazioni con servizi esterni possono essere sviluppati indipendentemente e, in prospettiva, distribuiti anche da altri sviluppatori. Alcuni potranno essere gratuiti, altri commerciali. Se questo ecosistema funzionerà, McBasic potrà crescere senza che ogni nuova esigenza debba necessariamente diventare una nuova funzione del prodotto principale.

Rimane infine l’elefante nella stanza: se l’intelligenza artificiale può già generare un’applicazione partendo da una descrizione, perché dovrei utilizzare McBasic?

È una domanda che mi sono posto diverse volte durante lo sviluppo e sono arrivato alla conclusione che l’AI non rende inutile un ambiente come McBasic. Potrebbe addirittura renderlo più utile.

Quando chiedo ad un’AI di costruire un’applicazione utilizzando uno stack moderno, il modello deve prendere una quantità considerevole di decisioni. Deve scegliere o assumere framework, librerie, strutture del progetto e pattern architetturali. Due richieste quasi identiche possono produrre applicazioni organizzate in maniera completamente diversa. Se poi continuo a sviluppare il progetto attraverso l’AI, rischio progressivamente di diventare l’operatore di un sistema che conosco sempre meno.

Un ambiente come McBasic riduce deliberatamente lo spazio delle possibilità. L’AI può conoscere il linguaggio, la libreria standard, il modello dei Form, tutti i controlli disponibili, le loro proprietà, i metodi e gli eventi, il sistema dei componenti e la struttura precisa di un progetto. Può inoltre conoscere il Form sul quale sto lavorando, sapere quali controlli contiene e comprendere le relazioni tra il codice e l’interfaccia.

Se sto lavorando su frmCustomers e chiedo di aggiungere una ricerca mentre l’utente digita, non voglio che l’AI inventi un’architettura. Voglio che guardi il progetto esistente, veda txtSearch e grdCustomers, capisca come sono collegati i dati e faccia la modifica utilizzando il modello di sviluppo di McBasic.

In questo scenario la semplicità dell’ambiente aiuta contemporaneamente l’essere umano e l’intelligenza artificiale. L’AI ha meno decisioni arbitrarie da prendere, il risultato è più prevedibile e l’utente rimane all’interno di un sistema che può ancora comprendere. Se qualcosa non funziona, posso chiedere all’AI di aiutarmi, ma posso anche aprire l’evento e leggere quello che ha scritto.

È forse questo l’aspetto che trovo più interessante dell’intero progetto. BASIC e intelligenza artificiale sembrano, a prima vista, appartenere a due epoche completamente diverse dell’informatica. In realtà potrebbero funzionare particolarmente bene insieme proprio perché risolvono due parti diverse dello stesso problema. L’AI riduce drasticamente il lavoro necessario per produrre codice, mentre un ambiente semplice e prevedibile riduce il lavoro necessario per capire, organizzare e mantenere quello che è stato prodotto.

Alla fine, quindi, non penso che la ragione per utilizzare McBasic sia che BASIC fosse migliore trent’anni fa o che gli strumenti moderni siano diventati inutilmente complicati. Sarebbero entrambe semplificazioni poco credibili. Penso invece che esista ancora una categoria molto ampia di applicazioni per le quali rapidità, leggibilità e semplicità dell’ambiente contano più della possibilità di scegliere tra venti framework differenti.

McBasic nasce per quella categoria di applicazioni e, molto banalmente, nasce anche perché è lo strumento che avrei voluto trovare quando ho iniziato a cercarlo. Se avessi trovato un ambiente Mac con il modello di sviluppo visuale che volevo, sufficientemente semplice da permettermi di creare rapidamente una piccola applicazione ma abbastanza completo da non doverlo abbandonare quando l’applicazione cresceva, con database, componenti e AI pensati come parti dello stesso sistema, probabilmente lo avrei utilizzato.

Non l’ho trovato, e alla fine ho deciso di provare a costruirlo.