- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
112 ：デフォルトの名無しさん[sage]：2016/05/12(木) 00:54:26.89 ID:TctSTaTq - >>110
> Extensible Web Manifesto
以下を読んだ。
http://jxck.hatenablog.com/entry/extendthewebforward
言っていることは分かるが多分無理だな。
低レベルAPIのすり合わせは高レベルAPIよりも難しい。
だから高レベルAPIのすりあわせすらマトモにできなかった連中には無理だ。
> そもそも、デバッギングはコーディングよりも2倍難しい。
> 従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。
> ブライアン・カーニハン [Brian Wilson Kernighan]
高レベルAPIの仕様策定が失敗しているケースが多々ある点についてはよくは知らないが、
JavaScript言語自体の仕様を見る限り、いろいろ迷走している点は多い。
仕様策定が失敗するのは、単純に使用策定している奴らに先見の明が無いからだ。
だから逆に言えば、先見の明が無いような奴らが仕様策定に関わってはいけない。
JavaScriptの連中はそこらへんを勘違いしている。だからゴミ仕様が山積みになる。
AppCacheがゴミであろうと、仕様として策定された以上、実装しないわけには行かない。
だから結局、ブラウザに対してゴミコードを含まなければならないという足かせが出来ただけになる。
結果的にJavaScriptの世界はゴミが増えていき、ゴミに振り回されることになる。
これを理解できていない。
とはいえ、それでも進化の速度を取っているといえばその通りだ。
C#が伽藍型仕様開発なら、JavaScriptはバザール型という訳だが、目に付く失敗も多い。
もちろん、XHR等は大成功の一例なのだろう。どちらが多いのかは、俺にはわからない。
SeviceWorkerがどうなるのかは見ものだな。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
113 ：デフォルトの名無しさん[sage]：2016/05/12(木) 00:54:55.63 ID:TctSTaTq - > ちゃんと書く
速度を問題にしているのだろう？だったらきちんと速度が出る書き方をするということだよ。
5倍というのはググれば出てくるはずだがN-body、つまり演算部分だ。
同様のベンチは他の人もやっていて、大体同じような値になっている。
ただ指摘の通り、その部分は他のもっと遅い部分に隠蔽され、結果的に見えないことが多い。
(ただしだからといって遅い部分も含めて速度比較して大差ないとか言う屁理屈はうざいだけだから止めろ。
それは速度比較とは言わない）
だからJavaScriptが通常用いられる用途に関しては、JavaScriptは十分速いし、
それ以上を望むのなら、ゴリゴリ書くしかない。
> ゲーム思考エンジン
これは環境はなんだ？
個人的には主力テキスト操作スクリプトをAWK/Perl->JavaScriptに乗り換えようかと思っているんだが、
DOS窓から操作できる使いやすい環境ってないか？
AWKやPerl同様、一行ずつ標準入力からReadline出来ればそれでいい。
nodeが一番マシか？
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
117 ：デフォルトの名無しさん[sage]：2016/05/12(木) 23:52:09.31 ID:TctSTaTq - >>114
WSHか。あれ食わず嫌いだったけど、やっぱお手軽でよさそうだよな。
まあやってみることにするよ。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
118 ：デフォルトの名無しさん[sage]：2016/05/12(木) 23:59:02.52 ID:TctSTaTq - >>115
違う。
> 策定に時間がかかったり、実装者や開発者とのやり取りが十分ではなかったから。
仕様策定とは「常に」こういうものなんだよ。言語のみならず他でも全て。
有名なイラスト、見たことがあるだろ。
> ニコニコ大百科/a/顧客が本当に必要だったもの (リンクはRock54で貼れない）
だから、これを分かった上で、そうならないようにする「実力」が必要なんだよ。
具体的に言えば、どんなに時間がかかろうが、いい仕様（必要な物）ならみんな使う。
だから、時間をかけてでもいい仕様にするというのが「先見の明」作戦。
これが無理なら、古典的だが報告連絡相談（ホウレンソウ)をきっちりやるしかない。
出来なかったのなら、どちらの作戦もやりきる実力が無かっただけ。
試行錯誤で進めていくのもありだと思うけど、
それなら結果的に無意味になってしまった仕様等をばっさり捨てていく覚悟も必要。
(詳しくは知らないがRailsはこれに近いのかもしれないし、それも妥当な戦術）
後方互換も必要です、新しい仕様も必要です、
でも十分な仕様策定能力はありません、というのが今のJavaScriptの状態だね。
進化速度を捨てるわけには行かないのだから、後方互換を捨てるしかないと思うのだけどね。
この点で言えば、ポリフィルでお茶を濁しまくっているのはいい作戦ではある。
とはいえ、出来る/出来ないをここで議論する意味は無い。
結果を見ればいいだけだから。
|