Visual Basic 6 w roku 2026: Połączenie z firmą Microsoft

C# jako język programowania nie jest w żadnym wypadku gorszy od VB6, nawet od VB.NET.

Ale: środowisko programistyczne .NET wydaje się być krokiem wstecz do epoki kamienia łupanego dla programisty VB6:

1. Brakuje magicznych możliwości debugowania, które sprawiły, że "programowanie na żywo" w VB6 stało się prawdziwym bodźcem do programowania: Zaczynasz od szkicu i optymalizujesz go w czasie wykonywania.
2. .NET łączy w sobie setki technologii pod jednym dachem, ale przeładowany interfejs zniechęca każdego nowicjusza lub osobę zmieniającą środowisko od samego początku, a krzywa uczenia się w celu zapoznania się z IDE jest ogromna.
3. IDE .NET jest znacznie mniej responsywne, a uruchomienie małej aplikacji Hello World może zająć 10 sekund czasu kompilacji, zanim prosty program w ogóle się uruchomi...
4. IDE .NET wydaje się być niezwykle zasobożerne. Szybka instalacja środowiska programistycznego .NET na Surface Laptop z 250 GB miejsca na dysku twardym szybko staje się jak uruchomienie trasy plucia, jeśli chodzi o zwolnienie wymaganych zasobów.

Mój apel do Microsoftu: VB6 musi stać się OpenSource, aby mógł być dalej rozwijany przez społeczność i przeniesiony do roku 2026.

VB6 żyje w roku 2026

Społeczność nigdy nie zrezygnowała z Visual Basic 6. Kr00l przeniósł Microsoft Common Controls często używane w VB6 do 2026 i stworzył te same komponenty w pełni obsługujące DPI i Unicode/UTF-8.

TwinBasic rozwija się w 64-bitowy kompilator, który można uruchomić nawet dla istniejących programów. Podejście społeczności jest godne pochwały i niezwykle ambitne, zwłaszcza że nikt nie ma dostępu do kodu źródłowego VB6 i społeczność musi opracowywać wszystko od zera.

Niestety, podejście to jest tak ambitne, że warto zadać sobie pytanie: jakie mamy inne alternatywy?

Wiele słabości VB6, takich jak prawdziwa wielowątkowość, można by rozwiązać w 2026 roku za pomocą dodatkowych komponentów Rust, które można by zadokować w razie potrzeby.

Stopień OOP w Visual Basic jest genialnym kompromisem między zmniejszeniem złożoności a opcjonalnym wykorzystaniem klas jako kontenerów metod i danych, gdzie naprawdę promuje wydajność programowania. To podejście nie powinno być w ogóle zmieniane.

Instalator dla VB6 IDE może i powinien zostać całkowicie przebudowany, na przykład za pomocą Inno Setup.

Pełna znajomość DPIA, pełna obsługa UTF8, a nawet 64-bitowy kompilator mogłyby być wbudowane bezpośrednio w kod źródłowy VB6.

Tam, gdzie VB6 wciąż wywołuje metody Ansi w Win32 API (np. WriteTextA), moglibyśmy zastąpić je metodami W obsługującymi UTF8 (WriteTextW).

My, społeczność, podjęlibyśmy się tego zadania i przenieślibyśmy genialne podejście Visual Basic 6 do roku 2026. Ponieważ żaden z byłych fanów VB6 nie używa obecnie Visual Basic .NET z prawdziwą pasją.

I to musi być przyznanie się Microsoftu: decyzja o wycofaniu VB6 i pozycjonowaniu .NET jako jego następcy nie powiodła się.

Wielu pozostałych programistów VB6 będzie musiało powoli zmienić orientację, stracić cierpliwość, a następnie powoli, ale pewnie przejść na Linuksa i Rusta.

Albo Microsoft wyda kod źródłowy Visual Basic 6, a my, społeczność, wprowadzimy to genialne środowisko programistyczne dla systemu Windows do roku 2026.

Ta druga opcja byłaby wielką wygraną dla społeczności, deweloperów, użytkowników, a nawet dla całego sektora technologicznego.

I wreszcie, co nie mniej ważne, byłby to duży plus dla Microsoftu, ponieważ decyzja o udostępnieniu kodu źródłowego Visual Basic 6 jako open source zwiększy również reputację Microsoftu i przyciągnie wielu fanów i programistów oraz zwiąże ich z ekosystemem Microsoftu.

Powiedziałbym, że byłaby to poważna wygrana dla Microsoftu.