年におけるVisual Basic 62026: マイクロソフトへの呼びかけ

プログラミング言語としてのC#は、VB6よりもVB.NETよりも決して悪くはない。

しかし、.NETの開発環境は、VB6の開発者にとっては石器時代に逆戻りしたように感じられる：

1. VB6の「ライブ・プログラミング」をプログラミングの真のブースターにしていた魔法のようなデバッグ機能が欠けている：下書きから始めて、実行時に最適化する。
2. .NETは、何百ものテクノロジーをひとつ屋根の下に統合しているように感じられるが、過負荷なインターフェースは、新規参入者や乗り換え組を最初から遠ざけ、IDEに慣れるための学習曲線は非常に大きい。
3. .NETのIDEは反応が鈍く、小さなHello Worldアプリを起動すると、単純なプログラムが始まるまでにコンパイル時間が1秒かかることもある。
4. .NET IDEは非常にリソースを消費するようだ。ハードディスク容量250GBのSurface Laptopに.NET開発環境を素早くインストールしても、必要なリソースを解放することになると、すぐにツバを吐くようなルートになる。

マイクロソフトへの私の呼びかけ：VB6はオープンソースになり、コミュニティによってさらに開発され、2年に引き継がれるようにしなければならない。

VB6は3年目も生き続ける

コミュニティは決してVisual Basic 6をあきらめなかった。Kr00lは、VB6でよく使われていたMicrosoft Common Controlsを2026に引き継ぎ、同じコンポーネントを完全にDPI対応、Unicode/UTF-8対応にしました。

TwinBasicは、既存のプログラムでも起動可能な64ビットコンパイラに発展しつつある。特に、誰もVB6のソースコードにアクセスできず、コミュニティがゼロからすべてを開発しなければならないのだから。

残念なことに、このアプローチは実のところ非常に野心的である。

本物のマルチスレッドなど、VB6の弱点の多くは、必要に応じてドッキングできるRustコンポーネントを追加することで、2026年には解決できるだろう。

ビジュアル・ベーシックにおけるOOPの程度は、複雑さを軽減することと、メソッドやデータのコンテナとしてクラスを任意に使用することで、プログラミングの効率化を促進することの間の巧妙な妥協点である。このアプローチはまったく変えるべきではありません。

VB6 IDEのインストーラーは、Inno Setupなどで完全に作り直すことができるし、またそうすべきである。

完全なDPIAwareness、完全なUTF8機能、そして64ビットコンパイラさえも、VB6のソースコードに直接組み込むことができるだろう。

VB6がまだWin32 APIでAnsiメソッドを呼び出しているところ（例えばWriteTextA）では、私たちはこれらをUTF8対応のWメソッド（WriteTextW）に置き換えることができます。

私たちコミュニティはこの作業を引き継ぎ、Visual Basic 6の独創的なアプローチを2026年に引き継ぐことになります。というのも、かつてのVB6ファンの中には、現在Visual Basic .NETを本当に熱心に使っている人はいないからだ。

VB6を廃止し、.NETをその後継と位置づけるという決定は失敗したのだ。

残されたVB6開発者の多くは、ゆっくりと方向転換し、忍耐を失い、そしてゆっくりと、しかし確実にLinuxやRustに乗り換えなければならないだろう。

あるいは、マイクロソフトがVisual Basic 6のソースコードを公開し、われわれコミュニティがこの素晴らしいWindows用開発環境を2026年に復活させることになるだろう。

後者は、コミュニティにとっても、開発者にとっても、ユーザーにとっても、さらにはテクノロジー部門全体にとっても大きな勝利となるだろう。

ビジュアル・ベーシック6のソースコードをオープンソースとして公開するという決定は、マイクロソフトの評判を高め、多くのファンや開発者を呼び戻し、マイクロソフトのエコシステムに結びつけるだろう。

これは、マイクロソフトにとって重大な勝利と言えるだろう。