今朝スターバックスでコーヒーを飲んでいたら、カウンター席の隣に座っていた青年が、万年筆でなんかを一所懸命に書いていた。お手本を見ながら十枚以上も同じ文面を書いている。どうも、営業の訪問先への謝礼らしい。葉書ではなくてカード状の便箋（資料とかも一緒に入れるのかな？）。長文ではないが、手書きだと決して楽ではない分量だ。 自発的なのか、上司に言われたのか、マニュアル化されているのか； ともかく、万年筆・手書きで礼状を書くことに意味があると思って頑張っているのだろう。 もし、僕がブルーブラックのインクでシタタメられた礼状を受け取ったら、「バカか、こいつ」となげいて千切ってゴミ箱に捨てる。「なんてひどいことをするんだ」と思われるかもしれないですね。 「わざわざ万年筆・手書き封書の礼状を出すこと」が、営業上の手法／戦略として有効である、という主張には特に反対はしない。理屈はわかるし、実際、効果があるの

僕は、twitterできわめて少数の人しかフォローしてません。そんな僕のtwitterタイムラインでも、何度も言及されていたのが次のブログエントリー： いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ 本文は「なるほどね」という感想なんですが、コメント欄に驚くべき発言があります。 まずは本文から紹介すると、「いっしょに仕事をしたいプログラマ 5つの特徴」が挙げられていて、それらの特徴で「欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう」と。 5つの特徴のひとつに「人のコードにパッチを送る」（適切なパッチを書ける能力）があるのですが、それに対するコメントが： ミッションクリティカルなシステムでは自分が再利用しようとする既存コードにバグがあった場合は、まるっとコピーしたうえで修正したものを使うことが多いです。 「まるっとコピー」って、い

ウチの子達は、サンタさんを固く信じていました。 その事情は：「なぜ彼はサンタクロースを固く信じているのか」 長男はさすがに「サンタさん、サンタさん」と言わなくなったのですが、次男はサンタの存在自体は今も信じているかもしれません。でも今年はサンタさんにお願いするのはやめてしまいました。 2年前、2008年のクリスマス前に「サンタさんに何頼んだの？」と聞いたのですが「おとうさんには教えない」と言われてしまいました。どうしても聞き出せないので、「たぶんこれだろう」と思うものを準備したのですが希望と違ってました。次男も僕も落ち込みました。「まっ、サンタさんだって間違いはあるさ」となぐさめましたが。 去年も事情は変わらず、またしてもハズレてしまったのです。2年続けてハズされたので、次男はサンタさん不信になり、どうも「サンタさんはアテにならない」と思ったようです。 10日ほどまえに、「おとうさん、クリ

7月20日に、id:hiroki_fさん（a.k.a. ジョニー）から次のようなメールが来ました。 C++闇の軍団の高橋晶さんから、『プログラミングの魔導書 vol.1 「Construct the World C++」』のpdfが送られてきました。出版前にブログで紹介とかしてくれませんか？ 僕もレビュー頼まれたんですけど、専門外なんで突っ込んだことは言えないですよね。応援してはいるんですけど。 いただいたPDFをざっと眺めてホホーと思ったんですが、なにも書かないで今日に至る。そしたら、もう [プログラミングの魔導書 まもなく予約締切] という状況でして、「皆さん早いとこ予約しましょう」と叫んでおきます。 http://longgate.co.jp/products.html 既に次のようなレビューが出ています。 プログラミングの魔導書 / Vol.1 Construct the Worl

とある論文に、パズルのネタになりそうな計算の話があったので紹介します。予備知識は特に要りませんが、けっこう難しい。 小学校で最初に習う計算は足し算です。しばらくして掛け算を習います。整数の掛け算、例えば 3×4 は、足し算の繰り返しとして導入することもできます。3×4 := 3 + 3 + 3 + 3 。 掛け算を先に習って、掛け算をベースに足し算を定義するような学習コースは聞いたことがありません。が、宇宙のどっかに、そんな順序で計算を教えている星があるかもしれません。我々地球人には不自然ですが、掛け算をもとに足し算を定義することは出来るようです。 実数の集合に対して、足し算を忘れてしまい、掛け算だけを考えます。掛け算の法則は全部使えます。具体的に書けば： (a×b)×c = a×(b×c) a×b = b×a a×1 = a a≠0 ならば、a×a' = 1 となるa'（aの逆数）が存在

一昨日の日曜日、映画「アバター」を観てきました。ほんとに「観たのか」というと、、、、 3D版「アバター」を観たいなーとは思っていたのですが、なんとなく行く機会がないままに「このまま見逃してしまうのかなー」と思っていたのです。が、長男が「観たい」と言い出したので「よし、行こう」となったのです。直前になって次男も「僕も行きたい」というので連れて行くことに。映画館は有楽町マリオンの「TOHOシネマズ 日劇」。 長男はともかく次男は、字幕の長大な映画（予告とか含めれば3時間くらい）で退屈してしまうのじゃないか、という心配はありました。始まってみると、二人とも面白そうに見ているので一安心。僕自身もけっこう入り込んで3D映像を楽しんでいたのですが、エラいことに。 黄色い巨大なブルドーザーが森を破壊して侵入してくるシーンで、次男が「頭が痛い、気持ち悪い」と言い出したのです。とりあえず外に連れ出してソファ

http://d.hatena.ne.jp/m-hiyama/20100225#c1267490716 ： 何人かがご指摘なさっているように「郡司さんは真剣なんだ／真面目なんだ」を否定する気は全然ありません（そうなんだろうと思っています）。であるなら、どうしてデタラメを書くんでしょうか？ デタラメという表現方法でしか真意を語れないのでしょうか？ -- 僕はそんなことはないと思います。痒いところに手が届かないような語り口でも、デタラメよりは効率的なコミュニケーション方法はあるはず。 以前、bonotakeさんもおっしゃっていた事ですが、「それで誰が幸せになるのか？」です。郡司さんになんらかの「真意」があるにしても、晦渋で難解、デタラメな用語法・推論では「真意」の理解者を減らすだけだろうし、「こけおどしの装飾」との評価もいたしかたないでしょう。 と、なんか「親切な忠告」風なことを書いてしまいま

もう十数年も前のことです。ある人と何度か話す機会があって、僕は彼の知識と見識に感服しました。彼は技術職ではなかったのですが、ソフトウェアに関連する仕事をしていました。ソフトウェアやIT業界に対する評価、批判、賛辞、予測などを色々と述べるのですが、ほとんどが的確な意見に思えたのです。 しばらくして、彼は技術職に移って、僕と仕事で関わることになりました。すると、えーと、ありていに言えば、使いものにならない技術者でした。はなしっぷりは相変わらずですが、言ってる事とやってる事（つうか出来る事）が余りにも違うので、もうウンザリ。結局彼は、また非技術系の仕事に変わりましたけどね。 最初に何度か話したとき、口だけの彼を見抜けなかった僕が愚かでした。彼は日経ナントカとかそういうタグイの雑誌の非常に熱心な読者だったんですね。仕事で必要と考えて精読していたのか、趣味的に好きだったのかわかりませんが。それを話の

id:paellaさんの、「クロージャとラムダ式は同義だ、と主張してみる」へのブックマーク・コメント： http://b.hatena.ne.jp/paella/20090702#bookmark-14323863 paellaさんはウケようとして書いたんじゃないだろうけど、僕は大笑いしてしまいましたよ。 誰か「今、shiroさんはここにいます」なるWebサービスをつくってもらえないだろうか。できればWEB API付きで。

だいぶ前に、クロージャ（閉包）って言葉の意味がわからないと書いたことがあります（「クロージャ、それなに？」）。最近また「クロージャ」って言葉を聞いたのですが、やっぱり何を意味しているのかわかんなくて（詮索する余裕もなくて）落ち着かない気分になりました。これはどうも精神衛生上よくない。 「クロージャ」と「ラムダ式」はまったく同義に扱ってもいいんじゃないのかな。例えばラムダ式 λx.(a*x + b) があるとき、自由変数a, bを具体化するための環境（変数束縛）をラムダ式と一緒にした (λx.(a*x + b), {a : 2, b : 1}) が古典的な意味のクロージャでしょ、たぶん。letを使えば、(let a = 2 b = 1; λx.(a*x + b)) みたく書けるけど、これも結局 (λa.λb.(λx.(a*x + b)))(2)(1) だから1個のラムダ式ですよね。 「クロー

Ruby言語ってご存知ですか？ インタプリタを開始すると、次のようなバナーが出るようです（動かしたことないけど）。 + `The Ruby Interpreter' Copyright 1993 Graham Hutton graham@cs.chalmers.se + ソースコードは、こんな宣言で始まるようです。 type prog = PRIM prim + SWAP + FORK + SEQ prog prog + PAR prog prog + INV prog type prim = AND + NOT type network == (List node # wire # wire) type node == (wire # prim # wire) type wire = NAME Int + TUPLE (List wire) んで、なんかトランスレーションの定義が並んだり

子供の行動（文字通りの幼稚な行動）や、ある分野の初心者が犯す間違いパターンをみていると、人間の能力や傾向性に対し何らかの示唆を得られたりします。稚拙な行動というのは、たいてい「自然さ」を持っていて、自然だからこそ多くの人が同じパターンに陥るのでしょう。そのパターンが具合が悪いものなら矯正したほうがいいでしょうが、矯正には人為的／意図的（あるいは意志的）トレーニングが必要です。 ウチの子供達の話 長男が小さいときオバアチャンと電話で話していて、目の前のテレビにロボットが出てくると「ほらっ、いまロボットがでてきたでしょ、あのロボットはね…」とか説明を始めてオバアチャンを困惑させていました。次男が今より小さいとき、夢のなかにおにいちゃん（長男）が出てきたらしく、朝起きると「おにいちゃん、夢のなかであんときさー …」とオシャベリをはじめました -- 自分とおにいちゃんは同じ夢を共有していると思って

なんらかの分野の初心者、なんらかの技量に習熟してない人、そういう人は全然ワカットランな状態にあるわけです。でも、わかっていないのが問題かというと、それは事実ではあっても、特に問題ではないですよね。だって、まだよくわかってない人を「初心者」とか呼ぶんだから、定義上当然にワカットランわけです。 僕が問題だと感じること、困ったもんだと思うことは、ワカットランの反対、つまり、ワカッテシマウことです。ほんとに分かってしまえば、ベテランやエキスパートの域に達したってことですが、初心者／未習熟なのにワカッテシマウのがちょっと困るのです。 僕自身もよくあることだから、自戒も込めて言うのですが、ワカットラン状態のときって、早とちりや誤解から「ナールホド、ソウカ！」とバカな納得をしてしまうことがあるんですよね。実は全然トンチンカンなんだけど。そういう軽率な了解・納得を後で思い起こすとスッゲー恥ずかしい。 たま

たまたま目にした論文に面白いことが書いてありました。 随分と昔（1976年）のことらしいのですが、福井県福井市中藤＜なかふじ＞小学校の先生が、「図形の周囲の長さから面積は求められないし、面積から周囲の長さも求められない」ことを子供達に納得してもらうために、次のような宿題を出したんだそうです。 次の図の「S」と書かれた四角は正方形のタイルです。このタイルの一辺の長さを単位として測ることにして； 図形(a)の周囲の長さは16、面積は16です。たまたま長さも面積も16でしたが、これで法則性があると早とちりしてはいけません。(b)から(e)までの周囲の長さと面積も求めてみなさい。 驚くべきことに、先生の意図に反して、とある子供が“周囲の長さと面積の関係”を発見してしまったというのです。 この子の発見は、その前年（1975年）出版の論文集（University of Tokyo Press）に公表さ

「CPS（継続渡し方式）変換をJavaScriptで説明してみるべ、ナーニ、たいしたことねーべよ」で、説明用の疑似構文として、JavaScriptに“型パラメータと総称”を入れたものを使ったのですが、型パラメータと総称の構文って、けっこうむずかしいですね。必ずしもJavaScriptに限らず、既存言語にもこだわらず、型パラメータと総称の構文について考えてみます。 いくつかの言葉 String, Integerなど型の名前（型定数）、X, Yのような不定な型を表す名前（型変数）、List, Pairなどの型構成子を含む記号表現をtype expressionというのだけど、直訳すると型式＜かた・しき＞。「型式」じゃ、みんな「けいしき」って読んじゃうだろうから、型表現にします。 型構成子と総称型とパラメータ付き型は、（区別する人もいるかもしれませんが）同義語です。与えられた型構成子（プリミティ

『安原製作所回顧録』（asin:4777909263）という文庫本を買ったけど、1ページも読まずになくした。あー、立ち読みした分が1ページくらいあったかな。

オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な

11月に入ると街はクリスマス一色、って、それ、リードタイム取り過ぎだろうよ。 それはともかく、表題の「彼」はウチの長男です。小学生、しかも低学年とは呼べない年齢ですが、今年もサンタさんのプレゼントを楽しみにしてます。 ウチの長男も、5歳くらいのとき、サンタさんの存在を疑ったようです。その理由はまーありきたりで： ウチには煙突なんてないのに、どこから入るの？ 世界中には子供がいっぱいいるのに、一晩で配り終わるの？ 僕（子供）が欲しいものがなんでわかるの？ 当然の疑問だし、これで「サンタさんなんて、いないんだ」と思ってもしょうがないだろうと、僕（父親）も思っていました。 ところが、クリスマスに近いある日、クロネコヤマトのお兄さんが（たぶん冗談半分で）「クリスマスの夜はサンタさんの手伝いをしなくちゃいけないから忙しいんだ」と言ったのです。長男はこの言葉は信じたようです。そして、「なぜ一晩で配り終

「ほとんど忘れた、Makefile」 にて： Makefileなんてもう何年も書いたことがないぞ。ウーン、だめだ、忘れている。 「忘れている」ってよりは、僕の知識じゃ古すぎて、改めて勉強しないとダメでした*1。 なにしろ、makeだけじゃ機能が貧弱なんで、cpp（Cプリプロセッサ）やm4（マクロプロセッサ）と組み合わせて使っていた頃しか知らんからね（古すぎ！）。今じゃGNU Makeを（使おうと思えば）どこでも使えるから、GNU Makeを習えばそれでいいじゃないかな。僕は、Windows上のMSYS（MinGW - Minimal SYStem）でGNU Makeを動かしました。 というわけで、GNU Makeの手習いをしたからメモしておきます。以下、名前がMakefileじゃなくても、GNU Makeへの指示を書いたファイルは何でもMakefileと呼びます。 [追記]id:paell