僕は、人生のかなりの時間と労力と情熱を文書処理に費やしました。なので、文書処理のことを書いたり話したりしたことはあります。ですが、文書処理の実際のプロジェクトやソフトウェアの話をしたことはありません。守秘義務の問題もありますし、仮に守秘義務に引っかからなくても進行中のプロジェクトについて口にすることはありません。 しかしながら、10年20年も昔の話なら、もはや誰にも迷惑はかからないし、気にする人もいないでしょう。技術的なアイディアで具体性があるものは特許になっているし、抽象的一般的な方法論は、むしろパブリックにすべきものでしょう。 僕がそのテの話をしなかった一番の理由はメンドクサイからです。そして、懐旧談に意味があるとは思えないからです。ごく最近、ふとしたキッカケから、個人的体験を縷々述べることに意味はないが、10年20年前に考えたりやったりしたことを書き残しておくことはまんざら無駄でもな

たいていのプログラミング言語が、「関数」、「メソッド」、「手続き」などと呼ばれる言語構成要素を持っています。ここ最近のエントリー内で僕は、それらをひっくるめて（少し低水準な観点から）「サブルーチン」と呼びました。 このサブルーチン概念に関していえば、どの言語も大差ない印象を持ちます。いくつかの引数をもらって何かして1つの値を返しますよね。（値を返さないこともあるけど、ありゃ、暗黙に特定の値を返していると見てさしつかない。） なんで引数はn個なのに、戻り値は1個なんでしょう？ 多値関数をサポートしている言語もあるけど（例：Common Lisp）、なんかオマケみたいな扱い。言語の中核的仕様として多値を採用している例を僕は知りません（あったら、教えて）。 それはコンピュータのせいでしょうか 「プログラマの常識関連」の文脈で言及した、スタックやレジスタが原因かもしれません。 普通（“普通”の解釈

バートランド・メイヤー（Bertrand Meyer）先生は、とにかく偉大です。局所的には、無理筋な例え話や強引な主張で僕らを笑わしてくれるのですが、全体としては実にまったく正しいことを言っています。 メイヤー先生の主張のなかでも、僕がもっとも影響を受けて、はてしなく役立っているのは「Command-Query分離の原則」です。オブジェクトやシステムのインターフェイス＆実装を「CommandとQueryに分けろよ」という提案。Commandは値を持たず、副作用（つうか、主作用だけど）だけを持ちます。Queryは副作用を持たず値だけを返します。 Commandとは何であるか、Queryとは何であるか、副作用を持つ／持たないとは何であるか -- これらの概念は、日常直感に頼るだけではなくて、正確に定義することができます。 Queryが副作用を持たないことから、同じQueryを二度発行すると、同

（直前の投稿の続き） …、んん、待てよ。 コメントアウトせざるを得ない、やむにやまれぬ事情ってのは、「ブラウザが要素内容のテキストを表示してしまう」ってことですよね。（追記：日記のコメントも見てください。）そもそも、未知要素のタグだけ無視してテキストを平然と表示するというブラウザの動作がトンデモナイのだけど、、、って言ってもしょうがないから止めよう。 で、内容テキストを属性にしてしまうなら、そもそもコメントアウトしなくていいのではないか、と。もう一度繰り返しますが、僕はそもそもがコメントアウト反対派なのです、囲み要素案は「ホントにどうにもならないなら、しょうがないから最後の一工夫」ということですから。 ここで少し一般論をしておきます。子要素<foo>text here</foo>を親要素の属性foo="text here"に“巻き上げる”ことはよく使われるし、それでことが済むなら、十分合理

naoyaさんの「そのページが誰のものなのかを示す識別子を埋め込む仕様を考えています」に対する僕の反応の趣旨は、「HTML（XML）コメント内に意味のある情報を記述する」という選択肢は良くない、ということです。PIは「まだしもマシ」と引き合いに出しただけです（特に推奨はしない）。 その後いろいろあって結局、「続々 Hatena ID Auto-Discovery」の最後において、TrackBackTechnical Specificationのコメントアウトに関するくだりを引用した後で： "This is not a perfect solution, but it works as a temporary fix." だそう。これをよしとするかどうか、ってとこですね とのこと。また、コメント案がぁー、、、 僕はそれを“よしとしない”わけだけど、現実的な事情からやむにやまれぬ場合でももう一

言い訳から始めます。この記事を（途中まででも）読んだ人は、次のように言いたくなるでしょう。 『理論から学ぶデータベース実践入門』は良い本なのか悪い本なのか、いったいどっちなんだよ?! この本は間違いや説明不足があり、誤読されやすい表現も多く、その点では残念な本です。しかし、面白いアイディア、するどい観察も含まれていて、行間を補い深読みすれば、多くの示唆を得られる本でもあります。 よって、「良い／悪い」の二択では答えられません。良い点と悪い点の両方を、できるだけ客観的に記述するしかないのです。それをした結果、長い記事となりました。 内容： ことの発端： zhanponさんの批判 奥野本擁護と奥野本批判 僕の擁護・批判の方針 zhanponさんの指摘の再検討 1. 論理的な矛盾とデータの不整合を混同している 2. 命題論理の限界についての説明がおかしい 3. 古典論理の定義を間違えている 4.

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

だいぶ前に書いた「プログラムの算術的計算法」と「プログラムの算術的計算法 (続き＆完結）」において、非決定性の選択と非決定性の繰り返しについて述べました。これらを非決定性述語により実現してみましょう。 コイン・トスとサイコロ博打で非決定性を実現 構文 choose A or B end は、「AかBのどちらかが実行されるが、どっちが実行されるかはわからない」という意味です。これは、次のようにコードでシミュレートできるでしょう。 if (coin()) { A; } else { B; } ここで、coin()が非決定性の述語で、コインを投げて表ならtrue、裏ならfalseを返す関数です。 構文 repeat A end は、「Aを何回か繰り返すが、何回繰り返すかはわからない」という意味です。こちらは次のように書けるでしょう。 var n = dice(); for (var i = 0;