Visual Basic 6 en el año 2026: Una llamada a Microsoft

C# como lenguaje de programación no es en absoluto peor que VB6, ni siquiera que VB.NET.

Pero: el entorno de desarrollo .NET parece un paso atrás en la Edad de Piedra para un desarrollador de VB6:

1. Carece de las mágicas capacidades de depuración que hacían de la "programación en vivo" en VB6 un auténtico revulsivo para la programación: Se empieza con un borrador y se optimiza en tiempo de ejecución.
2. .NET reúne lo que parecen cientos de tecnologías bajo un mismo techo, pero la sobrecargada interfaz echa para atrás a cualquier recién llegado o switcher desde el principio y la curva de aprendizaje para familiarizarse con el IDE es enorme.
3. El IDE de .NET parece mucho menos receptivo y arrancar una pequeña aplicación Hello World puede llevar 10 segundos de tiempo de compilación antes de que un programa sencillo siquiera se inicie...
4. El IDE .NET parece consumir muchos recursos. Instalar rápidamente un entorno de desarrollo .NET en un portátil Surface con 250 GB de espacio en el disco duro se convierte rápidamente en una ruta de escupitajos cuando se trata de liberar los recursos necesarios.

Mi llamada a Microsoft: VB6 debe convertirse en OpenSource para que pueda seguir siendo desarrollado por la comunidad y trasladado al año 2026.

VB6 sigue vivo en el año 2026

La comunidad nunca ha abandonado Visual Basic 6. Kr00l ha trasladado los Microsoft Common Controls utilizados a menudo en VB6 a 2026 y ha creado los mismos componentes completamente compatibles con DPI y con Unicode/UTF-8.

TwinBasic se está convirtiendo en un compilador de 64 bits iniciable incluso para programas existentes. El enfoque de la comunidad es encomiable y extremadamente ambicioso, especialmente porque nadie tiene acceso al código fuente de VB6 y la comunidad tiene que desarrollarlo todo desde cero.

Desgraciadamente, el planteamiento es en realidad tan ambicioso que cabe preguntarse: ¿qué otras alternativas tenemos en realidad?

Muchos de los puntos débiles de VB6, como el auténtico multithreading, podrían resolverse en 2026 con componentes adicionales de Rust que podrían acoplarse en caso necesario.

El grado de OOP en Visual Basic es un ingenioso compromiso entre la reducción de la complejidad y el uso opcional de clases como contenedores de métodos y datos donde realmente se promueve la eficiencia en la programación. Este enfoque no debería modificarse en absoluto.

El instalador para el IDE de VB6 podría y debería ser completamente reconstruido, por ejemplo con Inno Setup.

DPIAwareness completo, capacidad UTF8 completa e incluso un compilador de 64 bits podrían ser construidos directamente en el código fuente de VB6.

Donde VB6 todavía llama a métodos Ansi en la API Win32 (por ejemplo WriteTextA), podríamos sustituirlos por métodos W con capacidad UTF8 (WriteTextW).

Nosotros, la comunidad, nos encargaríamos de esta tarea y llevaríamos el ingenioso enfoque de Visual Basic 6 al año 2026. Porque ninguno de los antiguos fans de VB6 utiliza actualmente Visual Basic .NET con verdadera pasión.

Y esto debe ser un reconocimiento para Microsoft: la decisión de discontinuar VB6 y posicionar .NET como su sucesor ha fracasado.

Muchos de los desarrolladores de VB6 que quedan tendrán que reorientarse poco a poco, perder la paciencia y pasarse a Linux y Rust de forma lenta pero segura.

O Microsoft liberará el código fuente de Visual Basic 6 y nosotros, la comunidad, llevaremos este brillante entorno de desarrollo para Windows al año 2026.

Esto último sería una gran victoria para la comunidad, para los desarrolladores, para los usuarios e incluso para todo el sector tecnológico.

Y por último, pero no por ello menos importante, sería una gran ventaja para Microsoft, ya que la decisión de hacer que el código fuente de Visual Basic 6 esté disponible como código abierto también impulsará la reputación de Microsoft y traerá de vuelta a muchos fans y desarrolladores, y los vinculará al ecosistema de Microsoft.

En mi opinión, sería una gran victoria para Microsoft.