話がどんどん哲学的になっていくわけであるが(汗）、結局のところ「思考は記号の処理か？」っていうあたりの問いが気になっているのである。
例えば、「耐震強度」という概念をコンピュータが理解して・・ということは、パラメータを与えれば自動的に設計をしてくれれば良いのか、耐震強度と人間が勝手に言っている事柄を、単なる数値としてメモリに載せて、決められた手順に従って加工するだけで良いのか・・・ということだ。
ルールを決めるのが（ユーザではなくプログラマであるが）人間でしかありえない以上、コンピュータは人間が分かる（・・ということは、人間が別の人間に伝えるために文字を残す）形で表示が出来れば良い・・ということではなかろうか。AIの世界でも、人間のように振舞う（出力できる）コンピュータプログラムは知性と呼べるか？という問題があるようだが、「人間のように思わせることに時間を使うくらいならば、人間の機械として役に立つ計算機をとことん使おう」よ・・と思わないでもない。
具体的な話として、とあるプログラム（設計）の本に「変数名には意味が分かるような記号を付けろ」とか「意味が分からない変数名を付けるな」だの、さも、プログラマが意味を理解した上でプログラミングをするべき・・みたいなことが書かれていたりする。
いやいや、ある計算上の”型”に対して、人間が勝手にラベルを付けているだけであって、その変数名ですら「ある人にはわかるが、ある人には別の概念が入り込んでいる」となって、意味がぶれていたりするのではないかな？
・・で挙句の果てには、各人の意味の取り違いが元で、「いや、これはそういう意味じゃないんだよ」「こういう風に変えてくれない？」なんていうことが生じて、結局意味の差異を正す作業が「えぇ、あそこもここも直して、ドキュメントも直して、フロー自体が変わっちゃうんですよー」って泣くハメになる。
はじめから型と連番程度の意味の無い変数名にして、その変数にどんなラベルを付けるかだけをDBで管理していれば、プログラムは数値、日付、文字、オブジェクトなんていうシンプルな処理方法だけでよいし、人間がどんな風に捕らえようが、プログラム本体の動きには関係ないのである。概念を表現（加工）できる処理方法をプログラムとして書くことが出来れば、プログラマは意味など関係ないし、顧客は自分達の概念体系でそのプログラムを活用するんじゃないか？・・・・・・
実際に、今回作ったのもそんな感じ。DBに集約したスキーマ情報（ルール）にしたがって、ひとつの登録画面、検索画面、一覧表示画面、一括登録、一括出力から何十種類もの異なる画面を作り出すプログラム。
入力エラーチェック、ドロップダウン、日本語入力モード切替、並び順、一覧表示方法、ソート方法・・・すべてDBのスキーマ情報を参照して、必要な機能（Javascriptであったり、サーバサイドのプログラムであったり、HTMLであったり）ものを作り出す。
プログラムの内部では、項目がどんな意味を持って、何と関連していて、どうあるべきか・・なんて知らない。
（プログラマ自身もそんなことは知らなくても良い）
ユーザがある思いを持って何かを書き込み、プログラムは何か知らないが正確に保存して、必要情報をキーに保存した意味を取り出せれば良い・・・・そんな仕組みだ。
顧客が「この並びにしたい」とか「こんな項目を追加したい」とか「この表記を変えたい」って言ったら
「ここの情報を書き換えれば、プログラムの書き換えは不要ですよ」と応えることにした。
そう、テキストで記述したデータ構造と、マスタデータがあればプログラムの動作を変えられるようにしてあるのだ。
素晴らしい！。この方法を思いついて、そして実際にプロトタイプが動いた時には、かなり興奮した。
はじめに書いた2000フィールド、50種類のドキュメント（スキーマ群）を管理する、小さくはないデータベースシステムが、ほんの50本程度の比較的簡単なスクリプトで動いている。
この仕組み「データベースをもっとアクティブに活用しよう」という意味を込めて、db.Active!と名づけた。
こじんまりと商品化してみたい。
