Visual Basic 6 у році 2026: Дзвінок до Microsoft

C# як мова програмування нічим не гірша за VB6 і навіть за VB.NET.

Але: середовище розробки .NET відчувається як крок назад у кам'яний вік для розробника VB6:

1. У ньому відсутні чарівні можливості налагодження, які робили "живе програмування" у VB6 справжнім бустером для програмування: Ви починаєте з чернетки і оптимізуєте її під час виконання.
2. .NET об'єднує, здається, сотні технологій під одним дахом, але перевантажений інтерфейс з самого початку відштовхує будь-якого новачка або перемикача, а крива навчання для ознайомлення з IDE величезна.
3. IDE .NET набагато менш швидка, і запуск невеликого додатку Hello World може зайняти 10 секунди часу компіляції ще до того, як запуститься навіть проста програма...
4. .NET IDE здається надзвичайно вимогливим до ресурсів. Швидке встановлення середовища розробки .NET на ноутбук Surface Laptop з 250 ГБ місця на жорсткому диску швидко стає схожим на проходження маршруту, коли справа доходить до вивільнення необхідних ресурсів.

Мій заклик до Microsoft: VB6 повинен стати OpenSource, щоб його можна було розвивати спільнотою і перенести в рік 2026.

VB6 живе у році 2026

Спільнота ніколи не відмовлялася від Visual Basic 6. Kr00l переніс Microsoft Common Controls, які часто використовуються у VB6, у 2026 і створив ті самі компоненти, що повністю підтримують DPI та Unicode/UTF-8.

TwinBasic розвивається у 64-розрядний компілятор, який можна запускати навіть для існуючих програм. Підхід спільноти є похвальним і надзвичайно амбітним, особливо тому, що ніхто не має доступу до вихідного коду VB6 і спільноті доводиться розробляти все з нуля.

На жаль, підхід насправді настільки амбітний, що варто запитати: а які інші альтернативи ми маємо?

Багато слабких сторін VB6, таких як справжня багатопоточність, можуть бути вирішені у 2026 році за допомогою додаткових компонентів Rust, які можна буде зістикувати, якщо буде потреба.

Ступінь ООП у Visual Basic - це геніальний компроміс між зменшенням складності та необов'язковим використанням класів як контейнерів для методів і даних там, де це дійсно сприяє підвищенню ефективності програмування. Цей підхід не слід змінювати взагалі.

Інсталятор для VB6 IDE може і повинен бути повністю перебудований, наприклад, за допомогою Inno Setup.

Повна підтримка DPIA, повна підтримка UTF8 і навіть 64-розрядний компілятор можуть бути вбудовані безпосередньо у вихідний код VB6.

Там, де VB6 все ще викликає методи Ansi у Win32 API (наприклад, WriteTextA), ми могли б замінити їх на методи W з підтримкою UTF8 (WriteTextW).

Ми, спільнота, візьмемо на себе це завдання і перенесемо геніальний підхід Visual Basic 6 у 2026 рік. Тому що ніхто з колишніх фанатів VB6 зараз не використовує Visual Basic .NET з будь-якою справжньою пристрастю.

І це має бути визнанням для Microsoft: рішення припинити VB6 і позиціонувати .NET як його наступника провалилося.

Багатьом розробникам, що залишилися на VB6, доведеться повільно переорієнтуватися, втратити терпіння, а потім повільно, але впевнено переходити на Linux і Rust.

Або ж Microsoft випустить вихідний код Visual Basic 6, і ми, спільнота, перенесемо це блискуче середовище розробки для Windows у 2026 рік.

Останнє було б великою перемогою для спільноти, розробників, користувачів і навіть для всього технологічного сектору.

І останнє, але не менш важливе, це було б великим плюсом для Microsoft, оскільки рішення зробити вихідний код Visual Basic 6 доступним у вигляді відкритого коду також підвищить репутацію Microsoft і поверне багатьох шанувальників і розробників, а також прив'яже їх до екосистеми Microsoft.

Я б сказав, що це була б серйозна перемога для Microsoft.