トップ 追記

日々の破片

Subscribe with livedoor Reader
著作一覧

2015-07-01

_ 最大600個の法則

自然を名づけるにおもしろい考察(たった2件の実験結果もある)がある。

人類学者のブレント・バーリンの発見として、幅広い分野で民族分類においては、属の数は600が上限というものがあるそうだ。リンネ以前の自然科学者たちの分類でも属の数は600で尽きている。

どうも、人類という生物は機能的にある項目数の上限を自然と600に制限してしまう=600が記憶の上限らしい。

興味を持った筆者は昆虫学者の夫に生物の属数を数え上げさせてみた。結果は575。爬虫類学者の友人にも頼んだ結果は591。

もちろん、2人とも後になって、なんでこの時xやyを思い付かなかったのだろうと首をひねる。

どうも、バーリンの調査は正しそうだ。必要な時に思い出さないのであれば、命名する意味がない。だから、どの民族も600を上限として命名するようだ。

自然を名づける―なぜ生物分類では直感と科学が衝突するのか(キャロル・キサク・ヨーン/三中 信宏/野中 香方子)

で、多分に時間がかかるから実際に数え上げテストをやる気はないが、きっとおれはWin32APIで600、JDKで600、.NET Frameworkで600、RubyのKernel、組み込みクラス、主要ライブラリを合わせて600の関数までは使える(詳細はともかくこのAPIを使えばよいと考えられる)のではなかろうか(パラメータや定数も関数と同種として記憶していると仮定するともっと減るだろうが)。

逆に言えば、APIが600を超えた処理系(主要ライブラリを含む)やプラットフォームは、開発者の人間の機能制限を超えるため衰退していくのではないだろうか(それでMSはWin32APIからWinRT APIへ移行させようとしたのだったり)。もっとも何をもって科(属の上の分類)とするかはありそうだが、グラフィックAPIだけで1つの科とかみなすのは無理筋な気がする。

(と最初書いたが、科ではなく、界のレベルで考えなければおかしいことに気付いた。生物の属名といっているわけだし。すると、すべてのAPI界で600というように適用することになる。その場合、どれだけの属名を支配するかで開発者の依存度が決まることになる(600項目の入れ替えが難しいと仮定した場合)。それが、VBを極めると他の言語に動けなくなったり、Win32APIエキスパートがPOSIX全然だったりする理由なのかも知れない。個々人の頭の中の600という属名の分捕りゲームということだし、なんちゃらの専門家というのはそのなんちゃらで600スロットを埋めてしまった状態を指すのかも)

あるいは、それ(存在を思い出せないAPI)をIDEが補完したり推測できれば済むのだとすれば優れたIDEの提供がプラットフォームベンダーには必須(MSの切り開いた方法)という道理だ。

とりあえずFreeBSDのシステムコールが500個、Linux2.6が280個。


2015-06-28

_ 沈黙

新国立劇場で、松村禎三の沈黙。

原作は読んだことがないので、完全に初見でもある。

松村禎三はえらく前にビクターから出たLPを持っていたことがあるが、響きが美しい曲を作る人という印象がある。

松村禎三の世界(田中信昭/若杉弘/石丸寛/読売日本交響楽団/東京交響楽団/青木静雄/小林仁/坪田昭二/小泉浩/遠藤郁子/松村禎三)

(多分、これの元になったやつじゃないかなぁ)

場を細かく区切った2幕構成。

舞台には巨大な十字架が斜めに立つ。

最初、十字架にかけられて火あぶりにされる人を背景に置き、家族を密告したとしてキチジローという男が村人から責められているシーンで始まる。ハライソの寺へ行くのだという歌のみ明確な旋律がある。

場が変わるとマカオで、フェレイラから音信がとだえたため現状を知りたいと日本への渡航を地区長へ頼むロドリーゴ神父が出てくる。水先案内人としてキチジローが連れて来られるが、あまりのびびりっぷりに神父が呆れる。

場が変わると切支丹村で歓迎されるロドリーゴになる。名前がロドリーゴなので間違いなくこいつは牢屋へ入れられるのだろうなぁとか考えながら見る。恋人同士を祝福する。

場が変わると踏絵となる(幕を下ろした手前で演じられる)。

ああそうかと最初の場の記憶もあってはじめて、踏絵について納得した。

そんなもの、我が心の神を守れば、いくらでも踏めば良いではないかと不思議だったのだが(実際、江戸時代の中期以降はそうなったらしいが)、

1) 神は外部にあるのだから、その行為をどう取りつくろうが、神に見られているのだ(※)という意識があればなかなか踏むことはできない

2) 踏んで帰れば、村の人間は踏んだということを知ることになる。まして踏まずに帰ってこない人間がいればすでにそこに留まることは難しい。カムイ伝の正助だ。

※)この宗教受容のありかたが、日本人の多宗教容認(外に神があるという感覚の喪失)につながっていたりもするのかな?

かくして場が変わり、一緒に捕えられて踏むのを拒否した3人が海中への磔となっている。いよいよ潮が満ちて息ができなくなるというときに、前の場で結婚した男がハライソの寺の歌を歌う。このシーンは信じがたいほど感動的で驚く。見事な舞台だ。

ついにロドリーゴはキチジローの密告により捕まり、1幕は終わり。

2幕、奉行は以下の条件をロドリーゴへ出す。神父が転べば、その影響は絶大だ。お前が転べば、村人たちを許す。

ミノムシ状態で船から海へ投げ捨てる処刑を前に転ぶから許してくれといいだす村人が登場するが、奉行は認めない。もう遅い。しかしロドリーゴが転べば許す。だが、他の村人たちが、おれたちは喜んでハライソへ行くのだ。パードレは転ばんでくださいと言うのに力を得てロドリーゴは拒否する。

フェレイラ(沢野忠庵)登場。日本人はデウスを大日如来ととらえるし、しょせん、自分の外側に絶対的なものをおくという考え方はできないのだ。お前のやっていることは無駄だから、転んでしまえ。ロドリーゴはやはり拒否する。

最後の夜となり、牢屋に一人いるロドリーゴは呻き声を耳にする。音響として呻き声以外の何者にも聴こえないのだが、ロドリーゴにはそれが牢番の高いびきに聴こえる。

キチジローは告解をさせてくれと牢の外をずっとうろついている。ロドリーゴにはその声も不快に感じる。

忠庵が最後の説得にくる。ロドリーゴは拒否しつつ、牢番のいびきを止めてくれと言う。忠庵は驚き、あれは逆さ吊りにされた切支丹の苦痛の呻き声だと教える。お前は、自分が信仰を捨てぬことで神から認められたいというだけなのではないか。村人たちの苦しみを救っていないではないか。もしイエスだったら、どうすると思うか?

ロドリーゴはここにいたって観念する。

最後の場は長い。ロドリーゴは踏絵の踏まれて汚れたイエスを見て散々ためらった末にそっと足を乗せる。そして持ち上げ抱きしめる。

・原作では、ここで踏絵の中のイエスが感動的な語り掛けをするようだが、オペラではすべては無言のうちに進行する。

沈黙(遠藤周作)

なるほどなぁ。傑作だ。


2015-06-27

_ エクストリームプログラミング

池袋ジュンク堂で、角さんと角谷さん(名前の字面に山がない)によるエクストリームプログラム新訳のトークセッション。

参考文献特集でいろんな本が売っていたが、まずは青木さんの新刊だ。と思ったら置いてないので、長田さんに頼んで持ってきてもらって、まずはゲット(後払いだけど)。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)(青木 峰郎)

間違って早く着きすぎたので読み始める。

PostgreSQLを一応使うように書かれているが、それはあまり関係ない。

前書きを読むと、読者としてエンジニア(ソフトウェア開発者)とプランナー(データコンシューマ)の両方をターゲットとしていることがわかった。

・エンジニアはプランナーの意図を知るために読む。そしてエンジニアリングで何ができるかわからずに悶々としているプランナーの机の上にこっそり置く

・プランナーはエンジニアに意思を伝えるために読む。そしてデータ分析という観点が欠落しているエンジニアの机の上にこっそり置く

・プロジェクトの前にプランナーとエンジニアが勉強会を開いて一緒に読み、何をなすべきか合意する

と、3番目の読み方で、なんとエクストリームプログラミングのトークセッションの会場で売るにふさわしい本であることがわかった。

「XPは人と人とのつながりを変える」のだから、まさに青木さんのデータベースの本はエクストリームなのだった。

で、それはそれとして縦持ち横持ちとか(そうはいっても横持ちにも良い点はあると書いてから、では縦持ちにしましょうと進める余裕が、昨日の本の著者には無い文章作法で、実に心地よい)、ウィンドウ(これ、SQL Serverに導入されたとき、別の呼び方をしていたなぁと思い出しても思い出せない)とかを読んでいるうちに時間となった。

エクストリームプログラミング(Kent Beck/Cynthia Andres/角 征典)

集まった人たちをみて、黒テントを観に行ったらじじばばばかりでびっくりしたのと同じような感慨を全員が共有しているところで、始まる。

そうか、PofEAA読書会の同窓会のようなものなのか。

角さんのお話は、エクストリームプログラミングは読みにくいので(初版の翻訳はとても問題があると考えていたが、いざ自分で訳してみたら、ケントベックの書き方に問題があることが良くわかったとか話していておもしろかった)、ではどう読むべきか、それは表層(テクスト)ではなく作家主義でいくしかない、というわけでケントベックの生い立ちなどの説明から始まった。

作家主義ってそうではないような(と、つい映画における作家主義を考えてしまう)。ゴダールやトリュフォーがジョンフォードやハワードホークスの生い立ちを調べたとわけではない。その作家の作品にはその作家の刻印があり、それはその作家の作品を見ることだ。映画は役者の名前でみるものでも、物語がどうしたとか、ジャンルがどうしたとかでみるものでもない。それは誰が作ったかで観るものだ(突然思い出したが池田ののびーは黒澤明について誰かの書いたものをとりあげて、映画作家という呼び方をふつうはしないと断言することで見識の狭さを妙なところでも発揮していたなぁ)というのが作家主義のような気がするが、テクストとの対比ということは文学用語なのかも。しかし、野坂昭如の韜晦を額面通りにとって引用するのを目にすると、作品を書いた言葉と同じ作家の言葉であるという言葉の本質を軽々と無視できるのがとても不思議になる。作家の言葉はすべて作品なのだから、作品であろうが作品について語ったものであろうがどちらもメタな言質であって額面通りに受け取ってはならない。

とか考えながらも、角さんのプレゼンはむちゃくちゃおもしろくてまったく時間を忘れるほどだ。語り口のうまさと興味をひかせるためのアイキャッチとしてのスライドの融合だな。実におもしろい。

で、終わった後の懇親会に参加するためにうろうろしていれば、いやでも入口に並べられた本に目が行く。

というわけで、参考文献特集から、とりわけ目をひいたものを購入してしまう。

ディズニーアニメーション 生命を吹き込む魔法 ― The Illusion of Life ―(フランク・トーマス/オーリー・ジョンストン/高畑 勲)

ケントベックによれば(エクストリームプログラミングの参考文献リストにはケントベックによる一言コメントがついていて、そこも訳出されている。これが実におもしろい)、「ビジネスや技術の変化に対応するために、ディズニーのチーム体制が長年にわたり、どのように進化したかが描かれている。ユーザーインターフェイスデザイナーのヒントになることが満載。素晴らしい絵も収録されている。」

なのだが、そんな言葉を読む前に、目の前にした本の美しさとぱらぱらめくったときの書物としてのパターンに惹かれまくってしまったのだった。というか、タイトルがすでにデザインパターンではないか(魔法の形容ではあるけれど)。

その他、まだ読んでないことに気付いたので、クーンとか購入。

_ エクストリームプログラミングとチームギーク

思い出した。

角さんによれば、2つのタイプの人間がいる。

1つは目的至上主義。重要なのは目的の達成(成果を上げる)。

もう1つは手段至上主義。重要なのは過程を楽しむ。作る喜び至上主義。

で、続けて次のように断じる。

ケントベックは後者で、後者のことを世間知は「ボンクラ」と呼ぶ。

---

たとえば、「はじめに」を開いた途端に次の文章が目に入る。

「良いチームだろうと悪いチームだろうと、改善は必ずできる」

おかしい。

良いチームなら改善の必要ないじゃん。そんな余計なことをしている閑があったら、さっさと成果物を出せ。

とならずに、改善することが目的化していることにケントベックはまったく気づかずに改善に邁進する。

その結果、成否は問題とならなくなってしまう。重要なのは「開発者として最善を尽くすことだ(第1章の冒頭)」。

男だぜ。

というか、なるほどボンクラであるな……

が、そこがエクストリームプログラミングで語られていることの要点なのだった。

1980年代の流行語(世界的)にattitudeがあった。すべてのかっこよさはその個人のアティチュードに起因する。まさにエクストリームプログラミングとはあるべき(とるべき)アティチュードを示すものだ。なるほどケントベックが職業人としての道を歩み始めたのは1980年代だ。

それは真摯である。人間であるならば、かくありたいものだ。

エクストリームプログラミング(Kent Beck/Cynthia Andres/角 征典)

したがって、本書の対極にあるのが、チームギークだ。

チームギークにはチームワークをうまく回すためのいろいろな戦術が書かれている。なぜそのように振る舞うのか? それは成果を上げるためだ。多様性の尊重よりも、エゴの抑制(多様性を尊重するということは、おれさまのアティチュードも認めろということに他ならない)。すべてはチームの成果のために!

そこには人間としての真摯さというポエジーはない。あるのは、冷徹な計算だ。

まさにクール! スマート! ~(ボンクラ)である。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか(Brian W. Fitzpatrick/Ben Collins-Sussman/角 征典)

中庸を良しとするのであれば、両方から学ぶことができる。

そうでなければ、エクストリームプログラミングを勧める。「中庸を良しとする」妥協策が気に入らないとすれば、それは手段を重視しているからだ。


2015-06-26

_ 『自然を名づける』を読んだ

以前蛾の先生から教わって買ったままになっていた自然を名づけるを読んだ。

ここ数年で読んだ中で一番おもしろかった本かも知れない(不満もたくさんある)。あまりにおもしろいので400ページを越えるハードカバーの重くてかさばる本なのに通勤時に持ち歩くことになってしまった。

純粋にすさまじくおもしろい点を挙げる。

・まず、生物分類学という学問そのものと学者たちがおもしろい。

・良く知らない情熱を傾ける人がいるジャンルについて知ることそのものがおもしろい。

・リンネのキャラが立ち過ぎている。傲岸にして不遜、しかし真摯というおれの好みのタイプだ。

・数量分類学(ソーカル、最初ポストモダン叩きの人かと思ったら別の人だった)のキャラも濃い

 ・ソーカルがすごく好き――思い入れをもって読んでしまうのは、今になって気付いたが、師匠のミチナーとあわせて、まるで「先生、おれは対位法にさかのぼって勉強する必要があるんでしょうか?」「君、数学を知っているじゃん。音楽は構成だ。数学を使ってみればいいじゃん」というクセナキスとメシアンのことを意識せずに重ねて読んでいたからのようだ。

・ウーズのRNA分類が途中で消えてしまうのだがどうなったのだろうか?

・悲劇の半生ヘニックの知性にしびれまくる。またそれを発見した人たちも偉いなぁ。

・分岐学派の描写がヒャッハーのモヒカンそのものでぶっ飛ぶ(訳者のあとがきによれば、別に筆者がもっているわけではなく、十分以上に抑制して書いているというのだから、どれだけ攻撃的な連中なのかと。リナス世代なのだろうなぁ(と、タネンバウムとの論争を想像したり))

分類という行為に関する知見もおもしろい

・脳による生物と無生物の認識の差というのは実におもしろい

・ポケモンやら乗り物やらに対する子供のコレクション欲求

・些細なブランド(カバンでもPCでもOSでもなんでも良いけど)の差異分類/識別能力

・特に筆者による、現代のマーケティング(ブランド戦略)は人類(生物)の本質的能力である固体識別/分類/認識能力の刺激に依存しているのではないかという知見には感心しまくった。説得力があり過ぎておもしろ過ぎる。

特に中半まではページをめくる都度に新たな発見があるくらいに興奮のるつぼ状態で読める。

自然を名づける―なぜ生物分類では直感と科学が衝突するのか(キャロル・キサク・ヨーン/三中 信宏/野中 香方子)

不満点は、著者の態度だ。

どうにも分母が少ないからだとは思うが(とは言えこれまで著者名を意識して読んだ5人のうち5人全員だ)、女性科学者(科学分野著述者)特有の不快な攻撃的文体(訳者のものとは思えない。おそらく文章の組み立て方法にあるのだと想像する)が多用されているのだ。

特に第1章と後半で鼻につきすぎる。とにかく第1章が香ばしすぎるので危うく読むのをやめるところだった。

ルサンチマンが漂うと、ようするにこいつは全然知らなくて自信もないから虚勢を張って適当を書いているのではないか? と疑念が浮かんでくるからだろう。内容は最高なのだからもっと普通に書けば良いのにもったいない。

なんか最後のほうでは

・読者を子供扱いしてご機嫌を取るというくだらない戦略

・本気でぶっとんでしまった

・もともと頭が悪い

・書くことがなくなったので出版社とのページ数の契約上の帳尻合わせ

のいずれかに見える。

もっとも、本書にも出ているが、アメリカという大半の住民が進化を否定している国の言語で一般教養書を出版するということによる慎重さという可能性もある。その場合は

・読者をばかだと想定……というか、最初の可能性と同じことだった

そこが非常に読んでいて気分が悪いが、内容は本当におもしろかった。


2015-06-22

_ クヌースのThe Art of Computer Programming 1

アスキーの鈴木さんから分厚い封筒が届いたので、wktkしながら開けるとやはりThe Art of Computer Programmingの1が入っていて、猛烈に嬉しい。ありがとうございます。

世の中には、読むべきであり、読めなくても蔵書しておくべきであり、少なくとも眺めてはおくべき本というものがある。でも時代のちょっとした隙間で入手できなくなることがある。また、それはべきべきなので、必ず現時点に何らかのかたちで反映されている。したがって、意識せずとも済ますこともできる。つまり古典というものだ。

その古典の奥付に記された発行者を眺めて、不可思議な感慨を覚える。

The Art of Computer Programming 1の奥付

1巻は大雑把に(量的に)3つのパートから構成されている。

最初は離散数学で、シグマが山ほど出てくる。O記法(O(n**2)だからダメとかのO記法)もここで触れられている。知らなくても多分なんの問題もなくプログラミングはできるが、ある時点で、なんでおれは知らないのだ? と疑問に感じて(ということは必要性を理解する瞬間があるということだ)結局調べることになる。そこで初めて、高校の時に習った数学の必要性を思い知らされて、もっとまじめに勉強しておけば良かったなぁと感じたりすることになるわけだ。

次が情報構造(第2章)として、線形リストと木について説明してある。こういったことは知らなくても、Javaプログラマであれば、ArrayListやjavax.swing.tree TreeModelくらい何となく使えるはずだ(というか、ArrayListを使わずにプログラムを書くのは無理がある)。

双方向リスト(2.2.5)を読むと、今となっては使われることはないLinkedListについても、なぜJavaの実装当初は必要だと考えられたのか、なぜ.NET Frameworkでは無視されているのか、理解できるかも知れない。(ほとんどのユースケースではArrayListが十分に性能を発揮できるからで、もし、リスト全体のサイズが500MBくらいになってしかも途中挿入(add(index, element))とかが発生しまくれば、ArrayListよりもLinkedListのほうが良い結果となるかも知れない。でも先頭から最後までをしょっちゅう舐めまくるのであれば、途中挿入が発生しまくってもArrayListのほうが性能が良いかも知れない……というときに、プロファイリングしやすくできるので抽象List型を使えば良いね、というような話になるのであって、なんでもList型で受ければ良いというわけではない、別の話になっているけど)

木は使う人は使うが、使わない人にはまったく縁がないデータ構造だが、純粋におもしろい。

残りの1/3は演習問題の解答で、本書の演習問題は基本的に解答がちゃんと出ている。したがってモヤモヤした気持ちになることは無い。

サンプルのコードは、MIX(引用すると「MIXは1960年代から1970年代にかけて使われた数々のコンピュータとよく似ている。違っているのは、たぶんそれらのコンピュータよりも魅力的なことであろう」というわけで、クヌースのある意味理想のコンピュータなのだろう)という仮想マシンのアセンブリで書かれている(MMIXというRISC版に書き直した版についての言及が本文にも奥付にもあるけど、RISCで読みやすいのだろうか?)。多分、このコードを読むと、なぜ1970年代まではフローチャートが仕様の図示に使われていたのか、なぜGOTOが有害とされるにいたったのかを理解できるであろう。というのはともかく、理解しやすいと思う(また、なぜアルゴリズムを考えなくても今はプログラミングするプログラマーが存在できるのかを理解することもできる)。

The Art of Computer Programming Volume 1 Fundamental Algorithms Third Edition 日本語版(Donald E.Knuth/有澤 誠/和田 英一/有澤 誠/和田 英一/青木 孝/筧 一彦/鈴木 健一/長尾 高弘)

なぜ、ドワンゴの第一弾(だと思う)が本書なのか、その歴史的な意義を考えて、まずは購入して欲しい。

あらゆる意味から得こそすれ損となることはあり得ない(本書そのものを蔵書する価値は当然だが、今後の技術書という存在自体の存続に関係するものに違いないと考えざるを得ないからだ)。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|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|

ジェズイットを見習え