ECMAScript 4の標準化が中止される 27
ストーリー by hayakawa
紆余曲折を経て生み出される物とは何か 部門より
紆余曲折を経て生み出される物とは何か 部門より
The Registerの記事より、Ecma Internationalで進められていた次期JavaScript標準仕様である、ECMAScript 4(ES4)の策定作業が中止された。EcmaではES3.1の標準化も平行して進めており、こちらは「ES Harmony」という名前に改められて続行される。
ECMAScriptの標準化を担当するTC39(technical committee 39)では、ES4陣営(Adobe、Mozillaなど)とES3.1陣営(Microsoft、Yahoo!など)の対立が深刻化していたが、大幅な仕様改訂となるES4を捨てて、ES3の延長線上にあるES3.1を取ることで合意がなされた。合意内容についてはMozillaのBrendan Eich氏のメールを参照されたい。
Harmonyは「いがみ合っていても前進できないので、みんなで協力して次の仕様を決めましょう」ということを表しているようだが、いつまで仲良くしていられるだろうか。
およそ3 (スコア:5, おもしろおかしい)
Harmony (スコア:5, 参考になる)
JavaScript 2.0はECMAScript 3.1ベースに、ECMAScript 4は譲歩 [mycom.co.jp]
Re:Harmony (スコア:1, 興味深い)
しかし、名前空間とパッケージは3.1に含まれないのか。
一番わけがわからないところだから、ぜひ取り込んで欲しいんだけどなあ。
パッケージ等 (Re:Harmony) (スコア:4, 参考になる)
名前空間もパッケージも、 3.1 に取り込まれないだけでなく、 ECMAScript Harmony プロジェクトにおいては二度と考慮しないようです。逆に言えば、これらを Ecma Technical Committee 39 で議論することがあるとすれば Harmony プロジェクトが終わった後ということでしょう。
Brendan Eich さんのメールから引用 (強調は引用者):
試訳:
Re:パッケージ等 (Re:Harmony) (スコア:2, 興味深い)
早期束縛は、Javaみたいな強い型付けの言語への方向性だから、SCRIPT言語としてそれをやめるってのはまあ1つの考え方だなあとは思うんだけど、
パッケージと名前空間(似たようなもんだと思うぞ)が「Webでの利用において不適切」と判断されるというのは、どういう理由なのか、誰か説明してください。
ぜんぶObject(辞書)を適宜入れ子にしちゃればいいじゃん、という主張なんでしょうか?
だとすれば「いいじゃん」そのものについては納得できなくもないんですが、
ただ「Webに合わない」って点はどういう意味なのかさっぱり判りません。
それとも、ここでいうパッケージとかは(も)、Javaと同様の強い型付けの一環としてのパッケージという考え方だけを意味しているのでしょうか?
つまり動的なロードを許すと話がややこしくなってしまうようなタイプの「パッケージ」なのでしょうか?
単にパッケージといっただけでは色々な形態が考え得るのですが、
前後の文脈が読めるほど英語には堪能じゃないもので、誰か解説お願いします。
Re:パッケージ等 (Re:Harmony) (スコア:1, 参考になる)
まず
「ES4 における名前空間のユースケースのひとつは, (名前空間の intrinsic による)アーリーバインディングと, 性能の向上, プログラマの理解しやすさの改善でした」
という指摘が有るので、
やっぱり名前空間→早期束縛っていう流れは有るようです。
そして
「しかしウェブのようにコードを動的にロードする場面では, アーリーバインディングとレイトバインディングの衝突を避ける優先順位づけや予約の仕組みは必要です.」
と続いているので、もろに「動的ロードと相性が悪い」「というかそういうアーキテクチャの名前空間を想定している」系の話題のようです。
ところで
「すっきりした(desugar)」
という言い回しが散見しますが、
これは「構文糖(Syntax Sugar)」などで使うニュアンスにおける「sugar」なのでしょうかね?
つまりdeが付いたので否定になり「甘ったるくない」「くどくない」というような意味?
ぐぐっていたら、同じ文章について(むろん日本語でという意味で)解説なさってる頁を見つけました。
http://d.hatena.ne.jp/nitoyon/20080819 [hatena.ne.jp]
Object.freeze()で固めちまえば普通のクラスみたいに落ち着いて使えるね、ということのようです。
Rubyみたいな事後ハックは禁止ということかしらん。ちょっと寂しい。
Re:パッケージ等 (Re:Harmony) (スコア:2, 参考になる)
おっしゃる通りこの sugar は syntax sugar の sugar です。今の文章の場合、 desugar は糖衣構文を展開して糖衣構文を使わないコードに直すことなので、「すっきりした姿になる」は誤訳だと思います。クラス等の言語機能が糖衣構文で実現できれば言語仕様や実装がすっきりするのは事実でしょうけれど。
Re: (スコア:0)
首根っこ押さえられちゃった? (スコア:4, すばらしい洞察)
Web開発者の獲得と開発コストの分担の両得を目論んでいた
ところが裏目に出てしまったね。
Actionscriptの拡張を続けるコメントはあるようだが
FirefoxはWebコンテンツのために対応は避けられず
Adobeも新規の開発者にアクセスし続けるためには
新しい"将来のECMAScript"に追加対応せざるを得ない。
これから標準技術の旗を下ろして二重のコストを請け負うか
競合他社ひしめく檻の中に内部エンジンの未来を委ねるのか。
Re:首根っこ押さえられちゃった? (スコア:1)
JavaScript2の勉強を兼ねられますよってことには
もうならならないってこと?
もともとなってなかったかもしれないけど
Re: (スコア:0)
Adobeには気の毒ですが、この方向性は数の論理というよりも技術的正義だと思います。Mozillaが受ける恩恵は小さくないでしょう。Flashはどうなっちゃうかわかりませんが。
ECMAScript Harmony (スコア:3, 参考になる)
天に届く統一規格 (スコア:1)
Re:天に届く統一規格 (スコア:1, 興味深い)
やっぱり Linux のように動くものが出来上がってから規格化されるほうが遥かにスムーズ。デファクトスタンダード最強ってとこでしょうか。
ブラウザ戦争なんて失敗の代名詞的に使われることが多いですが、それがなかったら今のような Web アプリ全盛の時代はこなかったのではないかとも思えます。
# ブラウザの中で Plugin を使って動画を再生とか、ブラウザでメールやエディタとか
# ばかげているとしか思えません!:P
## 個人的には本気で Ajax は捨てたいと思ってますが、無理なんでしょうね
Re:天に届く統一規格 (スコア:1, 興味深い)
># ブラウザの中で Plugin を使って動画を再生とか、ブラウザでメールやエディタとか
># ばかげているとしか思えません!:P
>## 個人的には本気で Ajax は捨てたいと思ってますが、無理なんでしょうね
参考までにお聞かせ願いたいのですが、
あなたが望んでる(つまり馬鹿げてると思わない)ありかたは、どんなものですか?
JavaScriptなどの動的要素を一切含まないWebアプリがいい!という話でしょうか?
それとも
「アプリ」をやるならWebと無関係にやるべきだ、という主張でしょうか?
(なおJavaWebStartみたいな奴はWeb(ブラウザ)とは無関係という理解でいいですよね?)
素Webアプリと、今風クラサバ(アプリはHTTPでユーザに送る)と、という
両極端のどっちに賛成してる意見なのか読み取れなかったのと、
じゃあどっちなんだろう?と少々興味がわきまして。
なお私は今風クラサバのほうが好きです。
Webアプリ(HTML+JSあたり)じゃなんぼ頑張ったところで所詮はアプリとして使いにくいんで、簡易アプリ止まりと思っています。
あと気になったのは、ブラウザのなかでPlugin使ってアプリを動かす、つまりJavaAppletやFLASH/FLEXの方向性については、
どう思われてるか?です。
「プラグイン(をWebブラウザにかますの)が馬鹿げてる」という評価でしょうか?
それとも「あれはWebとは一線を画してるからOK」でしょうか?
なお私は「ユーザからみて使いやすければいい」です。今ならJavaAppletとかでもそんなに悲惨じゃない速度だからまあいいかな程度。
ブラウザのなかで何でも動かすという発想は、つきつめればURIというか「アドレス欄」が欲しいんですよね、ユーザも開発者も。
このURIをブラウザで叩けばアプリが起動する、という安心感みたいなものが、ユーザからも開発(配布)者からも持て囃されてる。
JavaWebStartみたいなものも起動はブラウザからなんですけど、いったん立ち上がるとブラウザとは切り離されるんで、(そのこと自体はむしろ良いことだとも思うんですが) 彼らが馴染んだアドレス欄からは切り離されてしまうことにより、彼らの不興を買う…のではないかという不安があります。
Re:天に届く統一規格 (スコア:1, 興味深い)
すいません、中途半端かつ不適切な内容でした。
私も JavaScript を使って行う現代風のクラサバに異論はありません。
スタティックな HTML だけではどうしても出来ない事が多々ありますし。
Ajax を捨てたいと思っているのは、今の方向性を突き詰めるが故の問題です。
今の方法では、どうしても UI にコードが入り込んでしまという問題があり、デザインとコードを分離することが非常に困難になってしまっています。
上記問題を解決するために、様々なツールやフレームワークなども用意されていますが、その規模や隠蔽している範囲が大きいこともあって、それが想定している道から外れたことをやろうとすると非常に困難になる、という問題があります。
Ajax 自体が元々からして Quick Hack のようなところから発生した技術で、体系的に組み立てられた規格品ではないが故の問題だと認識しています。
私の意見としては、きちんと UI から Ajax を分離すべきといった意見なのですが、これこそ「点に届く統一規格」で夢物語でしかありません。
# これは開発側の理論ですし、ユーザには関係のない話であることもあり
# 大失敗する、典型的パターンだと思います。
ブラウザの例えは、あの当時、すべての人が標準に従い、標準化されるのを待って何もしなかったら、Web アプリはおろか Ajax や、形式や方法にとらわれない動画の配信など、今のような Web にはならず、相変わらずページを受け取るだけの Web に留まっていたのではないかと思います。
今の Web の方向性には満足していますが、基盤にある技術は既に時代遅れ。
全てを統一する標準規格がほしい所ですが無理なんでしょうね。
Re: (スコア:0)
>JavaScript を使って行う現代風のクラサバに異論はありません。
更に脱線ぽいですが、JS以外を使った現代風クラサバはどう思われます?
前述したようにJavaAppletもこのグループですし、
(Javaでいえば)JavaWebStartもそうだし。
FLASHはJS系と呼ぶべきかどうか色々微妙ではあります。
というかコンパイルしちまう処理系だと元の言語が何だったかは二義的な問題にしかならないですし。
>Ajax を捨てたい
よくわからないのですが、
Ajaxも「JavaScript を使って行う現代風のクラサバ」(の流儀の1つ)
じゃないのでしょうか?
つまり「何を使って」「どこに」クライアントを実装してるか
Re:天に届く統一規格 (スコア:1)
静的な言語のリンカでは現在当然のように行われている処理ですが、JSだとevalがあるので難しいのではないのかなぁ?
Best regards, でぃーすけ
Re:天に届く統一規格 (スコア:1)
元の発言者ではありませんが、つまりは「ブラウザはブラウザであって『環境』ではない」って言いたいのではないでしょうか?
昔、文字端末しか無かったときに、初めはエディタであったものが『環境』であると主張し、何でもエディタからできるようにした。でも、それは元々エディタでしかなかったので、別の環境であるウィンドウシステムが出てくると、(一般には)見向きもされなくなってきた。
ブラウザはウィンドウシステムの上で動くもの(CUIで動くものもありますが)なので、別ウィンドウでやればいいことをわざわざブラウザ上のスクリプトにすること、つまりは屋上屋を重ねるようなやり方が面白くないということでしょう。
いっそのこと、ウィンドウシステムでなく、まずブラウザが起動するような環境ならいいのかも。(それっぽいのが、昔あったような?)
Re:天に届く統一規格 (スコア:1)
#知らない人もいると思うので。
しかし、統合開発環境はどうなんでしょうかね?ウィンドウシステム上に載ってるからOK?そーいえばEpochなんてのもあったっけ。
Re:天に届く統一規格 (スコア:1)
ブラウザってのは現代のEmacsだったんだ!
# だったらJavaScriptじゃなくてLispでw
Re: (スコア:0)
しばしば幾つかの動的言語が「Lispの末裔」と呼ばれますが、
JSはメジャーどころの中では特にLisp雰囲気を色濃く残した言語でしょうね。
今回の決定も、猛烈に色々台無しにしてまとめてしまえば、
「あんまりLispからかけ離れた言語になるの禁止」
って話だし。
#おもおか狙いなのでAC
Re: (スコア:0)
別ACですが・・・
単純にJavascriptという言語でやるのがいやなのでは?
複数ブラウザの派生表現を考えたりするのは大変ですもの。
# ライブラリが吸収してはくれたりしますが、標準ライブラリもないですし・・・
Re:天に届く統一規格 (スコア:1)
プラグインで動画再生すら否定していますよ?
Re:天に届く統一規格 (スコア:1, 興味深い)
POSIXという規格と、規格上で動作するアプリケーションが存在したからこそ成功した例ですから。
もちろん、開発が軌道に乗ってからは、いろいろと独自設計していますけど。
# ここまで書いて気付いたんですけど、ひょっとして kernel ではなく distribution のことを指していますか?
Re: (スコア:0, フレームのもと)
ECMAScriptといえば (スコア:0)
非常に楽しみですw