C# 2.0のyield文の解説。
ここでRubyを説明の例に出したのは、Rubyが優秀な言語であり、C#は努力によってRubyに近づくことができる……という主張を行うためではない。 Rubyは面白い言語ではあるが、本来の能力から見ると、最近の社会的な評価は過剰に高すぎるという印象がある。逆に、C#は本来の能力から見ると、社会的な評価が過剰に低すぎる感がある。筆者の漠然とした印象からいえば、個別の機能ではなく総合力で見ればRubyよりもC# 2.0の方がはるかに強力であり、実用性は高いと感じる。
この記事の作者が「本来の能力」とか、「実用性」というのを どう捉えているかに大きく依存するとは思うが、 「最近の(Rubyの)社会的な評価は過剰に高すぎる」という印象は理解できる。
が、しかし、この記事を読み進めていくと、 C#のyield文とかが、決してわかりやすくも、 使いやすくもないことが分かる(catchできないとか)。
文脈から考えると「総合力」とか「強力」というのは パフォーマンスのことだと思うが、性能はともかく純粋の言語設計の善し悪しで 見るとC#はRubyの足下にも及ばないと思う。
ま、そのぶん、効率良い実装は大変で、実装者は苦しい思いをしてるんだけど。
新しいwhyプロダクト、ShoesはGUIツールキット。 サンプルはこんな感じ。
Shoes.app do
button "Press Me" do
alert "You pressed me"
end
end
こういうAPIは好みだ。
GUI記述はコンパクトな方がよい。GUIに限らないけど。
今年のOSCONにおけるHadoopのプレゼンビデオ。
HadoopはGoogleのMap-Reduce相当の 分散コンピューティング環境。Javaで実装されている。
それそのものも興味深いソフトウェアであるが、 シークは遅いと強調している点が印象的であった。 データ量が大きくなってくると全体の挙動が小さいスケールとは 異なってくるというのは、物理と同じだ。っていうか、ディスクのシークってのは 物理的問題か。
増井さんのインタビュー。 こだわりが垣間見えて面白い。
そういえば、私は椅子や(物理的な)キーボードにはこだわらないなあ。 キー配列や使うソフトウェアには(必要以上に)こだわるのに。
IT業界のプロジェクトマネジメントが「遅れている」という点について 否定するつもりはないけれど、 それがソフトウェアが人類の経験したことない複雑さを持つことを軽視できないと思うんだけど。
連載が進むにつれ、そういう点も言及されるのかな。
明日の一便で移動するつもりだったが、
台風が近づいていて、早々に結構欠航になってしまったので、
今日のうちに移動。なんか今週は出張ばかり。
なんか今までに話したことのないテーマだったが、 これはこれで自分でも興味が持てたのでチャレンジしてみた。
オープンソースの定義やフリーソフトウェアとの関連など、 基本的なことを押さえた後は、 ネットの発達やバザールモデルの普及、開発者の意識向上などにより、 ソフトウェア開発に関して地理的な制約は少なくなってきている現状を紹介し、 その上で、「どこに住むか」ということについて改めて考察する、というような話。
また、仕事上の地理的制約がなくなる時、 地域がどのように特色を出し、開発者をひきつけるか、 それには個別のアプローチが存在するだろうというような話。
「田舎である」、「住環境がまとも」というのは島根が私に提供してくれている環境であり、 また、別の人は別の環境を選ぶだろう。真に魅力的な地域はどこか、 それはひとつのモノサシだけでは測れないだろうと思う。
なんだかまったりとRubyについて語るセッション。
ある意味「Rubyという藁をつかむ」ような島根県(失礼！)にくらべて、 横浜という「都会」の立ち位置をつかみかねる私。 あまりにも東京に近いという印象があるが、 住人にとっては東京とは違う微妙な距離があるようだ。
いや、もちろんRubyを活用した地域発展を目指すのに、 田舎だから良いとか、都会はダメとかそんなのはないんだけど。
会場のカフェですっかりおしゃべりをした後で、夕食。 もう中華街に移動してもかなりの店が閉まってしまっている。 不夜城というわけじゃないのね。
要するに「間違ってるよ」という話。
このような結果となる原因はPerlもRubyも共通で、巨大な浮動小数点数リテラルを処理するのに（内部的な有効桁数分の整数）×10nとして計算しているためです。「内部的な有効桁数分の整数」が計算途中で一度IEEE64bit浮動小数点数として保存されてしまうと仮数部の53bitでは10進17桁や18桁はカバーできず、この時点で丸められてしまうのです。丸められた結果を後から10n倍しても、本来の数を丸めた結果とは異なってしまいます。
なるほど。また、コメント欄ではshiroさんが、「How to Read Floating Point Numbers Accurately (1990)」 by William D. Clingerという論文を紹介していた。
せっかくもらった情報なんで、Rubyでもちゃんと実装したいんだが、 私がやっても(算数的素養の無さから)グダグダに してしまいそうなんで、だれか手をあげてくれるとうれしいなあ。他力本願モード。
しかし、PHPのstrtod()がこの論文をベースにしているとは驚いた。 ちょっと見直したっていうか、なんていうか。
一昔前に比べてプログラミング雑誌は減っていて、 それは(出版側にしてみれば)由々しき事態である、という話。
同じ日経BPの雑誌に連載を持つ身としては、看過できない内容である。 私が記事を書いたことのある雑誌も次々と休刊してしまい(Linux Magazine, Unix User, Opensource Magazine, 日経バイトなどなど)、影響も馬鹿にできない。
では、現在、プログラミング領域で紙の媒体に未来があるのか、と問われると、 なかなか難しい問題だ。似たような内容がWebでも入手できるからだ。 一応、私はお金をもらって書く記事と、この「にっき」のように自発的に書く記事との間では 「差別化」を行っているつもりだが、それでも、私が過去に書いた記事ががんがんWebで 公開されちゃうわけだし。悪いことではないけど。
とすると、Webでない紙の利点とは、読者にとって
くらいか。いまいちインパクトが弱いと言われてもしょうがない。
一方、記事を提供する側がウリにできる点としては
ではないだろうか。つまり、「編集」と「企画」という編集者の役割が ますます重要になる。
問題は、その編集者が生み出す違い(と、そこから生まれる価値)を 読者が理解できるか、という点だ。読者が雑誌に幾許かの価値(それこそ月に千何百円も) 見いださなければ、雑誌に未来はない。
もうどの辺がLLなんだかよく分からないけど、 言語好きが集まるイベントは希少だから、 それはそれで構わないと思う。
いや、日本でもOOPLAとかPOPLとかが開催されるようになれば、 いいのかな。でも、あっちはアカデミック色が濃すぎるしな。 発表しようにも、論文査読が通らなそう(トラウマがあるらしい)。
それはともかく、私とLLの位置関係は微妙で、 今回みたいに前日に他のイベントがあって交通費と宿泊費を負担してくれた場合には 気にしなくてすむけど、なんか私の交通費の異様な高さは このような「手弁当」の香りがするイベントには出席しにくいんだよなあ。
かといって、あんまり自分を安売りすると弾さんに怒られちゃうし。
実は地下鉄の出口を間違えて道に迷ってしまい、 和田先生の話が全然聞けなかった。これは後悔が残る。
で、今回は恒例Language Updateとパネル「オレ様言語の作り方」へ参加。
Language Updateは、むしろ他の言語の方が楽しかった。 IoとかLuaとか。多様性は善である。
で、Rubyは私とささだくんでプレゼンしたのだが、 私が思いっきりボケて、ささだくんがツッコむというスタイルにした。 Rubyくらいになると、もう言語の紹介は要らないし、 とはいえ、技術的な変化は些細なことになっちゃうし、 どうしてもウケ狙いになってしまうからだ。
のだが、実際のプレゼンは 当初の予想(期待？)ほどスムーズには行かなかった。 いかんせん8分という持ち時間が短すぎ。せめて15分欲しかった。 まあ、気まぐれな私に振り回されるささだくん、という構図がイメージできれば それで8割は成功な気がする。
が、ボケた内容のうち、一部は本気だったりする(「もしかして」機能とか)。 残りはきっと2.0だな。
「オレ様言語の作り方」は、高橋さんが司会で、 私がゲスト(解説者？)、パネラは
しかし、今思えば、解説者としての立ち位置だったら、 それを徹底すればよかった。
今のこの機能ですが、これはきっと〜の影響ですね。 いい味出してますねえ。
とか。失敗だ。
それをClassicの紹介とかに費やしてしまった。 台無しだ。ちなみに高橋さんからは、古いRubyについても いろいろ質問されて、手元にある一番古い0.49をコンパイルしてみたんだけど、 手を入れないと現在のLinuxではコンパイルできないし(古いglibcに依存してた)、 結構文法が違うし、で戸惑った。当時はまだ引数の括弧が省略できないし。
古いRubyの話は結局パネルでは使わなかったんだけどね。
あと、何人かの人に少し挨拶した後は、 くたびれていたので早々に帰ってしまった。 もうちょっといろんな人と話したかったんだけど、 残念。またの機会に。
今度私を見かけたら積極的に話しかけてくださいね。
このインタビューももう5回目か。
今度はささだくんがYARVにおける最適化について。 前回(M17N)は頑として黙ってたささだくんが、嬉々として語ってますよ。 ほんとにこういうのが好きなんだなあ。
私も嫌いじゃないけど、徹底できない。 だからMRIは遅いんだろうか。
長らくお世話になった宣教師が とうとう任期満了ということで、最後の挨拶。
まあ、長らくって言っても、全体の任期が2年なんだから、 松江では数ヶ月ってところなんだけど、 いろいろと頑張ってくれてたから、 印象が強い。
松江はZLプレースなので、 よく頑張っている宣教師が赴任してくることが多く、 大変ためになる。
帰っても、伝道中の経験や気持ちを忘れず、 適切に社会復帰してくださいませ。
Groovyの(Javaにない)演算子について。
「*.」や「.@」についてはどこまでうれしいのかよく分からないけど、 レシーバがnilならnilを返すメソッド呼び出し「?.」や、 メソッドを取り出す「.&」は、ちょっと欲しいと本気で思った。
しかし、よく考えないと「.」が前に来るのか、後に来るのか すぐにわからなくなってしまいそうだ。
LL魂のLightning Talkで発表された Ruby, Perl, Python, PHP, JavaScriptで動作する 高速テンプレートエンジン。
っていうか、DjangoやKidがそんなに遅いとは知らなかった。 ってことは、テンプレートエンジンの性能差というのが 全体のパフォーマンスに与える影響はわずかということなのだろうか。
CによるCPS (Continuation Passing Style) の実装っていうすごく面白そうな内容の論文[PDF]。 まだ読んでない。
YARVのFiberやブロックの高速化とかに使えるんだろうか。 なんとなく難しそうな気がするけど。
Lockすることなしにプロセス間通信を行うアルゴリズムについて。
アルゴリズム1,2くらいまではなにを言ってるか分かるんだけど、 コードが断片的すぎて(私の知識が限定的すぎて)、 どのくらいうれしいのか、どのくらい画期的なのか判断できなかった。
プロセス間通信のコストが下がるのであれば、 それに越したことはないのだけれど。
Pythonにおいて、マルチコアやクラスタを最大限活用しようと言う試み。
大変素晴らしい。で、将来参考にできるものがあれば ぜひ参考にさせてもらおう。
サンプルを見る限り、APIはちょっとわかりにくい気がする。 が、使い方が全然想像もつかないほどではない。
Googleの中にいれば、幸せだろうということは想像できる。 が、同時に外との断絶も発生しそうだ。
すべての人がGoogleの「中の人」になれない以上、 その幸せは人類の幸せではない。 それでいいのだろうか。
いいのか。
いや、FUDなのは分かってるんだ。 Googleにスポンサーされているオープンソースプロジェクトは沢山あるし、 Googleから公開されているものだってある。
でも、それでもなお私は自分の不安が消せない。
になるかどうか自信は無いのだが、 1.9でイテレータ系メソッドにブロックを渡さない時に返される Enumerable::Enumeratorクラスに、 外部イテレータとして使うことができるようにnextメソッドを追加した。
実装には最近YARVに追加されたFiberを利用した。 っていうか、Fiberって初めて使ったよ。 使いやすいような、使いにくいような。慣れてないせいかな。
追加したメソッドは以下の通り
また、Enumerable#zipメソッドは、以前は引数として渡されたEnumerableを to_aで配列に変換していたが、Enumeratorを外部イテレータとして使うことにした。 これで、無限列もzipの対象にできる。
あと、zipの挙動だが、今まではレシーバの要素数だけ繰返していたが、 今後は正式にレシーバと引数でもっとも少ない要素数だけ繰り返すことにした(今までも1.9ではArray#zipがそうなってた)。
これでgeneratorライブラリを使わなくても簡単に外部イテレータが使えて、 PythonやXtalに一歩近づいた。
開成高校の吉田投手は吉田くんの弟だったんだ(そんなわきゃない)。
それはともかく、誰にでも理解できる表現ができる人には あこがれちゃうなあ。いや、蛙男については必ずしも「誰にでも」とは 言えないかもしれないけど、 少なくともRubyよりは広い範囲に分かってもらえそう。
というわけで、実は蛙男商会も島根県の重要な地域資源(コンテンツ産業)と 見なされているらしいぞ。現在、蛙男さんはほとんど東京に居るみたいだけど。
データフォーマットに特化しているという点ではYAML、JSONと同じ方向性のように見える。 CSSの影響が強いので、そっち方面に慣れている人にはわかりやすいかもしれない。
＠ITのレポートが面白かった。
採用面接で「どんだけ技術が好きか」という点を集中的に確認するという仙石さん、という話。
技術が好きならば、プログラミング技術は後でいくらでも延ばせるし、 お互いに幸福な関係が築けるだろう、と。 まあ、確かにうちで生き残ってる連中も、 技術好きで日常生活をコンピュータにたとえて下らない話をするのが好きな連中が 多いものな。
今後の採用の参考にしよう。
Gemstoneといえば昔一世を風靡したOODBMS。 これがJRubyやRubiniusから使えるようになる、という話。 私はその頃ObjectStoreを使ってたけど。
待て。JavaとのコネクションでなんでもできるJRubyは分かるが Rubiniusが出てて、なんで本家Rubyが対象にならないのか。不思議。
動的型を好む人(Dynamic Typer)と静的型を好む人(Static Typer)は プログラミングの別の側面を見ているのだろう、という話。
If I understand correctly, people who prefer static type systems tend to
think in terms of structural invariants of their programs, while people who prefer dynamic type systems tend to think in terms of their programs' behavior. I am convinced this is a personal preference, nothing more, nothing less. I guess that static typers have equal problems developing in dynamically typed languages as dynamic typers have developing in statically typed languages. I don't see a problem here: If the requirements are such that a focus on static correctness is important, it's probably better to employ a static typer, whereas if the requirements are such that dynamic flexibility is more important, the job should better be done by a dynamic typer. There is nothing wrong with specialization, we don't need a grand unified theory of program development.
そう言われてみればそんな気もする。
「ぬりかべ」のあの姿と言うのは伝統的なものだと思っていたのだが、 実は水木さんの創造だったのね。実際はこんな獅子のような姿であったとは。
で、この「Ｌ・トム・ペリー コレクション」のＬ・トム・ペリーってのは、 ペリー長老のことだね、きっと。戦後、進駐軍として日本にいたって聞いてたけど、 ここまで日本通だったとは。
意外。
楽天のミーティングのため上京。
午後イチから日経コンピュータの取材。 編集長の人からいろいろと質問を受けては 答えるというスタイル。未来の話が多くて、 例によってテケトーな答えをしてしまったんだが、 きっと編集部の人がきれいにまとめてくれるに違いない。
編集者バンザイ。
写真も撮られた。カメラマンの人には「実物よりも良く写してくださいね」とお願いしたら、 快くOKしてくださった。きっと雑誌掲載時にはめちゃめちゃ修正が入っているに違いない。(笑
NDAにより中身は詳しく話せないが、 スケーラビリティをテーマに、いろいろと。 現時点ではサーベイ段階で、モノ作りにはまだかかりそうだ。 ざっくりとしたスケジュールでは9月頃には手が動かせるとよいなと思っているのだが。
その後、PFIの人たちとミーティング。
しかし、アルゴリズムネタでこんなに盛り上がるとは思わなかった。 世間的には「技術の楽天」のイメージはなくとも、 「技術好きに事欠かない楽天」というのは事実だと思う。
懇親会でも盛り上がりっぱなし。終電がなくなるまで、 アツく語っていた。
ホテルまで徒歩。近いところにしといてよかった。
ミラクルの吉岡さんによるLL魂レポート。
学校でコンパイラの作り方とかは習うけど、オレ様言語を作ってしまえというような危険思想をうえつけられるということはまあない。オトナの事情というやつで、研究職に進む人には、言語では論文とおらないよ(これが殺し文句)、企業に行く人には、言語では食えないよ(これも殺し文句)。大抵はそれであきらめるのが良い子の姿である。
それにもかかわらづ、わらわらとオレ様言語一派が勃興しているのは、やはりRubyのまつもとさんの影響に違いない。諸悪の根源はまつもとである。
えーと、諸悪の根源たるまつもとです。悪の大魔王か、私は。
とはいえ、私の影響は微々たるものであると想像する。
まず、第一に日本におけるオレ様言語率が高いかというと実はそんなことはない。 まあLL魂でパネルができる程度にはいるので、全然いないというわけではないだろうけど、 ヨーロッパやアメリカでの「オレ様言語」ぶりを見るにつけ、 むしろ世界第二の市場であるはずの日本はまだまだだと感じてしまう。
一方、日本以外のアジア諸国発のオレ様言語は ほとんど知られていない(きっとあると思うけど)ことを考えると 日本は特殊なのかもしれないなあ。
でもきっと、中国やインドの言語屋は英語圏に出ていっちゃうような気がする。 XRubyの人たちとか中国人だし。
こういう仕事の仕方も面白いなあ。
先入観無く、いろいろなやり方を学んでおこう。 実践できるかどうかはまだわからないけれど。
というイベントが9月に開催されるのだが、そこで話してほしいということで打ち合わせに渋谷。
正直、MySQLに対して悪感情はまったくないのだが、 なにぶん私自身がデータベースをまともに扱ったことがないので 固辞していたのだが、どうしてもお願いします、データベースと関係なくてもいいから、 ということで押し切られる。うーむ。
ということで、出席者の皆さん、 まつもとが変なこと言ってても石投げないでくださいね。
DBプログラミングは前職以来、それもDBMSはObjectStoreなので、 いわゆる普通のデータベースってぜんぜん使ったことないんだよね。
NaCl的にもビジネスにつながる話があるみたい。
オープンソースソフトウェアのソースコードの値段を換算するという話。 PHPのフレームワークSymfonyは700万ドルだそうだ。
で、ほかにもいくつか例が挙げられているうち、Rubyのお値段は 640万ドル、約7億5千万円。他のプロジェクトに比べるとはるかに安いが、 私の個人資産だと考えると*1、 とんでもない財産だ。
ソフトウェアが資産として課税されないことを強く望む。
*1 もちろん他にもたくさん貢献者がいるのは承知してるけど
平鍋さんとの対談4回目。
今回のテーマは柔軟性。もちろん柔軟というのは良い面と悪い面があって、 いろいろできるということはすごいことができると同時に、 チームに迷惑をかける悪いこともできるということだ。
でも、今回は良い面に注目して。
『JavaScript the definitive guide』の作者であるDavid Flanaganが Ruby 1.8とRuby 1.9の差についてまとめたもの。 良く調べている。
実は彼は現在『The Ruby Programming Languagea(仮題)』を執筆中である。 これは元々『Ruby in a Nutshell』の第二版として企画されたものだが、 結果的にまったくの新作になっている。
GNU EmacsとXEmacsは、しばしば懸念されるものの めったに起きることはないフリーソフトウェアプロジェクトのfork例。 ライセンス上、フリーソフトウェアプロジェクトのforkを強制的に止めることはできないが 協力した方が得、という話。
とはいうものの、この話の流れを読んでみるに、 forkの原因は技術的な要素よりも、 結局は人間関係とコミュニケーションが鍵であることと、 (本人は意図していないだろうけど)RMSのコミュニケーション能力は あまりほめられたものでなかろうことが読み取れる。
どこでも人間関係と言うのは難しいものだ。
はてなの伊藤さんのインタビュー。
オープンソースのコミュニティにコミットする人の中には、会社で充実した仕事ができなくてその反発からやってるという人も少なくありません。会社の中でくすぶっている人が外に出て道が開けるケースもあり、それは肯定されるべきだと思います。しかし、経営者の自分としてはそういうふうにエンジニアに思わせてしまうことが経営として失敗なので、肯定はしちゃいけないんですね。
「くすぶらせちゃいけない」というのはその通りだろう。 個人的には「積極的に外に出させる」というのをやりたい。 できてないんだけど。
NetBeansは進化中、という話。
ここで紹介されているスクリーンショットでは、
ができるようになっている。もう、「IDEがないから」という言い訳は 聞かなくてもすむのかもしれない。
Railsのおかげ(？)で、Rubyの代名詞という感じになったOpen Classだが、 ちょっと工夫すれば(annotationを使って)実現できる、という話。
Pythonのannotationってばなんでもできるよね。 おもしろいメタプログラミング機能だと思う。
それはそれとして、コメント欄では「たとえ可能でもしてはならない」というコメントが目立つ。 やはりOpen ClassはPython主義者(の多く)には耐えられないのかしら。
個人的には、この辺は言語で制限するのではなく、 「自分が何をしてるか分かってないと危険」ということだけ示して 許可したいのだけど。
PHP on Railsは不可能という話。
ActiveRecordをActiveRecordたらしめているものは、 リフレクション機能であり、それはPHPには欠けているから。 Javaにはリフレクション機能はあるんだけど、 言語的に硬いからなあ。結局はXMLなりGroovyなりを経由して 柔らかくするしかないのではないだろうか。
それはPHPでも同じか。複数言語を取り混ぜればよいという話になる。
というところで、タイムリーなMartin Fowlerの記事。
現在フレームワークを選んでいるのと同じように、何ができるかによって言語を選ぶような人たちのプロジェクトでは、複数の言語を見ることになるだろう。
そうなるかもしれない。しかし、その時、選択基準になる「何ができるか」とは「何」か。
LispでもRubyでもいい、十分に高度な抽象化能力を扱える言語であれば、 どの分野であっても、その言語の上にそれなりに有効なDSLを構築することができるはずだ。 となると、選択基準は実は「what」ではないだろう。
私の思いつくものは、以下の二つだ。
となると、JRubyやIronRuby(or Ruby.NET)のような相互運用性のある環境が より魅力的になるのかもしれない。 C言語とC Rubyはずっと以前からそういう関係を築いてきてるわけだけど。
デジカメでピンホールという発想はなかった。脱帽だ。
妻の実家へ帰省。9号線を通って島根県を横断。 途中食事したり買い物したりしたら6時間くらいかかった。
妻の実家はネットが通じないので、 しばらくネット無しの生活。 意外と気楽なもので、本を読んだりハックする時間が取れるので 良いことのような気がする。
もっとも帰ってからが恐ろしいのだが。
とても久しぶりの山口支部。 懐かしい顔も見れた。
もっともお盆というせいもあって、 「今日はいない」という人もそれなりにいて その点は残念であった。
青少年とかうちの子たちしかいなかったし。
次にくるのはいつになるかなあ。
1970年代にエジプトで発見されたグノーシス派の写本が 数奇な運命を経て世に公開されるまでを追ったドキュメンタリー。
しばらく前にネットで宣伝を見かけて、読みたいなと思ってはいたものの、 それだけのためにナショナルジオグラフィックを購読する気にもなれず 放置していたものを、先日、松江市立図書館で見つけて借りてきたのだった。
せっかく帰省中で時間があるので一気に読んだ。
で、感想だが、私としてはもうちょっとユダの福音書の中身についての 情報が欲しかったなあ、というもの。もちろん、現代において ユダの福音書がどのように扱われてきたかという点もドラマティックで 一般の読者にはそっちの方がウケるのかもしれないけど。
で、少しだけの情報から得られる内容からみると センセーショナルな宣伝文句の割にキリスト教の教義に与える影響は ほとんど(ぜんぜん)ないだろうな、と思った。
ただ、イスカリオテのユダの行為の後ろにある動機は、 正典(カノン)にはほとんど記載されていないが、 それなりにいろいろあっただろうな、とは以前から思っていたので、 信憑性はともかく「救い主の使命を達成するため」という動機は理解できる。
個人的には一番受け入れやすいのは、映画『ジーザス・クライスト・スーパースター』で 示されていた「窮地に追い込めば、自らを救うと同時にイスラエルを解放してくれるのではないか」という動機だけど。
のんびりと過ごす。 本を読んだり、デバッグしたり。
が、自分のことばかりしているわけには行かない。 家族の買い物にも付き合う。
午後は子供たちと従姉妹(妻の弟の娘たち)が遊ぶ。 ひさしぶりに見たらずいぶん成長していた。
松江に向かう。 途中買い物したりしたので、帰宅するまで6時間くらいかかった。 島根県、東西に長すぎ。
増井さんが社内で行ったRails勉強会の資料。 この手の勉強会、楽天の中でもやった方が良いなあ。 増井さんと交渉するか。
20号。ぱちぱちぱち。
しかし、私は今月めちゃめちゃ忙しくて、 連載(他言語探訪)はお休みしてます。
ごめんなさい。
商用Smalltalk処理系としてはそれなりに有名だったDolphinの開発が 中止される、という話。最大の理由は「商売にならないから」。
また、「オープンソース化してほしい」というリクエストには 「オープンソース運動は好きじゃない。 Dolphinの商業的価値を投げ棄てるくらいなら、 時の砂の中に埋もれて消えていく方がマシ」という返答が。
いずれにしても、Smalltalkは世間に受け入れられない証拠がまた一つ、 という感じか。残念だ。
しかし、Dolphinが市場からいなくなっても Smalltalkが死んでしまったわけじゃない。
たとえば、Syxは Smalltalk-80の新しい実装。頑張っているようにみえる。 ソースはまだ読んでないけど。
Smalltalk言語そのものではなく、その影響ということなら、 それは現代でも決して小さいものではない。 たとえばRubyもそうだ。RubyにはSmalltalkの影響が随所に見られる。
で、ここで紹介するSScriptはJavaScriptに対するSmalltalkの影響(文字列ベースだけど)。
実際にSScriptを使ったソースコードを見れば、ひとめでその面白さが分かるのではないだろうか。
[1, 2, 3]._collect(':x | ^x+1');
-> [2, 3, 4]
[1, 2, 3, 4]._select(':x | ^x > 2');
-> [3, 4]
[1, 2, 3]._collect(':x | ^x*2');
-> [2, 4, 6]
[1, 2, 3]._reject(':x | ^x > 1');
-> [1]
[1, 2, 3, 4]._inject_into(1, ':x :y | ^x*y');
-> 24
[1, 2, 3, 4]._inject_into(0, ':x :y | ^x+y');
-> 10
[1, 10, 7, 8]._sort(':x :y | ^x < y');
-> [1, 7, 8, 10]
[1, 2, 3]._sort(':x :y | ^x > y');
-> [3, 2, 1]
var a= {
x: 1,
y: 'howdy'
};
var b= {
x: 4,
y: 'howdy'
};
var c= {
x: 2,
y: 'howdy'
};
[a, b, c]._sort(':w :z | ^w.x < z.x');
-> [a, c, b]
var counter= 0;
'^counter < 5'.whileTrue('counter._print(); counter++;');
(5)._to_do(10, ':counter | counter._print();')
(0 > 1)._ifTrue(' "howdy partners!"._print(); ');
return (this <= 2)._ifTrue_ifFalse('^1', '^('+this+' -1).fibo(); + ('+this+' - 2).fibo();');
えーと、なんてクレージーなんでしょう(ほめてる)。 APIリファレンスも参照のこと。
Nuは「Rubyでない言語」。 どういうことかっていうと、Objective-CとRubyは思想的にはかなり近い線だが、 実装はまるで違う。文字列も配列もなにもかも。 で、Objective-Cのデータ構造を使ったRubyのような(しかも、Cのように効率が良く、 Lispの強力さも併せ持つ)言語なのだそうだ。
ただ、まだこれ以上の情報はないので、続報を楽しみに待ちたい。
追記: 続報
実態がよくわからない言語、その2。
Otterは「いつまでも公開されないArcはきっとこういう言語なんじゃないかな」というような言語。 だが、現時点ではホームページには なんの情報もない。
このLisp NYCに出席した人からの情報がほしいな。
追記: 過去ログが公開されているらしい。
ActiveRecordの欠点はテキストベースのカラムタイプの扱いと、 属性ハッシュにデータベースからのテキストとシリアライズされたオブジェクトが混じること、だとか。
私には判断できないが、欠点の指摘や改善の提案は非常に健全だと思う。
個人的にはRailsの最大の欠点は、 「自己中心性」にあると思う。 つまり、Railsはかなりすごい勢いでRubyそのものを変化させてしまうので、 他のライブラリなりフレームワークなりが似たようなことをしようとすると すぐに衝突してしまう。まあ、同じようなことをみんながやると大抵悲惨なことになるので、 基礎クラスを書き換えるような「黒魔術」はActiveSupportに任せておけ、 というのも理解できる態度ではあるが。
ま、このRailsの欠点はそのままRubyの弱点のせいでもあるわけで、 Ruby 2.0では、この辺になんとか対処したい。
Erlangのメッセージリングの例題をRubyで実装したもの、だと思うのだが、 ソースコードを読んでもいまいちなにをやっているのかわからない。
誰か解説してくれると嬉しいなあ。
というわけで、Rubyアソシエーションの重要な活動として 認定試験を始めます。
理事長として(この肩書き重いなあ)、尋ねられそうなことにはあらかじめ答えておく。
というわけで、期待しすぎず待っててほしい。 ネタでの受験は歓迎するが、採用面接で効果を発揮する約束はできない。
そんなにインパクトがあったかなあ。 まあ、Java陣営にも意識されるようになったというのは 自分でもすごいことだと思うけど。
まあ、言語なんてのは切磋琢磨できてナンボだと思うので、 良いことだと思う。
JRubyの中の人、Charles Nutterのブログから。 NetBeansのRuby対応はすごいぞ、という話。
先日紹介した属性対応もそうだけど、 やっぱちゃんとした投資が行われれば、 技術的に少々難しくてもなんとかなっちゃうもんなんだねぇ。
Javaスクリプトの9つの落とし穴。 実際には、ほとんどのものはある特定の実装(特に名は秘す)の落とし穴のような 気がするけど、2番のthisについてだけはよくわからない。 JavaScript言語の最大の欠点のような気がする。
高速なハッシュ関数を評価したBob Jenkinsのページには、FNV hashがもっとも高速であると書いてあるが、最近のCPU(AMD Athron XP)ではBob Jenkins hashの方が高速だし、もっと高速なハッシュ関数もある、という話。
Ruby 1.9は現在FNV hashを採用してるんだけど、 このSuperFastHash(なんて大胆な名前)に変えちゃおうかなあ。
YARVはPythonやPerlよりも高速であるという話。 我々にとってはもはや当たり前の事実だが、 海外でもそういう認識が広まりつつある。
前にも変えたような気がするけど、YARVの最大のウリは、 「Rubyは(マイクロベンチマークで)遅い」という風評を払拭することによる マーケティング効果だと思う。
YARVプロジェクトも含め、いろいろと発表する会。
今回はそのプロジェクトが無駄でないことを示すためか、 プロジェクト成果の社会的インパクトについても紹介するのだとか。
で、うち(NaCl)や永和さんや楽天から 「エンタープライズRuby」な未来について語ってもらうんだそうだ。 もちろん、YARVそのものについても、ささだくん自身による解説がある。
時間の都合がつけば私も行きたかった。
「D vs Ruby」を 受けて、「そんな比較、意味無いじゃん」とばかりに書かれたパロディ。
言語の比較って難しいよね、特に客観的になろうとすると。
たとえば、「Ruby's Named Parameter Passing, and its Sometimes Confusing Use in Rails」のコメント欄では、
Aesthetics aside, you should select Python over Ruby if you care about Unicode (and therefore XML) or need native threads or want more performance. Those are the indisputable ones. The disputable ones are: you want to build a large application from parts without worrying about name clashes OR you need to make maintenance easier by having a consistent, language-enforced coding style OR you need to reduce the cost of training new programmers by using a language with a simpler syntax.
Now what I've been looking for for a year is the reverse statement. Aesthetics aside, you should choose Ruby over Python if .... where the answer does not involve Rails. Rails aside, what problems are intrinsically a better fit for Ruby than for Python? Is it really just "tastes great, less filling?"
とある。「Rubyは遅いし、Unicodeサポートはプアだし、 美的感覚を除いてはPythonを選ばない理由はないんじゃない？」のだそうだ。
私でさえはっきり言語化できないけど、PythonとRubyとじゃ利用感が全然違い、 それは単なる「Aesthetics」である(ので重要ではない)という感覚は あまりに感覚を重要視していない気がする。
もっとも、美観についてもPythonを選ぶ人が多いのは、 それはそれで納得してるんだけど。
マルチコアの未来。
マルチコアになったらそれを活用するには特別なOSやソフトウェアが必要になる という論調が多いが、よく考えてみれば、普段我々はある特定のプロセスにCPUパワーを 全部預けるようなコンピュータの使い方はしていない。
日常的に複数のプログラムが動作しているのが当たり前なんだから、 コアの増加についてそんなに心配することはないのではないか、という話。
そういえば、我々が一番問題にしがちなWeb系では元々サーバープロセスがいっぱい いるんだからあまり難しいことを考えなくてもマルチコアは十分に活用できるよね。 スレッドだの、軽量プロセスだの、あまり心配しなくてもいいのかもしれない。
今日はビショップが実家に帰られたので不在である。 まあ、先週は私たちが不在だったので、交代ということなのだが。 で、順番からいって顧問の私が管理などをすることに。
聖餐会での話、日曜学校の教師、それに今週はたまたま神権会の教師まで 仰せつかって忙しかったのだが、 いちばん疲れたのはやはり集会の管理をすることだ。
娘にも「お父さん、緊張してた？」と尋ねられた。 確かにそうとう緊張してたんだけど、 端から見て分かるほどだったかな。どうも全部顔に出ちゃうタイプらしい。
なんだか、とてもくたびれた。
えーと、要するに「いびつなことはいいことだ」ということなのかな？
私が日本を代表してるような表現は正直こっぱずかしいのだが、 「Windowsのことがわからないおっさん」という表現は 実はあんまりはずれてないかも。
ただし、わからないのは主にWindowsプログラミングであって、 日常的な操作や設定くらいは(人より回り道することはあっても)なんとかできる。
でも、ワードやエクセルやパワーポイントは今でも使えない。
Javaは明示的に宣言してない例外がハンドルされていないと コンパイル時にエラーになる。これはこれで素晴らしい機能だけど、 結果としてプログラムコードを繁雑にしてしまう(ことがある)。
元々は以下のようにシンプルなコードだったのだが、
String readData(File file) {
BufferedReader in = new BufferedReader(new FileReader(file));
String data = in.readLine();
in.close();
return data;
}
コンパイルできるためには例外を捕捉しなければならない。
String readData(File file, String default_value) {
String data;
BufferedReader in = null;
try {
in = new BufferedReader(new FileReader(file));
data = in.readLine();
in.close();
}
catch(FileNotFoundException e) {
return default_value;
}
return data;
}
しかし、これでもまだダメだ。close()がIOExceptionを出すかもしれない。 で、最終版はこんな感じ。
String readData(File file, String default_value) {
String data = default_value;
BufferedReader in = null;
try {
in = new BufferedReader(new FileReader(file));
data = in.readLine();
}
catch(IOException e) {}
finally {
if (in != null) {
try {
in.close();
}
catch(IOException e) {}
}
}
return data;
}
例外の捕捉漏れを検出して、正しいコードを書かせようという言語機能が むしろコードを繁雑にして、「元々やりたいこと」を例外処理に埋没させてしまう危険性がある。 また、こんなに繁雑だとそもそも例外なんか使いたくない(Cみたいにエラーコードにしちゃう) という気にさせられてしまうんじゃないかなあ。それだとむしろ退化を促進しちゃう。
まあ、こんなことするくらいなら上にIOExceptionを投げちゃえばいいのかもしれないけど。
一方、Rubyではこうなる。
def read_data(file)
begin
file.readline
ensure
file.close
end
end
でも、これは例外をそのままスルーしてるんで、 上記のJavaコード(最終版)と比較するのは反則かもしれない。
Dolphon開発終了にインスパイアされたエントリふたたび。 「Smalltalkが生産性に欠ける」というのは、 またずいぶん大胆なエントリタイトルだと思う。
が、ここでは「言語としてははるかに劣るJavaが、 その言語としてのなじみやすさや クラスライブラリの蓄積によって 『普通のプログラマ』の生産性を向上させることにより、 Smalltalkエキスパートよりも低コストでのソフトウェア開発を可能にした」という ことが重視されている。
数少ない「選ばれた人」の生産性がいくら高くても、 圧倒的に多い「普通の人」の(安い)生産性にはかなわない、 という視点か。
完全に同意はしないものの、「普通の人に優しい」というのは、 Rubyが唯一LispやSmalltalkに勝っている点だけに、 個人的にはアリな視点だと思う。
Stallmanの欠点は他人の感情を理解しない点だと思う、という話。
StallmanはEmacsのある機能を修正することを、 EmacsメンテナのStefan Monnierに依頼した。 しかし、Stefanには娘が産まれたばかりなので、時間が取れなかった。
Stallmanの返答は
I am sorry to hear it. Unless someone else can figure these things out, I guess the release has to wait until you have time.
それは残念だ。ほかの誰かが対処できなければリリースは延期しなければならないな。
他の人がStepanに「おめでとう」を言う中、Stallmanは追い打ちをかけた。
It doesn't take special talents to reproduce -- even plants can do it. On the other hand, contributing to a program like Emacs takes real skill. That is really something to be proud of.
It helps more people, too.
子孫を作るってのには大した才能は要らない。植物でさえできることだ。 それに比べてEmacsのようなプログラムに貢献するのは誇るに足る本当の才能だ。
もっとたくさんの人を助けることになるしね。
いや、そりゃそうなんだけど、ねぇ。
車の警告ランプが点滅する。 すぐに点滅は止まってしまったのだが、 不安なのでディーラーに持ち込む。
現時点では警告が出てない旨を伝えると、 「コンピュータに記録が残ってると思いますよ」とのことであった。 ちゃんとログが記録されているのか。
で、調べてもらうとミッションがおかしくなっているらしい。 コンピュータがそれを補うべく一生懸命頑張っていたのだとか。
悲しい知らせとしては、修理に20万近くかかること。 いい値段だなあ。 もう５年も乗っているし、新しい車に乗り換えるべきか。 また中古車かな。
乗り換えるとすると、 結婚してからこっち、スズキ→三菱→マツダと乗り換えてきたので、 今度はなににしよう。7人乗り以上のミニバンがいいかと思うのだが。
Perl6入門編。
リリースが近づくにつれどんどん現実的になったPython 3000と比較して、 Perl6はとんがったまんま。資料を読むだけでも一苦労だ。 今回の資料もちょっとしか読めてない。
Ruby開発者がScalaについて知っておくべき5つのこと。
Erlangから使える分散データベースMnesiaについて。
この説明からは技術的詳細はよく分からないのだけど、 高速・分散・トランザクション不要などの謳い文句は魅力的に聞こえる。
ちゃんと論文読もうかしら。
出たよ、64コアCPU。
バスの配置を工夫したり L3キャッシュは近隣のCPUのL2キャッシュを利用する(んだよね)ような ことにより、性能のボトルネックをできるだけ排除するようにして マルチコア化を押し進めたものらしい。
あと、５年くらいしたらこの程度のCPUが一般的になっている、かもしれない。
より詳しい情報が「Massively multicore processor runs Linux」にある。各コア別OSを動かすことができるのかあ。
Sony内部でのソフトウェア技術者向け講演会。 演者は私と青木淳さん。
組み込みについてはあまり知識がないので、 私の知っている範囲の現状についていろいろと話をしたのだが、 通じたのだろうか不安である。
テレビやデジカメに組み込まれるソフトウェア開発にRubyを使え、 というわけには行かないだろうし。そもそも、ソフトウェア開発の自由度は相当低そう。
しかし、ハードウェア性能は向上してるし、 組み込み分野でもLinuxの普及が進んでいるようだから、 Rubyとは言わないまでも、もうちょっと動的で高級な言語を適用するというのは 十分アリな選択になりつつあるのではないだろうか。
上手に実装すればトータルのプログラムサイズを減らすことも可能だと思うし。
組み込み向け動的言語というのはまだ研究されていない面白い分野かもしれない。
講演料とは別に、デジカメ(DSC-T20)をいただいた。 びっくりするととともに、さすがソニーだと感心する。 今日の出席者の中にはこれを作った人もいたかもしれない(少なくともBRAVIAを作った人はいた)。
手ぶれ防止から顔認識まではやりの機能をきちんと抑えている810万画素デジカメ。 ただ、モード選択の簡単さや設定項目の多さ(だけ)は今まで使ってたEX-Z600の方が上かな。 高感度モードへの切り替えがちょっと難しかったり、起動時のロゴが消せなかったり。
いずれにしてもありがたい。
最近、MicrosoftはOSIにライセンス承認を求めたが、 OSIのボードメンバーでもあるGoogleのOSS担当Chris DiBonaが Microsoftを非難して承認に反対した、という話。
が、shared source全般はともかく、今回承認が求められた permissive licenseはOSDを満たしているので、 承認しない理由はないと思う。
ライセンスそのものと直接関係ないMicrosoftの行為を 「オープンソース的でない」として非難するのであれば、 れっきとしたオープンソースソフトウェア(たとえばLinux)を改造して 使っていても、再配布していないと言う理由で公開していないGoogleも 同じくらい「オープンソース的でない」のではないか、と。
Pythonのバグトラッカーがsourceforgeからroundupへ変更になる、という話。 PHP(sourceforge)からPerl(roundup)へ移行というのが興味深い。
Rubyのトラッカーも変更したいんだけど、 なんかピンと来るのがないんだよねえ。
追記:
roundupはPythonでした。確認を怠りました。 すみません。
ScalaはJVM上の言語としてJavaのライブラリにアクセスできるという「メリット」があるが、 ScalaとJavaでは言語としての性質がずいぶん違うので、Javaのライブラリが使えてしまう ということは実は言語を歪めてしまうのではないか、という話。
まあ、言語の魅力はライブラリに依存する部分は大きいわけで 言わんとすることはわからないでもない。 聞くところによるとScalaは結構がんばっているみたいだけど。
JRubyにも同じことが言える。あまりJavaライブラリへのアクセス性を強調していると いつのまにかRubyの良さを失ってしまうような。JRubyはRuby由来のライブラリが厚いから あまり心配することはないかな。
審査会。今年も力作が集まっていた。 以下は今年の印象。
「今ごろ？」感があるが、けっこう詳しいレポート。 九州は燃えている。
朝起きて新聞読んでたら、こんな記事が。 全然予告無しで。この辺、油断ならないのが「しまねクオリティ」。 もちろん、事前に断りはなし。 この「会議」のメンバに身内はいないし。
しかし、考えてみたら、このメンバに身内がいたり、 事前に相談があったりしたら「お手盛り」疑惑が持ち上がってしまうので それでよいのだ、ということに思い至った。
いずれにしても、知事が変わって松江市だけでなく島根県も IT振興策について行動を起こす気になったということと、 そのネタとしてRubyが採用されたということは確かのようだ。
県によると、「ソフト系ＩＴ産業誘致検討部会」が、世界的に注目されているＲｕｂｙの開発者、まつもとゆきひろさんが松江市在住であることなどから、島根がＲｕｂｙのメッカとなるよう、人材育成センターや研究機関を創設し、国内外から技術者や研究者が集まる仕組みのモデル案を紹介した。
委員からは、「今後二年間でＲｕｂｙを島根県が生かせるかが鍵」とする意見や「具体的なシステムを早急につくるべきだ」とした指摘が出た。
今後二年ですか。人材育成センターや研究機関ですか。 なんだかよくわかりませんが、頑張ります。
少なくとも島根からは引っ越しできなそうな気配が伝わりました(笑。
そういえば、先日米子の実家に帰った時、 米子の商工会議所では、
「松江はRubyってのを掲げていろいろやってるらしい」
「Rubyを作ったまつもとってのは米子出身らしい」
「うーん、松江はうまいことやったなあ」
などという会話があったとかなかったとかいう話を聞いてきた。
さて、問題です。米子市はどういうアクションをとるのがよいでしょうか。
正解は...、よくわかんないや。
diといってもdependency injectionとかではない。
Pythonにはid()という関数があって、オブジェクトの固有値(ID)を取り出すことができる。 ちょうどRubyでいうobject_idメソッドに相当する。
で、今回紹介されているこれは、 その逆を行うdiというライブラリ。di(id)とすると元のオブジェクトを取り出すことができる、 というもの。こっちはObjectSpace._id2ref()に相当する。
が、GCのこととかを考えているわけではないし、純粋にアドレスを整数化したidから 元のアドレスを取り出しているだけ(らしい)ので、 たとえばオブジェクトが解放されて、元々のメモリ領域がOSに返されちゃってたり、 あるいはオブジェクト以外のものに再利用されてたりしたら、 当然、面倒なことが起きる。最悪の場合にはSEGVになる。
とはいえ、idからオブジェクトが取り出せたりすると、デバッグ目的などには便利なこともあるかもしれない。作者も主要な目的はデバッグで他の目的には使えないだろうと書いている。
それなのに、コメント欄は荒れている。
「危険だ」、「こんなライブラリリリースするなんて信じられない」、「weakrefを使えばいいじゃないか」など否定的。そんなに目くじら立てなくても。
Rubiniusの最新ベンチマーク。表の見方がいまいちよくわからないんだけど、 どうもRuby1.8に決して負けない、と言ってるらしい。 ものによってはずっと速いぞ、ということだ。
まあ、ベンチマークを実行できる時点で、相当実装レベルが上がってるんだろうね。 今度はYARV(1.9)と対決していただきたい。
1.9に最近追加されたFiberについて。
とはいえ、これもまだ仕様が揺れているのだった。 今からなくなるってことはないだろうけど、 たとえば「Windowsでは本当にFiberを使う」とか、 実装上の変化もあるだろうし、CroutineからSemi-Coroutineになるとか。
あるいは、Enumerator#nextがあれば、素のFiberは要らないかも、 という考えもよぎっているらしい。
SuperFastHashのPaul Hsiehによる文字列ライブラリ。
高速・安全・高機能ということで、 ちょっと中身を読んでみたいソースである。
無人機(UAV or Drone)の設計図をオープンソースにしている人たちの集うニュースグループに 自機をイランの国旗の色で塗り分けたイラン人からのポストがあった。
自分(たち)がオープンソースにしている技術が、 自分の国家(この場合にはアメリカ)と対立している国家(この場合はイラク)の 武装勢力かもしれない人によって利用されているとしたら どうなんだろうか、という問題提起。
ちなみに「オープンソースの定義」的には禁止できない。
結局、このイラン人、Amir Aalipourくんはテヘランに住む17歳の少年であることが 明らかになったのだが、 だからといってこの問題提起が意味がないわけではない。
今週の司会はビショップにお願いした。
日曜学校のテーマは聖霊の賜物。 今回準備のために改めて勉強したが、 意外とものを知ってないことを自覚した。
集会終了後、評議会。 特に月末のYSAカンファレンスについて、いろいろと。 大規模なイベントなので準備が大変。 現地のスタッフの人はもっと大変に違いない。
夕食はお好み焼き。粉の配分を間違えたような気がする。
千葉県は出席番号が誕生日順であるという話。
しかし、私の小学校は誕生日順だった。私は4月生まれなので、 妙に早かった覚えが。
ということは、千葉県ではないもう一県とは鳥取県？ それとも、昔はもっと多かったってことなのかな。
Scheme R5.97RSにおけるUnicodeの取り扱いが「壊れている」という 話。
もっとも、(1)はshouldをmustと読み違えたもののようだ。 あと、(2)は後方互換のためのAPIであるということだ。
それ以外の、(3),(4)は間違いではないけど、 そこまで実装にコストをかける必要があるのかなあ。 この調子だとFactorは「世界一正確にUnicodeが扱える処理系」になるかもしれない。
(Common) Lispの最大の問題は「コマンドが作れないこと」という分析。 ライブラリは簡単に作れるんだけど。
ここでコマンドとはコマンドラインから実行できるもの、 あるいはexecシステムコールで呼び出せるもの(Windowsならstartか)。
いや、もちろん作れるんだけど、イメージをまるごと含む形になるため、 ほんの小さなプログラムでも巨大になりがち。 これでは「伝統的な開発モデル」にはうまくはまらない、 ということ。
Smalltalkでも似たような状態なんだけど、 とはいえ、これはLisp(やSmalltalk)の最大の利点でもあるわけだし。 利点と欠点が表裏一体ということか。
PerlのArtisticライセンスが、裁判所により 「著作権仕様許諾」ではなく「契約」であると見なされた、という話。
もっとも私にはそれがどう違うのかよくわからないんだけど、 スラッシュドットのコメントを読んでると、なんだか大きな違いがあるらしい。 少なくともアメリカ法の下では。
さらなる情報が(できれば日本語で)ほしいなあ。
[つぶやき] 大規模ってなんだろう - Don'tStopMusic (2007-08-27)
ひとくちに「大規模」と言ってもいろいろある、という話。
あと、付け加えるならば「金額が大きい、責任が重い」があるかな。
個人的な印象では「嵩」、「組織」については、 ツールや手法による支援と発想の転換で、 できるだけ小さくしていくしか生き延びる方法はないと思う。
たとえばRubyやRailsは、簡潔さと複雑さをフレームワークの下に隠してしまうことで 小規模な組織でも「ちゃんとした」Webアプリケーションの開発を可能にしている (と見なされているから流行ってる)。
あるいは、IDEやリファクタリングツールなどもそういう助けになってる のかもしれない。
私はこの種の大規模対応のことを「開発のスケーラビリティ」と呼んでいる。 そのゴールはできるだけ小さなコスト(ソフトウェア規模やチーム規模)で できるだけ大きな成果(顧客満足、価格)を産み出すことだ。
間違ってもソフトウェア規模やチーム規模そのものをゴールにしてはいけない。 「大規模なソフトウェアが作れました」とか 「大人数で技術レベルがバラバラのチームをマネジメントできました」 なんて自己満足でしかない。手段と目的を混同してはいけない*1
一方、「ユーザの数」で表現されるタイプのスケーラビリティもある。 アクセス数、アクセス密度、データ量などである。 私はこれらを「実行のスケーラビリティ」と呼んでいる。
これはこれで重要な問題だが、少なくとも開発のスケーラビリティとは 異なる技術が要求される。ApacheやFastCGI、Mongrelの使い方とか、 データベースの分割・複製、マルチコア活用。
どれをとってもエキサイティングな技術である。 これからもっと重要性が増す技術だと思う。
*1 手段のためなら目的を選ばない、まつもとに言われたくはないかもしれないが。
海外(特にアメリカか)では、 わりと一般的なビジネスツールであると聞く、 カンファレンスコールを使う機会があった。 参加者の大半はアメリカ在住。
ということで、次回があるなら、もうちょっと別のツールが使いたいなあ。 SkypeチャットとかIRCとか。文字ベースの方が私にはありがたいなあ。
国際電話経由で参加したのだが、 IP電話のおかげで安くすんだ(13分で40円)。 これだったら国内で携帯電話にかけるよりはるかに安いよ。
NHK地方局の短い番組でとりあげていただけるそうで、取材を受ける。 とはいえ、業界のネタを普通の人に分かるように表現するのは 困難を極めるので、取材の人も頭を抱えてる。
聞くところによると土曜日朝の５分のコーナーなのだそうだが、 取材だけでも何時間もかけている。 この後、撮影もあるんだが、それもきっと何時間もかかるんだろうなあ。
以前、未踏の件で「クローズアップ現代」に1分くらい登場しただけでも、 撮影に半日かかったものなあ。テレビはしんどいよ。
恥ずかしいし。
すいません、片棒担ぎです。
とはいえ、私にはSmalltalkを殺してもなんのメリットもない。 Smalltalk(や、Lisp。以下同じ)の優秀さを知るからこそ、 なぜSmalltalkが大衆に人気がないのかを考察することこそ 私が興味がある点だ。
大衆は強力なパワーに関心がないのか。 言語の人気はなにで決まるのか。
先日お話した青木淳さんも「苦節25年、もうあきらめてます」とおっしゃっていた。
くらいしか理由は思いつかないんだけど。 Squeakなどオープンソース処理系が登場してずいぶん経つし、 最初のものはあまり関係なさそうだ。
とはいえ、いずれにしても
Smalltalk はかつて例を見ないほどインストールベースが増え、話題にのぼり、人々が手に触れることが出来るように＊ようやく＊なりつつある昨今だというのに！ｗ
というのは、ずいぶん世間の認知とはズレている。 そのズレを解消するのが普及と再認識の第一歩かもしれない。
Perl, Python, Rubyの簡単な紹介。
一番面白かったのはここ。
しかし、RubyもSmalltalkのようにいずれは消える運命にある。だが、筆者もいまは「分かる」ようになり、楽しいと感じている。
「Smalltalkは消えたのか」とか、 「まあ、50年経てばRubyも消えるだろうけど」とか思うけど、 他人には言われたくはない。
なかなかツッコミどころのある表現だが、 しかし、実はこれは誤訳。
原文は
I was never able to really understand Smalltalk, mostly because of its very cryptic (to my mind) syntax. Ruby, however, is like Smalltalk for mere mortals. Now, I "get" it, and it is fun.
ああ、びっくりした。mere mortalsという表現が分からなかったんだね。
追記: 現在では注釈が付いて訂正されてるみたい。
テーマは「まわりが天才だらけ」と扇情的なものだが、 実際には「他人が天才と呼ぶ人」と「普通の人」の違いを示している点が 重要なのだと思う。
僕はそれまで、「自分には才能がない」と思っていたんです。ずっと後で分かったことなんですけど、それは才能のあるなしではなくて、別のものだったんです。
僕には「引き出し」がなかったんですね。
「天才だ！」と僕が思った人たちは、入社する前からアニメや漫画が好きで、アニメに対する素養があったのに、僕にはそういう引き出しがなかった。引き出しもなくて努力もしないで、いきなり彼らと伍そうと思った。入社してすぐに「あいつらは才能がある、俺にはない」という仕分けをしちゃって。それは大きな間違いで。
才能ではなく、引き出しの違いというのに気がつくのに、ずいぶんかかりました。
才能や能力があるかではなく、どれだけ蓄積したものがあるか というのがもっとも重要な点だと思う。ある意味、「時間をどう使うか決める」、 「モノになるまで継続する」ことができることこそ「才能」ではないか、と思う。
自分の引き出しはどこにあるか、知らないで「天才」と勝負するのは無謀すぎる。
自分の引き出しは、彼らと違ったんですよ。逆に、引き出しの違いが勝負ポイントになると思ったんです。
僕が好きなのはノンフィクションとか時代劇。そんなところの材料というのは、アニメの人はあまり持って来ないんです。だから僕は、なるべく漫画好き、アニメ好きが触れないようなところから持ってくる。
−−勝負ポイントを、自分の強いところに持ってくる、ということですね。
そうすると競争相手が少ないから、楽じゃないですか（笑）。
Googleがオープンソースソフトウェアとして公開しているsparsehash。 新BSDライセンス。
ハッシュテーブルは要素に対するオーバーヘッドは馬鹿にならないものがあるのだが、 こちらは1エントリあたりわずか2ビットしか消費しないのだそうだ。
いったいどうやっているのか。これもソースコードを読みたいソフトウェアである。
先日のFactorからの指摘に対する反論。
shouldとmustの取り違え。しかし、
a future version (of Larceny) will offer at least one variable-width representation that still provides O(1) access.
とあるのはどうやって実現するんだろう。実に興味深い。 というか、できるものならRubyでも真似したい。
同意。
後方互換性。また、collationはUTS(Unicode Technical Standard)であり、 実装しなくてもUnicode互換性に問題ない。
同上
今日はGfarmの話を聞いたり、その他いろいろなことを学んだが、 例によって具体的なことは書けないので、箇条書き。
なんかこの件についての反応をいくつか見かけたのでここに追記しておく(実際に書いたのは9月)。
まず、ほとんどのソフトウェア開発者は製造業経験者の語る「もっと知った方がよい」という 言葉を何度も聞いたことがあると思う。が、それらは実際には役に立たないことが多い。
我々の作るものには物理的制約がないこと、 ソフトウェアは製造するものではなく設計するものであること、 などから彼ら(製造業経験者)の使うメタファーは間違ってる(よく言って不適切である)ことが多いからだ。
それは事実だ。
今回トヨタ流製造業発想を聞いていて、 私自身が同じことを何度も思った。
が、純粋なソフトウェア開発者であり、かつ製造業についてほとんど知識のない私が これらの話を聞いて「製造業のことを知った方がよい」と思ったのは、 その態度であり取り組みである。
彼らが、プロセスの改善のために継続的かつ組織的に払っている努力は 尊敬に値する。ハッカーは環境改善が好きだが、それは組織的なものではない。 多人数によるソフトウェア開発は(伝聞によると)かなり前時代的かつ改善が推奨されない 雰囲気のところが多いと聞く。
彼らが、「正当な製品」を出荷するために継続的かつ組織的に払っている努力は 尊敬に値する。ソフトウェアはなにが「正当」が決めることが困難という事情を 考慮してもなお彼らほどの努力をしているところは少数派だろう。
もっとも私はよく知らないんだけど「組み込み」領域は 製造業の一部であるため、すでにこれくらいの努力と取り組みは行われている のかもしれない。なんか苦労話しか耳にしないんだけど、 それは彼らにとっての当たり前は話題にならないと言うことなのかもしれず。
ささだくんのところの場所を借りてM17Nミーティング。 今までの議論を忘れてたりして落ち込む。
結局、今回いろいろ話してて、新たに具体的に決まったのは、Rubyのリテラル強化。
ただし、以下の場合には事前に専用のライブラリをrequireする必要がある。
そのこころは、
である。\Nなどに専用ライブラリを必要とする点はPerl譲りである。 ただし、useのないRubyでは「事前にライブラリをrequireする」仕組みから 用意しないといけない。
あと、-Kの扱いや統一内部コードの問題もあるのだが、 結論を出せなかった。「文字」の問題(Unicode結合文字とか)に 時間を取りすぎたか。
なんだかんだ言って、M17Nが足を引っ張りそうだなあ。 「今月中に仕様をFIXせよ」との、ありがたい「ささだ指令」をいただく。
泣きそう。
「Erlang七つの大罪」とかいうからどんなんかなと思って読んだら、 ほとんどいいがかり。なんなんだよ「It is a computer language (based on English).」とか。
どうやら、COSAという「言語？」のファン(自分が作ってるんではないらしい)で そちらをほめたいから他の言語をけなすという行為に出てるようなんだが、 逆効果でないかな。
xorとbit shiftだけを作った(擬似)乱数生成器。
私は算数弱いんでよく理解できないんだけど、こんなにコンパクトなコードで 質の高い乱数が生成できるって言うんなら、それはすごいことではないだろうか。
ナノチューブと言うのは丈夫な素材で、強いうえに溶剤にも溶けない。 が、意外なものに溶ける、という話。
あらゆる溶媒を受け付けないナノチューブを溶かしてしまう「魔法の液体」は、実はコンビニで150円も出せば容易に入手できます。その液体の名はなんとサントリーの緑茶「伊右衛門 濃いめ」です。
どうやら学生が溶けないことを実証するため、いろいろやっているうちに 意外にも溶けたということのようだ。 世の中、分からないことの方が多いということを実感させる。
Seasarのひがさんのエントリから派生した会長のお言葉。
まあ、多少は仕方ないんじゃないでしょうか。そもそも「たのしさ」なんて訳の分からない物差しを持ち出して喜んでいながら冷静な評価を期待するのは虫がよすぎるでしょうし。
幸せになるユーザが増えるのを歓迎し、不幸になるユーザが増えるのを防ぎつつ、ハードランディングに備えて。
ていうか、Ruby自体はバブルにはならなさそうな。良くも悪くも。
そうかなあ。Railsほど前面に立ってないけれども、 バブルは確実にあると思う。バブルの大きさは小さいのかもしれないけど。
でなきゃ、私のところにこんなに講演の依頼が来たり、 NaClに分不相応な仕事が舞い込んだりしないと思うし。
で、現状が中身のない(あるいは薄い)風船であることを自覚した上で 中身を詰める努力を継続していった方がよいと考えている。 それを思ってのRubyアソシエーションだったり、 NaClといろんな会社との提携だったりするわけだし。
たぶん、バブルが崩壊しても、私にはあまりダメージはなさそうなんだけど。 もともと「お金」とは距離を置いてるし。
でも、最近上向いてきた収入が下がることは避けられないかなぁ。
「<---」とか「++-」とか、元々Rubyには存在しない演算子を作り出すライブラリ。
「パーザーを書き換えるのか、しかし、Yaccのパーザーは簡単じゃないよな」と思ったのだが、 実際には演算子の組み合わせで実現するようだ。
つまり、
foo ++- bar
は、もともと
foo.+(bar.-@().+@())
と解釈されるので、この組み合わせで指定したメソッドが起動するように それぞれの演算子を再定義してやるということ。
なるほど。思いつきもしなかった。脱帽。
ブロックからSQLを生成するライブラリAmbitionについて。
User.detect { |u| u.name == 'Jericho' && u.age == 22 }
のようなコードからSQLを生成できる。
Mockオブジェクトを使って、式からSQLを生成するようなライブラリは Squirrelのような ものが以前からあったが、どうしても以下のような制限があった。
一方、AmbitionはRubyを使って条件指定すると、それがそのままSQLになる というもの。たとえば、
User.first
"SELECT * FROM users LIMIT 1"
User.select { |m| m.name != 'macgyver' }
"SELECT * FROM users WHERE users.`name` <> 'macgyver'"
User.select { |u| u.email =~ /chris/ }.first
"SELECT * FROM users WHERE (users.`email` REGEXP 'chris') LIMIT 1"
User.select { |u| u.karma > 20 }.sort_by(&:karma).first(5)
"SELECT * FROM users WHERE (users.`karma` > 20)
ORDER BY users.karma LIMIT 5"
User.select { |u| u.email =~ 'ch%' }.size
"SELECT count(*) AS count_all FROM users
WHERE (users.`email` LIKE 'ch%')"
User.sort_by { |u| [ u.email, -u.created_at ] }
"SELECT * FROM users ORDER BY users.email, users.created_at DESC"
User.detect { |u| u.email =~ 'chris%' && u.profile.blog == 'Err' }
"SELECT users.`id` AS t0_r0 ... FROM users
LEFT OUTER JOIN profiles ON profiles.user_id = users.id
WHERE ((users.`email` LIKE 'chris%' AND profiles.blog = 'Err'))
LIMIT 1"
これはすごいぞ。で、これをどうやって実現しているかというと ParseTreeを使って 構文木を解析して、そこからSQLクエリを生成しているのだった。
頭いい。
でも、YARVで構文木って手に入るんだっけか。
EMMAって初めて聞いたけど「Europe」、「Middle East」、「Africa」の略らしい。 なんか広すぎて(世界の半分はカバーしてる)共通項がありそうな気がしないんだけど。
ま、いずれにせよ、Ruby on RailsとC#(ってフレームワークと言語を並べるのは不適切なような)が 人気が出ているという調査結果には、素直に喜んでおこう。