Tue, 22 Oct
はじめの言語の賞味期限、のつづき

前回 の続き。はてなブックマーク300超え は今年どころか 8-p.info 全体で新記録だと思う。ありがとうございます。コメントを読んでいると「いわれてみるとちがうかも…」「それはリンク先にあるのに!」とかいろいろあったので補足です。

そうこうしているうちに、Facebook: Analyzing PHP statically は動画もスライドも公開されていたので、これから見ます。

Hack の型って本当に HHVM は見てないの? 少なくとも parser は読んでるっぽいんだけど…

ここは自分の誤認と、誤解をまねく表現があったと思う。元記事にも訂正をいれてある。

Strange Loop のスライド の25ページ目 (“Hack Implementation”) の図で Type Checker が Compiler とわかれているのと、最後の 39ページ目 (“Everyone’s favorite generics slide”) にある

Remember, runtime throws everything away anyway, so perfwise, it’s type erasure.

から「見ておらず」と書いたけど、HHVM を読んで確認をとるまではしていなかった。すくなくとも、parser は読んで構文木にもわたっているので「見ておらず」は言い過ぎ、性能に影響しないかは要調査だった。

なんで Facebook ってこんなに PHP が好きなの?

これは Strange Loop のスライド で言及されてたのに、記事に入れ損ねた部分だった。スライドでは PHP の欠点にいろいろとふれた後 (14ページ) に

PHP gets three important things really right

  • Programmer workflow
  • State
  • Concurrency

と3つの点についてふれる。最初の Workflow は「変更してリロードすればすぐ反映される」というところで、これは「プログラマの短期記憶というもっとも貴重な資源に最適化されている」としている。

残り2つは State と Concurrency が「無いこと」で、毎リクエストごとにすべてが初期化されることでバグが押さえられること、リクエストが1スレッドで実行されることの (利点はスライドには明確に書いてないけどたぶん) 単純さを良い点としてあつかっている。

とはいえ、メソッドを改名しようとか、引数の順番を変えるとか、メソッドを消すとかいいだすと大変で、そこからスライドは Hack の話へと進んでいく。

言語の賞味期限ってこれアーキテクチャのはなしだよね?

Twitter: From Ruby on Rails to the JVM では、4:08 あたりで Ruby の改善をしている間も

But we are also looking for opportunities to

  • Join a bigger community
  • Find more developers
  • Use better tools

で結果としての JVM 移行だと、そして 8:12 あたりで

I want to hit hundreds of backend machines, composes responses back, and return in 50 milliseconds and that’s something I can’t do in Ruby right now.

と語っている。なので「SOA だけど全部 Ruby な Twitter」は、少なくとも当時の Twitter の人々にとっては現実的ではなく、言語の変更とアーキテクチャの変更は、どちらも必要だったのではないかと思う。

Facebook も実際のところ SOA っぽくなってるんじゃない?

QCon London 2011 の Evolution of Code Design at Facebook (via steps to phantasien) で Nick Schrock は “Still a monolithic PHP web app” を自称している。彼らのビジネスロジックは依然として PHP の中にあるらしい。

後々に SOA っぽくするなら、最初からしとけばいいんじゃないの?

最後は自作自演でだれにも聞かれていないことを。

  1. はじめは Rails みたいなフルスタックなフレームワークでソフトウェアを書く。
  2. そのソフトウェアに人気が出る。
  3. 顧客がソフトウェアに求めることがわかって、単位時間あたりに捌かなくてはいけない流量が増えて、雇える人の量も増える。
  4. ソフトウェアを SOA 風に複数のソフトウェアに切り分けて、それを別々のチームで開発するようにする。

というのは、私のようなスクリプト言語育ちにとっては自然で、「失敗してもクビにならない」類の答えだと思う。

一方で、フルスタックなフレームワークでモノリシックなソフトウェアを開発・運用することに比べて、SOA 風にソフトウェアが切り分けられた状況で開発・運用することがどのくらい大変なのかについて、私にはちゃんとした見積もりが無い。なんとなく大変なんだろうという気はする。でも、どのくらい大変なんだろう。

「いまは開発速度を重視すべき時期なので MVC は無視しましょう」というのは、今の時代だとあまり認められにくいスタイルだと思う。ソフトウェアを分割して「このリバースプロキシからの HTTP リクエストをうけとるソフトウェアからは MySQL を直接叩いたりしませんよ」みたいな制約をかすことは、MVC みたいな制約に比べるとどのくらい重いんだろうか。

そのくらいの軽い分割は SOA とは呼ばないのかもしれないけど、そんなことをぼんやり考える今日このごろです。