tracを使うことで、情報の整理がかなりしやすくなった。情報を参照しやすいことが、情報を入力することの動機付けになり、全体の情報量が増えることで、参照できる情報も増えて、必要な情報にすぐ当たれるようになってきている。その結果、コーディングの際に必要な情報を参照するのも容易になり、コーディングの効率が上がっている気がする。

また、リンクだけで済ませれば情報の重複を避けやすく、少ない手間で充実したドキュメントが作れる。1つのファイルで完結するドキュメントにするには一手間かける必要があるけど、今のところ、その段階には達していないし、達したとしても、ほとんどコピペだけで1つのファイルにまとめられるだろうから、大した作業にはならないだろう。

現在の自分が必要とし、将来の自分も必要とするであろうドキュメントを維持していく可能性が見えたことで、ドキュメントの作成が楽しくなってきた。

いい感じ。何がいいって、説明が面倒臭いところは、リンクを張って「ソースを見ろ」で済むところ。更新の必要すらない。

プログラミンには、変数や引数と言う概念がなく、四則演算すら用意されていない。そういう制約のあるプログラミング環境ではあるが、プログラミンで電卓を作ろうとする猛者はいるようだ。自分もまだ、触った程度ではあるが、簡単な足し算の方法は見つけた。まずは値をどう表現するかだが、それには画像を使う。画像は何でも良いのだが、とりあえず数字があるのでそれを利用する。

次に演算だが、それには「ブツカッタン」と「キガエルン」を利用する。ブツカッタンは特定のオブジェクトが衝突したときにのみ処理を行い、キガエルンは画像の切り替えを行う。その2つを利用すると、例えば「5」と言うオブジェクトに対し、「3」と言うオブジェクトがぶつかった時、画像を「5」から「8」に変えるような処理を書くことができる。一桁であれば10通りの処理を用意しておけばよい。そのようなオブジェクト「5」を作っておき、それに「3」をぶつけると「8」に変化する。

電卓を作るような猛者はもっとエレガントな方法を使っているのだろうが、基本的なところは同じだろう。オブジェクト同士の衝突により一方の状態を他方に伝え、それを利用して処理を行わせることから、一部では、このようなプログラミングを「衝突指向プログラミング」と呼んでいるようだ。

詳細に比較してみたわけではなく、第一印象。対象は幼稚園児を想定。まず、起動する動作について、Scratchは普通にアプリケーションを起動する操作で、プログラミンは、Webブラウザを起動してからブックマークをクリック、もしくは、リンクのアイコンからの起動。プログラミンの起動は遅いが、Webアプリでは一般的な遅さなので問題にはならない。

次に作成画面だが、Scratchの方が複雑。緑の旗が開始ボタンのようになっているようだが分かりにくいし、タグやアイコン選択での切り替えが多く、探すのが面倒臭い。慣れてしまえば良いのだろうが、文字の読めない幼稚園児にはちょっと厳しそうだ。プログラミンの方が、それとは違って、単純なことしかできない代わりに、分かりやすい。アイコンに名前が付いているが、読むよりもアイコンの形を見た方が良い。このあたりは幼稚園児にはフレンドリーだ。

スクリプトを組む際は、Scratchはスプライトを選択することで、編集したいスプライトに対するスクリプトのフレームを表示させないといけないので、直感的ではない。プログラミンの方は、画像に直接貼り付けていく感じなので、直感的。その代わり、独立したフレームがない分、オブジェクトが多くなると辛そう。

そして、第一印象で最も強く違いを感じた点が保存に関する部分。Scratchはローカルデバイスに保存される形式でファイル名が必要、プログラミンは詳細を調べていないが、ファイル名を必要としない。開くときは一覧表示されるサムネールから選択すれば良いだけ。このあたりの使い勝手はTuxPaintに近い。やはり、幼稚園児向きだ。

と言うことで、幼稚園児を対象とするなら、プログラミンだろう。この手のソフトで必要なことは、自分でもできるというふうに思わせること。出来合いのゲームを動かすこともできるのだが、低年齢では、そちらに走ってしまいがちで、作るということが学びにくいと言う話もある。幼稚園児なら、自分で書いた絵が動かす、親に手伝ってもらいながら高度なものに挑戦するということになるから、Scratchだと機能の豊富さが災いするように感じられた。

PLT Schemeって2年近く前に改名していたのか。

おもしろいものも出てくるようになったけど、邪魔な事には変わりない。AKBだから邪魔というわけではなかったようだ。

この冬に感じることは新しい車が速い。こちらのタイヤが寿命というのもあるが、タイヤの差にしては大きすぎる気がする。それで不思議に思っていたのだが、ESCを搭載しているんだな。

末尾呼び出しと言ってもSchemeの話ではなくて、C/C++の話。特にgccの話なので、sibling callといった方が正確か。

return funcA(a, b);

となっていたとき、この文のある関数とfuncAの型が一致していれば、関数呼び出しを行わず、引数を書き換えて、ジャンプ命令でfuncAの処理が実行されるような最適化。

再帰になっていれば、関数呼び出しがループのように展開されるけど、Schemeじゃないんだから、そういうものは最初からループで書いておけば良い。おいしいのは、より一般的な末尾呼び出しの方。関数呼び出しがジャンプに置き換えられるので、インライン化できないものもインライン化に近いパフォーマンスが期待できる。

コンパイル時には処理を決定できない関数ポインタを介した関数呼び出しについても、最適化されているっぽいけど、コンパイル後のコードで確認していない。

void func(Base* obj) {
  struct {
    static void deriv1(Parent* p, Deriv1* d1) {
      // 本来の型がDeriv1*のときの処理
      ...
    }
 
    static void deriv2(Parent* p, Deriv2* d2) {
      // 本来の型がDeriv2*のときの処理
      ...
    }
 
    static void deriv3(Parent* p, Deriv3* d3) {
      // 本来の型がDeriv3*のときの処理
      ...
    }
 
    ...
 
  } f;
 
  this->dispatch(obj, f.deriv1, f.deriv2, f.deriv3, ...);
}

Deriv1、Deriv2、Deriv3はBaseの派生クラス、func()は引数の型に応じた処理をする関数でParentのメンバ。そして、dispatchはtemplate関数で、第一引数以外は順不同。

型の間違いは防げるし、それぞれの型にあった処理を書くことに集中できるけど、dispatch()に渡し忘れたり、引数の型が同じものを作ったりするミスが起こりうる。

何かうまい手はないかな。

交友関係を広めようという意図が無く、既存の交友関係の中だけでコミュニケーションしたい場合、プライバシに対する仕様と使い勝手という点では、Google+の方が上のような気がする。