#モーションそのものじゃなくて、ジェスチャーなんですよね。MS の Kinect ライブラリはそのへんのノウハウの塊になってそうです。実際に商用のゲームソフトを作ってみないとわからないこともたくさんあったでしょうし。あと iPhone の操作でもそうで、ヒューリスティクスを使って、いかにユーザの意図を汲み取るかにパワーが集中されているような印象を受けました。
#ああそうそう。ジェスチャ認識と言えばモーキャップと区別がつきますね。
#あと、入力遅延も結構あるみたいですね。たぶんぼくが触っても気がつかないレベルだと思いますが。
#異なるというよりレイヤが違うか。ジェスチャ認識のインプットのひとつとしてモーキャップがある。
#そしてアニメーションに使われるモーキャップとジェスチャ認識に使われるモーキャップでは要請が異なる。
#本質的にはゲームパッドのボタンの代わりだから、そんなに自由度いらないんですよね。
#ゲームは入力遅延に結構敏感だと思うけど、ゲームデザインの時からそれを織り込んでるのかな。チョコボのジェスチャ入力をやった時 (もう14年前だ!)、認識部だけで1/20の遅延があったんだけど (それにゲーム自体での遅延が30fpsで1-2フレームあったかな)、デザイナの人はあんまりいい顔してなかったなあ。研究プロジェクトだったから大きな問題にはならなかったけど。
#でもうるさい人に言わせれば Bluetooth のコントローラはそれだけで数フレーム遅れるそうですし、HDMI の入力でも遅れるし、もう入力遅延を考えないゲームデザインというのはないんじゃないでしょうかね。
#そうか、最近は表示部でも遅延ありますしね。ネットにつないだらそこにも遅延だらけだし。今の現場ではそのへんをいかに気持ちよく見せるかってのにそうとうノウハウがありそう。
##ここで紹介されたQuora に登録してみたけど
#Lisp の話題も結構ある。
#Why isn't Racket (DrScheme) more popular? とか。
#ぼくもとうろくしてみました。Stackoverflow 風のサービスですかね。人をフォローできるのがいいですね。
#とおるさん発見。今日知ったのですが結構はやっている感じなのかなあ。
#僕はとおるさんが興味がありそうなトピックを推薦できるみたい。
#なるほどなあ。
#おお、なるほど。
#風が強い…時々室内灯が、ふっ、と暗くなる。また停電来るかなあ。
#ほう、youtubeも長さ制限無くなったとな。uploadをクリックしてみたら確かに "Congratulations! Your account is now enabled for uploads longer than 15 minutes." って出た。
#当面上げるものもないが。
#ピアノ曲の長さの縛りがなくなりますね
#ピアノソロで15分超って、かなり重い曲な気がするけど
#リストのロ短調ソナタ… 嘘です弾けません。
#数楽章まとめて、とか、曲集まとめて、なら越えますね。ショパンのエチュードは編集で12曲つなげたやつを制限に収まるように切って上げました。ばらばらになってた方が利便性はいいかも。playlist作ればいい話だし。
#ショパンのエチュードについては順番に弾くとちゃんとつながりがあるようになっているので、切りたくないってのはあるけど。
#でももう体力的にも練習時間的にも長い曲は難しいなあ。
#確かに体力いりますよね
#読めるところまで周囲を引っ張るか、周囲が読めなくても大丈夫な体制を作るところまでが「仕事」ですな RT: @nagayoru: gaucheで書いたやつ（マクロとかいっぱい）を人が読めないから書き直してって言われてる。やっぱりlispは仕事で使うべきじゃないのか・・・。
#もちろんコストとクオリティの兼ね合いがあるので、周囲も知っている言語Xを使うのに比べて生じる摩擦分のコストアップより、言語Yを使うことによるメリットが大きくなければ、わざわざ言語Yを使う意味はない。これはどんな言語にも言えること。
#仕事の内容によりますよね。
#わたしも以前の職場を去る際、Gaucheで書いたスクリプトのいくつかをPHPで書き直すと言う苦行を経験しました。
#実際には、知っているプログラミング言語で書かれているからと言って引き継ぎコストが低いとは限らないんですが
#やはり「知らない言語で書かれている」ことの心理的なハードルはかなり高いようです。
#それは拷問 > PHPで書き直し。PHPが悪いというんじゃないけど、言語Xで簡単に書けることがYではまわりくどい書き方をしなければならない、という場合にXのプログラムをYに書き直すのは辛いですね。
#まぁ、単純なスクリプトだったので(Gaucheじゃなくても簡単に書けるレベル)、書き直せたんですが。
#そこが難しいところで、Lispじゃなくても簡単に書けるものなら、周囲はわかる言語で書いてくれって思うだろうから、Lispを使うことの摩擦は大きくなる。本人としては簡単なものでもちょいちょいっとLispで書きたいってのが心情だろうけれど。一方、Lispじゃないと簡単に書けないものなら、周囲にもLispを理解しようというインセンティブが生まれる。
#つまり、難しいことをすればするほど、周囲との摩擦は小さくなる。
#(摩擦ってのは人間関係の摩擦ってことじゃなくてギャップを埋めるコストってこと。インピーダンスと言った方が良かったか)
#うん。ただし、私が仕事でかかわったプロジェクトで、他の言語だと難しいがLisp系言語だと劇的に楽にかけると思われるような課題には遭遇しなかったんですよね。
#そして、仮にそれがあったとしても、Lispを全く知らない人にその優位性を納得させるのはかなりのハードルだと思いました。
#だから、日頃書くような小規模なツールから少しずつ馴染ませていこうと画策してたんですが、実る前にわたしが去ることになったのが敗因だったのかなぁ、と。
#現実的には、全員に納得させられなくても、自分以外に1人か2人わかる人がいるって状態を作れるといいんですよね。そしたら自分がsingle point of failureにならないってことで上も説得しやすい。
#"Lisp Bot Wins Google AI Challenge — Will Lisp Win in the Semantic Web, Too?
##readとevalがはっきり分かれている言語があまり無いからなあ RT: @nitro_idiot: REPLってLisp界特有の単語だったんだね…インタラクティブシェルとか初めて聞いた。そういえばSmalltalk勉強会でもREPLって通じなかったなぁ
#readとevalが分かれているということは、evalはreadが返す構文木(データ構造で表現されたプログラム)を受け取るということ。構文木が複雑だと、そんなevalを作るメリットがあまりない。LispはS式でプログラムが表現できるために、データ構造でプログラムを表現してevalに渡すことが自然にできる。なのでreadとevalの分離は根っこのところでS式と結びついている。
#マクロのせいで読みにくくなるのは、
#マクロの書き方が悪いんじゃないですかね。
#うーん、そういう言い方もできなくはないんだけど…
#マクロってのは抽象化で、抽象化の作法っていうのは問題をどう捉えるかってことに依存する。わりと問題の捉え方が成立している分野では抽象化の作法ってのも定石みたいなものが決まってる。そういう背景を知ってる人が、その定石に則ったマクロを見れば、細かいことを知らないでも読めちゃう。
#読みにくくなるのは、(1)既にある作法を無視して独自の抽象化作法を使ってる、か、(2)問題が新しかったりニッチだったりして確立した作法が無いので、新たな抽象化作法を編み出した、か。前者ならはっきりとマクロの書き方が悪いと言えるけど、後者については、まあパッと見てわからないんだから悪いって言い方も出来るけど、「良い」やりかたをまだ誰も知らない段階なのでそこを責めてもなあ、という感じ。
#(2)のケースでマクロを使うのはむちゃくちゃ強力なんだけど (半ば、新しい問題に合わせた新しい言語を作るみたいなものだから)、それを人にわかってもらおうと思ったら、単に仕様や使い方だけを説明するんじゃなくて、背後にある抽象化の作法自体を説明する必要がある。
#「どう」使うかじゃなくて、「なぜ」そういうマクロがあって「なぜ」そういうインタフェースになってるのか、を説明するということ。
Gauche > Archives > 2010/12/10