JavaScript 4©2ch.net (398レス)
1-

16: 2015/02/11(水)21:51 ID:nRKk5Oa4(1) AAS
よくわかんないけどウェブプログラマがIEを恨む時代からChromeを恨む時代になる?
17: 2015/02/11(水)21:54 ID:z1YCt8TB(2/5) AAS
違う。これを発表したのはまさにTC39Meetingでだ。
だからGoogleはこれがES7あたりで標準になることを望んでいる。
O.oのときと同じく先行実験をするということ。

しかしJSが徐々に「Living Standerd」化していってるのは否定しない。
これは良い悪いではなく抗えない時代の流れなのだと思う。
そういえばこれと同じようにMozilla陣営が実験を進めていたParallelsは、
共感が少ないということで白紙に戻ったそうだ。

この取り組みが成功し、標準になるかどうかは結局は我々開発者の評判次第ということだ。
18: 2015/02/11(水)22:07 ID:z1YCt8TB(3/5) AAS
皆はasm.jsを手書きで書こうとして詰まったり、思ったよりパフォーマンスが上がらなかったことはないだろうか。
Saneなら違う。SaneはほぼJSの感覚で手で楽にかけるし、パフォーマンスだけでなくリーディングの面でも素晴らしい効果をもたらす。
問題はこのJSにモードを増やすという考え方が、開発者たちにとって歓迎されるかどうかだ。

このasm.jsについてのissueを見てほしい。
https://code.google.com/p/v8/issues/detail?id=2599
10でも多いレス数は80。100で大人気のスター数は630。
当初Googleはasm.js向けの最適化はしないと言っていたのが徐々に主張が変わり、
今では新最適化エンジンで"use asm"を認識し、最適化モードを切り替えられるようにしたほどである。
今回の"use sane"アイディアはこういったことから開発者の受けがいいと判断してのことだろう。
19: 2015/02/11(水)22:19 ID:TfFe/slw(1/2) AAS
asm.jsで目的は達成してるし他にはいらん
しかもasm.jsはソースがグチャグチャになるからアセンブラ並の難読化の役割も果たしてる
分かりやすくして欲しくない
20: 2015/02/11(水)23:07 ID:z1YCt8TB(4/5) AAS
asm.jsはネイティブのコードをJS化するときに活用できるものであって、
"use strict"の強化版的なSaneModeとはユースケースが違う。
特にvarの使用位置にこだわる人やLint勢、クラスベース言語経験者からは喜ばれると思う。
21: 2015/02/11(水)23:21 ID:z1YCt8TB(5/5) AAS
Sane/Soundで一番JSらしくなくなるのはオブジェクトが拡張できなくなる点だが、
sealedされて型のついたオブジェクトというのは、ES7で前々から提案されていたTypedObjectと同じだ。
コンストラクタがデフォルトでTypedObjectを返すようになるモードと考えれば、違和感も薄れるかもしれない。
22: 2015/02/11(水)23:31 ID:TfFe/slw(2/2) AAS
pdf読んだが、ただのstrict modeの拡張レベルの話しだな
SoundScriptの方にいたってはTypeScriptのパクリだし
TypeScriptパクる奴は後を絶たないな
23: 2015/02/11(水)23:38 ID:sJPqGjE7(1) AAS
パクってもらうのが目的な気がしてならない
24
(1): 2015/02/12(木)04:27 ID:vBHOZlzG(1/3) AAS
パクリも何もTypedScriptは元々ES6に向けたharmonyの機能を先行して実装し、
それに加えてES4の頃からアイディアがあってES7辺りでの実現が見込まれていた型注釈を組み込んだものだよ。
そしてTypeScriptの目標は自身(型注釈)がES7で取り入れられて最終的に用無しになることだからね。
CoffeeScriptなんかとよく並べられるが、どちらかと言うとtraceurや6to5みたいなトランスレーターの仲間と考えた方がいい。
とは言えTSの型注釈はコンパイル時の整合性チェックのためのもので、実行時に活用するSSとは少し有り様が違う。
25
(1): 2015/02/12(木)13:51 ID:sZL3z8VT(1/2) AAS
>>24
JavaScriptに型注釈が取り入れられるわけないし必要ない
それにブラウザ内蔵オブジェクトに正しく型を付けられるようにしたのはTypedScriptが最初だ
アイディアレベルのものと実際に実用的に動くものにしたのでは天と地ほどの差がある
実行時に活用するのは同じGoogleのAtScriptがあるだろ
26
(1): 2015/02/12(木)15:31 ID:vBHOZlzG(2/3) AAS
>>25
>>型注釈が取り入れられるわけない
そんなことはない
ただし、ESでの型注釈は現状無難なguardの方向になる可能性が一番高い
SSはもっと踏み込んでる

>>ブラウザ内蔵オブジェクトに正しく型を付けられるようにしたの〜
DefinitelyTypedについて言っているのならそれは完全にTSの功績
だがそれはTSの型注釈がコンパイル時の検証のためのものだから必要なのであって
ランタイムのチェックには必要ないもの

>>アイディアレベルのものと実際に実用的に動くものにしたのでは天と地ほどの差がある
省5
27
(1): 2015/02/12(木)16:52 ID:sZL3z8VT(2/2) AAS
>>26
> ただし、ESでの型注釈は現状無難なguardの方向になる可能性が一番高い
guardはブレンダン・アイクにいらねー言われてたよ

> DefinitelyTypedについて言っているのならそれは完全にTSの功績
ブラウザ内蔵オブジェクトは単純なclassの定義だけじゃ型付け出来ないものがある
TypeScriptは若干独特な仕様のinterfaceを導入して正しく型付けしている
28: 2015/02/12(木)18:47 ID:vBHOZlzG(3/3) AAS
>>27
guardそのものではないが、実行時の型チェック→エラー機能に留まる≒guardということ。

それと別に型が正しく型付けできない云々はあくまでTSの問題。TSが型をどのように定義し利用してるかの問題であって、一般的な話ではない。
そもそもTSにおける型とは架空のものだから。架空のものなのはJSが曖昧だから。

その点SSはそもそもクラスベースの世界だからインスタンスに紐付けられているクラス情報で判断できる。
で、ビルドインコンストラクタについてはどうやって外部の(プロトタイプベースの)世界と折り合いをつけるのかが示されていないから、
ランタイムチェックについては問題ないがAOT最適化をどうやるのかはなんとも言えない。
29: 2015/02/13(金)21:09 ID:WDmbay81(1) AAS
jsonの日
30: 2015/02/14(土)03:59 ID:TJAnvvXO(1) AAS
リア充の日
31: 2015/02/16(月)00:41 ID:/X+NPUTO(1) AAS
Effective JavaScript読むとJSのきもさに眩暈がするな
元々ガチ向けじゃなかったものをガチ向けにした気持ち悪さ
まるで遊戯王
32: 2015/02/16(月)02:39 ID:4iM7fmBu(1) AAS
どんな言語でもプログラムした事無い素人の典型的なレスだな(笑)
33
(1): 2015/02/16(月)08:14 ID:1Y+K6fCR(1) AAS
キモイだろ。普通に。
ここまで捏ね繰り回されたコードが普通に使われる言語は珍しい。
他の言語だとそういうキモイコードは、面白いけどさあ、で大体終わる。
34
(1): 2015/02/16(月)09:39 ID:o9E9nO+7(1) AAS
まあ皆キモイと思ってるから各種altJSが出てくるんだろうし
35: 2015/02/16(月)09:40 ID:JcJgKv2l(1) AAS
>>34
そんなこと思ってる奴は全体でも1割もいない
1-
あと 363 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.009s