[View] [Edit] [Attachments] [History] [Home] [Changes] [Search] [Help]
Testing and debugging framework for learning environment
コードネームを考える
- Bugunter
- Mole
- Musihime
- Insectarium
目標
- テストは楽しくなければならない。プログラムの過程においてテストは目標であり、テストを少しずつ通過する喜びを感じなければならない
- デバッグは楽しくなければならない。コード中だけでなく、デバッグ自体も創造的な過程であり、新たな発見を伴うものである。
- これらの作業を通じ、共同開発者と楽しく知的なコミュニケーションをとる事が出来る。
方向性
- 静的なルール。テスト。制約
- GGame 向け文字ベース
- 制約システムの研究。試作。
- テストフレームワークのインタフェース開発。
- 動的なトレース。ネットワーク。
- コード構造の可視化。コンテキスト情報のインタフェース。
- リモートデバッガ。
- 通信プロトコルの評価、選定。(soap, jabber, netmorph)
開発内訳
- プロジェクト名決定
- 言語ゲーム環境におけるテスト/デバッグツールプロトタイプ(smaCC版)
- 言語ゲーム環境における実装
- SqueakToys環境における拡張
- 運用テストと複数ユーザでの使用実験
関連作業
- プロジェクト置き場に投稿されたプロジェクトをテストしてみる
- squeak のウェブブラウザで見れる?
- E言語、 Mozart-Oz 調査
ついで作業
- comanche の拡張(画像キャッシュダサ過ぎ)
- jabber 日本語化(リモートアクセス)
- Flash 作成ツール
- ruby および perl の GUI フロントエンド
- ruby perl gdb のリモートデバッガ
- ssl の利用
- 日本語版 superswiki / plugin 内部調査
- squeak 内 emacs
応用事例
- 問題/規則を記述する正確な方法
- MU パズルを解く
- スケジュール帖への記入自動化
以下前に考えていたこと。
MetaQuiz の位置付け
MetaQuiz とは「言語ゲーム」の次の目標として位置付けられるプロジェクトです。
2002 年に僕が言語ゲームに関して行った研究は、主にプログラミング言語設計に便利な
ユーザインターフェースに関する物、例えば、解析ツリーのビジュアル表現や、
画像によるリテラル表現。ドラッグアンドドロップの応用といった物でした。
文法自体は伝統的な YACC 風の構文を採用していました。
言語ゲームの今後の課題は、本計画の目的 - エンドユーザによる言語設計 -
のために YACC 風の記述が有効なのかどうかを研究し、必要ならばより適合する
手法を見つけ出す事です。ここでまず、エンドユーザによる言語設計という当初の
目的自体を見直す事も視野に入っている事を挙げておきます。つまり、この目的の
向こう側には、コンピュータを深く利用する為にはどうするべきかと言う問いが
あり、それには、専門家による言語開発 -> 技術者によるアプリケーション開発 ->
ユーザによる利用という流れを見直したいという意図があります。その意図の
為には、必ずしもパーサジェネレータというこの確かに魅力的な概念にとらわれる
必要もまた無いという事です。
パーサジェネレータを開発するに当たり、BFN構文と関数型言語の相似性に
気づいた事が、一つのきっかけになりました。また、知人から prolog はさらに
似ていると教えられ、パーサジェネレータの開発と平行して、プログラム
言語全体を包括的に調査する必要性を感じました。それで去年の末は haskell の
勉強にあけくれて言語ゲームの開発が遅れてしまいましたが、なんとなく
面白くなりそうなネタ元はいくつかありました。それをまとめる前に、MetaQuiz
自体について述べます。
MetaQuiz の目的
結城浩さんの 2003年3月26日付けの日記に、興味深いやりとりが記されています。
http://www.hyuki.com/diary/dia0303.html#i26_22
お風呂の中で数列の次の文字を当てるクイズを子供とされている場面です。
僕は数少ない SE 経験から、人間の思考とコンピュータの思考の関係はこの
クイズのような物だと思うようになりました。
要求仕様: 10, 20, 30 の次の数字は?
分析: 多分これは 10 ずつ数字を増やしてゆきたいに違いない。
ソリューション: 次は 40 です。
人間の思考も顧客の要望も、このような例題として示されます。つまり僕らが
聞くのはああいう場合こうして欲しいとか、この場合はこうだとかの個別の
例だけで、一般化して設計するのはプログラマの仕事です。それでプログラム言語
自体もこのような一般的な法則を記述するのに適したスタイルを持っていますが、
これは人間にとって自然な例を元に考えると言うやり方とは違います。
MetaQuiz の目的は、このような人間の思考 - 一般的/個別的というより例題で考える - を
記述し、プログラム開発に役立てる方法を考えようというものです。この領域の
非常にホットな話題としては、XP プログラミングで一躍メジャーになった
テストファーストの教えです。これは仕様に適合しているかどうかを確認する
ために、小さなテストコードを書いて確認するという方法で、例で考えると言う
人間の習性を開発に生かすための軽量で優秀なアプローチといえます。
テストという考え方に沿って言えば、MetaQuiz の究極の目的は、「テストコードを
書くだけでプログラムが完成する」というものです。僕もこれが可能だと信じて
いるわけではありませんが(証明の仕方はわからないけど原理的に不可能な気がする)、
例えば今でも Huskell のコードなどはテストがそのままプログラムのようです。
-- フィボナッチ数の定義
fib 1 = 1
fib 2 = 1
fib n = fib (n - 2) + fib (n - 1)
ここでは 1 と 2 の場合だけ例を挙げて、後は一般的な法則を書いています。
後は fib 3 = 2; fib 4 = 3; といった記述から3行目をコンピュータに自動生成させる事が
出来れば MateQuiz は完成します。無理だと思うけど。
MetaQuiz の道のり
まずやらなくてはいけない事は、プログラミング言語の周りの文脈の復習です。
プログラミング言語の周りには様々な構造があり、その整理をする事によって
解決への道を探ります。
- 言語自体の汎化構造
- 言語仕様 -> 言語/開発環境 -> アプリケーション
- 実行環境
- クラス/関数(固定的) -> オブジェクト/イベント/IO(流動的)
例による要求(以下クイズと呼びます)は宣言的です。つまり、プログラムの実行によって
クイズ自体は変化せず、その性質から関数型言語と相性が良いことが予想されます。
一方で、クイズの答え自体は流動的です。
Link to this Page
- 言語ゲーム last edited on 19 March 2005 at 2:04:01 pm by 192.168.0.8