さるぅん プロジェクト は、 私が理想とするプログラムの有り様に従って作られた プログラムでこの世界を一杯にしようっ!というプロジェクトです。
私の理想とするプログラムの有り様は、一言で言うと
この3つの条件こそが さるぅん なプログラムの絶対条件である。
プログラムは単機能でなくてはいけない。
unix 出身者である私としては、 プログラムというものは、 1つ1つは単純であり、 ユーザーがそれらを組み合わせて高度な利用ができるように なっている必要がある、 と考える。
従って、無意味に追加的に機能がたくさんついているような システムは さるぅん であるとは言わない。
シンプルさと矛盾するように聞こえるかも知れないが、 プログラムというものは高機能でなくてはならない。
例としてファイルの中から文字列を探すソフトを考えてみよう。
「シンプルさ」とはこのソフトに ファイルの中の文字列を探す以外の機能を持たせてはならない、 ということだ。 シンプルでなくて良ければ、 ファイルビューアーとしての機能も付与し、 条件に一致したところをハイライトして見せる、 などというようなソフトも作れるだろう。 しかし、 さるぅん なプログラムには、 そのような機能はあってはいけない。
が、一方で 文字列を探す という機能で行けば、 単純な文字列一致検索以外に、 正規表現一致検索 という検索法がある。 探したい条件を 正規表現 という表現方法で記述することで、 単純な一致よりも遥かに複雑な条件にも対処できる 方法である。 さるぅん なソフトウェアは、 正規表現をサポートしなくてはいけない。
ここでさらに重要な点だが、
ここに判断の重要なポイントがある。
確かに単純文字列一致と全く同じ記法ではないが、 正規表現は単純文字列一致に極めて近いことを実現する能力がある。 つまり、本来、正規表現がサポートされている検索システムには、 単純文字列一致検索は不要なのだ。 つまり、文字列検索に正規表現システムを採用しても 単純文字列一致では検索でいるのに正規表現では検索できないような条件 は存在しない。 ここが重要なのだ。
つまり、ここで言う高機能とは、
「単機能 A を満たすようなソフトと、
単機能 B を満たすようなソフトと、
その両方の機能を満たし、
かつさらに別のことも全く同じ表現でできるような
単機能 C を満たすソフトがあった場合は、
単機能 C だけが高機能の名にふさわしい」
ということだ。
もちろん、開発の過程で単機能 A しか満たさないソフトや、 単機能 B しか満たさないソフトを作ることもあろう。 しかし、後に単機能 C を満たすソフトを開発したら、 A や B しかできないソフトはきれいさっぱり捨てるべきであるし、 開発においても可能な限り最初から C の機能を探そうと努力すべきである、 というのが さるぅん プロジェクトにおける重要なミッションである。
これは、最終的にユーザーが覚えなくてはいけないことを減らす効果がある。 確かに複雑なことができる機能は複雑であり、 最初に覚えるときに頭をたくさん使わなくてはいけない。 使っているときも頭をたくさん使わなくてはいけない。 しかし、2つも3つも「馬鹿単純」なソフトを覚えるよりも、 1つの応用性の高いソフトの使い方を覚える方が、 より多くの場合に同じソフトを使うことができ、 最終的に必要となる知識を減らしてくれる効果があるのだ。
従って、「初心者の苦情」などは無視し、 シンプルで高機能 なソフトを作ることに心血を注ぐのが、 プログラマーのあるべき道である、とわたしは考える。
基本的に、 シンプルで高機能 なソフトは複雑なアルゴリズムを必要とする。 シンプルで高機能であるという事は、 より高度な数学的バックグラウンドを持った処理を必要とするからだ。
そのようなアルゴリズムは往々にして、 メモリや CPU パワーを大量に消費する傾向がある。
しかし、それによって機能が制限されてはいけない。 最終的に処理できるデータ量に制約が出るようではいけない。 高機能なシステムは、上手に使えば普通なら3度も4度も人手をかけて 処理しなくてはいけないような状態を一度に処理する能力があるものだ。 しかも、その処理の間、人間は別のことができるものだ。 もし、そこで仕事が終わるのをボーッと待っている人間がいたとしたら、 それはそいつの時間の使い方が悪いのだ。 計算機は最適な処理を、 与えられたりソースの中でベストを尽くしてやっているのだから。
どうしてももっと早くしたいのであれば、 計算機リソースに投資するべきである。 ムーアの法則によれば、 18ヶ月(最近はもっと短いという噂もある)で計算機の早さは 2倍になるという。 メモリのコストは半分になるという。 ある時点では不可能な投資も、18ヶ月も待てば簡単にできるようになる。
このようにリソースがどんどん増大する時代にソフトの寿命を考えるならば、 当然ソフトは「将来にわたっても使える」存在でなくてはならない。 重要なのは少しのデータを簡単に処理できることではなく、 大量のデータを与えても処理時間が急速に爆発しないことである。 決して、 Belady の例外 のような、実装上のわなに陥ってはいけない。 この手のわなに陥らないことでソフトが長く使えることの方が、 目先の高速化よりも遥かに重要である。
その猿さ加減が永久に「猿」で終わるか、 優れた先見の明と評されるかは、 貴殿の腕次第である。