ずっと君のターン

いず 2011/11/15 01:01 今更ですが・・・この記事そうとう影響力がありそうなのでDartの肯定意見もちょっと書かせてください。
まだDartは機能不足ですが方向性は間違ってないと思います。読んでもらえるとうれしいです。
プログラミング言語Dartの「方向性」はやっぱり正しい / いずログ - http://is-log.blogspot.com/2011/11/dart.html

technohippy 2011/11/18 15:54 ありがとうございます。ですがアクセス数やはてブ数から考えて「本の虫」の人のDart礼賛の方がずっと影響力が大きいと思うので心配する必要はないと思いますよ。

さて、件の記事はひと通り読ませていただいたんですが話が発散しすぎていてどういった主張なのかが今ひとつ理解できませんでした。まるでアプリケーション開発に関わるすべての問題をDartが解決してくれるような文章に読めましたが視点が一方的で少し我田引水が過ぎるように感じます。

そもそもDartを批判する人は言語として優れているかどうかという点ではなく、「完全に新しい言語でJSを置き換える」という考え方を批判、というか「無理だろ」といっているように感じます。で、Googleみたいな大きな会社がそういう無理を通そうとすると周囲が混乱するだけなのでやめてくれ、というのが私の意見です。せめてJavaScriptのサブセットまたは拡張ならまだ応援する気にもなったでしょうが・・・。

通りすがり 2012/01/23 02:26 楽しく拝見させてもらいました。
確かにDartには否定的な意見、肯定的な意見があって
色々考えさせられる言語ではあると思います。

私は、次の三点において、Dartを前面肯定します。
１．サーバーサイドで最も使われているスクリプト言語である
　　PHPは脆弱性の高いコードを作りやすい仕様であるため、
　　代替言語が強く必要とされている。」
２．「サーバーサイドとクライアントサイドで、
　　覚える言語が異なる意味はない。」
３．要するに、サーバーサイド・クライアントサイドで
　　同じように使える手軽な"スクリプト言語"は今までなかった。

１．については言わずもがな。
２．については、そのような要望があることは事実で、
サーバーサイドスクリプトとしてJavaScriptが注目され始めています。
３．については、JavaScriptが有望ですが、現状として
JavaScriptがサーバーサイドで使われているとは言い難い状況です。
というのも、大規模になりがちなサーバーサイドで使うには、
JavaScriptには弱点があったから、そうなっているのだと思います。

だから、結局はJavaScriptとDartの戦いということになるかな、と。
GoogleはJavaScriptエンジン(V8)を開発していることもあり、
世界中で最もJavascriptの弱点等を知り尽くしている企業です。
Dartが仕様・実装としてそれなりにJavaScriptよりも
有用なものに進化するのならば、普及度と関係なく、
Mozillaの運営するFirefoxあたりもNativeに実装すると思いますよ。
ブラウザとしてシェアの少ないSafariも同調するでしょう。
IEはなかなか実装しないでしょうけど（笑

しかし、それでも、2012年の今年中には、IEのシェアは
1/3くらいに落ち込むことになりそうですので、少なくとも
2/3のブラウザはDartをNativeに実装することになると思います。

Dartの言語仕様は、最新の言語だけあって、
C#と同様に洗練され美しいです。
GoogleがApacheやnginxのDartプラグインをオープンな形で開発すれば、
一気に流れが変わる可能性もあると思います。
開発する人にとっては、「また言語覚えるのかよ」と思う人が
多い気もしますけど、一方で、綺麗な言語が流行るのを歓迎する人が
いるのも確かです。（私がそうです。）
JavaScriptに似ているので、覚えるのはそんな大したことじゃない
とも思いますし、私は歓迎します。

technohippy 2012/01/23 10:59 コメントありがとうございます。
いろんな考えがあっていいとは思いますが、いちおう通りすがりさんの意見に対する私の意見を書いておきますね。

１．サーバーサイドで最も使われているスクリプト言語であるPHPは脆弱性の高いコードを作りやすい仕様であるため、代替言語が強く必要とされている。

PHPが落とし穴の多いクソな言語であることは多くの人が認めていることですし、サーバーサイドで利用できるよりよい言語はいくらでもあります。それなのになぜ今だにPHPが広く使われているかというと「PHPがすでに広く使われていて仕事が沢山あるから」の一点ではないでしょうか。であるとすると、新しい言語を公開することはそもそも問題の解決になりません。

２．サーバーサイドとクライアントサイドで、覚える言語が異なる意味はない。

異なる言語を覚える意味はないというのは明らかに言い過ぎで、現状では目的に応じて使用する言語を変えるのはむしろ当然のことのように思います。サーバーサイドのプログラミングで嬉しいことの一つは利用する言語に原理的な制限がないことです。サーバーサイドとクライアントサイドで同じ言語を使えるようになるのもいいですが、そうするのであればサーバーサイドで使える言語を制限するのではなく、クライアントサイドで使える言語を増やす方向に進んでくれることを望みます。

３．要するに、サーバーサイド・クライアントサイドで同じように使える手軽な”スクリプト言語”は今までなかった。た

その認識が正しいとしても、「だから両方で使える全く新しい言語を開発する」という手段が正しいとは思えません。クライアントサイドで使われているJavaScriptをサーバーサイドで使えるようにするか、もしくはサーバーサイドで使われているRuby/Python/Perlなどをクライアントサイドで使えるようにするのが本筋ではないでしょうか。全くユーザーがいない言語をサーバーサイド・クライアントサイド両面で新たに普及させることと、すでにいずれかで広く使われている言語の利用範囲を広げること、実現するにあたってどちらが現実的かは議論の余地のないことです。

> ..略.. 少なくとも2/3のブラウザはDartをNativeに実装することになると思います。

楽観的な予測過ぎてご自身でも信じているとは思えません。Google自身もそこまで楽観的な予測はしていないはずです。もちろん5年先、10年先の話をしているのなら可能性はゼロとは言いませんが・・・。

> Dartの言語仕様は、最新の言語だけあって、C#と同様に洗練され美しいです。

審美眼は人それぞれですが、私はDartを「ダサい」と感じました。Go言語の方が美しいです。

通りすがり２ 2012/08/08 20:07 今さらですが、たまたま通りすがったので書き込ませていただきます。

１．
「既に流行ってるものがあるから新しい言語を公開することはそもそも問題の解決になりません」っていうのは論理としてはおかしい気がします。開発規模が大きくなって 問題が表面化し、PHP 等の既存の言語で対応できないとなれば、代替言語が出てくることは自然だと思います。

２．３．
個人的には、前の方がおっしゃるようなサーバーとクライアントを同一の言語にするのは本質ではないと思います。（メリットは無いというということはないですけど）多分、一番大きな問題は、クライアントサイドの開発において、JavaScript では大規模の開発を行うのに言語仕様上の無理があり、それを解決する必要があるという一点だと思います。サーバーサイドは言語の選択が自由ですからね。

おっしゃる通り、クライアントサイドで使える言語を増やせば確かに解決すると思います。
それは、全てのブラウザでその言語をサポートをさせるってことですよね。例えば、Python を全てのブラウザで使えるようにしろ、と。ですが、激しい企業間のブラウザ競争で、それは簡単なことではありません。例えば Microsoft は JavaScript を推進しており、別言語の導入に否定的な会社もあります。また何億もかかる新言語のエンジンの開発に、ブラウザ各社全てが簡単に賛成するはずもありません。Google の力をもってしても Google が言い出した言語を全社の全ブラウザにサポートさせることは無理ということです。一方、勝手に Chrome だけにサポートさせたとしても、全てのブラウザで使えない言語なんて流行りません。

となると、JavaScript の問題を解決するために残された Google の選択肢は、全てのブラウザで動くJavaScript を利用する方法以外は結局ありません。つまり、JavaScript の問題が発生しない言語を作って JavaScript に変換することで、全てのブラウザでの動作を保証するという方法しか残されてないわけです。

他の Ruby や Python 等の良質の言語は確かに有用ですが、JavaScript に変換することを考慮して設計されていないので無理があります。例えば、直接ファイルを扱えない JavaScript に、Python のファイルの処理を変換させるなど不可能です。

また、Google は JavaScript や HTML5 の仕様策定の場でずっと処理速度が遅いものに反対してきたように、モバイルデバイスでも快適に動かすために速度を重視してきました。Ruby や Python 等の言語を仮に JavaScript に変換できたとしても、無理やりな方法で変換しても、スピードは出ません。

結局、Google に出来ることと言えば、JavaScript の問題が発生せず、かつ JavaScript に変換しやすい新しい言語を設計するという方法しかなかったのだと思います。きっと、できることであれば、Google も新しい言語よりも、既存言語が使いたかったことでしょう。

今後数年で HTML5 が普及し、クライアントサイドの大規模開発が増えると、いずれ JavaScript の限界が表面化してくることは目に見えています。そこでブラウザ競争の中の新たな一戦略として Google が先手を打った、それが Dart なんだと思います。

通りすがり２ 2012/08/08 20:26 書き忘れましたが、もし Google の読みが当たり、開発中に JavaScript の限界にぶち当たることが増えれば、世の中的に Dart 以外の選択肢がなく、使わざるを得ない状況になると思います。とりあえず全てのブラウザで動いて、JavaScript の問題が解決できるのですから、使わない手はありません。この戦略で普及させておいて、競合他社のブラウザに Dart エンジンを対応させざるを得ない状況を狙ってるのだと思います。

もちろん、Microsoft のように「JavaScript で十分」という方が世の中的に正しいとなれば、Dart を使う必要には迫られなくなり無くなっていくと思います。まぁ、Microsoft もきっと JavaScript の問題には気づいているでしょうけど、大金を投資して対策するだけのメリットが無いという判断なんでしょう。このあたりはブラウザ開発各社間の戦略の違いだと思います。

technohippy 2012/08/09 11:59 コメントありがとうございます。普通あんまりコメントなんてつかないブログなんですが、なぜかここだけ大人気ですね・・・。

> １．「既に流行ってるものがあるから新しい言語を公開することは
> そもそも問題の解決になりません」っていうのは論理としてはおかしい気がします。

おっしゃることは正しいと思います。その論理はおかしいですね。

ただ、私はそうは言っていません。そもそも私のコメントはその前の方のコメントへの返答なのでそのコンテキストに沿って理解していただけるとありがたいです。

> １．サーバーサイドで最も使われているスクリプト言語である
> 　　PHPは脆弱性の高いコードを作りやすい仕様であるため、
>　　代替言語が強く必要とされている。

という先のコメントに対して、既にPHPよりも出来がいい代替言語はたくさんあるのにPHPは未だ人気なのだから、PHPがダメ言語であるという問題の解決策としてDart開発を位置づけるのはおかしい、と答えているまでです。つまり通りすがり2さんが言及している部分は単に「前の方の1の意見は論理的におかしい」と指摘しているだけです。

それ以降は要は「JavaScriptに変換される新しい言語っていいよね」ということかと思うんですが、もしそうならGWTがあればそれでよくありませんか？（Dart登場当初から各所で言われてることですが）

通りすがり2さんの論理では既にGWTがあるのにDartを公開したGoogleの意図を全く説明できません。

私としてはDartの本当に素晴らしい部分は通りすがり2さんが無視しているVMの実装にあるのだと思います。コア開発者の専門もそこですし。私は専門外なので具体的にどういった工夫がなされているかまでは分かりませんが、おそらく彼らがそれまで様々なVMを開発してきた経験から得た知見がたくさん盛り込まれていることでしょう。ただ、JavaScriptに変換するとその部分は生かされませんし、かといってDartVMが全ブラウザに乗るというのはなかなか考えづらい未来です。

・・・

あとは、気になった部分についていくつか個別に反応します。

> 他の Ruby や Python 等の良質の言語は確かに有用ですが、JavaScript に
> 変換することを考慮して設計されていないので無理があります。例えば、
> 直接ファイルを扱えない JavaScript に、Python のファイルの処理を
> 変換させるなど不可能です。

DartにもファイルIOライブラリはあります。その理屈だとDartもJavaScriptに変換するのに無理がある言語ということになりませんか？

> もし Google の読みが当たり、開発中に JavaScript の限界にぶち当たることが
> 増えれば、世の中的に Dart 以外の選択肢がなく、使わざるを得ない状況になると
> 思います。

そもそも、JavaScriptに変換する言語でJavaScriptの限界を超えられるものなんでしょうか？

Dart以外の選択肢がないという話ですが、大規模開発を目的としたJSコンバーターな言語としてはGWTやheXeは昔からありますし、今ならJSXというものもありますね。CoffeeScriptはパフォーマンス向上を目的にしていなさそうですが、まぁこれも昔からあります。私が知らないだけでJSに変換される言語というのは他にもあるんじゃないでしょうか。

通りすがり2 2012/08/13 05:33 こんにちは、通りすがり2です。
やっぱり議論を巻き起こしやすい話題なんだと思いますよ。
ではレスしますね。

１に関しては、PHP を置き換えるために、他に色んな言語があるのだから Dart である必要性はない、ということだったのですね。すみません、それだと同意します。もちろん Google がサーバーサイドにまで問題を見出していて、その解決に代替言語が使えないと思っているのであればその限りではありませんが、私はそこではなくて、Google は基本的にクライアントサイドの JavaScript を問題視していると思います。

>それ以降は要は「JavaScriptに変換される新しい言語っていいよね」ということかと思うんですが

すみません、そう纏められてしまうと、私の論点はかなり違ってます。おっしゃる通り、JavaScript に変換できる方法だけなのなら、山ほどあります（不勉強で JavaScript のコンバータは詳しくありませんでしたけど）。私もだらだらと書かずに、まず整理して短くまとめておけばよかったですね。

＜問題提起＞クライアントサイトでは不完全な JavaScript しか使えないのは問題である。
・もちろん Python や Ruby 等を実行させられればよいが、I/O 等が制限されているブラウザではそれも不可能である。
・いきなり新しい言語を作って、他社のブラウザにまでサポートを強要するのは難しい。
・結局、Google が今取れる現実解として、全ブラウザで動作させられる JavaScript にも変換できる新しい言語を作って徐々にシェアを伸ばし、最終的に世の中のクライアントの標準言語を Dart に置き換える。

となるでしょうか。「JavaScript に変換できるといいよね」というのは、Google が今取れる現実解として強く必要とされている要素（それが無ければ流行らない）なだけで、極論、JavaScript が無くなるのが一番いいとまで思っていると思います。

>もしそうならGWTがあればそれでよくありませんか？

GWT も、Google が JavaScript を問題視していることを強く証明するプロジェクトですよね。GWT 自体は Java と JavaScript 使って今の環境に強引に利用できるようにした程度のもので、結局それだと根本的な解決にならなかった、というように私は理解しています。Java だと厳密な記述ができるので JavaScript よりも厳密で大規模開発に適していますが、そもそも Java を JavaScript に変換するという部分にも無理がありますし、それが普及すれば、結局不完全な JavaScript が生き残ってしまいます。Google は、小手先の変換ではなく、「不完全」な JavaScript を「完全」な Dart に置き換える戦略を取っています。また、企業の立場から言えば、サーバー側のプラットフォームは他社が力を持っている Java に限定されるという問題もあります。結局、JavaScript の問題を解決しようとして色んな提案をしていて、その一つが GWT だったわけで、確かにそれなりに健闘したのですが、でもやっぱり無理があったので、より上位の提案として次は新言語 Dart 戦略を提案してみてはどうか、という流れになったのだと思います。

>DartにもファイルIOライブラリはあります。その理屈だとDartもJavaScriptに変換するのに無理がある言語ということになりませんか？

ならないと思います。なぜなら、作る時点からブラウザ上で動作するプロファイルと、一般用途・サーバー向けのプロファイル（I/O ライブラリ等はこっち）を完全に切り離して設計できるからです。これは JavaScript の存在に関係なく、ブラウザとサーバーそれぞれで動作させようとすると自然とそうなるはずです。そして、ブラウザ用のプロファイルを、JavaScript にも変換しやすい言語仕様にし、クロスコンパイラを作ればよいということになります。一方、Python 等の既存の言語では、例えば I/O ライブラリが使える前提で既に大半のライブラリが作成されてしまっているため、１つでもそういったライブラリを含んだものはブラウザ上で実行不可能ということになり、変換不可能ということになります。

>そもそも、JavaScriptに変換する言語でJavaScriptの限界を超えられるものなんでしょうか？

その論理は、極端な話「C 言語から機械語に変換して、機械語を超えられるんでしょうか？」と言ってるようなものだと思います。ご存知の通り機能的には無理ですし、機械語にできないことをやるために C 言語が存在しているわけではありません。あくまでもより効率的、人間が理解しやすい形で簡単に作れるという意味で機械語の「限界」を超えているわけです。同様に、JavaScript に元々できない機能的な部分を Dart にさせるということではなく、人が大規模開発においてより効率的・トラブルを起こさない開発を可能にする、という意味での JavaScript の「限界」を超える、という意味です。

>私としてはDartの本当に素晴らしい部分は通りすがり2さんが無視しているVMの実装にあるのだと思います。

VM に関しては、おっしゃる通りまずは Dart の普及が不可欠ですので、私はそこまで重要だとは考えていない立場ですね。VM のメリットが最重要なのなら、Java ベースの技術の方がよかった気はしますし、それが普及の決め手になるとは思えません。ですが、私が問題にしているクライアントサイドの問題が原因で、もし世の中が Dart を使わざるを得ない状況に追い込まれたら、その後は Dart は普及し、DartVM は力を発揮しそうです。私は、やっぱり普及しないと力を発揮できない VM よりも JavaScript の置き換えが最優先課題じゃないかなって思ってますね。

あと全体的に、Google という一企業の立場という視点を考えると、結構 technohippy さんの提案に無理があるるなぁって感じてます。「サーバーサイドで使われているRuby/Python/Perlなどをクライアントサイドで使えるようにするのが本筋ではないでしょうか。」「Dart以外の選択肢がないという話ですが」といった部分も、１ユーザーからしたらそう思いますが、Google の立場に立つと様々な他社さんが絡んできて、ライセンスとか力関係とか色々ありますので、自社で作った方が会社としては正解っていう場合もあると思います。

通りすがり2 2012/08/13 05:52 すみません、読み直して補足です。

>そもそも、JavaScriptに変換する言語でJavaScriptの限界を超えられるものなんでしょうか？

（初めの書き込みの続きです）
もちろん、JavaScript にできない Dart ならではの機能を持たせることもできるでしょうが、当面 Chrome でしか動かないということになるとその機能は意味をなさないことです。まずは JavaScript へ変換できる範囲の機能を持たせることが最優先課題で、ある程度普及してくれば、Dart を直接動かせるブラウザだけが恩恵を受けられる独自機能が増えてくると想定されます。ですが、Dart だけを充実させていくのは次の話だと思います。

（自己レス）
>あと全体的に、Google という一企業の立場という視点を考えると、結構 technohippy さんの提案に無理があるるなぁって感じてます。

訂正します。
→結構 technohippy さんの提案に無理があるなぁって感じることが何度かありました。

technohippy 2012/08/16 15:30 一応ひと通り読んだ私の回答としては未だ「GWTでよくね？」です。もしGWTをちゃんと調べたことがないのであれば、おそらく通りすがり2さんが考えているよりはずっとちゃんとしたプロダクトなので一度やってみるといいと思いますよ。

いろいろ返信しようかと思って途中まで書いてたんですが、ぶっちゃけ面倒くさくなりました。ごめんなさい。通りすがり2さん自身がJavaScriptに感じた問題点や実際に体験した不都合の記述がほぼなく、一般論ばかりなので話がまとまる気がしませんし・・・。あと、せっかくの長文コメントですが、私はそれにひとつひとつコメントするほど現時点でDartに情熱がありません。

通りすがり2さんのDartへの情熱はこのコメント欄ではなくご自身のブログにぶつけるのがいいかと思います。このコメント欄にリンクを張っていだだけたら拝読に伺いますので。

通りすがり2 2012/08/18 05:35 何度も長文申し訳ありません。ブログにしようとすると前後の流れを全部まとめないと、初めての方が訳がわかりませんので、今回は最後にコメント欄をお借りして、返答とまとめをして退散します。

>もしGWTをちゃんと調べたことがないのであれば

昔クラウドの波が来た時に、一通りサービスの技術調査をやってた時に Google App Engine を調べてたことがありまして、その時に GWT がサポートされてましたので、ついで程度にちょっとしたアプリケーションを GWT で作ったことぐらいならありますね。GAE が値上げされる前の話なので、もう１年以上かな、古い GWT ですけど、当時は何をどう Java から JavaScript に変換してるんだ？っていうのが気になって、吐かれた JavaScript を読んだものです。もちろんそれだけで本質が分かったと言えるレベルには達してないですけどね。

>通りすがり2さん自身がJavaScriptに感じた問題点や実際に体験した不都合の記述がほぼなく、

それを書き出すと書ききれないほどの長文になってしまいますし、調べれば嫌というほどヒットしますし…。軽く書くと、私も C, C++, Java, Perl, PHP, Ruby, C# と（主にオブジェクト指向言語を）色々やってきましたが、そもそもプロトタイプ系のオブジェクト指向言語に慣れてないという自分の側の理由で JavaScript は扱いにくかったですね。そもそも仕様上バイナリが扱える前提で作られてないために強引に BASE64 経由で文字列で扱わないといけないとか、クラスにスタティックメンバが作れないとか。そうそう、後者の件について、プロトタイプ系は C++ や Java 等の大規模開発で使われる一般的なデザインパターンが利用できないことになるので、どう大規模設計するんだろうと思ったことはありました（別の方法論があるのかな？）。他にも、例外処理から、変数定義から、クラス定義から、宣言に基づいた型の制約が無く、全部曖昧なのも気になります。これでバグ無しで作れるのかなぁ、と。まぁ、きちんと JavaScript に使い慣れた人だったら私の例ぐらいだったら解決策を知っているのかもしれないですけど、問題を見出している専門の方が多くいるのもまた事実です。やっぱり EcmaScript 自体がもともと貧弱で、それに思うがまま整理せずに拡張に拡張を重ねた言語だけに、洗練されていない部分があるんでしょうね。逆に、JavaScript を特徴づけるクロージャ等の仕組みはプロトタイプ系の言語ならではの機能で、よく考えられてるな、なるほどなって感じることもありました。

ちなみに、私自身はありのままの事実や客観的な見解を述べている感じで、確かに Dart に期待はしてますが、別段 Dart に情熱があるとか Google の肩を持っているというわけではありませんよ。個人的には、GWT については、仕事ならともかく、プライベートで Java 環境を用意しないと使えないっていうので、ちょっとサービスを作って一般公開するには使いにくくて、JavaScript も（少なくとも自分のスキルや思想では）個人的に使いにくくて、そうなると Dart に期待せざるを得ないっていう感じの立場ですね。ぶっちゃけ、Dart もリリースからほとんど大きな動きは無い感じですし、もう Google も諦めかけてるんじゃね？って思ったり思わなかったり（笑）まぁ、Dart が流行るかどうか五分五分か、それ以下かなぁって思ってます。

あ、限界を超える云々の話ですが、もし Dart を JavaScript に変換することでその「限界」が超えられないとすれば、Java のコードを変換してクライアントで JavaScript を実行させる GWT でも同様の「限界」が存在することになります。つまり、GWT でも Dart でもどっちも大規模開発では使えない、という結論になってしまいます（矛盾）。よって、GWT にできるなら、Dart にもできるはずです。ここからでも、正解は導けましたね。

通りすがり2 2012/08/18 05:35 では、この機会に GWT に対する Dart のメリットをまとめてみたので、それをきちんと整理して最後にします。

・GWT や Dart の存在から、少なくとも Google にとって JavaScript は不完全なもので、後々のために置き換えたほうがよいと考えている。また、少なくとも、Google は GWT を発表した後に自分で GWT を否定する Dart を発表している。これは Google が GWT が不完全であり、Dart がより上位の提案だと考えている証拠となる。

・GWT は Java や JavaScript を使っている。これらは自社の技術ではないので、例えば Java を GWT のために拡張したい場合でも、Google の都合だけで自由な拡張ができない。一方、Dart は自社技術であり、自由な変更ができる。それどころか、もし普及に成功した場合には、クライアントサイドの Web 技術の主導権（利権）を、Google が握ることが出来る。（Microsoft 等の競合他社はこれが怖いから Dart に反発してるんですけどね。JavaScript の問題点を認識してないわけではなくて）

・GWT は JavaScript を使っている。つまり、Java からの変換が必須となる。変換されたコードには必ず無駄がありソースの可読性やパフォーマンスに支障が出る。Google は、Web プラットフォームにおいて何よりも処理速度を重視しており、特にモバイルで遅いのは致命的である。また、世の中の Web のスタンダードを、GWT から変換された遅くて不完全な JavaScript のコードに埋め尽くされるような汚い状態にするべきではない。（変換に限界があるのは technohippy さんの記事に書かれてる通りですね）

・サーバーサイドにおいて、GWT の動作には Java の動作環境が必須である。ところが、安価な共用サーバー等を含め、Perl や PHP に比べると Java は全ての一般的なサーバーで動かせるとは言いにくい。中小企業が世の中の大半を構成していることを考えると、これは小さい問題ではない。恩恵が受けられる企業やユーザーが限られるのは標準技術として好ましくないし、それによって普及や拡大に大きな支障が出るという問題もある。

・GWT は開発者に非常に近い技術で、開発者以外は扱いにくい。例えば、Web デザイナーが CSS と同時に JavaScript を学んでクライアントサイドのデザインや開発を行うことがあるが、難解・支配的な GWT（+Java）を学んでクライアントサイドの開発を行うことは期待できない。一方、デザイナーは JavaScript のような感覚で Dart を学び、jQuery を導入するような感覚で Dart ライブラリを使えれば、クライアントサイドのデザインや開発が可能になる。

・GWT を使えば JavaScript の問題を間接的に解決できるとしても、サーバーサイドで既存の PHP や Ruby 等の資産をベースにするような場合や、予め環境が決まっている場合において GWT を使えない場合がある。GWT を使わない場合、結局クライアントサイドは JavaScript を利用する必要があり、その場合は JavaScript の不完全性に直面する。その場合にクライアントサイドのみを Dart に変えられれば、過去の資産との共存ができる。（少なくともサーバー・クライアント両方を縛る GWT ほどの制約はない）

もちろん Java のライブラリが使えないとか Dart 側にも色々デメリットもあるでしょうが、メリットだけをざっと羅列したらこんなところでしょうか。意見は色々あってもいいと思いますし、正解が一つあるようなものではないので、適当に読み流していただいて結構ですよ。

# っていうか、無くなりかけてた JavaScript に再び脚光を浴びさせたのって、Google なんですけどね…。

うわ、また長文になってる…。
何度も長々とお付き合い＆乱文失礼いたしました。

technohippy 2012/08/20 12:04 ありがとうございます。多分、これが私の最後の返答です。もちろん通りすがり2さんからさらに返答があれば読ませてはいただきますが。

通りすがり2さんのJavaScriptへの不満はまとめると次の二つのように思います。
1. バイナリが扱えないこと
2. クラスベースオブジェクト指向ではないこと
1に関しては今のJavaScriptはTypedArrayがあるので大丈夫です。2に関してはJSはそういう言語なので。たとえば、Dartにはプロトタイプベースのオブジェクト指向を実現するための機能がほぼありませんが、それに文句を言われても困りますよね。

通りすがり2さんとの基本的な考え方の違いとして、私はDartを「JavaScriptの限界を超えるために開発された言語」とは全く捉えていません。JavaScriptは多人数大規模開発には向かないのでそれに向いた言語としてDartを作った、と考えています。通りすがり2さんは向き不向きを限界と表現しているのかも知れませんが、その言い換えは誤解を招くと思います。

で、向き不向きの話なので、おそらくGoogleもJavaScriptを撲滅することは予想も希望もしていません。クライアントサイドでDartとJavaScript、より適した方を選択できるようになることを最も望ましく思っているのではないでしょうか。

あと、DartがGWTを置き換えることについては、Googleは少なくとも公式には否定しています。最近Google GroupsのUIが刷新されましたが、そのUIもGWTを使用しているそうですし、完全に置き換えたいと思っているとは考えにくいですね。

あとは個別に気になったところを。

> GWT から変換された遅くて不完全な JavaScript のコードに埋め尽くされるような汚い状態にするべきではない

以前聞いたGooglerの話によると「GWTの最適化は相当なレベルに達しているので、標準的なJavaScripterの組んだJSよりもGWTから変換したJSの方が早い」ということでした。Google I/OでV8上でのJavaScript高速化の話がありましたが、あのセッションを聞くとたしかに機械的に最適化した方が早いと思えます。

> サーバーサイドにおいて、GWT の動作には Java の動作環境が必須である。

どうしてもGWT RPCを使いたければそうかも知れませんが、JSONでのやりとりでよければその限りではありません。

通りすがり2 2012/08/21 22:53 こんにちは。前回書き込んだ後に色々調べてたのですが、公式の社内文書を見つけ、確実なことが色々とわかったので、補足と訂正があります。最後と言いながら、やっぱりレスせずにいられなくて…、すみません、もう少しだけ…

この文書は Dart 戦略を始める際に Google 社内で送られたメールが流出したものらしいです。（英語の原文です、また Dash は Dart を指しているとして以下読み替えあり）
https://gist.github.com/1208618

＞向き不向きを限界と表現しているのかも知れませんが
私としては、向き不向きではなく、根本的な言語仕様の欠陥による「限界」を意味しています。Java や C# のような昔の言語の欠陥を研究した上で洗練された後発の言語に私の意味での「限界」はありません。

＞通りすがり2さんのJavaScriptへの不満はまとめると
前のレスに関しては書いているときに思いついたことを少し挙げただけなので、それ以外にも JavaScript の仕様に対して色々思うことはあるってのだけ付け加えておきます。（色々言いたいこともあるのですが、また長くなるので我慢します）

＞JavaScirpt は今はバイナリは扱えます
言語仕様上、バイナリが扱えない時期があった時点で、JavaScript にもともと欠陥があったと言えないでしょうか。元々バイナリが扱えない標準言語なんて他にありますか？また、そんな言語が「下位互換を残しながら」不足している機能を付け加え続けることに無理があるとは思いませんか？「TypedArray が最近は使えるが、実は内部的には JavaScript の仕様に沿ってバイナリを文字列として扱っているだけで、処理の効率は悪い」といったような不自然な実装にもなりかねません。また、バイナリが扱えないだけなら付け加えるだけで済みますが、下位互換を残すために型の種類を整理できないとか、バージョンアップで直せない欠陥が多々あります。

＞向き不向きの話なので、おそらくGoogleもJavaScriptを撲滅することは予想も希望もしていません。
上の公式書類によると「JavaScript を捨てて Dart 一本に絞って戦う戦略は、うまく行けば技術的にも会社的にもハイリターンだが、JavaScript への発言力がなくなってしまい、さらに Dart が失敗した場合は Google は全てを失ってしまう。この非常に高いリスクを考えると、結局両方を並行してやる戦略が最善である」と書かれていました。なので私も訂正です、Google が JavaScript に対しても力を入れるというのはその通りでした。すみません。一方で、向き不向きのために両立させているのではなく、会社間の競争や力関係が原因であることがわかります。さらに、JavaScript を切り捨てる Dart 一本の選択肢も考えていた形跡があるということは、技術的には JavaScript を十分に Dart だけでカバーできるという事実も導け出せます。

また、
１）JavaScript 自体が下位互換性を保って発展してきたため、根本的な言語仕様の問題を改善するタイミングを失ってしまっている
２）Dart は、古い JavaScript を徹底的に研究し、その長所や手軽さをそのままに、短所を補い、さらに現在の Web 事情に合うように設計されている
とも Google は言っています。JavaScript と Dart は単に性質の異なる２つの言語の向き不向きという横並びの関係ではなく、JavaScript を超えるために設計された上位の言語であると言えます。JavaScript に向くほぼ全ての分野で Dart は向くように設計されていますし、実用上のことも考えられているので苦手になる分野は少ないでしょう。

＞GWTの最適化は相当なレベルに達しているので
これが正しいとなると、technohippy さん自身のブログ記事中の「ネイティブのJavaScriptは常にコンパイルされたDartコードを打ち負かすことができるという事実は残る」というのが否定され、さらにはそれを根拠にしている記事後半の主張全てが否定されてしまいますね。私の意見は、元々の technohippy さんの記事に同意で、GWT 等でいくら最適化しようと超えられない壁があると思っています。ちなみに、JavaScript は動作速度を念頭に設計されていないらしく、速度重視で設計された Dart ネイティブに少なくとも変換で勝つことはできません。

＞GWT は Java が無くても動作させられる
Java 無しで動くのは純粋に知りませんでした、興味がある技術だけに参考になります。一方で、問題の本質は「標準技術なら世の中の大半のサーバーで動作させられることが重要」という部分なのですが、例えばデーモン設置不可、プログラムは Perl や PHP しか動かないような格安の共用レンタルサーバーでも動かせるのでしょうか。（すみません、不勉強の私には調べた限りだとそもそも Java 無しで動くという情報にすらたどり着けなかったです）

# 後で読み直して気づいたのですが、どうも私の前のレスの下の方の辺りは、クライアントサイドの言語の問題だけを解決するのにわざわざサーバー側のプラットフォームまで Java だとかなんだとかで制約がつくのは汚い、と言いたかったようです。

あと、議論に関係する公式書類をいくつか訳すと

＞◆JSCompiler と GWT の将来はどうなりますか？
＞JSCompiler と GWT プロジェクトは既に Dart プロジェクトに吸収され、一本化されている途中です。これらのプロジェクトの成果は、Dart に全てを統合するための方向性を示してくれました。現在のバージョンの JSCompiler・GWT を使っているチームには長期間サポートを行って共存する形を取りますが、同時に Dart への移行ツール等を提供して移行を推し進めていきます。
＞◆Google 社員は今後どの技術を使えばよいですか？
＞（中略）また、現在 GWT や JSCompiler を使っているチームも、最終的には Dart コンパイラに移行させていきます。

ということで、GWT は今後緩やかに Dart へ移行していくようですね（Dart ベースの技術として生き残る？）。また、この Dart 発表の公式書類の著者には GWT の責任者の名前も入っているようで、同じ会社の技術である GWT と、それを改善したという立場である Dart を対立関係にすること自体がおかしいことでした。

通りすがり2 2012/08/21 22:57 長々と議論してきましたが、記事に対する私の意見を簡潔にまとめて最後にしたいと思います。（最後になるかな…）

1. ウェブのための構造化されていて柔軟なプログラミング言語を創り上げること。
＞単に選択肢が増えるだけだ。

クライアントサイドで利用可能なのは現在 JavaScript しかなく、それでできないことを可能にするという意味で「単に選択肢が増えるだけ」というのは間違いということになります。

2. Dartはプログラマに馴染み深く自然な印象を与え、簡単に学ぶことができる。
＞何故既存の言語を選ばなかったのか？

既存の言語は、ブラウザ用のプロファイルとサーバー用のプロファイルが分離されていないため利用できなかった、ということです。

3. Dartはあらゆる種類のデバイスに対応する。
＞さらに新しい言語の細分化を招くんじゃなくて？

言語が増えることは確かに細分化につながると思います。なので Google にとっても新言語の提案は苦肉の策だと思います。だからと言って、他の言語を使うことが無理で、現在の JavaScript にもできないのであれば、他に選択肢がありません。

4. Dartをすべてのメジャーでモダンなブラウザで高速に動作させるツールを提供する。
＞他社のブラウザはネイティブ対応なんてしないだろう

JavaScript へのコンパイルで動作が遅くなることが挙げられていますが、「最適化を行って変換することでより高速化する GWT の例がある」とご自身でそれは否定されました。ということは、全てのブラウザで動き、ネイティブ対応しなくても高速に動作するので問題ありません。（なお、私は変換で必ずしも高速化しないと考える立場で、だから変換が十分有用だとしても GWT も汚いと感じますし、変換のデメリットがあると思っているので、他のブラウザに Dart をネイティブ対応せざるを得ない状況にすることが重要であると考えています。できなかった場合は速度の面で Dart は不利です）

＞（JavaScript は）世界で一番利用されているプログラミング言語であるにもかかわらず、

言語が素晴らしいから流行ったわけではなく、クライアントサイドにそれ以外の選択肢が無く、使わざるを得なかったからと考えます。でなければ、素晴らしいはずの JavaScript にわざわざ変換する GWT や CoffeeScript みたいなものが存在することが説明できません。HTML5 を機に大規模開発への世の中の流れがあり、JavaScript ではそれに耐えない欠陥を多く抱えているため、今後を見据えて仕方なく Dart を作る羽目になったという感じだと思います（公式文書からもそういう雰囲気が伝わってきます）。

gi-chi 2011/10/14 05:04 Go言語の公開は2009年

technohippy 2011/10/14 08:58 おお、昨年じゃなかった。修正します。ありがとうございました。