RubyとLispでウェブアプリケーションを実運用 35
ストーリー by mhatta
なんどでもよみがえるさ 部門より
なんどでもよみがえるさ 部門より
本家/.の記事より。飛行機は天候や空港の都合ですぐ遅れる乗り物だが、そんなときはFlightCasterを試してみると良い。現時点では米国内便のみ対応だが、管制情報や天気予報、最近10年間の飛行記録を取り混ぜて、統計分析によってリアルタイムに飛行機の遅れを予想する新しいサービスだ。
しかし/.的に関心があるのは、どちらかというと実装の中身だろう。このサイトはフロントエンドにおなじみRuby on Rails、大規模分散計算フレームワークApache Hadoopを使い、Ruby版PaaSのHerokuにホスティングされている。しかしバックエンドの実装に用いられたのはRubyではなく、Javaで書かれたLisp方言の一つClojure。FlightCaster開発陣の一人のインタビューでは興味深い内幕が披露されている。O'Reillyからは新たなLisp本の出版も予告されているが、とうとう「カッコの時代」が来たのだろうか…。
むしろ予測アルゴリズムは何なのか (スコア:3, 興味深い)
BayesianなのかSVMなのかHMMなのか、どんな推定アルゴリズムを使っているのか気になったのですが、
http://flightcaster.com/faq [flightcaster.com] より引用
というわけで、特許出願中ということぐらいしかわかりませんね。
良く分からないにも拘らず果敢に発言してみます。 (スコア:1)
最初はぱっと見て、航空予約システムがLispなのかと思った。
統計情報や交通事情や紛争天災年中行事から遅延を予想するサービス・・・
実際に航空会社のサイトで運行情報を見たほうがいいのでは？
何に使うんだろう？遅延で払い戻しが生じる事に対して保険をかけた場合、
保険会社が査定に使えるくらいかな？
個人で調べて、5％くらいの便は遅れて到着します、と言われてもどうしようもないような。
いや、そうではなく。これLispだからどうなのかと。
LispじゃなくRubyをフロントエンドに使ったタロット占いでも変わらないんじゃないかと。
Re:良く分からないにも拘らず果敢に発言してみます。 (スコア:2)
FlightCasterは、例えば明日の運行状況（遅延、運休など）を「予測する」システムなので、
航空会社のサイトの「運行情報」のような「現況レポート」とは別物だと思います。
Re:良く分からないにも拘らず果敢に発言してみます。 (スコア:1, 参考になる)
Y Combinatorの投資家向けの発表であったんだが、日本語記事どっかに行ってしまった。
Re: (スコア:0)
日本では、羽田空港の混雑をダイヤに織り込んでいない全日空ぐらいしか必要なさそうな･･･。
バブル景気の頃の(駄) (スコア:0)
＃AIブームは遠くになりにけり
なんかさいきん (スコア:1, すばらしい洞察)
広告がどんどんいかがわしいものになってくんだけど、どうなのよ？
金さえ入ればいいの？
Re:なんかさいきん (スコア:2, すばらしい洞察)
Re:なんかさいきん (スコア:2, おもしろおかしい)
反論できない所がすごくムカつくな
feedbackボタンの挙動がかっけー！ (スコア:1)
メッセージ用のダイアログに、ほかの人が投稿した
既存の要望や質問を、リストアップするセクションがある。
ほかの人の投稿に対して「禿しく同意」ボタンを押すと、
賛同者の人数が、カウントアップされるという仕組み。
こういうインタフェイスは、いいと思うなぁ。
/.らしい、素晴らしいテーマですね、、、。 (スコア:1)
私だったら、Djangoで、ＧＡＥって言うところかな、、、。
lispの部分は、pythonのlambda式を使えば、そのまま使えるかも、、。
cpython の代わりにclpythonを使ったら、もっと面白いかな、、、。
でもＧＡＥは使えないな、、、。
絶望した！ (スコア:0)
だがちょっと待って欲しい (スコア:0)
Re:だがちょっと待って欲しい (スコア:3, 興味深い)
SICPより前に The Little Lisper を軽く読んでおくのがおすすめ。これで「あれ?LISPに括弧なんてあったっけ?」と思うくらいに括弧に慣れればしめたもの。
・SICP読んだだけではまともにLISPは使えません。あの本ではLISPの一番強力な機構であるマクロについての記述が不足している。
・SICPはcommon lispではなくschemeの本(※)。
と言った点にも注意。私見ですが、「common lisp←→scheme」間より「scheme←→javascript」間の方が近いと思っています。実際SICPを理解するとecmascriptの定義書(とくに最初は読みにくい10章あたり -- 実装する人にしか必要のないあたりですが...)が理解しやすくなるかと。あとperlが分かるなら、common lispの変数はlocal的な感覚で、schemeとjavascriptの変数はmy的な感覚。
(※) Gauche(schemeの1つの実装)の作者ですら、実用的には(永久に自分がメンテするシステムならGauche使うけど)common lispじゃないと厳しい、と言った意味のことを言っていました(どこか忘れましたがGaucheのサイトから辿れます)。
Best regards, でぃーすけ
Re: (スコア:0)
書いて極楽、見て地獄
Re:だがちょっと待って欲しい (スコア:2, すばらしい洞察)
＞書いて極楽、見て地獄
あれ、いつの間にPerlの話に？
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re:だがちょっと待って欲しい (スコア:1)
> あれ、いつの間にPerlの話に？
Let Over Lambda の Appendix.A からです。LOL
Re: (スコア:0)
>実用的には(永久に自分がメンテするシステムならGauche使うけど)common lispじゃないと厳しい
CommonLisp全体と、
Schemeのうちあくまで氏のオレオレ実装(独自拡張いっぱいあり)のGaucheとを
同列に比べたら、
そりゃ自分以外がメンテするにゃ厳しいという答えになるでしょうけど、
それは「Schemeの」話ではなくGaucheの話ですよね。
＃実際のところどうなのかは氏のサイトの書き方しだいだけど、
＃元コメの書き方をそのまま読解すればそうとしか読めん。
確かにSchemeは所謂フルスタックの真逆で「仕様の小ささ」「周辺ライブラリのことなんか出来るだけ関知しない」が売りなのだから、
実用するにはスタックの足りなさを補完するようなオレオレ実装が山ほど生まれるのが宿命なのだけど、
上コメからそこまで読み取れるわけでなし。
Re: (スコア:0)
あの本も古いね。いつからあるんだろ。
優れた本なのは間違いはないが、悪影響も甚だしいんだよな。かぶれてメクラになるやつが続出だ。
Re: (スコア:0)
>優れた本なのは間違いはないが、悪影響も甚だしいんだよな。かぶれてメクラになるやつが続出だ。
同意するなぁ。
講義内容を神聖不可侵な物として受け取っているとしか思えない言動するんだよね。
かぶれると５年くらいダメだよね。
#もちろんかぶれ無い人の方が多いのだけど、駄目な子ほど目立つというか、声がデカイというか正直邪魔
Re:だがちょっと待って欲しい (スコア:2)
Re: (スコア:0)
どの辺がそんなに悪影響があるんでしょうか。
関数による素直な抽象の例ばかりのように思うんですが。
OOP的じゃないから、だめとか、そういうドグマ的な話ですか？
教えていただければ幸いです。
Re: (スコア:0)
これは悪影響の例といっていいでしょうね
ほら、ドグマとか言ってるし(笑)
> OOP的じゃないから、だめとか、そういうドグマ的な話ですか？
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
という発言があります。なので問題はSICPの内容ではないわけです。「優れすぎ」ているでカブれて視野が狭くなる、という言い方はできるかもしれませんが。ですから
> どの辺がそんなに悪影響があるんでしょうか。
> 関数による素直な抽象の例ばかりのように思うんですが。
という質問の仕方には、ああやっぱりSICPのことにしか目がいかず、外のことに目が向いてらっしゃらないな、と感じたわけです。
ここまでなら「そんなカブれるほどの本だっけ？」という話だと解釈することもできましたが、ドグマ的うんぬんでその可能性は潰れてしまいました。
Re: (スコア:0)
なんてかんこいい！ (スコア:0)
相反するあれとこれ (スコア:0)
深く考えないで、
インデントのPythonとカッコのLispなんていうトンデモ組み合わせだったらもっと面白かったかもね
なんて言ってみる。
Re: (スコア:0)
作者 (スコア:0)
>Clojure is a LISP for the JVM created by Rich Hickey.
リッチでヒッキーな人が作ったの？
＃三千院ナギ？
＃↑頭良くて金と暇あってヒッキーだというならゲーム三昧じゃなく自由ソフトも作って欲しいんだが。
つまり、 (スコア:0)
Lispじゃ、UIを作れないって事だな。
Re: (スコア:0)
Re: (スコア:0)
つ Kahua Project [kahua.org]
逆に言えばLispベースのアプリケーションサーバーなんぞにも
ちゃんと需要はあったってことか。
Yahooのサービスを作った時のPaul Grahamの話を読むと
なんか確かに素晴らしい気はするんだが。
Re: (スコア:0)
Kahuaといえば継続ベースですなあ。
>Yahooのサービスを作った時のPaul Grahamの話
もちろん言語としての生産性とか自由度の問題も大きいのだろうけど、
Graham氏の「要望が来たらその場でさくさく修正できるんだぜ」という辺りを実現してる要因は、必ずしも言語そのものの強みではなく、どちらかというと「修正後のリロードなんて野暮なことを心配しなくていい」ような処理系エンジンの作りの問題なんじゃないか？
Javaでも(Seasarの人が)ホットリロードとか言っているわけだけど、
状態マシンをメモリ内部※にきちんと持つ(持つことを諦めない)ならば、
「リロード」とはどこまで行っても