神話に喝！――WindowsからLinuxへの移行をめぐって
おそらく、こんなふうに考えているのだろう。「Free Software FoundationのWebサイトを読むと、どうやら開発には無垢のCをそのまま使っているようだね。無論、Visual C++やVisual Basicがないことはわかっているよ。Linux独自のコンポーネント・モデルなどないのだろう。それに、ハードウェアを低レベルで操作するDirectXとなると、それに類するものはまったく見えない。生粋のWindows使いにとって、Linuxのプログラムを作るのは単に面倒という以上のものがあるね」
もし上の説を信じるなら、「旦那、ニューヨーク市に値ごろの橋がありますよ。ここだけの話、今週限り特別価格でご提供しますよ！」ということになる。まあ冗談はさておき、ルーターのあちら側の方々がLinuxプログラミングをめぐって信じている神話はIP6アドレスの数ほどもある。そんなわけだから、いくつかつぶしておこうと思う。
神話: Linuxにコンポーネント・モデルがない
MFC（Microsoft Foundation Classes）の世界でCOM（Component Object Module）とActiveXテクノロジを使って手軽に開発が行えるのは確かに便利だ。だが、Linuxの世界もそれほど荒涼としたものではない。遥か昔、Unixプラットフォーム向けのアプリケーションを書こうとすると細かなことをいろいろ気にしなければならず、作業の流れもばらばらだった。しかし、今は違う。オブジェクト・モデルがないと考えるのは、転がり落ちる大岩を山頂まで押し上げる、あのシジフォスの神話を信じるようなものである。
実際、デスクトップ・マネージャはいずれも独自のオブジェクト・モデルを持つ。たとえば、GnomeのBonoboはCORBA（Common Object Request Broker）を実装したもので、MFCに似たGUIコントロールと、どのアプリケーションでも使える非GUIコンポーネント、それにCOM/DCOMやOpenDocと似たアプリケーション間インタフェースをサポートする。KDEのKPartsも MFCライクなフレームワークとどこでも使えるコンポーネントを組み合わせた独自のモデルである。具体的なタスクのレベルで見ると、ほかにもコンポーネント・セットは存在する。たとえば、OpenOffice.orgのオフィスベーススイートコンポーネント、XPCOM（MozillaのCOMサブセット）、XUL（XMベースのUI記述言語）などである。もちろん、SunのJavaBeansも忘れてはならない。
Linuxアプリケーションは書きたいが、新しいことは学びたくないというWindowsプログラマは、WINEからCOM/DCOMのサブセットを入手するとよい。しかし、WINEの開発者であるAlexandre Julliardは、コンポーネント・モジュールの欠如の問題に別の見解を持っている。「この神話は基本的には正しいと思う」とJulliardは言う。「もちろん、LinuxがCOMの実装を必要とするかどうかはまったく別の問題だ。Linuxはそれがなくてもうまくやれると思う。無論、これはWindowsプログラマの望む答えになっていないだろうが。Linuxには.Net実装＋Monoプロジェクトというものがあり、.NetはCOMに取って代わると考えられている。この問題はこれで決着するのだろう。」
神話: Linuxは言語が少なく、IDEがない
WindowsプログラマがFree Software FoundationのWebサイトを見てどんな印象を持つかはわからないが、本格的なLinuxプログラミングのための「まともな」言語はCだけではない。Burger Kingがよく言っていたように、LispもあればC++もあり、Pythonも使える。IDE（統合開発環境）だっていろいろあるので、自由に使えばよい。
編集ツールに関して、Emacsとviの戦いはGNU/LinuxとWindowsの議論と同様、苛烈なものがある。どちらのプログラムも当初はただのテキストエディタだったが、今やVisual C++の編集機能に匹敵する能力を備え、Emacsに至ってはGCCコンパイラのカバーする全言語をサポートし、CVSまで統合している。
テキストベースのインタフェースを、時たまわけがわからなくなるキーボードコマンドを駆使して使う自信がなければ、GUIベースのIDEもいろいろある。GnomeのAnjutaはプログラミング用で、これをGladeというキビキビしたアプリケーション開発ツールと組み合わせればユーザ・インタフェースの編集ができる。KDevelopは同じ機能をKDEで提供する。EclipseはIBMによってオープンソース化されたもので、Java用のIDEである。
完全に統合されたスイートの中で決まったツールセットを決まったやり方で使うのは簡単だが、IDEの範囲から外れたことをやろうとすると、じれったい思いをする。Linuxのツールなら、さまざまなスイートをいろいろ組み合わせて使うことができる。1つのツールセットに1つの機能セットという縛りがないのだ。現実のワークフローに合わせて最適なツールセットを選ぶことができるだろう。
神話: DirectX、DirectX、DirectX！
Linuxには低レベルのハードウェアを操作するDirectXのようなテクノロジが単体で存在しない。だが、それはプログラムからハードウェアを操作できないという意味ではない。使いやすい1つのパッケージにまとまっていないだけの話だ。オープンソースの開発者たちは、いくつかのプロジェクトでハードウェア・ライブラリの問題と取り組んできた。どのプロジェクトも、ある一点に集中している。例を挙げるなら、OpenALは3DオーディオのAPIで、これはWindows、Mac、Linuxの各プラットフォームでUnreal 2やSoldier of FortuneといったソフトウェアのAPIとして使われてきた。サンプリング・オーディオで最も人気のあるライブラリはlibmpegとlibvorbisだが、そのほかAIFFからWAVまで、ほとんどのサウンド・フォーマットについてライブラリを手に入れることができる。コントロールや入力、ウィンドウ管理に関して、Linuxのほとんどの開発者はSimple DirectMedia Layer（SDL）を使用している。SDLはエクステンションによって多数のオペレーティング・システムの各種オーディオ、ビデオ、2D/3Dグラフィックス、フォントをサポートする。
「たいていの開発者はテクスチャに2Dグラフィックスを使い、それを3Dポリゴンに貼り付けて動かす」と、ベテランの開発者で、オープンソースの権威でもあるJohn Le’Brecageは説明する。「OpenGL下のネイティブな2Dは非常に遅い。3DとOpenGLでそれをごまかすのがいつものやり方だ」
神話: 喝！
つまるところ、プログラミングはプログラミングに過ぎない。WindowsプログラマがLinuxに移行するにはある程度努力が必要だろうが、ヘラクレスのような超人的な力が必要なわけでもない。Linuxへの移行をめぐる都市伝説は、多くの都市伝説がそうであるように、現実の障害よりもFUDに満ちている。Linuxの迷宮にミノタウロスの怪物はいないのである。
