「… + 未知成分 10%」セミナーの報告 - 檜山正幸のキマイラ飼育記 (はてなBlog)

「Erlang 30% + JavaScript 60% + 未知成分 10%」セミナーの報告です。

フーッ、まとめんの大変だった。この総括で一段落。

参加者

まず、ご参加くださった方々。順番は申し込み順です。氏名／ニックネームの公開に関してはご了承をいただいています（縁故参加者は檜山の判断）。

浜地慎一郎さん
高田敦史さん
荻野淳也 (id:ogijun) さん
id:publichtml さん
村岡友介さん
tmiya さん
野中哲さん
杉浦達樹さん
id:monjudoh さん
石井大輔さん（縁故参加）
太田裕樹さん（縁故参加）
他 5名の皆さん

資料

次のURLからアクセスできます。パッとしないし、トッ散らかってますが。

http://www.chimaira.org/archive/20081220.html

問題点

アンケートから拾った問題点を記します。次回もありそうですから反省として。

電源が欲しい → あっ、忘れていました。
椅子が硬かった → 全部柔らかい椅子は準備できませんでした。それはハズレの椅子だったんですね。すみません。
薄着の人には寒かった → 空間は広かったですからねー。ンー、今度は厚着してください。
広いのだからもっと人数多くても… → 机と椅子があんなもんで。
「会場はこちら」の貼り紙が欲しかった → おっしゃるとおり。
プロジェクターの映像が見えないときが → 僕（檜山）が立ち位置に気を付けるべきでした。
申し込み時、既に締め切っているかどうわからない → 締め切れば告知します。

ペイパル寄付についてもアンケートを採ったのですが、この結果は別の機会に。

感想など

アンケートとメールでくださった感想など。おおむね好評だったようでホッとしました。ブラケット（[ と ]）内は檜山の注釈です。

JavaScriptとErlangを勉強する気になりました。
Erlang本を読もうと思った。[さかきはらクンが喜びます。]
Erlang は web とかで斜め読みして Alef+VM みたいな? くらいの認識でしたけど、システムが予想してたよりはるかに面白げなものだとわかったのは大きな収穫でした。
貴重な話をありがとうございました。[参加者の]皆様また是非どこかでお会いしましょう。
楽しい時間をありがとうございました。
気難しいと思い込んでたErlangくんが、実は意外と気さくなで、しかも想像以上にユニークなやつだとわかったのが一番の収穫でした。
「この技術が現実化したら何が起こるんだろう」と想像をふくらませてわくわくできる非常に楽しいセミナーでした。
セミナたいへんたのしかったです。[ErlangやJavaScriptを]人が何かに使ってるのを見るとイメージわきやすいですね。

質疑応答の記録

その場の文脈がないと意味が取りにくいかもしれませんが、K君の記録から抜粋します。事後のコメントを若干足しました。

[Q] カーネル=ERTSということでいいの？
[A] そうではなく、ERTSは、エミュレータ（仮想ハードウェア）、カーネル、基本ライブラリ、基本アプリケーションを全部含めた実行環境だと捉えたほうがいい。[追記：文脈により、エミュレータをERTSと呼ぶこともあります。]
[Q] エミュレータのソースコードはWindows用とLinux用で違うのか？
[A] ertsのソースツリーを見ると、sys/ の下にホストOSに依存したコードが各OSごとに分けて入っているが、その量はたいしたことない。エミュレータの大部分は共通のコードを使っている。
[Q] コンパイルの過程がよく分からない。
[A] 概念的／理論的には、高級言語 Erlang → 抽象機械語Core Erlang → 具体的機械語BEAM(今) or JAM(昔)。最近のコンパイラでは、実装上もほぼこのような過程を経ていると思う。Core Erlangから、BEAM, JAM以外の具体的機械語に落とすことは可能。しかし、Core ErlangがErlangとかなり密着した仕様なので、Erlang以外の高級言語からCore Erlangに落とすのは難しそう。
[Q] Erlangからはファイルそのものは見えていないということだが、lsで見えてるよ？
[A] このlsは、lsコマンドに似せた関数。lsのごとく振る舞うように実装してある。ファイルはプロセスでラップされている。
[Q] file openに失敗するとどうなる？
[A] POSIX標準のエラーをアトムで返す（例：enoent）。format_error/1で可読メッセージを生成できる。
[Q] ErlangのコンパイラはErlangだけで書けるのか。
[A] 100%Erlangで書いてある。
[Q] 他の（非標準の）ファイルシステムなどを使おうとするなら？
[A] ドライバはC言語で書けるので、自分でドライバを書けばどうにでもなる。ファイルシステムに限らずネットワークなどでも同様。
[Q] ドライバやライブラリなど、すべてをC言語で書けば速くなるのか？
[A] Erlangのスケジューリングとの兼ね合いで、必ずしもそういうわけではない。
[Q] マルチコアだと早くならないのか？
[A] マルチコアの恩恵はちゃんと受けるはず。確証はないけど。
[Q] マルチコアの疑似環境を整えることはできるのか？
[A] もちろん本当に速くなるわけではないけれど、そういうオプションはあっと思う[檜山注：この発言の真偽は未確認]
[Q] CallとCastとは？
[A] Callは返り値がある。Castは一方通行、行きっぱなし。
[Q] Callは非同期？
[A] JavaScriptでは非同期。Erlangでは同期と思ってよい。
[Q] ブラウザからどうやってERTSと通信しているのか？
[A] ODJS（On Demand JavaScript, JSONP）方式を使っている。
[Q] つまり、1つのブラウザとERTSの間ではクライアント/サーバ・スタイルということ？
[A] 双方向／対等である点で違うのだが、そう思っても別にかまわない。
[Q] 必要なソフトウェアをインストールしてもらった上で、各種EDPあるいはERTS実装を使ってもらえばいいのでは？
[A] 何もインストールしなくていいという点でJavaScriptを選んだ。ただし、ActionScriptなどはインストールされてる場合も多いし有望。セキュリティ対策もJavaScriptよりは配慮できる。
[Q] アプレットは？
[A] アプレットなら同期通信ができるようになるが、起動が遅いし誰も使わないのでは。
[つっこみ] アプレットでクロスドメインはできなかったのでは？
[つっこみ] デフォルトの設定で制限されていたような…
[Q] 今回のコードはもうダウンロードできる？
[A] JavaScript側は公開済み。Erlangコードの一部もGoogle Codeにある。
[Q] マルチキャストは実装済みか？
[A] まだ一部。
[Q] ERTSは今一台しか動いていない？
[A] そう。増やしてみたいが、今は一台。
[Q] ERTSを複数動かす場合の動作は？
[A] ERTS同士をEDPでつないでクラスターで動かす。
[Q] Erlangにpsコマンドみたいなものはある？
[A] i()で似たようなことができる。
[Q] 大量のプロセスを生成すると、バグが見つかりにくくなるのでは？
[A] OTP Design Principlesに安全な設計手法、コーディング方法などについて書かれている。この手法に則ったサポートライブラリ（フレームワーク）がbehaviorとして多数用意されている。
[Q] チーム（リンクされたプロセス群）のプロセスのどれかが死んだらそこで終わり？
[A] one_for_oneなど、いくつかのストラテジーを選べる。
[Q] supervisorの動作は言語で定義されているのか？
[A] ライブラリとして用意されている。gen_serverなど、"generic"が付いたモジュールがテンプレート、あるいはフレームワークにあたるが、ホットスワップなどの動作も内部で記述されているので自前で書くのは危険。
[Q] GUIのライブラリはあるのか？
[A] gsというのがあるがショボイ。GUIプログラムの良いサンプルは見あたらない。しかし、独立した安全なスレッド(プロセス)を作れるという点から考えると、GUIは作りやすいのではないか。
[Q] クローラを作るのに都合がよさそう。
[A] そうかも。
[Q] メッセージ通信におけるメモリコピーは？
[A] 同一ERTS内ならデータの共有を行っている。特にバイナリなどはコピーを避けている。Erlangは破壊的代入がない（データがイミュタブル）だから共有はしやすい。[追記：小さなデータに関してはプロセスからプロセスにコピーされます]
[Q] GCは？
[A] システム全体のGCもあるし、各プロセス領域ごとのGCもやっているようだ。プログラミングする上で、メモリがどこに割り当てられているかとかGCのタイミングは気にする必要はない。
[Q] JavaScriptのDOM-3はDOM-2と何が変わったのか？
[A] MouseEventのようなイベント種別の名前が複数形だったのが単数形になったことが一番うれしい :-)
[Q] JSON型に関数を含めることは可能か？
[A] できない。
[Q] 原理的には、stringを送ってevalすればいいのでは？
[A] まーそうだけど、関数を送るというのは考えていない。ただし、Remote XPath/JSONPath みたいなパス式はあってもいいかもしれない