13/05/03 13:55:49.86
JavaScript, Perl, PHP, Python, …
スクリプト言語をすべて扱うスレッドです。
最強のスクリプト言語は、どれよ？
さあ、死ぬまで語りやがれ！！！
■ スクリプト言語の用途
簡易Webアプリ、シェルスクリプト
■ スクリプト言語の特徴
1レスで書ける程度の使い捨ての短いコードなら作成が容易だが
実行速度は劣っており、2人以上の開発、1000行を超えるソースコード、
10ファイル以上からなるソースコード、大規模になればなるほど
修正時の影響範囲の把握が困難で簡単なスペルミスが
発見しづらいバグを生み、IDEなどの静的解析ツールの適用が難しく
何から何まで人手でやらなければならずプログラマの負担が大きい。
・インタプリタ
・動的型
・正規表現
・クロージャ
などを利用できるものがある。
1レスには収まらないが100行程度の短いコードはここで
URLﾘﾝｸ(play.island.ac)
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
13/05/03 13:57:29.26
>>1
乙
3:デフォルトの名無しさん
13/05/03 13:59:38.86
さりげなくスレタイからRubyを抜くなw
4:デフォルトの名無しさん
13/05/03 14:00:06.41
残念入らなかった。
5:デフォルトの名無しさん
13/05/03 14:16:25.04
前スレ>>999
> リスト内包は集合論とかの数式を見慣れた人には分かりやすいよね
短い場合はそうだと思うけど、
長くなった場合は見にくいよ。
多分その理由は思考の流れと逆に書くからだと思うな。
ディレクトリのように、前から絞り込んでいくやりかたと
後ろから絞り込んでいくやり方がある。
長い場合は、前から絞り込むほうが理にかなっている。
例えばドメインは、後ろから絞り込んでいくやり方だけど
パスの部分は前から絞り込んでいくやり方になってる。
住所を真似して後ろから絞り込んだのはいいが、
途中（パスの部分）で破綻したのではないかな。
GUIのメニューやCSSのセレクタも前から絞り込んでるね。
英語の文化のせいで後ろから絞り込むやり方が存在するけど、
論理的に考えたら前から絞り込むほうがいいのだろう。
日本語は基本的に前から絞り込む文化。
6:デフォルトの名無しさん
13/05/03 14:21:00.60
リスト内包表記
[x * 2 for x in A if x % 2 == 0]
前から絞り込む発想だとこうなっていただろう。
[for x in A if x % 2 == 0 x * 2]
境目がわかりにくいという問題を解決すると・・・
[for(x in A) if(x % 2 == 0) x * 2]
面白いことに、既存の文法に近い形になってしまう。
7:デフォルトの名無しさん
13/05/03 14:21:21.95
>>1は勝手に内容を変えてんじゃねーよ
スクリプト言語に対する偏見が強すぎるわ
ていうか、前スレでコード書けなかったアホだろ>>1は？
「俺はコード書くほど暇人じゃない」とか言っといて
わざわざ文章改悪してスレ立てまでやってんのかよ
ビックリするほど暇人じゃねーか
8:デフォルトの名無しさん
13/05/03 14:22:33.50
少し修正
[for (x in A) if (x % 2 == 0) x * 2]
9:デフォルトの名無しさん
13/05/03 14:29:01.90
>>8で思ったんだけど
[x * 2 for (x in A) if (x % 2 == 0)]
こう書いたほうが見やすくね？
10:デフォルトの名無しさん
13/05/03 14:31:40.77
こうじゃねーの？
[x * 2 for (x in A if (x % 2 == 0) )]
11:デフォルトの名無しさん
13/05/03 14:35:46.46
>>5
数学の素養の無いドカタは
無理に内包表記を使う必要は無いよ
12:デフォルトの名無しさん
13/05/03 14:39:26.51
>>11
典型的だね。
何も言えないから、とりあえず馬鹿にして満足感を得る。
13:デフォルトの名無しさん
13/05/03 14:41:17.84
別にどれも変わらねーよ
くだらねえなあ
次いでに普通のforでも変わらねーよ
14:デフォルトの名無しさん
13/05/03 14:47:48.89
リスト内包表記の方が効率が良い
入れ子は避けるべきだが、ここで挙がってるのは論外
リスト内包表記をディスるためにわざわざ一つの式を格好で括るとか
少なくともpythonではないな。前スレでC的な書き方が分かりやすくて良いとか言ってたC脳だろうが
15:デフォルトの名無しさん
13/05/03 14:49:59.75
効率が効率がって、公式実装がC言語の100倍遅い言語で言われましてもw
16:デフォルトの名無しさん
13/05/03 14:50:06.04
効率は変わらんよｗ
17:デフォルトの名無しさん
13/05/03 14:50:28.57
集合は {x| x は偶数 } って書くから x が左に来てないとすわりが悪いかな
18:デフォルトの名無しさん
13/05/03 14:51:39.00
うーん、そういう文脈でCを使われるのはなぁ
C使う人間の全てがアホではないよ
前スレのアホは底なしの低能だが
19:デフォルトの名無しさん
13/05/03 14:51:49.98
haskellの内包表記こそが至高
forなどというキーワードを使うpythonは数学に慣れてると見にくい
20:デフォルトの名無しさん
13/05/03 14:52:17.98
>>17
だから>>11でFA
21:デフォルトの名無しさん
13/05/03 14:52:57.72
>>18
視野が狭いと文脈違いに見えるよねえw
22:デフォルトの名無しさん
13/05/03 14:55:35.63
リスト内包表記はリストを返すが、繰り返し文でリスト末尾に追加していくより効率が良い
条件分岐がある場合、最初に必要な長さを指定して確保しておくことはできない
23:デフォルトの名無しさん
13/05/03 14:57:00.00
>>20
>>11
典型的だね。
何も言えないから、とりあえず馬鹿にして満足感を得る。
24:デフォルトの名無しさん
13/05/03 14:57:22.17
どうだろう双方向リストなら末尾付加のコストは普通に定数だよね
25:デフォルトの名無しさん
13/05/03 15:00:23.70
{x| x は偶数 }
なんでこんな単純なものが
[x for x in A if x % 2 == 0]
こんな風に複雑になるのかね？
[x | isEven(x) ]
ここまで単純化してやっと
数学っぽいといえると思うんだが？
26:デフォルトの名無しさん
13/05/03 15:00:37.91
ジェネレータ式の効率が良すぎてどうでもいい
27:デフォルトの名無しさん
13/05/03 15:01:05.20
ちょっと簡潔にかけるとか数学に似てるとか
つまんないことで満足してればいいよ
28:デフォルトの名無しさん
13/05/03 15:03:01.51
上で言われてるようにジェネレータにもできるからメモリ効率も良い使い方ができる
>>24
関数呼び出しのコストがあるのでオーダーで考えてるんだろうけど実際は係数って無視できないくらい効いてくるので。
29:デフォルトの名無しさん
13/05/03 15:03:23.98
>>25
それなら見やすいと思うね。
でもごちゃごちゃしていたら見にくい。
そこが内包表記の限界なのだろう。
30:デフォルトの名無しさん
13/05/03 15:04:38.96
>>28
定数オーダーの末尾付加によるリストの作成が無視できないような状況で
pythonとかって、あんまり想像がつかないんだけど
31:デフォルトの名無しさん
13/05/03 15:05:24.86
内包表記は数学の式まで完結化できる
pythonの場合はfor文を使えるようにしてる
32:デフォルトの名無しさん
13/05/03 15:05:25.97
>>25
え？式の外でdomainを明示してるんじゃなかったら
数学でもdomainを書く必要があるよ？
33:デフォルトの名無しさん
13/05/03 15:06:05.81
>>28
> 上で言われてるようにジェネレータにもできるからメモリ効率も良い使い方ができる
ループで回してもメモリ効率いいと思うけど？
本質的には値を入れた配列を作らずに
値を計算で求めるってだけだし。
34:デフォルトの名無しさん
13/05/03 15:06:41.46
>>30
リスト内包表記を使った方が効率が良いという話
実際に比べればわかるし、内包表記を使わない理由がないのだが
35:デフォルトの名無しさん
13/05/03 15:07:12.47
>>32
なら書けばいいのでは？
36:デフォルトの名無しさん
13/05/03 15:08:32.57
{x| x∈A ∧x≡0 (mod 2)}
これが数学かな
37:デフォルトの名無しさん
13/05/03 15:09:21.71
>>33
ジェネレータ関数について勉強しなおせ
38:デフォルトの名無しさん
13/05/03 15:09:58.06
>>34
その効率の良さも無視できるレベルって話
ジェネレータも呼び出しを遅延させてるだけで
実際はそんな便利な場面は少ない
39:デフォルトの名無しさん
13/05/03 15:11:51.52
お前が無視したいだけだろw無視する意味がわからん
itertoolsと組み合わせて使いどころありまくりだわ
40:デフォルトの名無しさん
13/05/03 15:12:36.31
これも数学だよね？
{x| x は A に含まれる かつ x は 2で割った時のあまりが0}
何が言いたいかというと、数学は記号を使っているから
見やすいのであって、それを言葉（日本語英語関係ない）に
するととたんに見づらくなるということ
41:デフォルトの名無しさん
13/05/03 15:14:15.07
>>37
勉強しなおしたが答えは同じだった。
はい、君のターン
○○しろとかいって、自分のターンを飛ばすやつ多いよねｗ
42:デフォルトの名無しさん
13/05/03 15:14:51.25
>>40
慣れの問題
43:デフォルトの名無しさん
13/05/03 15:14:51.82
ぼくのかんがえた究極数学猿真似言語
{x| x (- A /\ x _= 0 (mod 2)}
44:デフォルトの名無しさん
13/05/03 15:17:53.86
var x = [];
for(i=0; i < A.length; i++) {
if(i % 2) {
x.push(i);
}
}
まあこれでなんの問題もないし、読みやすいし
パフォーマンスもpythonより速いよ
45:デフォルトの名無しさん
13/05/03 15:18:53.97
>>42
うん。だから
頭から絞り込む方法も
後ろから絞り込む方法も
所詮慣れでしかないんだよ。
で、何故か世の中の多くは
頭から絞り込んでいく方法。
多くの人が慣れているのは
頭から絞り込む方法だってことさ。
数学かどうかは、記号を使うかどうかだから
記号を使って頭から絞り込むのが一番見やすい。
46:デフォルトの名無しさん
13/05/03 15:19:13.29
>>35
情報量が違う式を比べて「数学と比べて複雑」とか言ってるアホ(>>25)が滑稽だなって
やっぱりドカタはそういう基本的な事が分からないんだね
47:デフォルトの名無しさん
13/05/03 15:20:18.72
>>46
だから合わせればいいじゃん。
48:デフォルトの名無しさん
13/05/03 15:23:10.02
>>44
これのほうが良い。だんだん内包表記に似てきたね。
for(i in A) if(isEven(i)) x.push(i);
49:デフォルトの名無しさん
13/05/03 15:24:41.91
>>44
遅いのだが…
50:デフォルトの名無しさん
13/05/03 15:25:00.24
>>48
正直、何 が 良 い の か 分 か ら な い
全く同じだろ？
ちょっと簡潔になってるだけだろ
そんなくだらない上っ面だけ見て満足なの？
51:デフォルトの名無しさん
13/05/03 15:25:32.97
>>49
V8エンジンなら最適化されてるから、CPythonより速い
52:デフォルトの名無しさん
13/05/03 15:26:08.24
forやifの一行でも必ず {} でくくること
という変なコーディング規約をなくせば
内包表記とほとんど変わらなくなる。
もっとも必ず {} でくくること。の理由にも
賛同できるので、
{}でくくらない場合は一行で書くこと
改行を入れるときは必ず{}でくくること。
というコーディング規約を推奨する。
53:デフォルトの名無しさん
13/05/03 15:26:21.56
>>48みたいな糞コードを量産するねがJS厨だなあ
54:デフォルトの名無しさん
13/05/03 15:27:04.83
>>50
え？ 完結に書くことは重要だよ。
それだけ読む量が少ないってことだから。
55:デフォルトの名無しさん
13/05/03 15:27:39.69
>>53
やっとこのスレに気づいたか
いつものアンチJS厨さんよぉｗ
56:デフォルトの名無しさん
13/05/03 15:28:26.78
>>54
文字数・行数の少なさと、理解する量の多さは違う
読む量(理解量みたいなもの)と理解するスピードは、
少なくとも俺の場合はほぼ全く一緒なのだが
57:デフォルトの名無しさん
13/05/03 15:28:30.29
一行に複数のブロックがあるから気持ち悪いんだな
その場合、結果が先行して書かれた方がわかりやすい
58:デフォルトの名無しさん
13/05/03 15:30:34.64
>>52
リスト内包表記に嫉妬しすぎ。お前の代替案は醜すぎ
59:デフォルトの名無しさん
13/05/03 15:32:23.60
>>56
100行コードを読むのと、それを関数にして読む場合の
理解のスピードが同じだって？
じゃあお前は関数使うなｗ
知識を使って読むべきコードを減らすのが関数の利点。
一連のコードを知識に置き換えることで読む量を減らす。
lengthまでiをインクリメントしていく。をinの一言で、
(i % 2)==0 を isEvenの一言にすることで、
読むべきコードを減らして、理解するスピードをアップさせている。
60:デフォルトの名無しさん
13/05/03 15:32:51.60
例えば
if (x % 2 == 0) {
hoge;
}
と
if (x % 2 == 0) hoge;
では後者がいいとかって話と一緒
どっちが早く理解できるか競争する大会があったとして、出場者の平均タイムは
どっちも同じだわいみたいなw
61:デフォルトの名無しさん
13/05/03 15:33:54.43
>>59
意味のあるときは関数使うよ
でも、今回の場合、難解度に差はない
62:デフォルトの名無しさん
13/05/03 15:34:00.18
>>57
> その場合、結果が先行して書かれた方がわかりやすい
それは慣れの問題だってさ。
英語と日本語の問題と話が全く一緒になった。
結論を頭に持ってくるのが英語風
結論を最後に持ってくるのが日本語風
>>58
醜すぎの理由が書いてない時点で、お前の嫉妬にしか見えんな。
63:デフォルトの名無しさん
13/05/03 15:35:24.32
>>60
Perlだと両方かけるよね。
if (x % 2 == 0) hoge;
と
hoge if (x % 2 == 0);
どっちもコンパイルに通る。
この二つに違いはない。
64:デフォルトの名無しさん
13/05/03 15:37:24.79
内包表記はfor文を簡潔にするけど、複雑な処理まで簡略化はしてくれない
結果、上っ面が簡潔になっただけで、たいして理解力は向上していない
65:デフォルトの名無しさん
13/05/03 15:38:45.87
x % 2 == 0 は慣用句になってるけど
普通は関数にしたほうが読みやすいよ。
「フィボナッチ数列」と一言いうだけで
どんな数列かわかるだろう？
この数式なんだっけ？
あぁ、フィボナッチ数列か。
みたいな考える時間が要らなくなる。
66:デフォルトの名無しさん
13/05/03 15:42:57.74
>>63
Perlでは前者は{}必須
67:デフォルトの名無しさん
13/05/03 15:43:46.06
複雑な処理を簡潔にする魔法があるのかよ
上っ面とは物は言い様だな。それぞれのパーツを簡潔にするのが唯一の方法だし
pythonは設計も習慣もそういうスタンス
めちゃくちゃなJSが何か言ってることに非常に違和感がある
68:デフォルトの名無しさん
13/05/03 15:49:27.50
>>65
結局そこなんだよ
ぶっちゃけ、for文が長いと言っても慣用句なんだよ
長い慣用句を簡潔な単語で表したところで、
理解力は上がらないんだよ
タイプ量が少なくて済むけど、コピペとかsnippetとかもあるしねえ
69:デフォルトの名無しさん
13/05/03 15:51:52.73
>>67
なにいってんだばか？
処理を実行するのはコンピュータ
正確だから処理が複雑かどうかは関係ない。
人間にとって重要なのは、その処理を
どれだけ簡素に見せられるかどうかだろ。
お前はコンピュータか？人間か？言ってみろ。
70:デフォルトの名無しさん
13/05/03 15:53:20.02
>>65
関数化よいよね。しかしアホには限界が…
ちなみにipythonでallclose？と入力したらヘルプが表示されるから安心
986/1001:デフォルトの名無しさん[sage]
2013/05/03(金) 10:13:47.88
>>985
しかし現実は
「allclose？mean？axis？arrayで囲ってる？xsとys交換してから比較？linalg？norm？」
Pythonのコードは知的教養レベルが高い人が抽象的な言葉でわけのわからん議論をしてるのに
似てるw
ただ、その割には他の言語でもたいして大変じゃないんだよなあ
71:デフォルトの名無しさん
13/05/03 15:55:04.88
>>67
魔法なんてないよ
だから、大差はない
結局ライブラリの差
pythonは今のところ数値計算のライブラリは揃っているけど
内包表記やらが優れているわけではない
72:デフォルトの名無しさん
13/05/03 15:55:12.87
>>68
おいおい、お前の言ってる「長い」は
せいぜい20文字ぐらいで限界だろうがw
73:デフォルトの名無しさん
13/05/03 15:58:09.28
>>71
当たり前だろ。りすとこんぷりへんしょんなんて今日びまともな言語なら必ず備えてる
標準的な便利機能でしかない。それをできない言語が劣ってるだけ
for文のように書けるというのはよく考えられてるけどね
74:デフォルトの名無しさん
13/05/03 15:59:39.26
内包表記もインデックス演算子のオーバーロードもipythonの使い易さも
それぞれは小さい、人によっては無視できる程度の違いにすぎない。
しかし、そういう物の積み重ねがアルゴリズムを記述したいユーザをPythonに引きつけ、
Pythonにはnumpy, scipyを作るようなユーザが集まる一方で、
Javascriptにはnumpyが産まれる兆しすら無いのに繋がっている。
75:デフォルトの名無しさん
13/05/03 16:00:18.74
>>73
１．それが出来ない言語とは？
２．それが出来ない言語で簡単にかけない例は？
（ライブラリを使って簡単にかけることなら却下）
この二つを説明できて
初めて説得力があるというもの。
76:デフォルトの名無しさん
13/05/03 16:00:49.01
>>73
お前、天才集団Googleさんに喧嘩売ってるの？
77:デフォルトの名無しさん
13/05/03 16:01:04.23
>>74
と思いたいんだねぇ。
あっはっはｗ
78:デフォルトの名無しさん
13/05/03 16:01:42.26
>>74
兆しはあるよ
あと二年後には多分ある
79:デフォルトの名無しさん
13/05/03 16:02:17.99
演算子のオーバーロードなんていらねえ！
リスト内包表記なんていらねえ！
Cのように書けば良い！
>>75
このスレに挙がってるリスト内包表記の代替案とかw
挙げ句にわざわざ醜くしてリスト内包表記に似せる始末
80:デフォルトの名無しさん
13/05/03 16:04:27.32
JavaScriptで生まれてるのは
ゲームやウェブアプリやウェブシステムだからな。
そういう人たちを惹きつける言語というわけか。
81:デフォルトの名無しさん
13/05/03 16:04:37.01
二年後って、JSはずいぶん遅れてるんだねえ。まあそれもお得意の妄想だろうけど
ともかく未来にすがるしかないなんて現在の現実ではどうしようもない糞言語なんだろうな
82:デフォルトの名無しさん
13/05/03 16:05:42.53
>>79
> このスレに挙がってるリスト内包表記の代替案とかw
> 挙げ句にわざわざ醜くしてリスト内包表記に似せる始末
へ？ 普通の書き方じゃね？
うーん、何処にも変な所が見られない。
for(i in A) if(i % 2 == 0) x.push(i);
83:デフォルトの名無しさん
13/05/03 16:06:18.49
>>79
実際要らないんじゃないかねえ
天才集団が作った言語、GoやDartにはどちらもないしさ
84:デフォルトの名無しさん
13/05/03 16:06:44.01
Cやフォートランと仲良しの言語じゃないとダメだよ
JSは低レベルな計算とは切り離されてるから無理
85:デフォルトの名無しさん
13/05/03 16:07:05.56
>>81
でもPythonで作られたものよりか
JavaScriptで作られたもののほうが
今は多いよ。
86:デフォルトの名無しさん
13/05/03 16:08:26.82
>>84
JavaScriptが低レベルな計算と切り離されてるってのがよくわからん。
高レベルな計算は出来るってことだよな？
低レベルな計算ってなんのことだ？
87:デフォルトの名無しさん
13/05/03 16:09:23.36
Javascriptは最近までブラウザの中の言語だったからね
C言語なんかと連携できるようになったのも最近の話だし、
パフォーマンスが良くなったのも最近
だから、確かに今はクリティカルな数値計算をしようとする人が少ない
ただ、V8の登場、node.jsで状況は一変した
兆しは確実にある
88:デフォルトの名無しさん
13/05/03 16:10:13.69
int型の計算のことだろ？
まあそれもInt32ArrayなどのTyped Array（ブラウザに既に実装済み）で
できるようになったけど。
89:デフォルトの名無しさん
13/05/03 16:10:32.25
やっぱり低レベルが通じない馬鹿がJSを擁護してた
90:デフォルトの名無しさん
13/05/03 16:11:40.95
確かに低レベル。前スレからJS厨のレベルの低さが目立つ
91:デフォルトの名無しさん
13/05/03 16:11:51.06
JavaScriptが登場したのは1995年だからね。
重要なのは開発スピード
この数年は、衰えるどころかスピードアップしている
92:デフォルトの名無しさん
13/05/03 16:12:29.03
確かに新しい言語に内包表記も演算子オーバーロードも入れないGoogleは低レベルだよね
93:デフォルトの名無しさん
13/05/03 16:12:34.04
アンチJSが低レベルだと認められる理由。
何も内容がないレスをするから。
94:デフォルトの名無しさん
13/05/03 16:14:29.17
>>82
JS厨な俺としても、その記法で必須なxの初期化を省いてるのが気になる
95:デフォルトの名無しさん
13/05/03 16:15:29.73
>>94
というか、JS厨の俺から見るとvar省いてるのとin使ってるのが気になる
つか、こいつJS知らんだろ
96:デフォルトの名無しさん
13/05/03 16:15:34.86
>>92
それ、どこがpythonより優れてんの？天才集団とか権威主義のカスは死んでいいぞ
使ってから喋れ
97:デフォルトの名無しさん
13/05/03 16:16:23.64
pythonもJavascriptも使い倒した上で天才集団が新しく作った言語に
文句あるの？
権威主義ですが何か？
98:デフォルトの名無しさん
13/05/03 16:16:53.44
あ、アホな方のJS厨はJSすら知らないのかw
99:デフォルトの名無しさん
13/05/03 16:18:02.42
まあ本質とは全く関係のないくだらん揚げ足取りだからあえて指摘しなかったけど
100:デフォルトの名無しさん
13/05/03 16:18:21.58
>>97
開き直ったら正当化してんのかよ
goとdartを使ってから擁護しろと言ってんたよ
101:デフォルトの名無しさん
13/05/03 16:18:32.30
いつから>>82がJavaScriptだと思い込んでいた？ｗｗｗｗ
102:デフォルトの名無しさん
13/05/03 16:19:05.78
自分がろくに書けない言語の厨になるとはレベル高いなw
103:デフォルトの名無しさん
13/05/03 16:19:16.68
敵は皆JS厨じゃあー！
見るもの全部、JavaScriptじゃあー！
104:デフォルトの名無しさん
13/05/03 16:19:42.60
訂正:正当化してんのかよ→正当化されるのかよ
105:デフォルトの名無しさん
13/05/03 16:20:50.23
ぶっちゃけ、アホの方のJS厨は
LLスレだった頃から度々書き込んでたJavaドカタだと思う
106:デフォルトの名無しさん
13/05/03 16:21:28.19
>>100
俺が使おうが使うまいが真実は変わらんだろ？
107:デフォルトの名無しさん
13/05/03 16:22:37.88
>>105
説得力ありすぎてこまるw
邪魔すぎてスレタイ変更で追い出されたからな
108:デフォルトの名無しさん
13/05/03 16:22:39.59
>>105
ぶっちゃけ、アホな方のアンチJSは妄想癖があると思う
109:デフォルトの名無しさん
13/05/03 16:25:01.17
>>106
何が真実かも説明できないやつが何言ってんだ？お話にならない
110:デフォルトの名無しさん
13/05/03 16:26:28.34
>>109
真実は、PythonもJavascriptも知り尽くした天才集団が新しく作った言語に
演算子オーバーロードと内包表記が採用されなかったということ
つまり、こんな機能はいらないんだよ
こんなゴミ機能で喜んでる奴はバカ
111:デフォルトの名無しさん
13/05/03 16:30:16.43
>>107
皆で一斉にJavaをdisり始めたら、急にJavaを擁護し始めそうだねw
もしかして、内包表記を執拗にdisるのも、Javaに無い機能をdisってるのかも
112:デフォルトの名無しさん
13/05/03 16:31:20.34
>>110
で、どこがどう優れてるんだ？
前スレのお題をその２つで綺麗に書いてくれ
goはかなり特殊な言語でオブジェクト思考プログラミングすら、他の言語のようにはしない
コードは冗長になりがち。Cの代替になれるかどうか
dartとかもうどうしようもない言語だと思うが
113:デフォルトの名無しさん
13/05/03 16:31:44.95
誰もJava Disに参加しないのであったｗ
一人でやってろアホ
114:デフォルトの名無しさん
13/05/03 16:32:36.78
Java8も延期になったし、言語自体も古くさくてゴミ
いまさらdisるのも馬鹿馬鹿しい程ウンコ
115:デフォルトの名無しさん
13/05/03 16:33:06.81
最近思ってもみなかったところから白熱するねこのスレ
116:デフォルトの名無しさん
13/05/03 16:33:09.82
敵を見つけないといけないから可哀想だよね。
このスレではJSが敵か。
敵を叩くことで精一杯。
何もためになる話をしない。
117:デフォルトの名無しさん
13/05/03 16:34:58.48
>>112
俺がその二つで奇麗に書こうが書くまいが真実は全く変わらないのだが？
説得力が欲しいならお前がどうしても汚くなってしまうことをソースで書いてみせれば良いだろ
俺はやらないよ
天才集団が新しく作ったというだけで十分な説得力だし
118:デフォルトの名無しさん
13/05/03 16:36:13.97
>>117
> 俺はやらないよ
コード書けない低能だからねw
やりたくても無理だね
119:デフォルトの名無しさん
13/05/03 16:36:45.00
どうせ、112は長くなった行数を見て冗長だとか可読性が無いとか言い出す奴だろ
120:デフォルトの名無しさん
13/05/03 16:37:31.11
JS厨あらためgo厨 or Dart厨かw
121:デフォルトの名無しさん
13/05/03 16:38:25.10
goは何か少ない機能だな。必要最低限というか
リスト内包表記的なことはmapでやるっぽいな
その方法はpythonでもできるけどリスト内包表記を使った方が可読性面で良いとされてる
122:デフォルトの名無しさん
13/05/03 16:38:27.83
>>118 >>120
中身を語らず人格批判
自分より先に人にソースを要求
これがアンチJS厨
123:デフォルトの名無しさん
13/05/03 16:39:08.18
>>121
javascriptもそんな感じ
クロージャ使ってmap
124:デフォルトの名無しさん
13/05/03 16:40:02.35
表記はあくまで表記であり
機能ではないから
その機能は別の表記できるんだよな。
125:デフォルトの名無しさん
13/05/03 16:40:31.23
>>122
その逃げ回りっぷりを批判されてるってわからんの
自分より先にってなんだよ。こっちに示すもんねーだろ馬鹿か
126:デフォルトの名無しさん
13/05/03 16:43:13.74
>>123
今回の流れでJS触ったがクロージャはマジで当たり前のように外部変数壊しててやばいと思った
リスト内包表記はそんなことできない
127:デフォルトの名無しさん
13/05/03 16:44:14.00
JSも嫌いじゃないから、こんなアホが使ってると思いたく無かったわ
あーよかった
そうかー、JS厨じゃなくて偽プログラマだったのか
128:デフォルトの名無しさん
13/05/03 16:44:49.72
>>126
むしろそれが出来るからこそ、クラスの代替になるんだけどね
クロージャはJSの中でもみんなが絶賛してる機能
メリットの方が大きい
129:デフォルトの名無しさん
13/05/03 16:45:36.59
そりゃJSプログラマがみんなこんなんだったら世界が崩壊してる
130:デフォルトの名無しさん
13/05/03 16:48:05.71
>>128
それは制約上の妥協点でしかなくで
関数でクラスの代替？とかやってるのが端から見たら終わってて
普通のクラスじゃダメな理由がわからない
131:デフォルトの名無しさん
13/05/03 16:50:26.44
>>125
お前も逃げてるじゃん
示すものがない？
天才集団に楯突くからには、ソース示した方が説得力あるだろw
Pythonのソースだってお前が書いたソースじゃないだろ
アンチJSはまさに虎の威を借る狐
>>130
まあ分かりにくいだろうね
これのおかげで、ブラウザのイベント処理とか、非同期処理とかが
うまく扱えて、インターネットと非常に相性が良かったわけで
今また盛り上がってきてるのにつながるわけだけど
実際に書かないとこれは実感できない
132:デフォルトの名無しさん
13/05/03 16:58:15.53
> 天才集団に楯突くからには、
> まさに虎の威を借る狐
ブーメランすぎるwww
133:デフォルトの名無しさん
13/05/03 16:59:01.77
>>131
JS厨ってお前みたいな馬鹿しかいないんだな
何がどう優れてるのか示せない限りただの幻想じゃん
JSでは勝てないから自分も知らない言語に逃げるクズ
134:デフォルトの名無しさん
13/05/03 17:01:05.12
JSというかHTML5の熱烈指支持者、アルファブロガーっていうのキュレーターだっけ？アーリーアダプターか？スタバでMac使ってる連中の言うことを真に受けちゃったんだろう。
135:デフォルトの名無しさん
13/05/03 17:02:55.40
ちょっと俺がJS厨のフリして煽ったら
見ないうちに荒れやがってｗ
ほんと仲間はすぐに寄ってくるな。
136:デフォルトの名無しさん
13/05/03 17:13:34.45
numpy.jsがあったらこんな雰囲気になるんだろうな
var numpy = require(numpy);
function kmeans(data, K) {
var xs = random.randint(0, K, data.length),
ys = zeros(data.length)
while (!allclose(xs, ys)) {
for (var k = 0, ms = []; k < K; k++) {
ms.push(mean(at(data, xs, function(x) {return x==k;})),
{axis: 0});
}
ys = xs;
for (var i = 0, xs = []; i < data.length; i++) {
for (var j = 0, ts = []; j < ms.length; j++) {
ts.push(linalg.norm(data[i].sub(ms[j])));
}
xs.push(nanargmin(ts));
}
}
return xs;
}
やっぱりたいして変わらない
ライブラリの違い
137:デフォルトの名無しさん
13/05/03 17:16:46.17
JS厨は毎日これ
妄想を垂れ流す、今勝てないから未来（妄想）にすがる、見知らぬ権威に頼る
自分の知識は関係ないと言う、無知だからデタラメしか言えない
筋金入りのペテン師、といっても始めから誰も信用してないけど
ライブラリの違いが致命的であることを理解できない馬鹿
railsかなんで流行ったと思ってるんだ。まあCと相性悪い点も汎用言語としては論外だし
妄想が実現することは一生ないけど
138:デフォルトの名無しさん
13/05/03 17:16:48.84
>>133
少なくとも、内包表記と演算子オーバーロードがないことくらいは知ってたから
お前よりはマシじゃね？w
139:デフォルトの名無しさん
13/05/03 17:18:46.95
>>138
なんで劣ってる点を挙げて優れてると主張するんだ？キチガイか？
140:デフォルトの名無しさん
13/05/03 17:20:06.60
>>137
お前は毎日それを言って過ごしてるってことだなｗ
141:デフォルトの名無しさん
13/05/03 17:20:39.57
>>139
劣ってる？
採用されていないんだから、必要ない機能ってことだろ
つまり、劣ってないということ
むしろある方が劣ってるってこと
142:デフォルトの名無しさん
13/05/03 17:20:45.28
>>136
そのライブラリの有無が重要なんだと思う
ライブラリを除いた狭義の言語だけ扱っていても
その言語で「実際に」何ができるのかはわからないし
143:デフォルトの名無しさん
13/05/03 17:22:40.01
>>142
まあもちろんそうなんだけど、これは歴史的に見てしょうがない気がする
数値計算はまだはっきりと苦手分野
状況が一変し始めてる段階
144:デフォルトの名無しさん
13/05/03 17:24:08.12
>>142
ライブラリを比較って意味では、scipy使えばコード書く必要すら無いんだよねkmeans...
145:デフォルトの名無しさん
13/05/03 17:27:42.11
>>141
それは反証できない、お前お得意の詐欺だか
現にそれらの機能は広く使われて恩恵がある
リスト内包表記やC#のLINQがないほうが良いとか言ってる天才はいない
だからお前がないほうが良い理由を説明できないならそれはただの欠点でしかない
146:デフォルトの名無しさん
13/05/03 17:28:58.06
>>144
kmeans関数さえあればね
それってライブラリさえあればJSでもなんでも変わらんということだけど
>>145
採用されなかった
その事実だけで十分説得力を持つから俺はそれ以上何か言う気はないね
詐欺だと勝手に思いたければ思ってれば？
147:デフォルトの名無しさん
13/05/03 17:31:15.87
>>146
説得力のある説明ができないなら、リスト内包表記や演算子がない点については欠陥があるということだから
それ以外で何がなぜ優れてるのか説明しないとお前の論は何も通らない
天才が失敗した、それだけ。
148:デフォルトの名無しさん
13/05/03 17:32:44.74
ライブラリさえあればー、誰か膨大なライブラリを用意してくれー、誰かー、JSをまともな言語にしてくれー
149:デフォルトの名無しさん
13/05/03 17:33:04.97
かつてSunに居た天才達は、Javaをデザインするときに
「ブルーカラーでも使えるように」様々な機能を削ってJavaを作った
何が言いたいか分かるな？
150:デフォルトの名無しさん
13/05/03 17:34:42.67
>>147
説得力ある説明してるしw
何を言っても無駄とはまさにこのことw
まさか、Pythonを使いこなしているGoogleがそれらの機能を知らないはずがないしな
Googleコーディング規約でも実はネストした内包表記禁止してるくらいだし、
少なくともまともに検討した結果、無い方が良いと判断したのは確実
仮にお前の言うように失敗だったとしても、それなりに根拠があるってこと
本当はそんなに喜ぶほどの価値はないんだよ
151:デフォルトの名無しさん
13/05/03 17:35:06.78
>>149
ポインタは危険だったね。メモリ管理は大変だったね
つまりデメリットを説明しないかきりお前とGoogleは完全に間違ってるということ
152:デフォルトの名無しさん
13/05/03 17:37:00.25
>>151
Googleが完全に間違ってるかどうかは
俺が説明できるかどうかにかかってるのか
すげえな俺
神かw
153:デフォルトの名無しさん
13/05/03 17:37:49.42
内包表記は数学の素養がない馬鹿にとって可読性が低い
（自分が使わなくても、他人が書いたコードは読む必要がある）
だから馬鹿対策で機能を削った
自分達はPythonやC++を使うから、馬鹿は低能向けの言語使っとけってことだ
154:デフォルトの名無しさん
13/05/03 17:39:05.83
>>153
C＋＋には内包表記はないぞ
Pythonにしても、自分たちが使うコーディング規約で内包表記は単純なものだけにしましょう
と言ってるし
155:デフォルトの名無しさん
13/05/03 17:39:17.91
>>150
なんでGoogle事情に詳しいお前が採用しなかった理由を説明できないんだ
あと演算子オーバーロードの恩恵を理解できないとかバカすぎ
いろんな自作クラスに対して直感的な記述は不可能になる
これは科学技術分野では特にありがたい機能だ。だから、Googleの言語はJS同様に劣った言語なんだな
156:デフォルトの名無しさん
13/05/03 17:41:32.06
>>154
演算子オーバーロードがある
157:デフォルトの名無しさん
13/05/03 17:44:46.83
>>149
> 何が言いたいか分かるな？
嘘を言いたいんでしょう？
158:デフォルトの名無しさん
13/05/03 17:45:07.43
>>155
そう思いたければ思えば良い
科学技術に長けたGoogleがC/C++の代替を目指した言語で採用しなかった
お前より頭がいい奴はそう思ってるってだけ
>>156
そして、スタイルガイドにこう記述することになる
「特殊な状況を除き、演算子をオーバーロードしてはいけません。」
理由も載ってるからググってこいよw
159:デフォルトの名無しさん
13/05/03 17:45:25.45
Google Python Style Guide より List Comprehensions の項を引用
> Pros:
> Simple list comprehensions can be clearer and simpler than other list creation techniques.
> Generator expressions can be very efficient, since they avoid the creation of a list entirely.
> Cons:
> Complicated list comprehensions or generator expressions can be hard to read.
複雑な場合に読み難いってだけじゃなく、
シンプルな場合は他の方法よりシンプルで明快だと書いてるね
さらにジェネレータ式は効率的だとも
160:デフォルトの名無しさん
13/05/03 17:45:58.74
PHPer（何を議論しているのかさっぱり分からん・・・^p^）
161:デフォルトの名無しさん
13/05/03 17:46:46.09
>>160
次のターゲットかい？
お前も懲りないね。
162:デフォルトの名無しさん
13/05/03 17:48:46.84
>>159
can beって書いてあるように
あくまで良い場合もあるってだけ
言語に組み込むほどの良さでもないんだろう
悪い面の方がむしろあるってことなんだろうね
163:デフォルトの名無しさん
13/05/03 17:49:07.66
内包表記のネストを避けるのはgoogleだけじゃなくpythonコミュニティ全体の話だ
そんな暗黙のルールはどの言語にもある
>>158
Pythonはお前より頭の良い奴が作ったんだから
お前はPythonに一切の文句を言えないはずだが？
164:デフォルトの名無しさん
13/05/03 17:50:20.65
python開発者より馬鹿な奴がpython批判っておかしくないですか
お前が何を言ってもpythonの設計は正しいということですよね
誰よりも頭が悪いお前は何しにここに来てんだ
165:デフォルトの名無しさん
13/05/03 17:50:32.33
>>162
その通り。can beって書いてあるように
あくまで複雑な内包表記でも読み難くなる場合もあるってだけ
166:デフォルトの名無しさん
13/05/03 17:51:57.20
>>158
え？goは科学技術分野の言語ではないと思うが
googleに詳しいお前の公式見解を聞きたい
167:デフォルトの名無しさん
13/05/03 17:52:47.13
まあ、python作った当時の作者なら俺の方が
新しい言語を知ってる分、この分野に関しての知恵はあるだろうな
pythonの人とやらも今新しく言語を作るなら内包表記採用しないかもなw
googleの場合は歴史的な試行錯誤の末、今採用してないわけでw
168:デフォルトの名無しさん
13/05/03 17:55:25.43
リスト内包表記やLINQを批判してるまともなプログラマなんて見たことないよ
169:デフォルトの名無しさん
13/05/03 17:57:04.12
俺達はいつまでこの既知外の相手をしなければいけないの？
170:デフォルトの名無しさん
13/05/03 17:59:47.53
ちゃっかりLINQを混ぜて何がしたいんだ
LINQなんて採用されてなさすぎだろw
171:デフォルトの名無しさん
13/05/03 17:59:48.74
>>167
googleが間違った。正解だというのなら証拠見せろ
また未来に頼るのか？お前そればっかだな
事実ベースで語るならそんなのを正解として出すほうが馬鹿。天才だからーって阿呆か
goやdartの設計思想も説明できないしさあ、お前ゴミすぎるだろ。反論できる？
172:デフォルトの名無しさん
13/05/03 18:01:01.04
>>171
いや、だから、俺は証拠を見せる必要がないと思うから
しないだけ
今の時代にGoogleが間違ったってかw
へー説得力ありますなあ
173:デフォルトの名無しさん
13/05/03 18:06:14.61
実際Google言語はまだ主流じゃないし、馬鹿みたいに正しい言語と言われても嘘っぱちにしかならない
174:デフォルトの名無しさん
13/05/03 18:07:46.41
JSでは勝てなくて逃げ惑う、説明を求められ逃げ回る。これだけ
175:デフォルトの名無しさん
13/05/03 18:08:20.49
URLﾘﾝｸ(golang.jp)
> メソッドと演算子のオーバロードをサポートしていない理由は?
>
> メソッドを呼び出す際に、メソッドの型をいちいち調べしなくてよい方がシンプルです。
> 他の言語に接した経験から言えることは、同じ名前で、かつシグネチャが異なるメソッドの寄せ集めを持つことは、
> ときに役に立ちますが、混乱を招くだけで充分に機能しません。
> 型の中で、メソッドが名前だけで検索できるよう制約を課すことは、Go言語の型システムを単純な仕組みにする上での大きな決断でした。
Javaを含む殆どの静的型付けOOPLを全否定だな
これがGoogleの天才が出した結論か
176:デフォルトの名無しさん
13/05/03 18:09:39.92
それが吉と出るか凶と出るかわからないのだが、お前が正しいと思う根拠は何？
177:デフォルトの名無しさん
13/05/03 18:11:17.57
googleがこう言ってるからって自己の無いただのgoogleの代弁者のくせにこの底抜けバカっぷりがすごい
何も理解せずに行き当たりばったりで喋るからこうなる
178:デフォルトの名無しさん
13/05/03 18:11:58.07
主流になることには失敗するかもな
仕様の善し悪しより人気や宣伝の面もあるし
ただ、自分たちが使うことも念頭において開発してる言語だし、
真剣に検討した結果であることは間違いない
仮にそう決断したことが悪い判断だったとしても、
お前が言うように手放しで喜べるような単純なもんでもなく
議論が裏にあるってことだ
少なくとも、浅い考えで「内包表記がないー、オーバーロードがないー
話にならないー、全然違うー」
なんて話ではない
むしろ、そんなものあってもなくても実は生産性に大差はないんだよというのが
説得力を持つ
179:デフォルトの名無しさん
13/05/03 18:13:26.78
> 演算子のオーバーロードに関しては、絶対に必要というより、あれば便利という程度であり、
> 採用しないことでシンプルさを保ちました。
そしてメソッドのオーバーロードは結構批判的なのに、
演算子オーバーロードはそうでもないという
180:デフォルトの名無しさん
13/05/03 18:13:36.88
失敗したら説得力ねーよｗ
181:デフォルトの名無しさん
13/05/03 18:14:02.28
>>179
C++スタイルガイド見てこいよ
かなり批判的
182:デフォルトの名無しさん
13/05/03 18:16:57.58
>>181
見て来た
> 演算子をオーバーロードするとコードは直感的にわかりやすくなりますが、次のような欠点もあります。
>
> ・コストの高い操作なのに、コストの安い組み込み操作だと思わせてしまう。
> ・オーバーロードした演算子を呼び出している場所を見つけるのが非常に困難になる。== の呼び出しを探すよりも Equals() を探す方がはるかに簡単です。
> ・ポインタにも機能する演算子があるが、これらはバグを生みやすい。Foo + 4 がやることと、&Foo + 4 がやることは全く違います。コンパイラはどちらにも警告を出さないため、デバッグは非常に難しくなります。
> ・オーバーロードには想定外の悪影響もあります。たとえばクラスが単項 operator& をオーバーロードしていると、クラスは安全に前方宣言できません。
基本的に2番目以外はC++固有の問題だと思う
183:デフォルトの名無しさん
13/05/03 18:18:47.69
>>178が必死に話を有耶無耶にしようとしてるところ悪いけどさあ
一長一短あるならリスト内包表記がなければ優れてるとかいう馬鹿な主張をしてる
お前は本当に救いようがない馬鹿だということを自白してることになるし
リスト内包表記やオーバーロードの有用性は未だに否定されてないのだが
184:デフォルトの名無しさん
13/05/03 18:20:36.34
ぶっちゃけ、内包表記と演算子オーバーロードがなくても
>>136レベルの簡潔さにはなるんだろ
十分許容範囲だわw
理解に大きな差が出るとは思えない
>>182
そうかね、一番目は明らかに固有じゃない気がするし、３番や４番も
同類の問題が出てきそうだけど
>>183
有用性とデメリットがあってそのバランスを取った結果採用されなかったってことだろw
185:デフォルトの名無しさん
13/05/03 18:20:49.34
C++の演算子オーバーロードはややこしい
Pythonはシンプルだし。むしろ無いと困る
というかどうせ代替のメソッドを定義することになるが
こうすると式に一貫性がなくなる
186:デフォルトの名無しさん
13/05/03 18:23:32.13
まあ、人気が言語の良し悪しだと言いたいなら、
お前の嫌いなJavaがPythonより良い言語ってことになるけどいいの？w
187:デフォルトの名無しさん
13/05/03 18:25:34.62
>>184
Googleの天才は採用しなかった、他の天才は採用した
なんでGoogleが一方的に正しいんだ？馬鹿？
188:デフォルトの名無しさん
13/05/03 18:25:39.44
>>186
メソッドのオーバーロードがあるJavaなんて
Googleの天才達によって否定済みですけど？
189:デフォルトの名無しさん
13/05/03 18:31:49.51
>>186
実際Javaの汎用性やそれに伴うライブラリの豊富さは強いだろ
それに対してPythonはPythonの良さがあると言えるわけ
一ミリも知らない言語をgoogleが作ったから良いと言っちゃう馬鹿と一緒くたにしないでほしいわけ
190:デフォルトの名無しさん
13/05/03 18:38:56.67
>>187
一方的に正しいとか、まあそこまでは言ってない
他が天才かどうかは知らんが、仮にそうだとしても、意見が割れてるのは確かだ
その時点で、内包表記の有用性はかなり怪しいものになるんだよ
>>188
そうだね
人気がある方が正しいと考える君の考えは
ここでもGoogleに否定されたわけだ
DartやGoは今のところ人気はない
ただ、だからといって正しくないとは言えない
>>189
結局仕様の良し悪しじゃないじゃんw
191:デフォルトの名無しさん
13/05/03 18:42:25.20
>>184
一番目も、C++の場合、オーバーロード無しで演算子が出来る事は
Cと同じだから低コストと思うワケで、
高コストな操作（文字列やリストの連結等）が演算子で書ける言語の場合
演算子だから低コストなんて思わないよ
だから前提からしてC++固有とまでいかなくても、最近の言語には当てはまらない話
192:デフォルトの名無しさん
13/05/03 18:42:58.87
>>190
Javaの仕様の悪いところやPythonの仕様の良いところも馬鹿なお前と違って言えるし
それは議論されつくされてる。リスト内包表記が無い方がいいとか言ってる馬鹿はいないけど
実際正解してないgoogleを正解例としてpython批判してる馬鹿が
問題となるコードを例によって一回も出してくれないしこれからも一生出さないと思うと呆れるしか無い
193:デフォルトの名無しさん
13/05/03 18:44:20.90
JavaとJavascriptがウンコって結論になれば
別にGoが最高の言語という結論になっても構わない俺がいるw
194:デフォルトの名無しさん
13/05/03 18:45:04.15
言語を一ミリも知らないのはどっちだw
本当は、「まともなプログラマーなら、内包表記や演算子オーバーロードを採用して当たり前！
主要な新しい言語は全部そう！」って思ってたんだろw
正直になれよw
>>191
一番有名な例であるiostreamからして高コストなioだからなあ
195:デフォルトの名無しさん
13/05/03 18:45:51.61
JS絶賛から逃げ出して苦し紛れにGoogle擁護してるゴミがどこまで頑張るか観察したい
頑張ってると言っても正しさは一切ないけど
196:デフォルトの名無しさん
13/05/03 18:47:42.52
>>195
まあ別に逃げ出してないし、
俺がどこまで頑張ろうとJSの時代が来ることは変わらんわけでw
指をくわえてみてると良いよw
197:デフォルトの名無しさん
13/05/03 18:48:40.93
>>193
そこなんだよな
逆に言えばJS厨はJSが糞だという結論に落ち着きかけたから
Googleをスケープゴートとして使ってるだけ
Googleの言語はまだまだだし、JSが科学で使い物にならないという事実は明らかなのに
198:デフォルトの名無しさん
13/05/03 18:50:12.24
>>197
いつ結論が出たんだよw
お前が勝手に勝利宣言してるけど、
真実はライブラリがないだけで、JS自体はちっとも糞ではなく、
これからどんどんライブラリが出ることも確定してるってことだ
199:デフォルトの名無しさん
13/05/03 18:50:48.10
>>196
ほら、今がショボいことを認めたくないから現実逃避を続けてるじゃん
200:デフォルトの名無しさん
13/05/03 18:52:08.63
はい、今はライブラリがなくて完敗宣言っと
201:デフォルトの名無しさん
13/05/03 18:52:14.65
え？確定してんの？
202:デフォルトの名無しさん
13/05/03 18:53:26.65
>>199
いや、今はしょぼいよ
数値計算のライブラリがないという点でな
ただ、ウェブ関連は充実してるし、これから
数値計算もこれからしょぼくなくなるけど
>>200
今だけなw
良かったなw
>>201
まあ分かる奴には分かる
ヤバいよ
マジで来る
203:デフォルトの名無しさん
13/05/03 18:54:20.74
確定してるわけないだろ。大規模なライブラリはブラッシュアップに時間がかかるし
万が一、数年後にまともなライブラリができるとして今JSを使う必要性はまったくない
完成してから吠えてくれw
204:デフォルトの名無しさん
13/05/03 18:55:10.59
数値計算で今JS使わなくても良いのは確か
というかまず、充実したC++ライブラリのラッパーがくるんじゃないかね
205:デフォルトの名無しさん
13/05/03 18:58:32.08
だからー、演算子オーバーロードがないと式の記述が不自然になるんだってｗ
JSは一生ねーよ
206:デフォルトの名無しさん
13/05/03 19:00:33.36
C++のラッパー作るだけで良ければ今頃どの言語にもscipy相当があるよ
Railsクローンが色んな言語にあるようにな
なのに、scipy相当がPythonにしか無い時点で察しろって話
207:デフォルトの名無しさん
13/05/03 19:01:27.55
>>205
まあそういう奴も安心
なんせ別言語が定義できるくらいだから、別の言語が使えるようになるよ
俺は直接JS使うけどw
208:デフォルトの名無しさん
13/05/03 19:04:09.87
>>207
君は科学技術計算に縁のない底辺ドカタなんだから
最初から関係ないよ
いつまでもJSを使っててくれて構わない
209:デフォルトの名無しさん
13/05/03 19:05:36.81
>>208
確かにあんまり縁がなかったわw
万一今科学計算が必要でも別にC++やpython使うから良いけどw
210:デフォルトの名無しさん
13/05/03 19:07:10.00
使うなよ気持ち悪い
211:デフォルトの名無しさん
13/05/03 20:27:01.00
Scipyっての知らなかったけど、面白いな
遺伝的アルゴリズムとかもあるのか
ちょっと遊ぶのにいいかもしれん
このスレでJavascriptの良さを力説するのも無駄じゃなかったw
212:デフォルトの名無しさん
13/05/03 20:51:38.70
馬鹿の上にこの気持ち悪さ
これは凄い
213:デフォルトの名無しさん
13/05/03 21:42:10.23
伸びてるから何かと思ったら
数値計算向けの言語pythonで数値計算のお題出して
しかもライブラリ借りて解いて喜んでいるのか
dom操作のお題出したあとjQuery使って解いて
Javascriptスゲーと言ってるようなもんだわ
214:デフォルトの名無しさん
13/05/03 21:45:20.48
しかも、Javascriptに一時間程度で簡単に解かれちゃってたw
215:デフォルトの名無しさん
13/05/03 21:46:20.69
Linuxのシステムの一部でも使われてるのにそれは無理があるわなあ
実際JSってあらゆる普段使いに向かないんだからさ
216:デフォルトの名無しさん
13/05/03 21:48:29.92
まあ、pythonが数値計算向けってのはちょっと違うな
もともとは汎用スクリプト言語
JSはブラウザ用言語だったが、今となっては広範囲に使える汎用言語
ただ、数値計算は凄いライブラリがある関係上、pythonが今のところ有利
217:デフォルトの名無しさん
13/05/03 21:49:01.94
>>213
御題出したのはJS厨
で、解いたんだからお前も解けという流れ
218:デフォルトの名無しさん
13/05/03 21:49:07.31
いやJS厨もライブラリ絶賛しまくりだったのに
返り討ちに合った途端にライブラリがある問題はダメってなんなん
自演下手過ぎだし
219:デフォルトの名無しさん
13/05/03 21:50:26.18
その何でもかんでもJS厨に見える癖、何とかならんのか
しかも一人か二人だと思ってるようだし
220:デフォルトの名無しさん
13/05/03 21:51:28.84
じゃあ論破された馬鹿な主張を繰り返すのやめろよ馬鹿
221:デフォルトの名無しさん
13/05/03 21:51:41.74
JS厨っていうか、壮絶なアホが一匹いる
222:デフォルトの名無しさん
13/05/03 21:52:15.14
論破された主張って何のことだよw
223:デフォルトの名無しさん
13/05/03 21:52:38.61
JSが科学技術分野で追い付くことはないし
不確定な遠い未来しか武器がないなら黙ってろ
224:デフォルトの名無しさん
13/05/03 21:52:50.82
>>221
中身のない中傷を繰り返すアンチJSのことか
225:デフォルトの名無しさん
13/05/03 21:54:34.52
>>223
そう思うなら反論する必要がない
余裕こいてれば良いだろ
226:デフォルトの名無しさん
13/05/03 21:55:04.23
ライブラリがあれば、どの言語も同じようにかけることが
証明されてしまったからな。
これからどう反論する？
227:デフォルトの名無しさん
13/05/03 21:55:19.39
JSがnumpyに追い付く証拠も出さずに妄想を毎日垂れ流す限り一生中傷され続ける
自分がデタラメを並べてると気付いてないわけじゃないだろ
悪ふざけはやめろキチガイ
228:デフォルトの名無しさん
13/05/03 21:55:44.21
お題だしたのがJS厨って怪しいな
scipyやnumpy知ってたっぽいし、むしろpython厨っぽい
229:デフォルトの名無しさん
13/05/03 21:56:46.68
ライブラリの差が
言語の差になってるうちは
言語の優位性なんて語れないぞ。
言語だけの範囲で語ろうぜ。
230:デフォルトの名無しさん
13/05/03 21:56:49.77
>>225
お前のペテンを批判してるだけ
231:デフォルトの名無しさん
13/05/03 21:58:00.15
不確定な未来について好き勝手に論じるなら、
科学技術計算でJavascriptがPythonに追いつく未来より、
asm.jsで中間言語に落ちぶれる未来の方が
遥かに実現する可能性が高そう
少なくとも、asm.jsは既に存在するわけだし、Googleも興味を持ってる
232:デフォルトの名無しさん
13/05/03 21:58:01.92
言語の差はライブラリで埋まる
証拠は数々上がっている。
233:デフォルトの名無しさん
13/05/03 21:58:55.14
状況証拠みたいなものしかないけど、Javascriptが熱いというのはマジだってば
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
234:デフォルトの名無しさん
13/05/03 22:02:22.45
JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語と結論でただろ
JS厨がpythonに対してスコープは絞るべきとか言ってたのは今考えたら悪うしかない
かなり危険な糞仕様
235:デフォルトの名無しさん
13/05/03 22:02:27.12
>>232
Javascriptは全然マシだけど、Javaはウンコすぎて無理
関数オブジェクトすらないゴミでは話にならない
やっぱり言語による差はあるよ
236:デフォルトの名無しさん
13/05/03 22:02:53.80
>>231
numpyみたいにコアの処理をCに任せればいいだけ
237:デフォルトの名無しさん
13/05/03 22:03:41.07
>>235
それがならないんだなぁ。
証拠は数々上がっている。
238:デフォルトの名無しさん
13/05/03 22:03:58.27
>>236
うん、簡単だね
今すぐ実装してきて良いぞ
239:デフォルトの名無しさん
13/05/03 22:04:42.82
>>234
ちょっと抽象的すぎて良く分からんな
Lintで検出できないようなもんかね？
240:デフォルトの名無しさん
13/05/03 22:06:16.82
>>239
変更するのがデフォだからテストも通る
241:デフォルトの名無しさん
13/05/03 22:06:24.11
>>237
おいおい、JavascriptとJavaを一緒にするなよ
ぶっちぎりでゴミだよJavaは
関数オブジェクトが無いんだよ？信じられんわ
242:デフォルトの名無しさん
13/05/03 22:07:06.29
>>234
> JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語
それ、お前が変更しまくらないと
出来ない無能なんですーって
言ってるだけじゃないかｗ
243:デフォルトの名無しさん
13/05/03 22:07:44.91
>>241
はいはい、必死だね。
世の中にはクラスすらない言語もあるんだよ。
244:デフォルトの名無しさん
13/05/03 22:08:55.68
俺頭悪いので分からんから、具体例で説明してくれ
245:デフォルトの名無しさん
13/05/03 22:11:07.96
>>234
それがないとクラスも作れないカス言語
pythonでは明示するしコミュニティでは極力避けてるのに
JSは文化的に積極的にやってる。というかそれがないと無理なんだろうな
だとしたら、意味もなく大量のvar宣言せずにクロージャの宣言をしたほうが良い
246:デフォルトの名無しさん
13/05/03 22:12:40.24
Java使いでもEgor Kulikovみたいな奴いるしな
Egorの1/10もプログラム書けない奴が大半だろ
言語というよりやっぱ個人差の方が大きい
247:デフォルトの名無しさん
13/05/03 22:13:49.80
>>245
自分の無知をさらけ出して恥ずかしくないの？ｗ
JavaScriptにはグローバル変数すら無いしね。
248:デフォルトの名無しさん
13/05/03 22:14:11.17
>>245
ちょっと具体例で説明して欲しいんだが、
こんな感じのこと？
a = 1;
function() {
a=2; //ああ、変更できちゃったよ！
}
249:デフォルトの名無しさん
13/05/03 22:14:14.08
>>244
Cでグローバル変数を使い回すようなもの
それを便利とか言って多様するのは
プログラミング初心者と競技プログラミングだけ
それ以外でもやむを得ず使う場合はあるが
普通は危険な割にメリットが少ないから避ける
250:デフォルトの名無しさん
13/05/03 22:15:53.62
>>247
実際に関数を呼び出せば関数外の変数を書き換えるのが当然の言語だろ
違うなら反論よろ
251:デフォルトの名無しさん
13/05/03 22:16:14.21
>>249
ちょっと良く分からん
pythonのコード例とjavascriptのコード例を対比させて説明してくれないか？
252:デフォルトの名無しさん
13/05/03 22:16:21.63
>>248
そうそうそれのこと。
グローバルな変数を書き換えることができて
それを防ぐ方法がない。
これがJSというカス言語
253:デフォルトの名無しさん
13/05/03 22:17:49.08
>>252
防ぐ方法はあるだろ
あんまり変な事書くなよPython使いが皆アホだと思われるだろ
254:デフォルトの名無しさん
13/05/03 22:18:30.76
strictモードで防げるじゃん。
やっぱり無知だったか。
アハハハハ
255:デフォルトの名無しさん
13/05/03 22:20:41.17
Python使いが皆アホということで結論が出ました
はい、撤収ーｗ
256:デフォルトの名無しさん
13/05/03 22:21:32.60
なんだ Perl のパクリか（棒）
257:デフォルトの名無しさん
13/05/03 22:24:06.89
あれれ～、var宣言があるからクロージャが楽なんじゃなかったの？
その代わり｢普通の｣関数には宣言がいるのか、トホホ…
危険を承知で糞仕様にしたから、あとから継ぎ接ぎ対策したのか
そしたら一層、大量のvar宣言がつくづく無駄でしかないのだが？
258:デフォルトの名無しさん
13/05/03 22:25:36.30
>>257
いいから比較して書けよ
話はそれからだ。
無知なPython厨をいたぶるのは楽しいね～ｗ
259:デフォルトの名無しさん
13/05/03 22:26:25.56
安全モードがデフォじゃないのは危険な操作が普通に必須だからだろうな
260:デフォルトの名無しさん
13/05/03 22:28:24.21
>>259
意味不明。安全モードは英語にしたらsafe modeだ。無知すぎ
261:デフォルトの名無しさん
13/05/03 22:29:17.26
JSのデフォである危険モードを対比して言っただけだから
262:デフォルトの名無しさん
13/05/03 22:30:58.95
どこから危険モードなんてでてきたんだ？
危険モードが有るんだったら
安全モードがあるのかよ？
無いよ。安全モードなんてねｗ
263:デフォルトの名無しさん
13/05/03 22:31:03.56
え？use strictで防げるのか？
JS厨だがそれは知らなかった
通常var忘れるのは防げるが、外の変数とかぶっても防げたのか
264:デフォルトの名無しさん
13/05/03 22:34:47.93
strictって日本語に翻訳したら
安全って単語だが？
ってどや顔していってほしいｗｗｗｗ
265:デフォルトの名無しさん
13/05/03 22:35:45.16
内側の関数に責任を持つのは通常自分なので、ミスさえしなければ
通常問題は起きないのが救い
メリットとデメリットを考えるとメリットの方が大きいけど
クラスだけではjavascriptはとっくに廃れてた
266:デフォルトの名無しさん
13/05/03 22:38:23.25
use strictを使えば通常はvarを強制できる
いきなりスペルミスで変数を宣言してしまうpythonの方がよっぽど危険
267:デフォルトの名無しさん
13/05/03 22:39:54.89
>>262
デフォは危険だろ。そこは反論できないはずだ
だってそれを防ぐ方法を作ってるんだからw
糞言語すぎ
268:デフォルトの名無しさん
13/05/03 22:41:14.88
>>267
頭悪いの？
静的型付け言語が安全って言いたいの？
269:デフォルトの名無しさん
13/05/03 22:43:15.91
>>248
そもそもpython以外でこれができない有名言語ってあるの？
270:デフォルトの名無しさん
13/05/03 22:44:28.11
静的言語は動的言語より安全だと思うけど
静的言語でもスペルミスによる意図しない変数の変更は防げないだろうねｗ
で、デフォで危険な事実は否定できてないなあ
271:デフォルトの名無しさん
13/05/03 22:44:33.40
少なくとも、C/C++、Java、Schemeは出来る
272:デフォルトの名無しさん
13/05/03 22:45:10.61
そういえば、Haskellは代入自体が出来ないな
273:デフォルトの名無しさん
13/05/03 22:45:21.36
>>266
> いきなりスペルミスで変数を宣言してしまう
どんなコード？
274:デフォルトの名無しさん
13/05/03 22:46:36.11
>>273
test = 2
teest = 3 #ああ、testを変えたつもりが新しい変数に！
275:デフォルトの名無しさん
13/05/03 22:46:41.67
>>263
ここで暴れてるのは偽JS厨だから
276:デフォルトの名無しさん
13/05/03 22:47:13.79
>>274
それは危険だなｗｗｗｗ
277:デフォルトの名無しさん
13/05/03 22:47:59.28
>>274
もっとちゃんとしたコードにしてくれよ
うちのvim + pyflakes だと、宣言だけして未使用の変数は
警告で色付けされるから一目で分かるんだよ
278:デフォルトの名無しさん
13/05/03 22:50:15.59
>>277
よくわからんが、こうすればいいのか？
test = 2
use(test)
teest = 3
use(teest) #変数名の間違いに気づかず補完してしまった！
279:デフォルトの名無しさん
13/05/03 22:51:32.54
>>263
どういうこと？
280:デフォルトの名無しさん
13/05/03 22:51:37.52
>>278
補完するときに候補が複数でる(testとteest)から気付くよ
もっと真面目に考えてくれよ
281:デフォルトの名無しさん
13/05/03 22:52:03.00
アンチJSの人は結構有用なレスしてくれるようになったな
人格批判ばかりするのとは別人か
282:デフォルトの名無しさん
13/05/03 22:54:28.40
>>280
補完は言語の機能ではありません。
283:デフォルトの名無しさん
13/05/03 22:55:04.20
>>280
じゃあ、補完じゃなくてコピペで
284:デフォルトの名無しさん
13/05/03 22:55:13.05
JS厨は何人もいるだろうが、アホなJS厨は一人しかいないと思ってる
そこでここのアホなJS厨（中傷されてるお前だよ）に聞きたいのだが
お前は以外にもアホなJS厨（毎日一日中妄想垂れ流し野郎）はいるのか？
お前みたいなのが複数人いるとかさぶいぼ立つけどアホなJS厨は何人いる？
285:デフォルトの名無しさん
13/05/03 22:56:42.63
>>284
多分、お前は俺も中傷してるけど、他の奴も中傷してると思う
現実とはそんなもん
286:デフォルトの名無しさん
13/05/03 22:57:02.77
なめJS厨はスペルミスによって外部変数が変更されうるという事実に気づかないのだろうか
287:デフォルトの名無しさん
13/05/03 22:59:06.53
JS厨は優しさが垣間見える
あまり他人の中傷はしない
288:デフォルトの名無しさん
13/05/03 22:59:37.30
>>285
つまり、今はライブラリないけど将来は必ずあるとか、
google様が考えた言語と違うから糞言語とか言ってるJS厨が複数人いるのか。うわあ
JS厨やべーな・・・
289:デフォルトの名無しさん
13/05/03 23:01:10.82
JS厨は最初は句読点で平静を装って妄想を垂れ流すが
痛いところを疲れると草を生やして開き直って煽りまくる
290:デフォルトの名無しさん
13/05/03 23:01:26.58
>>288
お前が中傷してるのはもっと前からだろう？w
291:デフォルトの名無しさん
13/05/03 23:02:17.13
>>282
補完って言い出したの>>278だが……
それはともかく、エディタやツール類のサポートは一切考慮しないってこと？
ライブラリの件と同じく、そういうのが大事だと思うが……
292:デフォルトの名無しさん
13/05/03 23:02:49.86
>>289
それが一人だと思ってるのか
良く規制に引っかからないな
IP使い分けてるのか
293:デフォルトの名無しさん
13/05/03 23:03:43.54
スペルミスは言語の責任じゃないけど
これだけ使われてる言語にしてはまともな開発環境がないのが問題だよな
いっそブラウザに載せればいいのに
今でもChromeのコンソール使うと一応保管や保存できるが
前使った時はどうも挙動があやしいのでやめた
新しいファイルは作れないから
一旦別のエディッタで作ってからみたいになるし
294:デフォルトの名無しさん
13/05/03 23:04:33.28
>>291
ちなみに278は283のレスをしてるだろ
295:デフォルトの名無しさん
13/05/03 23:05:24.80
>>290
JSは奇跡の言語とかJSで凄い時代になるとか気持ち悪い煽動を始めた辺りから
叩いてるけど懲りずに毎日同じ妄想を垂れ流してる奴が
お前以外にいるのか？おそろしい
296:デフォルトの名無しさん
13/05/03 23:07:18.07
あ、あとスペルミスはuse strictして
JSエンジンの設定弄ればV8でもFFのやつでも警告でたはず（実行前に）
JSでも静的解析はできるがevalとかがある都合上OFFになってる
297:デフォルトの名無しさん
13/05/03 23:08:28.58
高機能化して欲しいのになんでブラウザ？
一番高機能なIDEであるVSがブラウザで動いてるところを想像できない
298:デフォルトの名無しさん
13/05/03 23:08:41.67
>>293
右クリックの保存の挙動が怪しいの？
今は多分大丈夫と思う
Chrome Canary使ってるけど
299:デフォルトの名無しさん
13/05/03 23:08:55.20
>>294
補完が使えるのにコピペなんてしないから、
もっと現実味のある理由を考えて
300:デフォルトの名無しさん
13/05/03 23:09:52.95
>>295
俺の前は知らんが、今は俺一人だ
ちなみに俺はソース書いてるJS厨
301:デフォルトの名無しさん
13/05/03 23:10:47.73
vimプラグインの補完は凄いと聞く。俺は数行の編集でしか使わないけど
あと最近はsublimeのステマをやたら聞く
302:デフォルトの名無しさん
13/05/03 23:11:20.89
JSでvarつけ忘れて外部変数とぶつかったらどうなるの？教えて！警告でるの？
303:デフォルトの名無しさん
13/05/03 23:11:48.81
>>299
実はダブルクリックの方が補完より速い場合あるから
マウス毛嫌いしてないで試してみ？
vimだから嫌いそうだけど
304:デフォルトの名無しさん
13/05/03 23:12:23.20
sublimeは実際凄いよ
vimよりいいかも
305:デフォルトの名無しさん
13/05/03 23:13:25.80
>>300
ソース書くって、今日も例を示せと数十回言ったけど返ってきた記憶がない
306:デフォルトの名無しさん
13/05/03 23:14:37.56
>>305
まあほとんどJSのソースしか書いてないからな
たまに議論のついでにちょろっと小さいコード片をいれるくらい
307:デフォルトの名無しさん
13/05/03 23:17:00.39
デタラメを重ねすぎて狼少年にしか見えない
308:デフォルトの名無しさん
13/05/03 23:17:21.27
>>297
デバッガとセットになってて欲しいし
HTML上で使う場合はブラウザ使うし
HTMLの画像とか他のファイルも一元管理できた方がよくない？
>>298
今度試してみるかな
とは言え最近はNode.jsばっかり書いてるんだけどね
Node.jsでもブラウザをデバッガとして使うんだけど
ココら辺ももう少し連携しやすくして欲しいなあ
>>302
出ないよ
それで出たら親スコープの変数触れないじゃん
そうじゃなくて明らかに出てきてない変数から代入しようとしてたりするケースみたいなのは
JSエンジンのオプションで出せるようにできる
あとはvarを必至にすることでスペルミス軽減
309:デフォルトの名無しさん
13/05/03 23:17:47.57
クラスターのプログラム書くときにベクトルのライブラリをググったら
sylvesterとかいうのしか引っかからなかったから
数値計算は相当苦手なのはわかった
まあ低機能だから適当に説明読んで即使えたけどw
310:デフォルトの名無しさん
13/05/03 23:18:48.12
だからさ、親と子で宣言子付けるのが逆なんだよね
それで意味もなくvarだらけのコードになる
311:デフォルトの名無しさん
13/05/03 23:20:04.26
「normって何？」と言ってるJS厨がいて数値計算は相当苦手なんだなあと思った
312:デフォルトの名無しさん
13/05/03 23:21:19.40
俺みたいに理系の院行ってるならノルムは当然知ってるけど、それ以外の一般人は
普通に分からんだろうね
313:デフォルトの名無しさん
13/05/03 23:21:56.12
>>310
何言ってるのかさっぱりわからない。
クロージャーは、関数外部の変数を見れたらいけないと言いたいのか？
それはもはやクロージャーではない。
なぜならクロージャーの要件の一つが外部の変数を見れること。
314:デフォルトの名無しさん
13/05/03 23:22:37.48
>>311
知ってるか知ってないかの違い
ググればわかるようなことを
自慢げに言われてもなｗ
315:デフォルトの名無しさん
13/05/03 23:22:44.91
>>313
pythonが真のクロージャを備えていないことが
よっぽどコンプレックスなんじゃないの
316:デフォルトの名無しさん
13/05/03 23:25:11.17
Pythonに真のクロージャがないとか
JSのクロージャは危険じゃないとか
言ってる奴はアホだろ
317:デフォルトの名無しさん
13/05/03 23:25:46.24
なんか1周回って戻ってきたな
Pythonのレキシカルスコープがちょっと変わってるんで、それを調べてから書き込んだほうがいい
JS厨の俺としてもうんざりですよ
318:デフォルトの名無しさん
13/05/03 23:26:21.82
Javaで内部クラスをクロージャとして使うと
外部スコープはfinal変数しか参照できないけど、
そんな感じで、読むのは良いけど書くのはダメってのは
わりとありがち
319:デフォルトの名無しさん
13/05/03 23:27:56.20
>>314
自慢じゃなくてかなり基本的なことだから、共通基盤が違うんだなあと
ノルムと言って伝わらない人は確かに科学的な計算しないと思う
320:デフォルトの名無しさん
13/05/03 23:27:56.92
pythonでも一応外部の変数を「見る」ことはできたはず
代入が出来ないだけ
321:デフォルトの名無しさん
13/05/03 23:29:53.60
>>318
F#とかもそうなんだっけ
そういう安全装置は意味あるし、pythonのスコープがおかしいって指摘が微妙だよな
322:デフォルトの名無しさん
13/05/03 23:30:47.60
>>319
そいつは本当に自分が知らないことを聞いているのか
一般的な事柄としてそういう疑問があると言ってるのか、
そしてついでにいえば、そいつがどのレスと同一人物なのか
もう少し注意深く見た方が良い
323:デフォルトの名無しさん
13/05/03 23:31:14.37
外部変数に代入したくないときに明示するか（var）、
代入したいときに明示するか（nonlocal）の違いじゃないの？
激しくどうでもいい
324:デフォルトの名無しさん
13/05/03 23:31:45.32
>>318
それってfinalじゃなくても良くなるって話を随分前に聞いた覚えがあるけど、
Java7でもまだだっけ？
325:デフォルトの名無しさん
13/05/03 23:32:15.33
Pythonってどうしてそういう仕様にしたんだろう
当然良いことも悪いこともあると思うが
自分には他の言事の差別化が大きいのかなと思ってしまう
326:デフォルトの名無しさん
13/05/03 23:33:03.21
もしかして、pythonが簡潔を売りにしてる割にはself地獄なのも似たような思想なのかね
危険だとか
327:デフォルトの名無しさん
13/05/03 23:35:13.75
>>323
JSのが明らかに危険なのにどうでもいいってｗ
>>322
それこそ本当にどうでもいいです。
科学的なコードに対して一般的に聞くことにどんな意味が？
JSで書いたほうが良いと言ってた奴だったと思うよ
328:デフォルトの名無しさん
13/05/03 23:36:21.07
Python節、まあいいと思うよ
でも外側のスコープ変数変更出来ない方が普通だとは思わないな
変更されない、方を特殊に扱った方が自然だと思う
JSだってそれはできるし
329:デフォルトの名無しさん
13/05/03 23:38:22.45
>>328
それは超初心者レベルのプログラミングも分かってないってこと
意図しない副作用に注意するなら、変更する場合に明示するほうが自然だろ
330:デフォルトの名無しさん
13/05/03 23:38:27.76
>>327
レス見てきたけど、趣旨としては一般的なことだね
normは確かに数学の用語だけど、norm以外にもいろいろ挙げてる
から意味はあるね
normを揶揄するのは揚げ足取りの類い
331:デフォルトの名無しさん
13/05/03 23:39:53.56
>>285
変更不可な変数の宣言と混同してる
332:デフォルトの名無しさん
13/05/03 23:39:58.67
>>329
確かに
これはnonlocalの方が優れてるわ
まあselfは気に食わないけど
333:デフォルトの名無しさん
13/05/03 23:40:33.94
>>324
final変数しか参照できないって不便だよな。
for(final int i : list) {
//クロージャー呼び出し
}
for(int i : list) {
final int i_ = i;
//クロージャー呼び出し
}
いちいちfinal付けるかfinalつけた変数に代入しないといけないんだよな。
334:デフォルトの名無しさん
13/05/03 23:41:43.58
>>329
自分で書いておいてその程度の事が意図しないとかいう感覚がわからない
内側のスコープにその変数を使ってるもんだと思って、
実際には無くて、外側のいじっちゃいけない同名の変数を
意図せず弄って問題が起きることがあるってこと？
簡単な具体例を説明して欲しい
335:デフォルトの名無しさん
13/05/03 23:42:38.02
>>333
拡張forでfinal宣言するのは常識
> Java セキュアコーディングスタンダード > 01. 宣言と初期化 (DCL)
DCL02-J. 拡張 for 文のループ変数は必ず final 宣言する
URLﾘﾝｸ(www.jpcert.or.jp)
336:デフォルトの名無しさん
13/05/03 23:42:51.63
>>334
滅多に起きないけど、varを忘れてしまった場合にありうる
337:デフォルトの名無しさん
13/05/03 23:44:09.47
>>335
マジか
これは良い情報
まあ仕事じゃレビューでfinalとってくれって言われるのが落ちだろうけど
338:デフォルトの名無しさん
13/05/03 23:45:06.87
>>324
Java8で、final値だと自明な場合はfinalを書かなくても
final変数として参照できるようになる、らしい
339:デフォルトの名無しさん
13/05/03 23:45:58.38
クロージャが呼ばれるときその中身は見えないし、その変数はそのクロージャ以外でも使われるのなら
変数の中身は当然追いにくくなるし、クロージャは基本的にメリットない気がする
なんで引数で渡したりしないの？
340:デフォルトの名無しさん
13/05/03 23:46:33.01
>>336
あー、言いたいことはわかった気がするけど
ちょっといろいろと仮定が都合良すぎるな
確かに一昔前なら実際起きてそうなことだと思うけど
今は皆慣れてコーディングスタイルとかも良くなってきてるし
そのためにstrictmodeもあるしね
341:デフォルトの名無しさん
13/05/03 23:48:11.95
strict modeの存在自体が危険性を示唆してるし
なんで普通の関数にそんなものを付けなきゃいけないのか謎
クロージャにだけ付ければ良いし、そしたらvar宣言自体が無駄
という結論ではダメですか
342:デフォルトの名無しさん
13/05/03 23:49:43.39
クロージャを普通に使うJSではそれが逆に大変になるということだろうな
343:デフォルトの名無しさん
13/05/03 23:52:10.68
>>339
それはさ、クロージャをクラスに置き換えても同じことが言えるんじゃない？
344:デフォルトの名無しさん
13/05/03 23:52:23.01
var付け忘れというより、varつけて宣言した変数を使うつもりで変数名タイプミスして
グローバル変数になるとかのパターンが、かなり危険だね
なので"use strict"が導入された
>>341
"use strict"は関数毎につける必要はないよ
実質モジュール単位で有効にすればいい
345:デフォルトの名無しさん
13/05/03 23:52:59.24
>>341
どういうこと？
今話してた意図せずスコープリークしてしまうのを防ぐ役目があるじゃん？
クロージャにだけ固いスコープが必要？
よくそのメリットがわかんないな
346:デフォルトの名無しさん
13/05/03 23:53:54.26
>>344
だからさ、それ本当にuse strictで防げるのか？
俺の手元のテストコードがおかしいのか？
347:デフォルトの名無しさん
13/05/03 23:54:23.89
>>343
クラスは変更される変数と独立してないだろ
348:デフォルトの名無しさん
13/05/03 23:55:28.33
>>345
クロージャはコードが長くなりがち。
長いコードはスコープが広いのと同じことになる。
つまり何処で変数を変更しているかわかりにくい。
影響範囲を狭くするために
外のスコープに一切アクセス出来ない
クロージャ（？）が必要。
これをクロージャと呼ばないとかどうでもいい
違う名前でいいから、そういうものが必要。
349:デフォルトの名無しさん
13/05/03 23:55:53.00
use strict で防げる派と防げない派がいるけど
350:デフォルトの名無しさん
13/05/03 23:56:01.24
>>347
メソッドはフィールド変数と独立してるじゃん
同じじゃないの？
外側のクラスに囲まれてるから独立してないというのなら、
クロージャだってさらに外側のクロージャに囲まれているの
だから独立してない
351:デフォルトの名無しさん
13/05/03 23:57:09.50
だからさ、varつけて宣言した変数を使うつもりで変数名タイプミスして
それが偶然グローバル変数とバッティングした場合は
use strict付けてても無力ってことだろ
そんなレアケースどうでもいいわ
352:デフォルトの名無しさん
13/05/03 23:57:31.88
>>346
varで宣言してない変数を触ろうとするとエラーになるんだから
意図しない外側の変数やグローバル変数を弄ることがないってことでしょ？
それでも何か不満があるの？
>>348
クロージャは即時関数とも重なるから
むしろだいたい短いと思うんだけど
353:デフォルトの名無しさん
13/05/03 23:57:58.80
>>351
varを付け忘れた変数が外側とバッティングする場合はそこまでレアではない
ただ、これもレアっちゃレアだと思うが
354:デフォルトの名無しさん
13/05/03 23:58:11.69
>>349
タイプミスして
グローバル変数の宣言になるパターンは防げる
宣言済みの外部変数へのアクセスになるのは防げない
355:デフォルトの名無しさん
13/05/03 23:59:44.13
宣言済の変数もゲッター、セッター使えば一応防げる
356:デフォルトの名無しさん
13/05/04 00:02:52.85
お前らと話していると、静的型付け言語のほうが
優れていると言ってるとしか思えなくなって来るな。
人間ミスをする生き物だ。ミスしても謝ればいいだけ。
誰もそれを責める権利は持っていない。
ミスが怖いならコンピュータにでもなれよ。
357:デフォルトの名無しさん
13/05/04 00:03:35.37
クラス内のメソッドはクロージャで、だからselfを付けるってこと？なるほど
358:デフォルトの名無しさん
13/05/04 00:04:36.54
オブジェクトなら簡単に代入参照制限できるし外部関数化もできるけど
プリミティブ型はちょっと面倒だな
まあPython-JSコンバータつくるときはいいかも
359:デフォルトの名無しさん
13/05/04 00:12:48.16
>>308
使ったことないけど、Cloud 9とかintelliJ IDEAってのが良いらしい。
ただ、sublimeもlintやdev toolと連携すればそこそこいけるし、
セットってのがそんなに利点かなあ
360:デフォルトの名無しさん
13/05/04 00:13:13.68
まあスコープ浸透しない変数が本当にあった方がよくてそれで速度向上するんなら
ES.strawmanくらいには挙がってないとおかしいんだが
361:デフォルトの名無しさん
13/05/04 00:15:26.73
速度向上？
362:デフォルトの名無しさん
13/05/04 00:16:09.51
>>359
最近段々とChromeがOS化してきちゃってさ
というか９割の時間Chromeを全画面表示してるし
363:デフォルトの名無しさん
13/05/04 00:16:25.04
Colud 9 IDE
URLﾘﾝｸ(www.publickey1.jp)
凄い時代だよなあ
クラウドでIDEとか
Javascriptすげえ
364:デフォルトの名無しさん
13/05/04 00:19:51.95
>>361
初期のconstみたいに実装に思わぬ負担となる場合がある
浸透しないとその分内側は軽くなると普通思うが
前例があるからどうなるのか心配
普通の変数と変わらない程度なら実装のコンパクト化を考えるといらない
365:デフォルトの名無しさん
13/05/04 00:22:14.41
>>364
いや、誰も速度の話なんてしてなかったように思えるのに
急に速度向上の話になったからビックリしただけ
366:デフォルトの名無しさん
13/05/04 00:23:47.20
>>356
どうだろうねえ
静的型付けの方がより安全ではあるけど、動的でも
だいぶ頑張れるしねえ
むしろ柔軟性を考えるとデメリットかもしれない
静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
367:デフォルトの名無しさん
13/05/04 00:26:41.58
> 静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
そうか？
jQueryのキモは、セレクタ文字列から、jQueryオブジェクト型を返すだけだろ？
普通に型つきオブジェクト指向のやり方だと思うけど。
368:デフォルトの名無しさん
13/05/04 00:29:22.65
静的言語でjQueryの＄関数を実装するとかマジキチ
業界を破門レベル
369:デフォルトの名無しさん
13/05/04 00:29:32.64
>>356
このスレではスコープ関係の議論をしてて、スコープについては
ダイナミックスコープより安全なレキシカルスコープが主流になってるから
あんまり違和感が無かった
370:デフォルトの名無しさん
13/05/04 00:30:34.51
>>365
誰もしてなくてもJSにとって速度向上はものすごく大事なことなの
371:デフォルトの名無しさん
13/05/04 00:31:25.32
>>367
例えばプラグインがメソッドを追加しまくってるけど、
単純な継承では継承の順番を指定しないと駄目だろ
372:デフォルトの名無しさん
13/05/04 00:31:48.16
なぜならJSはリアルタイム性が重視される用途によく使われるから。
GUIとか、その動作速度でさくさく感が大きく変わる。
373:デフォルトの名無しさん
13/05/04 00:33:23.12
>>371
プラグインがメソッド追加するのは
jQueryの失敗点の一つだと思ってるけど。
だって、名前かぶったらどうするのさ？
374:デフォルトの名無しさん
13/05/04 00:35:19.53
VS+C#は戦車、スクリプト言語は拳銃くらいのイメージ
375:デフォルトの名無しさん
13/05/04 00:35:20.19
>>368
いいじゃない
jQuery-C++とかjQuery-Javaとか
JQuery $ = new JQuery();
$(”ul li .hoge”).css("color", "red");
がJavaのコードでも別に良いじゃない
376:デフォルトの名無しさん
13/05/04 00:37:20.94
>>373
noconflictとかでなんとかならんかね
実際そんなに問題出てる？
377:デフォルトの名無しさん
13/05/04 00:39:15.03
>>375
全然よくない
本当は型によって振る舞いを変えるのは
JIT妨害の代表格みたいなものだからJSでも最悪なんだよ
でもjQueryはブラウザとHTMLの柔らかさや非互換性があるからこそ便利なもの
静的言語でやると悪いことしか産まない
378:デフォルトの名無しさん
13/05/04 00:39:50.55
>>375
だよな。作れない理由が思いつかない。
>>376
noconflictは単にjQueryのエイリアスである$を使わない（jQueryだけを使う）
ってだけの意味でしか無いので、何も効果はない。
379:デフォルトの名無しさん
13/05/04 00:41:11.04
>>377
具体的な理由何一つ言ってないなｗ
380:デフォルトの名無しさん
13/05/04 00:41:20.53
>>374
C, C#, Java あたりは PC で
スクリプト言語はスマホやタブレットなのかもしれない
381:デフォルトの名無しさん
13/05/04 00:41:31.07
Javaで$(”ul li .hoge”)という書き方は内部で$メソッドを定義しない限り
残念ながら出来ない
どうしても、$.$()になる
Cなら出来るだろうけどそれこそ破門レベルw
あと当然extends JQueryはそれぞれ別のクラスになってしまう
382:デフォルトの名無しさん
13/05/04 00:42:49.00
>>378
名前かぶったら別の変数にして使えるじゃん
383:デフォルトの名無しさん
13/05/04 00:42:57.27
jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
静的言語で移植するのは１００％無理
ブラウザのDOM関数叩ける、V8のライブラリとして作るのならなんとかというところ
384:デフォルトの名無しさん
13/05/04 00:44:09.85
>>381
$が関数名として使えないとかいう話？
使えるけど？
> $.$()になる
あぁ、staticインポート機能を知らないのか。
385:デフォルトの名無しさん
13/05/04 00:45:24.42
>>382
えとね、今はプラグインのメソッド名の話してるの
$オブジェクトを別の変数で使う話してないの
386:デフォルトの名無しさん
13/05/04 00:45:25.53
>>384
ああ忘れてたわ
すまん
387:デフォルトの名無しさん
13/05/04 00:46:12.63
>>385
だから、プラグインのメソッド名がかぶるなら、$オブジェクトを別の変数に入れて
それぞれ使い分ければ良いだろ
388:デフォルトの名無しさん
13/05/04 00:47:39.72
staticだと、それこそnoconflictができないよね
まあ何か考えれば方法があるのかもしれないが
389:デフォルトの名無しさん
13/05/04 00:47:41.21
無理だって言われてるのに意地張るなよ
それともチューリング完全だからとかいうのか？
390:デフォルトの名無しさん
13/05/04 00:50:57.95
>>387
お前馬鹿か？
$をhogeって変数に入れても
プラグインのメソッドは、
$にもhogeにも作られるんだよ。
$はオブジェクト、つまり参照型なんだから
コピーは作られない。
391:デフォルトの名無しさん
13/05/04 00:54:19.33
>>388
noconflictもstaticもお前勘違いしてるだろ。
無理に参加しなくていいよｗ
392:デフォルトの名無しさん
13/05/04 00:55:26.14
>>390
deep copyすればいいじゃない
393:デフォルトの名無しさん
13/05/04 00:58:42.91
>>383
> jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
> 静的言語で移植するのは１００％無理
JavaとJavaScriptでthisの扱いが違うのだからそれは当然
100%同じインターフェースで実装できるわけじゃないが
実用上困らないレベルでは実装可能。
例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
394:デフォルトの名無しさん
13/05/04 00:59:10.41
>>390
何がどう出来ないんだ？
単なるオブジェクトだよ？
クローンも作れるし、それぞれに独自の拡張が出来る
プロトタイプベースの言語に慣れてないのか？
395:デフォルトの名無しさん
13/05/04 01:00:22.56
jQueryはJavaでは無理って言われて
ついにJavaドカタが本性を現した、の巻
396:デフォルトの名無しさん
13/05/04 01:00:54.91
>>392
プラグインはjQueryにメソッドを生やす。
jQueryをコピーして作られたjQuery2にメソッドは生やさない。
jQueryに生えたメソッドをjQuery2に移し替えても
プラグインはjQuery2ではなくjQueryを参照する。
397:デフォルトの名無しさん
13/05/04 01:02:33.63
まあ実際にjQueryを真似たjsoupというJavaライブラリが存在するしな。
実証されてることをうだうだ言っても意味が無い。
398:デフォルトの名無しさん
13/05/04 01:03:16.21
>>393
>100%同じインターフェースで実装できるわけじゃない
>例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
別に昨日が実装できるのは当たり前なんですけど？
あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
399:デフォルトの名無しさん
13/05/04 01:03:40.69
URLﾘﾝｸ(gihyo.jp)
2012年1月27日，XMLをjQuery風に操作できるJavaライブラリ「jOOX 1.0.0」が
リリースされました。jOOXはLukas Eder氏が開発したもので，流れるような
インタフェース（Fluent Interface）（注1）で記述していくことでXMLの走査や
編集が行えます。Java 5から導入されたStatic Importをうまく使っており，
非常に簡潔な記述を実現しています（リスト）。
リスト jOOXを使ったコード
Document doc = $(new File("foo.xml")).document();
Match m = $(doc).find("book").filter(ids("book1", "book2"));
400:デフォルトの名無しさん
13/05/04 01:04:18.51
>>398
> あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
具体的には？
401:デフォルトの名無しさん
13/05/04 01:04:39.83
>>396
プラグインAでjQueryにメソッドをはやしてから
別名変数にクローンを保存
ブラグインBでjQueryのメソッドを上書き
余裕
402:デフォルトの名無しさん
13/05/04 01:05:30.54
URLﾘﾝｸ(code.google.com)
// Parse the document from a file
Document document = $(xmlFile).document();
// Wrap the document with the jOOX API
Match x1 = $(document);
// This will get all books (wrapped <book/> DOM Elements)
Match x2 = $(document).find("book");
// This will get all even or odd books
Match x3 = $(document).find("book").filter(even());
Match x4 = $(document).find("book").filter(odd());
// This will get all book ID's
List<String> ids = $(document).find("book").ids();
// This will get all books with ID = 1 or ID = 2
Match x5 = $(document).find("book").filter(ids(1, 2));
// Or, use css-selector syntax:
Match x6 = $(document).find("book#1, book#2");
// This will use XPath to find books with ID = 1 or ID = 2
Match x7 = $(document).xpath("//book[@id = 1 or @id = 2]");
403:デフォルトの名無しさん
13/05/04 01:05:59.81
そのjOOXとやらのプラグインはどうなってるの？
イベント操作は？
404:デフォルトの名無しさん
13/05/04 01:07:39.75
// This will add a new book
$(document).find("books").append("<book id=\"5\"><name>Harry Potter</name></book>");
// But so does this
$(document).find("book").filter(ids(5)).after("<book id=\"6\"/>");
// This will remove book ID = 1
$(document).find("book").filter(ids(1)).remove();
// Or this
$(document).find("book").remove(ids(1));
405:デフォルトの名無しさん
13/05/04 01:08:41.21
>>403
落ち着け
これはXMLをjQuery風に操作できるライブラリ
406:デフォルトの名無しさん
13/05/04 01:08:52.25
>>396
jQueryを読み込んでから各プラグインを読み込む間
いつでも変数弄ったり自由にできるんだけど
JQ=DC(jQuery)
プラグイン１を読み込む
[jQuery1,jQuery]=[jQuery,DC(JQ)]
プラグイン２を読み込む
[jQuery2,jQuery]=[jQuery,DC(JQ)]
プラグイン３を読み込む
[jQuery3,jQuery]=[jQuery,DC(JQ)]
でぜんぶ別々のプラグインが使える
407:デフォルトの名無しさん
13/05/04 01:14:14.18
>>403
イベント？ Javaはブラウザじゃないんだが
一体誰がイベントを送信するんだ？
408:デフォルトの名無しさん
13/05/04 01:15:37.17
イベントとブラウザかどうかは関係ないんだが
タイマー、ソケット、エラーとかいろいろ発生源はある
409:デフォルトの名無しさん
13/05/04 01:17:55.92
>>380
それは汎用性という観点だろうけど、C/C++は別格
汎用性:
C/C++ >>>>>> C#, Java, JVM言語 >>>>>>>>>>>>>>>>>>>> スクリプト言語
プログラミング能力:
Lv6 => C/C++使い
Lv3-5 => C#, Java, JVM言語使い
無能力者～Lv1 => スクリプト言語使い
410:デフォルトの名無しさん
13/05/04 01:18:22.60
>>408
> タイマー、ソケット、エラーとかいろいろ発生源はある
だからなんでそれをjQuery風ライブラリで扱わないといかんの？
お前が言ってるのはsetTimeoutでできることを
jQueryでやりましょうって言ってるようなもんだよ。
jQueryが扱う対象はDOMのイベント
DOMのイベントはブラウザが発生させる。