Inemuri nezumi diary(2009-05-29)
_ ふつうでない Haskell の学び方：なぜ「遅延する」関数型言語は重要か John Hughes の書いた "Why Functional Programming Matters" という、とても魅力的な文章があります(邦訳は nobsun がしてくださいました 『なぜ関数プログラミングは重要か』)。 この文書のなかで、 John は「遅延評価」がプログラムのモジュール化に貢献することを述べています。また、アルゴリズムを遅延的に書くことで実行効率があがることもあるということを指摘しています。 ところで、一方でこういう有名なプログラミングに関するジョーク(にしては、とても気合が入っている)をご存知の方もいることでしょう : "The Evolution of a Haskell Programmer", Fritz Ruehr, Willamette University,2001-0
Inemuri nezumi diary(2009-05-03)
いけがみを召喚するには、出現予定を参考にしてください。三週間前までにメールをくだされば、日程を追加するなどしてスケジュールに組み込むことができるかもしれません。勉強会や個人的な会合、中途採用面接などに応じます。 _ Haskell のまなびかた(2009-05-03版) わたしがはじめて Haskell の処理系を触ったのは 2004 年の春ですから、もうかれこれ 5 年の歳月がたったことになります。はやいものだなあ。当時に比べて書籍もサイトも充実してきたので、学びやすくなったとは思います。 しかし、GHC がデファクトスタンダードになりましたが、GHC の変化が著しいこと、GHC が *nix 以外のプラットフォーム(つまり Windows や MacOSX など)でバグが多いこと、ライブラリが爆発的に増えた一方でその依存性を解決する方法がまだ確立していないことなど、現在でも Haske
Inemuri nezumi diary(2009-01-19)
_ 論文ファイブが書けない言い訳(skipはご自由に) 職場でも居室でも論文は読むのだが、分量が違いすぎる。職場で読むほうが圧倒的に多いのである。一日あたりをいうと、少ないときは０本（ここは笑う場面です）、多いときはこれは例外的でちょうど７０本読んだ。 ７０ってのはおかしすぎで、実際読んだだけで一日を終えた。これは、詳しくはいえないが、「対象についていけがみがよくわかっていない論文」の査読を依頼されたときである。しかし、著者の主張の解決策は理解できたし、私が詳細に確かめるのも悪くはないかと感じたのだった。そこで、編集者に「私、その対象については、門外漢ですが、査読にあたって最大の努力はしますよ、それで不都合があれば査読者を下ろしてください」というようなやりとりがなされたあとで、査読した（実際、差読者は複数いて、対象の専門の方も査読をなさるということだった）。 で、査読論文の1次参考文献、2
Inemuri nezumi diary(2008-04-15)
_ RSpec にますます期待する 私は Gerald M. Weinberg （通称 jerry）の著作が大好きである。 ワインバーグは、1956 年からソフトウエアコンサルタントをやっているというから、私からみたら大先輩にあたる人である。彼の文体はアメリカ人らしいジョークにあふれており、挿絵もぶったまげたものが多いので読んでいて楽しい。中でも『ライト、ついてますかー問題発見の人間学』は傑作である。この本は、タイトルにもあるように「問題」に関する本である。この本の挿絵はサイコーである。特に、「目をつぶって両足でピョン」は名文である（「問題」について深く考察する前に、「自分の知っている方法で問題を解こうとしてしまう心理」を指す）。 『ライトついてますか』は、コンピュータに限らず、あらゆる生活の知恵を生み出すと思う。私の母は生真面目で素直に考え込んでしまう性格なので、この本をプレゼントした。
Inemuri nezumi diary(2008-02-11) - ログを眺めて過ごす時間を減らす
_ ログを眺めて過ごす時間を減らす LaTeX でも、ghc でも、configure でも、ぼーっとログを眺めている時間が長いような気がする。webcam と GNU screen のログキャプチャで私のとある一日の様子を見てみたら、やっぱりそうだった。しかも、長い時間かけた結果、なんか通らないところが見付かると嬉しい。ビョーキなわけである。 これではいかんなー、という気がした。 21世紀たる今や flymake on Emacs (or flyspell) で、ほとんどの問題は 書いた瞬間 に解決してしまっているので、バグを探す目的でログを見つめる必要はあまりない。だから、ログは勝手に background でだらだら流れてくださってよい。計算機が定期的に私の振舞いを監視すべきで、成功や失敗に計算機が気がついたら、計算機が私に連絡をよこすべきだ。私が計算機を監視しているのは、まるで逆で
すばらしいソフトウエアを作るためには Inemuri nezumi diary(2008-04-03)
_ エイプリルフールに乗り遅れた ふぬんが。去年の4/1にやった四月馬鹿と、その後の一連のエントリの評判がよかったので2月から準備して、3月は日記も(ほとんど)書かずに脇目もふらずに準備していたのだが。風呂敷を広げすぎたようだ。 でもおかげで、自分のやりたいことが明確になったことは感謝している。今後もほそぼそと続けていれば、来年には大バカぶりをお見せすることができるだろう。それでいいのか、という思いもあるが。 _ 坤(坤為地) 坤、元亨。利牝馬之貞。君子有攸往、先迷、後得生。利西南得朋、東北喪朋。安貞吉。 彖曰、至哉坤元、萬物資生。乃順承生。坤厚載物、徳合无彊。含弘光大、品物咸亨。牝馬地類、行地无彊。柔順利貞、君子攸行。先迷失道、後順得常。西南得朋、乃与類行。東北喪朋、乃終有慶。安貞之吉、應地无彊。 象曰、地勢坤。君子以厚徳載物。 『易経上経』、「坤」より一部抜粋。 八卦の中で、いまのお気
Purely testing Inemuri nezumi diary(2008-03-14) - Purely testing
_ Purely testing Type-driven testing in Haskell (Simon Peyton Jones)より。 Simon の主張はいつもすばらしいのだけど、この発表に関しては Summary に首をかしげる人もいるかもしれない(わたしもその一人): Over the next 10 years, the software battleground will be the control of effects To succeed, we must shift programming perspective from imperative-by-default to functional-by-default A concrete example: testing Functional programs are far easier to test A fu
ランダムテスト(あるいはFuzz testing) Inemuri nezumi diary(2007-05-20)
_ ランダムテスト(あるいはFuzz testing) は、実は数学の予想を確かめるための超高級なテクニックだということを改めて認識した。こいつは poor man's auto theorem prover だ（ある意味）。計算できないようなホモロジーとかカテゴリーとかでも、やりようはあると思う（しかし、具体的に例を出せと言われても専門家ではないのでわからん、儂と議論が必要）。ともかく、計算できるものはすべてTestableなわけで、predicate を書けばただちに 100 回計算し、反例を探しまわる。 import Test.QuickCheck prop_Pythagoras :: Int -> Int -> Int -> Property prop_Pythagoras x y z = (x > 0) && (y > 0) && (z > 0) ==> not $ (x *
Inemuri nezumi diary(2007-07-12)
_ Simply Easy! We present an implementation in Haskell of a dependently-typed lambda calculus that can be used as the core of a programming language. We show that a dependently-typed lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as an implementation of the simply typed lambda calculus, which we emphasize by discussi
仕様に基づいたテストスイーツを書く - Inemuri nezumi diary(2007-08-22)
_ 独りで始める Concrete and Specific Programming(CSP) エクストリーム・プログラミング(XPとして知られている)は、ビジネス側と開発側の両者が共通の達成可能なゴールに集中するための、ビジネス及びソフトウェア開発の規律である。 Kent Beck [XPエクストリームプログラミング実行計画(The XP Series), Kent Beck and Martin Fowler, Foreword by Tom DeMarco 序言より引用] このエントリでは、開発側の夢を実現するためのプログラミング技術 Concrete and Specific Programming を提唱します。 趣味としてのプログラミングは、ビジネスとは無関係です。それは、人生に与えられた有限の時間の使い道として、あなたが選んだ選択肢です。なぜ、プログラミングを趣味とするのか、
Inemuri nezumi diary(2007-08-23)
_ 独りで始める Concrete and Specific Programming (CSP) 実践 昨日のエントリから引き続いて。設計とテストスイーツを先に書き、実装を後に書く Concrete and Specific Programming を実際に行ってみます。ただ、私も人に教えた経験がないものですから、何を対象にすればいいものやら、わかりません。 そこで、プログラマの誰もが馴染んでいる単純な「データ構造とアルゴリズム」から具体例を取りたいと思います。 _ 具体例その1. Stack 一つ目の具体例としてスタックを取り上げます。 まず、夢メモを書きます。 Stack 夢メモ 日付:2007-08-23 作るもの: スタック(メソッドはnew, pop, pushのみ)。 どのように作るのか: 読者層に配慮して Ruby で。 Ruby についてくる Array を一つインスタンス
Inemuri nezumi diary(2008-01-03) : Ruby on Rails の注文の多い料理店に入ってしまった話
_ Ming/Ruby 0.1.9 has been shipped 去年のクリスマスに Pawel Karwowski からありがたいメールが来て、Pawel がメンテナに加わってくれました。0.1.8 が 155 KB, 0.1.9 が 1.72 MB です。どんだけがんばってくれたか、Pawel には感謝でいっぱいです。 僕自身は Ming/Ruby に愛想をつかしています。今後は Pawel とその後の仲間たちにおまかせしようと思っています。ChangeLog 読んだら "Kazuki" さんが重要な仕事をしてくださったみたいで、 Kazuki さんにも感謝しています。って Kazuki さんって誰? もともと Ming の Ruby ラッパを作ろうと思ったのは、博士後期課程の研究がうまくいかなかったときの逃避行動でした。当時、SWF は出来たてほやほやのテクノロジで将来を感じさせ
いまさらTDDを見直す - Inemuri nezumi diary(2007-07-25)
_ いまさらTDDを見直す いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。 この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。 型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。 つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。 反論もありそうなことを敢えて言うが、私自身、テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inemuri nezumi diary(2009-02-07) - 『まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」を聞いてないんだけど、どんなコードを見せていたのだろうか？』
http://madscientist.jp/~ikegami/diary/20080514.html
バグがでないのは良い知らせなのか Inemuri nezumi diary(2008-03-08)
http://madscientist.jp/~ikegami/diary/20070427.html
Inemuri nezumi diary(2007-09-17)
http://madscientist.jp/~ikegami/diary/20070617.html