トップ «前の日記(2009-08-30) 最新 次の日記(2009-09-01)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|

ToDo:


2009-08-31

_ 自然言語プログラミング

http://www.kmonos.net/pub/Presen/fltv/FLTV.pdf

これは今まで見た kinaba さんの偉業の中でも 最高峰だなぁこれは。 そしてこの偉業に自分の名前が出ててうれしかった。

kinaba さんは詐欺師にむいていると思う。 説明がうますぎて、賛成できなくてもすばらしいと思ってしまう。

賛成できない、というか少しひっかかるのは名前推論の話。 最初見た時はすごいなー面白いなーと思った記憶がある。 でもいつだったかその話をぼんやり思い出してる時に、 微妙にひっかかることがあって、そのひっかかりを今また思い出した。 みんなそうかもだけど、僕こういうのよくあるんだよなぁ。 他の人の発言やら意見を最初ぼんやり流しておいて、 後から replay した時になにかそれに対する考えがまとまってくるみたいな。

で何が賛成できないかというと、 コピペビリティを落としたり、 直交する文を挿入した時に意味を変えちゃうことがあるんだよねコレ。

String serializedString;
Obj objs[10];
for (int i = 0; i < 10; i++) {
  var _ = objs[i].serialize();
  serializedString += $String;
}

とか書いてたことにして、 なんかこうこの時点での objs[i] の値の中身が見たいとして、 適当に他からコピペしてきたデバッグルーチンを コピペではったりするとして、

String serializedString;
Obj objs[10];
for (int i = 0; i < 10; i++) {
  Obj o = objs[i];
  var _ = o.serialize();
  // ここを
  String s = "";
  for (int j = 0; j < o.children.size; j++) {
    if (j != 0) s += ", ";
    s += o[j].debugString();
  }
  printString(s);
  // コピってきたよ
  serializedString += $String;
}

とか、まあ恣意的な例だしこれ自体に関しては デバッグ出力用の関数を Obj のメンバにしろよボケという話なのだけど、 まぁこういう状況は他にもまぁ、あるんじゃないかなぁと思う。

自然言語でも実際これってよく起きる問題だと思うんだよなぁ。 英語論文とかひいこら言いながら書いてた時とか、 わかりやすくするために文の順序とか入れ替えてたりすると、 いつのまにか以前は問題なかった the が 意味がわからんくなる程度に遠くになっちゃったりして。

エラーコレクティングが容易な口語では、 この手の省略ってヤツは鬼強い物体なので、 口語でプログラムできるようになったら こういう名前推論はありかなぁとか思う。 あと、要はミスに気付かせてくれればいいわけで、 IDE が賢くなって、名前が変わった時に $String が色が変わったりして知らせてくれると十分なのかもね。 あるいは名前推論は basic block をまたげないとか そういう制約を入れてしまうか…

ところで上の例はもう一つ本当にウザい話と関係していて、 コピってきた元の例が本当に j でループしてくれていればいいんだけど、 i でループしてたらこれ全部 j に書き換える必要があったわけで、 for の中の 3 つの i=>j はまぁ忘れなかったとしても、 中の if の i=>j は、これは、僕がやったら 50% くらいの確率で ミスる部分なんじゃないかなぁとか思う。 さてこの内側のループのコピペミスに関しては、 これはむしろ名前推論がなされてれば完全に防げるミスだったりするわけですよね… 実際 Perl でコード書いてると $_ についてよく起きることのように思う。

とかなんとか。

every と some は、 sawzall の some はそんな動きしてたっけ、 いやなんかもっと珍妙な動きをしてた気もするが…

http://labs.google.com/papers/sawzall-sciprog.pdf

Quantifier variables are declared like regular variables, but the base
type (usually int) is prefixed by a keyword specifying the form of
quantifier. For example, given an array a, the statement
  when (i: some int; B(a[i]))
    F(i);
executes F(i) if and only if, for some value of i, the boolean
condition B(a[i]) is true. When F(i) is invoked, i will be bound to
the value that satisfies the condition.

全然別物だったよ。 要はループに並列可能性を suggest するためのものだった。

メッセージを共通化する話は、

.maxPriority = .max{|a,b|a.priority<=> b.priority}

っていう文法は普通にいいなぁ。

objs.map{|o|o.children.map{|c|c.doSomething}}

objs.map(&.children.map(&:doSomething))

とか書けるといいなぁ。 途中の話に戻るけど、要はループ変数というのが 最も名前を省略したい物体なのだよね。 あれだけ type 数を増加させる C++ の algorithm なのだけど、 iterator の名前をつけなくて良いのは抗いがたい魅力なのですよ。

どうでも良いのですが、 僕は iterator の変数は i とかつけて j とか k とかにするのは k とかが int じゃないのが混乱を招きそうで嫌いだし、 it は英語の it ぽくてキモいという話もあって iter を採用しているのですけど、 iter の次の、2つ目以降の iterator 型ループ変数名にいつも困っていたのでした。 たいていは外っかわをもう少し説明的な名前にしてたのだけど、 どうしても名前つけにくいものも多くて。

ところがこの間 jter とか kter とかつける文化が 多くは無いもののあるようだと教えてもらって、 これがすごく気にいっているのでした。

変数名として意味の無いものをつけるべきでない、 という主張があって、 tmp とかはいけないとされてると思う。 でも、どうでもいいループの変数、特にループの中で すぐにデリファレンスしてそれ以降使わない iterator 、つまり、

for (vector<Obj*>::const_iterator iter = objs.begin(); iter != objs.end(); ++iter) {
  Obj* obj = *iter;
  // 二度と iter は必要ない…
}

とかそういうものは 本当にどうでもいいんだから、 どうでもいい名前をつけるべきだと思っていて、 これを obj_iter とかつけるのはむしろこう、 意味深で可読性を落としているように、 個人的には思うんだよな。

一方僕は humans.find(you) とかした結果帰ってきた iterator に iter と名付けるのはよくないと思う。 それは単なる名もなきどうでもいい 60億要素の humans それぞれを指す iter じゃなくて、 60億の中のたったひとりのために用意されたかけがえのない iterator なので、 もう少し意味がある名前をつけるべきだと思う。 僕は found とかよくつけるけど。

find といえば、その見つかった iterator を 名付けないのもあまり好きでない。

objMap.erase(objMap.find(o), objMap.end());

とかいうヤツ。 これは冗長でも分けたいケースが多いように思う。

map<Obj*>::iterator found = objMap.find(o);
objMap.erase(found, objMap.end());

なぜかというと、 この found は何かしら貴重なものに決まってるから、 後から log 出力に加えたい可能性、 printf デバッグやデバッガで名前を指定したい可能性が かなり強いと思うから。

これは意識するようになったのは割と最近のことかもしれない。

(05:56)

_ 追加

何個か書き忘れてた。

  • swap する時は tmp って名前をつけてもいいと思うんだよね。
  • Ruby の tap とか 1.9 の引数が帰ってくる mame#p は printf デバッグの観点では .find の戻り値をいちいちローカル変数に入れなくても十分にしてくれる能力を持ってると思う。実際、 Ruby だったら僕はこういう値に名前をつけなくても全然違和感ないし、むしろ自分でもつけない気がする。そのへんは書いてるプログラムのドメインやら言語やらによる部分も多いな。

(06:05)

_ 民主

自称サヨとしてはむしろ民主より左よりでいいくらいなので、 自民よりは民主でまぁいいかなぁという感じだった。 公明も消えるし。

うちの選挙区の自民の人は大変ニートにやさしくなさそうなことを ブログに書いていて、気にいらない感じだったのでそれもよかった。

個人的には民主は結局何言ってるのか わからんとかいう話があるのだけど、 まぁ色々な人から広く支持集めようとするとそんなもんかねえ的な。 僕だけの支持を得ればいいのであれば もっとわかりやすい左でいいわけだけど

(06:21)

_ JVM読書会

http://twitter.com/kmizu/status/3646075084

あるといいなぁ。

というかでも、なんだろう一つのコードを ひたすら読むのって結構疲れるし あまり意味ない時間も多い気がするんだよな。

でなんか思ったんだけど、 最近読んだ/いじったコードを紹介する輪読会があれば 僕は満足なんじゃないかなぁとか思った。

(06:27)

本日のツッコミ(全1件) [ツッコミを入れる]
_ kohls coupons (2014-05-24 03:05)

&#12381;&#12398;&#12424;&#12358;&#12394;&#24847;&#21619;&#12398;&#12354;&#12427;&#12502;&#12525;&#12464;&#12398;&#35352;&#20107;&#12398;&#12383;&#12417;&#12395;&#12354;&#12394;&#12383;&#12398;&#12454;&#12455;&#12502;&#12510;&#12473;&#12479;&#12540;&#12395;&#24863;&#35613;&#12290;&#31169;&#12399;&#12289;&#19978;&#12398;&#12499;&#12517;&#12540;&#12395;&#24863;&#37528;&#12434;&#21463;&#12369;&#12390; はじめてのにき(2009-08-31).

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2009年
8月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
1.niha(2014-05-24 03:05) 2.shinh(2014-05-24 03:05) 3.niha(2014-05-24 03:05)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h