背景

以下の情報は古くなっており、参考の目的のみで残してあるものです。 GrWin の最新版はこちらから利用できます。

コンピュータ・ハードウェアの飛躍的な発展に伴い，少し前までは考えられもしなかった高速な計算環境を個人で所有できる状況が実現し，一つのパラダイムを形成している。 ソフトウェア的にも，ユーザーはハードウェアの相違を意識することなく豊富なコンピュータ資源を活用できるようになった。 コンピュータの利便性はその高速処理能力だけでなく，プログラムにより，ハードウェアが許すどのような機能も実現できるそのフレキシビリティーにあるが，高度に発展したハードウェアを活かすためのソフトウェア技術が高度化したためにそのプログラミングも高度なものになってしまい，多くのユーザーはインターネットのブラウザや，ワープロや表計算などのアプリケーションを動かすだけの場合が多く，ほとんどゲームにしか使わないという人も少なくない。 勉学や研究のためにパーソナルコンピュータを所有している理工系の学生や研究者であっても，数値計算を除くと市販あるいはフリーソフトとして流通しているアプリケーション・プログラムを利用するのみといった状況になりつつある。 例えば，数値計算結果（あるいは測定データ）をプロットするための非常に優れたフリーなアプリケーションがいくつか存在し，非常に広く使われているものの，最も単純な統計処理であるエラーバー一つをとっても，使用しているアプリケーションがどのような処理をしているかを熟知（あるいは意識）しているユーザーがどの程度いるか疑問である。 もちろん，そのようなソフトウェアの能力や機能が自分の要求水準を満たすものであれば，時間を節約するためにも，機能をよく理解した上でそれらは大いに活用すべきであるが，内容をよく理解せずにきれいな結果がすぐに得られるという理由だけで使ってしまったり，要求を満たす既存のアプリケーションそのものが存在しない場合は問題である。

現在のところ，プログラミングを専門としない多くの`素人'（他分野の学生や研究者を含む）にとっては，極論すると，プログラミングが可能なのは数値計算の部分だけであり，高速な計算環境から得られた膨大な量のデータを解析する場合や，データの視覚化そのものが本質的に重要である場合などに必要になるグラフィクス処理は容易でなく，このパラダイムを有効利用するプログラミング手段が（とくに Windows 上で）ほとんどないのが現状である。 つまり，多くの（`素人'）ユーザーたちは，たとえすばらしいアイディアをもっていてもそれを実現するためのスキルが追いつかないために，「プログラム可能」というコンピュータの最大の特徴を数値計算部分にしか活かしきれず， 既存のアプリケーションで「できることだけをやる」か， 数値計算だけが主要な用途である場合を除いて， `素人'が最近のパソコンのハードウェア性能を使い切ることができるのはほとんどゲームだけという歪んだ（もったいない？）状況が生まれている。 とくに，教育現場では視覚的な教材が求められている中，最近のパソコンが10数年程前のスーパーコンピュータにも匹敵する演算性能やメモリ容量，それに，ほんの少し前のスーパー・ワークステーション並の画像処理能力を有しているという事実を見逃す手はないといえよう。

ハードウェアの高度化に伴ってグラフィクス処理を含むソフトウェア開発がソフトウェアの専門家のみによってなされるようになってきた状況は， かつて科学者たちが自らの研究目的を遂行するために実験装置を自作していたのが，最近では，やはり，実験装置が高度に発達したために自作がなかなか困難になってきている事実と類似している。 しかし，ソフトウェアの自作と実験装置の自作とが本質的に異なる点は，利用可能なコンピュータさえあれば，ソフトウェア開発に必要なものはアイデアと時間（と，若干の電気代）だけという点である。 時間とハードウェアが許す限り，自分のアイディアや目的に合致したソフトウェアを自作することは原理的に可能なはずであるし， 研究内容の方を，既存のソフトウェアに合わせて制限してしまうのでは本末転倒であるといわざるを得ないだろう。

高度化したハードウェアを有効に，しかも，ソフトウェア上でハードウェア依存性をほとんど意識する必要のないグラフィクスを基礎としたユーザー・インターフェース(GUI: Graphical User Interface) としては，現在，Windows（Xp/2000/NT/Me/9x）と Mac　OS，それに UNIX 上の X Window システムが主流であり，それらのどれについても市販，あるいはフリーの優れたグラフィクス・ライブラリが多数存在していて，原理的にはどのようなものでもプログラミングが可能である。 しかしそれらのほとんどは，個人で購入するには高価すぎるものであったり，フリーソフトであっても，マルチプラットフォーム化にも重点をおいた C＋＋ によるオブジェクト指向のクラス・ライブラリという形態をとっているために， `素人'がそれらのライブラリを利用するには，ライブラリそのものの使い方に習熟する前に，まず，難解なC++の習得から始めなければならない。 コンピュータを道具として使う，計算機科学を専門としない多くの`素人'ユーザーにとって，C＋＋ 言語やそれを用いた GUI のためのプログラミング技法の習得は本来の目的ではなく，時間をそれらに割くことが現実的な選択とならずに，結果として既存のソフトウェアで間に合わす場合が多いものと思われる。 そのような背景で，教育や研究の多くの現場では，大きな欠点が指摘されているにもかかわらず，未だに局所変数が使えない古いタイプのBASIC言語が，文法が単純で習得しやすいことに加えて，グラフィクス表示が容易に行えるという理由で，場合によってはやむなく古い DOS 上で，使われ続けている。

あえて大胆な言い方をすれば，最近のライブラリの傾向の一つである C++ のオブジェクト指向によるクラスライブラリを用いたマルチプラットフォーム化の流れはソフトウェアの供給者側の立場であって，利用者はそのアプリケーションがどのようなプログラミングスタイルで開発されたかには興味がない。 また，教育や研究の目的などで自分のために必要なプログラミングを行う人や， 単一のプラットフォームしか使わないユーザーは自分の目的を達するために自分の好きなプログラミングスタイルを選択できることが望ましいし， シミュレーション等では主要部のプログラミングにオブジェクト指向を必要としないものも多い。 しかし，簡単なグラフィクス表示であっても，少しでも GUI を含むアプリケーションを開発する場合には，C++ や java によるオブジェクト指向によるプログラミングスタイルがほとんど主流であり，Windows ではそれらがほとんど唯一の現実的な選択肢であったといわざるを得ない。 筆者自身オブジェクト指向プログラミングの有用性はよく理解しているつもりであり，これからプログラム開発に本格的に取り組もうとしている人や，複雑なデータ構造を扱わなくてはならない人たちがオブジェクト指向プログラミングを修得することは，もちろん，大いに推奨されることである。 しかし，オブジェクト指向プログラミングにおける概念的な修得の難しさは否定できず，グラフィクス表示を行うためだけの場合でさえ，それ以外の選択肢（逃げ道）がないことは問題であろう。

従来，プログラミングにより計算結果の可視化を行うには，グラフィクス命令を標準で含んでいる BASIC 言語を利用するか，あるいは何らかの unix 環境上で X-Window プログラミングを行うといった選択肢しか存在しなかったといえる。 局所変数が使えない古いタイプの BASIC 言語ではプログラムの規模においてすぐに限界がきてしまうし，改良版 BASIC 言語はあまり普及しておらず，また，広く利用されているフリーなものも存在しない。したがって，ある程度の将来を見据えた実用性を考慮すれば，これまでは，unix 環境上で X-Window プログラミングを行うことがほとんど唯一の選択肢であったといえる。 開発環境という面で考えると，LINUX や FreeBSD，NetBSD を始めとする近年のフリーな unix 系 OS の充実度はすばらしく，世界中のボランティアが現在も活発に活動して非常に使いやすいものになっているし， 上に述べたように X-Window 上では多くのフリーなグラフィクス・ライブラリが利用できる。 しかし，X-Windowプログラミングによってシミュレーション結果の可視化を行うことが可能になるまでには相当の学習時間を要するので，その結果を直接活かすことのできない，計算機科学を専門としない`素人'（学生）にとってはあまり適切とはいえない。 専門知識をあまり必要としない X-Window 用のグラフィクス・ライブラリも複数存在するが，unix 環境を個人で保守するためにはまたそれなりの彼らの本業とは無関係な知識やスキルを相当程度必要とするので，計算機自体に興味のある人たちを除くと，やはり，unix 環境を個人で利用するのは`素人'にとって荷が重い。

「開発環境としてみると，Windows は API の体系化が進んでいなくて汚い」とか「Windows なんて...」という発言を計算機のプロたちの発言としてネットワーク上などでよく目にする。 また，Windows は一企業の製品であり，その企業の経営方針を嫌う声もよく聞く。 それらの多くには筆者自身も共感するものの，現実社会を見てみると，最近 LINUX のシェアが伸びているとはいえ，それらのかなりな部分はプロたちが使う「企業向け」のものであろうし，一般ユーザ（つまり，`素人'）が使っているパソコンの OS に限定すると，やはり Windows（と，若干の MacOS ）が圧倒的なシェアを占めているのではないかと想像する。 つまり，開発者側の「好き嫌い」とは別に，多くの`素人'利用者の目の前のパソコンでは Windows が動いていて，そこではかつてのような安直なグラフィクス・プログラミングができない現状がある。

シミュレーションや計算物理学の授業においては実習が不可欠であることは言うまでもないが，授業時間内だけの実習では効果はあまり期待できない。 必然的に授業時間外でも自習を可能とする環境の整備が必要となる。 授業で利用する設備を授業時間外にも利用可能とすることで，自習環境を整えている例は多いが，学生が自宅にパソコンを所有している場合にはそれも活用できることが望ましい。 その場合，授業で使うものとほぼ同じ環境を自宅パソコン上に「追加経費なし」に構築できることが理想である。 Linux や FreeBSD，NetBSD といったフリーな unix 系の OS でもそのような授業環境と自習環境を構築することは可能と思われるが，上に述べた理由から，計算機科学を専門としない学習者にとって最も敷居が低いのは，好き嫌いは別として，Windows を使用することではないだろうか。 学習を離れて（ 専門家の仲間入りをして ），研究や業務でシミュレーション等を行う場合には圧倒的に unix 環境が多く使われているという現実もある。 しかし，Windows 環境であっても，一旦一つのシステム上である程度の習熟をつめば他の環境へ移ることはそれほど困難なものではないはずである。

以上のような背景から，`素人'にとって「原理的にプログラム可能」であることと「実際にプログラムを組むことができる」ことのギャップを少しでも埋めるために，現在最もユーザー数が多いと思われるWindows（Xp/2000/NT/Me/9x）に対応プラットフォームを限定しても，C++ の知識を必要とせず，また，C++ でも利用でき，BASIC程度の容易さで使用可能なフリーなグラフィクス・ライブラリを開発し，普及を計ることには大きな意義があるだろう。 このことの実現を`プロ'に期待しても上に述べたように「百年河清を俟つ」の感があり，これが，'非オブジェクト指向'の「GrWin グラフィクスライブラリ」の開発を推進している動機である。

Last modified:  Mon Sep 08 18:30:00 JST 2003