Seasar Conference 2007 Autumn Seasar を支えるテクノロジー
東工大の准教授で、Javassist開発者の千葉 滋 先生のゲスト講演
- ReflectionとMetaobject(後のAOPである)の歴史
- クラスローダの話
と来て、動的言語vs静的言語の比較→落とし所を提供するGluonJというものの紹介をしていました。
静的言語vs動的言語
| 静的言語 | 動的言語 | |
|---|---|---|
| Reliability(信頼性) | Productivity(生産性) | |
| Java,C#… | Ruby,PHP…,LISP | |
| 型付 | 型無し | |
| 高速実行 | マシンは毎年速くなる(から実行速度は遅くても良い) | |
| 分析、設計、実装 | Rapid Prototyping | |
| 大規模チーム | 少数精鋭チーム | |
| Avoid coding | Enjoy coding |
静的なJavaでもHotSwapを使えば、すでにロード済みのクラスを再ロード可能だが、
メソッドの中身は変更できても、新メソッド･新フィールドの追加はできない。
そこは固定しているから最適化が出来る→実行速度が速い。
Rubyではいつでも新メソッド、新フィールドの追加が出来る代わりに実行速度は遅い。
本当に必要なものは、上記の静的言語･動的言語のどちらかではなくて、Reliableでproductiveなもの。
- 秩序を持って動的〜〜を
- でも基本は静的〜〜を
本当に常時クラス書き換えをできるようにする必要があるか？
→ロード時までにクラス書き換えできれば十分じゃないの？
GluonJ
- 継承のような記述でクラス定義を上書きできる
- 元のソースコードは触らない
- staticメソッドの上書きが可能
- final,privateでも上書き可能
- 呼び出し元が特定クラスのときだけ、上書きメソッドを実行するとかも出来る
まとめ
Reliableでproductiveに動的言語のよさをマイルドに採用しよう
感想
というか雑感というか疑問というか
動的言語の実行速度の遅さを気にしない人は、
マシンがどんどん速くなってるからOKっていう富豪的プログラミングの観点で気にしない人より、
ボトルネックになるのは、静的言語なり動的言語で記述するアプリケーションコードの実行時間じゃなくて、
DB接続の時間やサーバサイドマッシュアップでのWeb API呼び出しの待ち時間だから気にしない人のほうが多いんじゃないかな。
なので、GluonJの実行時にクラス定義を上書きできないという特性は、
性能上の優位性より、自分の足を打ち抜かないようにしか作れないという安全面の優位性の方が重要な気がする。
クラス定義の動的・静的の話しか出なかったけど、変数の型付の静的・動的の話もあるよね。
その辺での歩み寄りというか落とし所はどんなもんなのかなあと。
C#3.0のローカル変数限定でvarで変数宣言→型推論でコンパイル時に型決定っていうのも、その辺の落とし所を探した結果なんだろうか？
GluonJは静的言語を基本として、動的言語のようなクラス定義の上書きができるというものだったけど、
逆に動的言語を基本として、フレームワーク〜プロジェクト別のカスタマイズまではクラス定義上書きOK、
アプリケーションコードではクラス定義上書きNGみたいなことはできないかなあと。
プラグマみたいの？
よくわからないけど、ECMAScript4にそれっぽい臭いを感じる。
2007/11/12追記
Yuguiさんからのトラックバック
動的言語なフレームワーク @ 2007年11月 @ ratio - rational - irrational @ IDM
によると、Rubyでは(Railsでは？)アプリケーションコードではクラス定義上書きNGみたいなことが普通に出来るそうです。
Module#freezeするとメソッドの追加削除ができなくなる。だから、VMはfrozen classの利用を検出したらメソッド探索をインライン展開したりとかいう最適化の余地があるんじゃなかろうか。
