RFC4627としてJSONが定義されたという話(の日本語訳)。
JSONも結構便利だよね。誰かができの良さそうなJSONライブラリを書いてくれたら 標準添付するのがいいんじゃないかなあ。
最近、第二版が出た「The Ruby Way」の著者、Hal Fultonへのインタビュー。
HalへRubyを紹介したのがConrad Schneikerだとは知らなかった。 彼はcomp.lang.ruby設立の立役者であり、 Ruby界に「Principle of Least Surprise」という標語を導入した人でもある(確か)。
きっと松江市長は「オープンソースラボ」にこういうのを期待しているんではなかろうか。 くわばら、くわばら。
とはいうものの、なんらかの形で「良循環」で実現させてみたいものだ。 最大の障壁は地域格差と、それによる(プログラマ)人口密度の低さのような気がする。
日本語訳。
JoelがRubyに関して触れてくれるのはありがたいことだと思う。 それにJoelの結論に対して反対しているというわけでもない。
that's not a safe choice for at least another year or six.
(RoRは)少なくとも後何年かは安全な選択とは言えない
彼はビジネスマンだし、彼自らが Ruby on Railsを選択することによる「リスク」を勧めるのはどうかと思う。
ただし、そこから先はいただけない。
1) it displays a stunning antipathy towards Unicode and, 2) it's known to be slow, so if you become The Next MySpace, you'll be buying 5 times as many boxes as the .NET guy down the hall.
1) RubyはひどくUnicodeを嫌っているし、 2) 遅いことで知られている。次のMySpace(SNS)になろうとしたら、.NETで実装するより5倍の台数マシンを買わなくちゃいけなくなる。
いずれも事実ではない。
確かにJava、PythonやPerlなどUnicode中心のやり方とは異なっているけど、 別にUnicodeを嫌っているわけじゃないし、 Webアプリケーションのボトルネックは、主にネットワークやデータベースで 言語にはない(じゃなきゃ、誰がPHPを使う?)。 むしろ、大きなサイトの話を聞くと、 「マシンは買えばすむが生産性は金だけでは解決できない」という傾向があるようだ。
(追記)
Joel自身はVBScriptをベースにしたWasabiという言語を使っているそうだ。矛盾じゃないか、という指摘があちこちから上がっているが、 他人にリスクを勧めるのと自分でリスクをとるのとは別問題だと思う。
彼自身は「職を危うくする」危険はないわけだし。
JSONはYAMLでもあるからSyckで十分では?
YAMLはJSON完全互換じゃないのと、書き出しもサポートしたいんで専用ライブラリも欲しい気がします。
システム版パレートの法則が存在し、ボトルネック部分を解決すれば全体として「遅い」といわれるRubyでもオールCで書かれたシステムと見分けがつかないぐらいパフォーマンスを出せる。という当り前のことを当り前に実証したよ、というのをオイラはシアトルのRuby Conf 2003で話したつもりだったんだけど。Rubyも含めてインタプリタを使うほとんどの場合、ビット演算とかは遅いけど、そんなのはそこだけCで書いたモジュールをリンクしちゃえばいいだけだし。Rubyはめっちゃプラクティカルなんだけどねぇ。
「Unicodeが使えない」、「遅い」はRubyの二大FUDネタですね。
うーん。「Webアプリケーション」という言葉で想定しているものにずれがある気がします。元の文章でも単なるWebアプリケーションと言わずに「Webサーバ上に構築するエンタープライズアプリケーション」「大きなミッションクリティカルなWebシステム」という風に表現していますし。「大きなミッションクリティカルなWebシステム」で処理系の速度がボトルネックになるケースがどれだけあるのかはわかりませんが、少なくとも「Webアプリケーション」とひとくくりにして論じるのは大雑把に過ぎるのでは無いかと思います。
マシンを5台買ってもある単一の処理がアクセラレートされるわけでもないので「Rubyは遅い」というより「Ruby環境はスケーラビリティが無い」という話をJoelさんはしたかったのではないか、と非常に都合良く解釈しましたがその辺はいかがですか。
投稿すると500 Internal Server Errorが出ましたが投稿はされているようですね。あと昨日からwww.ruby-lang.orgの調子が悪いようでリファレンスマニュアルがなかなか参照できません...
私のところでも時々発生します>internal server error<br>まだ原因がわからないんです。<br>www.ruby-lang.orgは年寄りマシンがここ数日不調です。どうもCPUかマザーボードがダメみたい。今日、リプレースマシンが届きましたから、そのうち改善されるのではないかと。
で、スケーラビリティの話ですが、YahooとかGoogleみたいなモンスタークラスの実績はありませんが、FastCGIなどと組み合わせることでかなりのところまでは行く、というのが最近の評判のようです。<br>まあ、basecampをはじめとしてWeb2.0という触れ込みで実運用しているサイトがたくさんありますしね。
Webアプリケーションなんて前にバランサー、後ろに(分散)DBで、処理本体がRubyであるかどうかなんて関係ないけどね。(<br>分散)DB側の能力がボトルネックでRubyであるかどうかなんて関係ないじゃん。もっとメソッドレベルで密な分散をやりたいときはdRubyを使えばOSの接続上限までは分散化できるわけだし(って、以前のソフトウェアシンポジュームで発表したけどね)。ぜんぜん問題ないんだけどね。問題ないものを問題があるっていうのは、無知なのかFUDなのか、あるいはその両方なんでしょうかねぇ。ところでdRubyはよく出来ていて、簡単にバックエンドに処理が振れていいんだけど、あんまり有効活用していないねぇ。残念。