アメリカには(キリスト教国全般か？)、12月になるとアドベントカレンダーというものを 用意して、毎日めくっては(宗教的に)インスパイアされるという習慣があるのだが、 これはそのRuby版。
毎日新しいリンクが登場するので、 めくってみるのが楽しい。
(XML Schemaではなく)RELAX NGを使おう、という勝利宣言。 数多くのアプリケーションで実際に使われているだけでなく、 規格という点からもISO/IEC 19757, Part 2に含まれたRELAX NGに劣るところはない、 そうだ。
私自身はXMLの事情について詳しくはないが、 少なくともボヘミアンと貴族の闘争で とうとうボヘミアンが勝ったということは感慨深い。
ERBの別実装Erubisの紹介。って、こいつCで実装されてる erubyより速いってことになってるんだけど。 なんでそんなに高速なんだろうか。ソースを見てもすぐにはわからない。
入手は gem install erubis で完了する。 楽になったものである。
B000CFWN6C
教会。良い集会であった。
神権会でクリスマスの伝統と文化について急遽話す機会があったんだけど、 ちょっと面白かったので、ここでも紹介。
ちなみに画像は岡本監督の『B000CFWN6C』。 名作と言われているが、残念ながら未見。
*1 さらに余談だが、カーネル・サンダース人形も日本発
開催が発表。今度はDave Thomasがゲストだ。
「2007 年の Ruby が見える・2007 年の Ruby に会える」がテーマなんだそうだ。
「2007年のRuby」ねえ。どんななんだろう。 個人的には相変わらずまったりと進みたいのだが、 周囲がそれを許さないとかあるのかな。
もう、何と言ったらいいのか。
さすがのUnicodeにも「うしのあゆみがおそい」とか、 絶対含まれないに違いない。いくらなんでも。 どんなにコードポイント空間がスカスカでも。
そういえば、RubyConfでTim Brayからもらった 『Unicode 5.0』まだ読んでないなあ。
追記
酒井 政裕さんから「「うしのあゆみがおそい」はU+3E2Aとしてすでに含まれている」との指摘が。Unicodeおそるべし。やっぱそのうち全部載るのかな。
えーと、物書きにあるまじきこと、と言われそうですが、 私、「年末進行」なるもののこと、すっかり失念しておりました。
正直、普段の月よりもずいぶん早く原稿の催促を受けて、 少々パニクっております。しかも、先月のうちに考えていたテーマについて、 いざ書こうと思ったら、全然筆が進まない、という。
悩んだ揚げ句、当初考えていたのとはまったく違ったテーマになった。 今月は「バージョン管理」。RCSとかCVSとかSubversionとかgitとかの話。 ここ数ヶ月Rails周辺について話してきたけど、 正直、ちょっと飽きてきたので。まだ、Rails本体の話になってないのに。
我々が子供のころには、コンピュータ(「マイコン」と呼ばれていた)は、 まだなにもできない存在で、私と同世代は、 その上でBASICでASCIIキャラクタを動かして 「ゲームのようなもの」を作ることでプログラミングを学んできたと思う。
しかし、今はそんなことはできない。コンピュータはチープなものではなくなり、 プログラミングの対象ではなく、道具に成り下がってしまった。 私の子供はコンピュータのユーザではあるがプログラマではない。 プリインストールされているソフトウェアが提供してくれている処理を使うことはできても、 コンピュータをコントロールすることはできないし、新しい可能性を切り開くこともできない。
が、リンク先のエントリの
ということはつまり、今チープな作品に出会える場を探すとすると、 技術的な制約があるなど何らかの理由で 「へぼくても許される感」が残っているところにこそ、 チープ教育の素地があるのかな、と思います。
今の学生は、作品を作ることにおいて、 「無意味なポジティブさ」を何から学ぶのでしょうか。 携帯電話の制限された環境の中でちっちゃいゲームを作るのもいい。 ブログも文章作品のチープ教育に一役買っているような気がします。 YouTube や iMovie や携帯についたビデオカメラは、 映像作品のチープ教育を手助けする可能性を秘めています。 チープ教育の芽は、探せばまだいたるところにありそうです。
というのは、希望が持てた。 チープ教育の「場」の提供。これはプログラミング教育における新しい視点かも。 知ってる人にとっては「とっくにわかってるよ」ってことかもしれないけど。
進まない。本当は今日が〆切なんだが、終わらなかった。 明日にはなんとか。
明日の発表のためにスライド書き。 ちょっと遅いだろうと言う気もする。
東京へ移動。 某企業との合同懇親会。楽しかった。
RubyConfの時に受けたインタビューがポッドキャストとして公開。 恥ずかしい。
Lispから見た「スクリプト言語」への苦言(？)。 だいぶ感情的になっておられます。
で、ですね、興味深いんで、ちょっと分析してみたい*1。
まず、どうやらこの方(えーと、KURODAさんですね)をもっとも怒らせているのは どうやら私らしい。というのも、
スクリプト言語ってのがあります。つづりが P や R で始まるあれです。
色々調べてみると、スクリプト言語の連中というのは、 何かといえば Lisp を引合いに出すのが常套になっているようです。
Lisp の不幸の1つに、
Lisp を使わない奴に限って Lisp について語りたがるというのがあるんですが、今回もう1つ加わったのは、
Lisp を知らない奴に限って Lisp を他のもの、なかでも自分の自慰行為の結果と比べたがる
っておっしゃっているが、
という条件に一番合致するのは、私しか思いつかない。
いや、怒らせるつもりはなかったんだけどなあ。しゃれですよ、しゃれ。
まず、第一に私はLispを知らないわけではない。 もちろん、職業的にCommon Lispでプログラムしたことがあるわけでないから、 第一線の方と比較すればまだまだのは当然だが、 Lispについて語る資格がないほど知らないわけではないと思う。
いや、ないのかな。思想や歴史の概要ならともかく、 その歴史を体験したわけでもないし、 Common Lispの仕様のすべてを把握しているわけじゃないし。 今日もCommon LispでSymbolに対して適用可能な操作のリストを見つけようとして 四苦八苦したもんな。
「(Common) Lispについて精通した人でないとLispを語る資格がない」っていうことなのかもしれないが、 そうだとすると、まあ、ずいぶんと敷居の高い言語であるなあとは思う。
私のどの発言がどんな「トンデモ」に感じられたかは、 ここではわからないが、私自身はいつもLispという言語に対して 「リスペクト」しているつもりである。 仮に少々揶揄することはあるにしても、それは親しみを込めた発言のはずだ。
私のLispに関する発言は、基本的には以下に分類される。
最初のものは、つまり、「Lispのこんなところがすばらしい」ということだ。 ほめているわけだから、非難されるいわれはない。 あるいは「お前なんかから言われたくはない」ってのはあるかもしれないけど。
次のところは、要するに「Lispのあるところは(ある種のスクリプト言語には)不要だ」 ということだ。これは 「Lisp の良いとこを取ろうと思ったら最低 ANSI にあるものは全部入れとかないといけない」という発言と対立しているから、KURODAさんとは意見を異にしている。
もちろん、これは「Lispの良いとこ」の定義によるわけだが、 KURODAさんの場合にはその定義は明確である。「最低ANSIにあるものは全部入れとかないといけない」という発言からは「Lispの良さとはCommon Lispであることと同値である」ことが引き出せる。疑問の余地はない。
おそらくKURODAさんにとってはそうなのであろう。そこは否定しない。
しかし、おそらく不幸なことに、すべての人がKURODAさんに賛成するかと言うと そうではなさそうだ。しかも、より不幸なことに、 KURODAさんに賛成する感性を持つ人は、業界を見まわす限り、かなり少数派のようだ。
そのような少数派の人の持つ自意識を端的に表現した引用があった。
(Common) Lisp has been the language from which inferior people picked good ideas when they could not handle the full language. -- Erik Naggum
(Common) Lispは、真の言語を取り扱えない劣った人々がアイディアを取り込んでくる言語である
その通り。 我々、「劣った人々」はLispで実験され実証された優れたアイディアを 長年言語に取り込んできた。Lispは言語機能のテストベッドとして非常に優れている。
しかし、先鋭的なLispな人にとって計算外なことは、 業界の人間の大多数がいわゆる「劣った人間」で、 Common Lispには堪えられない、あるいは必要としていない、 という「事実」だ。
そして、私を含む大多数の「普通の人々」は、 Lispがいくら優れた言語でも、Lisp以外の「劣った言語」のユーザを 「劣った人々」と公言するような「Lisp選民」とのお付き合いには 抵抗がある。
今までLispという言語について語ったことはあったけれども、 LispコミュニティやLispユーザの精神性について言及したことはなかった(と思う)。 しかし、今回のことで「Lispが広まらないのには括弧以外の理由があるのかもね」と 強く感じた次第である。
参考: comp.lang.lisp: how I lost my faith
Erann Gatが、 Googleに移ってLispへの「信仰」を失い、Pythonに移行したという話。 「Lispじゃなきゃ」というのが思いこみであったとの告白。
あと、KURODAさんは「言語仕様を小さくまとめてライブラリで言語をリッチにしていこう」という考えを「残念ながらこれは端的に間違ってます」と簡単に断言しておられるが、 もしかしたら、これも同様に「思いこみ」から来る結論かもしれない。 Common Lispの著者の一人でもあるGuy SteeleのFortressは、 まさにそのアイディアを具現化しようとしてるのだから。
いや、KURODAさんがglsよりも正しい可能性は否定できないけど。
追記
「ある言語のユーザーの中に、自分にとって不快な言動をする人がいる」ということを言語自体や言語のユーザー全体をけなす理由にするのは反感の元」という指摘が。
また、こういう指摘も
言語Xのユーザーは、特に有名なユーザーは、同じ言語Xのユーザーから言語Xを使わないことを理由になじられたりはしません。だから「言語Xを使わないことをなじる言語Xのユーザー」がいないと感じてしまうんでしょうか。
まあ、もっともである。が、少々補足したい。
まず、誤解されないために、私が以下のように思っていることを明記したい
私自身はKURODAさんの選民意識は理解できるし、 さほど不快でもない。論理がおかしいとは思うけど。 おまけにこれでますます「普通の人々」がLispから離れちゃうんじゃないかと危惧するけど。
さて、Ruby厨についてであるが、 そういう人がいるという話は聞いている。 まさに上記の理由により私はあまりお目にかかったことはないけど、 存在は認識している。
しかし、少なくともその多くは選民意識によるものではない。 っていうか、Lispのようなある意味特殊なポジションにいる言語と違って、 大衆に受け入れられやすい言語のひとつである(しかも、類似ポジションの言語が複数ある) Rubyに対して「選民意識」を感じたとしたら、 それは単なる無知から来るものであろう。
*1 なんてことすると、ますます怒らせちゃうかも。
講演。CTCさんといえばシステムインテグレータとしては 中堅以上、大手と言っても良いと思うレベルだと思うのだが、 相当Rubyについて真剣に考えていただいている。
CTC 執行役員 ITエンジニアリング室 室長 鈴木 誠治氏
非常によくリサーチしてあって、私の過去の発言からの引用なども あったりして、本気度を感じられた。っていうか、 だいぶかぶってしまった。正直、なめてました。すいません。
株式会社ネットワーク応用通信研究所 代表取締役 井上 浩
うちの社長。途中、RadRailsを使って、名刺管理アプリケーションヲ作るデモを 行ったのだが、実質2分で完了した。「説明がなければ1分で出来る」そうだ。 まあ、何度も同じデモをしているせいもあるが、 おそらく彼は「日本で一番速くWebアプリを作れる男」の称号が得られるかもしれない。 意味があるかどうかはわからないけど。
株式会社ネットワーク応用通信研究所 特別研究員 まつもと ゆきひろ
「ここまで来ました」という話。 どっちかっていうと「社会の変化と動的言語の台頭」がメインテーマで、 1.9の話はほんの数枚。
●パネリスト
稚内北星学園大学 客員教授/要求開発アライアンス 理事 細川 努 氏
TIS株式会社/日本XPユーザグループ 会長 倉貫 義人 氏
「Drecom Award on Rails」大賞受賞者 メタデータ株式会社 大場 寧子 氏
CTC ソリューションエンジニアリング技術部 基盤技術課 井澤 信悦
●モデレータ ：
コモンズ・メディア 代表 星 暁雄 氏
すばらしかった。これまでパネルと言うと、 自分自身がパネリストのものを含めて盛り上がらず退屈なものが多かったのだが これは情報は豊富だし、啓発されるし。
特に私自身はJavaな経験がないので、当て推量で話をしているJavaとの比較を 実際の経験をもとにした話として聞けたのはありがたい。 また、倉貫さんから聞いた「Railsの良さは、立ち上げの速さよりも、変化への対応の速さ」という点は、予想はしていたものの、非常に興味深かった。
また、「Rubyができる人を集めるのが大変なので、小規模なものはRuby、大規模なものはJava」という話は良く聞く(し、私もそう思っていた)のだが、大場さんの「(少なくとも自分の経験がある6人くらいまでなら)改めてRubyを教えても元が取れる」という意見は予想していなかった。彼女はすでに現在かかわっているプロジェクトのほとんどすべてをRubyでやっているそうだ。今年になってからRubyを始めたはずなのに。
その後、懇親会。たくさんの人にあいさつさせてもらい、 名刺交換もたくさんした。あまりいっぺんに大勢の人にあったものだから、 一人一人顔を覚えていられなかったのが残念だ。 次お会いした時に失礼なことを言っても許してください。
で、帰りの飛行機のために、会場を後にし、羽田空港まで急いだのだが、 思ったよりも京急が遅くて、空港に着いたのが出発10分前だった。 息が切れるほど走って、カウンターのお姉さんにお願いしたのだが 「今、ゲートが閉まりました」とのこと。がーん。
しかたがないので、近くのホテルにチェックイン。 1泊の予定だったのに家族に申し訳ない。
が、なんとか今日、暇を見つけて完成させました。
とはいえ、
内容的に浅い。
「とりあえずこんなのがあります」というので終始している。
その割に分量が多い。
説明したのはRCS, CVS, Subversion, svk, git, stgくらいなのだが(既に多い)、 これにstg向け自作スクリプトのリストなんかも載せたもんだから 普段より相当増えた。もしかしたら10ページ以上になるかも。 まずい。
編集の方には迷惑かけるなあ。
米子への第一便で帰る。もう疲れちゃったよ。
最近までブックマークにはishinao.netのMM/Memoを使っていたんだが、 新体制への移行が本格化したらしいとのことで、 使えないことが多くなってきた。
del.icio.usも試してみたが、いまいちピンとこない。 やっぱ、リモートはダメだということで、 前から細々と使っていたローカルにインストールしたcalkiを 本格的に使うことにする。
しかし、いくつか気に入らない点があるのでハックする。
calkiはRubyで実装してあるので、ハックは簡単...と言いたいところだが、 Ajax部分はJavaScriptなのである。この言語は、とっつきやすいが たまに予想しない動作をする。ま、慣れてないせいだろうな。 そんなに悪い言語ではないと思う。
Rubiniusの作者、Evan Phoenixのインタビュー。
「MatzのインタプリタもYARVも複雑すぎ。もっとシンプルなものを作る」とのこと。
ま、あれらが複雑なのは過去のしがらみがあるのもあるし、 Ruby自身が複雑なせいもある。 プロトタイプの時点でシンプルで高速だからと言って、 実用レベルまで進んでも、その良い性質を保てるかどうかはまだわからない。 期待しつつ観察することにしよう。
ま、YARVにしても、Rubiniusにしても、JRubyやRubyCLRにしても、 より優れたRuby実装が登場するのは歓迎だ。
そうすれば、私はデザインに専念できる。
いや、それも淋しいけど。
ところで、EvanはPeepCode Screencastsから、 $1,000の寄付を受けたようだ。ちょうど12月はEvanに仕事がないから、 Rubiniusに専念できるように、ということである。
京都の某ラジオ局から電話でインタビュー。 気になるのは、いわゆる普通の人も聞くような番組で 普段しゃべってるのと同じような内容で話して理解されるだろうか、ということ。 話した内容は編集してくださるとのことだが。
また、番組はpodcastingもされるらしい。
一時間も電話で話してたら肩凝った。
Seymour Papertといえば言語好きには「LOGOの父」として認識されていると思う。 あるいは「4624400437」の著者として。
で、そのPapertがハノイでのカンファレンスで事故に巻き込まれ、重体とのこと。 一刻も速い回復を祈る。
追記:
As of December 12 evening, he was in stable but critical condition [3] and on December 14 he opened his eyes and recognised his family.[4]
だそうだ。とりあえず、良かった。
私の古いエントリに対する反応。
僕の考えは、ＨＳＰが 「挫折率の低いプログラミング言語」 だから、です。
....
僕はＨＳＰのメリットを以下のように考えているのですが、
- フリーウェアである
- セットアップが簡単
- ウィンドウ、画像の操作が簡単
- 文法が単純で習得が容易
- 自作ＥＸＥの配布が可能
これらはゲーム製作という点から見ると、とても魅力的な要素なんですよね。
...
結局、ＨＳＰユーザーにとっては、『言語仕様の正しさ』よりも、『目的達成の容易さ』の方が重要なのではないでしょうか？
理解はできる。要するに、ほとんどのユーザにとって言語の優劣は関係ないという、ことなのだろう。
まあ、「正しい言語」とか存在しないんだけど、 それでも「良い言語」と「そうでない言語」はあると思う。 しかし、「そうでない言語」であっても 当面の目的を果たすのに十分であれば、ユーザを引きつけられるということか。
局所最適化の結果でもあるかもしれない。
しかし、長らく古典的なBASICは駆逐されたような気がしていたのだが、 さまざまな形で生き延びているようだ。 COBOL同様、言語はしぶとい。
BASICは滅びぬ、何度でも蘇るさ！
集会終了後、米子でデボーショナルの衛星中継があるというので 参加しに行った。
クリスマスソングやクリスマスにちなむお話など、 クリスマスらしい気持ちを感じることができた。 今年も他の人にいい気持ちになってもらえるようなことを なにか一つでもしたいものだなあ。
なにがいいかなあ。
先週金曜日に行ったプレス発表が記事になっている。
「私はJavaではWebアプリケーションが書けないが、Ruby on Railsなら書ける。 この生産性の違いは無限大だ」と言ったとか。 もちろん、ネタなので真面目に反論してはいけない。
CELFの上田さんが、コミュニティ運営に苦心した、という話。
Linuxの場合はすでに存在するコミュニティに参加する形になるので、 そこにある雰囲気や慣習を尊重するということが重要になるのだろう。 私は「自分のコミュニティ」を作った形になるので、そういう経験はあまりない。
後からRubyコミュニティに参加した人はどう感じてるんだろうね。
国内に検索サーバを置くのは著作権違反になる、という話。
しかし、たとえ海外にサーバを置いていても、 日本国内の人間が運営し、日本国内に在住するものに対してサービスを行っているなら 日本国内法が適用されるような気がするのは気のせいだろうか。 法律の条文を厳密に解釈するとそうなってしまうということだろうか。
なんとなくネタのような臭いもする。
延長賛成派(特に松本零士)の意見がまるっきり論理的ではないのは、 私が反対派だからだろうか。
普通、延長したいなら、延長することのメリットについて語ると思うのだが、 浪花節もどきのような話(私の夫の作品の著作権が切れるのです〜)とか、 根性論(歯を食い縛って作品を生みだして〜)とか。
苦労したことに同情しないでもないが、 それは一律７０年に伸ばす理由にはならない。 一定の要件を満たす時に延長を許すというならまだしも。
むしろ、そのような人情論が一律延長の理由になると感じられる感性が理解できない。 人情論で人類のコモンズの発展を阻害してよいのか。私にはとうていそうは思えない
まだまだ溝は深い。
WebアプリケーションフレームワークとHTTPサーバの間に入って抽象化を行う層。
Webアプリケーションフレームワークが林立するPythonの事情がきっかけになったに違いない。 が、そのような抽象化層の存在は(性能などのじゃまにならない限り)望ましいことだと思う。
「あっというまにゼロからWSGI」も参照のこと。
Rubyもこういうのがどんどん出てくるくらいユーザや開発者の層が厚くなるといいなあ。
日々進歩しているらしいJRubyの新リリース。
Railsの動作も改善され、opensslも(スクラッチから実装したものが)添付され、 性能も改善されたらしい。
そのうち抜かれちゃったらどうしよう。「気にしない」と言いつつも 本音では結構意識しているような。
判決が出た。有罪。
150万の罰金刑で済んだのを喜ぶべきか、 有罪になったのを悲しむべきか。
しかし、法律素人の観点から見るとこの判決はおかしく感じる。
著作権侵害の幇助と見なせる要件は満たしていると言えないことはないと思うので、 法廷で「Winnyは主に著作権を侵害するために開発されたソフトウェアである」との 裁定が行われて、その結果有罪であると言うなら、論理は通っている。
あるいは、技術自体に罪はなくても、金子さんが世の中に著作権侵害を蔓延させようとしていた というのであれば、有罪なのもやむなしと思う。
しかし、実際には
(Winnyは)さまざまな分野に応用可能で有意義なものであり、技術自体は価値中立的なもの
であり、
(金子被告は)著作権侵害の状態をことさら生じさせることは企図しておらず、経済的利益も得ていない
と認定している。上記の両方が成立していないにもかかわらず、 これで有罪というのでは、 「では、いったい何が悪かったの」という話になるのではないだろうか。
判決文全文を読んだら、また違う印象を持つのだろうか。
ヨットレースへのスポンサーを集める話。
オープンソースソフトウェアもこれくらい熱心にスポンサーを集めたら、 もうちょっと違う形の発展があるだろうか。
しかし、スポンサーがいなければそもそも参戦できないヨットレースと コンピュータ1台(あとできればネット回線)があれば、開発できちゃうソフトウェアとでは かける熱意が全然違うのかもね。
スポンサー探しするくらいだったらコード書いてたいし。
ITmediaに載せるということで取材を受ける。 写真のためということで、わざわざ松江まで来てくださる。
日経、朝日、と続いて最近取材が続いている。
日経ITpro, ラジオ, で今度のITmediaだ。 なんだか露出が多くて恥ずかしい。
お昼は蕎麦。鴨南蛮と割子蕎麦でおいしい思いをした。 風穴さんも満足げだ。
1月17日から19日まで、フランスのニースで開かれる ACMのプログラミング言語に関するカンファレンス。
行きたいなあ。
Wednesday, 17 January 2007
Invited Keynote: 9:00 - 10:00
Perl 6: Reconciling the Irreconcilable
Audrey TangSession 1: 10:20 - 11:20
Operational Semantics for Multi-Language Programs
Jacob Matthews and Robert Bruce FindlerSemantics of Static Pointcuts in AspectJ
Pavel Avgustinov, Elnar Hajiyev, Neil Ongkingco, Oege de Moor, Damien Sereni, Julian Tibble, Mathieu VerbaereA Typed Intermediate Language for Compiling Multiple Inheritance
Juan ChenSession 2: 11:30 - 12:30
Cork: Dynamic Memory Leak Detection for Garbage-Collected Languages
Maria Jump and Kathryn S McKinleyDynamic Heap Type Inference for Program Understanding and Debugging
Marina Polishchuk, Ben Liblit, and Chloe W. SchulzeCompositional Dynamic Test Generation
Patrice GodefroidLocality Approximation Using Time
Xipeng Shen, Jonathan Shaw, Brian Meeker, Chen DingSession 3: 14:00 - 15:15
Modular Type Classes
Derek Dreyer, Robert Harper, and Manuel M.T. ChakravartyFirst-Class Nonstandard Interpretations by Opening Closures
Jeffrey Mark Siskind and Barak A. PearlmutterPADS/ML: A Functional Data Description Language
Yitzhak Mandelbaum, Kathleen Fisher, David Walker, Mary Fernandez, and Artem GleyzerGenerative Unbinding of Names
Andrew M Pitts and Mark R ShinwellSession 4: 15:45 - 17:15
Types, Bytes, and Separation Logic
Gerwin Klein, Harvey Tuch, Michael NorrishA Very Modal Model of a Modern, Major, General Type System
Andrew W. Appel, Paul-Andre Mellies, Christopher D. Richards, Jerome VouillonContext Logic as Modal Logic: Completeness and Parametric Inexpressivity
Cristiano Calcagno, Philippa Gardner, Uri ZarfatyThursday, 18 January 2007
Invited Keynote: 9:00 - 10:00
From Implementation to Theory in Product Synthesis
Don BatorySession 5: 10:20 - 11:30
Scrap your boilerplate with XPath-like combinators
Ralf LammelLightweight Fusion by Fixed Point Promotion
Atsushi Ohori , Isao SasanoLazy Multivariate Higher-Order Forward-Mode AD
Barak A. Pearlmutter and Jeffrey Mark SiskindSession 6: 11:30 - 12:30
A Complete, Co-Inductive Syntactic Theory of Sequential Control and State
Kristian Stoevring and Soren B. LassenTowards a Mechanized Metatheory of Standard ML
Daniel K. Lee, Karl Crary, Robert HarperSession 7: 14:00 - 15:30
Logic-Flow Analysis of Higher-Order Programs
Matthew MightExtracting Queries by Static Analysis of Transparent Persistence
Ben Wiedermann and William R. CookVariance analyses from invariance analyses
Josh Berdine, Aziem Chawdhary, Byron Cook, Dino Distefano, Peter O'HearnSession 8: 16:00 - 17:30
Assessing security threats of looping constructs
Pasquale MalacariaJavaScript Instrumentation for Browser Security
Dachuan Yu, Ajay Chander, Nayeem Islam, and Igor SerikovSecure Implementations of Typed Channel Abstractions
Michele Bugliesi and Marco GiuntiFriday, 19 January 2007
Invited Keynote: 9:00 - 10:00
Advanced Programming Languages in Enterprise Software: A lambda-calculus theorist wanders into an enterprise datacenter
Chet MurthySession 9: 10:20 - 11:20
Proving That Programs Eventually Do Something Good
Byron Cook, Alexey Gotsman, Andreas Podelski, Andrey Rybalchenko, Moshe VardiProgram Verification as Probabilistic Inference
Sumit Gulwani and Nebojsa JojicSession 10: 11:30 - 12:30
Lock Allocation
Michael Emmi, Jeffrey Fischer, Ranjit Jhala, Rupak MajumdarModular Verification of a Non-Blocking Stack
Matthew Parkinson, Richard Bornat and Peter O'HearnOn the Analysis of Interacting Pushdown Systems
Vineet Kahlon and Aarti GuptaSession 11: 14:00 - 15:30
Specialization of CML message-passing primitives
John Reppy, Yingqi XiaoConditional Must Not Aliasing for Static Race Detection
Mayur Naik and Alex AikenInterprocedural Analysis of Asynchronous Programs
Ranjit Jhala, Rupak MajumdarSession 12: 16:00 - 17:30
Preferential Path Profiling: Compactly Numbering Interesting Paths
Kapil Vaswani, Aditya V. Nori, Trishul M. ChilimbiGeometry of Synthesis: A structured approach to VLSI design
Dan GhicaA Semantics-Based Approach to Malware Detection
Mila Dalla Preda, Mihai Christodorescu, Somesh Jha, Saumya Debray
しかたない、Proceedingsを待つか。いつ来るかなあ。
言語間でお互いにどう見ているかの階層。
「わかるわかる」というものもあれば、 「それは違うんじゃない」というものもある。
ところで、外から見たRubyプログラマへの印象ってのは
Rubyプログラマはどのプログラミング言語利用者よりも自分たちが上だと考えているが、 Webプログラミング言語以外が存在していることを知らないのでPerlよりも上にした。
という感じなんだろうか。実際は、私の周辺では 「Webプログラミング言語以外が存在していることを知らない」人なんてのは 少数派なんだけど。私の周辺は特異点である可能性が高いしな。
答えは「そのレベルで安心できない人はRubyを使わない方がよい」です。 だって、整数のプラスだってなんだって再定義可能なんだから。
とはいえ、滅多にないとは言え名称の重複を心配しないといけないというのも切ない。
こういう時はまず原典を参照するに限る。 改めてCLtLを参照してCommon Lispのcatchとthrowについて調べてみると、
The catch special form serves as a target for transfer of control by throw. The form tag is evaluated first to produce an object that names the catch; it may be any Lisp object.
とある。がーん、今までずっとシンボルしかダメだと思ってたよ。 任意のオブジェクトがcatch/throwできるのね。
だとすると、やり方はある。
catchに引数を省略した時にタグになるようなオブジェクトを作ってやればいいんだ。 今まではシンボルに限定していたので、今まで使われたことのないシンボルを生成する gensymのようなことをするには抵抗があったのだが(シンボルはGCされないから)、 オブジェクトでいいというのなら、とりあえず任意のオブジェクトを作って渡してやればいいのだ。
新しいAPIだとこういう使い方になる。
catch {|tag|
....
throw tag
}
で、tagは一度きりしか使われないオブジェクトだから(現在の実装は、Objectのインスタンスを渡す)、重複を気にせず使えるようになる。大域脱出させたい時には、tagのオブジェクトを引数で渡してやることになるだろう。
これで安心。
近い将来1.9にコミットしようと考えている。 でも、ささだくんに聞いたら、これってYARVだと実装が難しいんだって。 なかなか難しい問題だ。
申し込みサイトがオープンした。 私も発表することになっている。
っていうか、坂村センセの直後に話すのは、ひっじょうに抵抗があるんですけど。 分不相応っていうか、なんていうか。
姉二人は部活。 残る家族とクリスマス前の買い物。
ユーザインタフェース、特にユーザがそのツールを使ってどのように感じるかを デザインの根本原理にするという話。
Webアプリケーションに特化した話ではあるが、 そのデザイン原則はあらゆるUIデザインにつながる。
言語デザインにも有効そうだ。
Yakov Fainによる2007年の予測。
視点の違いか、かなり、つまらない未来予測である。 せっかくだから、外れてもいいから面白い予測をすればいいのに。
Common Lispのリーダーマクロを使って、Rubyにしか見えないLispプログラムを書く、 という話。
#@suck-lisp
defun fib (n)
if (< n 0)
(error "oops")
elif (= n 0)
0
elif (= n 1)
1
else
let
x <- (fib (- n 1))
y <- (fib (- n 2))
in
(+ x y)
end
end
end
defun f (lst)
(print-lst lst)
end
defun print-lst (lst)
when lst
let
x <- (car lst)
xs <- (cdr lst)
in
(print x)
(print-lst xs)
end
end
end
defun walk (dir)
let
files <- nil
dirs <- (cl-fad:list-directory dir)
in
(dolist (d dirs)
if (cl-fad:directory-exists-p d)
(setf files (append files (walk d)))
else
(push d files)
end)
files
end
end
defun print-file-list ()
(loop for e in (walk "./") do (format t "~A~&" e))
end
まあ、確かにリーダーマクロを使えばなんでもありだよね。 が、それを「良いこと」に含めるのに非常に抵抗があるのは、 私だけだろうか。
井上社長とSAABに乗って福岡へ。
空港で博多ラーメンをいただく。おいしかった。
田代IPAオープンソースセンター長、 NaCl井上社長、私の順でプレゼンを。
田代さんはIPAのオープンソースの取り組みや 行政がオープンソースに取り組む必然性などについて。
井上社長は地方におけるオープンソースへの取り組みについて。 あと、RailsPlatformの宣伝と実演。 あいかわらず見事な高速アプリケーション作成。
で、私は「Rubyのチカラ」と題して、 Rubyとその周辺について。Rubyについて知らない人もいるだろうし、 あまり突っ込んだ話は避けて、一般論で。 最近の講演とかなり内容的にはかぶるが、一応スライドは新作。
しかし、私の発表はここ数ヶ月で最長の80分(他二人は40分)。 長いぞ。聞いてる人は集中力を維持できたんだろうか。 話してる本人も途中しばらくテンション下がってたのに。
その後、交流会。 大量の名刺交換をしたが、途中で名刺を切らしてしまい、 相当失礼した。
当日のレポート(で、私が捕捉したもの)は以下に。
懇親会後、夕食をいただき(おいしかったなあ、伊勢エビ動いてたし)、 ホテルへ。
ホテルは久しぶりにネットが使えず、残念であったが、 もしかして集中して執筆や構想を練るために使えるかも、 とポジティブにとらえた...が、疲れがたまっていて、そのまま寝てしまったのだった。
色つけと補完(補完はirb/completionでもできるけど)。
method_missingとText/Levenshteinを使ったirbのスペルチェック。 これは結構便利かも。
先日の日経BP主催次世代開発フォーラムの時のインタビューが掲載された。
ちゃんとカメラマンにとってもらった写真は映りがいいぞ。実物より。
Rubyの落とし穴。
実例を見ないとわからないものもあるが、まあ、おおむね妥当であろう(ただし、6は誤解。1,2,3,4,7,8,11,12は慣れの問題。9,10,13はもうちょっと考えてみよう)。
追記
コメントにもあるように5も誤解。クラス名である定数が削除され、 サブクラスが存在せず、インスタンスがすべて回収されれば、 クラスやモジュールもGCの対象になる。 ライブラリ全体をunloadする機能はないが、ある言語の方が珍しいと思う。
9は1.9では解決されている(クラス変数は継承しない)。
10はsingleton methodはクラス変数の場所を変更しない(囲んでいるclass文だけで決まる) ことを理解すれば問題なし。慣れの問題。
13はあまり使いやすくない仕様なので、将来の1.9では変更しよう。 手元ではもう直した。
どう変更したかと言うと、以下の通り
これもeigenclass化への一歩かもしれない。
Python 3000について、抽象的な話が多くて、 具体的な実装などについて語る人はあんまりいないという話。
Pythonくらい大所帯だといろいろ大変なんだろうなあ。 Rubyでは抽象的な話をしたがる人もあまりいないから。 まあ、それは私がすき勝手できるということでもあるのだけれど。
また、Python 3000の先、Python 4000の話を始めてくれて結構、とのこと。 Python 3000が具体的になりそうになって、新たな「遠くの目標(aka 燃料)」が必要になった とも言えるかもしれない。
forkを使った並列ライブラリ。使いやすそう。
Rubyからも使えるといいのだが、Rubyの場合プロセスで空間が分断されちゃうと オブジェクトが見えないから、違う工夫が必要そうだ。 いっそスレッド(pthread)を使ってRARDSのようなAPIを提供してもらうのが 良いのだろうか。
Ruby開発もとうとうSubversionに移行した。 関係者の皆さん、お疲れさま。
SubversionはSunからもらった新しいマシンで動いている。
で、私は自作stgからのpushスクリプトをsvnを使うように変更して終わり。 改めてsvkとかを使う気にはならないなあ。
稚内北星学園大学の丸山学長を中心にした講義シリーズ。 1月に開かれる第3回には、私も参加させてもらう。
「Web2.0」というテーマだが、私の発表はそれとは関係のない「動的言語について」。
なぜ今ごろ、とも思うのだが。
で、もう一つの「なぜ」は、なぜ「独自のOSSコミュニティを作るべき」なのか。 記事を読んでもその理由はさっぱりわからない。
Kim氏は、「われわれ北東アジアの3カ国は、CE Linuxを除き、今のところOSSの生産国というよりユーザーに過ぎず、国際的なコミュニティに貢献できることも少ない」と話す。その理由のひとつは、「アジアで開発力のあるデベロッパーは1カ所に集まっておらず、力を合わせることなくばらばらに活動していることにあるのではないか」とKim氏は指摘する。そこで、北東アジア独自のコミュニティを作ってはどうかというのだ。
「アジアがOSSユーザに過ぎない」というのは分からないでもないし、 貢献が少ないので改善したいと言う気持ちも分かるが、 だからといって「1カ所に集まって、力を合わせる」ことが必要なのかなあ。
まあ、face to faceのコミュニケーションで話が進むことは多いのは認めるが、 決して必須ではないし、どうせ英語でコミュニケーションするのであれば アジア限定にする理由も見当たらない。
もうちょっとなにがしたいのか見守りたい。
先日の風穴さんによるインタビューをまとめたもの。
「ちょっと違う視点からのインタビューを行いたい」という申し出の通り、 オープンソースで仕事してる人としてまつもとが表現されている、かも。
あまり仕事をしないのに、対外的な知名度だけが上がっていったので、結果的に会社としては、このような形でしか（まつもとを）使えなかったということだったのではないかと（笑）。
は本音。いやあ、首にならなくて良かった。経営者の忍耐のおかげである。
明日のクリスマス会のための準備。ハロウィーンの時もそうだったが、 前日の準備も楽しいものだ。
スパム検出Webサービス。それなりに精度は高いらしい。
RWikiのスパム(実は私がせっせと消している)や、 ここのコメントやトラックバックのスパムに嫌気が差しているので、 こういうのを導入したいものだなあ。
Rubyの新しい入門書。中身は少ししか見てないんだけど、 比較的分かりやすい内容のように思える。英語だけど。
オンラインで読んだり、データをダウンロードするのは無料。 印刷したものはlulu(RedHatの偉い人だったBob Youngの作った出版社)から10ドルで購入できる。
今年は朗読劇をやるというので、
など、えらくIT化の進んだものとなった。 最近、教会でもコンピュータの活用が進んでいる。
クリスマス会後、娘たちはキャロリングということで、 近所の病院にクリスマスソングを歌い、プレゼントを届けに行った。
「アニメ映画「ゲド戦記」の主題歌の歌詞が萩原朔太郎の詩に酷似している」ので、 スタジオジブリが 「テルーの唄の作詞について記載される場合は『萩原朔太郎の詩、こころに着想を得て作詞されました』と表記していただくようお願いいたします」との見解を出したことの不思議。
これは私も不思議に思っていた。
いや、創作において以前の作品からインスパイヤされることは日常茶飯事で、 それに対して「そうなんですよ、感謝してます」以上のことが本当に必要か。 ましてや著作権が既に切れたものについてまで。
「松本零士の銀河鉄道999について記載される場合は「宮沢賢治の童話、銀河鉄道の夜に着想を得ております」と表記していただくようにお願いいたしします」との見解は聞いたことはないが。 しかも、銀河鉄道999の初出時に銀河鉄道の夜の著作権は切れてなかったはずだが。
追記
あるいは「大ヤマトについて記載される場合は「宇宙戦艦ヤマトに着想を得て(ry。
特にクリスマス礼拝と銘打ったわけではないのだが、 聖餐会のお話はみな熱がこもっていて、時間がオーバーした。 しかたがないので、話者の一人に特にお願いして来週に回ってもらう必要があった。 時間調整はなかなか難しいものだ。
大切な書類をうちに忘れてきたので、神権会の時間に自宅に戻る。 ちょっとうっかりがすぎるな。
集会終了後、セミナリーの補習。 主にビデオを見たり。
Rubyのような、「革新的な技術があるわけではないんだけれども、組み合わせとバランスで価値のあるソフトウェア」というのは論文にしにくい(で、結局論文書けずに単位取得退学になってしまったわけなんだけど)。
そういうのをカバーするための特集。
ソフトウェア論文は従来の研究論文と異なり，どのようなソフトウェ アについてどのような観点から論文を執筆すれば学術論文として認められるか に関して十分な社会的合意があるわけではなく，このことがソフトウェア開発 の論文化の妨げとなってきました．
本「ソフトウェア論文」特集はこの問題を打破すべく企画したものです．優れ たソフトウェア成果を積極的に論文化してご投稿いただき，編集委員会での議 論と査読・改訂のプロセスを経ることによって，「良いソフトウェア論文」に 関する合意を形成し，その具体例を実際に示すことを目標としています．
ささだくんから教えてもらって、投稿しようかなあ、と考えていたのだが、 直前になって「投稿はソフトウェア科学会会員限定」という事実に気がついてしまった。
考えてみれば、そりゃそうだよな。なんのための学会だということもない。 もうちょっと早く気がついて入会しておくべきであった。
というわけで、せっかくのチャンスを棒に振った、というお話。 ま、学位への熱もだいぶ冷めてるし、リプリント代も馬鹿にならないし、 書かないで済むならそれはそれでいいか、と思う今日このごろ。
ruby-talk経由、 1998年に私がcomp.lang.miscニュースグループにRubyを紹介した時の記事。
もうすっかり忘れてたよ。「Pythonより速い」とか書いちゃってるなあ。 当時は速かったのかなあ。
「Googleは社員を子供扱いしていることで繋ぎ止めている」という話。
ま、そういうところはあるかも。 子供扱いする余裕すらない会社もたくさんあるわけだが。
私がGoogleに行きたいと思わないのは、Googleでの自分がイメージできないから。 給料だけはだいぶ上がりそうだけど、 Rubyをフルタイムというわけにはいかなくなりそうだし、 住環境その他の条件も悪くなりそう。
夜、近所の知り合いの家にクリスマスソングを歌いに。
なんか今年心からちゃんと「メリークリスマス」と言えたのは初めてのような気がする。 が、その直後「普段からお世話になってますから」とガレのランプ(レプリカ)をいただいてしまった。海老で鯛を釣ってしまった。
ともあれ、メリークリスマス。
「インストール一切不要！ メモ帳一本でゲームが作れる開発環境(Windows用)」。
こういうのがあればHSPじゃなくてもとりあえず始められるのかなあ。
ワーキングプア問題で、一生懸命働いても生活保護を受けている人よりも 収入が低い人たちがいることに対応しようとする動き。
その動きそのものには別に反対するところではないが、
働いた賃金よりも生活保護の方が多いねじれを解消するのが狙い。生活保護の引き下げと最低賃金の水準切り上げの両方で対応する。
えーと、引き下げることで「ねじれ」は解消するかもしれないが、 「困っている人を助ける」という視点がまるまる抜け落ちているような。
それとも、なんらかの事情で「生活保護」ってのは高くなりすぎているのだろうか。
日弁連から延長反対意見。 社会的に影響力のありそうなところから反対意見が出れば、 世の中の動きも変化があるだろうか。
延長賛成派の論に合理的理由を見いだせない私としては このままなしくずしに延長されてしまうことは避けたい。
BON SAGOOLはRailsで書いてある。
「Ruby on Rails」で開発しています。なんといっても開発がすごく早いのがいいです。逆に苦労した点は、動作がすごく遅いことですね（笑）。
遅くて申し訳ない。もうすぐ速くなる、かも。
YAMLライブラリの対応は早かったRubyだが、JSONライブラリは添付される予定はない。 が、JSONもYAMLと同じくらい可能性があるフォーマットだと思うので、 個人的には標準対応したいものだなあ。
もっとも私自身がメンテできないから、誰かに名乗りをあげてもらう必要があるのだけど。
高名なCommon Lispの複雑さの二大巨頭の一つ(もうひとつはformat)の loopマクロの使い方いろいろ。
こんなの複雑すぎて使えないと考えるべきか、 あるいは、なんでもできてすばらしいと考えるべきか。
とりあえず冗談抜きで「なんでもできそう」ではある。
Basecamp風味のソフトウェアプロジェクト管理ツール。Rails製。 Tracに似てると言えば似てるかもしれない。
私自身はTracも使えてないので、こういうのがどれくらい便利か いまいち想像力が働かないのだけれど、 Rubyでもバグレポートやら新機能の提案やらなんやらがあちこちに分散しているのは確かなので、 そういうのを一ヶ所にまとめるワンストップソリューションにはニーズがあるのだろう とは思う。
どっかに用意するか。でも、最近Wikiには(Spamに)うんざりしてるので、 Tracじゃないものがいいなあ。
「Rubyにはclass/moduleのunloadingがない」との指摘があったので、 どれどれと調べてみた。
Javaでのclass unloadingってのは、思ったよりも複雑である。 正直、もっと簡単にできると思っていた。
詳細はリンク先を 見てもらいたいが、正直Javaのクラスローダの基本がよくわかってない私には難しかったが、 簡単にアンロード出来るようなものではないことはわかる。
一方、Rubyであるが、
状態になれば、クラスやモジュールもGCの対象になる。 ということは、クラスローダのないRubyの方がシンプルにアンロードできる ということにならないだろうか。
あるある。
たとえば、私だと、HSPやPHPに対する「悪意」を読み取られたことがある。
別にそれらの言語を憎んでたり、あるいはそれらの言語ユーザに対して 思うところがあるわけではないのだけれど。
それらの言語には「これは変だ」とか「プログラミング言語としてみると欠点がある」とは思うし、それをはっきり口にする。けど、それは(私の感覚では)事実の指摘であり、 別に悪意でも何でもないんだけどなー。
もちろん、私がRubyに対する「これは変だ」とか「ここが欠点だ」とかいう指摘に対して、悪意を読み取るつもりはない。その指摘が合理性のあるものである限り。
敬愛するLispに対する悪意まで読み取られてしまうと、それは悲しい。
某非技術系雑誌の取材。
取材したライターの方は大変困っておられた。 まず、私のやってることそのものが業界外では理解不能。 また、相変わらず「力の抜けきった」応対をするものだから。 一般人対象の取材のときはどなたも困っておられるが、 今回はひときわのようだ。
あと、仕事がひけてから家族も含めて写真撮影。 妻は今までの取材その他の中で一番緊張していたようだ。
どの雑誌に載るかは、その時まで両親に秘密にしておこう。 2月号らしい。
風穴さんのインタビュー第二回目。 実は直前まで原稿のチェックが行われていた。
周囲がまつもと氏のたぐいまれなプログラミング言語アーキテクトとしての才能に気づき、まつもとがそれに専念できるような体制が自然に形作られつつある
とあるんだけど、実際のところはどうなのかなあ。
いや、以前よりも言語設計に専念しやすくなっているのは事実なんだけど、 「たぐいまれな…才能」とかどうなんだろうね。 そういう言葉はむしろ「今まで存在しなかったものを新たに作り出す人」に向けられるべきなんじゃないかなあ。私は既存のものを「適当」に組み合わせただけだし、 あんまり新しいものを作った感じはない。
「組み合わせることも才能」と言ってくださった方もいるし、 そういう才能が存在しうることを否定はしないけど、 私の場合、どっちかっていうと才能よりも「偶然うまくいった」ってところなんじゃないかなあ。
例年、仕事納めの日には散らかった机の上の「地層」を片付けるのが 慣習になっているのだが、今年は出社するのが遅くて ほとんど作業時間が取れなかった。 で、不要そうなもの(ほぼ全部)をみんなゴミ箱に突っ込んで終わり、とする。
前田くんからグループへの「締めの言葉」を依頼される。 乾杯の音頭とか締めの挨拶とか、大の苦手なんだよね。 何を言ったらいいのかわからないし。
で、「みなさん、お疲れ様。終わり」、だけ。
苦笑される。
数学者Haskell Curryにちなんで名付けられた関数型論理型言語。 関数型の部分はHaskellに良く似ているように見える。
しかし、Curryは姓も名も言語に使われるのか、すごいな。
「JRubyの中の人」、Charles Nutterがホリデーシーズンに JRubyでやったこと、やろうとしていること。
いくつかの工夫により、場合によってはCRubyよりもJRubyが早いケースが出てきた とのこと。すばらしい。元々BignumがかかわるとJRubyの方が速かったんだけど(JavaのBignum実装が優秀だから)。
そして更なる高速化のためのメソッド呼び出しについてのアイディア募集中。
こういうの見てると、20年前のSmalltalkなどの高速化論文の再発明のような気がしないでもない。 メソッドマトリクスとかそんな論文OOPSLAで見たような気がする。 いかに疎なマトリクスを圧縮するかとか。
でも、マトリクスって動的言語とは相性悪いんだよね。
Elizabeth Wiethoffの「How to think like a computer scientist」シリーズの新作。 まだ「書きはじめたばかり」だそうだが、 すでに完成している最初の方は結構出来がよさそう。
完成が楽しみである。
松江地方は今年最初の積雪。朝目が覚めたら10cm以上積もっていた。 びっくり。確かに昨日あたりからぐっと冷え込んでいたけれども。
この雪の中、娘たちは映画を見に行くとのこと。 まあ、この辺の人たちはこれくらいの積雪、どうということはないので、 さしてトラブルもなく映画は観れたらしい。
ErlyWebはErlangにおけるRails相当。
「やるじゃないかErlang」というのが正直な印象。 いつまで待っても「Lisp on Rails」とか出てきてないものね(Lispにはそんなもの必要ない、というのはあるかもしれないけど)。
で、final words:
After reading all this, some of you may be thinking, “This is weird… I thought Erlang is some scary telcom thing, but what I'm actually seeing here is that Erlang is very simple… Heck, this stuff is even simpler than Rails. What's going on here?”
If that's what you're thinking, then you are right. Erlang *is* simpler than Ruby, and that's why ErlyWeb is naturally simpler than Rails. In fact, Erlang's simplicity is one of its most underrated aspects. Erlang's creators knew very well what they were doing when they insisted on keeping Erlang simple: complexity leads to bugs; bugs lead to downtime; and if there's one thing Erlangers hate the most, it's downtime.
...、えーと、Erlangの言語仕様がRubyよりも小さいという点と、 Erlangerがダウンタイムを毛嫌いする(好きな人はいないと思うけど...)ことには、 完全に同意するけれども、 ここで紹介されているErlyWebから「Railsよりシンプル」という印象を受ける 人はそんなにいないと思うなあ。
普通、「シンプル」っていう時には「ツールの単純さ」よりも、 「ユーザ作業の単純さ」を言うんじゃないかなあ。 ツールデザイナーはついつい「ほら、このツール。こんなにシンプルな仕組みでこんなに強力」とか 言いたくなるけど、ほとんどのユーザはそんなこと気にしないんじゃないか。
ErlyWebのできが悪いとは思わないし、 もうほんのちょっとだけツールサポートが篤くなれば Rails(とかTurboGearsとか)に匹敵するWebアプリケーションフレームワークになると思うけど、 現時点で「ほら、こんなにシンプルだろ」と言っちゃうのは 逆効果なんじゃないかなあ。
私の日記に反応がない理由について。
いや、いずれもごもっとも。
で、私が対処できることはほとんどないんだけれど、 二番目の「数日分まとめて更新される」ことだけは なんとかしたいと思う。2007年は「毎日日記更新」を目標のひとつにしよう。
昨日、「筆ぐるめ」で作った年賀状を投函。少々遅いが。
ここでフリーソフトウェアだけで完結できないのが悲しいところだ。 数年以内になんとかしたいところ。
KleetingKardとか結構いい線行ってるんだけどなあ。
オープンソースについて2006年を振り返る、という話。 Rubyのことが結構大きく取り上げられていて驚く。
そういえば、2006年はRubyがたくさんの人に届いた年であったなあ。 私自身はそれについて特別になんの活動もしていないんだけれど、 他の人たちが一生懸命頑張ってくれたおかげかな。
今年後半は私自身も露出が多くて、
は特にインパクトが大きかった。なんか何年も会ってなかった友人から電話があったり、 あちこちの親戚から「読んだよ」と言われたり。
非常に恥ずかしい一年でもあった。
RedHandedも今年を振り返る言葉を掲載している。
Lispについてのよくある誤解と、その中にあるちょっとした真実、の話。
具体的には以下の疑問への答え。
やっぱLispってネガティブな方向に誤解されやすいわ。
でも、なんでだろう？
歴史学者によると、知られているもっとも古い宗教儀式は蛇(Python)を礼拝するものだ、という話。
やっぱPythonって根強いわ。
大晦日だからといって、なにか特別な礼拝行事を行うわけではない。 数年前、元旦が日曜日だった時には普段3時間あるプログラムが1時間で終わったことがあったな。
普段通りの集会。 ただ、他の人を待ったりしてたので、 帰るのはいつもよりもずっと遅くなってしまった。
だいぶくたびれたので今日はおとなしくしてよう。