«前の日記(2005-01-04) 最新 次の日記(2005-01-06)» 編集

Matzにっき


2005-01-05 [長年日記]

_ [言語] Python Is Not Java

静的言語であるところのJavaと動的言語のPythonとの比較。 この論はPythonをRubyに置き換えてもだいたい成立する。

興味深いところを引用。

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think “I know, I’ll use XML.” Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling. But in Python, more often than not, code is easier to write than XML. And Python can process code much, much faster than your code can process XML. (Not only that, but you have to write the XML processing code, whereas Python itself is already written for you.)

実は今までどうしてJavaな人たちが(決してJavaと相性が良いわけでもない)XMLをあんなに使いたがるのか、 十分に理解していなかったのだが、これではっきりした気がする。 XMLはJavaよりもずっとagileでflexibleなので、 「Javaアプリケーションのスクリプティング」の標準的言語の地位を確立しているのだ。 なるほど、そういうことか。

そもそも独立したアプリケーションスクリプティング言語を必要としない PythonやRubyにどっぷりな人には理解できないことに違いない。 我々がXMLを必要とする局面は唯一「interoperability」だけだ。 それさえもXMLよりはYAMLの方がよっぽど適していると思うけど。

_ 米子

おととい米子に行ったのにもかかわらず再び米子訪問。 母校(米子東)のすぐそばを通ったが、遠目には学校はなにも変わっておらず、懐かしい気がした。 いくつかの場所で買い物。

本日のツッコミ(全24件) [ツッコミを入れる]
_ AC (2005-01-06 23:03)

あとXMLを使う場面はデータの永続性の確保かな。<br>コンパイラ言語用のインタプリタ言語的役割というか、ほとんどの場合設定ファイルとしてXML文書を使ってると思うのだけど、ファイル自体は手動で変更しないでツールを使うんだという前提だと、ルールが厳格なので開発言語としては結構使えると思っています。ツールさえあれば・・・。<br>最後の「そもそも独立した〜だけだ。」を読むとまつもとさん的には開発にツールを使うという前提はあんまり無いんだなあという印象ですね。<br>たとえばWISIWIGなUMLエディタで設計してオブジェクトを生成するとか、Webフレームワークを使って実装するときにアクションとかイベントをGUIなツールで繋げてあげるとかいう場合の中間形式とか保存形式としてXMLは有用だと思うのだけど。<br>CGIみたいに毎回パースしなきゃいけないなら別として。

_ まつもと (2005-01-06 23:26)

データの永続的保存の形式としても、中間形式にしても「XMLが最適」という理由はないように思います。ツールを使うっていうならなおさら。それでもXMLを使っちゃうんだよねえ。

_ おごちゃん (2005-01-06 23:35)

XMLって、「加工しやすい文書フォーマット」でしょ。それ以上でもそれ以下でもないように思うのだけど。データ交換に使うとか、serializeフォーマットに使うとかってのも、加工しやすい文書フォーマットだという性質を使っているだけ。と解釈してるけどなぁ。私はわりとXMLラヴだけど、その辺で割り切っているから好きでいられるような気がする。

_ AC (2005-01-07 01:23)

最良ではないけど気持ち悪くはないというか、まあ。<br>構造化されたデータは扱いやすいし。<br>再帰構造も扱えるし。<br>正当性も検証しやすいし。<br>標準化されてるし。<br>ライブラリもあるし。<br>エディタで開けるし。<br>バイナリ出力とか、RubyならツールもRubyで作ってMarshalでもいいっちゃいいけど、それってあんまりな気がするし、現実的な解が他にないので。<br>あとJavaだとRelaxerという便利なものがあるのも一因のような気がする。

_ yoosaki (2005-01-07 05:34)

http://www.xaa.jp/<br><br>こんなプロジェクトやってます。XMLをかなり積極的に使ってます。<br>言語としてはスクリプティングというよりアプリケーションの静的に宣言できる部分はXMLにもってきているという感じです。<br>それと、アプリケーションの中心となるデータ構造をXMLにしてしまうというぶっとんだ考えかたも。

_ kou (2005-01-07 11:22)

寡聞にして申し訳ありませんが素朴な質問を1つさせてください。<br>ではXMLの代替としては何がオススメだと思われますでしょうか?<br>最近はXML関連のツールはかなり充実していて、DBでもテーブルではなくXMLベース(と言うか木構造?)でデータを管理できたり、再整形にしてもXSLTでサックリ手を抜けるという印象だったので、これを否定されているわけではないとは思います。確かにYAMLであればXMLと一対一変換できる(?)ので同様の事がもっと可読性、記述性の良い状態で出来可能なのは分かりますが、これもいわゆるXMLの方言と取れます。<br>しかし「それさえもXMLよりはYAMLの方がよっぽど適していると思うけど」というコメントを見るとXMLや(XMLの方言としてのYAML)が与えてくれる解法よりももっと良い解法をご存知なような印象を受けたのですが?

_ まつもと (2005-01-07 14:46)

誤解されると困るので、最初に明言しておくと、現状のJavaユーザがXMLを選択することが不適切な判断だと主張しているわけではありません。状況を考えると適切な判断であることが多いと思います。とりあえずXMLで表現できるわけですし、読み書き・編集するライブラリもそろっているわけですし。ですから、XMLがJavaアプリケーションのスクリプティング言語の地位を確立している現状を変えろなどと主張するつもりはありません。<br><br>しかし、Extensible Markup LanguageであるXMLをデータ表現に(使えるからという理由で)使ってしまうことを勧めるような処理系提供者はどうかなあと考えています。データ表現として使うのであれば、YAMLやS式のような型情報が定義されているフォーマットの方がふさわしいと思います。単にwell-formedなXMLでは型に関する情報は含みませんから、データ表現にはほんとうはあまり向いていないのではないかと思います。<br><br>XML Schemaも含めれば、そのような「向いていない」ことはないのだと思いますが、既にあげたYAMLやS式のことを考えると、XMLという技術がそんなにおおげさなスキーマを適用してまでデータ表現に採用すべき技術かどうかということには疑問があります。<br><br>とはいうものの、最初に書いたように個々の(Java)開発者に対して「だからYAMLを選べ」とかいうような主張は無意味ですから、そんな主張はするつもりはありません。Javaをデザインした人たちがデータ表現形式としては、XMLよりもましなものを採用してくれていたらなあ、くらいなものです。

_ kazuho (2005-01-07 15:23)

私は XML-RPC の型表現が気持ち悪く感じられるのですが、そのあたりを批判されているということでしょうか?

_ yoosaki (2005-01-07 15:40)

私がXMLをデータ表現に用いているのは、もちろんスキーマの利用を前提にしています。ただし、XML SchemaではなくRELAX NGですが。<br>オブジェクト指向はデータに対して振る舞いを与えることで純粋なデータと振る舞いを持つオブジェクトとの境界をあいまいにしていると思います。<br>アプリケーションが操作の対象としているデータモデルをプログラムから分離することで得られるメリットも多くあると考えています。<br>もちろん、すべての人に受け入れられる考えかたではないのは承知の上なのでここであまり議論するつもりもありませんが、自己フォローということで。

_ みずしま (2005-01-07 20:39)

S式に型情報が定義されているというのは、どういう意味でしょうか。S式自体で型情報が規定されているとは思えないのですが。

_ まつもと (2005-01-07 21:02)

確かに「純粋なS式」にはシンボルとリストしかないのですが、普通に使われている「Lispが採用しているS式」には数、文字列、ベクタなどが定義されている、ということです。

_ AC (2005-01-07 21:29)

型はオブジェクトが知ってるし、オブジェクトもスキーマで定義してツールで吐くものだし、XMLの入出力には常にそれを使うのだから、型情報がなくてもどうでもいいと思う。<br>そして今Ruby版のRelaxerみたいなのが切実にほしい。

_ まつもと (2005-01-07 22:52)

もうちょっと詳しく教えていただけませんか? > ACさん<br><br>出力の方は「型はオブジェクトが知っている」というのは言えると思いますが、戻すためにはどこかに型情報が必要だと思うのですが。<br><br>> そして今Ruby版のRelaxerみたいなのが切実にほしい。 <br><br>Relaxerの知識がないのでなんとも言えませんね。検討してみます。

_ みずしま (2005-01-07 23:00)

そういうことなら、納得です。>Lispが採用しているS式<br>しかし、いずれにしてもS式自体には「静的な型」が存在しないので、静的型の言語とは相性が悪そうな気がします。S式の静的な型情報を定義するスキーマを作れば同じようなことはできるかもしれませんが、それは結局XMLでスキーマを使うのと大して変わりない気がしますし。

_ まつもと (2005-01-08 00:28)

S式と静的型言語の相性は、スキーマなしでwell-formedなXMLを処理するのと同じくらいだと思いますよ。<br>あるいは私が知らないだけで、いまやJavaのXML処理はなんらかのスキーマを使うようになっているのかもしれませんが(でも、やっぱりそんなことはないように思う)。

_ みずしま (2005-01-08 03:32)

さすがに、何でもスキーマを使って処理するということは無いと思いますが、Relaxerみたいに(Relax NGなどの)スキーマ言語を用いた記述から、Javaクラスを自動生成するツールはJava系では、それなりに使われているんじゃないでしょうか。

_ T (2005-01-08 22:41)

MVCでいえば、<br>XMLはMですよね。<br>Vがスタイルシート<br>Cは各プログラムが決めますね。<br><br>>普通に使われている「Lispが採用しているS式」には数、文>字列、ベクタなどが定義されている、ということです。 <br>で、こっちはMCと。<br>S式だけだと、Mになってしまいますが。<br><br>そして、YAMLはMVCと3セットですかね。

_ T (2005-01-08 22:54)

>型はオブジェクトが知ってるし、オブジェクトもスキーマ<br>>で定義してツールで吐くものだし、XMLの入出力には常に<br>>それを使うのだから、型情報がなくてもどうでもいいと思<br>これはJavaの直列化機能のことを指してるんじゃないでしょうか?<br>javaでは<br>outputSream.write(obj)<br>とすればストリームに書き出せますし<br>inputStream.read()//readObjectかも<br>とすればストリームから読み込めます。<br>要するにクラス情報をプログラム側は持ってますので、<br>それに従って読み込めばいいわけです。<br>ストリームがXMLファイルであってもなんら問題はないでしょう。

_ T (2005-01-08 23:07)

>静的とか動的とか<br>ある集合Aがあって、その要素は一般的に数字で表現される。それは、文字だけ見ても整数なのか、集合Aなのかわからない。この集合Aには演算子+が定義されていて、集合Aの要素1と2にに対して1+2は12である。このような集合が実は数学の世界にはいっぱいある(だいたい嘘)。<br>動的な言語はこれをうまく処理できるのだろうか?

_ まつもと (2005-01-08 23:27)

「これ」がよく理解できなかったので分かりません > Tさん<br>演算子によって振る舞いが変わるってこと?

_ AC (2005-01-08 23:41)

入力もとりあえずRelaxerに限って言えば、出力されたXMLの各要素に対応するエンティティクラスのコンストラクタにXML文書とか断片を渡せば自分自身を構成してくれるのでXML文書自体に型情報は必要ない、ということです。<br>RelaxerってORマッピングツールみたいなもん?

_ T (2005-01-11 02:32)

説明わかりずらくて申し分けないですorz<br>「型情報無しでオブジェクトを復元すること」ですね。型情報はXMLの仕様に含める必要もないということさえ伝わればいいのですけど。<br><br>とりあえず、メタ情報の配置場所がどこがいいのかってのは使い方によって違いますから、どこがいいかは一概に言えません。<br>符号化とまったく同じというか、符号化の話をしてるんでした(^^;<br><br>ソフトウェアにおける符号化はなにを最適化したいんでしょう?情報源符号化は平均符号長の最小化とか計算コスト最小化とかですね。<br>DBMSであればランダムアクセスコスト最小化とか、データ構造定義の抽象化とかですね。<br><br>評価関数があれば比較は簡単なんですけどね・・・<br>まあ、XMLの木構造(ラティス構造)だけとってきてしまうと<br>そこいらのフォーマットとなんら変わらないので比較できませんね。<br>私はXMLの冗長なところがいいのかな、と。冗長だから人間が誤るのを訂正してくれるわけです。

_ AC (2005-01-11 03:50)

もうそろそろ話題もクローズでしょうけど。<br>どうも型情報を含めようという動きは過去にあったけど普及はしていないようだ。<br>http://www.atmarkit.co.jp/fxml/tanpatsu/24bohem/01.html

_ 村山@Java屋 (2005-02-01 14:12)

Javaの人もXMLが好きな人は多いとは思いませんよ.設定ファイルなどでなんらかのファイル形式が必要であること,(オープンソースの!)Jakarta Commons Digesterが既に動いているので,必要ならそれが利用できること,他に対立候補が存在しないこと,などの消極的な理由でXMLが事実上の標準になっているだけだと思います.<br>「XMLにおける貴族とボヘミアン」の問題は厳密に言うと型情報を持つか否かの問題ではなく,型情報をSAXパーサーなどのより低いレベルで必須にするか否かの問題だそうです.

お名前:
E-mail:
コメント:
[]

«前の日記(2005-01-04) 最新 次の日記(2005-01-06)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.