Visual Basic 6 nell'anno 2026: Un appello a Microsoft

C# come linguaggio di programmazione non è affatto peggiore di VB6, nemmeno di VB.NET.

Ma: l'ambiente di sviluppo .NET sembra un passo indietro all'età della pietra per uno sviluppatore VB6:

1. Mancano le magiche funzionalità di debugging che hanno reso la "programmazione in tempo reale" in VB6 un vero e proprio stimolo per la programmazione: Si parte da una bozza e la si ottimizza in fase di esecuzione.
2. .NET riunisce centinaia di tecnologie sotto lo stesso tetto, ma l'interfaccia sovraccarica scoraggia fin dall'inizio i nuovi arrivati e la curva di apprendimento per familiarizzare con l'IDE è enorme.
3. L'IDE .NET è molto meno reattivo e l'avvio di una piccola applicazione Hello World può richiedere 10 secondi di tempo di compilazione prima di avviare un semplice programma...
4. L'IDE .NET sembra essere estremamente avido di risorse. Installare rapidamente un ambiente di sviluppo .NET su un Surface Laptop con 250GB di spazio sul disco rigido diventa rapidamente come eseguire un percorso a sputo quando si tratta di liberare le risorse necessarie.

Il mio appello a Microsoft: VB6 deve diventare OpenSource in modo da poter essere ulteriormente sviluppato dalla comunità e trasferito nell'anno 2026.

VB6 continua a vivere nell'anno 2026

La comunità non ha mai rinunciato a Visual Basic 6. Kr00l ha riportato i Microsoft Common Controls spesso utilizzati in VB6 nel 2026 e ha creato gli stessi componenti completamente DPI-aware e con capacità Unicode/UTF-8.

TwinBasic sta diventando un compilatore a 64 bit avviabile anche per i programmi esistenti. L'approccio della comunità è lodevole ed estremamente ambizioso, soprattutto perché nessuno ha accesso al codice sorgente di VB6 e la comunità deve sviluppare tutto da zero.

Purtroppo, l'approccio è talmente ambizioso che vale la pena chiedersi: quali altre alternative abbiamo?

Molte delle debolezze di VB6, come il vero multithreading, potrebbero essere risolte nel 2026 con componenti Rust aggiuntivi che potrebbero essere agganciati all'occorrenza.

Il grado di OOP di Visual Basic è un ingegnoso compromesso tra la riduzione della complessità e l'uso facoltativo delle classi come contenitori di metodi e dati, laddove questo favorisce realmente l'efficienza della programmazione. Questo approccio non dovrebbe essere assolutamente modificato.

Il programma di installazione dell'IDE VB6 potrebbe e dovrebbe essere completamente ricostruito, ad esempio con Inno Setup.

Il DPIAwareness completo, la piena capacità UTF8 e persino un compilatore a 64 bit potrebbero essere integrati direttamente nel codice sorgente di VB6.

Dove VB6 chiama ancora metodi Ansi nell'API Win32 (ad esempio WriteTextA), potremmo sostituirli con metodi W con capacità UTF8 (WriteTextW).

Noi, la comunità, ci occuperemo di questo compito e porteremo l'ingegnoso approccio di Visual Basic 6 nell'anno 2026. Perché nessuno degli ex fan di VB6 sta attualmente utilizzando Visual Basic .NET con vera passione.

E questa deve essere un'ammissione per Microsoft: la decisione di abbandonare VB6 e di posizionare .NET come suo successore è fallita.

Molti degli sviluppatori VB6 rimasti dovranno lentamente riorientarsi, perdere la pazienza e passare lentamente ma inesorabilmente a Linux e Rust.

Oppure Microsoft rilascerà il codice sorgente di Visual Basic 6 e noi, la comunità, porteremo questo brillante ambiente di sviluppo per Windows nell'anno 2026.

Quest'ultima ipotesi sarebbe una grande vittoria per la comunità, per gli sviluppatori, per gli utenti e anche per l'intero settore tecnologico.

Infine, ma non per questo meno importante, sarebbe un grande vantaggio per Microsoft: la decisione di rendere disponibile il codice sorgente di Visual Basic 6 come open source aumenterà la reputazione di Microsoft e farà tornare molti fan e sviluppatori, legandoli all'ecosistema Microsoft.

Direi che si tratta di una grande vittoria per Microsoft.