http://return0.dyndns.org/log/2009/08/08#s_1 :
ところで既に何度か書いている通り、今の俺の仕事は檜山さんの配下で世界を転覆させるソフトウェアを開発することなのだが、ここ数日はそこで使うための対話シェルとスクリプト言語の開発をやっていた。
“世界を転覆させる”ことができるかどうか、あんまり自信がないのだけど、Kuwataさんの実装力のおかげで、当初の目論見通りに進捗はしてます。
それらの詳細はまあここではどうでもいい。
と、Kuwataさんは具体的な内容を書かないので、僕が書きます。まー、僕のほうが広報担当だから ^^;
「新ユニット結成のお知らせ + GAE上でファイルシステムの模倣」で次のように述べました。
僕もKuwataさんも「おぼしき事言わぬは腹ふくるるわざ」な人なので、やろうとしていること／やっていることを特に機密扱いしたりはしません。口頭で NNDA [Non-(Non-Disclosure) Agreement] を結んでいます :-)
設計方針や仕様に関しては、できるだけ公開しようと思っているのですが、逐次にレポーティングするのはえらい大変。レポートは断片的にならざるを得ませんね。ソフトウェア自体は、一段落したところでソースも含めて公開します。しかし、それで「何を目指しているのか」「何に使えるのか」「他と何が違うのか」などが分かるとも思えないので、説明の労力を省くことはできないでしょう。
後でまとめて文書を作るなんてことは出来そうにないので、折に触れて「何を目指しているのか」「何に使えるのか」「他と何が違うのか」を書いていこうと思います、断片的にでも。
名前
プロジェクトとソフトウェアの名前はCaty（キャティ）です。何かのアクロニム（略号）でもなく、面白い由来もありません。前身のプロジェクトが猫に由来する名前だったので、それから猫（cat）を取って、なんとなくyを付けただけです。
「キティ」と発音が似ているので、「キティちゃんをロゴに採用しよう」と提案したら、Kuwataさんに「サンリオに怒られるからやめたほうがいい」と反対されました。「キティちゃんにインスパイアされたキャティちゃんロゴを作る」案も「サンリオによけい怒られる」と却下、でした。ちなみに、キャティちゃんは女の子で、たぶん猫です*1。
後から思い起こしたのですが、だいぶ以前に小さな実験的なプロジェクト／ソフトウェアにKatyという名前（これもアクロニムじゃない）を付けたことがあるので、僕はこのての名前が好きみたいです。
さらに事後的なコジツケをすると、僕が設計すると、カテゴリカルになるだろうから、catはcategoricalのcatだと言ってもいいでしょう。実際、コマンド（と呼ぶプログラム実行単位）は、半環圏*2の上のスタンピング・モナドのクライスリ射でモデル化できるようになっています。
ジャンルと特徴
ソフトウェアのジャンル（種類）は極めて平凡なもので、Webフレームワークです。世に五万とあるWebフレームワークに対して、(五万＋一)番目を付け足すのかというと、そんなつもりはないし、たぶんそうはならないでしょう。
プログラミング言語にもプラットフォーム（OS、Webサーバー、Webサーバーとのインターフェースなど）にも依存しないように注意を払っています。でも、この点は利用者（Web制作者）からは見えないし、まだポーティング例がないので、現状あんまり大声では言えません。
利用者から見てのメリットは「簡単」なことです。この特徴も、ありきたりな表現しかできないのですが、「世界一簡単」が目標です、マジで。
開発用のシェルがあり、プロンプトに対してコマンドラインを入力できます。コマンドラインはキーボードから手で入力するので、通常数十文字、長くとも200文字程度だと思います。このコマンドラインがうまく動くのを目視で確認したら、コマンドラインをそのまま（加工や編集は不要）ファイルに収めます。
こうして出来たスクリプトファイルがWebアプリケーションの実体になります。「数十文字のスクリプトファイルが数個」で実現できる動的Webサイトでも、相当に広範囲の要求に応えられるだろうと踏んでいます。
魔法が使えるわけではないので、裏の仕掛けや制約は当然に存在します。複雑で高度な機能を必要とするWebサイトは最初から守備範囲外です。「簡単なモノなら簡単に作れる」ってことです。そんなの当たり前だろう、って？ そうです、当たり前です！ しかし僕が見るところ、簡単なモノでさえ簡単に作れない現状があるので、Catyに意義があるだろうと思うのです。
技術と方針
最小抽象ファイルシステム （Minimum Abstract Filesystem; mafs）、厳密分離指向テンプレート言語／エンジンとMVCR方式、JSONとJSONスキーマなどは、Catyの構成要素となる技術です。
「簡単でわかりやすい」が第一の目標なので、複雑さをまねく要因は徹底的に排除します。たいして使いもしない機能や親切心でのカスタマイズ可能性／自由度が累積すると、手が付けられない複雑さとなるので、ミニマリズムを貫く態度が必要です。ある段階で導入した機能でも、後で「要らない」と判断すれば容赦なく切り捨てます。もったいないから残しておくなんて事はしません。
正直言って「いくらなんでも機能不足かな」と感じることはあります。しかし、経験上、「いつか使うかもしれない」「誰かが使うかもしれない」「あれば便利かもしれない」「あっても邪魔じゃない」のような誘惑に屈することは、極めてリスキーなので、禅僧のごとくにストイックな気持ちで仕様を考えているのです。
困っていること
「簡単でわかりやすい」が第一の目標だとするなら、「簡単さ／わかりやすさ」に関する尺度・基準が必要です。その尺度によって計って、より簡単／わかりやすいほうを選択したり、目指したりするわけです。
ところが、この尺度にあんまり自信がない。僕が「簡単でわかりやすい」と思っていることが、ターゲットユーザーである“Web制作をする人々”の「簡単でわかりやすい」感覚と一致してるか不安だということです。
「簡単でわかりやすい」なんて感覚は個人差があるし、平均値とか統計的に有意な情報が取れる見込みはないでしょう。一方、普遍的に共有できる簡単さ／わかかりやすさが存在するような気もするし。原理的に計量・計測困難であります。だからまー、仮説を取っ替え引っ替え進むしかないのだろう、とも思っています。
誤解／勘違いして欲しくないのは、最終的な利用者にとっての「簡単さ／わかりやさ」を実現するための背景理論、設計原理、実装方式が簡単容易であるなんてことはないことです。むしろ、単純さを保ちながらも抜けなく整合的なシステムを構成するには、かなり膨大な量の問題を解かなくちゃなりません。
僕が今後断片的にレポートするであろう内容は、出会った問題と、それを解くための試行錯誤（うまくいけば解決策）ですから、簡単でもなきゃ分かりやすくもないかも知れません。
