2016_09 のバックアップ(No.6)

2016年09月

(by K, 2016.09.01)

↑

2016年09月01日(木) #00 あえて協力ではなく一人で

タグ： #雑談

世間では、みんなで一緒にやりましょうとか、チームワークとか、協力とか、そういう文脈が多い。そんな気がする。
そして技術が発展することで、より多くの人が効率よく協力できる、みたいな話がある。オープンソースの流れもまさにそれの一つかもしれない。

これはこれで結構なことなんだけど、僕はむしろ「一人だけでできることを増やす」方向の技術発展に興味がある。つまり個人の生産性を上げたい。従来、これは多人数で協力しなければできないと思われていたようなことを、時間はそれなりにかかってもいいから、たった一人でやってしまったとかできるようになったとかいうのが好きだ。
一人でできるっていうのがどれほど素晴らしいか。それは他人にアイデアを説明しなくていいし、いいわけも説得もいらないっていうことだ。
いや、もちろんそういうコミュニケーションがアイデアを磨くこともあるんだけど、でもそれがただの非効率でしかない場合もある。特に新しいことをやろうとするとたいてい周囲には理解されない。だから時間がかかってもいいから一人でやりたい。僕はそう思うことがよくある。

僕は仲間がいればなあって思う場合、手伝ってくれる仲間よりも競争してくれる仲間を想定するほうが多い（全てではないけど）。手伝いはコンピュータにやらせる。つまり僕にとって協力する相手はコンピュータであり、競争する相手は人間だ。コンピュータは強すぎるかもしくは弱すぎて、どちらにせよ競争相手にはならない、どんな分野でも。

この話題は絶対どこかで書いたよな・・・と探してやっと見つけた。2014_0001の2014.01.12 Sunだ。

だから集団開発のためにどうたらこうたら、みたいな話を聞くと、うーん、それじゃないんだよーって言いそうになってしまう。そんな努力はいいから、まずは個人の生産性をあげようよー。個人の効率が上がれば、もちろん全体の効率も上がるよ！でも集団開発のためのいい方法が見つかっても、個人開発の人にはメリットはないよ。

なんかね、集団開発するときは当然だけどみんなそれなりに足並みをそろえなきゃいけない。やれコメントの付け方をどうしろとか、インデントはこうしろとか、変数や関数の命名規則はどうしろとか。チームの中の一番できない人に全員が合わせなきゃいけない。もちろん一番できない人は精いっぱい努力して背伸びしてそれなりにはできるようになってもらうわけだけど（そうでなければチームから外される）、一番できる人はもっと雑に書いても余裕でできるしその方が開発効率がよかったりするわけで、それなのに一番できない人に合わせるっていうのは確実に非効率だと僕は思う。
基本的に、人は自分の限界に近いところで作業をしているときに成長する。だから一番できる人は集団開発をしても伸びないかもしれない。それでいいのか。できる人はどんどんできるようになって革命的な手法を編み出すところまで行くべきなんじゃないのか。

個人の生産性を上げるにはどうしたらいいだろう。そのためにOSにできることはなんだろう。プログラミング言語にできることは何だろう。

↑

2016年09月01日(木) #01 多数決じゃだめなこともあるという話

タグ： #雑談

ここに10人のグループがあったとする（村？）。たまにすごい人がいるかもしれないけど、でもまあ10人に1人の割合なので、たいていはその程度でしかない。
それに対して1万人のグループがあったとする（町？）。この中には相当に優秀な人が混ざっているかもしれない。もしこの優秀な人の意見を活用できれば、このグループは相当に「強く」なれる。
多数決というのは一つの問題についてみんなで考えるということだけど、そういうことをすると、1万人に1人しかない天才の意見はまず無視される。天才は「そのプロジェクトは失敗の可能性が高い」と完全に見抜いているかもしれない。でもそれは反映されない。だからせっかく1万人みんなで決断しているのに、10人で決めた場合と同じ程度の決断力しかない。むしろ1万人から集計するために1000倍のコストがかかっているから損なくらいだ。

どうすればいいのか。天才は若いうちから誰かによって見出されるべきである。そしてその人にはできうる限りの最高の教育をして、最大限に賢くなって、その上でその意見は他の凡人たちの何倍も（というか数千倍くらいは）重視されるべきである。もしそれができれば、1万人のグループは10人のグループの1000倍よりも素晴らしい成果をあげられるだろう。
企業では、適材適所みたいな考え方が浸透していて、優秀な人はどんどん出世して、意見が重視されるようになっている。それに企業では多数決で物事を決めることはあまり多くない。たいていの重要なことは社長とかが決める。社長も優秀な社員に助言を求めるし、それで考えたりしている。

日本は人口1億人だけど、それを十分に生かせているのだろうか。
中国とかは、優秀な人はどんどん奨学金がもらえて留学させてもらえるらしいと聞いたことがあって、ああ、それは10億人という規模をうまく活用しているんだなーと思った。

↑

2016年09月01日(木) #02 中途半端な詐欺

タグ： #雑談

世の中には他人をだまそうとする人がいる。そういう人の一部は、最後の最後に「でも僕は○○だとは言ったけど、××だとはいってないよ。だから嘘は言ってないよ」みたいな言い訳をする。僕はこれがいつもよくわからない。
わざと誤解させるように誘導しておいて、きっと相手は誤解しているだろうなと思っていてもより正確に説明して確認しようとしたりはせず、それでいて「自分はウソは言ってない」と言うことにいったい何の意味があるのか。だましたいのなら堂々と嘘でも何でも言って好きにすればいいじゃないか。だましたくないのなら、「それって○○ってことだけど、ほんとにほんとにそれでいいの？××の方がいいんじゃないの？」って言えばいいじゃないか。
わーい、ひっかかったー、っていう笑い話にして、相手の不注意を指摘したいだけなのかな。でも明らかに誤解する文脈を提供しておいて、それでお前が不注意だからいけないっていうのは、やりすぎじゃないか。普通の人なら引っかからないようなことにひっかかるようなら確かに不注意を指摘するべきかもしれないけど・・・。
自分が嘘を言わないように苦労して言葉を選んでいるところをみたりすると、おい、その無駄な努力は何のために必要なんだ？ってつっこみたくなる。

↑

2016年09月01日(木) #03 末永く使えるための仕様とは

タグ： #プログラミング言語

C言語では、intはそのCPUにとってもっとも普通に扱える整数のビット数、とされている。16ビットCPUではintは16ビットで、32ビットCPUではintは32ビットになっている。
僕はこういう仕様はダメだと思う。プログラマからすれば、CPUにとって普通に扱えるかどうかなんてどうでもよくて、とにかくそのプログラムで扱う数値の範囲を十分にカバーできているかどうかがすべてである。
INT_MAXとかを検査すればいいということになっているけど、じゃあINT_MAXが十分でなかったらlongに切り替えないといけないのか。そんなコードはややこしい。
まあ今ではintは16ビット以上、longは32ビット以上と決まっている。そう、こういう仕様がいい仕様なのだ。INT_MAXとかを提供されても全然うれしくない。確実に32ビットを使いたければlongにすればいいのだ。C言語は最初からそうすればよかった。

↑

2016年09月08日(木) #00 行き詰って頭がオーバーヒートする前に

タグ： #雑談

特にプログラミングでよくあることだけど、あれもこれもやんなきゃなあみたいに構想が爆発して手におえないときがある。
そういう時は、そういう構想と無関係でほぼ仕様が確定しているところから片付けていくのがいいと思う。そうやって作っていくと堀が埋まって、肝心の構想もより具体的に考えられるようになる。

↑

2016年09月08日(木) #01 プログラムの時代からデータの時代へ

タグ： #雑談

機械学習とかを勉強すると、プログラムよりもデータのほうが重要なんじゃないかと思えるときがある。プログラムはライブラリを適当に組み合わせた程度で十分だけど、データはとにかくたくさん集める必要がある。

↑

2016年09月13日(火) #00 簡単な可変長整数フォーマット

タグ： #oss

第二世代OSASKではgh4、OSECPU-VMではhh4という4ビット単位のフォーマットを使っていたけど、もっとシンプルで8ビット単位のものがほしいと思ったので設計しました。
0xxxxxxx 1バイト 0-7f
10xxxxxx_xxxxxxxx 2バイト 0-3fff
110xxxxx_xxxxxxxx_xxxxxxxx 3バイト 0-1f_ffff
1110xxxx_... 4バイト 0-fff_ffff
11110xxx_... 5バイト 0-7_ffff_ffff
第一バイトがffになるものはリザーブ

↑

こめんと欄

コメント	お名前	NameLink

0xxxxxxx	1バイト	0-7f
10xxxxxx_xxxxxxxx	2バイト	0-3fff
110xxxxx_xxxxxxxx_xxxxxxxx	3バイト	0-1f_ffff
1110xxxx_...	4バイト	0-fff_ffff
11110xxx_...	5バイト	0-7_ffff_ffff