天泣記

2016-02-08 (Mon)

#1 条件分岐の心理

ちょっと妄想した。

2016-02-01 (Mon)

#1 RUBY_ で始まる定数の利用状況

ふと、RUBY_VERSION などの定数がどのくらい使われているのか数えてみた。

まず、そういう定数はいくつあるのだろうか。 all-ruby で調べてみる。

% all-ruby -e 'p Object.constants.collect {|x| x.to_s }.delete_if {|x| /\ARUBY_/ !~ x }.sort.join(" ")'
...
ruby-1.3.4-990531     ""
ruby-1.3.4-990611     "RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
...
ruby-1.8.5            "RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
ruby-1.8.5-p2         "RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
...
ruby-1.8.7-preview4   "RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
ruby-1.8.7            "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
...
ruby-1.8.7-p374       "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_VERSION"
ruby-1.9.0-0          "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"
...
ruby-1.9.0-3          "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"
ruby-1.9.0-4          "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_ENGINE RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"
...
ruby-2.2.4            "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_ENGINE RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"
ruby-2.3.0-preview1   "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_ENGINE RUBY_ENGINE_VERSION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"
...
ruby-2.3.0            "RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_ENGINE RUBY_ENGINE_VERSION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION"

とりあえず減ったことはないようなので、Ruby 2.3.0 にあるものだけ考えればいいようだ。

gem-codesearch で検索して数えてみる。

% for w in RUBY_COPYRIGHT RUBY_DESCRIPTION RUBY_ENGINE RUBY_ENGINE_VERSION RUBY_PATCHLEVEL RUBY_PLATFORM RUBY_RELEASE_DATE RUBY_REVISION RUBY_VERSION
do
echo -n "$w: "
gmilk -e grep -s rb -a $w|grep "\\<$w\\>"|wc -l
done
RUBY_COPYRIGHT: 32
RUBY_DESCRIPTION: 467
RUBY_ENGINE: 2800
RUBY_ENGINE_VERSION: 34
RUBY_PATCHLEVEL: 681
RUBY_PLATFORM: 10993
RUBY_RELEASE_DATE: 493
RUBY_REVISION: 91
RUBY_VERSION: 23099

RUBY_VERSION がいちばん多くて、次が RUBY_PLATFORM のようだ。

RUBY_ENGINE もそこそこ多いな。CRuby 以外を考慮する人もそこそこいるのだろう。

2016-01-30 (Sat)

#1

関数型IoTプログラミング勉強会 第0回」に行ってみた。

2015-12-11 (Fri)

#1 RubyKaigi 1日目

昼休みに「APIデザインケーススタディ」のサイン会をやって、100冊完売した。

2015-11-08 (Sun)

#1 大江戸Ruby会議05で発表

大江戸Ruby会議05 で「超簡単! 英語でバグレポート」という発表を行った。

最後のほうの pow(-1.0, infinity) に関するする話は、バグレポートというテーマからはちょっと外れるのと時間がなかったので発表では話さなかったが、懇親会で話したところ、そこそこ面白がってくれたひとがいたようだ。

2015-10-11 (Sun)

#2 人間の認知と API デザイン

「脳からみた心」を読みながら考えていたのだが、API のデザインでも「人間の認知が、勝手に動作するたくさんのプロセスが重層的に組み合わさっている」ということを利用している気がする。

たとえば、この前のRuby開発者会議で、map_keys, map_valuesの提案 について議論があった。hash.map_values は、hash の値それぞれを変換した新しいハッシュを返すメソッドである。いつものことで名前問題なのだが、hash.map_values は hash の値それぞれを変換した値の配列を返すようにみえて良くない、という (しばたさんの) 意見があった。私はそれを hash.map_values と hash.values.map が似すぎている (どちらも map と values という単語から構成されていて、単語の順序と間の記号しか違いがない) ことが問題なのではないかと述べた。

ハッシュにはすでに values メソッドと map メソッドが存在するので、hash.values.map という記述が可能で、これが hash の値それぞれを変換した値の配列を求める書き方である。hash.map_values は、配列ではなくハッシュを返すという違う動作なのだが、似すぎていて、プログラマは区別しづらいのではないか、というわけである。

ここで私が述べたことは hash.map_values という記述をみたときに、map という単語と values という単語からの連想が頭の中で勝手に行われてプログラマの認識に影響する、ということを前提としている。この前提は、言語処理系が行う解釈 (文法にしたがってメソッド呼び出しを認識してからメソッドの名前の解釈を行う) とは異なる。

また、最近の matz の tweet で、「実際、String#+,-についていろいろ考えてるんですよね。-(マイナス)は氷点下からfrozenを連想するとか。」 というのがあった。これも、+ や - という記号からの連想が勝手に起こることが前提となっているように思う。

そういう頭の中で勝手に起こる連想が、実際の動作と一致する (あるいは、少なくとも矛盾しない) というのは API デザインの大きな要素なのではないだろうか。

DSL (Domain Specific Language) もそのような考えで理解できる。DSL をつくるときは domain における記述になるべく合わせて記述できるように工夫する。そうしておけば、domain における記述からの意味の連想が頭の中で勝手に起こる。そして、その連想のとおりの動作を行うようにしておけば、勝手に起こる連想を利用できるので、人間は自然に解釈できるようになる。

人間がプログラムを読むときには、言語処理系の解釈 (もっと正確にはプログラミング言語の意味論) にしたがって解釈すべきだ、という考え方もあるかもしれない。そうしないと間違う可能性があるのは確かで、プログラムが規格の範囲内かどうかを検討するとか、意識的にそうやって解釈しなければならない場合があるのはまちがないない。それに、プログラミングの学習で、上で述べたような人間の話を正面から扱うことはあまりないので、言語処理系が行う解釈しか意識しないひとは多そうな気がする。

そのように考えていると、上記の map, values, +, - といった字面からの連想というのは些細な話だと思うかもしれない。でも、人間の認知のやりかたを考えると、些細な話ではないのだ。

#1 脳からみた心 (著: 山鳥重)

脳からみた心 (著: 山鳥重)を読んだ。

なかなかおもしろかった。読んだ後で検索したら、けっこう定番な本のようだ。もともと1985年にNHK出版から出たのは入手できない時期があったみたいだけど、2013年に角川ソフィア文庫で出し直したようだ。

プログラマから見ると、さまざまなバグの症状からブラックボックスなプログラムの構造を推測するというような話に思えた。ここでいう「ブラックボックスなプログラム」は脳で、「バグの症状」は様々な症例なわけだけど。

紹介されているいろんな例をみると、人間の認知というのは、勝手に動作するたくさんのプロセスが重層的に組み合わさっているという感じに思える。

2015-10-10 (Sat)

#1 オブジェクト生成の時間と major GC の関係

オブジェクトひとつの生成にかかる時間をみると縦横斜めの線が見えて、それが major GC の数と関係しているっぽいと述べたが、生成時間を (前と同じく) 色で示して、その上に等高線で major GC の数を描けばおなじ形であることが明確になるのではないかと思いついた。

で、描いたのが以下である。

gc-2d-raster-contour.R:

library(ggplot2)
d <- read.csv("2015-10/gc-2d.csv")
p = ggplot(d, aes(N, M, fill=TimePerAlloc.s., z=MajorGC)) +
  geom_raster() +
  geom_contour(color="#FFFFFF")
print(p)

gc-2d-raster-contour.png

やはり、かなり似ていることがわかる。色の変化と等高線による分割は同じような形になっていると思う。



田中哲