確かに、Java、C++、C# などの主流派の言語では「クラスベース」を採用しているので、クラス機構を持つことがオブジェクト指向言語の必須の要件でもあるかのように誤解されることが多いようですけど…。オブジェクト指向のやり方にも 「TMTOWTDI」 (There's More Than One Way To Do It. [wikipedia.org]:やり方はひとつじゃない)っていう Perl の格言が当てはまるわけですねぇ~
Dynamic HTML … 懐かしい響きですねぇ。(ノ∀`*)。 たしか Netscape Navigator に導入された独自拡張の一つでしたよね? それで Internet Explorer でも導入されて、第一次ブラウザ戦争(第二次?)になっていたのでした。
個人的にはまだ、マシンも非力で、ダイヤルアップ接続だったので、スクリプトの仕組みははっきり言ってウザイと感じていた部分も多々ありました。時代が過ぎて、マシンも回線も当時に比べれば遥かに強力になりましたけど、それに比例するかのように Dynamic HTML コンテンツの方も、にデカクなってしまって、なぜかモッサリ感のあるページが多いような…。
基本料無料 (スコア:5, おもしろおかしい)
Re:基本料無料 (スコア:2)
永世小学六年生神アイドル支持者(バランス取らなくっちゃなぁっ!!)
言語名 (スコア:1)
JSFrontではないんだな。
いずれネイティブ環境ができたらJS++と呼ばれたりはしないんだな。
ふーん、 (スコア:1)
Js_of_ocaml [ocsigen.org]でいいや。
Re: (スコア:0)
ocamljsだと思ったら本当にJs of ocamlで別モノだった
思い出したのは… (スコア:0)
FORTRANやBASICをC言語風に拡張するRatforやRatbasといったプリプロセッサ。
JavaScript用のプリプロセッサは簡単な最適化や難読化するものぐらいしか知らなかったけど、いい所に目をつけたって感じです。
# 作者は Software Tools の読者なのだろうか?
Re:思い出したのは… (スコア:3, 参考になる)
ブラウザ上のJavaScript実行環境で使える(JavaScriptにトランスレートできる)言語としては、
機能的にほぼJavaScriptと1対1対応する(という点ではRatforに近い)CoffeeScript [wikipedia.org]とか、
独自VMもあるけどJavaScriptへの変換もサポートしているGoogleの Dart 言語 [srad.jp]とか、
先行する言語はいくつかありますね。
それらと較べて、3番煎じなJSXにどんなメリットがあるのは知りたいところです。
Re: (スコア:0)
世界のgeekがN番煎じを作る
→ 「意欲的だなあ」
日本の技術者がN番煎じを作る
→ 「何の意味があるの?車輪の再発明乙。これだから日本人はだめなんだよ」
Re:思い出したのは… (スコア:1)
「意欲的」というのと「実用的」というのは別だしね。
たとえ端から見ている分には面白くても、実用的で無ければ使いたいとは思わない。
N番煎じで、しかも日本国内限定の(世界的に見れば)知名度の低い会社で作られた言語。
なにより不安なのが、この後も開発やバグフィックスが続くかどうか。
有料化すればまだいい方で、業績が傾けば真っ先に切り捨てられるのはこういう部分。
コミュニティが育っていればコミュニティ任せにするのもありだけど、このままだと鳴かず飛ばずで
消えていく可能性の方が高いし、そういう言語だからこそコミュニティに参加する人も少なくなると思う。
Re: (スコア:0)
自分達が必要としているものを作る、
と言う企業のオープンソース施策としてはありがちな話なんで、
無理に難癖を探すほどの興味は湧かないなぁ。
Re: (スコア:0)
日本企業なんだから日本語のスライドにしてよ、と思いました。
Re: (スコア:0)
このコメントツリーにあるようなネガティブな日本人は、最初からターゲットにしていませんという意思表示だったら、いい皮肉だなあ。
コミュニティに任せる事ができるのは、コミュニティを作る人とそれに乗る人がいてこそです。
#同じアホなら…
こうやって、新規技術が出てきてもケチ付けるだけ付けて使わず、様子見して有名になってから尻馬に乗るかって思ってる人ばかりじゃ、日本から基礎技術やデファクトスタンダードが出てこないって当然の話です。
Re:思い出したのは… (スコア:5, 参考になる)
私の意図としては、大元のコメント [srad.jp]が
と、既にそういうアプローチがいくつかあることを知らないような内容だったので、そこにツッコミを入れたかっただけなんですけどね。
私の書いた [srad.jp]
という文章にツッコミが入れられてる感じですが、先行する同種のプロダクトがあるなら、それと比較するのは当然のことでしょう。この分に「車輪の再発明乙」みたいなネガティブなつもりは全然ないのに、なぜかネガティブな日本人扱いされちゃうし…
で、スライド見るとちゃんと既存のシステムとの比較が書いてましたね。適当に和訳すると
○Google Web Toolkit(Java からJavaScriptへのトランスレータ)
・Javaコードと変換後のJSコードで微妙に挙動が違うのでデバッグしづらい
・変換で速度やサイズのオーバーヘッドが発生する
・JavaScriptのライブラリと組み合わせるのが難しい。
→JSXは以上のような問題は発生しない。
○Google Closure Compiler (JavaScriptの最適化ツール)
・型情報のアノテーションに基づいたJavaScriptの最適化を行う
・記述は困難でメンテナンスしづらい
→JSXは厳密な型付を行うので記述上の問題は発生しない。ClosureCompilerで適用可能な最適化は総てJSXでも可能(初期JSXはClosureCompileで処理できる完全なアノテーション付きのコードを生成できてた)
○Dart(Googleによる独自言語。VMもあるし、JavaScriptへのトランスレータもある)
・JSに変換したコードは動作が遅い
・Chrome以外はネイティブ言語としてサポートされそうにない
○ActionScript3(Flashが使ってる言語。JavaScriptに対して、クラスと型が拡張されている)
・JavaScriptに変換するのは無理
・ネイティブな性能は出せない(型情報に基づいた最適化は、JITのサポートが必須)
といったところでしょうか。CoffeeScriptとの比較はありません。
CoffeeScriptはほぼ1対1でJavaScriptに対応するシンタックスシュガーレベルの言語だから比較対象外としたのかな?
JSXの処理系が最初はClosureCompilerへのトランスレータだったのを、JavaScriptへのトランスレータとして完成させたってことで。
アプローチとしては、Google Closure Compiler をベースとしてその性能を実現した上で、記述性向上のために独自言語を作った、って感じですかね。
ちゃんと、先行するプロダクトの問題調査をしている、正しいN番煎じだと思います。
Re: (スコア:0)
ドキュメント類が日本語で完備されてるならメリットにならないかなw
JavaScript自体を拡張してほしい (スコア:0)
こういうのもいいけど、JavaScript自体をまともな言語にしてほしい・・・
Re:JavaScript自体を拡張してほしい (スコア:3)
じゅうぶん、まともな言語だと思いますよ。class 構文すらいらないのに、強力なオブジェクト指向機能を持つという、シンプルで素晴らしい言語であります。正しい書き方を覚えれば広域変数も汚さず、なんら不自由はありません。唯一の欠点は、インタプリタの高速化が難しいことだと理解してますが、それもコンピューター自体の高速化と、実行エンジンの工夫と努力によって補われつつあります。
しかも、ブラウザ自体にこれまた強力な JavaScript ビルドインデバッガがあるのに、十分、生産性の高い JavaScript を置き換えてしまおうというのは、筋が悪いように見えます。
Re:JavaScript自体を拡張してほしい (スコア:2)
「class 構文すらいらないのに、強力なオブジェクト指向機能…」 とのことですが…、JavaScript が採用しているオブジェクト指向を体現するアプローチが、三大アプローチの
の中のひとつ、「プロトタイプベース」ってことはご存知でしょうか?
確かに、Java、C++、C# などの主流派の言語では「クラスベース」を採用しているので、クラス機構を持つことがオブジェクト指向言語の必須の要件でもあるかのように誤解されることが多いようですけど…。オブジェクト指向のやり方にも 「TMTOWTDI」 (There's More Than One Way To Do It. [wikipedia.org]:やり方はひとつじゃない)っていう Perl の格言が当てはまるわけですねぇ~
(゚ω^* )♪
Re: (スコア:0)
それなりの品質の技術者をそれなりの値段で使わざるをえない現状では
正しい書き方に習熟しなくてもそれなりの品質が維持できるのが良い言語なんだよなぁ
Re:JavaScript自体を拡張してほしい (スコア:1)
ていうか、ブラウザでJavaScript以外の別の言語を使えるようにすれば全て解決する話なんじゃ……
# Perl信者 vs Python信者 vs Ruby信者 の戦いが今はじまる
1を聞いて0を知れ!
Re:JavaScript自体を拡張してほしい (スコア:2)
趣味でプログラムを書く私個人的には嬉しいですが、Web関連の開発者にとっては単に悩みの種が増えるだけのような気もします。
# ふとWindowsのActive Scriptingを思い出しました。これって流行ったんでしたっけ?
DON
Re:JavaScript自体を拡張してほしい (スコア:1)
ブラウザベンダの妥協の産物なんじゃない >> JS
IEみたいに みたいな感じで:言語拡張ができそうなものはあるけど、非IEユーザとその処理系のインストールが必要だし。
Silverlightとかも、インストールされていない環境があるし。
Chrome native clientみたいなのもの Chromeの x86系に限定されるし。
java appletは動作がアレすぎたし。
結局の所、標準的に広く使えるようにするのは難しいと思う。
一時期、 flash の active scriptが良い感じに行き渡っていたけど、iphoneに一蹴されてしまったよね。
で残ったのが、javascriptぐらいしか広く使える技術がないと残念な結果に。
思い切って、ブラウザにVMの仕様のせて、
そのVMに対してコンパイルできれば動作するみたいな、
軽量のJVMや.NETみたいなものを策定すれば、言語の壁を破れるので、好きな言語でかけてハッピーになれるのかも。
だが、それが標準で行き渡る頃には、ネットとブラウザはまったく別のものになっていそうだけども。
by rti.
Re: (スコア:0)
いや、親コメントの意味はふつーに分かるけど。
Re:JavaScript自体を拡張してほしい (スコア:1)
素朴に思ったのですけど、Java …というか、 Java Bytecode を使えるようにできないのでしょうかねぇ。もちろん、Applet というフレームワークとは完全に別物としてです。
Java Bytecode が使えれば、Java 言語はもちろん、JavaScript (=Rhino)、Python (=Jython)、Ruby (=JRuby) 、Scala、Haskel (=Jaskel)、Groovy、Clojure、Noop、Kotlin… などなども全部行けたりしませんかねぇ…。
(b^ー°)
Re:JavaScript自体を拡張してほしい (スコア:1)
IE だと JScript を使わずに VBScript を使うこともできましたね。今も生きてるかしりませんが。
それ以外には、PerlScript [activestate.com] というものがありましてな……。
Re:JavaScript自体を拡張してほしい (スコア:1)
ありましたねぇ。あれ、以前から疑問だったのですが、どうして、Perl でなく PerlScript なんていう名前にしてあるんでしょぉね? (゚∀゚)
Re: (スコア:0)
そこにlisp信者とWhitespace信者が参入する
Re: (スコア:0)
戦う以前の段階で駆逐されるわw
Re: (スコア:0)
VBS: 呼んだ?
Re:JavaScript自体を拡張してほしい (スコア:1)
古い時代をよくご存知で… (゚∀゚)
Sun Microsystems が Tcl をブラウザ言語にすべくやってましたよねぇ~。私が知る(狭い)限りでは、Tcl は今や、EDA 分野ぐらいでしか使われていないようですが…。
Tcl戦争とGuile (スコア:1)
TclはRMSに殺されたと私は思ってます。
http://www.vanderburg.org/OldPages/Tcl/war/ [vanderburg.org]
Tcl/Tkはクロスプラットフォームで動くGUIを簡潔に記述できて私は好きだったんですけどね。
RMSが汎用拡張言語として出してきたのがGuileです。
http://www.gnu.org/software/guile/ [gnu.org]
http://ja.wikipedia.org/wiki/GNU_Guile [wikipedia.org]
たしかGIMPはGuile採用してなかったっけと思ったら、Guileを使うパッチがあるってだけでデフォルトはTinySchemeだったのか。
http://old.nabble.com/GIMP-and-Guile-2.0-td31827140.html [nabble.com]
Re: (スコア:0)
>使えるようにすれば全て解決する話
全くつまらん冗談だな。ギャグならギャグに徹しろ。
Re: (スコア:0)
Rubyはchromeのnacl上で動きそうな気配がしてきましたね。
Re:JavaScript自体を拡張してほしい (スコア:1)
あおりとか罵倒とか現状擁護じゃないですよーと前置きしつつ、
まともになるための具体的な指摘が知りたいです。
元ACに限らず。
自分なりにJavascriptのイヤなところを挙げるとgenericityの無さだったり処理costの不透明さだったりするけど、それは別段他のlight weight languageでもかわんないんないからなーと思ってます。(FlexだとArray.みたいに書けるけど、自作クラスでは適用されないステキさだしw)
OO的な要素の後付け感はいなめないとして、それを再構築してくれたらなーとはおもいます。
# タイトルに「拡張」ってあるからもしかしてもっと機能が必要とことかしら?(制限する方じゃなくて翼広げる方向?)
# ところで、もうそろそろECMAScriptってよびませんか?それともE電化?
Re:JavaScript自体を拡張してほしい (スコア:1)
なんとなーく、プロトタイプベースな所か、ライブラリというか標準オブジェクトが貧弱な所か、または過去の互換性によるトラウマ的拒否反応なのかなーとか思った。
もしくはリテラルとオブジェクトの微妙な違いとか、ノンプリエンティブなところとか、かも。
javascriptが生き残ったのはプロトタイプベースだからこそと思うけど、いい加減jqueryみたいなのって組込で持って、urnかなにかで指定したい。
Re:JavaScript自体を拡張してほしい (スコア:1)
その辺は今のところ CDN を使うのが正解では。
Re:JavaScript自体を拡張してほしい (スコア:1)
問題ないように見えるのに結果がおかしいコードを前に10分以上悩んで、セミコロン自動補完が原因だと気付いたときは、ちょっとがっくりしました(^^;)
後方互換のせいでなくすわけにはいかないんでしょうけど、せめてインタプリタに対してオフにする指令が出せれば……。
Re:JavaScript自体を拡張してほしい (スコア:1)
変数の宣言を強制したりとか、データ型の指定を可能にしたりとか、…
の開発をサポートするような実装が全般的に欲しい。
ここら辺が無いから今回のトピックのようなものが出てくるんだと思う。
Re:JavaScript自体を拡張してほしい (スコア:1)
Re: (スコア:0)
DeNA「うちに言われても・・・」
Re: (スコア:0)
もともとのWeb2.0ってそういう方向だったはずなんですけどねえ。
GoogleがAJAXを発表してすべてを吹き飛ばした。
Re:JavaScript自体を拡張してほしい (スコア:1)
AJAX は Dynamic HTML (IE4 辺りで言われてた言葉) の名前を付け替えただけで、xmlHttpRequest もこの頃の IE が持っていたものです。
まだ AJAX という言葉がなかった頃から利用して、Web 向けのゲームを発表している人とかが国内にもいましたよ。
当時としては「また MS の独自拡張か」だったわけですが。
Re:JavaScript自体を拡張してほしい (スコア:1)
Dynamic HTML … 懐かしい響きですねぇ。(ノ∀`*)。 たしか Netscape Navigator に導入された独自拡張の一つでしたよね? それで Internet Explorer でも導入されて、第一次ブラウザ戦争(第二次?)になっていたのでした。
個人的にはまだ、マシンも非力で、ダイヤルアップ接続だったので、スクリプトの仕組みははっきり言ってウザイと感じていた部分も多々ありました。時代が過ぎて、マシンも回線も当時に比べれば遥かに強力になりましたけど、それに比例するかのように Dynamic HTML コンテンツの方も、にデカクなってしまって、なぜかモッサリ感のあるページが多いような…。
なので、twitter なんかは、モバイル向けページで閲覧していたりします…。Slashdot もモッサリしてるので、モバイル向けページができないかなぁ~?スクリプトで何でもかんでもヤルのは、正直、勘弁してほしいです… (≧ヘ≦)
Re:JavaScript自体を拡張してほしい (スコア:1)
百歩譲って生産性改善の余地はあるとしても (スコア:0)
JavaScriptに変換して実行するのにどうして遅い、メモリを食う、という問題点が解決するの?
Re:百歩譲って生産性改善の余地はあるとしても (スコア:1)
Re:百歩譲って生産性改善の余地はあるとしても (スコア:1)
最適化が全てみたいです。
元から最適化されたコード書いてる人には高速化、少メモリの恩恵はそれほどないみたいな感じでしたね。
それでも保守性とか生産性とかメリットはあるとのこと。
Re:百歩譲って生産性改善の余地はあるとしても (スコア:1)
こういうところで紹介されている(手動の)最適化手法を、自動でやれば速くなりますよ。
http://news.mynavi.jp/news/2009/11/11/015/index.html [mynavi.jp]
手動最適化は、えてしてコードの保守性を落すんですが(例: インライン展開)、処理系がやってくれれば、そういう心配はないですし。
自明なインライン展開のみならず、以下のようなこともしてくれるようです:
http://twitter.com/kazuho/status/208028042675757056 [twitter.com]
> link-time optimization ですね。final がついてない関数についても すべて見る、継承クラスを見渡して実装が1個しかなければインライン展開しちゃうとか
他にも、コンパイラがやる最適化
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%8... [wikipedia.org]
のうち、今回のケースでも適用できるものは沢山ありますね。たとえばループ不変量のコード移動はやっているようです:
http://twitter.com/kazuho/status/208064114021511169 [twitter.com]
http://twitter.com/kazuho/status/208065074542297088 [twitter.com]
> ビジーループの中のほうで switch (arguments.length) してるコードがあってですね? 実行速度と GC の双方に負荷がやばかったり
Re: (スコア:0)
最適化するから。JITを使わないから。
と、発表スライドからは読めるのですが、違うのかしらん
なんでまた (スコア:0)
こんな被りそうな名前にするかな。
After Effectsかなんかで.jsxって使ってなかった?
Re:ガラパゴスDart (スコア:1)
Dartは遅いし、ちゃんとしたOO言語じゃないし、Chrome以外では動かないし、ともスライドに書いてある。