星田さんの記事に対するコメント。
まず、Racketに対するGUIについては次の記事を参考に。
ここでは色々と追加の話を書いていく。
まず、コンピュータのソフトウェアの歴史は、標準化への歴史、って言い換えてもいいくらいだ。
最初は独自仕様のなにかが誕生する。そしてそれがプラットフォームをまたぐ、と。
ハードウェア、ソフトウェア両者共、デファクトスタンダードを含み、「標準化」へ突き進んでくる、ってのが歴史上の流れとなる。
文字コード、なんかも元々はハードウェア・プラットフォームによって「違ってた」のが最初だ。それがアスキーコードを仲介して「標準化」されてきてる。
プログラミング言語もそうで、どれでも最初、登場時は「ある特定のプラットフォーム依存」だったりする。それがその特定のプラットフォームを飛び越えて別々のプラットフォームに移植され、差異が出て、また「共通基盤」を求めて標準化する。各々のプラットフォームの「差異」を吸収するように成長していくわけだ。
キーボード配列もそう。SHARP X68000のキーボードは現行ポピュラーなIBM-PCから標準化されたキーボードの配列とは違う。PC-9801もしかり、だ。今はISO(国際標準化機構)が制定したキーボード配列に(アメリカ以外は)準拠した、あるいはそれに近いキー配列が主流になっている。
X68000のキーボード。色々と今の観点からは不可思議なキーが付いてて、全般的には現代のキーボード配列とは互換性が無い。言い換えれば、1980年代当時の「キーボード」とは、プラットフォーム毎に最適化されたブツで、そのマシンの「性能」によって左右されていた。
Apple Macintoshのキーボード。後のヴァージョンと違い、80年代のMacのキーボードは、ファンクションキーを持たなかった。これはIBM-PC的なDOSのCLI環境との決別を意味し、「ファンクションキーが必要になるような動作は全てワンボタンマウスの操作で」と言う、現時点で見ると狂った主張の元にデザインされてた、からだ。
Commodore Amiga 1200。MSXのようなキーボード一体型のマシン。これも現行のキー配列とは若干違う。また、ファンクションキーもF10までしか存在しない。また、X68000/Mac/Amiga 1200共にコントロールキー(Ctrl)は現行のIBM-PCを基とした場所に存在せず、Shiftキーに近い位置になってる事に気づいただろうか?逆にCaps Lockキーがない、あるいは位置が違う。このように、80年代及び90年代前半辺りまでは民生機には「統一環境」なぞ無く、ハードウェアメーカーによってキーボード配列が「違って」たんだ。
こういう様々な「違い」を乗り越えて、「標準化」してきたのがプログラムやプログラミング言語の歴史だ。
そして残った場所がグラフィック、だと言えるだろう。そしてこの「残った部分」と言うのがなかなか厄介なワケだ。
元々、例えば民生機でも、「標準となるグラフィックの仕組み」ってのはバラバラだった。何故なら昔のPCだと画像表示自体が難しかったからだ。
結果描画速度、そして使える色彩数、解像度なんかも全くのバラバラだった。そもそもシステムが違ってたわけだ。
例えばApple IIは特定の画像用回路を持たず、全部CPUで賄ってた。富士通のFM-7なんかはCPUを二個積んで片方を画像用としてた。SORD M5から始まってSEGA SC-3000、そしてMSXはテキサスインスツルメンツ製の「PPU」(Picture Processing Unit)と呼ばれる画像チップを使ってた。Commodore Amigaは独自の画像回路を積んでいた・・・と百花繚乱だったんだ。
もっと言えば、現在のディスプレイ表示はほぼ「ビットマップ方式」になってるが、かつては別の方式だった「ビットプレーン方式」も良く使われてた。PC-9801、Commodore Amigaやスーパーファミコンまでのゲーム機は基本的にビットプレーン方式であり、かつ、ビットプレーン方式は画面スクロールが得意だ、と言う特徴がある(※1)。
スーパーマリオブラザーズのような「背景画面が自然と左に、高速でスクロールしていく」と言うようなゲームは当時のビットマップ採用の、特にパソコンでは再現が難しかった。
逆にビットマップ採用のPC生まれのアクションゲームだと、スクロール無しで、面から面へと切り替わるようなデザインになっていて、画面を跨ぐと一回止まり、改めて次の面を「一気に読み込む」ようなデザインが主流だったのもこれが理由。「流れるように面が移動」出来なかったので、当時のビットマップ系PC生まれのゲームではある種、苦肉の策でこういうゲームデザインになっていた。
この「全くバラバラの表示用ハードウェア」を統一的に扱うのは困難だった。
要するに、コンピュータの歴史の中で「画像表示」と言うのは新しい分野で、「文字だらけ」の環境よりスタートがそもそも遅かったわけだよな。
この状況は、色んな独自ハードウェアを作ってた会社が潰れたり、あるいはコンピュータを作るのを止めたり、とか色々な要因が重なって、ある程度デファクトスタンダード的に収束するのは21世紀に入る前後、と言う事になる。大体どのマシンも例えばNVIDIAとかATI(現在はAMDに買収されてから長い)のGPUを積むようになるまで戦国時代だった、って言って良いだろう。
マシンによってCPUが違うのは大変だったわけだけど、マシンによって画像出力回路が違う、ってのはもっと大変だったわけだ。
ある程度デファクトスタンダードが決まってからまだ20年ちょっとくらいしか経ってないんだよな。
もう一つ問題がある。ソフトウェア側の問題だ。
そもそも、民生機初のGUIを用いたPCはApple Macintoshだったんだけど(※2)、これの元ネタとなったAltoと言うマシンに積んでいたプログラミング環境、Smalltalkは、「ソフトウェアを環境から切り離して単独で使う」のが難しかったんだ。
Smalltalk実装Squeak。故・スティーブ・ジョブズがパロアルト研究所を訪ねてAltoを見かけた時、これを見て「OS」だと勘違いしたのが、その後のGUIパソコン開発のキッカケになった、と言う話が有名だが、実はこれはOSではなく、ホントに全部「プログラミング言語」なんだ。つまり、ウィンドウもメニューも「プログラミング言語の機能だった」と言うのがSmalltalkの恐ろしいトコで、と同時に、これを実現する機能の「オブジェクト指向」と言う呼び方もこのSmalltalkに端を発する。
Smalltalkで作られたプログラムはSmalltalkに内包され「その外に出ることは出来ない」。
Lispで書かれたソフトがLispから切り離せず(※3)、Emacs Lispで書かれたアプリケーションはEmacsから切り離せない、と言うのは有名だが、ある意味その形式の「トドメ」がSmalltalkだ。
Smalltalkで書かれたソフトはSmalltalkの外には出られないんだ(※4)。
このように、元々GUIと言うのは「中にあるあらゆるものを縛り付ける」システムとして登場してる。
大まかに言うと、民生機レベルで「ソフトウェアとGUI環境を切り離して」性交成功したのはWindowsが初めて、って言っていいだろう。
と言うのもDOS資産を重要視したから、で、最初のWindowsはあくまで「DOSにGUIと言うガワ」を被せたシステムだったから、だ。基本はCLIのDOS。GUIはあくまでガワ。
だから恐らくここで初めて、GUIをシステムから引っ剥がしたって言って良いと思う・・・最初のMacはそもそもCLIもなかったし、そんなカンジだったんじゃねぇかなぁ(※5)。
そして90年代半ばを過ぎると、色んな「独自PC」を作ってたメーカーは淘汰されてWindows、Mac、UNIXの三強時代となる。
CLIレベルではまぁまぁ「標準化」にそこそこ乗っ取ってればお互い互換なソフトウェアは作れるし使える。
問題は、だ。今まで見てきた通り、画像出力回路が同じとは限らない(※6)。そしてGUIの「実現方法」も違う(※7)。
プラットフォームAでGUIのソフトを作って、それを別のプラットフォームBに移植するのが厄介なわけだ。今度はソフトウェアレベルで。
こういう移植のやりやすさを「クロスプラットフォーム」と呼んだりするんだけど、CLIならいざ知らず、GUIは色んな意味でまだメンド臭く、そして「標準化」と言うのがまだ成されてない分野なわけ。
とは言っても、GUIを構成するツールをGUIツールキット、って言うんだけど、いくつかクロスプラットフォームを実現する為のライブラリがチラホラあるわけ。
現時点だとWindowsだとWindows API/Direct X、LinuxだとX Window/GNOME/KDE(※8)、MacだとObjective Cを基盤としてCocoa、と全くGUIを構成するツールが違うわけなんだけども、これらの差異を吸収して統一インターフェースを提供してる試み、なわけだな。
有名所が3つくらいあって、
ってのは今後良く聞く事になると思う。
1. のTcl/tkってのはPython組み込みのtkinterの元になってるGUIツールセットだ。ある意味これが一番簡単で、正直GUIとしてはダサいんだけど使いやすいと言われている。PythonのIDLEなんかはこれで作られてます。
3. のQtはGoogleが作って提供してるGUIアプリで使われてる。この3つの中では最後発でいっちゃん高機能だと思う。原則C/C++用なんだけど、Pythonなんかでも使える。
2. は中間くらいかね。きれいだし、比較的扱いやすい。RacketのGUIのベースになってるのがこれ。そして例えば音声編集ソフト、AudacityなんかのGUIもこれで作られている。Linux生まれなんだけどWindowsでも大活躍してて愛用してる人が多いんじゃない?
Audacity。音声編集ソフトとしてはあまりにも有名。Linux生まれだけど、Windows上での人気の方がスゴイ?
数式処理ソフトwxMaxima。MaximaはCommon Lispで書かれたCLIの数式処理ソフトウェアだが、それのGUI版がwxMaximaで、名前が指し示す通り、GUI部分はwxWidgetsで作られている。
それを実現してるのはGUIがクロスプラットフォームなツールキット、wxWidgetsで作られてるから、って言っていいと思う。
RacketでGUIを覚えるなら、mrEd Designerを使いながらやってけばいいと思うんだけど、後にPythonに移行する事を考えてもwxWidgetsを学ぶのは良い選択だと思う。Pythonでも使えるし、少なくともtkinterよかキレイだ。
Pythonの場合、wxGladeってツールを使うんだけど、いずれにせよ、mrEd Designerと構成は同じだし(同じGUIツールキットだから・笑)片方から片方に移るのもそんなに難しくないでしょう。
wxGlade。C/C++、Python用のGUIコードを吐き出すGUIビルダー。残念ながらRacketには対応してないが、この代わりにRacketで使えるのがmrEd Designerと言う事だ。
Racket GUIを通じてwxWidgetsを覚えておいたら、Pythonは元より、Rubyなんかに移動しても使える。提供されてるバインディング(GUIツールキットを使う為のライブラリ)が結構広範囲の言語に渡ってる為、後々にも応用は効きやすい。
ここで高林哲氏がwxGladeを使ってGUI部品を作る例を挙げている。これはwxGladeなんだけど、mrEdDesignerを使う際の参考にもなると思う。
※1: 家庭用コンソール市場で恐らく初めてビットマップ方式が採用されたのが、SONYのプレイステーションで、ビットプレーン方式にこだわって作られたのがセガサターンだったと思う。
プレステはスクロールが苦手で3Dが得意、サターンは2Dが得意だけど3Dが苦手、と言うのは、そもそもこの2機種の画像出力の方式が違う、事に由来してると思う。
プレステが出るまで、つまり「ゲームの画像の基本が3D」となるまで、ビットマップ方式は「スクロールが苦手」、つまり、全面的な一気の画像書き換えがビットプレーンに比べると遅い事が往年のゲーマーにはウケが悪かったから、なんだ。
一方、3Dだと、プレイヤー視点から観て画像が大規模に書き換わる事がなく、奥行きを基準として「徐々に」書き換えていけばいいので、演出上問題がなくなる(代わりに座標計算が厄介な事になるが、プレステは行列演算用の特殊な計算用チップを積んでいた)。
※2: と言うのは実は嘘で、その登場の前年(1983年)、Apple Lisaと言うパソコンが最初のGUI搭載の民生機。しかし高額で商業的には失敗した。
同年、実は日本でもNEC PC-100と言うGUIマシンが登場してる。しかしこれも、基本的には高額で失敗した商品となる。
ちなみに、1983年〜1984年はある意味分水嶺で、Apple Macintoshが登場した1984年に、後にUNIX系OSで広く使われるGUIの基本ソフト、X Window SystemがMITで産声を上げ、今現在でもLinux等のフリーOSのGUIの基礎基盤を提供している。
※3: もっともその特徴はLispならでは、ではなく、いわゆるインタプリタ系言語(例えばPython)だとそうならざるを得ない。つまりスタンドアロンのソフトウェアを作るのは難しい。
Javaなんかも結果そうで、Javaで書かれたソフトウェアには実行環境としてJava仮想マシン(JVM)が必要、ってのもJVMは基本的にはインタプリタだから、だ。
インタプリタを基本とする言語だと、スタンドアロンを作ろうとすれば、結局インタプリタのコア部分を切り離して、「実行環境」として同梱して提供する以外の方法はない。
※4: GUIとプログラミング言語部分を切り離したSmalltalk実装にGNU Smalltalkがある。
ただし、熱烈なSmalltalkファンはGNU Smalltalkをあまり評価してない模様だ。
※5: Commodore Amiga(1985年登場)はCLIも持ってたし、そういう意味だとGUIとCLIは分離はしていた。
ただし、この時期、Macもそうだけど、基盤のOSは実はROMに積まれていて、「交換不可な」、今で言うとBIOSと兼任、と言うようなカンジだった。
じゃあ、OSのアップグレードはどうしてたんだ、と言うと、AmigaはそのままマジでROMを交換する、と言う力技(笑)。また、Macの場合は、ディスク上にもOSが積めて、ROMとディスク上のOSのヴァージョン番号を比較し、新しい方を優先する、と言うようなシステムになっていた。
いずれにせよ、当時のレベルだとGUIのメモリ占有率が高く、結果CLIベースのPCと違って、OS部分は単価が安いROMに載っけるしかなかったんだ。
※6: Appleがモトローラ製品を中心とした製造を止め、インテルに鞍替えし、実質中身が「高級Windows機」になったのが2005年だ。その後、貪欲にWindows用資産を活用し、いや、むしろWindows専売機よかチップメーカーに性能を求めるようになったのもこの時から、だ。
※7: Windowsの主力言語はC++で、これは(必ずしもそうではないが)「オブジェクト指向をくっつけた」C言語、と言う捉え方をされている。
しかし、「オブジェクト指向をくっつけた」C言語はC++だけ、ではなく、Appleが採用したブツをObjective Cと言う。
C++はCの他にSimulaと言う言語の影響が強いが、一方、Objective Cはド直球にSmalltalkの影響が強く、またApple(と言うかスティーブ・ジョブズが過去興した会社であるNeXT社)のGUI環境基盤、NeXT Stepとのひっつき具合が凄い。単独の言語の筈なのにGUIに何故か張り付いていて面食らった事がある。
これが、OS Xの中身はUNIXで、むしろLinuxに近い筈なのに、GUIソフトのLinuxからの移植や、逆にMacからの移植が難しい遠因なんじゃないか、と思う。
結果、Windows <-> Linuxのソフトウェアの行き来はそこそこあるのに、Macがまたしてもハブられてる原因じゃなかろうか。
※8: 正確に言うと、Linux等のUNIX系フリーOSの場合、X Window Systemがほぼ基盤として採用されているが、「その上」にウィンドウマネージャやらデスクトップ環境(GNOMEとかKDEとか)やらガンガンレイヤーが重ねられてて、ワケが分からん事になっている。
UNIX系フリーOSの場合、プログラムする側が関わるのは、よっぽどのハッカーじゃない限り、表層も表層部分であって、ある意味GUIの「構成」で考えるとむしろWindowsの方がスッキリしてるんじゃなかろうか・・・・・・APIの引数のクソ多さはさておき、として。
