VBがキライ

2002/07/13 Visual Studio.NETに関する記述を訂正。

私はVB(Visual Basic)がキライである。その理由はいくつかあり、

言語仕様がころころ変わるので萎える。そもそも言語自体も萎えるようなものである。
ランタイムライブラリが異様にでかく、しかも変な配布制限があるため、扱いが面倒くさい。
なぜか知らないが、システムのDLL書き換えなどの影響をもろに受けやすい。

といったところが思い浮かぶが、何よりも

実行速度が遅い

というのが最大の理由だ。4.0までVBは完全なインタプリタ(--EXEファイルの形をしていても、実際にはVBランタイムライブラリがインタプリタの役割をして、インタプリタ実行されていた--)であったので、「5.0では最適化機能つきネイティブコンパイラ採用」という宣伝には感激したものだった。コードの高速化、インタプリタが不要になることによるランタイムライブラリの縮小……胸が高鳴る日々が続いた。

パフォーマンス!!

だが、実体はというと、各誌のベンチマークなどで明らかになっているが、最適化コンパイルしてもCの数十分の1のパフォーマンスしかでないものだったのだ。あれには心底失望させられた。それに加えて、ランタイムライブラリの大きさも全く変わっていなかった。ランタイムライブラリを全て含めると、(もちろん圧縮しても、)フロッピー1枚には入らなくなってしまうのだ。具体的なデータは主な開発ツールの数値計算速度比較やヒラテ技研ソフトウェアライブラリ実行速度の比較テストにある。

相変わらずの遅さ、ますます奇異になっていく言語仕様、そんなあれこれに嫌気がさし、ちょうど入試があって実際のプログラミングからは遠ざかっていった。受験勉強の合間をぬってひたすらC/C++によるWin32プログラミングの本を読みあさっていたため、受験が終わったとき、目の前にはVisual C++しかなかった。

"手軽にGUI"

私はVBの「手軽にGUIアプリケーションが書ける」というスタンスには反対しない。現在私はThellのウィンドウ関連のコードを数日かけて読みやすくまとめているのだが、VBだったらそんな作業ははじめっから皆無だ。

手軽にGUIアプリケーションを書きたければ、BorlandのDelphiかC++ Builderを使うべきだ。両者とも、非常にいいコードを生成することで知られ、高速さで知られるVisual C++と同じくらいの性能を出す。

では私は、なぜこうしてSDKでこつこつと書く道を選んだのだろうか。最大の理由はVisual C++があり、MFCがキライだったので、自然とWin32SDKに落ち着いたということ。そして、一旦覚えた言語を変えたくないように、一度覚えたスタイルも手放せないということで今に至っているわけだ。

.NETに思うこと

Visual Studio.NETでは、VB以外でも簡単なGUIの構築が可能になると言う。Visual C++が、真の"Visual" C++になるわけだ。だが、巷にあふれる情報はみなC#での開発ばかりを取り上げており、私の知りたい"C++ではどうするのか"という疑問にはほとんど答えてくれない。(おそらく、大半のプログラマは.NETになってもC++を使いたいと考えるに違いない。)

何故私はこうも、時代の流れに反することばかりを願ってしまうのだろうか。プログラミングの流儀というのは多分に好みによるところが非常に大きいため、どうしようもないのが実状だ。Visual Studio.NETでは、C++でもC#の場合と同じくGUIを構築できるだろうし、WinFormsがMFCの替わりに快適なGUIプログラミングを提供してくれるのだろう。問題は、必要とする情報が手に入るか、というところにある。Microsoftの思惑通り、Windows開発がC#一色になってしまうと、C++で開発したい私にとっては非常にやりづらい世の中になってしまいそうだ。

訂正。やはりVisual C++はVisualになれませんでした。RAD開発ができるのはVisual C#/Visual Basic.NETのみ。Visual Studio.NETを実際に購入してみて判明。どこで情報を読み違ったのだろうか？Beta以降に仕様が変更された、とかかもしれない。残念だ。

戻る