静的型付け言語の潜在開発生産性は今の100倍 ×2

1 ：デフォルトの名無しさん：2013/10/06(日) 00:30:02.59

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。

すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。

コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

静的型付け言語の潜在開発生産性は今の100倍
http://toro.2ch.net/test/read.cgi/tech/1362302249/

2 ：デフォルトの名無しさん：2013/10/06(日) 00:35:23.66

おっつっつ
ポジティブな話題話そうぜ

3 ：デフォルトの名無しさん：2013/10/06(日) 05:59:07.15

で、何なんだったんだあのJS馬鹿は

4 ：デフォルトの名無しさん：2013/10/06(日) 06:05:38.89

JSが嫌いで憎くてたまらないんだろうさ。

5 ：デフォルトの名無しさん：2013/10/06(日) 06:51:40.72

クロージャは関数外の変数を参照できる必要はあるけど、書き換えられる必要は無い

JSerはJSが関数型を取り込んでるとか云うわりに、関数型について無知すぎる

6 ：デフォルトの名無しさん：2013/10/06(日) 12:12:29.38

> クロージャは関数外の変数を参照できる必要はあるけど、書き換えられる必要は無い

無知発見ｗ

書き換えられないと駄目だし、その他の言語も全て書き換えられる。

7 ：デフォルトの名無しさん：2013/10/06(日) 12:17:59.68

それ以前にだな、
JS馬鹿の
外のスコープを参照可能であることとvarのセマンティクスが腐っている事を
混同したアホな議論にいつまで付き合ってやるんだ？

8 ：デフォルトの名無しさん：2013/10/06(日) 12:37:02.05

>varのセマンティクスが腐っている

具体的に

9 ：デフォルトの名無しさん：2013/10/06(日) 12:49:06.19

>>6
＞書き換えられないと駄目だし、その他の言語も全て書き換えられる。

Haskell

10 ：デフォルトの名無しさん：2013/10/06(日) 13:08:41.57

>>9
Haskellは純粋関数型言語なので
変数の書き換えそのものがないだけ。

11 ：デフォルトの名無しさん：2013/10/06(日) 13:11:18.52

「その他の言語も全て書き換えられる」と
言ったからダメなんだろ。

変数を書き換えられる言語であれば、
すべての言語がクロージャーから
クロージャー外の変数を書き換えれられる。

12 ：デフォルトの名無しさん：2013/10/06(日) 13:12:17.57

>>5
> JSerはJSが関数型を取り込んでるとか云うわりに、関数型について無知すぎる

関数型を取り込む ≠ 関数型言語

ですよ？

いつ関数型言語になったといいました？

13 ：デフォルトの名無しさん：2013/10/06(日) 13:30:25.98

完全論破された後のJSerの言い訳ワロス
無知すぎる

14 ：デフォルトの名無しさん：2013/10/06(日) 13:37:44.00

OCamlも再代入はめったに使わない

15 ：デフォルトの名無しさん：2013/10/06(日) 14:52:09.19

関数型言語の低レベルのメリットっていうのは純粋関数型言語でしか得られない
JSの場合関数型「スタイル」っぽくも書けるってだけのこと

16 ：デフォルトの名無しさん：2013/10/06(日) 16:28:55.18

JSerの場合、関数型スタイルの事これっぽっちも分かってないと思うよ
まさかコールバック地獄を関数型スタイルだと思ってんの？

17 ：デフォルトの名無しさん：2013/10/06(日) 16:52:19.10

JSを叩けなくなったら今度は架空のJSer叩きっすか……
凄い執念だぁ

18 ：デフォルトの名無しさん：2013/10/06(日) 17:12:15.39

関数スコープ外の変数を上書き出来ないと困るー
めっちゃ頻繁に上書きしたいわー
上書きにvarとか必要になったら面倒でプログラミングにならんわー
ってのがJSerの主張でしょ？

19 ：デフォルトの名無しさん：2013/10/06(日) 17:17:42.53

>>18
架空のJSer叩きっすかｗ

20 ：デフォルトの名無しさん：2013/10/06(日) 17:22:56.54

関数スコープ外の変数をあまり上書きしないなら
varを付けた場合と付けない場合の振舞いは
逆の方が良いね

21 ：デフォルトの名無しさん：2013/10/06(日) 17:40:17.18

>>20
意味がわからん。

varって変数宣言だぞ？

varを付けた時と付けない時が反対って、
お前、 varを付けなかったら、
変数宣言してないのに
変数が勝手に宣言されるってことか？

変数名間違ってもエラーにならないってことなんだが。

22 ：デフォルトの名無しさん：2013/10/06(日) 17:42:40.03

IDE使わんの？
未使用変数をリアルタイムで色付けしてくれるタイプの

23 ：デフォルトの名無しさん：2013/10/06(日) 17:45:51.65

varを付けなくても勝手に宣言されるとしたら、
名前間違ったら、未使用変数ではなくなってしまうよな。

24 ：デフォルトの名無しさん：2013/10/06(日) 17:46:39.23

んなことないよ
よく考えろよ

25 ：デフォルトの名無しさん：2013/10/06(日) 17:49:07.12

最初に一回宣言しただけで
他から一度も参照されてない変数に色付けする機能があるんだよ
varとか関係なく、便利

26 ：デフォルトの名無しさん：2013/10/06(日) 17:50:00.56

例えばこういうこと。

var i, j;
k=123;

スペルミスでkという名前を使ってしまった場合、
varを付けたとき変数宣言されるならば、
宣言されてないkを使っている・・・スペルミスだろうと警告できる。

だけどvarを付けなくても変数宣言される場合は、
kを使ってるから、kは未使用ではない。
なんの問題もないと判断してしまう。

27 ：デフォルトの名無しさん：2013/10/06(日) 17:50:11.33

グローバルに変数ができちゃうことが問題なわけでそれ以外は問題ない
よってvarとかそういうもので何か変わるもんでもない

28 ：デフォルトの名無しさん：2013/10/06(日) 17:50:47.84

>>26
>>25を読んでね

29 ：デフォルトの名無しさん：2013/10/06(日) 17:54:21.82

JavaScriptにはevalやグローバル変数のハッシュアクセスがあるんだからそれは無理

30 ：デフォルトの名無しさん：2013/10/06(日) 17:55:03.85

>>28
二回間違ったらアウトじゃん？

31 ：デフォルトの名無しさん：2013/10/06(日) 17:56:17.66

そうなんだ、残念だね

32 ：デフォルトの名無しさん：2013/10/06(日) 17:56:35.64

>>27
グローバルに変数ができることなんて無いよ。

>>29
だよね。ソースコード上は変数が一回しか使われてないように見えても
使っていることだってあるし。

たぶん動的言語を知らないから
思いつかないんだろうな。

33 ：デフォルトの名無しさん：2013/10/06(日) 17:57:31.79

>>30
最初の一回目でリアルタイムで色が付くのに、
それに気付かずに二回目も間違えるの？

34 ：デフォルトの名無しさん：2013/10/06(日) 17:57:43.66

は？
x = 1
ってやったらもろxはグローバル変数だろうが

35 ：デフォルトの名無しさん：2013/10/06(日) 17:58:44.93

>>29
関数スコープの変数宣言の話じゃないの？

36 ：デフォルトの名無しさん：2013/10/06(日) 18:01:15.44

>>34
ちゃんと読んでよね。

$ cat a.js
"use strict"
x = 1;

$ node a.js
x = 1;
^
ReferenceError: x is not defined
at Object.<anonymous> (/tmp/a.js:3:3)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:901:3

37 ：デフォルトの名無しさん：2013/10/06(日) 18:02:00.42

>>32
型が動的でもスコープはレキシカルって言語も多いよ
あんまりダイナミックスコープを採用してるメジャー言語って無いんじゃない？
Perl（両方使える）とかEmacs Lispくらい？

38 ：デフォルトの名無しさん：2013/10/06(日) 18:02:30.53

変数がどこのスコープに属してるのか解析するのはかなり大変だと思うぞ
そんじょそこらのエディタのプラグインじゃないだろうし
これからもできないだろう
なんだかんだ言ってやっぱりJSはコンパイルが要らないことを活かして
トライアンドエラーで、ブラウザのコンソールを使ってデバッグしていくしかない
エディタの超高度な支援に期待するのは話がうますぎる

39 ：デフォルトの名無しさん：2013/10/06(日) 18:03:55.16

ブラウザのコンソールってお前・・・。

ブラウザにはデバッガが内蔵されていることも知らんのか？
ブレークポイントもステップ実行もできるぞ。

40 ：デフォルトの名無しさん：2013/10/06(日) 18:04:11.07

>>36
お前こそちゃんと読めよ
strict modeじゃない場合の挙動で
varの効果を逆にすればいいみたいなこと言う輩に言ったんだよ

41 ：デフォルトの名無しさん：2013/10/06(日) 18:05:17.38

>>40
今はstrict modeがデフォです。
今ではとっくに解決してしまった、
昔の話をいつまでしてるんですか？

42 ：デフォルトの名無しさん：2013/10/06(日) 18:06:13.56

さすがにuse strictじゃない挙動は論外だろ……

43 ：デフォルトの名無しさん：2013/10/06(日) 18:06:19.72

>>39
バカはお前だ
当然それも含んでデベロッパーツールのことをIDEとかと対比して分かりやすくコンソールと読んでるいるに決まってるだろうが
言葉の揚げ足取りやめろよ

44 ：デフォルトの名無しさん：2013/10/06(日) 18:06:32.40

馬鹿「varの効果を逆にすればいい（どやっ）」

天才「strict modeをONにすればいいじゃないですか( ﾟ∀ﾟ)ｱﾊﾊハハ八八ﾉヽﾉヽノヽノ＼/＼」

45 ：デフォルトの名無しさん：2013/10/06(日) 18:07:10.95

>>43
コンソールの意味もしらんの？

GUIのデバッガを
お前はコンソールって言うわけ？

46 ：デフォルトの名無しさん：2013/10/06(日) 18:07:31.60

>>41
日本語分かんないのか？
話が噛み合ってないぞ

47 ：デフォルトの名無しさん：2013/10/06(日) 18:08:19.24

良く使う＆より危険でない操作の方を短く書けるべきだよね？って話でしょ
全然別の問題が並行して議論されてるんですよ

48 ：デフォルトの名無しさん：2013/10/06(日) 18:08:39.55

>>43
お前の場合、GDB（デバッガ）をIDEじゃないからという理由で
コンソールっていいそうだなｗ

49 ：デフォルトの名無しさん：2013/10/06(日) 18:09:27.39

>>45
言葉尻を捉えるのはもういいから
勘違いしてた、ごめんねでいいだろ

50 ：デフォルトの名無しさん：2013/10/06(日) 18:10:13.76

コンソールはデバッガじゃないですよ。
勘違いしてたごめんねって誤るのはまだ？

51 ：デフォルトの名無しさん：2013/10/06(日) 18:11:00.41

JavaScriptがどうのこうのこのスレで語ることじゃない
ここ行け
http://toro.2ch.net/test/read.cgi/tech/1379350030

52 ：デフォルトの名無しさん：2013/10/06(日) 18:11:40.68

>>50
誤りでした
勘違いしてたごめんね

53 ：デフォルトの名無しさん：2013/10/06(日) 18:12:51.92

>>51
そっちはJS厨に乗っ取られた

54 ：デフォルトの名無しさん：2013/10/06(日) 18:15:02.48

過疎スレでJavaScriptが一番話題に事欠かないってだけでしょ
ここでもそうだけど

55 ：デフォルトの名無しさん：2013/10/06(日) 18:23:49.46

>>38
evalとかバイトコード書き換えを使う場合を除けば
解析できると思うけどねぇ
eval使って解析できないのは自己責任と割り切る

56 ：デフォルトの名無しさん：2013/10/06(日) 18:28:02.40

一応メモ帳でも書ける言語なんだからエディタに期待するのは
言語仕様検討外だからなあ
一応実行時のデバッグサポートについては沢山仕様で入ってるけど
そりゃあ不可能ではないが
JSLintやHintでさえ異常な認識したりするし、現状絵に描いた餅だなあ

57 ：デフォルトの名無しさん：2013/10/06(日) 18:33:30.28

>>54
すげえプラス思考

58 ：デフォルトの名無しさん：2013/10/06(日) 18:38:44.38

LListの場合はサーバサイド－クライアントサイドとして見た時
もしくはそうじゃなくても日常的にWebは皆触れてるし、
大企業が絡んでるのも合って公平に見てもJSが最も話題にしやすい言語かと
HTML5とES6の勧告が来年に控えてる今だからってのもあるけど

59 ：デフォルトの名無しさん：2013/10/06(日) 18:42:00.43

単純にJavaScriptを使っている人が多いのと、サーバーサイドでは別の言語を使っていて
クライアントでJavaScriptを使う、みたいな人が多いだろうから他の言語との比較で色々
話題や不平不満も出てくるんじゃ無いのかな。

言語Aでの作業から言語Bへの作業にスイッチした時に「言語Aではxx出来るのにむき～」
と感じる場面が自分は時々あるけれども、JavaScriptも例外じゃない。

60 ：デフォルトの名無しさん：2013/10/06(日) 18:47:10.91

Webは日進月歩だしJSの仕様実装もLivingStandardだしね
WebAPIを含めれば毎日何らかの新しいことがあるだろう
個人的にはやっぱりES6で歴代のバージョンUPと比較できないほど
大きく変わるっていうのにワクワクしてる

61 ：デフォルトの名無しさん：2013/10/06(日) 18:51:15.38

俺も土管として使いやすくなりそうでワクワクしてる

62 ：デフォルトの名無しさん：2013/10/06(日) 18:56:44.77

ProxyやReflectionが入ったから色んな代替言語が作りやすくなるだろうね

63 ：デフォルトの名無しさん：2013/10/06(日) 19:04:14.60

なかっち動画
http://www.youtube.com/watch?v=z2qK2lhk9O0s

みんなで選ぶニコ生重大事件 2012
http://vote1.fc2.com/browse/16615334/2/
2012年　ニコ生MVP
http://blog.with2.net/vote/?m=va&id=103374&bm=
2012年ニコ生事件簿ベスト10
http://niconama.doorblog.jp/archives/21097592.html

生放送の配信者がFME切り忘れﾌﾟﾗｲﾍﾞｰﾄを晒す羽目に放送後に取った行動とは?
http://getnews.jp/archives/227112
FME切り忘れた生主が放送終了後､驚愕の行動
http://niconama.doorblog.jp/archives/9369466.html
台湾誌
http://www.ettoday.net/news/20120625/64810.htm

64 ：デフォルトの名無しさん：2013/10/06(日) 19:56:54.77

Reflectってどういう時に使ったらいいんかね？

65 ：デフォルトの名無しさん：2013/10/06(日) 21:36:18.25

Javascriptの生産性が低すぎる件ですが
どうやったら解消できますか？

66 ：デフォルトの名無しさん：2013/10/06(日) 21:44:34.02

具体的には？
というか言語の生産性にそこまでの差なんて無いと思うけど
それDOMがつまらないってだけじゃない？
もちろんスクリプト言語なんだから環境によってぜんぜん違う
UnityのJavaScriptなんてまるっきり別物だし

67 ：デフォルトの名無しさん：2013/10/06(日) 23:16:15.44

>>1
>静的型付け言語の潜在開発生産性は今の100倍

なるほど、今の静的型付け言語は、動的言語の/100の能力って事だな。
スレタイは一見、静的言語を褒めてるように見せてるけど、実は動的言語(´∀｀∩)↑age↑なんだよね。
当面は動的が有望と。

68 ：デフォルトの名無しさん：2013/10/06(日) 23:28:34.07

単純に考えて実行環境は
コア数が増えサンプリング推論技術が高まるほどより動的な言語に有利

69 ：デフォルトの名無しさん：2013/10/06(日) 23:33:52.61

>>67
> >静的型付け言語の潜在開発生産性は今の100倍
>
> なるほど、今の静的型付け言語は、動的言語の/100の能力って事だな。

なんでこんなに馬鹿なんだろう？
論理学の勉強したこと無いのかな。

馬鹿にも分かりやすくたとえてあげよう。

フリーザ「私の戦闘力は今の100倍だ」
ヤムチャ「ということは俺の1/100の戦闘力って事だな」

70 ：デフォルトの名無しさん：2013/10/06(日) 23:35:00.24

世代じゃないから分からん
とある辺りで例えてくれ

71 ：デフォルトの名無しさん：2013/10/06(日) 23:41:08.74

世代じゃないって、60代以上か？
でも俺の親でも知ってるし、
だとしたら、70代以上か？

72 ：デフォルトの名無しさん：2013/10/06(日) 23:43:17.61

２０だ

73 ：デフォルトの名無しさん：2013/10/06(日) 23:44:59.16

頭が悪いからJSしか使わない
動的言語なんて他にもいろいろあるのに

74 ：デフォルトの名無しさん：2013/10/06(日) 23:47:39.68

こりゃまた頭が悪そうな台詞だ

75 ：デフォルトの名無しさん：2013/10/06(日) 23:54:31.22

ほらな
本当に一つしか知らないからこんなレスにも反応してしまうし、
そう思考停止してるから与えられた環境で満足してしまう

それがJS使いの平均だと思われるのが本当に残念だ

76 ：デフォルトの名無しさん：2013/10/06(日) 23:55:41.09

>>75
お前誰にレスしてるんだ？
いきなり出てきてわけのわからんこと言うなよ。
お前の人間性が問われるところだぞ。

77 ：デフォルトの名無しさん：2013/10/07(月) 01:16:50.67

とりあうな

78 ：デフォルトの名無しさん：2013/10/07(月) 01:46:28.22

>>69
100倍もあるなら何故すぐ発現させないんだ？ってところだろ。
いつまでたっても発現しない「潜在性」に縋るのは単なる厨か信者だしな。

79 ：デフォルトの名無しさん：2013/10/07(月) 01:50:00.70

民主の潜在可能性は自民の100倍！
株価は3倍、国民所得は2倍に！

80 ：デフォルトの名無しさん：2013/10/07(月) 09:12:15.81

>>78
> 100倍もあるなら何故すぐ発現させないんだ？ってところだろ。
ツールとか技術がまだ確立されてないから。
すぐに出来ると思うなよｗ

81 ：デフォルトの名無しさん：2013/10/07(月) 09:19:38.08

どの辺りに伸び代があるの？
と建設的な質問をしてみる

82 ：デフォルトの名無しさん：2013/10/07(月) 11:05:44.53

データベースとモデルクラスが一体化すれば楽になる
DDLを定義変更したら自動でモデルクラスが再生成されるとか

もう既にあるんだろうけど

83 ：デフォルトの名無しさん：2013/10/07(月) 15:24:23.75

その辺りはもはや言語と言うよりフレームワークの問題では？
そもそも言語にそんな差があるとは思えない
純粋関数型は特殊さがいろいろあるけど、静的か動的かくらいでねぇ

84 ：デフォルトの名無しさん：2013/10/07(月) 16:44:03.54

>>80
じゃあ動的言語も、ツールとか技術が確立されたら、静的言語を軽く超えるな。

85 ：デフォルトの名無しさん：2013/10/07(月) 18:39:43.99

>>64
ポリフィルに凄い大活躍すること間違いなし

86 ：デフォルトの名無しさん：2013/10/07(月) 20:06:59.73

もう型推論でも使ってろ
これで静的も動的も仲良くなれる

87 ：デフォルトの名無しさん：2013/10/07(月) 20:39:00.13

JavaScriptの著名なエンジンは型推論してるじゃん

88 ：デフォルトの名無しさん：2013/10/07(月) 20:54:13.50

TypeScriptのあまりに御粗末な型推論を見る限り
JavaScriptの型推論には期待出来ない

89 ：デフォルトの名無しさん：2013/10/07(月) 21:14:41.66

TypeScriptの型付けはコンパイル時エラーを出すためのもので
実行時には何の効果も及ぼさないよ
JSのエンジンの型推論は普通に協力
だからこそあの速度を維持できるんだからね

90 ：デフォルトの名無しさん：2013/10/07(月) 21:37:40.21

真面目な話、実行時プロファイルに比べたら効果は微々たるもの

91 ：デフォルトの名無しさん：2013/10/07(月) 21:42:52.87

仮に実行時に効果を及ぼせたとしても、
簡単に数値化と文字列を間違えるようなウンコな型推論じゃ
全く効率的では無いだろうね＞ TypeScript

92 ：デフォルトの名無しさん：2013/10/07(月) 21:57:02.85

文字列と数値の間違いなんて無い

93 ：デフォルトの名無しさん：2013/10/07(月) 22:00:54.71

馬鹿なんだから、確かめもせずに無いとか書くなよ
>>6で知ったかして恥かいたばかりだろJSerは

94 ：デフォルトの名無しさん：2013/10/07(月) 22:02:46.11

今のCPUじゃ32bitや64bitが扱いやすいんだから
オーバーフローが気になる固い数値型は要らなくて
JSとかDartとかみたいに自動スケーリングのほうがいいと思う

95 ：デフォルトの名無しさん：2013/10/07(月) 22:04:43.82

>>93
エディタの表記が間違うのはエディタのせいであって言語の間違いではない
全てはTSの仕様通りですがなにか？

96 ：デフォルトの名無しさん：2013/10/07(月) 22:08:49.19

これを貼れば良いんだよねw

> function g() : number { return ((x,y) => x + y)(1, "Hello World"); }
> の戻り値は "1Hello World"

97 ：デフォルトの名無しさん：2013/10/07(月) 22:19:23.80

それ型推論関係ないし
TypeScriptの型指定は実行時は関係ない
IDEのサポートのためのものでしかない

98 ：デフォルトの名無しさん：2013/10/08(火) 00:24:47.80

>>84
> じゃあ動的言語も、ツールとか技術が確立されたら、静的言語を軽く超えるな。

それはないよ。

動的言語の定義により、
「実行するまで状態が確定しない」

故に実行前に知ることが出来ない情報が多い。

99 ：デフォルトの名無しさん：2013/10/08(火) 01:24:19.23

コンパイルが要らないから
実行時も開発環境に気楽に入れれるから
状況が違う

100 ：デフォルトの名無しさん：2013/10/08(火) 01:38:39.24

>>99
おいおい、実行って一度実行すれば
いいってもんじゃないぞ。

実行しないと状態が確定しないというのは、
一度実行しても違う実行パターンがあるならば
状態が確定しないということだ。

すべての実行パターンなんて、想定不可能なわけで
事実上いくら時間があっても、状態は確定しないってことだぞ。

101 ：デフォルトの名無しさん：2013/10/08(火) 01:42:04.10

コンパイル時間なんて実行時間に比べりゃ
微々たるもんよ。

102 ：デフォルトの名無しさん：2013/10/08(火) 01:59:43.55

変なことを言うねえ
ライブコーディングは大きな開発生産性じゃない？

103 ：デフォルトの名無しさん：2013/10/08(火) 03:32:24.93

いいえ、何も考えずに行き当たりばったりで
書いてるだけにしか見えませんね。

頭のなかでちゃんと考えていれば
実行しなくてもコードはかけるはずです。

例えば将棋でコマを動かしてから考えるプロがいますか？
そんなことをするのは初心者だけです。
動かしたらやり直しはきかないですからね。

頭の中で瞬時に幾つもの手を考え、その中から
最善の方法を選び、それを書くだけなので動かす必要はありません。
いちいち動かすなんて面倒くさいことしてられませんよ。

104 ：デフォルトの名無しさん：2013/10/08(火) 03:42:13.25

将棋のソフト作る時は予想外のバグがあるもので
何十回も何百回も動かしてみないといけないものだぞ
それは電王戦出るような開発者も言ってるし
自分もつくづく感じてる

105 ：デフォルトの名無しさん：2013/10/08(火) 03:45:41.63

>>104
論点がずれてる。アホ。

106 ：デフォルトの名無しさん：2013/10/08(火) 03:48:45.30

そもそも、ライブコーディングは、ライブでコーディングすることであって
ライブで実行することじゃないからｗ

107 ：デフォルトの名無しさん：2013/10/08(火) 03:57:17.91

ん？いきなりどうした？

108 ：デフォルトの名無しさん：2013/10/08(火) 03:57:41.22

C言語やJavaのライブコーディング動画も
あるのに何を言ってるんだ？って話。

109 ：デフォルトの名無しさん：2013/10/08(火) 04:00:31.97

そりゃそのとおりだね。

110 ：デフォルトの名無しさん：2013/10/08(火) 04:02:10.48

ここまで1100レス消費して
動的型が優れてる証拠は山ほどあるのに静的型については０
静的厨はいつもの様に揚げ足取りにご執心
人の意見は否定してばかりだが自分の意見は言わない
それも当然、ぶつけて負けるのが分かりきっているから
恐怖と不安で脳が混乱し煽り文章しか打つことが出来ない
当に病気

111 ：デフォルトの名無しさん：2013/10/08(火) 04:04:06.95

自演のコメは間隔が約3分あいててわかりやすいね。

112 ：デフォルトの名無しさん：2013/10/08(火) 04:06:25.40

>>111
自分のこと言ってんの？

113 ：デフォルトの名無しさん：2013/10/08(火) 04:08:30.37

もう煽りはいいからね……
前向きな話をしようよ。
このスレで話すべきことはこんな技術があるよってことでしょ？

114 ：デフォルトの名無しさん：2013/10/08(火) 04:11:16.27

煽ってきたのはそっちだってーのｗ

ライブコーディングの意味間違ってるでしょ？
それに対して反論がないなら、
何も言うことはないはずだよ？

誰にレスしてんのさ。

115 ：デフォルトの名無しさん：2013/10/08(火) 04:18:36.31

>>113
言うだけ無駄無駄
こいつら最初から分かり合うつもりなんて一切無いし

折角わざわざ過疎スレに動的言語のネタ投下してやってるのに、こいつら言語と同じで頭まで固い
普通だったら勉強になるなぁってなるとこ

今じゃ色んな言語が色んな言語の特徴を取り入れてるってのに
おまえ自身の思考が潜在能力を潰してることに気づいたときには手遅れｗ

116 ：デフォルトの名無しさん：2013/10/08(火) 04:22:26.11

>>114,117
お得意の記憶操作＆被害妄想いつもご苦労でーすｗｗ

117 ：デフォルトの名無しさん：2013/10/08(火) 04:24:05.36

自演のコメは間隔が約10分あいててわかりやすいね（笑）

118 ：デフォルトの名無しさん：2013/10/08(火) 04:26:48.15

おお、こりゃ自演バレが余程応えたようだｗ
効いてるｗ効いてるｗｗ

119 ：デフォルトの名無しさん：2013/10/08(火) 04:27:24.44

こいつなんで煽るんだろう？

ライブコーディングの間違いを指摘しただけでしょ？

120 ：デフォルトの名無しさん：2013/10/08(火) 04:31:16.25

素直に間違いも認められないし、謝ることも出来ない。
言動がガキそのもので人間性が最悪、最底辺だなーって思うね。
多分本人も気づいてないんだろうけどさ。
社会の落ちこぼれなんだろうな。
だからここでうっぷんを晴らしている。

121 ：デフォルトの名無しさん：2013/10/08(火) 07:17:48.66

頭から読み直してて気になったんだけど、>>96って本当にコンパイル通るの？

>>97
君の考える型推論って何？

122 ：デフォルトの名無しさん：2013/10/08(火) 07:25:38.46

型注釈はあっていいなぁ。あって困る理由がない。

123 ：デフォルトの名無しさん：2013/10/08(火) 08:33:53.33

numberって型注釈を書いてstringが返ってくるくらいなら
何も無いほうがマシ
まじで騙されるわ

124 ：デフォルトの名無しさん：2013/10/08(火) 14:11:18.65

コメントにnumberを返すって書いてあるのにstringが返ってくるくらいなら
コメントなんて無いほうがマシ
まじで騙されるわ

アホでしたか。

125 ：デフォルトの名無しさん：2013/10/08(火) 16:16:27.15

アホはお前だ

126 ：デフォルトの名無しさん：2013/10/08(火) 17:31:07.05

TSはJSに変換されるんだからオーバーヘッドがかからないように
実行時の判断は省略されるのは当たり前
エディタの問題であって言語の問題ではないし
凄く特殊なケースを挙げてまで何がしたいのだろうか？

127 ：デフォルトの名無しさん：2013/10/08(火) 17:36:43.20

型チェックをすり抜けるんだからコンパイラの問題じゃん

128 ：デフォルトの名無しさん：2013/10/08(火) 18:01:52.58

せやな
言語のせいじゃない

129 ：デフォルトの名無しさん：2013/10/08(火) 18:16:58.80

>>106
いや、ライブで実行することだけど？
少なくとも学術論文ではそうなっているよ？

130 ：デフォルトの名無しさん：2013/10/08(火) 18:19:55.04

コンパイラがバグってるんじゃなかったら、
そんなユルユルな型チェックで良しとする言語の問題

131 ：デフォルトの名無しさん：2013/10/08(火) 18:24:44.98

TypeScriptの場合、>>96は仕様通りだよ

132 ：デフォルトの名無しさん：2013/10/08(火) 18:28:01.89

>>129
http://en.wikipedia.org/wiki/Live_coding

133 ：デフォルトの名無しさん：2013/10/08(火) 19:40:26.15

まさかのソースはウィキかw
ほれ、学術系での定義
http://liveprogramming.github.io/2013/papers/liveness.pdf
A system supporting fully live programming is one that permits
a programmer to edit a program while it is running, and furthermore
the system continues the execution immediately and without noticeable
interruption according to the updated version of the program

134 ：デフォルトの名無しさん：2013/10/08(火) 19:50:05.04

LLと同じで必ずしも同じ意味で使われてるとは限らないでしょ
言葉尻捉えるより相手の気持ち汲み取ってあげようよ

135 ：デフォルトの名無しさん：2013/10/08(火) 20:07:10.68

>>134
同意。というわけで>>106は反省するように。

136 ：デフォルトの名無しさん：2013/10/08(火) 21:00:15.73

Java, PHP, 旧VB, 古い時代のPerl, Javascript

この辺りの言語しか経験の無い奴って
ウンコ言語の基準でしか物事考えられないから
議論が噛み合ない

137 ：デフォルトの名無しさん：2013/10/08(火) 21:08:53.33

まあJavaScriptはいくらバージョンを重ねたところで今ブラウザで広くまともに使えるバージョンが
未だウンコなので仕方がない。

138 ：デフォルトの名無しさん：2013/10/08(火) 21:32:30.60

広く使える必要なんて皆無だけどな
広く広まってる分新しいバージョンの人数も多いということでもあるし
そもそもWeb上のものだけのものでもないからね

139 ：デフォルトの名無しさん：2013/10/09(水) 05:10:43.68

ロジックはc++で書いてasmjsにして終わり
早くこんな時代になってほしい
UIはjsでいいかな

140 ：デフォルトの名無しさん：2013/10/09(水) 06:09:48.79

asm.jsで直接扱えるのは数値と真偽値だけです

141 ：デフォルトの名無しさん：2013/10/09(水) 06:26:44.38

>>133
ライブコーディングでなくて、ライブプログラミングだし、
しかもライブコーディングの部分読む限りwikiと変わらんけど。
自分で相手の根拠示すとか、根本的なアホなの？

142 ：デフォルトの名無しさん：2013/10/09(水) 06:27:32.62

今現在一般向けのウェブサイトのUI開発にCoffeeScriptの類を使うのは珍しく
無いけど、ECMAScript6相当を同じ分野に投入できるのはまだまだ先だろうな。

当面はサーバーサイド等の特定実装かマニアの趣味。
ブラウザのバージョンの入れ替わりの速いモバイル向けのHTML5アプリから使わ
れ始めて、PC向けのサイトにも使えるようになるのはGoogleがIE10のサポートを
切る辺りだろうから、まだ数年かかる。

143 ：デフォルトの名無しさん：2013/10/09(水) 06:32:38.79

>>141
ちゃんと論文全文読もうね。

144 ：デフォルトの名無しさん：2013/10/09(水) 07:08:46.87

>>143
ブーメランですね。

145 ：デフォルトの名無しさん：2013/10/09(水) 07:25:37.94

CoffeeScriptやTypeScriptはES6みたいなものだ
CSはESの礎（プロトタイプになったし）
TSのはES.nextを意識して実装してる
classとかアロー関数とか有名なものは皆は同じ

146 ：デフォルトの名無しさん：2013/10/09(水) 07:38:01.16

つまりCoffeeScriptやTypeScript、Haxeを使っておけば良いということか。

147 ：デフォルトの名無しさん：2013/10/09(水) 07:45:44.43

ブラウザではコンパイルしてJSになる言語を使ってればOK

148 ：デフォルトの名無しさん：2013/10/09(水) 07:51:16.95

>>146
今使うのならCSよりはTSにした方がいい
CS使うのならES6simuの方がいい

149 ：デフォルトの名無しさん：2013/10/09(水) 07:55:45.82

でーでもTSの型推論ゴミでしょ？
マトモな型推論ある言語を使った事あったら
草不可避

150 ：デフォルトの名無しさん：2013/10/09(水) 07:58:24.79

まあES6はES5に置き換え不可な機能がいくつか合って
classもそうなんだけどな
とにかくclass構文に関しては導入され次第さっさと使った方がいい

>>142
IE12はおそらくwin7対応だろうし
自動アップデートされるから10とか気にしなくて良くなるよ
Vistaの9が暫く気になるかなー、まあ数少ないし仕方ないかくらい

151 ：デフォルトの名無しさん：2013/10/09(水) 08:00:12.03

TSに型推論なんてないぞ？
型注釈ならあるがあくまで開発サポートのためで
実行時には綺麗サッパリ外れてほぼCSと同じコードになる

152 ：デフォルトの名無しさん：2013/10/09(水) 08:07:38.73

いくらTSの型推論がゴミだからって、全く型推論が無い扱いは可哀想だろうよ
一応、この程度のコードなら型チャックしてくれるんだから

function f(): number {
    var x = 1
    var y = x + "a"
    return y // Cannot convert 'string' to 'number'
}

153 ：デフォルトの名無しさん：2013/10/09(水) 08:08:18.44

うわ、型チャックってなんだ。型チェックだ

154 ：デフォルトの名無しさん：2013/10/09(水) 08:08:47.23

マトモな型推論ある言語を使った事あったら
TypeScriptに型推論があるなんて思うわけがない
上に出てた型推論とは全く関係ない指摘を型推論と思い込んじゃたってのがすぐ分かる

155 ：デフォルトの名無しさん：2013/10/09(水) 08:10:44.24

>>152
型推論っていうのは宣言を明示的にしなくても
勝手に宣言してくれるような機能であってそういう明示的なのとは全く違う

156 ：デフォルトの名無しさん：2013/10/09(水) 08:12:01.27

でもこれは型チェックできない、ワロス

function f(): number {return ((x) => x)("a")}

157 ：デフォルトの名無しさん：2013/10/09(水) 08:12:46.05

>>155
xやyの型はいつ宣言しましたか？

158 ：デフォルトの名無しさん：2013/10/09(水) 08:14:35.63

xやyの型でエラーが出てるんじゃなくて
関数の戻り値の型と合わないエラーでしょ
型推論っていうのはこういうの

var x = [];
x = 1; //error

159 ：デフォルトの名無しさん：2013/10/09(水) 08:17:00.22

>>158
お前本当に何も分かってないな
宣言してないyの型を推論して、その推論した型と戻り値の型が合わないから
エラーを出してるんだろうが

で、>>158のそのxは何で型エラーが出てるの？www

160 ：デフォルトの名無しさん：2013/10/09(水) 08:18:41.96

型推論っていうのは
型を推論することじゃなくて
どの型で宣言されればいいのか推論することです
いい加減恥ずかしいからやめてね

161 ：デフォルトの名無しさん：2013/10/09(水) 08:22:38.27

これでも見て勉強しろ。
http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96

162 ：デフォルトの名無しさん：2013/10/09(水) 08:28:30.40

>>160
いや、まさに型を推論してるんだけど

で、>>158は何でエラーになったの？答えてよ
あと>>157にもね

163 ：デフォルトの名無しさん：2013/10/09(水) 11:11:27.33

function add_1(x){ return x + 1; }
function add_2(x){ return add_1(add_1(x)); }

add_2("22"); // compile error

こうだろ普通
戻り値型の注釈付けておいて型推論できましたって言われても

164 ：デフォルトの名無しさん：2013/10/09(水) 11:41:27.36

それは何でコンパイルエラーなの？

165 ：デフォルトの名無しさん：2013/10/09(水) 11:50:49.86

>>164
型推論が働くならコンパイルエラーという意味

166 ：デフォルトの名無しさん：2013/10/09(水) 13:03:03.35

JSは文字列と数の加算が定義されてるんだから、
勝手にエラーにしたらダメだろ

167 ：デフォルトの名無しさん：2013/10/09(水) 14:25:23.29

IE11、ES6対応といっても主要な機能だとletとconstへの新規対応だけなんだな。

ES6は凄い -> letとconstが使えます、って事か。実質。
そりゃ凄い。

言語の仕様拡張で夢は広がりんぐは結構だけど肝心の実装とランタイム環境の更新が
伴ってない。

ブラウザ向けは当面別の言語の模索も続くだろうね。Haxeってどうなん?

168 ：デフォルトの名無しさん：2013/10/09(水) 14:40:57.26

>>166
それもまともに型推論働かない理由の一つだな
根本的におかしい機能に固執する

169 ：デフォルトの名無しさん：2013/10/09(水) 15:43:45.77

varはスコープの先頭にまとめるというスタイルも変数巻き上げのトラブルを避けるための
ノウハウはいえ、客観的にみると単にウンコな変数宣言の仕様に巻き込まれて強制されて
いるだけで、見栄え的にも何時の時代のCよという感じではあるな。

170 ：デフォルトの名無しさん：2013/10/09(水) 17:22:36.80

>>163
ローカル変数の型推論は型推論と呼ばない俺ルール発動ですか？
俺ルールじゃないなら信頼できるソースを頂けますか？

171 ：デフォルトの名無しさん：2013/10/09(水) 18:11:14.52

>>170
俺ルール発動か？
そもそも型推論じゃないとは言ってないが
そんな貧弱なチェックであるとドヤ顔されても困ると言ってる

172 ：デフォルトの名無しさん：2013/10/09(水) 19:49:32.66

型推論っていうのは変数の宣言される型を推測することであって
その変数がどんな型かを推論することじゃないだろ
TypeScriptの場合varで宣言したときはJSと同じ任意型であって
型推論で型が決定されているわけじゃない

173 ：デフォルトの名無しさん：2013/10/09(水) 19:54:40.67

>>169
それはJSに慣れてない人のためのもので
知っていれば別になんでもないこと

174 ：デフォルトの名無しさん：2013/10/09(水) 20:07:26.61

>>172広義では型を決め打ちすること全般でいいんじゃ？

175 ：デフォルトの名無しさん：2013/10/09(水) 20:20:03.95

ほかの言語の欠陥はあげつらうのにJavaScriptの欠陥は「知っていればなんともない」
なんですね。巻き上げられて良いことなんて何もない、単なるバグの発生源なのに。

176 ：デフォルトの名無しさん：2013/10/09(水) 20:24:41.48

つーかTSとかの型推論挙げずに素直に関数型言語や.NET系の型推論挙げとけよ

177 ：デフォルトの名無しさん：2013/10/09(水) 20:32:15.72

>>172
いい加減なこと書くなよ
ちゃんと任意型を表すanyがあるし、varで宣言しても任意型にならない
第一任意型なら、>>152はエラーになったらダメだろうが

ここでも読んで出直してこい
TSの型推論ついても書いてあるから
http://phyzkit.net/typescript/

178 ：デフォルトの名無しさん：2013/10/09(水) 20:41:08.15

anyとvarで吐かれるコードは同じ
そんないい加減なもの型推論とはいえない

179 ：デフォルトの名無しさん：2013/10/09(水) 20:42:44.15

>>175
それでバグが起こったことや実際見たことなんて入門したての頃から１０年強一度もないな。

180 ：デフォルトの名無しさん：2013/10/09(水) 20:46:08.43

>>178
型チェックの結果コンパイルエラーになるか否かが違う

181 ：デフォルトの名無しさん：2013/10/09(水) 20:50:05.99

なって無いじゃん
そんなんコンパイラの気休めサービスで言語の機能じゃないだろ

182 ：デフォルトの名無しさん：2013/10/09(水) 20:51:58.89

>>179
宣言を最初にまとめる方が異端な現状を見ると全く説得力がない
ただ気になる人もいるってだけでそりゃ人間の好みって言うもの
lintとかでも途中の宣言を認めないなんてものはないし
実際困ることもない

重複宣言にならないっていう便利なことはある
letなどならこれはエラーになってしまう
要は使い分けの問題

183 ：デフォルトの名無しさん：2013/10/09(水) 20:53:55.14

これはコンパイルエラー

var x = 0
var n : string = x // Cannot convert 'number' to 'string'

こっちはコンパイルエラーじゃない

var x : any = 0
var n : string = x

184 ：デフォルトの名無しさん：2013/10/09(水) 20:56:15.46

>>181
TSの仕様書にも型推論について書かれてるけど……

http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf

185 ：デフォルトの名無しさん：2013/10/09(水) 20:57:05.49

ES7のguardが導入されるのを待とう。
既に一部ES7候補の仕様を実装してきているFirefoxならそう遠くないはず。

186 ：デフォルトの名無しさん：2013/10/09(水) 20:58:56.02

その通り動かない仕様書なんて便所の落書きと同じｗ
必死だなTS厨ｗｗｗ

187 ：デフォルトの名無しさん：2013/10/09(水) 21:01:48.34

>>186
＞その通り動かない仕様書なんて便所の落書きと同じｗ

仕様書のどの辺りを読んで、仕様通りに動かないと思ったの？
仕様書のその箇所を引用してみて

188 ：デフォルトの名無しさん：2013/10/09(水) 21:02:56.57

TypeScriptは言語じゃなくて「JavaScriptをよりよく書くためもの」だからこんなものだよ。
それで十分役目を果たしてるんだから問題ない。

189 ：デフォルトの名無しさん：2013/10/09(水) 21:06:40.48

>>187その必要はないｗ
こちらにはちゃんとした型推論ではなく気休めサービスでしか無い証拠があるんだからｗ
そちらがちゃんと示してコンパイラの実装不備で今は便所の落書きになってるけれど
将来は期待してくださいお願いしますって弁解してみろよｗｗ出来るもんならｗｗｗｗｗ

190 ：デフォルトの名無しさん：2013/10/09(水) 21:10:10.41

>>189
いや、型推論がゴミなのは仕様通りなので、
コンパイラの実装不備っていう結論はおかしい
そう言える証拠があるなら別だけど

191 ：デフォルトの名無しさん：2013/10/09(水) 21:11:41.60

>>189
仕様書も読まずに仕様について語るなよ……
それでもプログラマかよ

192 ：デフォルトの名無しさん：2013/10/09(水) 21:11:56.46

ゴミの型推論が仕様通りならちゃんと擬似型推論って言えよｗｗ
見え張ってんじゃねえよｗｗ

193 ：デフォルトの名無しさん：2013/10/09(水) 21:13:30.92

>>191
馬鹿かｗ
こっちは型推論が仕様にあるって言葉を信用したんだよｗ
で、実際はゴミだったわけだｗ詐欺だわｗｗｗ

194 ：デフォルトの名無しさん：2013/10/09(水) 21:15:06.78

>>193
うわぁ、仕事できなそう…

195 ：デフォルトの名無しさん：2013/10/09(水) 21:17:30.63

遂にTS厨白旗かｗｗ
もう人格批判がやっとやっとｗｗ

196 ：デフォルトの名無しさん：2013/10/09(水) 21:19:09.20

ていうか、一貫してTSの型推論はゴミだと書いてきたつもりだが…
どのレスを読んでTS厨だと思ったのだろうか

197 ：デフォルトの名無しさん：2013/10/09(水) 21:24:51.87

型推論なんていらない
せっかくの動的型の優位性が失われる
自動変換も知らないやつが悪い

198 ：デフォルトの名無しさん：2013/10/09(水) 21:26:21.49

自動変換？暗黙の型変換のこと？

199 ：デフォルトの名無しさん：2013/10/09(水) 21:28:05.57

JavaScriptの暗黙の型変換や条件評価はものすごく複雑だぞ
まあ普段使う分にはその1/5くらいの知識で十分だろうが

200 ：デフォルトの名無しさん：2013/10/09(水) 21:34:35.57

型推論で失われる動的型の優位性って何？

201 ：デフォルトの名無しさん：2013/10/09(水) 21:38:22.80

型推論をパフォーマンス向上のために使うのなら結構だし、実際されてることだけど、
それを厳格さのために用意されて型エラーが出るようなことになると相性悪いってことじゃない？
やっぱりguardとか「型揃え」の方が考え方として相性いいんじゃないかな。

202 ：デフォルトの名無しさん：2013/10/09(水) 21:39:12.25

連想配列に色んな型を含める

203 ：デフォルトの名無しさん：2013/10/09(水) 21:41:38.17

オブジェクトに入れればいいんとちゃうん？

204 ：デフォルトの名無しさん：2013/10/09(水) 21:46:20.12

連想配列はMapを使えばいい

205 ：デフォルトの名無しさん：2013/10/09(水) 21:48:04.17

>>198 >>200
実を言うと釣りのつもりで書いたのに
擁護多すぎてドン引き中

206 ：デフォルトの名無しさん：2013/10/09(水) 22:06:17.72

まあ本当にそこは言語の「柄」、そうじゃなくなったらその言語じゃないって部分だから
JavaScriptを使う限り前向きに受け入れて使うしか無いでしょう
どんな言語でもそう

207 ：デフォルトの名無しさん：2013/10/09(水) 22:07:43.07

new xcomponent({width:200, height:100, visible: false})　// 使用

動的
xcomponent::constructor(xcis){...}

静的
xcomponentInitStruct {
　int width,
　int height,
　bool visible
}
xcomponent::constructor(xcomponentInitStruct xcis){...}

208 ：デフォルトの名無しさん：2013/10/09(水) 22:15:29.31

既に「エラーの出ない型推論」をエンジンが暗黙的にやってくれてるんだから
JSはそれでいいじゃん

209 ：デフォルトの名無しさん：2013/10/09(水) 22:17:35.88

scalaとかも静的型なんだが

210 ：デフォルトの名無しさん：2013/10/09(水) 22:18:25.61

実行速度だけで言えばそうかもね
もっとも実行速度で比べたらJSも静的型言語に比べたら遅いけど

211 ：デフォルトの名無しさん：2013/10/09(水) 22:20:32.41

まあ、TSの型推論をみれば、JSのエンジンがやってる型推論の程度も想像がつくな
本当に自明なところだけ推論してるんでしょう

212 ：デフォルトの名無しさん：2013/10/09(水) 22:20:57.36

JSは変数使いまわしたら推論効かなくなるっちゅうの

213 ：デフォルトの名無しさん：2013/10/09(水) 22:28:06.13

俺ならこうする
y &= ~(y >> 31);

214 ：デフォルトの名無しさん：2013/10/09(水) 22:29:58.28

型推論というのは二種類あって、
一つは、静的型付け言語用の機能で型を書くのが
面倒だからそれを省略してかけるという機能

これはあくまで省略記法であり型情報は失われておらず
型を書いているのと全く変わりがない。

そのため静的型付け言語用であり、こっちの意味の型推論は
動的型付け言語には存在しない。
一般に言われる型推論というのはこっちの方。

もう一つは動的型付け用の機能で、明らかに特定の型しか
なりえないと判断した時に、動的な言語の遅さをカバーするために
特定の型用に最適化するための機能。

JSなんかの型推論というのはこっちの方。

コンパイラが頑張って型を推論できればいいのだが
現実にはそれが難しいために、型を明確にするために
特殊な書き方をすることがある。

215 ：デフォルトの名無しさん：2013/10/09(水) 22:33:21.31

うーん。それだと実行時に統計情報を収集して
特定の型用の最適化コードを生成するのも含んでしまう感じだな

216 ：デフォルトの名無しさん：2013/10/09(水) 22:33:56.84

HaskellとCoffeeScriptの組み合わせがトレンドなんだろ？

217 ：デフォルトの名無しさん：2013/10/09(水) 22:34:15.28

>>211
プロファイル数に応じて投機度と最適化度を変えてるし、
Firefoxなんかは何個もエンジン積んで使い分けてる。
http://ledyba.org/2013/02/27181531.php

218 ：デフォルトの名無しさん：2013/10/09(水) 22:38:37.67

asm.js使うとネイティブ超える場合もあるしなあ

219 ：デフォルトの名無しさん：2013/10/09(水) 22:38:55.09

後者ってVMで有効になるやつのことでしょ
JSみたいに根幹にハッシュ使ってる言語で型推論で最適化とかいっても焼け石に水だと思うけどなあ

220 ：デフォルトの名無しさん：2013/10/09(水) 22:41:20.55

最適化に邪魔な仕様は意図的に無視して
何らかの不具合が生じた場合にフォールバックするというのが
JS最適化の手法

221 ：デフォルトの名無しさん：2013/10/09(水) 22:43:40.74

既にhotspotが通ってきた道だな

222 ：デフォルトの名無しさん：2013/10/09(水) 22:45:13.22

だってV8の主流メンバって同じ人でしょ？

223 ：デフォルトの名無しさん：2013/10/09(水) 22:47:12.54

>>217はv8じゃなくてmozillaだろ

224 ：デフォルトの名無しさん：2013/10/09(水) 22:47:30.55

いくらJSでも型が途中で変わる方が稀だしな
JSerが型宣言を嫌うのは厳密性よりもむしろ面倒だから
だから型推論は嫌いじゃない

225 ：デフォルトの名無しさん：2013/10/09(水) 22:49:39.11

>>223
>>220-221に対して言ったまでだしV8も基本は同じです
仮想クラスを仮定したり変数や配列なんかのタイプも仮定してる

226 ：デフォルトの名無しさん：2013/10/09(水) 22:51:06.32

asm.jsみたいなのがJSのあるべき姿じゃね？

227 ：デフォルトの名無しさん：2013/10/09(水) 22:51:09.63

そういう人は型推論付きの関数型言語やるとJSが嫌いになる
ソースは俺

228 ：デフォルトの名無しさん：2013/10/09(水) 22:53:48.75

>>226
asm.js式の最適化方法は汎用化されてエンジンに採用されてきてるよ
まあでも要はこれguardだよね、ES7が入ればやっぱりこのへんは良くなるだろうね

229 ：デフォルトの名無しさん：2013/10/09(水) 22:55:28.08

>>226
あんなの使うならVM作ればいいじゃんって思う
emscriptenのために犠牲になってるとしか思えない

230 ：デフォルトの名無しさん：2013/10/09(水) 22:58:28.07

VM作っても型が動的でであるならば
結局遅いんだけどね。

231 ：デフォルトの名無しさん：2013/10/09(水) 23:00:19.13

何回か書いたことあるけど
一番ダメなのはデバッガの表記が解決に繋がりにくいこと
今手で書くとして一番ダメなのはそこ
あとやっぱり形態がモジュール風というか、
ちょっとasm.js関数１つ作りたい時とかには厳かすぎるね

232 ：デフォルトの名無しさん：2013/10/09(水) 23:02:25.13

asm.jsなんて手書きするもんじゃないと思う

233 ：デフォルトの名無しさん：2013/10/09(水) 23:04:43.45

>>232
ぐう正論

234 ：デフォルトの名無しさん：2013/10/09(水) 23:07:09.89

ES7のguardsって何？パターンマッチの出来損ないみたいなもの？

235 ：デフォルトの名無しさん：2013/10/09(水) 23:08:24.66

>>232,233
それは好奇心を制限するものではないさ
自分はまだ手で各可能性を信じてるよ
ようはlintとデバッガさえまともになれば手で書けるんだからね

236 ：デフォルトの名無しさん：2013/10/09(水) 23:11:08.48

>>234マルチ型付け
つまり変数の型を決定するのではなく、入ってくる型を宣言する仕組み
ようするにガード

237 ：デフォルトの名無しさん：2013/10/09(水) 23:13:58.66

>>236
宣言した以外の型が入ってきたときはどうなるの？

238 ：デフォルトの名無しさん：2013/10/09(水) 23:14:16.94

おれはすでにロジックはC++で書いてemscripten

239 ：デフォルトの名無しさん：2013/10/09(水) 23:22:38.30

>>237当然エラー
多分こんな感じになるんじゃない？
let x :: Number | Boolean = value;

240 ：デフォルトの名無しさん：2013/10/09(水) 23:34:12.80

ES7では特に数値型に関してはリテラルもたくさん入る。
それら同士の演算結果の型がどうなるか次第でだいぶイメージ変わる。
そもそもプリミティブ型になるのかvalue-object型になるのかが不明。

241 ：デフォルトの名無しさん：2013/10/09(水) 23:42:16.48

演算子オーバーロードとValueProxyが入るから
ES7からはどんなものでも自由自在に暗黙の型変換できるし
いくつも新たに定義されるだろう

242 ：デフォルトの名無しさん：2013/10/10(木) 00:56:36.30

Mozillaだけが突っ走ってその他のブラウザが実装し始めるのはずっと先だと思うけどね。
そんな未来は来ない可能性だってある。

243 ：デフォルトの名無しさん：2013/10/10(木) 01:07:35.53

ValueObjectはES6に前身が入ったしES7途中経過報告でもう発表されてるし
ES7の３本柱になることが確実なものよ
ES6で実装する時に手間をかけるからES7への移行はスムーズに行くはず

そこんとこプリミティブ型になったらやっぱり厄介だろうね
だから実装負荷も考えてValueObjectで行くことになると思う
Parallelsも他の仕様と絡みにくいWorkerの糖衣APIみたいなものだから実装は容易
ガードもただ実装するだけなら型チェックの変形版だから容易

244 ：デフォルトの名無しさん：2013/10/10(木) 01:24:19.40

ValueObjectってどのブラウザで使えるの？

245 ：デフォルトの名無しさん：2013/10/10(木) 01:44:20.08

FirefoxでValueObjectのコンストラクタ（？）の前身が使える
int8(123)とかfloat32(123)

今これはただint8やfloat32に揃えられたdouble
Numberプリミティブ型が帰ってくるだけで、
ES6ではStructType({ x: uint32, y: uint32 })
とかして構造体っぽいのを作るために専ら使われるものだけど

ES7ではこれが増えて
int64(123)
bignum(123)
decimal(123)
とかしたときはValueObjectというものが帰ってくる予定

そしてそれらを演算子オーバーロードやValueProxyの技術と合わせることによって
オブジェクト間の演算が可能になって、JSに型を増やせるねってこと

246 ：デフォルトの名無しさん：2013/10/10(木) 01:57:16.84

Haskellの先進性に比べると
JSに追加される機能は
時代遅れのウンコと言わざるをえない

247 ：デフォルトの名無しさん：2013/10/10(木) 01:59:49.12

先進過ぎて誰も付いてこれないんじゃないか？
例えるなら鳩山由紀夫みたいなもんだろう

248 ：デフォルトの名無しさん：2013/10/10(木) 02:08:53.50

そりゃあだって今までは単なるブラウザの上で
ちょこちょこっとHTMLを動かすだけのスクリプトだったんだからね

でもこれからは低レベル、高レベル、スクリプト言語として、大規模開発用言語として
幅広く、深く進化していくよ
ES5移行は本当に多くの言語を参考にして作られてる
確かHaskellもどこかの仕様で見たし、議論でも見たよ
遅いかもしれないけど失敗や出戻りが少なくて済む、
馴染み深いものが入ると思えばいい

特にパフォーマンスに関しては貪欲だよ
初めて言語仕様で最適化を明言しようとしてるし、
マルチスレッド化やSIMD系の型も入る

他にもイベントループとそれを扱う仕組みが言語に組み込まれたり
とにかく見てて毎日飽きない
そこがJavaScriptの一番の良さだと思ってる
完成されきっちゃったら話すこと無くてつまんないじゃん

249 ：デフォルトの名無しさん：2013/10/10(木) 03:08:09.06

平和だなあ

250 ：デフォルトの名無しさん：2013/10/10(木) 03:11:24.08

>>182
>宣言を最初にまとめる方が異端な現状を見ると全く説得力がない

これはそうかなぁ。

function(){
var a = ... ,
　　i = 0, ...

......

for(; i < x; i++)

的なのはよく見るでしょ。書き方のスタイルとして。

251 ：デフォルトの名無しさん：2013/10/10(木) 04:06:30.16

おいおいｗ
それは２０００％ないわｗ
ループ複数書く時詰むだろそれｗ
これの間違いだろ……
（書き慣れてないのがすぐ分かるなオイ（笑））

function(){
var i

......
for(i = 0; i < x; i++)

252 ：デフォルトの名無しさん：2013/10/10(木) 05:44:13.14

2000%無いって、jQueryそのものや関連プラグインはこの書き方多いやん・・・

カウンタの類の初期化まで先頭でまとめてやるのは極端にしても関数の初めの方に
変数宣言をまとめる傾向はJavaScriptでは結構目立つと思う。

253 ：デフォルトの名無しさん：2013/10/10(木) 05:46:12.32

jQueryはその上で変数を使い回す

254 ：デフォルトの名無しさん：2013/10/10(木) 05:51:47.11

傾向と徹底するのはぜんぜん違うだろ……

255 ：デフォルトの名無しさん：2013/10/10(木) 06:02:12.24

jQueryがなんぼのものかは知らんが
自分が信頼できるソースでそんなコーディング使われてるのは見たことがない
https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/v8natives.js
http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Array.js
https://github.com/joyent/node/blob/master/src/node.js

ESコミュでも
スーパーマンの書いてるコード適当に見ても
ブログ　http://www.2ality.com/
GITHUB　https://github.com/domenic/promises-unwrapping/blob/master/run-tests.js
見当たらない

256 ：デフォルトの名無しさん：2013/10/10(木) 06:15:20.99

NPMスタイルのセミコロンフリーと同じ
合理性を考えてのものだが異端は異端
でもそれを愛するのは素晴らしいこと
俺もセミコロンフリーで貫いてきてる

257 ：デフォルトの名無しさん：2013/10/10(木) 12:08:03.32

JSでセミコロン無しで書く奴はキチガイ
素直にCoffee使えと

258 ：デフォルトの名無しさん：2013/10/10(木) 12:29:08.52

言語仕様で省略が定義されてるんだから不必要なところで省くのは当然。
Coffeeでもいるときはいる
何も変わらない

259 ：デフォルトの名無しさん：2013/10/10(木) 12:35:25.62

そう言えばコンストラクタをnew無しで呼び出すと
グローバルに変数ができたり誤作動起こすから
JSではインスタンス化にnew使うなっていう派閥があったな
それと同じくらい過度に慎重すぎね？
もちろん付けるスタイルもありだと思うが
付けないからといって基地外はないさ

260 ：デフォルトの名無しさん：2013/10/10(木) 14:50:51.20

jsマンセーしてる奴らは静的関数型なんが触ったこともない低濃どもでしょ？
あんなクソ言語で生産性高いとか片腹痛いわw

261 ：デフォルトの名無しさん：2013/10/10(木) 14:54:21.76

>>260
ダメ日本語が流行りなのか？

262 ：デフォルトの名無しさん：2013/10/10(木) 15:00:47.39

>>260
具体的にpls

263 ：デフォルトの名無しさん：2013/10/10(木) 15:06:02.41

実際のところMozilla以外のES6の実装の現況ってどうなの。
letとconstだけ実装されてその他の機能のサポートはベンダーごとにてんでばらばら
というオチにならない保証ってあるの?

264 ：デフォルトの名無しさん：2013/10/10(木) 16:35:56.56

標準があるのにどうしてバラバラになると思うのか？
１１月くらいがラストコールだから
表立った実装は来年来年からってとこでしょう

V8は近々大きな動きありそうだけど

265 ：デフォルトの名無しさん：2013/10/11(金) 03:58:39.03

jsは標準ライブラリの類が貧弱すぎ
c++にすら負けてるって言語として存在価値なし

266 ：デフォルトの名無しさん：2013/10/11(金) 04:46:26.38

標準ライブラリが多くあるべきかどうかは良し悪しあると思う
特にJSは「スクリプト」なんだから環境に応じた
ホストオブジェクトを提供してもらったほうがとても合理的
基本的なものは揃ってると思うし

267 ：デフォルトの名無しさん：2013/10/11(金) 05:17:19.54

ある程度クロスプラットフォームじゃないと
スクリプト使ってる意味ない気がするが

268 ：デフォルトの名無しさん：2013/10/11(金) 05:23:15.45

共通して必要そうなものはひと通り揃ってると思うが……

269 ：デフォルトの名無しさん：2013/10/11(金) 05:40:57.98

具体的に書いてくれんと困るな
具体的に何が不足してると思うのか

270 ：デフォルトの名無しさん：2013/10/11(金) 05:48:53.69

ライブラリの多い少ない以前にJavaScriptはライブラリをimportする機能が言語仕様に
無いじゃん。ライブラリ毎に手作りしたローダー使うとか<script>タグ使うとかバラバラ。

来年か再来年には解決するらしいが。

271 ：デフォルトの名無しさん：2013/10/11(金) 05:51:57.33

ES6にあるからそれを今言われてもどうとも言い様がないな。
１年待ってね、ってくらいか。

272 ：デフォルトの名無しさん：2013/10/11(金) 06:03:37.25

結局ライブラリとは何だったのか……

273 ：デフォルトの名無しさん：2013/10/11(金) 06:10:48.66

つかえねーなw

274 ：デフォルトの名無しさん：2013/10/11(金) 08:26:16.37

JSに代数的データ型とパターンマッチが入るのは何時ですか？

275 ：デフォルトの名無しさん：2013/10/11(金) 09:06:56.87

>>270
そんなもん、requirejsでとっくに解決してるじゃん。
requirejsでscriptタグで読み込むのを想定したライブラリも使える。

実際にライブラリが使えるのであれば、
ライブラリをインポートする機能の有る無しは問題じゃない。

276 ：デフォルトの名無しさん：2013/10/11(金) 09:19:43.77

requireは今は処理系拡張であって言語仕様にないだろ
標準化してから言えよ

277 ：デフォルトの名無しさん：2013/10/11(金) 09:22:45.03

本当に欲しいのはブラウザの上で動くVMであって、いまjsをそのような使い方してるけどこれじゃない感はあるよね。どうしても無理やりにしたりjsの言語仕様に引っ張られる。
その上でjsが実装されたり他の言語やそれをラップしたJVMやCLRが動いてネイティブの移植が格段に楽になるとかなればいいのに。
その上で皆が実装言語としてjsを使うかは見ものではあるけれど。
各社足並み揃えて作ってくんないかなー

278 ：デフォルトの名無しさん：2013/10/11(金) 10:04:49.21

Scalaでappletを書けないものかね？

279 ：デフォルトの名無しさん：2013/10/11(金) 15:08:05.08

>>274
＞データ型
ES7
＞パターンマッチ
意味が広すぎ

>>276
標準化されてるよ

>>277
何も具体的なことがない長文ご苦労

280 ：デフォルトの名無しさん：2013/10/11(金) 15:15:50.50

>>279
パターンマッチつーたらHaskellやMLにあるやつでしょ

281 ：デフォルトの名無しさん：2013/10/11(金) 15:19:33.49

ていうか、ES7に代数的データ型入るの？どんな感じのコードになるの？

あの文脈でパターンマッチが分からないとかいうし、
イマイチ>>279は分かってない気配がするんだけど…

282 ：デフォルトの名無しさん：2013/10/11(金) 15:26:12.21

それでも意味はかなり広いと思うが
ES6の分割代入やらレストパラメータやら、それこそES7のguardとかじゃないか？

283 ：デフォルトの名無しさん：2013/10/11(金) 15:32:59.91

>>281
すまん寝起きで適当に言ったが、まあJS関数型じゃないから
JSっぽく同じようなことは実現できると思うよ

284 ：デフォルトの名無しさん：2013/10/11(金) 15:42:14.53

何れにしても今は無いし使えるようになるのも再来年かそれ以降だな。

285 ：デフォルトの名無しさん：2013/10/11(金) 15:43:20.21

標準ライブラリが少ないみたいな話は、必要なら多くする必要があるかなって思うけど
もう言語の書き方については、
例えばJSにはクラスがないけど、もっと面白い方法が使えるわけで
そこはJS流で書いてねとしか言えんな
もちろんどう足掻いてもやりにくい、不足してることがあるんなら別だけど

>>284
分割代入云々は既にFFで使えるよ

286 ：デフォルトの名無しさん：2013/10/11(金) 15:53:47.98

そんな特定環境の特定実装の特定用途にしか使えないもの「使える」とは言えん。
「試せる」とでも言っておけ。

287 ：デフォルトの名無しさん：2013/10/11(金) 15:56:24.14

じゃあ試せるよ

288 ：デフォルトの名無しさん：2013/10/11(金) 15:57:50.23

素直で結構。

289 ：デフォルトの名無しさん：2013/10/11(金) 16:17:41.46

Firefox、及びそのOS、及びGMのシェアは特定とは言いがたいほど多いだろ

290 ：デフォルトの名無しさん：2013/10/11(金) 16:33:01.02

JSの場合はいっせーので実装が変わるわけじゃなくて日進月歩
機能もV8に１つメソッドが追加されたね
そういうものだからもっと緩く見て欲しい

291 ：デフォルトの名無しさん：2013/10/11(金) 16:38:18.74

>>289
ブラウザ上での用途に関してはFirefoxの機能拡張およびFirefoxでしか動かないサイトの作成というのは
充分に特定用途だと思うが。

サーバサイドに関してはこればかりは実績が伴わないと意味がない。
「使える」とは例えばストック状態のnode.js等で使えるようになってから言ってほしい。

292 ：デフォルトの名無しさん：2013/10/11(金) 16:49:53.98

あー言えばこー言う
ダメだこりゃ話にならん

293 ：デフォルトの名無しさん：2013/10/11(金) 17:19:28.99

FirefoxでES6の仕様通りに使えるものは「使える」と言っていいと思うけどな
仕様通りじゃないものは「使えない」だけど
マクロとしてのJSって未だにES3相当が多いし
そういうのまでとは一緒にできないというか、
そもそも「JavaScript」っていう名称が
EcmaScript準拠＋環境APIっていうくらいの意味しか持ってないと思う

もちろんES3のポンコツ実装からES7にいきかけてるものまで入り乱れてるのがWebだから
そこを考えると必然的に「使えない」「使えない」となってしまいがちだけど
そんな厳しい環境で話をしなくてもいいと思うんだよね

例えOpenGLES3が使えるAndroid端末が当分は数少ないとしても
そういう技術を話してる時にそれを出して使えないと言うのは違うと思うんだ
それと同じだと思う

294 ：デフォルトの名無しさん：2013/10/11(金) 17:58:27.96

そういうのはJS専用のスレでやれ
違うとか言われても実際使えないなら使わんし

295 ：デフォルトの名無しさん：2013/10/11(金) 18:01:24.32

使える環境があり、使おうと思えば使えるのは「使えない」とは言えません

296 ：デフォルトの名無しさん：2013/10/11(金) 18:05:36.83

あほくさ
Mozilla仕様なんてアドオンぐらいでしか使えないだろ
本当ウェブ界隈は似非プログラマ多いな

297 ：デフォルトの名無しさん：2013/10/11(金) 18:08:31.45

まるで働けるとこがあって働こうと思えば働けるのに
言い訳ばかりで働かないニートのようですね^^

298 ：デフォルトの名無しさん：2013/10/11(金) 18:17:36.14

仕様追いかけてるだけで書ける気になってるニート君は
XULでも書いてりゃいいんじゃない

299 ：デフォルトの名無しさん：2013/10/11(金) 18:19:35.12

仕様追いかけてるだけ？？？
実装もされてて使えるじゃん
何言ってんだこいつ

300 ：デフォルトの名無しさん：2013/10/11(金) 18:31:58.05

そりゃあ実際問題Webでは使いにくいだろうけど
意地になって使えないと言うほどのことでもないのに
なんか相手に自分の意見認めさせたら賞金とかでも出るのか？

ここは潜在能力や可能性を語るスレなんだから
こういうのもあるんだでいいんじゃないかな
何かと文句つけて否定してもメリットがないよ

301 ：デフォルトの名無しさん：2013/10/11(金) 18:46:26.30

可能性だけで言うならHaskellが最強ですね

302 ：デフォルトの名無しさん：2013/10/11(金) 18:57:08.91

requireがjsの言語仕様(ecma)で標準化されてるとか
なんでつまらない嘘つくん

303 ：デフォルトの名無しさん：2013/10/11(金) 19:04:54.48

純粋関数型言語はコア増加の流れと相性がいいと思う
この先コアが数十個、百個ってなっていった時、
超並列時代で活きやすいってのは大きな魅力
でも関数型臭さは良くない点でもあるんだよなあ

304 ：デフォルトの名無しさん：2013/10/11(金) 19:06:55.92

>>302ecmaじゃなくてJavaScript
ecmascriptはあらゆる拡張を許してるから
商標はともかくオレオレ言語仕様を入れてJavaScript仕様とするのは自由
UnityのJavaScriptなんてC#バインドの酷いもんだろ？

305 ：デフォルトの名無しさん：2013/10/11(金) 19:25:27.38

JavaScriptが何なのか
それは使ってる人によって全然違うと思う
例え同じV8でもNodeとChromeじゃ書き用が違う
やっぱり標準入出力を持たないESはスクリプト言語であって
環境と合わせて初めて言語といえるんだと思うんだよね
そんな中このスレであえて話題にできる一番しっかりしたものって言うと
勧告間近のES6draftについてじゃなかろうか
もしこのスレで鋭いアドバイスが出たらESコミュに挙げてもいいし
使える使えないの話をするより、どんな仕様や技術がいいのか話すのは
思った以上に有意義なことだと思うよ

306 ：デフォルトの名無しさん：2013/10/11(金) 19:31:17.21

UnityのJSはJSerなら絶対JSと認めないJS

307 ：デフォルトの名無しさん：2013/10/11(金) 19:45:01.23

>>304
どのオレオレJavaScriptで仕様化されているのrequireは

308 ：デフォルトの名無しさん：2013/10/11(金) 19:46:24.65

ジョークにマジレス？！

309 ：デフォルトの名無しさん：2013/10/11(金) 19:53:58.32

都合の悪い発言はジョークとか釣りってことにして有耶無耶にします

310 ：デフォルトの名無しさん：2013/10/11(金) 19:55:01.87

そんな事よりrequireが標準化されてるソースまだー？

311 ：デフォルトの名無しさん：2013/10/11(金) 19:55:55.53

アスペ乙

312 ：デフォルトの名無しさん：2013/10/11(金) 19:57:44.24

相手の言いたいことを察する能力に欠けてる
アスペ可愛く言うとKYです

313 ：デフォルトの名無しさん：2013/10/11(金) 19:59:20.36

アスペってことにして終わりにしたいんですか？
なんでrequireが標準化されてるなんてぶっこいちゃったの？
これだけでまともに触ってないのバレバレじゃん

314 ：デフォルトの名無しさん：2013/10/11(金) 20:02:11.39

誰がそんなこと言ったんだ？
またお得意の被害妄想か！

315 ：デフォルトの名無しさん：2013/10/11(金) 20:05:47.67

でっち上げは玄人()プログラマの得意技だからな

316 ：デフォルトの名無しさん：2013/10/11(金) 20:07:34.68

なんだかんだ言って、あちらこちらで話題になるJavaScriptは凄いと思う
他の言語は一瞬話題に上がってもすぐ途切れちゃうもんね
特に静的型言語はそういう傾向があるように見える
活発なLL人に比べてなんかもう皆冷めてるというか悟ってるイメージ

317 ：デフォルトの名無しさん：2013/10/11(金) 20:14:33.31

>>276
＞標準化されてるよ
本当に話し逸らして何とかなると思ってるの
標準化のソースまだー？ﾏﾁｸﾀﾋﾞﾚﾀﾖ

318 ：デフォルトの名無しさん：2013/10/11(金) 20:19:02.57

もしかして>>279か？
ちゃんとアンカ付けてくれないと誰に愚痴ってるのか分からなくて困惑するんだけど…

319 ：デフォルトの名無しさん：2013/10/11(金) 20:19:58.16

>>318
おっとごめんよ>>279だ

320 ：デフォルトの名無しさん：2013/10/11(金) 20:24:48.59

JSが興味深いから話題になってるんじゃなくて、
JSerが直ぐバレるテキトーな嘘かますから炎上してるだけじゃね？

321 ：デフォルトの名無しさん：2013/10/11(金) 20:45:05.25

>>319
もうしわけない
>>283の通り適当に書いてしまった
どうか許してくれ

322 ：デフォルトの名無しさん：2013/10/11(金) 20:59:43.92

>>321
まともに会話する気がある人の時点で許すよ
心から許すよ

323 ：デフォルトの名無しさん：2013/10/11(金) 21:26:42.03

たまには文句言う前に作ったら？

324 ：デフォルトの名無しさん：2013/10/11(金) 21:46:14.97

JSerの奴らはIEの介護で憔悴しきってるんだからちょっとは夢を見させてやれ

325 ：デフォルトの名無しさん：2013/10/11(金) 22:03:27.98

JS使いの屁理屈っぽさはウェブ系って感じがするよね。
メガネかけてるんだろなあ。
自分で自分のことオサレって思ってる感じがオシャレじゃないねって感じ。
わかる？

326 ：デフォルトの名無しさん：2013/10/11(金) 22:11:15.60

オシャレだからJSやってますとかJSやってるからオシャレだなんて思ってる人はそうそういないと思うよ。
そんなに新しい言語でもないし古臭さも残ってることは残ってるし、
今や定番になってきたけどちょっと前の頃のC#とかobjective-Cがまさにそんな感じじゃない？
JSは「楽しい」んだと思う、もちろん周りの環境、HTML5ムードも合わせて、凄く素敵でやりがいがある。

327 ：デフォルトの名無しさん：2013/10/11(金) 22:13:44.71

うん屁理屈っぽい。
メガネ。

328 ：デフォルトの名無しさん：2013/10/11(金) 22:15:58.48

実際に楽しんでることをメガネって言われても困るな
別に生きとし生けるもの全てがJSが好きになれるとは言わないよ

329 ：デフォルトの名無しさん：2013/10/11(金) 22:19:45.94

でもさ、メガネじゃない眼鏡だって言われてもJS使いなら納得じゃない？
そんな感じしない？

330 ：デフォルトの名無しさん：2013/10/11(金) 22:21:13.22

別にJSerは他の言語を否定したり俺が一番だなんて言ってないんだよなぁ

331 ：デフォルトの名無しさん：2013/10/11(金) 22:22:21.34

JSerは純粋だよ
ここでもJSをフォローして熱を伝えようとしてるだけ

332 ：デフォルトの名無しさん：2013/10/11(金) 22:25:29.64

JSerの発言は20年C言語やってる俺からしたら全て子供の戯言レベル

333 ：デフォルトの名無しさん：2013/10/11(金) 22:25:47.00

関数型の便利さがわからない。
どこがどう便利なのかさっぱり。
もしかして不便になってない？

334 ：デフォルトの名無しさん：2013/10/11(金) 22:30:39.78

制約を儲けることは都合が良くもあり悪くもある
何を取るかという話
何も考えずに見たら当然使いにくいものでしか無い
しっかり考えて関数型がいいな、今回はこれを使おうってなった時に
初めて進化を発揮する

335 ：デフォルトの名無しさん：2013/10/11(金) 22:35:43.24

そうだな
このスレが話が進まないのは言語を限定してないからだ

静的型付け言語っていうのが既存のものなのか
将来生まれる言語を指してるのかもわからない

336 ：デフォルトの名無しさん：2013/10/11(金) 22:48:27.74

>>300
みんなで小銭出し合って賞金用意しない？
それよくない？

337 ：デフォルトの名無しさん：2013/10/11(金) 22:54:11.92

BitCoinならいいよ

338 ：デフォルトの名無しさん：2013/10/12(土) 00:02:26.25

型宣言でも型注釈でもガードでも何でも良いけれども、オプショナルな型付けが追加された
ばあい型付きと形無しどちらのスタイルで書くのがメインになるんだろうね。

JavaScriptに似た言語の事例だとActionScriptが2から3でオプショナルな片付けに以降した
例があるけれども、この場合最終的には型付きできっちり書く人が多かった気がする。
どっちかというとFlex使ったRIA向け関連を見てきたというのもあるけど。

339 ：デフォルトの名無しさん：2013/10/12(土) 00:15:00.40

それはエンジンによる
エンジンの最適化に役立つならそういう場面で書くよ

型の安全性の為にはどうしようかなあ
今まで数値型と文字列型でハマるのは大きなプロジェクトで１回はあって最大限に厄介な部類だけど
普段から付ける手間よりはバグ対処のほうがいいかも

340 ：デフォルトの名無しさん：2013/10/12(土) 00:27:09.07

型注釈入ろうが変わらないだろうな
元からプリミティブよりObjectのチェックコードのが多いだろうし

341 ：デフォルトの名無しさん：2013/10/12(土) 00:29:33.71

asm.jsの威力見るとどうだろうか。

342 ：デフォルトの名無しさん：2013/10/12(土) 01:43:10.38

これから先、当分はtypescriptが主流になると思う
jsの代替っていくつかあるけど、一番筋がいいと思う

343 ：デフォルトの名無しさん：2013/10/12(土) 01:47:49.08

AS2->AS3の事例で言えば単純にFlexその他のAS3向けのライブラリがかっちり型付きで提供されて
いたのと、メソッドのシグネチャを中心に型が決まっている場所では型注釈付けた方がその後も
FlexBuilder上で補完がビシバシ効いて自分が楽が出来るので型注釈付けた方が結果的に楽だった
という事情がある。型書くこと自体は補完も効いて全然手間じゃない。

型無しでやりたい場面は型無しでやれば良いし。

344 ：デフォルトの名無しさん：2013/10/12(土) 01:51:21.06

action scriptは、デザイナーが書くか、プログラマーが書くかで違ってたろう
プログラマーなら当然型を指定した方が書きやすい

345 ：デフォルトの名無しさん：2013/10/12(土) 02:00:07.30

AS3はコンパイル言語だけどJavaScriptは違う
そこはやっぱり大きいよ

346 ：デフォルトの名無しさん：2013/10/12(土) 02:02:12.17

何が大きいのかは答えられんけどね。

とにかく大っきんだ

347 ：デフォルトの名無しさん：2013/10/12(土) 02:08:21.72

コンパイル言語は一々実行させて上手く動いてるか確認するような非効率なことはしない
なるべく多く実行時以前に問題になりそうな箇所を潰そうとするけど
JSは取り敢えず動かしてみて必要なら実行させながら値を確認するデバッグでやってきたし
自分もその一人だけどそれで十分だと思ってる人も多いんじゃないかな
手間暇の問題での話ね

348 ：デフォルトの名無しさん：2013/10/12(土) 02:13:06.53

つまりJSerの性質が大きいってことだな
うーむ、、、
でもなあ、初心者本やサイトに載るかなあ
オプションである限り大抵は応用、発展として先送りされると思うんだよね
やっぱり難しく見えるのもあるし
そうすると積極的に使うようにはならないんじゃないかな

349 ：デフォルトの名無しさん：2013/10/12(土) 02:15:37.03

>>344
補完が効きやすいのはわかるけど、他に書きやすさってあるの？

350 ：デフォルトの名無しさん：2013/10/12(土) 02:16:28.70

補完よりも、影響範囲の把握の方が重要だけどな。

351 ：デフォルトの名無しさん：2013/10/12(土) 02:22:15.31

影響範囲か……イメージ不可能

352 ：デフォルトの名無しさん：2013/10/12(土) 02:39:55.49

影響範囲って何？
実装者は使用者が実装の内部は全く気にせずにいいような実装をして
それを使用者が使って実装をするの繰り返しで物ができるものじゃ？

353 ：デフォルトの名無しさん：2013/10/12(土) 02:41:58.77

>>352
コードを修正した時、
その修正の影響が及ぼす範囲を
知ることが出来るかどうか。

354 ：デフォルトの名無しさん：2013/10/12(土) 02:47:11.94

クラスを変更するとき
そのインスタンスがどこで使われてるか分かるってこと？

355 ：デフォルトの名無しさん：2013/10/12(土) 02:49:41.61

それもわかるし、
メソッドを変えてもわかる。

たまたま同じ名前なのか？
などと調べる必要もない。

これらはコードが大きくなればなるほど
開発時間に直結してくる。

356 ：デフォルトの名無しさん：2013/10/12(土) 02:53:16.00

そういうことを徹底していくとダックタイピングとかいう芸当とは合わないよね？

357 ：デフォルトの名無しさん：2013/10/12(土) 02:54:59.47

多くの場合、ダックタイピングは
ダックタイピングする必要があるからしているのではなく、
ダックタイピングになってしまうというだけ
実際にはダックタイピングの必要性はかなり低い。

358 ：デフォルトの名無しさん：2013/10/12(土) 02:57:59.53

でもJSの標準メソッドとかの多くはクラスを確認しないから
ダックタイピングによく利用されてそれが問題解決を優しくしてることもあるよ
例えばDOMなんかの配列もどきに配列のメソッドを適用したい時とか

359 ：デフォルトの名無しさん：2013/10/12(土) 03:27:29.10

JSにそもそもクラスの概念は無い
オブジェクトが何を継承するか決めるのはプロトタイプオブジェクト

360 ：デフォルトの名無しさん：2013/10/12(土) 04:43:01.40

確かに……
根本的にモデルが違う、というかクラスなんて無いし要らないのか

361 ：デフォルトの名無しさん：2013/10/12(土) 04:59:38.42

動いている途中でtypoとか想定いない値が入ってエラーになって止まる場合、
ファイルやデータが削除したり、書き換わったりで元の状態に戻せないから
仕方なくダックタイピングってのも珍しくないからな。コンパイラだとそういう
凡ミスを早い段階で潰してくれるからねぇ。凡ミスなんてしょっちゅうするでしょ？

362 ：デフォルトの名無しさん：2013/10/12(土) 05:10:30.85

話のつながりが分からんｗ
しっかり書いてくれｗ

363 ：デフォルトの名無しさん：2013/10/12(土) 06:37:41.05

そういうこと言ってると、例の勘違いJSマンセーくんが
JSでもクラスプログラミングできるもん
とかいいだすぞ…

364 ：デフォルトの名無しさん：2013/10/12(土) 06:38:53.98

>>361はダックタイピングがまるでわかってないな

365 ：デフォルトの名無しさん：2013/10/12(土) 07:53:04.62

そもそも動的言語は実行時のコンテキストとコーディングの手軽さ重視だから
真面目に制御しようとしたら煩わしくなるのは当たり前だわな

366 ：デフォルトの名無しさん：2013/10/12(土) 08:03:03.47

コンパイラ言語ではダックタイピングできないとか思い込んでるアホがいる？

367 ：デフォルトの名無しさん：2013/10/12(土) 08:28:57.08

☓ ダックタイピングできるから便利
○ いいかげんArray.prototype.slice.callの代わりぐらい用意しろボケ

368 ：デフォルトの名無しさん：2013/10/12(土) 10:15:10.41

>>366
文句なく出来るのはOCamlくらい？
Scalaは実行速度にデメリットあるらしいし、C++は記述がメンドイ

369 ：デフォルトの名無しさん：2013/10/12(土) 10:17:18.10

OCamlのは構造部分型。ダックタイピングとは全く別物。

370 ：デフォルトの名無しさん：2013/10/12(土) 10:33:11.08

構造的部分型と別物と言えるほど、厳密な定義がダックタイピングにあるの？

371 ：デフォルトの名無しさん：2013/10/12(土) 10:39:49.66

構造部分型は静的型付けなのだから
ダックタイピングとは完全に別物

372 ：デフォルトの名無しさん：2013/10/12(土) 10:44:25.85

JavaScriptのダックタイピングなどと一緒にされてはOCamlが不憫だ。

373 ：デフォルトの名無しさん：2013/10/12(土) 11:26:01.43

>>366はぱっと見smalltalkの話だと思うが、
なんでOCamlだと思ったんだろうな
あの強力な型を持つOCamlで特定オブジェクトのメソッド入れ替えとかできるのか？

374 ：デフォルトの名無しさん：2013/10/12(土) 11:31:52.41

>>373
＞あの強力な型を持つOCamlで特定オブジェクトのメソッド入れ替えとかできるのか？

特定オブジェクトのメソッド入れ替えがダックタイピングに必要なの？

375 ：デフォルトの名無しさん：2013/10/12(土) 11:37:29.95

>>371
ダックタイピングは動的型付けじゃなきゃダメなの？何で？

376 ：デフォルトの名無しさん：2013/10/12(土) 11:42:16.16

構造的部分型はダックタイピングで出来る事は
全て出来るが、その上で静的型チェックも
やってくれる優れものなので、
定義上区別される

377 ：デフォルトの名無しさん：2013/10/12(土) 12:14:08.04

>>374
ダックタイピングはクラス(型)じゃなくてインスタンスにかかるからダメだろう
逆に言えばインスタンス別への動的変更ができない処理系じゃ
型の構造見てるのとかわらないから構造的部分型と同じだろうね

378 ：デフォルトの名無しさん：2013/10/12(土) 12:19:54.42

静的型付けでもダックタイピングは可能。
だけど、ダックタイピングを使った場所は
静的型付けのメリットが少なくなる。

で、そもそもの話をすると
ダックタイピングが本当に必要な場所ってのは少ない。
だから、本当に必要な場所のみに使うというのが正しい使い方。

ほんの少しの場所のために、全体をダックタイピングにするなんて愚かでしかない。

379 ：デフォルトの名無しさん：2013/10/12(土) 12:26:49.87

いやいや静的型付だけで純粋なダックタイピングは無理だろうよ
言語が静的型だろうと型の決まらないオブジェクトの扱いは動的型だから

380 ：デフォルトの名無しさん：2013/10/12(土) 12:31:05.84

純粋なダックタイピングってなんだ？

381 ：デフォルトの名無しさん：2013/10/12(土) 14:53:45.89

>>378
俺もそう思うわ
ダックタイピングなんてしないに越したことはない
仕方なくそうする

382 ：デフォルトの名無しさん：2013/10/12(土) 15:16:50.89

低能がわめいておるわ

383 ：デフォルトの名無しさん：2013/10/12(土) 15:20:16.65

ダッタイなんてDBとかXMLの構造をフレキシブルにしたままで扱えるっていう
ただいってんだけだろ

384 ：デフォルトの名無しさん：2013/10/12(土) 16:13:25.68

クラスベースと合わないっていうのもあるんじゃない？
>>367
あるよ
あるけど配列っぽいのを配列に治すって時点でどうもね

385 ：デフォルトの名無しさん：2013/10/12(土) 16:29:38.19

ほぼ全ての仕組みがオブジェクトで成り立ってるし
クラスもないし暗黙の型変換が多用されるJavaScriptで
あえてダックタイピングを禁止して無理やりクラスベースっぽく
こだわるのがいつも得策とはとても思えん

386 ：デフォルトの名無しさん：2013/10/12(土) 16:34:45.40

>>385
なるほどケースバイケースであると、しかし、B型のお前としては
ケースバイケースというどっちつかずの玉虫色の答えを出すのも
気に入らぬ、そういうことだな？

387 ：デフォルトの名無しさん：2013/10/12(土) 16:42:41.36

いや違う
はっきり言いたいことを言わせてもらえば
JavaScriptは自由な言語だと思ってる
これまでもいろんな時代があったけど
色んな人が自由に使ってきた

そして今、まあ当たり前の存在へと昇華するには
デザインパターンやらそういうお決まりを決めなきゃいけないものなんだろうが
それでもバッドパーツとか言ってJavaっぽく書かせたり
もしくはJavaっぽさを捨てようとか、いやいや関数型をtwっていすべきとか

自分はとにかく好きに書いていいよっていう言語であって欲しい
だから、原則これはこうみたいなのはやめて欲しい
言語機能を好きなだけフルに使って書かせて欲しい

大規模開発現場でルールを決めるのはいいけど
きほんは個人用のスクリプト言語としてフリーであり続けて欲しい
あとはやっぱりせっかくのプロトタイプベースとか忘れずに活かして欲しい

388 ：デフォルトの名無しさん：2013/10/12(土) 16:43:51.06

>>387
ああ、うん。
他の言語でも同じだから。

違う！っていうのなら、それはお前の思い込み。

389 ：デフォルトの名無しさん：2013/10/12(土) 16:48:37.23

>>388何が言いたいのかよく分からん

390 ：デフォルトの名無しさん：2013/10/12(土) 16:51:52.04

>>388の目にはJavaScriptの
「自由さ」
「本来のオブジェクトモデルのシンプルさ」
がJavaの
「ブルーカラー統制向き」
「根本的な面倒臭さ」
と区別つかないのだろう。

391 ：デフォルトの名無しさん：2013/10/12(土) 16:56:22.21

>>384
slice以外の方法あるの？
ES6とかMozillaのArray.fromとか言ったらぶっ飛ばすぞ

392 ：デフォルトの名無しさん：2013/10/12(土) 17:02:05.59

当然Array.fromだろ
なんでES7のguardの話は織り込み済みでES6のArray.fromはダメなんだよｗ

393 ：デフォルトの名無しさん：2013/10/12(土) 17:03:15.84

いま>>391はぶっ飛ばすために全力疾走してます

394 ：デフォルトの名無しさん：2013/10/12(土) 17:05:59.64

>>392
今JSって言えばHTML5かnodeだろ
なんで普及もしてない限定環境の話してんだよ

395 ：デフォルトの名無しさん：2013/10/12(土) 17:07:29.30

>>390
JavaScriptの自由さｗｗｗ

笑うところですか？

ほんとうの自由とは
マイナーな言語を使って
飯を食ってる人のことですよ？

396 ：デフォルトの名無しさん：2013/10/12(土) 17:13:32.02

>>394
今>>338からの流れの話なのがわからない？
JSにそういうのが追加されたときの話をしてるんだから
当然Array.fromは使えるに決まってるじゃん
アホなの？

397 ：デフォルトの名無しさん：2013/10/12(土) 17:13:50.58

とりあえずポエムは抜きで頼む。
キラキラした目で「JavaScriptは自由な言語っ・・・!」とか語られても他の人はひくだけだから。

398 ：デフォルトの名無しさん：2013/10/12(土) 17:17:23.50

言語の雰囲気は重要だと思うが

399 ：デフォルトの名無しさん：2013/10/12(土) 17:27:59.52

>>398
お前さんも>>338からの流れを読みなさい。

「ダックタイピングなんてしないに越したことはない」なんて話をしているところに
具体的な話もないそんなポエムを持ち出してもハァ? だ。

400 ：デフォルトの名無しさん：2013/10/12(土) 17:32:45.73

>>399
このコーディングスタイルが適切かじゃなくて
実際にそうするようになるだろうかの話なんだから
JSerの性質>>348は大事なポイントじゃないか？

401 ：デフォルトの名無しさん：2013/10/12(土) 17:41:13.55

馬鹿な屁理屈はもう聞き飽きた…

402 ：デフォルトの名無しさん：2013/10/12(土) 17:46:17.09

文化の分裂が起こるかもね。

型付きできっちり書く貴族とあくまで型無しにこだわるボヘミアン。

そしてそんな空中戦はよそに「ECMAScript7なんて絶対ﾑﾘwww Part22」なんてスレも
更新を重ね、大多数のユーザーにとっては単に言語機能やライブラリで用意された
便利なイディオムを反復するだけなので今とたいして変わらん。

403 ：デフォルトの名無しさん：2013/10/12(土) 17:51:45.29

どういう人が型付で書くようになると思う？
静的から来た人はそうしたがるかもしれないけど
自分自身は全てには付けないと思う
型宣言じゃなくてguardだってとこも多少あるけど

１つ検討がつきにくいのは入門者だなあ
言語仕様が肥大化した時どのように教えられて育つようになるんだろう

404 ：デフォルトの名無しさん：2013/10/12(土) 18:01:54.61

今まで見てきたものでいうと
「初めての○○」なのに浅く広く言語仕様を網羅したようなものばかりが出るようになる
そして新規入門者が遠のいて言語が少子高齢化状態になる
そしたらさらに入門者の気持ちがわかるピュアな人が減ってやがては廃れる

405 ：デフォルトの名無しさん：2013/10/12(土) 18:05:44.84

でかいもの。企業が提供するライブラリ。フレームワークの類。
この辺りからずんずん型付きが増える。

メタプログラミング的なことをするものを除いて再利用を目的に開発される物は
型付きが優位になる。
型情報なんて仕様書の一部なので結局どこかに書かないといけないし。

406 ：デフォルトの名無しさん：2013/10/12(土) 18:06:13.15

その廃れていった具体例が○○言語だ

↓あとよろしく

407 ：デフォルトの名無しさん：2013/10/12(土) 18:09:51.33

guardを型付きって呼んでいいのか…
なんか違和感がある

408 ：デフォルトの名無しさん：2013/10/12(土) 18:10:44.98

C言語ですね、分かります

409 ：デフォルトの名無しさん：2013/10/12(土) 18:14:15.86

じゃあガード付きで良いよ。

410 ：デフォルトの名無しさん：2013/10/12(土) 18:18:43.94

彼女が私のボディーガードだ。

411 ：デフォルトの名無しさん：2013/10/12(土) 18:24:48.90

そもそもguardで>>355静的に解析できるもんなのかね？
myGuard = Type.make(guard1, guard2, ...)
var a :: myGuard
みたいなこともできる型宣言と比べ物にならないほど動的なものだし

412 ：デフォルトの名無しさん：2013/10/12(土) 19:01:32.84

クラスの件もそうだけどJSに無理やり当てはめようとしても
上手くいかないことなんて分かりきってるから
諦めてJSはJSとして気持ちを切り替えて使っていくしか無いだろうな

413 ：デフォルトの名無しさん：2013/10/12(土) 19:04:37.63

南米系は全員マリオだよね？

414 ：デフォルトの名無しさん：2013/10/12(土) 19:06:54.37

YES WE ARE.

415 ：デフォルトの名無しさん：2013/10/12(土) 19:13:49.89

実際のところガードってどの程度実現可能性があるの。
MSとかAppleとかGoogleはどの程度コミットメントしていてコンセンサスがとれてるの。

416 ：デフォルトの名無しさん：2013/10/12(土) 19:18:13.08

このスレはhoge禁止ですか？

417 ：デフォルトの名無しさん：2013/10/12(土) 19:22:38.63

現状積極的に議論されてないので何とも言えないが、
他の仕様と矛盾しないし後方互換性も取れるし
やっぱり何らかの型の仕組みを入れたいだろうから
わざわざ否定する人は少ないと思われる
もっといいのが出るか問題がなければ順当に入るんじゃないかな

まあValueObjectよりは下、Parallelsとどっこいくらいのイメージ

418 ：デフォルトの名無しさん：2013/10/12(土) 19:32:05.72

全く新しい試みだから多分長い時間がかかると思うよ
class構文って10年も話し合われてきてprivateの辺りとかようやく最近まとまってきたでしょ

419 ：デフォルトの名無しさん：2013/10/12(土) 19:44:29.39

ガードって何？

420 ：デフォルトの名無しさん：2013/10/12(土) 19:53:53.01

パターンマッチをショボくしたやつ

421 ：デフォルトの名無しさん：2013/10/12(土) 19:57:47.75

それが何で騒がれてるの？
switch文とどう違うの？

422 ：デフォルトの名無しさん：2013/10/12(土) 20:00:45.16

騒がれてない

423 ：デフォルトの名無しさん：2013/10/12(土) 20:03:30.92

ガードで飛躍する人類の未来とか語ってなかったっけ？

424 ：デフォルトの名無しさん：2013/10/12(土) 20:08:27.52

チョットおかしい人の声が大きいのは
よくある事

425 ：デフォルトの名無しさん：2013/10/12(土) 20:22:56.53

普及は少なくとも2010年代後半ひょっとすると2020年代初頭と言ったところか > ガード。
未来技術だなぁ。

426 ：デフォルトの名無しさん：2013/10/12(土) 20:32:06.07

2週くらい周回遅れしてるJSに相応しい機能

427 ：デフォルトの名無しさん：2013/10/12(土) 20:34:52.28

なんでそんな酷いこと言われないといけないのか分からん

428 ：デフォルトの名無しさん：2013/10/12(土) 20:39:30.06

とりあえずF# to javascriptのツールが使い物になりそうなのでなどうでも良い

429 ：デフォルトの名無しさん：2013/10/12(土) 21:00:42.82

意欲的な言語機能云々よりまずテンプレート文字列をちゃんと各社横並びで使えるようにして欲しい。
ちょい書きスクリプト言語として使うのにこれが使えないのは普通に不便。

430 ：デフォルトの名無しさん：2013/10/12(土) 21:19:21.15

javascriptって人間にも解読可能な中間言語でしょ。
C++やJavaなどから変換出力してライブラリはブラウザ互換の物を使う。

431 ：デフォルトの名無しさん：2013/10/12(土) 21:20:10.93

>>428
FunScriptのことならたぶん使ってるうちにガッカリする
簡単にFFI書けるFay-langのがまだマシ
jsのゆるゆる仕様に静的関数型が合わせるのは無理だと悟った

432 ：デフォルトの名無しさん：2013/10/12(土) 21:33:04.35

>>429
後1年ES6まで待ってね

433 ：デフォルトの名無しさん：2013/10/12(土) 22:01:12.67

再来年以降の間違いでしょ。
ES6なんて待っていない。必要な機能を実装したブラウザが広く行き渡るのを待っている。

434 ：デフォルトの名無しさん：2013/10/12(土) 22:37:01.63

いつまでも夢見てろよ
そのまま起きるなｗ

435 ：デフォルトの名無しさん：2013/10/12(土) 22:45:39.35

pcはともかく、Androidやiosは古いバージョンが相当先まで生き残るだろうな

436 ：デフォルトの名無しさん：2013/10/12(土) 22:50:58.92

Android4以降なら大抵Chromeも一緒に載ってる

437 ：デフォルトの名無しさん：2013/10/12(土) 22:56:56.53

スマホはバージョンアップもあるし端末の寿命長くないと思う
当面の問題はVistaのIE9だと思う
IE12だか13だかES6をサポートしてくれるIEがwin7をサポートしてくれるとすれば
Vistaが息絶えた時がES6の始まり

438 ：デフォルトの名無しさん：2013/10/12(土) 23:10:30.18

ES5が気兼ねなく使えるのはXPが死ぬそろそろだろう？
だったらES6が使えるのは時期的にES7の勧告があるくらいだろうな

439 ：デフォルトの名無しさん：2013/10/12(土) 23:17:47.66

>>438
サーバー側ならもっと速く使えるよ。
ブラウザが問題であって
ブラウザを使わない環境であれば、
他の言語と同じだからね。

440 ：デフォルトの名無しさん：2013/10/12(土) 23:38:24.46

んなことは分かってるが認めないとイチャモンつける奴がいるから仕方ないだろ

441 ：デフォルトの名無しさん：2013/10/13(日) 00:09:34.25

老人の面倒を見ないといけないのも若者の務め

442 ：デフォルトの名無しさん：2013/10/13(日) 00:11:07.53

なぜJavascriptが嫌われているのかやっとわかった。
もし俺がLinuxについて今まで触れていたならLinuxが嫌われていただろう。
触れなくてよかった。

今初めてスレタイを見て分かった。

443 ：デフォルトの名無しさん：2013/10/13(日) 00:15:40.48

Linuxｗｗｗとか意味わからんがｗｗｗ
このスレで特定言語、特にLL推せば荒れるに決まってんぞｗ

444 ：デフォルトの名無しさん：2013/10/13(日) 00:30:46.59

>>431
いやWebSharperの方。FunScriptも試したが既存のソース読み込ませたらイミフなコンパイルエラー出てダメだった。
WebSharperはエラー出ても理由とかがわかりやすいし既存のソースもほぼ改変なくいけた。

445 ：デフォルトの名無しさん：2013/10/13(日) 00:38:48.76

北京オリンピックやったばかりなのに次は東京オリンピックやるんだってね。
最近勢いあるね中国。

446 ：デフォルトの名無しさん：2013/10/13(日) 00:39:59.20

>>445
トンキンｗｗｗ

447 ：デフォルトの名無しさん：2013/10/13(日) 03:33:36.21

>>439
>サーバー側ならもっと速く使えるよ。
もうES6使えてるの？

448 ：デフォルトの名無しさん：2013/10/13(日) 04:02:13.69

いくらかね
ほんとに日進月歩で今日はメソッドが１つ増えたー
とかの積み重ねだからねES6は
一気に変わるのはIEくらいのものでしょう

449 ：デフォルトの名無しさん：2013/10/13(日) 04:21:41.37

これはかなりすごい。
目からうろこ。

http://www.youtube.com/watch?v=6p95-kRxF_E

450 ：デフォルトの名無しさん：2013/10/13(日) 04:24:11.02

>>449を見なくてもいいように説明

ジュースの自動販売機で当たりを出す方法【裏技？】

結局外れで、ブラックのコーヒーがでてきて
そんなに甘くないと言いたかっただけ。

451 ：デフォルトの名無しさん：2013/10/13(日) 04:51:25.31

キチガイ増えたな・・

452 ：デフォルトの名無しさん：2013/10/13(日) 08:39:07.10

Ubuntuの新しいバージョンが発表になった

453 ：デフォルトの名無しさん：2013/10/13(日) 10:53:34.88

pcの場合、ブラウザを変えるのも比較的容易だがスマートフォンの場合はそうは行かない
iphone4以前は当分使われ続けるだろう

454 ：デフォルトの名無しさん：2013/10/13(日) 14:27:24.02

逆だと思う
スマホは５年も１０年も使われないが
IEは使われる

455 ：デフォルトの名無しさん：2013/10/13(日) 16:26:03.35

それはないな。
WindowsはLinuxに駆逐されるから。

456 ：デフォルトの名無しさん：2013/10/13(日) 16:46:15.52

そうかもしれないがそれはVista終了には間に合わないな
一応最低ラインではあと５年くらいIE9を見なければならないのは確かだろう
まあ実際はHTML5との兼ね合いでそこまで長くはないだろうが

３年後とするとAndroidではChromeが載ってると思って良くなる
iPhoneもOS更新率が高いからAndroidと比べてそこまで状況は酷くはないだろう

457 ：デフォルトの名無しさん：2013/10/13(日) 17:17:47.55

ところで既定の検索プロバイダをとうとうBingに変更した。
さようならGoogle。
あなたの作ろうとする未来には乗れません。

458 ：デフォルトの名無しさん：2013/10/13(日) 17:28:26.19

MSが作ろうとしている未来には乗るわけかw

459 ：デフォルトの名無しさん：2013/10/13(日) 17:49:04.83

http://www.youtube.com/watch?v=XiqgmAYrd3c

460 ：デフォルトの名無しさん：2013/10/13(日) 18:13:34.77

メリンダさんとゲイツ氏が人々のためにYoutubeを買い取ってくれればなあ。

461 ：デフォルトの名無しさん：2013/10/13(日) 19:48:31.72

>>460
MSも動画サイト作っただろ

462 ：デフォルトの名無しさん：2013/10/13(日) 20:26:50.64

マイクロソフトは人々のために良いものを無償提供すると言えないでしょ。

Googleは対価を求めず人々によいものを提供する。
本来高価なサービスを無償で提供する。
この取り組みにあなたも貢献できる。
貢献すれば人々からあなた自身の価値を認められる。
何かいいことあるかもよ？
使うだけでも貢献しています。

こういう幻想を抱かせることができないと、CGMはうまくいかない。
つまり、基本的に嘘がつけない人には無理。

463 ：デフォルトの名無しさん：2013/10/13(日) 20:31:46.83

あなたの貢献は確かに小さなものかもしれない。
サービスを消費しているにすぎないのだから。
しかし、その小さな貢献がいくつも集まることで、世界をより豊かにするのです。

こういった、あなたがサービスを利用することで社会正義のために役立つ的な
正しいことをしていると納得できる説明も必要なんじゃないかな。
宣伝マンってある種の宗教性があるでしょ。
それで信者と呼ばれたりする。

464 ：デフォルトの名無しさん：2013/10/13(日) 20:37:02.99

マイクロソフトは営利企業にすぎないので、Googleのような社会正義実現を
目指す団体にCGMで勝つことはできない。

これは漠然とした理論のようだけど、たいていのことは計算通りにしか
ならないので、必ずそうなると思う。

良いことをしてると納得させることができないといけない。
サービスが成功して、化けの皮がはがれてきたとしても、悪いことに加担していない
と思わせないと。
その時には、利用者も被害者の一員だと思わせることで、CGMを継続できる。

465 ：デフォルトの名無しさん：2013/10/13(日) 22:15:06.42

Googleってニコニコにすら勝ててないじゃん

466 ：デフォルトの名無しさん：2013/10/13(日) 23:28:07.65

>>462-464
これ同じ人？
Googleが慈善団体なのとでも思ってるん？

467 ：デフォルトの名無しさん：2013/10/13(日) 23:51:04.73

>>466
「教祖になる本」でも読んだんだろ。

468 ：デフォルトの名無しさん：2013/10/13(日) 23:51:58.73

国家を真面目に作ろうとしてるくらいだから単なる営利企業ではないな
自愛団体かもしれんｗ

469 ：デフォルトの名無しさん：2013/10/14(月) 15:16:32.98

JSに変換できる言語処理系で、一番出来の良いヤツを教えてください
なお、TypeScriptは試してみたのですがJS臭が強過ぎてダメでした

470 ：デフォルトの名無しさん：2013/10/14(月) 15:26:37.99

CoffeeScriptやHaxe

471 ：デフォルトの名無しさん：2013/10/14(月) 15:42:53.04

>>469
仕様変更に耐えられるならLiveScriptお勧め

472 ：デフォルトの名無しさん：2013/10/14(月) 16:32:59.50

TSが嫌なら素直にes6ifyでも使っとけ

473 ：デフォルトの名無しさん：2013/10/14(月) 18:14:52.59

えー？なんでそんなウンコ使わなきゃならんの？

474 ：デフォルトの名無しさん：2013/10/14(月) 18:45:23.96

PCはXP世代のマシンでもChromeやFirefoxを使えるけど、スマートフォンは取り残されるからな
GoogleがWebkitから分裂してスマートフォンのブラウザの断片化が進む

475 ：デフォルトの名無しさん：2013/10/14(月) 20:10:35.23

皆がChrome使ってくれるんなら苦労はしないんだけど

476 ：デフォルトの名無しさん：2013/10/14(月) 22:24:50.49

Perl, Ruby, PythonあたりがJSにコンパイル出来れば
JSにまつわる不毛な論争の7割が減る気がする

477 ：デフォルトの名無しさん：2013/10/14(月) 22:38:01.29

>>469
WebSharperお勧め。

478 ：デフォルトの名無しさん：2013/10/14(月) 23:50:05.95

>>477
別人だが、これいいな。

479 ：デフォルトの名無しさん：2013/10/15(火) 07:17:52.99

es6ify以外はまあ良いな。
この文脈で何故なおもJS推すのかよく解らん。

480 ：デフォルトの名無しさん：2013/10/15(火) 08:17:23.21

標準であるということはそれだけで価値高いからな

481 ：デフォルトの名無しさん：2013/10/15(火) 08:29:52.35

標準にこだわって生産性の低い環境を使い続ける連中がいるおかげで
生産性の高い環境を選ぶだけで競争優位に立てる

482 ：デフォルトの名無しさん：2013/10/15(火) 08:35:54.17

お、おう

483 ：デフォルトの名無しさん：2013/10/15(火) 16:59:17.46

汎用性にこだわらない奴はプログラマ向いてないな

484 ：デフォルトの名無しさん：2013/10/15(火) 17:03:07.89

”こだわる”の言葉の意味を知らないとそうなる。

485 ：デフォルトの名無しさん：2013/10/15(火) 17:20:34.57

まあ殆どの奴が「食わず嫌い」なのは間違いなさそうだな

486 ：デフォルトの名無しさん：2013/10/15(火) 17:28:32.29

いろいろ触った上でJavaScriptは糞。
標準が高機能である事は重要。

487 ：デフォルトの名無しさん：2013/10/15(火) 18:15:06.20

言語自体に大した違いなんて無い。

488 ：デフォルトの名無しさん：2013/10/15(火) 18:43:09.62

WebAPIが徹底的に機能を提供する作りになってるから、
言語にいくら大層な機能があっても役に立たない

489 ：デフォルトの名無しさん：2013/10/15(火) 19:36:09.80

意味不明
WebAPI主体ならなおさら標準でURIコンポーネントぐらい用意しとけよ

490 ：デフォルトの名無しさん：2013/10/15(火) 19:37:09.01

>>487
＞言語自体に大した違いなんて無い。

こういう事書く奴に限って、クソ言語しか使った事無いんだよな
お前は判断出来るだけの経験が無いだろっつの

491 ：デフォルトの名無しさん：2013/10/15(火) 19:40:31.93

違いがない？
なら全部Cで書けよ。

492 ：デフォルトの名無しさん：2013/10/15(火) 20:11:06.20

ここって動的言語スレ？

493 ：デフォルトの名無しさん：2013/10/15(火) 20:33:22.07

LLerが過疎スレと頭の硬い言語使いたちに話題を与えてやっているところです

494 ：デフォルトの名無しさん：2013/10/15(火) 20:35:53.70

>>489
笑ったw そりゃそーだ

495 ：デフォルトの名無しさん：2013/10/15(火) 20:38:11.16

>>489
あるだろ節穴

>>490,491
Webで使う上でどうそんなに違うのか説明よろ
こちとら悪魔の証明は出来ないんでね
反証待ってまーすｗｗ

496 ：デフォルトの名無しさん：2013/10/15(火) 20:48:34.77

パッケージングがない言語は総じてクソ

497 ：デフォルトの名無しさん：2013/10/15(火) 20:54:57.45

Lispの後継JavaScriptが素晴らしくないわけない
当初はそう思っていました

498 ：デフォルトの名無しさん：2013/10/15(火) 21:01:12.15

>>495
ほおー。ならjs言語の標準のURLクラスの仕様をぜひ示してくださいな。

499 ：デフォルトの名無しさん：2013/10/15(火) 21:12:01.02

JSにクラスはないしURLコンポーネントが備わってる必要もない
必要がるのなら外部APIとして提供してもらえばいい
それがスクリプト言語って言うもの

500 ：デフォルトの名無しさん：2013/10/15(火) 21:12:35.49

またいつもの糞JSerか

501 ：デフォルトの名無しさん：2013/10/15(火) 21:14:33.80

ES6でclass構文できるんだけど？
そんな詭弁で大丈夫か？

502 ：デフォルトの名無しさん：2013/10/15(火) 21:15:30.76

糞JSerですがなにか？
俺が糞だとしてもJSは神聖なものです

503 ：デフォルトの名無しさん：2013/10/15(火) 21:16:42.46

>>501
前スレだか前々スレだかで嫌というほど説明合っただろう
あれはただの糖衣構文でクラスなんかないのは変わらないと

504 ：デフォルトの名無しさん：2013/10/15(火) 21:16:57.07

488 ：デフォルトの名無しさん：2013/10/15(火) 18:43:09.62
WebAPIが徹底的に機能を提供する作りになってるから、
言語にいくら大層な機能があっても役に立たない

489 ：デフォルトの名無しさん：2013/10/15(火) 19:36:09.80
意味不明
WebAPI主体ならなおさら標準でURIコンポーネントぐらい用意しとけよ

495 ：デフォルトの名無しさん：2013/10/15(火) 20:38:11.16
>>489
あるだろ節穴

早くソース出せよ

505 ：デフォルトの名無しさん：2013/10/15(火) 21:20:25.29

URLWebAPIならあるhttp://url.spec.whatwg.org/#api

506 ：デフォルトの名無しさん：2013/10/15(火) 21:25:04.47

>>504
まず俺の質問に答えろやクズｗｗ

ほらよあったやんけｗｗ
>>505

507 ：デフォルトの名無しさん：2013/10/15(火) 21:35:13.98

まあ例によってまだFirefoxしかそれなりに対応してないんだけどね
URLコンストラクタ自体は他のAPIの為に既に広く使えるけど、ちょっとアレ

508 ：デフォルトの名無しさん：2013/10/15(火) 21:37:31.76

1. WebAPIじゃない
2. 言語標準じゃなくてWeb標準、しかもDOM
3. firefox、chrome、operaで試したけど使える環境一つもない

なめてんの？

509 ：デフォルトの名無しさん：2013/10/15(火) 21:39:11.78

>>212
質問者は質問する気がないのなら帰って、どうぞ。
喧嘩したいのならスレを間違ってますよ。
こっちですよ。
http://toro.2ch.net/test/read.cgi/tech/1379350030/1

510 ：デフォルトの名無しさん：2013/10/15(火) 21:40:28.78

JSerは自分で使った経験から語ってるんじゃなくて、
てきとーにググって返答してる感じだね

511 ：デフォルトの名無しさん：2013/10/15(火) 21:42:30.52

>>508
言語標準？？？
Web標準にあるって話でしょう？
JavaScriptはWebだけのためのものじゃないんだからさ
あとこういうのをWebAPIっていうのよ、URLAPIね
それからFirefoxではそれなりに使えるよ

512 ：デフォルトの名無しさん：2013/10/15(火) 21:44:23.34

>>510
試したことがあるから覚えててURL貼ったんだよ
まあ、今はまだ使えそうにないから将来に期待だなーって感じで
でもこういうAPIを沢山追うのが楽しいんだと思うよ

513 ：デフォルトの名無しさん：2013/10/15(火) 21:44:43.14

>>511
DOM APIだろ虚言癖
Web APIはHTTPのサービスのAPIの事だろうが

514 ：デフォルトの名無しさん：2013/10/15(火) 21:46:42.12

>>512
firefoxのnightlyだとあるのか？
少なくとも安定版はFile APIのURLしか見つからないんだが

515 ：デフォルトの名無しさん：2013/10/15(火) 21:49:41.30

>>513
WebAPIっていうのはDOMAPIを含むHTML5の流れに乗ったAPIのこと全般を指す言葉だよ
https://wiki.mozilla.org/WebAPI

516 ：デフォルトの名無しさん：2013/10/15(火) 21:51:50.03

>>514
nightlyしか入れてないから分からないけど
スタティックメソッドはないよ
URLのインスタンスメソッド（？）がいくつかある

517 ：デフォルトの名無しさん：2013/10/15(火) 21:54:15.19

>>509
JavaScript質問スレを荒らしてる自演厨はここからの派遣か
http://toro.2ch.net/test/read.cgi/hp/1381678387
趣味悪いなおいｗ

518 ：デフォルトの名無しさん：2013/10/15(火) 21:58:04.14

>>515
WebAPIってサーバーサイドだけの単語じゃなくなったんだな
虚言癖なんて言って申し訳ない、単純にこちらが浅学なだけだった

519 ：デフォルトの名無しさん：2013/10/15(火) 21:58:34.95

ありゃ
というかChromeでもURLコンストラクタ機能してるわ
ついこの前試したときは見せかけだと思ってたんだけどどうなんだろう

520 ：デフォルトの名無しさん：2013/10/15(火) 22:00:19.32

>>518
全く気にしてないよ

521 ：デフォルトの名無しさん：2013/10/15(火) 22:08:22.32

// chrome v30
new URL("http://www.google.com") // => URL {}
var url = new URL("http://www.google.com") // => undefined
Object.keys(url); // => []
url.path // => undefined

こうなるよ
flagsにも特に関係の有りそうな設定はない

522 ：デフォルトの名無しさん：2013/10/15(火) 22:29:33.56

>>521見つけた
https://code.google.com/p/chromium/issues/detail?id=303152
５日前から少しずつ実装されてきてるっぽい
Chrome Canary 32.0.1671.3でこうなる

Object.keys(url); // =>
["hash", "search", "pathname", "port", "hostname", "host", "password", "username", "protocol", "origin", "href"]

523 ：デフォルトの名無しさん：2013/10/15(火) 22:31:46.89

chromium-dev v32試してみたら

new URL("http://www.google.com");
// => URL {hash: "", search: "", pathname: "/", port: "", ...

ちょうど境目にあたる時期だったんだな
chromeにもfirefoxにも入ってるならさすがに標準と認めざるを得ないな

524 ：デフォルトの名無しさん：2013/10/15(火) 22:54:06.16

>>522
リンク先読んだ、ありがとう
specからnodeのURLの簡易版だと思ってたけど
なんだか想定してる使い方からして違うみたいだね

525 ：デフォルトの名無しさん：2013/10/15(火) 22:59:44.59

こことか見ると仕様はとても良く似ていると思うけれど
https://developer.mozilla.org/en-US/docs/Web/API/URL.URL

526 ：デフォルトの名無しさん：2013/10/15(火) 23:00:32.85

http://nodejs.jp/nodejs.org_ja/api/url.html

527 ：デフォルトの名無しさん：2013/10/15(火) 23:49:43.19

今更URIクラスを実装しているなんて何周遅れなんだJS。

528 ：デフォルトの名無しさん：2013/10/15(火) 23:58:53.33

今までは必要となる機会がなかったから

529 ：デフォルトの名無しさん：2013/10/16(水) 00:17:01.62

呆れるな……

530 ：デフォルトの名無しさん：2013/10/16(水) 03:34:29.49

今までJavaScriptなぞでずっと満足してた連中が作ってるわけで
いろんな意味でトロくさかったり身の程知らずだったり井の中の蛙だったり要するにバカだったり
誤った判断を繰り返すのは仕方がないと思ってる。

なぜネイティブのようなアプリが作れないのだろう？糞言語と言われるのだろう？と疑問に思い
一つ一つゆっくり気づいていくのを待つしかあるまい。生暖かい目で見守ろう。

ハードルが軽く数十はあってそれぞれに1年くらいかかりそうだけどな。

531 ：デフォルトの名無しさん：2013/10/16(水) 04:13:11.68

何？喧嘩売ってんのお前

532 ：デフォルトの名無しさん：2013/10/16(水) 05:40:19.09

このスレに常駐しているJSerにとってJavaScriptは完全無欠の言語なの?
使っている言語の愚痴の一つも言わないユーザーってなんかキモい。

533 ：デフォルトの名無しさん：2013/10/16(水) 09:01:09.56

不満点は全て将来バージョンの仕様で解決される目処が付いたから
実装が早く進んでくれることを祈るくらいしかない
と、言うか不満を抱く前に色んなAPI覚えることが多いってのもある
今を頑張りながら将来にも期待できる
JSerは充実しています

534 ：デフォルトの名無しさん：2013/10/16(水) 11:26:34.20

今仕様にケチがあるのならここで言わずにメーリングリストに載せるだろJK

535 ：デフォルトの名無しさん：2013/10/16(水) 15:00:45.17

>>533
>不満点は全て将来バージョンの仕様で解決される目処が付いたから

具体的にどんな不満があったの。

536 ：デフォルトの名無しさん：2013/10/16(水) 15:15:08.08

>>535
bignum型
これが長年欲しかった

537 ：デフォルトの名無しさん：2013/10/16(水) 15:21:21.59

普通に未来のES6ES7で予告されている機能のリストは裏返せば現在のJSerの不満の
リストと解釈して問題ない。

538 ：デフォルトの名無しさん：2013/10/16(水) 15:36:47.44

あった方が便利ねっていうのと無いのが不満だわって言うのは分けて考えてる
全て前者には含まれるけど、後者に含まれるのは個人的にかなり少ない

まあ、「新しい規格を作る上」でどうかっていう枠組みで見ると
多くがこれくらい無いと不満だわってなるだろうし、一般論では言えんね

539 ：デフォルトの名無しさん：2013/10/16(水) 16:00:09.03

あった方が便利と言うのは裏返せば無いと多かれ少なかれ不便なわけで、特に他の言語では
あったりごく普通な言語機能が存在しなかったり異常だったりすると他の言語との掛け持ち
組にとっては不満となるでしょ。

特にサーバー側で別の言語を使っていてWebクライアント開発にJavaScriptを使っていると
いう掛け持ち組は多いだろうから他の言語との比較で不満が出てくるのはごく自然。

540 ：デフォルトの名無しさん：2013/10/16(水) 18:15:54.61

サーバ側で使ってる言語にJSへのトランスレータがあれば解決だね

541 ：デフォルトの名無しさん：2013/10/16(水) 18:24:48.87

GWTなんかはそんなフレームワークだけどね。

542 ：デフォルトの名無しさん：2013/10/16(水) 18:28:55.09

Javaはアンチも多いから...

543 ：デフォルトの名無しさん：2013/10/16(水) 19:02:51.32

ウンコ言語からウンコ言語にコンパイルできても
意味ないでしょ

544 ：デフォルトの名無しさん：2013/10/16(水) 22:27:43.64

そうかRubyはウンコ言語だったのか

545 ：デフォルトの名無しさん：2013/10/16(水) 22:37:43.67

おまえらはウンコマニアの変態だってこった

546 ：デフォルトの名無しさん：2013/10/16(水) 23:12:39.72

>>543
ウンコが二つから一つになるのは馬鹿にできないぞ。

547 ：デフォルトの名無しさん：2013/10/16(水) 23:28:52.18

ここは天国板か

548 ：デフォルトの名無しさん：2013/10/17(木) 06:19:13.39

>>539
郷に入っては郷に従え
さっぱりその言語を使えこなせないのに文句をいうのは笑えるｗ
違う言語を使ってて違うのがおかしいとか言い初めた時にはもうね、苦笑

549 ：デフォルトの名無しさん：2013/10/17(木) 06:38:45.82

なるほど。使いこなすとはすなわち無批判になると言うことか。

550 ：デフォルトの名無しさん：2013/10/17(木) 06:51:13.17

>>533でFAだろう
それ以上でも以下でもない
JSerにとって仕様は安泰だが実装が不安
今も昔もこれからも
あとはとにかくAPIを叩いていくことになるから
そのAPIに不満は細々持つが
ここに書いてもJSer以外分かっちゃくれないだろう
そういうスレで解決策話すに決まっている
いずれにしろ言語自体に不満はほぼない

551 ：デフォルトの名無しさん：2013/10/17(木) 06:57:14.07

>>550
> >>533でFAだろう

そうか。

>不満点は全て将来バージョンの仕様で解決される目処が付いたから

つまり現在バージョンには不満点があると言うことだよな。なら現在バージョンを
使っている人が不満を愚痴るのも別にかまわんだろう。

> ここに書いてもJSer以外分かっちゃくれないだろう

恥ずかしからずにその高尚な不満とやらを披露してみればよいのに。

552 ：デフォルトの名無しさん：2013/10/17(木) 07:05:53.22

数値計算関係は完全に腐ってる
新しい標準ライブラリや仕様もできる気配ないし

553 ：デフォルトの名無しさん：2013/10/17(木) 07:14:19.54

>>551
今抱えてる大きな不満は０
しいて挙げるとしたらこれか>>536
今は気にしてないけど、しばしばこれはカバーが大変だからね
あとは正直ぱっと思いつかない
これに関してどう？って聞かれれば沢山細々あるだろうけどね

ES6を見るまでES6の機能が欲しいとは思わなかったのと
既にES6が使える気でいるのが大きい

例えばもしIE8でES3で書かなきゃいけなくなったら
ES3に不満抱かないでしょ？そこは間違いなくIE8に苛立ちが全部行くわけだ
だから今は毎日実装のアップデートをチェックして早くES6実装されないかなと悶々としてる

同じくAPIに付いてだってさ、>>505もそうだけど
「Living Standard」ってのが多いのよ
実装で普及してなんか明らかにこれは失敗だったねってわかった時には
当然その解決策が出てるのよ
だから仕様に文句言うって発想にはなりにくいのよね

>>552
何に困ってるのかよく分からんけど、
NumberやMathの関数はもの凄く増えたよ

554 ：デフォルトの名無しさん：2013/10/17(木) 07:28:18.21

配列のmapやらはちょっと気になるとこはあるな
まずDOM系の配列もどきに使えないのが直感的じゃない
あとは第二引数以降がオプショナルな標準関数にかけると誤爆するってことだな
この２点、どうするのが一番スマートに解決できるかね

555 ：デフォルトの名無しさん：2013/10/17(木) 07:52:15.87

living standardとか格好つけて言ったところで実際に現場でコードを書いている人間は
de factoを相手にしているわけで何も救いにもならんわな。
そのliving standardとやらはどれだけ広くプロダクションで使われているのさ。
机上の空論か単に趣味。

> ES6を見るまでES6の機能が欲しいとは思わなかったのと

ほんと無批判なんだね。

556 ：デフォルトの名無しさん：2013/10/17(木) 08:14:47.65

>>553
増えたよってクッソ少なかった数学関数部分だけやろ
有理数や複素数その他なんて
仕様だけでもrubyやpythonの標準ライブラリ以下

557 ：デフォルトの名無しさん：2013/10/17(木) 08:23:08.67

scipyはもちろん、numpyレベルに到達するのすら
永劫の時間がかかるだろう

558 ：デフォルトの名無しさん：2013/10/17(木) 08:24:24.33

>>555
仕様を批判するかっていう話だろう？
実装を批判することならしょっちゅうだよ
仕様は常に前に進んでる限り批判できるところはない

>>556
ES7まで待ってね

559 ：デフォルトの名無しさん：2013/10/17(木) 08:31:40.51

仕様は自分たちで作っていくものだろうよ

560 ：デフォルトの名無しさん：2013/10/17(木) 08:38:22.10

>>558
> 仕様を批判するかっていう話だろう？

いや全然? いま現場でどれだけ使えますか、関心があるのはそれだけだけど。

> 実装を批判することならしょっちゅうだよ

それなら今現在使える実装で広く無難に使えるJavaScriptの機能には不満だとか
ウンコだと愚痴るのも大目に見て欲しいな。

> ES7まで待ってね

つまり遠い未来に期待しろと。

561 ：デフォルトの名無しさん：2013/10/17(木) 08:42:04.99

>>560
実装批判なら好きなだけどうぞ
実のない話しならJSアンチスレで、実のある解決したいことなら各JSスレでしてね

562 ：デフォルトの名無しさん：2013/10/17(木) 08:50:04.06

このスレでJSについて話してるのは
何もJSがいいぞという話ではなくて
動的言語の可能性を示すための一例だから
ここでJSを愚痴ってもしかたない

563 ：デフォルトの名無しさん：2013/10/17(木) 09:03:06.59

>>561
JSアンチスレはここですが、なにか？

564 ：デフォルトの名無しさん：2013/10/17(木) 10:18:23.11

>>562
既に他の言語ではとっくの昔に実現されてる機能がJSにも(仕様では)存在するって話から
どんな可能性を読み取れば良いの？

565 ：デフォルトの名無しさん：2013/10/17(木) 10:52:57.65

もうjsがクソ言語かどうかは別スレでやれよ(´・ω・｀)

566 ：デフォルトの名無しさん：2013/10/17(木) 10:55:31.30

意味不
誰がいつJavaScriptのそういう仕様が良いと言ったのか
動的言語がいい理由はエンジンの可能性として前スレから散々出ただろう
JavaScriptもV8凄いねって話で出ただけで
仕様の話は足りないという意見とその反論のみで
この趣旨に則って議論されては無いだろう
だから批判は別スレでやれって言ってる

567 ：デフォルトの名無しさん：2013/10/17(木) 13:22:18.18

　 jsは静的言語より柔軟で凄い
→ 実装足りてないよ
→ jsは実装じゃなくて仕様、仕様は安泰
→ 仕様も足りてないよ
→ 仕様の批判は別スレでやれ

なぜなのか

568 ：デフォルトの名無しさん：2013/10/17(木) 15:46:07.10

開発生産性という面であれば例えばGUI開発のようなある程度の規模のAPIを相手に
する開発する場合、IDE上でいわゆるコンテントアシストやインテリセンスの類が
高打率で効いた方が非常に助かる。
そういう点では静的型や動的にしても仕様として型アノテーションを持っていて
きっちり注釈をつける習慣のある言語でないとアシストするにも打率が低すぎる。

IDEやエディタとかでも時々jQuery対応とか謳うものがあるけれども、そもそも論
としてどうしてフレームワーク決め打ちで対応をアピールする必要があるのか。
言語仕様的にフレームワーク決め打ちで実装しないと十分なアシストを提供する
のが難しい部分があるって事じゃないのかな。

今時のJavaScriptフレームワークにテンプレートエンジンを組み合わせた開発に
しても、何年も前のAS3+MXMLに全然追いついていないと思う点も多い。

569 ：デフォルトの名無しさん：2013/10/17(木) 15:54:46.32

型アノテーション無しでもバシバシ補完が決まる
Pythonのjediは凄い

570 ：デフォルトの名無しさん：2013/10/17(木) 16:09:31.29

それは単純だけど依存するモジュールをPythonのコード内で普通にimportで明示
しているのも大きいと思う。
典型的なJavaScriptを使ったWeb向けの開発の場合、どういうコンテキストの中で
今相手にしているコードがロードされるのか解らんと依存範囲が特定できないし
アシストするにも限度がある。

require.jsを使ったところでrequire.js決め打ちでエディタが対応しないとダメ
だろうなぁ。

571 ：デフォルトの名無しさん：2013/10/17(木) 20:26:38.24

JSがウンコだから悪いってことか…

572 ：デフォルトの名無しさん：2013/10/17(木) 20:38:51.81

このスレJSのアンチvs信者スレなのに埋まるの早すぎ

573 ：デフォルトの名無しさん：2013/10/17(木) 21:03:33.30

アンチ対信者というよりもリアルユーザー対未来の仕様を語る趣味の人でしょ。

今現在不便なことを愚痴ると未来の仕様が語られ今現在普及している実装では使えないと
話すと実装の話はスレチとかわされる。

574 ：デフォルトの名無しさん：2013/10/17(木) 21:24:09.39

ES99くらいになれば、型を書かなくても
Pythonくらい補完が効くようになるの？

575 ：デフォルトの名無しさん：2013/10/17(木) 21:49:23.36

>>571
依存性を宣言的に列挙する文法も無ければ依存性の解決方法も仕様化されていない、そういう意味では
今のJavaScriptがウンコなのが悪いということだろう。

576 ：デフォルトの名無しさん：2013/10/17(木) 21:51:18.27

今どき生のJavaScript使ってるからだろ。
Haxeその他有るじゃん。

577 ：デフォルトの名無しさん：2013/10/17(木) 21:55:19.52

C++,C#,Java,Python,Ruby,PHP,Perl,その他マイナー言語を初級くらいで扱えるけど
自分はJavaScriptが一番好きだよ

578 ：デフォルトの名無しさん：2013/10/17(木) 21:55:41.77

>>576
そんなマイナー言語、仕事で使えないじゃん

579 ：デフォルトの名無しさん：2013/10/17(木) 22:06:58.90

>>578
そうそう、その通り！
だから貴方は、今迄の言語を使っていて下さい。

580 ：デフォルトの名無しさん：2013/10/18(金) 00:24:48.20

JavaScriptにコンパイルする言語が山ほど出てくるあたりが今現在のJavaScriptに不満を抱く人が
多いって傍証。

NoSQLじゃなくてNoJavaScriptと言ったところだな。

581 ：デフォルトの名無しさん：2013/10/18(金) 00:56:17.69

だからもうjavascriptの言語がくそかどうとかはどうでもいいよ。
動的の代表格として出すのはいいけど、それ以外の糞仕様について語るのはスレチだ。

582 ：デフォルトの名無しさん：2013/10/18(金) 01:02:54.60

クソなJavascriptが動的言語の代表格ヅラしてるのが
滑稽だと言っているんだよ

583 ：デフォルトの名無しさん：2013/10/18(金) 01:19:43.88

>>580
> JavaScriptにコンパイルする言語が山ほど出てくるあたりが今現在のJavaScriptに不満を抱く人が
> 多いって傍証。

まったく論理的じゃない。

言語というのは山ほど出きるもの。C、C++、Perl、Ruby、PHP、Java
それらは、アセンブラに不満をいだいたから出来たわけじゃない。

584 ：デフォルトの名無しさん：2013/10/18(金) 01:36:27.98

>>583
それでは他にどんな理由があると？説得力のある別の理由付けをよろしく。

585 ：デフォルトの名無しさん：2013/10/18(金) 01:49:22.03

CSやTSは次期ESと協調して策定されてるよ
別の派閥ってわけじゃ全くない
どれもより良い機能を追求するJS.nextファミリー

586 ：デフォルトの名無しさん：2013/10/18(金) 01:55:42.00

>>584
プログラミング言語を作る理由？

既存の言語よりも優れているものを作りたいからじゃねーの？

特定の何かがダメだからではなく、他の言語全てよりも優れたもの、
需要にあったものを作りたいだけだよ。

JavaScriptがだめでCoffeeScriptを作ったというところまではいいが、
CoffeeScriptがあるのに、TypeScriptを作ったということは、
CoffeeScriptもだめということになる。○○もだめで□□を作り、
□□もだめだから△△を作り、それもだめだから☆☆を作った。と思う？

違うね。言語が作られるのは、他の言語よりも優れたものを目指して作ってるだけ。
JavaScriptにコンパイルするのはブラウザで動くのがJavaScriptだけだからってだけ。
JavaScriptだけ不満があるから他の言語を作ったのではなく、
その他の言語全てに不満があるから作ってる。

587 ：デフォルトの名無しさん：2013/10/18(金) 01:57:47.35

言語に不満があると言っても、それは主観の話、
個人の考え方の違いであり、その証拠に
JavaScriptは多くの人に使われている。

588 ：デフォルトの名無しさん：2013/10/18(金) 02:09:18.78

考え方の違いの数だけ言語が出来るだけの話。

589 ：デフォルトの名無しさん：2013/10/18(金) 02:23:22.11

JavaScriptも求められる状況が変わってきてそれに合わせて
JavaScript自体も進化しようとしてるし、altJSも出てきている
全て現状をより良くしようとする試みで敵同士ではなく味方
未来を負っているものに対してやれ現実がどうたら後ろ向きな批判されるとそりゃ嫌だわな
しかもとっくに解決の目処が立ってたり、そもそも見当違いなことばかり
>>554みたいな皆で解決策話し合える具体的で前向きな問題定義をしろよ

590 ：デフォルトの名無しさん：2013/10/18(金) 02:37:08.74

必死だねぇ。JSerとしてはひたすらJavaScriptは完全無欠の愛される言語と信じたいわけだ。

んなこと無いよ。
大多数の人は他の言語と同様に良い点悪い点併せ持った持った言語として使っているだけ。
今現在不便なところには普通に文句を言う。

591 ：デフォルトの名無しさん：2013/10/18(金) 02:54:09.33

どんな言語も夢見る未来のバージョンは大抵は完全無欠に見えるもの。
そりゃ今見えている不満を潰すところから取りかかるのだから当然。

そして出た頃には実際使ってみると新たな不満が出てくるのもお約束。

592 ：デフォルトの名無しさん：2013/10/18(金) 03:17:32.52

>>590
このスレは文句を言うスレではありません
不満があるのなら建設的な意見を出してください
そしてその不満の多くには既に解決策が示されていますから
このスレで出しても無駄です
各言語スレ、もしくはHTML5スレのような所で愚痴を必死にやってください

593 ：デフォルトの名無しさん：2013/10/18(金) 04:33:32.20

>>592
だからそもそもjsのことを話すスレじゃねえよ。お前が出てけwww

594 ：デフォルトの名無しさん：2013/10/18(金) 04:48:04.24

こやつ草生やさないとろくに弁解も出来ないほど追い込まれてるな
あと一歩だな

595 ：デフォルトの名無しさん：2013/10/18(金) 04:49:07.67

>>594
お前は何と戦ってるんだw

596 ：デフォルトの名無しさん：2013/10/18(金) 05:28:22.46

何でも首突っ込んでJavaScript(ES)中心で話すのをやめればいいだけ
なんで他言語の後追い仕様を元に優秀とか言っちゃうかね

597 ：デフォルトの名無しさん：2013/10/18(金) 05:43:10.94

>>596
ルビーストの悪口はそこまでだー！

598 ：デフォルトの名無しさん：2013/10/18(金) 05:57:42.84

>>596
Disる対象の言語仕様が劣っていないと余程都合がわるいようだな＾＾

599 ：デフォルトの名無しさん：2013/10/18(金) 06:57:39.17

型推論付きの静的型付け言語かオプショナルな静的型付きの動的型付け言語だな。

600 ：デフォルトの名無しさん：2013/10/18(金) 06:59:55.11

機能が多ければ良いってもんでもない
シンプル・イズ・ザ・ベスト

601 ：デフォルトの名無しさん：2013/10/18(金) 07:06:11.03

(※ただしES6や7で導入される機能は除く)

602 ：デフォルトの名無しさん：2013/10/18(金) 07:22:46.36

型注釈なんて単に機械可読なように仕様化されたドキュメントの断片です。

意固地なJSerはそれがわからんか、単にドキュメントを書く習慣がないのです。

603 ：デフォルトの名無しさん：2013/10/18(金) 07:34:28.31

その話は散々TypeScriptの時にしてむしろ分かってなかったのは
非スクリプターのようだったがな

604 ：デフォルトの名無しさん：2013/10/18(金) 08:03:38.39

TypeScriptの話ってなんだっけ？
型推論がウンコってことしか覚えてない

605 ：デフォルトの名無しさん：2013/10/18(金) 09:06:33.44

計算モデルと言語仕様との区別すら出来てない手合ばっかりだな。

606 ：デフォルトの名無しさん：2013/10/18(金) 09:23:39.43

どの書き込み見てそう思っちゃったの？

607 ：デフォルトの名無しさん：2013/10/18(金) 12:35:07.99

606だろ。

608 ：デフォルトの名無しさん：2013/10/18(金) 13:55:49.99

で、結局動的型+型注釈はどうなの?
御利益はあるし、Enhanced JSの多くが取り入れているあたりからも需要もあると
思うのだけど。

609 ：デフォルトの名無しさん：2013/10/18(金) 14:43:44.00

むしろドキュメントとソースの整合性が取れなくなるから無駄でFAだっただろ

610 ：デフォルトの名無しさん：2013/10/18(金) 15:09:26.70

?
型に関してドキュメントとソースの整合性を静的に機械的にチェック出来る余地
があるのが型注釈の良いところだと思うけど。
型の付記の有無が実行時のセマンティクスに影響を与えるかは言語次第だし、
実行時に型チェックをせずに垂れ流すか型エラーを投げるかは一長一短がある。

それにそういう整合性をとるのは例えばライブラリやフレームワークの開発者が
頑張れば良いことで、彼らが一度頑張ればそのご利益はその成果物のユーザーに
広く行き渡るわけで。

型注釈やオプショナルな静的型を持つ言語では内部の実装は動的型も併用しつつ
柔軟に書いて、公開メソッドのようなAPIの顔の部分はきっちり型付きで書いたり
するのがベストプラクティスだったりするよね。

成果物にきっちり解りやすいドキュメントを書くのと同じだよ。
機械にも読みやすい点が違うだけで。

611 ：デフォルトの名無しさん：2013/10/18(金) 16:05:39.95

型注釈ならjsdocでいいじゃん

612 ：デフォルトの名無しさん：2013/10/18(金) 16:09:44.78

会社では動的型(+オプショナルな型付き)言語のGroovyを使ってGrails上で開発しているけれど、

・モデル: がっちり型付き(DBにマッピングするので結局型は明記する必要があるし)
・サービス: 公開メソッドは型付き
・その上のコントローラーやビュー: 動的型も併用

みたいな感じで回っている。大事なところは型付きで、柔軟性が必要なところやコンパクトに
書きたいところ(ビューのテンプレートの中のインラインコードとか)は動的型で。
実際使っていて静的動的両方使えるのは何かと都合が良い。
あとGroovyとJavaは混ぜることが出来るのでJavaでゴリゴリ書く部分もある。

613 ：デフォルトの名無しさん：2013/10/18(金) 16:16:45.14

Groovy使うとかTypeScript使う並に今はまだ時期尚早だろ

614 ：デフォルトの名無しさん：2013/10/18(金) 16:36:17.55

jsもasm.jsっぽい型指定使うようにすればいいじゃん
注釈ならdocでいいけど前者ならパファーマンス上がる効果も見込めるし

615 ：デフォルトの名無しさん：2013/10/18(金) 16:39:09.43

静的+型推論が一番
実行時速度も動的より早い

616 ：デフォルトの名無しさん：2013/10/18(金) 16:44:29.51

>>613
Groovyはそれなりに古いよ。

どんぐらい古いかというと産みの親が「開発当時Scalaについて知っていたらGroovyなんか
作らなかったのに」とつぶやいてそのままScalaに走った程度には古いw
時期的には同時期。

歴史的にはGrailsはZendやDjangoと同時期にスタートしていて、今もSpringベースの
フルスタックフレームワークとしては一番活発に更新され文書化されているものの一つなので、
特に時期尚早と言うこともない。

617 ：デフォルトの名無しさん：2013/10/18(金) 16:44:45.67

※根拠なし

618 ：デフォルトの名無しさん：2013/10/18(金) 16:59:23.33

Grailsに関連してJavaの世界でのWebフレームワークの流行廃りに関してはこのあたり。61ページぐらいから。
http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013

619 ：デフォルトの名無しさん：2013/10/18(金) 17:39:05.07

asm.jsってネイティブより高速なケースも出てきたし
このまま行くとemscripten＋生JSが最強そうだな

620 ：デフォルトの名無しさん：2013/10/18(金) 18:57:04.00

GroovyにせよScalaにせよJavaにせよJVMファミリーでみな簡単に連携できる。
.netファミリーも同様で、要するに同じ実行環境で場面に応じた言語をシームレスに使い分け
られるのは便利。

621 ：デフォルトの名無しさん：2013/10/18(金) 19:24:05.00

理屈ではそうだが現実は.netが糞なのでどうしようもない

622 ：デフォルトの名無しさん：2013/10/18(金) 20:27:48.51

Groovy時期尚早ってなんだろ。ちゃんと使われているよ。
Androidの次期ビルド環境はGradleだしね。

623 ：デフォルトの名無しさん：2013/10/18(金) 21:11:24.70

まともに使えるのは２、３年後ってとこじゃないかな？

624 ：デフォルトの名無しさん：2013/10/18(金) 21:15:49.09

TypeScriptの方が使えるようになるの早そうだね
http://blogs.msdn.com/b/typescript/archive/2013/10/17/typescript-and-the-road-to-1-0.aspx

625 ：デフォルトの名無しさん：2013/10/18(金) 21:37:37.60

>>624
.NETは元からJScriptがあったからな

626 ：デフォルトの名無しさん：2013/10/18(金) 22:05:29.10

まあまともに使えるまであと3・4年かかるES6とか待つよりも現実的な解ではあるよね・・・ > TypeScript

627 ：デフォルトの名無しさん：2013/10/18(金) 22:08:06.83

ES6は既に半分くらい使えるし９割対応までモダンエンジンならせいぜいあと１年何だが

628 ：デフォルトの名無しさん：2013/10/18(金) 22:20:11.09

IE11のES6対応なんてletとconstだけだし(すごいね!)IE12のスケジュールや更新内容なんて分からんし。

629 ：デフォルトの名無しさん：2013/10/18(金) 22:24:35.55

letに対応してるだけでかなり十分
あとはアロー関数だけあればいい

630 ：デフォルトの名無しさん：2013/10/18(金) 22:30:48.63

だから土管としてはもう十分だって

631 ：デフォルトの名無しさん：2013/10/18(金) 22:30:58.22

来年以降のES12とそれからまた先のES11の絶滅をお待ちください > アロー関数

632 ：デフォルトの名無しさん：2013/10/18(金) 22:32:58.14

なんだESって。IEだ。

633 ：デフォルトの名無しさん：2013/10/18(金) 22:57:10.56

letが使えるってことで、１つあると思うのは
何でもかんでも
(function(){
})
で囲うのやめて
ブロックとletにしないかなーってこと

極力varを使わないで全部letにする
これができるのはそこそこ大きいと自分は思う

634 ：デフォルトの名無しさん：2013/10/18(金) 23:19:03.30

何でもかんでもfunctionで囲んでいる辺りでこの言語何かがおかしいと気づいて欲しい。

635 ：デフォルトの名無しさん：2013/10/18(金) 23:22:50.99

その言い方だと語弊があるな
導入と結論が結びついてないし
バカな煽りにしかなってないよ

636 ：デフォルトの名無しさん：2013/10/18(金) 23:34:44.88

>>635
お前の指摘する内容が
お前の書き込み自身にモロに当てはまっててワロタw

637 ：デフォルトの名無しさん：2013/10/18(金) 23:42:01.10

KY黙っとけ

638 ：デフォルトの名無しさん：2013/10/19(土) 00:20:34.69

JSをクソだと指摘するだけで
発狂する輩がいるのが不思議。事実じゃん

639 ：デフォルトの名無しさん：2013/10/19(土) 00:32:39.26

>>621
それはJVMに比べてクソだ言うてんの？

640 ：デフォルトの名無しさん：2013/10/19(土) 00:32:55.23

633のは弁護出来ないよなぁ。
再来年以降はlet使えるようになって改善するらしいけど。

641 ：デフォルトの名無しさん：2013/10/19(土) 01:57:57.87

しかしながらletはコストが高いんだよなあ
特にfor文では一目瞭然

642 ：デフォルトの名無しさん：2013/10/19(土) 02:05:12.50

来年にはIE11の強制アップデートがあるんじゃないかな

643 ：デフォルトの名無しさん：2013/10/19(土) 06:32:30.56

groovyって日本だとあまり馴染みないけど、海外だと結構名前聞くよな

644 ：デフォルトの名無しさん：2013/10/19(土) 08:40:52.49

Javascriptについて質問です。
どうして以下のような結果になるのですか？
全然意味が分かりません。。。

['1','2','3'].map(parseInt) //[1, NaN, NaN]

645 ：デフォルトの名無しさん：2013/10/19(土) 09:38:28.19

>>644
なんだこれw

646 ：デフォルトの名無しさん：2013/10/19(土) 10:29:24.01

JSウンコ伝説に新たな1ページなの？

647 ：デフォルトの名無しさん：2013/10/19(土) 10:36:01.47

駄々こねてるな。

648 ：デフォルトの名無しさん：2013/10/19(土) 11:34:41.10

ぐうの音も出ない

649 ：デフォルトの名無しさん：2013/10/19(土) 12:10:51.95

JSerの解説マダ～？

650 ：デフォルトの名無しさん：2013/10/19(土) 12:38:04.79

>>644

function vi(value, index) {return index + ':' + value }
['a','b','c'].map(vi)
=> [ '0:a', '1:b', '2:c' ]

これと同等だから
function p(value, index) {return parseInt(value, index) }
['1','2','3'].map(p)

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/parseInt

var intValue = parseInt(string[, radix]);

引数

string
パースしたい値を表す文字列

radix
string （第一引数）の基数を表す整数

651 ：デフォルトの名無しさん：2013/10/19(土) 13:11:24.78

Haskellで言うところのmapAccumLなのか
普通のmapは無いの？

652 ：デフォルトの名無しさん：2013/10/19(土) 13:26:14.27

自分で作ればいいんじゃね？

っていうかコアになんでも詰め込もうとするなよ。
コアは最小限で後はライブラリで補う方がいい。

コアだけなら
['1','2','3'].map(v=>parseInt(v))
ってかけるようになるだろ？

今すぐには全てのブラウザで使えない？
うん、だから、自分で作れってことさ。

653 ：デフォルトの名無しさん：2013/10/19(土) 13:42:52.54

JSって引数の数が合わなくても
例外すら出ないんだ

654 ：デフォルトの名無しさん：2013/10/19(土) 13:43:52.80

この場合引数の数あってるだろ。
なんでこう馬鹿は馬鹿なこと言い出すんだろうか。

655 ：デフォルトの名無しさん：2013/10/19(土) 13:50:41.50

え？valueとindexを引数にとる関数がmapの引数になるんじゃないの？

656 ：デフォルトの名無しさん：2013/10/19(土) 13:55:09.28

頭悪すぎｗ
valueとindexって変数名だぞ？

それを言うなら、引数を二つ取る関数がmapの
引数になるという言い方をするべき。

657 ：デフォルトの名無しさん：2013/10/19(土) 13:56:03.41

つまり引数を一つしか取らない関数を
mapに渡したらエラーになって欲しいって
言ってるのか？

658 ：デフォルトの名無しさん：2013/10/19(土) 14:07:10.44

ううん。引数の数が合わなくてもエラーにならないよね？って言ってるだけだよ

659 ：デフォルトの名無しさん：2013/10/19(土) 14:09:22.17

関係ない話はいいから、
mapとpasrseIntの話の続きをしようぜ。

で、結局、なんの問題もないってことか。

660 ：デフォルトの名無しさん：2013/10/19(土) 14:28:17.13

いや、問題無いどころか、ナカナカ良いよ
引数の数が合わなくてもエラーにならない仕様を活かして
mapとmapAccumを一つの関数で実現してる

まあ、静的型ならオーバーロードで簡単に実現できるだろうけど

661 ：デフォルトの名無しさん：2013/10/19(土) 14:46:28.05

JavaScriptは知ってるけどHaskellは知らないから
当然mapAccumLも知らないけど、
>>650の説明はmapAccumLとは違うだろ？

662 ：デフォルトの名無しさん：2013/10/19(土) 15:11:04.80

>>654
mapのcallbackって引数3つじゃね？

663 ：デフォルトの名無しさん：2013/10/19(土) 15:20:51.65

>>656
いちいち言い換えないと理解できないやつの方が頭悪いと思うけどｗ

664 ：デフォルトの名無しさん：2013/10/19(土) 16:52:23.51

バクりやすそうな仕様だな

665 ：デフォルトの名無しさん：2013/10/19(土) 16:55:13.49

>>664
そだな。バグりにくく生産性が高いJavaが
いまのところ最強という結論にどうしても行き着いてしまうな。

666 ：デフォルトの名無しさん：2013/10/19(土) 17:16:30.94

問題はあるよ
>>554でも書いたけど、やっぱり気になる
でもmapが悪いわけでもparseIntが悪いわけでもない
「考えてみれば当然」の動作だし、知っていればいくらでも防げるんだよね
でも気づきにくい初心者落としの穴が増えたってのはやっぱり嬉しくない
何とかしてそこを改善したいんだけど、
map系での自動引数制限みたいなのは互換性が崩れるからもう無理かな
でもこれはいい経験になって、任意数の引数とる関数とかは
mapのためにも第一引数に配列って形にしようって声が出るようになった
まあ難しいね

667 ：デフォルトの名無しさん：2013/10/19(土) 17:19:00.65

素直にインデックス付きが欲しい場合はmapWithIndexとかeachWithIndexじゃダメなの。
あるいはa.zipWithIndex().map(f)とか。

668 ：デフォルトの名無しさん：2013/10/19(土) 17:24:10.16

C言語ですら、ANSI Cになるときに引数の数の整合性をチェックするようになったのに
今の時代にチェックしないJSはマジでクソだな
しかも、今後もチェックするようになる可能性も無い

669 ：デフォルトの名無しさん：2013/10/19(土) 17:26:10.65

typescript使えってことだろ
javascriptはプログラマーだけじゃなくデザイナーウェブマスターも使うんで厳密なプログラミングは好まれないんだろう

670 ：デフォルトの名無しさん：2013/10/19(土) 17:27:28.39

第一引数に配列とか、その場その場で次元というかインデント性というかズラすのはやめてほしい…。構造崩してなんの為のプログラム言語なんだか。ダメ絶対。

671 ：デフォルトの名無しさん：2013/10/19(土) 17:33:29.41

>>667
それなら引数１つのmapを定義すれば済みそうじゃない？
Array.prototype.map2 = function (func, thisArg) {
return this.map(function (val) {return func.call(thisArg, val)})
}

a = ["10px","20px","30px"]
a.map2(parseInt) //[10, 20, 30]
まあ本来parseIntはこういうのに使うべきで無闇矢鱈に使われすぎっていうのもあるんだけどね

>>668
そんな冗長になるもの要らないでしょ
必要なら関数側でチェックすればいいじゃん？
デフォルト引数とかもあるし、柔軟に柔軟にがいいと思うよ

>>670
既存の関数のオーバーライドとしてだから別に自然だよ

672 ：デフォルトの名無しさん：2013/10/19(土) 17:36:19.80

型の弱い言語は総じてゴミだな

673 ：デフォルトの名無しさん：2013/10/19(土) 17:44:41.93

>>669
TypeScriptってこんなコードですらエラーにならないけど

function f(g) { return g(1,2) }
f(function(x){ return x })

674 ：デフォルトの名無しさん：2013/10/19(土) 17:45:04.09

1引数のparseDecimalを新設すれば良いんじゃ無い?
既に1引数のparseFloatをparseNumに改名するのでも良い。

初心者向けにはparseIntの解説に2進数8進数16進数など色々な基数でパースする
無駄に豊富なサンプルをここだけ妙に専門用語満載な解説と一緒にてんこ盛りに
すれば概ね無問題。不思議と自然に使わなくなるはず。

675 ：デフォルトの名無しさん：2013/10/19(土) 17:51:56.11

function asUnaryFunction(x){ return function(n){ return x(n); } }

["0","1","2"].map( asUnaryFunction(parseInt) );

676 ：デフォルトの名無しさん：2013/10/19(土) 17:53:03.49

引数が二つ以上あるって事は、本来役割の違う処理が混ざってるって事なんだよね
どこまでも分けていったら人間がついていけなくなるからしないけど

677 ：デフォルトの名無しさん：2013/10/19(土) 17:53:44.83

引数バインドがあればもっと上手く解決できるんじゃないかな
こんな感じで第二引数だけを固定してやれれば

Function.prototype.bindArg = function (binds) {
var func = this
return function () {
var args = [].map.call(arguments, function (arg, i) {
return i in binds ? binds[i] : arg
})
return func.apply(this, args)
}
}

["10px", "20px", "30px"].map(parseInt.bindArg([,10]))

678 ：デフォルトの名無しさん：2013/10/19(土) 17:54:11.63

じゃあカリー化で

679 ：デフォルトの名無しさん：2013/10/19(土) 17:56:19.89

>>674こういう感じか

parseDecimal = parseInt.bindArg([,10])

["10px", "20px", "30px"].map(parseDecimal) //[10, 20, 30]

680 ：デフォルトの名無しさん：2013/10/19(土) 18:02:38.30

長年ゴミ言語に付き合ってるだけあって
耐性ついてるな

681 ：デフォルトの名無しさん：2013/10/19(土) 18:04:15.92

>>679
うん。でもそこはあくまでとっかかり。

一番大切なのはJavaScriptエディタ上でparseIntにマウスカーソルを乗せると
技術解説やらトリッキーな使用例や過去の仕様書へのリンクも含めた10ページ
ぐらいの長大なツールチップヘルプがポップアップして画面を埋め尽くすこと。

682 ：デフォルトの名無しさん：2013/10/19(土) 18:06:10.03

この手の面倒なのに遭遇するとscalaで書きたくなる

683 ：デフォルトの名無しさん：2013/10/19(土) 18:08:49.53

ES6流の解決方法だと
forMapArityLimitシンボルをparseIntにつけてmapで判断だろうが
mapがES5のもので、この問題が数年置いて置かれたってのが仕様からの解決を難しくしてる

684 ：デフォルトの名無しさん：2013/10/19(土) 18:12:49.85

LiveScriptで十分やった

[ "10px" "20px" "30px" ].map( parseInt _, 10)

685 ：デフォルトの名無しさん：2013/10/19(土) 18:15:16.81

>>681
うーん、まあそこまでするかはさておき
MDNのmapの項目見たら一応乗ってたね
まずは初心者はMDNを参考にするよう徹底したいとこ

686 ：デフォルトの名無しさん：2013/10/19(土) 18:46:38.85

JavaScriptって柔軟だね。
いろんなことが出来る。

687 ：デフォルトの名無しさん：2013/10/19(土) 19:01:50.42

仮にもLispの後継を名乗るのならトリッキーであるべき

688 ：デフォルトの名無しさん：2013/10/19(土) 19:07:55.78

とりあえず各言語のこれからの課題はマルチコアをいかに活かせるかじゃね

689 ：デフォルトの名無しさん：2013/10/19(土) 21:05:32.00

このスレみてたら、やっぱJavascriptはゴミだって確信できた
やっぱりRubyを使い続けてて良かった

690 ：デフォルトの名無しさん：2013/10/19(土) 21:31:38.10

公式HobbyのRubyに言われてもな……

691 ：デフォルトの名無しさん：2013/10/19(土) 21:56:54.27

JavaとかJavascriptってHobby以下だよな...
まあJavaはドカタ向けに、Javascriptは非プログラマ向けに
あえてダメに作られたんだけど

692 ：デフォルトの名無しさん：2013/10/19(土) 22:00:42.67

流石Hobbyプログラマの言うことは一味違うな

693 ：デフォルトの名無しさん：2013/10/19(土) 22:31:33.61

その公式HobbyとHobby以下の合わせ技のような立ち位置が切なくなるのでその辺りで勘弁して下さい

　--- Groovyからのお願い ---

694 ：デフォルトの名無しさん：2013/10/20(日) 12:23:04.41

javascriptはチューリング完全であればなんでもいいよ
他言語から変換すればいいから

695 ：デフォルトの名無しさん：2013/10/20(日) 17:40:53.30

そんなアホなことをしなくてもJavaScriptを使いこなせればいいだけのこと

696 ：デフォルトの名無しさん：2013/10/20(日) 17:48:24.09

使いこなせても使いたくない

697 ：デフォルトの名無しさん：2013/10/20(日) 17:53:42.76

損な性格してんのね
かわいそ～

698 ：デフォルトの名無しさん：2013/10/20(日) 18:33:12.00

まぁマゾの方が楽しめる場面もあるかもな。
羨ましくはないが。

699 ：デフォルトの名無しさん：2013/10/20(日) 18:49:16.99

JavaScriptとか楽しすぎるんだが

700 ：デフォルトの名無しさん：2013/10/20(日) 18:56:25.15

ブラウザでいろいろできるっていうのがいい

701 ：デフォルトの名無しさん：2013/10/20(日) 19:06:12.31

ブラウザでいろいろできるっていうのが、JSの唯一の利点だからね
ただ、他言語からJSに変換できるようになって
唯一のアドバンテージも無くなっちゃった

702 ：デフォルトの名無しさん：2013/10/20(日) 19:11:06.64

他言語からJSに変換ってはやってないね。

703 ：デフォルトの名無しさん：2013/10/20(日) 19:11:47.25

そんなもん昔からできるし
JSが廃れそうな兆候とか皆無だけどな
まあ、理想を語るのは自由か

704 ：デフォルトの名無しさん：2013/10/20(日) 19:11:47.46

ブラウザで動かすって結局はDOM操作だからね。
他の言語が変換できるといっても
DOMのAPIは変わんないし。

705 ：デフォルトの名無しさん：2013/10/20(日) 19:12:17.00

めっちゃ流行ってる
ttps://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

706 ：デフォルトの名無しさん：2013/10/20(日) 19:12:20.17

むしろJSがブラウザ以外で動かないという
デメリットがなくなった気がする。

707 ：デフォルトの名無しさん：2013/10/20(日) 19:13:00.78

node.jsが出来損ないじゃなければ...

708 ：デフォルトの名無しさん：2013/10/20(日) 19:14:05.03

DOM扱うだけならそれこそJSで十分だけどな

709 ：デフォルトの名無しさん：2013/10/20(日) 19:16:21.08

それは言えてる

710 ：デフォルトの名無しさん：2013/10/20(日) 19:16:51.01

>>705
あぁ、使われてないという意味だよｗ
存在するかどうかじゃない。

711 ：デフォルトの名無しさん：2013/10/20(日) 19:17:29.66

使われてないか、どうやって調べたの？

712 ：デフォルトの名無しさん：2013/10/20(日) 19:17:37.41

やっぱりJSってのは大企業数社が
協力して開発しているっていうのが大きいよ。

713 ：デフォルトの名無しさん：2013/10/20(日) 19:18:28.54

Node.jsはソケット周りの問題をこの度のsocket3で片付けたし
あとはまあ、Webサーバー専用機としてみた時は改善点あるけど
バランス的には出来損ないじゃないと思うけどな

JSとしての課題はそういうのじゃなくてむしろ、
色んな環境でのAPIを揃えていくことにあると思う
ここがちゃんとしないとこの先JSerが困ることになるし
もちろんaltJSの言語にも影響する

714 ：デフォルトの名無しさん：2013/10/20(日) 19:18:31.14

>>711
幾つものランキングを見たら判断できる。

715 ：デフォルトの名無しさん：2013/10/20(日) 19:20:29.51

使われてるって判断したのは
どうやって調べているかというと
調べてないｗ

716 ：デフォルトの名無しさん：2013/10/20(日) 19:22:17.37

そういう煽りはもういいよ
前に進める皆のためになる話題をしよう
今も昔も各言語はいろんな言語を参考に進化してきたろ
プログラマも勿論協力しあうべき

717 ：デフォルトの名無しさん：2013/10/20(日) 19:25:16.48

Dartは生成されるJSコードがマジうんこだから
一目見て使われてるか分かるな
他はコードみてもわからないかも

718 ：デフォルトの名無しさん：2013/10/20(日) 19:31:43.17

>>717
一時期のキチガイレベルと比べ物にならないくらい今はまともなコード書くようになってるよ
更に最適化もしてくれる
JSで適当に書くより早い
https://www.dartlang.org/performance/

719 ：デフォルトの名無しさん：2013/10/20(日) 19:32:08.84

よっぽど簡単なコードでない限り、
どの言語も汚いJSコード吐き出すってーのｗ

720 ：デフォルトの名無しさん：2013/10/20(日) 19:32:42.28

>>718
吐き出したコードが、読めないという意味です。

721 ：デフォルトの名無しさん：2013/10/20(日) 19:35:00.24

まあ最適化とことんしていくつもりみたいだからね
TSやCSに比べたらそうだろうが、
そもそも自分で書いてない変換されたコードは読みにくいし
あんまり読むもんじゃないと思うね

722 ：デフォルトの名無しさん：2013/10/20(日) 19:38:12.32

>>719
例えば？

723 ：デフォルトの名無しさん：2013/10/20(日) 19:41:27.87

まあ人間が書いたコードには敵わないと思いたいな
パフォーマンスと精密さ以外では

724 ：デフォルトの名無しさん：2013/10/20(日) 19:43:09.96

どう書こうがJSのコードは可読性悪いからな

725 ：デフォルトの名無しさん：2013/10/20(日) 19:44:39.15

最近のJSターゲットのトランスレータ系は、結構読めるソース吐くぞ。
つーか、ヘッポコPGが書いたコードより素直で読みやすかったり。

726 ：デフォルトの名無しさん：2013/10/20(日) 19:51:02.56

そりゃあそうだろうな

727 ：デフォルトの名無しさん：2013/10/20(日) 20:10:23.59

altJSってJavaScriptで書くと
冗長になるコードを簡単にかけるのが売りなんで、
変換すると冗長になるのは当たり前なんだが？
やっぱり使ったことないんだろうな。

728 ：デフォルトの名無しさん：2013/10/20(日) 20:14:04.89

それはCoffeeScriptの売りだがaltJS全体の売りではない

729 ：デフォルトの名無しさん：2013/10/20(日) 20:15:34.71

JavaScriptってES6まで配列とかの継承出来なかったけど
ES3だかに変換するaltJSではその問題ずっと引きずらないのかな

730 ：デフォルトの名無しさん：2013/10/20(日) 20:17:07.36

>>727
冗長だけど読めるコードに変換するんじゃん？

731 ：デフォルトの名無しさん：2013/10/20(日) 20:20:00.23

>>730
変換する時に無駄な機能をゴテゴテ付けてくれるから読みにくい。
最初からJSで必要最小限のコードを書いたほうが読みやすい。

732 ：デフォルトの名無しさん：2013/10/20(日) 20:21:49.41

>731
例えば？

733 ：デフォルトの名無しさん：2013/10/20(日) 20:22:31.07

それ以前に自分で読むなら自分で書いたままのコードが一番読みやすいに決まってる

734 ：デフォルトの名無しさん：2013/10/20(日) 20:56:43.89

>>729
ES6が殆どのブラウザで動くようになったら
ES6に変換するようになると思うよ

735 ：デフォルトの名無しさん：2013/10/20(日) 21:54:03.45

それこそ何年かかるんだか
つうかES6で書けるならそっちで書くのでよくね

736 ：デフォルトの名無しさん：2013/10/20(日) 21:58:36.12

今ES5で一番不満なのはProxyだなあ
これが使えなくて本当に参ってる
V8でさっさと使えるようになって欲しいんだけど
V8のProxyは旧Proxyで使いものにならない
１日もはやくDirectProxy実装して欲しい
でないとやりたいことがいつまでたってもできないわ

737 ：デフォルトの名無しさん：2013/10/20(日) 22:00:28.85

>>735
ちゃんとした静的型で書きたい、とか？
TypeScriptはなんちゃってだし

738 ：デフォルトの名無しさん：2013/10/20(日) 22:02:39.77

いや、もちろん多言語を使いたいってのは分かるけど
JSの使いやすさ自体がES6で結構上がるので同仕様もなくaltを使う必要はなくなると思う

739 ：デフォルトの名無しさん：2013/10/20(日) 22:17:23.51

JSは型をチェックするのではなく揃えるようにしたらいいと思う
あとなるべくエラーを出さないってのも良いと思う

例えば数値以外は弾く
if (typeof x !== 'number' || isNaN(x)) throw 'err';

のではなくて本当にできる限り初期化するのでいいように務める
x = +x || 0

弾く必要があるときもできるかぎり抽象度の高い段階、
それこそ入力を受け取ってすぐでチェックする
つまりできるだけ早い段階で型を保証、確定させといてその後は気にしないのがコツかと
これさえ守れはそうそう躓くことは無いはずだし、大変じゃないはず

それで大人数で作るときは出来るだけモジュール化して細部を他者から呼ばせることのないようにする

740 ：デフォルトの名無しさん：2013/10/20(日) 22:20:31.21

あと場合によっては出力値をチェックするだけってのも有効だと思う

741 ：デフォルトの名無しさん：2013/10/20(日) 22:26:13.82

普通だな

742 ：デフォルトの名無しさん：2013/10/20(日) 22:40:20.14

静的厨は型が動的なことを恐れすぎ

743 ：デフォルトの名無しさん：2013/10/20(日) 22:42:57.86

静的でも動的変数使えるのってある？
型推論じゃなくてね

744 ：デフォルトの名無しさん：2013/10/20(日) 22:49:34.59

やろうと思えばレベルならいくらでも
もし動的レベルにできるなら
それは動的言語の枠に入れた方がいい

745 ：デフォルトの名無しさん：2013/10/20(日) 22:52:18.16

>>743
C#のdynamicとかVB.NETのOption Strict Offとか。

746 ：デフォルトの名無しさん：2013/10/20(日) 23:19:23.65

静的動的には拘らないけど、型チェックはキッチリやっていただけると
テストコードが減ります

747 ：デフォルトの名無しさん：2013/10/20(日) 23:25:51.62

型チェック？？？
値をチェックするのに含まれるから別にあえて型チェック意識する必要なんて皆無だろ

748 ：デフォルトの名無しさん：2013/10/20(日) 23:36:56.09

最終的な値が合ってる間違ってるだけの情報じゃ、
関数の深い所で型エラーになってたら
間違った場所を追うのが大変ですよ

749 ：デフォルトの名無しさん：2013/10/20(日) 23:44:54.35

型エラーって何
動的言語での話をしてるんだよね？
で、暗黙の型変換や変数が任意型のせいでエラーが出ないのを問題視してるんじゃないの？

750 ：デフォルトの名無しさん：2013/10/20(日) 23:52:02.00

静的でも関数型のように副作用を極力できないようにしてバグが発生するのを抑えようとする中、値の変更どころか種類まで自由になる動的はないわー
動的の柔軟なところがいい場面もあるけれど、お前らの書いてるコードではほとんど必要ないぞ。

751 ：デフォルトの名無しさん：2013/10/20(日) 23:57:18.18

何でもかんでも厳格である必要はないがな
基本軽量でやろうと思う箇所でチェック入れるので十分だと思う
もちろん動的静的両方あるんだから適時適所だが
少なくとも自分は動的のほうが好きというか便利で使いやすいと感じる

752 ：デフォルトの名無しさん：2013/10/20(日) 23:58:15.68

柔らかいのを活かすんじゃなくて固くある必要がないんだよ

753 ：デフォルトの名無しさん：2013/10/21(月) 00:07:09.45

まぁその辺は好みだろうがF#使ってると変なバグの入り込む余地がほぼ潰されるけど楽に書けるので動的で軽く書けるという利点が全く分からん。
F#やその他の静的関数がたは軽くかけるのに硬さの利点も併せ持つぞ？

754 ：デフォルトの名無しさん：2013/10/21(月) 00:08:26.12

固くある必要が無いってのが皆目わからん(´・ω・｀)
固さでどんだけ助けられたことか。

755 ：デフォルトの名無しさん：2013/10/21(月) 00:10:42.78

動的も静的も使うけど暗黙的なのもあんまり好きじゃないし型とかも明示的に書いたほうがいいわ

756 ：デフォルトの名無しさん：2013/10/21(月) 00:10:50.79

必要があるんなら世の中全て静的型付け言語が蔓延ってないとおかしいがな

757 ：デフォルトの名無しさん：2013/10/21(月) 00:13:28.35

>>756
それは逆も言えるだろ。必要ないならなんで全部動的になってないのよw

758 ：デフォルトの名無しさん：2013/10/21(月) 00:15:09.81

助けられることもあるけど俺の感覚では余計なお世話感が強い

759 ：デフォルトの名無しさん：2013/10/21(月) 00:16:37.00

>>757
適材適所って言葉を知らんのか
メリットとデメリットは表裏一体なのは
プログラマならよく分かってることだろ

760 ：デフォルトの名無しさん：2013/10/21(月) 00:19:58.34

適所があまりないような～。

761 ：デフォルトの名無しさん：2013/10/21(月) 00:23:28.28

適所はJavaScriptがこれから次々見せてくれるよ

762 ：デフォルトの名無しさん：2013/10/21(月) 00:24:47.28

え？土管がなんだって？

763 ：デフォルトの名無しさん：2013/10/21(月) 00:25:19.22

JSの話はするな
そしていちいち突っかかるな

764 ：デフォルトの名無しさん：2013/10/21(月) 00:25:52.98

土管じゃなくてJavaScript

765 ：デフォルトの名無しさん：2013/10/21(月) 00:28:01.41

JavaScriptは昨今一番可能性を見せてくれている言語だから
話題に挙がるのもしかたがない
具体的な話をしちゃいけないんならこの不毛なスレがもっと不毛になってしまう

766 ：デフォルトの名無しさん：2013/10/21(月) 00:29:01.52

JSはCの二倍速い。

767 ：デフォルトの名無しさん：2013/10/21(月) 00:29:23.56

一番可能性があるのはD言語だろ

768 ：デフォルトの名無しさん：2013/10/21(月) 00:33:21.03

>>759
だから適所だと思って動的使ってるところは多分適所じゃないよって話なんだが。
動的のメリットである柔軟性がバグの温床になりやすいというデメリットになるよというのもそう。

769 ：デフォルトの名無しさん：2013/10/21(月) 00:35:55.36

>>766
asm.js的書き方でが直接対応のFFで２倍、直接非対応のCRで３倍ネイティブより遅い
マクロベンチだとだいたい５～１０倍くらい遅いって感じが現状じゃね？
http://kripken.github.io/mloc_emscripten_talk/box2d_graph_updated2.png

770 ：デフォルトの名無しさん：2013/10/21(月) 00:37:04.35

>>768
あなたの価値観は尊重するが
大衆とズレてることだけは認識しておいた方がいい

771 ：デフォルトの名無しさん：2013/10/21(月) 00:38:28.68

＞＞マクロベンチだとだいたい５～１０倍くらい遅い
これは非asm.jsの話ね

772 ：デフォルトの名無しさん：2013/10/21(月) 00:39:14.24

自分が大衆だと思わないことだ。

773 ：デフォルトの名無しさん：2013/10/21(月) 00:40:05.30

JSは動的なコード最適化があるので可能性は無限大。
使えば使うほど速くなる。

774 ：デフォルトの名無しさん：2013/10/21(月) 00:40:55.49

せやな
人の意見に不毛なケチつけるのは無し
へーそういう考え方もあるのねくらいに止めとけ
大人なら

775 ：デフォルトの名無しさん：2013/10/21(月) 00:40:58.64

大衆とは>>770のことである。
この定義は、>>770から聞きました。

776 ：デフォルトの名無しさん：2013/10/21(月) 00:41:05.91

何でここの連中はJSが好きなのかね
Webプログラマー板にでもいればいいのに

777 ：デフォルトの名無しさん：2013/10/21(月) 00:41:50.59

いいから、煽るなって
前向きな話をしようぜ
大衆より体臭を気にしろ

778 ：デフォルトの名無しさん：2013/10/21(月) 00:43:03.81

>>776
使用者や環境とともに成長してきた言語だから
当然

779 ：デフォルトの名無しさん：2013/10/21(月) 00:43:42.75

JS実行一回目でCの二倍高速。
二回目で2.5倍、10回目では3倍程度高速になります。

780 ：デフォルトの名無しさん：2013/10/21(月) 00:45:31.05

スパコンで数値計算してるヤツにこのスレ教えたら
爆笑してた

781 ：デフォルトの名無しさん：2013/10/21(月) 00:47:29.70

スパコンで　←　単なるユーザー、秘孔突かれて爆笑してたんだろ。
ヒデブとか言いそうだね。

782 ：デフォルトの名無しさん：2013/10/21(月) 00:48:12.96

1780レスもあって
静的型付け言語の潜在開発生産性は今の100倍
とやらが一度も話し合われてない
話し合われそうになってもすぐおじゃんになる民度に笑うわ

783 ：デフォルトの名無しさん：2013/10/21(月) 00:50:36.18

JSのVM作ってるヤツなんて、iccで最適化周り作ってる連中から見ればウンコだってさ

784 ：デフォルトの名無しさん：2013/10/21(月) 00:51:06.18

ほとんどJavaScriptじゃねえか
ここにきてやっと本題話してる感じ

785 ：デフォルトの名無しさん：2013/10/21(月) 00:51:16.46

>>779
そうなる可能性はあるよね
まあCのコンパイラも進化するだろうからアレだろうけど
自動スケーリングという策に対して
関数型言語のような厳密性アプローチか
LLのプロファイリングアプローチ、
正直それぞれ期待できると思う

786 ：デフォルトの名無しさん：2013/10/21(月) 00:53:00.73

>>784
え、そうだったの？
動的がいいか静的がいいかって話？
こういう技術で開発が楽になるとか
コンパイラの性能が上がるとか
そういうのと思ってたんだが……

787 ：デフォルトの名無しさん：2013/10/21(月) 00:54:44.51

>>773
> JSは動的なコード最適化があるので可能性は無限大。

動的な最適化っていうのは、
「動的で最適化出来ない」より速いのであって
静的な最適化のほうが速いよ。

なぜかというと、動的な最適化は所詮
実行時に最適化処理をするしかないから。

静的に最適化したコードを複数持っていて
実行時に使用する最適化コードを切り替える方が速い。

例えば、CPUが持っているマルチメディア命令セットごとに
DLLを作っておいて、実行時にCPUを判定して切り替えて使う
なんてものが、静的に最適化＋実行時に動的に切り替える方法の一つ。

788 ：デフォルトの名無しさん：2013/10/21(月) 00:58:18.18

極論話だなそれ
それで済むんなら話が始まる必要すらない
そういうことを自動的にやってくれるのがJITの強みでしょうに

789 ：デフォルトの名無しさん：2013/10/21(月) 00:58:50.07

>>787
イイエ違います。
あなたは最適化の意味を知らない。

790 ：デフォルトの名無しさん：2013/10/21(月) 01:02:23.53

最適化はもっとスピリチュアルで神聖なものです。

791 ：デフォルトの名無しさん：2013/10/21(月) 01:04:11.71

俺も詳しく知らないし、上手く説明できないけど、実行時でこそできる最適化ってのがあるよ
人間の書くコードもコンパイラも完璧なら理屈的に要らないんだろうけどさ
実行環境に対応するってだけじゃなくて、人の書いたコードの意味とでもいうのかな
そういうのに対応するために有効なんだって
あと、マルチコアっていうのは、そういう最適化に１，２スレッドさけやすいってのはあるかと

792 ：デフォルトの名無しさん：2013/10/21(月) 01:04:18.03

JSにマルチスレッドなんてできんの？

793 ：デフォルトの名無しさん：2013/10/21(月) 01:04:31.59

jsの言ってる最適化って中間言語があればいい話で動的である必要なくね？

794 ：デフォルトの名無しさん：2013/10/21(月) 01:11:43.87

JSの言語構造が最適化に最適なのです。
その証拠にJavaはJITがあってもCより20倍しか速くなりません。
JSはそれ以上速くなる可能性があります。

20倍というのは、昔日本の研究者が発表した値で、当時結構話題になりました。
今でも、日本の研究者を馬鹿にするとき、特定国の研究者が持ち出すトピック
として使われます。
ですから、割とあてにならない話で、JSの圧倒的勝ちと言えます。

795 ：デフォルトの名無しさん：2013/10/21(月) 01:13:18.11

>>792
エンジンの話でしょう
JS仕様自体でもマルチスレッド意識してるよ
例のES7の話になってきて、例によって今はプロトタイプがFFにあるだけだけど

>>793
別にJSが言ってるわけではないがｗ
中間言語にする過程でコンテキストが失われたり
やっぱり読めなくなるからな

http://nothingcosmos.blog52.fc2.com/blog-entry-155.html
ここで中間言語化のそういう欠点の片鱗が知れる

796 ：デフォルトの名無しさん：2013/10/21(月) 01:14:16.98

Brainfuckでもやってろ

797 ：デフォルトの名無しさん：2013/10/21(月) 01:16:46.82

llvmは普通にCを中間言語に変換してるね

798 ：デフォルトの名無しさん：2013/10/21(月) 01:19:35.40

いやCPUごとにバイナリを生成すれば
静的のほうが速いからｗ

799 ：デフォルトの名無しさん：2013/10/21(月) 01:22:44.87

同じ話を繰り返さないでいいよ
単なる荒らし目的だろうけど

800 ：デフォルトの名無しさん：2013/10/21(月) 01:24:07.11

動的も静的もみんなちがってみんないい

みつを

801 ：デフォルトの名無しさん：2013/10/21(月) 01:25:35.50

>>795
いや、最適化に必要な情報があるならそれは残せばいいだけで。
V8がやってる最適化はjsでないとできないこととかあるの？

802 ：デフォルトの名無しさん：2013/10/21(月) 01:29:48.30

>>801
結果がすべてを物語っているんじゃないの？
JSはCの2倍以上速い。
これがすべて。

803 ：デフォルトの名無しさん：2013/10/21(月) 01:31:53.90

>>802
同じアルゴリズムで書いたコードで比較してるんですよね？
すごい興味があるので、ソースください

804 ：デフォルトの名無しさん：2013/10/21(月) 01:33:12.11

>>801
それってゆくゆくは中間言語じゃなくてそのままをJITコンパイルすればいいってことになるでしょ？
自分はただJITの可能性と中間言語の問題点を挙げただけでJSがどうとか極論はどうでもいいよ

805 ：デフォルトの名無しさん：2013/10/21(月) 01:33:28.24

>>802

訂正しておくね。

JSはCの2倍以上速い。
ことが一件だけ確認された。
残りの数億件はCの方が速い。

806 ：デフォルトの名無しさん：2013/10/21(月) 01:34:30.36

言語の可能性の話と宗教を絡めるのはやめろ

807 ：デフォルトの名無しさん：2013/10/21(月) 01:35:05.89

Cの方が速いという事例があれば
Cが速いと認めてあげますよ。

808 ：デフォルトの名無しさん：2013/10/21(月) 01:35:23.99

>>805
釣りに構うな
本当のJSerならあんな事言わない

809 ：デフォルトの名無しさん：2013/10/21(月) 01:36:53.49

荒らし目的でJSJS言ってる奴、極端な０か１かばかり主張する
話が通じない奴に餌をやらないでください

810 ：デフォルトの名無しさん：2013/10/21(月) 01:40:53.59

私はJSの良さを皆さんにも教えてあげたいという善意で書きこしてるんですよ

811 ：デフォルトの名無しさん：2013/10/21(月) 01:43:20.68

舐めてんの？
そんなんでJSを布教させられるわけねえだろ
出直して来い

812 ：デフォルトの名無しさん：2013/10/21(月) 01:45:18.61

JSはミスを誘発しやすいクソ構文だけど
実行速度はそこそこ速いので土管に最適ってことでしょ？知ってた

813 ：デフォルトの名無しさん：2013/10/21(月) 01:46:22.14

土管には実行速度が速いことが
一番重要だからな。

814 ：デフォルトの名無しさん：2013/10/21(月) 01:46:54.07

最速コードを書くのはいつも土管だし。

815 ：デフォルトの名無しさん：2013/10/21(月) 01:47:35.66

とりあえず気に食わない相手は
みんな土管と言っておけば、
すっきりするよ。
はいお前土管決定ってな。

816 ：デフォルトの名無しさん：2013/10/21(月) 01:49:04.44

土管がでてきたから俺はさっさと寝るかな。

817 ：デフォルトの名無しさん：2013/10/21(月) 01:49:20.76

いくら土管と言われようが俺はJSが一番好きだし誇りに思う
なのでどーでもいい

818 ：デフォルトの名無しさん：2013/10/21(月) 01:50:38.01

お前のかーちゃんどーかんｗ

819 ：デフォルトの名無しさん：2013/10/21(月) 01:50:45.65

私も誇りを持ってJSを使っています
誇りを持てる言語ってなかなかないと思います

820 ：デフォルトの名無しさん：2013/10/21(月) 01:51:47.11

JavaScriptは全てを受け止めてくれる抱擁力がある

821 ：デフォルトの名無しさん：2013/10/21(月) 01:52:12.41

土方が土管に誇りを持ってるのか
字面がくどいな

822 ：デフォルトの名無しさん：2013/10/21(月) 01:53:04.22

JSを使える優越感。

823 ：デフォルトの名無しさん：2013/10/21(月) 01:55:37.53

どうでもいいけど、追い詰められたら
ドカタって言って逃げるのやめたら？
毎度思うけど、小学生にしか見えん。

何を言うのも勝手だけど、
こっちは小学生かよって思って見てるからね。
そのことを忘れないで欲しい。

824 ：デフォルトの名無しさん：2013/10/21(月) 01:55:55.82

土管を馬鹿にしてるの？

825 ：デフォルトの名無しさん：2013/10/21(月) 01:57:15.55

>>804
んじゃなおさらここで触れるべきことじゃないじゃん。
少なくとも動的ゆえに静的では出来ないような最適化ができるよってことじゃなければ。

826 ：デフォルトの名無しさん：2013/10/21(月) 01:57:22.29

>>823土管としてしかJSを扱えない人達なんだから仕方ない

827 ：小学生：2013/10/21(月) 01:57:30.22

はい、おまえのとーちゃんどかたけってい！！！
うまれるまえから、おまえもどかたけってーい

これでいいですか？

828 ：デフォルトの名無しさん：2013/10/21(月) 01:59:45.94

なんか動的、静的関係なく、
コンパイル言語はコンパイルした時点でのCPUにしか対応できないが、
インタプリタ言語は未知のCPUでも対応できるって話にしか見えないんだが。

実行時にソースをコンパイルする言語なら、
静的言語でも未知のCPUに対応できるよ？

829 ：デフォルトの名無しさん：2013/10/21(月) 01:59:54.16

>>825
JITは必要かどうかっていう話題に対して提示したんだから
このスレで話すべきことだよ
別に動的VS静的スレじゃないし、動的静的の立場で話してないでしょ

830 ：デフォルトの名無しさん：2013/10/21(月) 02:01:35.63

インタプリタは違うな。
実行時にソースをコンパイルする静的言語は
なんて言ったらいいんだ？

831 ：デフォルトの名無しさん：2013/10/21(月) 02:02:20.51

せっかくのスレを正常化するための話題が
静的厨には静的言語への挑戦と受け止められたらしいな
やっぱり>>782の通りになった残念無念

832 ：デフォルトの名無しさん：2013/10/21(月) 02:02:58.72

それらはすべてJSの仲間です

833 ：デフォルトの名無しさん：2013/10/21(月) 02:05:08.16

>>830 実行時と言っても言葉の使われ方としては
実行「中」中心ならJIT
実行「直前」中心ならAOT
コンパイルっていうけど言語としては難しいね
C言語でもやろうと思えばJIT出来るんですって言われればそうかってなるし

834 ：デフォルトの名無しさん：2013/10/21(月) 02:07:33.69

実際にやってるのはJSだけだけどね
絶大な効果があるという意味ではね

835 ：デフォルトの名無しさん：2013/10/21(月) 02:10:12.83

>>831
スレを正常化というけど、スレタイとは全然合ってない話題って気がするよ
そりゃ、実行速度が開発生産性に直結するような分野もあるだろうけど、大抵は違うだろ

836 ：デフォルトの名無しさん：2013/10/21(月) 02:11:21.48

>>834
もとがクッソ遅かったから伸びしろは大きかったね
それでもまだ遅いけど

837 ：デフォルトの名無しさん：2013/10/21(月) 02:13:37.21

>>834 Dartもやってんじゃない？
というかV8とDartエンジンってよく似た最適化導入されてるよね
SMIとか凄く特徴的だよねえ
静的言語の可能性としてはDartに注目すべきなんじゃないかな
V8とのいろんな比較もしやすいだろうし
まあまずはDartがブラウザに乗ってからが本番だけど、
この冬とか前聞いたんだけどどうなのかな

838 ：デフォルトの名無しさん：2013/10/21(月) 02:16:57.89

>>718みるとV8はこの１年で50％以上もスコア伸ばしてるから
マクロベンチではまだまだ伸びしろあるだろうね

839 ：デフォルトの名無しさん：2013/10/21(月) 02:23:53.35

実行時に最適化というのは
要するにJIT積んでいればいいわけだから
JITで有名なJavaやC＃からもわかるように
静的言語でも実行時に最適化できるということ。

840 ：デフォルトの名無しさん：2013/10/21(月) 02:25:46.75

静的型付け言語の型って最大何種類あるの？最小は？

841 ：デフォルトの名無しさん：2013/10/21(月) 02:28:16.02

クラスも入れると無限大

842 ：デフォルトの名無しさん：2013/10/21(月) 02:29:29.09

あれ、JITは必要なくCPU毎にコンパイルすればいいんじゃなかったの？？？

843 ：デフォルトの名無しさん：2013/10/21(月) 02:32:09.93

えぇJITよりもCPUごとにコンパイル
したほうが速いですよ？
何も矛盾しませんが。

844 ：デフォルトの名無しさん：2013/10/21(月) 02:32:56.32

JSの実行速度が速いと言っても、JSを何に使うんだろう
スマートフォンの世界じゃHTML5アプリよりネイティブアプリにするだろう
ウェブのサーバーサイドでPHPなんかをNodeが代替するかといえば、一分にそういうケースもあるだろうけど、主流になるとは

845 ：デフォルトの名無しさん：2013/10/21(月) 02:33:40.17

> スマートフォンの世界じゃHTML5アプリよりネイティブアプリにするだろう

お前は、ウェブサイトを全部ネイティブアプリにしたいのか？

846 ：デフォルトの名無しさん：2013/10/21(月) 02:35:29.69

>>843
まだ同じこと言ってんのか
皆が教えてくれてるのに成長しないやつだな

847 ：デフォルトの名無しさん：2013/10/21(月) 02:36:35.01

FirefoxOSというものがあってだな……
JavaScript＝＝ネイティブなんだが……

848 ：デフォルトの名無しさん：2013/10/21(月) 02:36:46.63

>>846
JITが必要な理由と、
速度は別の話だって
わかりませんか？

849 ：デフォルトの名無しさん：2013/10/21(月) 02:37:31.71

実行速度を気にするような複雑なアプリをJSで書く必要性はない
頑張ってHTML5でゲーム作るより、ネイティブで作る方が遥かに簡単で速く動く

850 ：デフォルトの名無しさん：2013/10/21(月) 02:38:58.53

AndroidすらiPhoneよりオーバーヘッドがあって遅いって批判されてるのに、JS使ってたら話にならないと思われる

851 ：デフォルトの名無しさん：2013/10/21(月) 02:40:56.29

ウェブサイトってのはCPUに依存しないように
しなくてはいけないからJavaScriptが必要で
できるだけ速く動かしたいからJITが必要なだけ。
そしてJITは静的言語でも使える。

速度が必要な物が、ネイティブアプリで
作られていることからもわかるように、
速度重視だとコンパイルしてしまったほうが速い。

852 ：デフォルトの名無しさん：2013/10/21(月) 02:41:25.68

それは固定概念って奴だな

853 ：デフォルトの名無しさん：2013/10/21(月) 02:43:05.53

誰か固定じゃない概念を示してやれ。
そうすれば、俺は勝てる。
皆の力が必要だ。

854 ：デフォルトの名無しさん：2013/10/21(月) 02:43:48.52

だからネイティブって何よ？
ひょっとして静的言語のこと？
速度は静的は昔の話になりつつあるってまだ分かんないのかな
そうじゃなかったらFirefoxOSなんて実現するわけ無いでしょ
スクリプトからAPIを叩いて気楽に作る時代なんですよ今は

855 ：デフォルトの名無しさん：2013/10/21(月) 02:44:20.40

隙があるレスすると
すぐにおちょくられるんだから
気をつけたほうがいいよ。

856 ：デフォルトの名無しさん：2013/10/21(月) 02:44:34.43

>>853
皮肉の通じないアスペ乙

857 ：デフォルトの名無しさん：2013/10/21(月) 02:45:32.74

>>854
> だからネイティブって何よ？

CPUが直接実行できる機械語が
生成済みになっているもの。
だからFirefoxOSのJavScriptはネイティブではない。

858 ：デフォルトの名無しさん：2013/10/21(月) 02:46:02.30

>>855
この風潮ホント嫌だよな
盛り上がるにしてももっと和気あいあいといい方向で盛り上がろうぜ

859 ：デフォルトの名無しさん：2013/10/21(月) 02:47:06.60

http://d.hatena.ne.jp/genius_strategy/20130508/1368002653

> この点を踏まえて、3つの OS のネイティブアプリケーションが実行できるかどうかを下表に示す。
>
> OS ネイティブアプリケーションの実行可否
> Android 可
> Firefox OS 不可
> Tizen OS 可

FirefoxOSはネイティブアプリは実行できないみたいだけど？
ネイティブの定義が大幅にずれてる人だね。

860 ：デフォルトの名無しさん：2013/10/21(月) 02:47:12.22

ははあ
じゃあAndroidのJavaはネイティブでは無いのね

861 ：デフォルトの名無しさん：2013/10/21(月) 02:48:14.65

>>859
そういう屁理屈はいいから

862 ：デフォルトの名無しさん：2013/10/21(月) 02:49:49.05

>>860
当たり前だろ？
JSもJavaもJITを使っている以上
ネイティブではない。

Javaは静的言語だが。

さっきから静的言語とネイティブが
ごっちゃになってる人がいるんだよね。

一番速いのはネイティブ＋静的言語

863 ：デフォルトの名無しさん：2013/10/21(月) 02:50:15.01

JavaはネイティブJSは非ネイティブ
それ以上でも以下でもない
まずは用語を勉強してからスレに来なさい

864 ：デフォルトの名無しさん：2013/10/21(月) 02:52:56.80

>>862
Javaはネイティブじゃないって言い張ってるの君だけだね…

865 ：デフォルトの名無しさん：2013/10/21(月) 02:58:34.82

ネイティブっていうのは直接マシン語に変換される言語
JSとかは生まれはインタプリタ言語だったが
今やLLはJITでアセンブラまでコンパイルされるが基本なのでこの分け方は当てはまらない
スマートフォンでネイティブっていうのは所謂インストールしてウィジェットとかある
つまりOSで直接強くサポートされた言語ってこと
例えばwinやMacでのC言語なんかは当にそうと言える
JavaやLLみたいなどこででも動くことを目指した言語は言語としてはそうは言えないが
その環境ではネイティブだと言っていいと思う
そういうことだよね？

866 ：デフォルトの名無しさん：2013/10/21(月) 03:01:11.35

要するにJSやJavaはネイティブじゃないが
AndroidのJavaやFirefoxのJSはネイティブと呼ばれるってことでFAで？

867 ：デフォルトの名無しさん：2013/10/21(月) 03:03:29.77

普通、C#やJavaはネイティブ、PythonやJSはスクリプトって言うんじゃない

868 ：デフォルトの名無しさん：2013/10/21(月) 03:07:30.07

まあネイティブ上で動くっていうイメージの問題でしょうね
本質的には変わりない

869 ：デフォルトの名無しさん：2013/10/21(月) 03:20:48.14

型無しでも型付きでも書けてメソッド毎に静的型付けの強制をオンオフ出来て静的言語Javaで書かれた
資産を直接利用できる動的言語Groovyはなかなか節操がないぞ。

870 ：デフォルトの名無しさん：2013/10/21(月) 03:30:14.87

Java自体が趣味で書くには好きじゃないな
良くも悪くも土方向け言語って感触

871 ：デフォルトの名無しさん：2013/10/21(月) 04:20:24.53

VM上で動くのをネイティブとは言わんだろ

872 ：デフォルトの名無しさん：2013/10/21(月) 04:27:28.77

それは人間から見た視点であって結局は機械語になって動くわけだし
機械語から機械語を動的生成するみたいなのは多かれ少なかれ
どのコンパイル後コードでも内でやってることだよ

873 ：デフォルトの名無しさん：2013/10/21(月) 05:09:43.87

自分の都合で勝手に用語の意味変えるのやめろや

874 ：デフォルトの名無しさん：2013/10/21(月) 05:15:29.72

OSがそのままロードできもしない物をネイティブとは言わん

875 ：デフォルトの名無しさん：2013/10/21(月) 05:18:42.92

>>864
Java Native Interfaceというものがあってだな……

876 ：デフォルトの名無しさん：2013/10/21(月) 05:30:11.69

結局どっち？VM上で動くのもネイティブって言うの？Javaって機種ごとコンパイルとかしないよね。まあ関係ない話題みたいだけど

877 ：デフォルトの名無しさん：2013/10/21(月) 05:33:04.65

静的型付けは、構造というかルール性の事でOK？チューリング完全な言語であれば、その上にVM的に静的型付言語を走らせる事が出来るんだよね、理屈としては
読んでて分からんくなりそ

878 ：デフォルトの名無しさん：2013/10/21(月) 05:37:59.20

>>876
Javaは実行時にclassを解釈するJITコンパイラが間に入ってるから、
ネイティブじゃない

879 ：デフォルトの名無しさん：2013/10/21(月) 05:48:30.72

>>878
ありがとー！
じゃあ動的言語上で動く静的言語がjava？
プログラムソースはテキスト型(でかいchar)って事で瞬間瞬間は静的な動的コンパイル言語？
難しいわ

880 ：デフォルトの名無しさん：2013/10/21(月) 05:49:25.82

>>876-877
勘違いしてるのお前だけだろ

881 ：デフォルトの名無しさん：2013/10/21(月) 05:52:49.53

>>880
分かってないのに口挟んだゴメン。読んでたら気になってさぁ…

882 ：デフォルトの名無しさん：2013/10/21(月) 05:57:13.69

.NETもマネージコードとネイティブコードを区別してるね。
ネイティブがNative Machine Codeの略称だとするなら
コンパイル時に機械語に変換されるものがネイティブっちゅうことになるんかね。

883 ：デフォルトの名無しさん：2013/10/21(月) 05:58:51.77

結局01の組み合わせで動くんだから両者に明確な違いなど無いよ

884 ：デフォルトの名無しさん：2013/10/21(月) 06:00:11.67

>>883
食べ物を食べてうんこして死んでいくんだから猿も人間も違いなんてないみたいなｗ

885 ：デフォルトの名無しさん：2013/10/21(月) 06:01:13.23

コンパイル時に機械語に変換されるものがネイティブ
いやいや言葉的にそれはおかしいだろ
OSが強くサポートしている言語がそのOS上でのネイティブだよ

886 ：デフォルトの名無しさん：2013/10/21(月) 06:02:18.23

少なくともコンパイル云々とネイティブかどうかは直接的に関係ない

887 ：デフォルトの名無しさん：2013/10/21(月) 06:05:23.46

>>885
それじゃ足りない
実行コード部分はハードウェアが直接解釈できないと

888 ：デフォルトの名無しさん：2013/10/21(月) 06:12:42.13

>>885
そんな屁理屈がまかり通るなら
AndroidはJavaがネイティブってことになるし
Windowsは.NET、Unixはshがネイティブになるだろ

889 ：デフォルトの名無しさん：2013/10/21(月) 06:15:06.23

いつ機械語に翻訳されるかとネイティブという言葉が結びつかないんだが
それに結局はメモリ確保とかでOSコールするんだからVM上で動いてるのと同じだがな

890 ：デフォルトの名無しさん：2013/10/21(月) 06:15:59.94

>>888
そのとおりなんだが

891 ：デフォルトの名無しさん：2013/10/21(月) 06:20:43.35

>>890
もう詭弁の相手するの面倒だから適当にググった
http://e-words.jp/w/Android20NDK.html

892 ：デフォルトの名無しさん：2013/10/21(月) 06:31:49.00

普段はそんな意味で使わないくせに、なんでこういう時だけ頑ななのかな。

893 ：デフォルトの名無しさん：2013/10/21(月) 06:32:46.48

>>891
簡単に言うと、機械語、VM上で実行されるコード、インタプリタで
実行されるソースコードをネイティブコードと呼ぶんだなあ。
知らなかった。
機械語だけを呼ぶと思ってたわ～。

894 ：デフォルトの名無しさん：2013/10/21(月) 06:33:41.05

プログラマってこんな頑固でいいものなの？
ネイティブとは何かって程度の話題に何百レスも使うスレの住民が
可能性なんて語れるわけないよな
今の環境に固執してるもん

895 ：デフォルトの名無しさん：2013/10/21(月) 07:10:48.55

荒らしてる奴がいるだけだろ

896 ：デフォルトの名無しさん：2013/10/21(月) 07:19:33.90

何かおかしいと思ったら、
HTML5との対比語のネイティブを言ってるのね。
そら文脈依存の言葉を、単独で使っちゃいかんやろ。

897 ：デフォルトの名無しさん：2013/10/21(月) 07:29:56.73

>>894
2chにプログラマの代表が集結してる訳ないだろ。

898 ：デフォルトの名無しさん：2013/10/21(月) 07:39:16.23

>>896
どっからHTML5が出て来た

899 ：デフォルトの名無しさん：2013/10/21(月) 07:46:47.28

>>898
せっかくフォローしてやってるのに…。

900 ：デフォルトの名無しさん：2013/10/21(月) 07:49:54.18

正しさなんてどうでもいいのさ
強弁して押し通すゲームだから

901 ：デフォルトの名無しさん：2013/10/21(月) 08:02:19.79

HTML5だってFFOSならネイティブだ
スマホではアプリの審査とかいろんな特徴上の理由で
ハイブリットアプリとかJavaとHTML5というのを独特に区別してるからな
AndroidではほぼほぼWebアプリと対比したJavaアプリ
iPhoneではほぼほぼWebアプリと対比したo'Cアプリ
のことで単なる代名詞でしか無い

902 ：デフォルトの名無しさん：2013/10/21(月) 08:06:53.71

PerlやPythonがプリインストールされてるLinuxディス鳥では
これらもネイティブだよー

903 ：デフォルトの名無しさん：2013/10/21(月) 08:21:38.11

FFOSではC++もJavaもネイティブじゃないんですね
わかります

904 ：デフォルトの名無しさん：2013/10/21(月) 08:26:22.60

書き換えといて
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AE%E6%AF%94%E8%BC%83

905 ：デフォルトの名無しさん：2013/10/21(月) 08:51:12.29

>>902
暗黙的にアプリとしての視点で言ってるから基本的にそれらは対象外だな

>>903
対象外
OSでサポートされててアプリが作れる言語ってことでいいでしょう
既存のスマホではできることの差、アプリの種類の名称として>>901で定着しちゃってるけど

906 ：デフォルトの名無しさん：2013/10/21(月) 08:55:49.90

>>904
そこでは一般的な実行モデルの話であって
言語がどう呼ばれるべきかとは直接関係ない
当然文脈で異なる

907 ：デフォルトの名無しさん：2013/10/21(月) 09:12:47.04

>>906
そこに書いてある文脈で呼ぶべきだ。

勝手にオレオレ文脈作って
誰も呼んでない適当な呼び方をするんじゃない。

908 ：デフォルトの名無しさん：2013/10/21(月) 09:14:25.90

実行モデルの話をしていたよなぁ？
>>906は何言ってるんだ。

909 ：デフォルトの名無しさん：2013/10/21(月) 12:15:25.76

ここ数ヶ月JSのステマをし続けてる奴がいる
何の目的かは知らないが

910 ：デフォルトの名無しさん：2013/10/21(月) 13:41:52.12

>>905
そういうのをネイティブというのはウェブ界隈での呼び方だぞ
相当狭い世界で生きてるんだな

911 ：デフォルトの名無しさん：2013/10/21(月) 13:54:57.76

狭いも何も最初からスマホの話>>844-847で
FirefoxOSのJavaScriptをネイティブと呼ぶべきかという話題なんだが
だからJavaScriptはネイティブってことで正しいでしょ

912 ：デフォルトの名無しさん：2013/10/21(月) 14:12:09.10

JSをネイティブというのはさすがに違和感あり過ぎる
それより上がないから比較対象もないし

913 ：デフォルトの名無しさん：2013/10/21(月) 14:38:09.64

だからその常識に挑戦するのがFFOSなんだって
FFOSでだってブラウザ上で動くアプリとパッケージアプリは区別されるべきだし
スマホ一般で言うにはネイティブと言っておけばいいでしょ
ユーザーから見たら変わらないわけだし

914 ：デフォルトの名無しさん：2013/10/21(月) 14:40:48.72

お前らばか？
そんなコンテキストによって意味が変わる言葉の意味についてコンテキスト決めずに論争してもしょうがないだろ。
せめてこのスレではこの意味で使おうというならまだしも。

915 ：デフォルトの名無しさん：2013/10/21(月) 14:43:25.56

ユーザーから見たら詐欺だろ

916 ：デフォルトの名無しさん：2013/10/21(月) 14:48:40.06

ユーザーだけではなく開発者の視点から見ても同じ

917 ：デフォルトの名無しさん：2013/10/21(月) 14:51:18.87

スマホでネイティブアプリと言ったらインストール可能なアプリ程度の意味しかない
ほぼWebViewだけのものとか大いにあるし

918 ：デフォルトの名無しさん：2013/10/21(月) 14:53:58.95

それをネイティブとは言わん

919 ：デフォルトの名無しさん：2013/10/21(月) 14:56:14.63

現にそう使われてるから
今使われてるものに当てはめるなら言えるでしょ

920 ：デフォルトの名無しさん：2013/10/21(月) 14:58:56.53

どうせポシャるプラットフォーム上でJavaScriptやHTML5がネイティブだとか
どうとか実にどうでも良い。

というかJavaScriptやHTML5がネイティブだとか粘着し続けているのJSerという
か単なるMozilla厨かよ。
前置きもなくFFOSとか略されたところでそれが世間一般に普通に通じると思って
いるのならかなり痛い認識だぞ。

921 ：デフォルトの名無しさん：2013/10/21(月) 14:58:57.81

いや言わないって
WevViewアプリがネイティブならSenchaやMonacaのアプリもネイティブだろ

922 ：デフォルトの名無しさん：2013/10/21(月) 15:00:30.47

インストール型Webアプリだとブラウザアプリのこと指すし
ネイティブWebアプリだとハイブリットアプリのことを指すし
素直にネイティブアプリと呼ぶのが一番じゃないかと思う

923 ：デフォルトの名無しさん：2013/10/21(月) 15:00:30.95

>>921
typo
s/WevView/WebView/
それと>>921は>>919へのレス

924 ：デフォルトの名無しさん：2013/10/21(月) 15:01:54.53

OS自身の記述言語がネイティブてある。

「OS」の指す範囲は各自定義してね。

925 ：デフォルトの名無しさん：2013/10/21(月) 15:01:55.97

>>922
ハイブリッドはハイブリッドだろ
ってか自分でハイブリッドって言ってるのに変だと思わないのかｗ

926 ：デフォルトの名無しさん：2013/10/21(月) 15:02:34.43

>>921
それらは出力形態としてはハイブリットアプリ

927 ：デフォルトの名無しさん：2013/10/21(月) 15:04:23.54

>>925
いいや、ネイティブアプリでいいのよ
屁理屈こねない

928 ：デフォルトの名無しさん：2013/10/21(月) 15:08:34.02

>>927
そこまで意味を拡張してしまったら
ネイティブという用語そのものに必要性ないだろｗ
馬鹿すぎて話にならないｗ

929 ：デフォルトの名無しさん：2013/10/21(月) 15:57:00.09

ハイブリットアプリだけは120％ないだろ…
形式が一番近いのはブラウザアプリ、というかほぼまんまで
ブラウザがOSと融合してVM的な機能も提供してるんだから
普通に考えたらネイティブアプリと呼ぶでしょ
どれだけ妥協してもネイティブアプリの風格を持ったブラウザアプリってとこだわ

930 ：デフォルトの名無しさん：2013/10/21(月) 16:01:08.92

プラットフォームがある機能のネイティブサポートをうたうのは単体の出荷状態で
その機能に対応している場合。

なのでFirefoxOSはJavaScriptをネイティブサポートしているといって良い。
だけどそれを走らせるARMだか何だかのCPUにとってJavaやJavaScriptはネイティブ
サポートの対象じゃないね。別途JVMなりJSエンジンが必要。

成果物に関して「ネイティブ」と呼ぶのはプラットフォーム横断的な実行環境との
比較で特定プラットフォーム向けに書かれたものをさすと思うけれども。
なのでJavaScriptで書かれたFirefoxOS向けのアプリはネイティブアプリかな。
ただそれを走らせるCPUにとってはネイティブでも何でもないね。

931 ：デフォルトの名無しさん：2013/10/21(月) 16:01:38.26

ネイティブ（アプリの風格を持ったブラウザ）アプリ
ってことでこの話はもういいよ

932 ：デフォルトの名無しさん：2013/10/21(月) 17:28:36.32

LinuxではshとPerlとPythonはネイティブって結論でいいよね？

933 ：デフォルトの名無しさん：2013/10/21(月) 17:38:02.75

NO
アプリとして一般的か否かは重要
所謂シェルスクリプトはシェルスクリプト

934 ：デフォルトの名無しさん：2013/10/21(月) 18:10:06.97

プラットフォームに特化した言語をネイティブっていうんだろ
他のプラットフォームでも使えたらネイティブとは言わない

935 ：デフォルトの名無しさん：2013/10/21(月) 18:56:30.23

>>933
一般的かどうか、どうやって決めたの？
主観？

936 ：デフォルトの名無しさん：2013/10/21(月) 18:59:48.85

ネイティブコード＝機械語は昔からある用語

ネイティブアプリ＝非ウェブアプリは
ブラウザアプリが増えて区別するために作られた新しい用語

937 ：デフォルトの名無しさん：2013/10/21(月) 19:04:06.51

ネイティブコードにコンプレックス持っちゃったドカタが
ネイティブじゃ無いものをネイティブって呼び出したのが起源

938 ：デフォルトの名無しさん：2013/10/21(月) 19:38:54.94

>>936
そうそう
で、この話題は最初からそっちの方向で話し合われてる
言語ではなく環境も含んでの話だからね

939 ：デフォルトの名無しさん：2013/10/21(月) 19:42:06.94

そんなことはどうでもいいから技術について語ろうぜ
例えばJSONってどうよ

940 ：デフォルトの名無しさん：2013/10/21(月) 20:01:07.91

JSはソースコードがネイティブコードなので超速い。
Cはコンパイルして機械語でやっとネイティブコードなので遅い。

941 ：デフォルトの名無しさん：2013/10/21(月) 20:14:21.23

同じこというやつに突っ込むのだけはやめろよ

942 ：デフォルトの名無しさん：2013/10/21(月) 20:26:00.40

どう見ても荒らしたいだけだから突っ込むのやめた方がいいな

943 ：デフォルトの名無しさん：2013/10/21(月) 20:49:47.85

突っ込む気力すらない

944 ：デフォルトの名無しさん：2013/10/21(月) 20:51:23.76

JIT以前はC言語が速かった
JITの登場でスクリプトのほうが速くなった

945 ：デフォルトの名無しさん：2013/10/21(月) 20:53:25.71

どうせマイクロベンチでしか比較できんだろ
適当なベンチサイトでも見て遊んでろ

ttp://benchmarksgame.alioth.debian.org/

946 ：デフォルトの名無しさん：2013/10/21(月) 21:02:59.70

JSの実行速度は十分、それよりも64bit型とかが必要だし
なんといってもボトルネックなのはDOM操作だから

947 ：デフォルトの名無しさん：2013/10/21(月) 21:08:06.93

もっとIDEを強化すべきだと思う
ドカタ = IDE の図式

948 ：デフォルトの名無しさん：2013/10/21(月) 21:08:50.89

>>939
もっとJSONスキーマを使えるインフラが流行って良い。

949 ：デフォルトの名無しさん：2013/10/21(月) 21:11:09.80

JSONはハッシュのキーに文字列しか使えないところが
最高にうざくて頭悪い

950 ：デフォルトの名無しさん：2013/10/21(月) 21:42:31.37

この前循環参照含むオブジェクトを文字列化できないのかできないかって質問がJS質問スレであって
循環参照を解いたオブジェクトに崩してからJSON化するってので乗り切ってた
確かにJSONは表現能力もそこまで高くないし、それよりもスキーマがかっちりしてないって言うのを見るけど
ちょっと追加パーサー書けばそれなりの拡張は容易だと思う
それよりも取り敢えずシンプルで組み込みやすいって方をとったんじゃないかな

951 ：デフォルトの名無しさん：2013/10/21(月) 22:17:08.08

拡張が容易って・・・JSONの拡張?

952 ：デフォルトの名無しさん：2013/10/21(月) 22:22:40.01

そもそもJSONは規格なんで
勝手に拡張してはいけませんねぇ。
循環参照あるならYAMLを使うべきでしょ。

953 ：デフォルトの名無しさん：2013/10/21(月) 22:24:35.48

循環参照なんてルートに一段かませて
そこに接続してるパス書けばいいだけじゃないの

954 ：デフォルトの名無しさん：2013/10/21(月) 22:39:12.74

JSONの拡張じゃなくて例えば複雑な型が使いたいのなら
{
"type-string":"aaaa"
"value-string":"bbbb"
}
みたいにするとか、アプリケーション側でカバーできるってこと

あんまり高機能だとあらゆる環境での共通フォーマットにはしづらいでしょ

>>953
どういうこと？気になる

955 ：デフォルトの名無しさん：2013/10/21(月) 22:47:44.32

>>954
複雑さの先送りがあとあと効いてきそうな感じ…

956 ：デフォルトの名無しさん：2013/10/21(月) 22:53:49.16

>>954
{
　"object": { 本来のデータ },
　"cyclicRef": [ { "from": ["path"],"to":["path"]}, ... ]
}

>>955
複雑にして失敗したのがXMLだよ

957 ：デフォルトの名無しさん：2013/10/21(月) 23:24:31.54

こんな感じだな
http://ideone.com/Zxp7kN
変換後の文字列も少なくていいと思う
このままだと配列がオブジェクトになってしまうが
それ以外はJSONのパワーアップ版だ

958 ：デフォルトの名無しさん：2013/10/21(月) 23:34:24.58

>>956
そもそも循環参照を持つのはJSON化出来ないのよ
だから本物のデータとやらをJSON.stringifyで文字列化出来ない
だから例の質問では（ライブラリフリーで）一番効率の良い方法として
循環参照のない形にほぐしてJSON化するという手を取った

959 ：デフォルトの名無しさん：2013/10/22(火) 00:24:44.59

>>957
配列に対応しておいた

960 ：デフォルトの名無しさん：2013/10/22(火) 06:19:45.24

>>958
>そもそも循環参照を持つのはJSON化出来ないのよ
>だから本物のデータとやらをJSON.stringifyで文字列化出来ない
いやそれぐらいわかって書いてるよ
元のレスじゃ循環参照を元に戻すとは言ってなかったから

961 ：デフォルトの名無しさん：2013/10/22(火) 06:58:11.85

>>953のレス書いた奴がそんなこと言うんだ
笑えるね

962 ：デフォルトの名無しさん：2013/10/22(火) 07:18:33.30

>>961
え？なんで急に発狂した？

963 ：デフォルトの名無しさん：2013/10/22(火) 07:30:31.76

FilerMakerで1日　＜＜＜　C#ポトペタ+NuGetで1週間　＜＜＜　HTML5+Ruby,PHP,Javaで1ヶ月
http://engawa.2ch.net/test/read.cgi/poverty/1382394266/

964 ：デフォルトの名無しさん：2013/10/22(火) 07:42:55.09

寝起きで頭がまわらないのは理解するがもう少し良く読みよく考えてから書き込んでくれな

965 ：デフォルトの名無しさん：2013/10/22(火) 07:57:05.69

話ぶった切るけどJSONの妥当性検証ってどうしてる?

* JSONスキーマ
* JSONマッパー提供のバリデーション機能
* アプリケーションロジック内でなんとなく
* その他

966 ：デフォルトの名無しさん：2013/10/22(火) 08:04:27.48

>>964
説明する気もないなら黙っとれ

967 ：デフォルトの名無しさん：2013/10/22(火) 08:13:56.30

JSONスキーマ一択

968 ：デフォルトの名無しさん：2013/10/22(火) 08:14:29.00

>>965パース関数にかけて通れば妥当
TwitterのStreamingAPIみたいに断片で続けて送られて来るときはもはやそうするしか無い

969 ：デフォルトの名無しさん：2013/10/22(火) 08:40:31.99

>>968
検証できるよ。

970 ：デフォルトの名無しさん：2013/10/22(火) 08:47:56.99

うん、だからパース関数にかけてみればいいよね

971 ：デフォルトの名無しさん：2013/10/22(火) 09:17:26.46

>>970
うん、だから正当なJSONであるだけじゃなく、
データ構造の妥当性の検証もできるよ。

972 ：デフォルトの名無しさん：2013/10/22(火) 13:56:44.32

灘高校生
http://uni.2ch.net/test/read.cgi/newsplus/1382414731/
「いまさらエクセルを学ぶより、プログラミングを学ぼう。できて当たり前の時代が来る」

973 ：デフォルトの名無しさん：2013/10/22(火) 14:22:26.61

>>970
well-formedとvalidはちがうやろ

974 ：デフォルトの名無しさん：2013/10/22(火) 17:13:33.47

JSONの妥当性と言ったらフォーマットの妥当性の様に聞こえる

975 ：デフォルトの名無しさん：2013/10/22(火) 18:33:23.89

例としてJSONスキーマやアプリケーションロジックでのバリデーションをあげているので
well-formedではなくvalidのチェックだと解ると思うけど。

976 ：デフォルトの名無しさん：2013/10/22(火) 18:36:24.96

HTML5/WebアプリってVBアプリの工数10倍かかるのにの人月1/2だよね。見積書いてる奴バカなの？
http://hayabusa3.2ch.net/test/read.cgi/news/1382432343/

977 ：デフォルトの名無しさん：2013/10/22(火) 18:50:42.69

それJSONあんま関係なくね

978 ：デフォルトの名無しさん：2013/10/22(火) 19:00:49.05

次スレは？

979 ：デフォルトの名無しさん：2013/10/22(火) 19:40:36.94

コンビニのレジと同じくらいの給料なんじゃないの？

980 ：デフォルトの名無しさん：2013/10/22(火) 22:13:50.77

これ今月のスレかよ
むっちゃ伸びてんな

981 ：デフォルトの名無しさん：2013/10/22(火) 23:56:53.88

>>839
そう。このスレでは動的型付けと動的最適化がごっちゃになってる。

982 ：デフォルトの名無しさん：2013/10/23(水) 10:36:01.41

次スレそろそろ要らないな

983 ：デフォルトの名無しさん：2013/10/23(水) 19:02:30.06

>>839
JavaもC#もJITは言語レベルよりずっと下の
静的型付けとか関係ないレイヤで行われるんだけど？

984 ：デフォルトの名無しさん：2013/10/23(水) 19:19:07.44

だから何？

985 ：デフォルトの名無しさん：2013/10/23(水) 19:37:05.58

結局静的言語ならではの何かなんて語るほど無いってことなんだからスレタイが悪いんでしょ
次スレ建てるんなら「プログラミング言語の潜在開発生産性は今の100倍」とかにしてね

986 ：デフォルトの名無しさん：2013/10/23(水) 19:39:48.61

>>985
だから動的は糞て静的関数型の方が遥かに生産性がいいってFAでてんじゃん(´・ω・｀)

987 ：デフォルトの名無しさん：2013/10/23(水) 20:09:43.82

JavaScriptは糞って一応の結論は出た形かな

988 ：デフォルトの名無しさん：2013/10/23(水) 20:31:19.12

JSがクソだから動的型付けはクソっていうなら、
Cがクソだから静的型付けはクソってのと同類だな

989 ：デフォルトの名無しさん：2013/10/23(水) 20:37:14.27

>>1の
＞コンピュータがコードの意味を正確に認識できる方法が必要。
＞実行しないとわからないことはコンピュータは認識できない。
＞静的型付け言語であれば、実行しなくてもわかるのでコンピュータが理解できる。
＞そうすれば様々なコンピュータの高度な情報支援が得られる。

は要するにIDEの、コードを書く時の場合だけど
IDEが100倍も良くなることなんてあるの？
今で十分だと思うんだけど、この辺りが語られてない

あとは最適化についてはそこそこ語られたけど
開発ってのは書いてコンパイルして終わりじゃなくて
もっと運用とかの面も入れたほうがいいと思うから

次スレではそういうとこ話そう

990 ：デフォルトの名無しさん：2013/10/23(水) 20:44:35.91

開発効率を上げる方法について語るスレでええな

991 ：デフォルトの名無しさん：2013/10/23(水) 20:58:10.06

実質はJSを褒め称えるスレなんだけどね。

992 ：デフォルトの名無しさん：2013/10/23(水) 21:34:00.12

JSのエンジンが凄いという話は出たがJSが凄いという話は出てないし
そもそも特定の言語について語るスレではない
どの言語がいいかではなく言語を使うときの開発力向上について話すスレだ

993 ：デフォルトの名無しさん：2013/10/23(水) 21:52:38.30

という建前で、JSを褒め称えるスレなんだけどね。

994 ：デフォルトの名無しさん：2013/10/23(水) 22:01:04.82

というのは幻想で、現実は貶されとそのフォローしか無かったけどね

995 ：デフォルトの名無しさん：2013/10/23(水) 23:50:43.97

>>993
信者のキモいマゾっぷりがさらけ出されただけだがな(´・ω・｀)