[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 05/04 14:57 / Filesize : 153 KB / Number-of Response : 594
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

[JavaScript,PHP] スクリプト言語33 [Perl,Python]



1 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 13:55:49.86 ]
JavaScript, Perl, PHP, Python, …
スクリプト言語をすべて扱うスレッドです。
最強のスクリプト言語は、どれよ?
さあ、死ぬまで語りやがれ!!!

■ スクリプト言語の用途
簡易Webアプリ、シェルスクリプト

■ スクリプト言語の特徴
1レスで書ける程度の使い捨ての短いコードなら作成が容易だが
実行速度は劣っており、2人以上の開発、1000行を超えるソースコード、
10ファイル以上からなるソースコード、大規模になればなるほど
修正時の影響範囲の把握が困難で簡単なスペルミスが
発見しづらいバグを生み、IDEなどの静的解析ツールの適用が難しく
何から何まで人手でやらなければならずプログラマの負担が大きい。
・インタプリタ
・動的型
・正規表現
・クロージャ
などを利用できるものがある。

1レスには収まらないが100行程度の短いコードはここで
ttp://play.island.ac/codepaste/

toro.2ch.net/test/read.cgi/tech/1365250318/

86 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:08:26.82 ]
>>84
JavaScriptが低レベルな計算と切り離されてるってのがよくわからん。
高レベルな計算は出来るってことだよな?

低レベルな計算ってなんのことだ?

87 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:09:23.36 ]
Javascriptは最近までブラウザの中の言語だったからね
C言語なんかと連携できるようになったのも最近の話だし、
パフォーマンスが良くなったのも最近
だから、確かに今はクリティカルな数値計算をしようとする人が少ない
ただ、V8の登場、node.jsで状況は一変した
兆しは確実にある

88 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:10:13.69 ]
int型の計算のことだろ?

まあそれもInt32ArrayなどのTyped Array(ブラウザに既に実装済み)で
できるようになったけど。

89 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:10:32.25 ]
やっぱり低レベルが通じない馬鹿がJSを擁護してた

90 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:11:40.95 ]
確かに低レベル。前スレからJS厨のレベルの低さが目立つ

91 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:11:51.06 ]
JavaScriptが登場したのは1995年だからね。

重要なのは開発スピード
この数年は、衰えるどころかスピードアップしている

92 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:12:29.03 ]
確かに新しい言語に内包表記も演算子オーバーロードも入れないGoogleは低レベルだよね

93 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:12:34.04 ]
アンチJSが低レベルだと認められる理由。

何も内容がないレスをするから。

94 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:14:29.17 ]
>>82
JS厨な俺としても、その記法で必須なxの初期化を省いてるのが気になる



95 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:15:29.73 ]
>>94
というか、JS厨の俺から見るとvar省いてるのとin使ってるのが気になる
つか、こいつJS知らんだろ

96 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:15:34.86 ]
>>92
それ、どこがpythonより優れてんの?天才集団とか権威主義のカスは死んでいいぞ
使ってから喋れ

97 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:16:23.64 ]
pythonもJavascriptも使い倒した上で天才集団が新しく作った言語に
文句あるの?
権威主義ですが何か?

98 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:16:53.44 ]
あ、アホな方のJS厨はJSすら知らないのかw

99 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:18:02.42 ]
まあ本質とは全く関係のないくだらん揚げ足取りだからあえて指摘しなかったけど

100 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:18:21.58 ]
>>97
開き直ったら正当化してんのかよ
goとdartを使ってから擁護しろと言ってんたよ

101 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:18:32.30 ]
いつから>>82がJavaScriptだと思い込んでいた?wwww

102 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:19:05.78 ]
自分がろくに書けない言語の厨になるとはレベル高いなw

103 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:19:16.68 ]
敵は皆JS厨じゃあー!

見るもの全部、JavaScriptじゃあー!

104 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:19:42.60 ]
訂正:正当化してんのかよ→正当化されるのかよ



105 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:20:50.23 ]
ぶっちゃけ、アホの方のJS厨は
LLスレだった頃から度々書き込んでたJavaドカタだと思う

106 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:21:28.19 ]
>>100
俺が使おうが使うまいが真実は変わらんだろ?

107 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:22:37.88 ]
>>105
説得力ありすぎてこまるw
邪魔すぎてスレタイ変更で追い出されたからな

108 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:22:39.59 ]
>>105
ぶっちゃけ、アホな方のアンチJSは妄想癖があると思う

109 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:25:01.17 ]
>>106
何が真実かも説明できないやつが何言ってんだ?お話にならない

110 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:26:28.34 ]
>>109
真実は、PythonもJavascriptも知り尽くした天才集団が新しく作った言語に
演算子オーバーロードと内包表記が採用されなかったということ

つまり、こんな機能はいらないんだよ
こんなゴミ機能で喜んでる奴はバカ

111 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:30:16.43 ]
>>107
皆で一斉にJavaをdisり始めたら、急にJavaを擁護し始めそうだねw

もしかして、内包表記を執拗にdisるのも、Javaに無い機能をdisってるのかも

112 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:31:20.34 ]
>>110
で、どこがどう優れてるんだ?
前スレのお題をその2つで綺麗に書いてくれ
goはかなり特殊な言語でオブジェクト思考プログラミングすら、他の言語のようにはしない
コードは冗長になりがち。Cの代替になれるかどうか
dartとかもうどうしようもない言語だと思うが

113 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:31:44.95 ]
誰もJava Disに参加しないのであったw

一人でやってろアホ

114 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:32:36.78 ]
Java8も延期になったし、言語自体も古くさくてゴミ
いまさらdisるのも馬鹿馬鹿しい程ウンコ



115 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:33:06.81 ]
最近思ってもみなかったところから白熱するねこのスレ

116 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:33:09.82 ]
敵を見つけないといけないから可哀想だよね。
このスレではJSが敵か。
敵を叩くことで精一杯。
何もためになる話をしない。

117 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:34:58.48 ]
>>112
俺がその二つで奇麗に書こうが書くまいが真実は全く変わらないのだが?
説得力が欲しいならお前がどうしても汚くなってしまうことをソースで書いてみせれば良いだろ
俺はやらないよ
天才集団が新しく作ったというだけで十分な説得力だし

118 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:36:13.97 ]
>>117
> 俺はやらないよ

コード書けない低能だからねw
やりたくても無理だね

119 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:36:45.00 ]
どうせ、112は長くなった行数を見て冗長だとか可読性が無いとか言い出す奴だろ

120 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:37:31.11 ]
JS厨あらためgo厨 or Dart厨かw

121 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:38:25.10 ]
goは何か少ない機能だな。必要最低限というか
リスト内包表記的なことはmapでやるっぽいな
その方法はpythonでもできるけどリスト内包表記を使った方が可読性面で良いとされてる

122 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:38:27.83 ]
>>118 >>120
中身を語らず人格批判
自分より先に人にソースを要求
これがアンチJS厨

123 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:39:08.18 ]
>>121
javascriptもそんな感じ
クロージャ使ってmap

124 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:40:02.35 ]
表記はあくまで表記であり
機能ではないから
その機能は別の表記できるんだよな。



125 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:40:31.23 ]
>>122
その逃げ回りっぷりを批判されてるってわからんの
自分より先にってなんだよ。こっちに示すもんねーだろ馬鹿か

126 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:43:13.74 ]
>>123
今回の流れでJS触ったがクロージャはマジで当たり前のように外部変数壊しててやばいと思った
リスト内包表記はそんなことできない

127 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:44:14.00 ]
JSも嫌いじゃないから、こんなアホが使ってると思いたく無かったわ
あーよかった
そうかー、JS厨じゃなくて偽プログラマだったのか

128 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:44:49.72 ]
>>126
むしろそれが出来るからこそ、クラスの代替になるんだけどね
クロージャはJSの中でもみんなが絶賛してる機能
メリットの方が大きい

129 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:45:36.59 ]
そりゃJSプログラマがみんなこんなんだったら世界が崩壊してる

130 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:48:05.71 ]
>>128
それは制約上の妥協点でしかなくで
関数でクラスの代替?とかやってるのが端から見たら終わってて
普通のクラスじゃダメな理由がわからない

131 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:50:26.44 ]
>>125
お前も逃げてるじゃん
示すものがない?
天才集団に楯突くからには、ソース示した方が説得力あるだろw
Pythonのソースだってお前が書いたソースじゃないだろ
アンチJSはまさに虎の威を借る狐

>>130
まあ分かりにくいだろうね
これのおかげで、ブラウザのイベント処理とか、非同期処理とかが
うまく扱えて、インターネットと非常に相性が良かったわけで
今また盛り上がってきてるのにつながるわけだけど
実際に書かないとこれは実感できない

132 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:58:15.53 ]
> 天才集団に楯突くからには、
> まさに虎の威を借る狐

ブーメランすぎるwww

133 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:59:01.77 ]
>>131
JS厨ってお前みたいな馬鹿しかいないんだな
何がどう優れてるのか示せない限りただの幻想じゃん
JSでは勝てないから自分も知らない言語に逃げるクズ

134 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:01:05.12 ]
JSというかHTML5の熱烈指支持者、アルファブロガーっていうのキュレーターだっけ?アーリーアダプターか?スタバでMac使ってる連中の言うことを真に受けちゃったんだろう。



135 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:02:55.40 ]
ちょっと俺がJS厨のフリして煽ったら
見ないうちに荒れやがってw

ほんと仲間はすぐに寄ってくるな。

136 名前:デフォルトの名無しさん mailto:sage [2013/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 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:16:46.17 ]
JS厨は毎日これ
妄想を垂れ流す、今勝てないから未来(妄想)にすがる、見知らぬ権威に頼る
自分の知識は関係ないと言う、無知だからデタラメしか言えない
筋金入りのペテン師、といっても始めから誰も信用してないけど
ライブラリの違いが致命的であることを理解できない馬鹿
railsかなんで流行ったと思ってるんだ。まあCと相性悪い点も汎用言語としては論外だし
妄想が実現することは一生ないけど

138 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:16:48.84 ]
>>133
少なくとも、内包表記と演算子オーバーロードがないことくらいは知ってたから
お前よりはマシじゃね?w

139 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:18:46.95 ]
>>138
なんで劣ってる点を挙げて優れてると主張するんだ?キチガイか?

140 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:20:06.60 ]
>>137
お前は毎日それを言って過ごしてるってことだなw

141 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:20:39.57 ]
>>139
劣ってる?
採用されていないんだから、必要ない機能ってことだろ
つまり、劣ってないということ
むしろある方が劣ってるってこと

142 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:20:45.28 ]
>>136
そのライブラリの有無が重要なんだと思う
ライブラリを除いた狭義の言語だけ扱っていても
その言語で「実際に」何ができるのかはわからないし

143 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:22:40.01 ]
>>142
まあもちろんそうなんだけど、これは歴史的に見てしょうがない気がする
数値計算はまだはっきりと苦手分野
状況が一変し始めてる段階

144 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:24:08.12 ]
>>142
ライブラリを比較って意味では、scipy使えばコード書く必要すら無いんだよねkmeans...



145 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:27:42.11 ]
>>141
それは反証できない、お前お得意の詐欺だか
現にそれらの機能は広く使われて恩恵がある
リスト内包表記やC#のLINQがないほうが良いとか言ってる天才はいない
だからお前がないほうが良い理由を説明できないならそれはただの欠点でしかない

146 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:28:58.06 ]
>>144
kmeans関数さえあればね
それってライブラリさえあればJSでもなんでも変わらんということだけど
>>145
採用されなかった
その事実だけで十分説得力を持つから俺はそれ以上何か言う気はないね
詐欺だと勝手に思いたければ思ってれば?

147 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:31:15.87 ]
>>146
説得力のある説明ができないなら、リスト内包表記や演算子がない点については欠陥があるということだから
それ以外で何がなぜ優れてるのか説明しないとお前の論は何も通らない
天才が失敗した、それだけ。

148 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:32:44.74 ]
ライブラリさえあればー、誰か膨大なライブラリを用意してくれー、誰かー、JSをまともな言語にしてくれー

149 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:33:04.97 ]
かつてSunに居た天才達は、Javaをデザインするときに
「ブルーカラーでも使えるように」様々な機能を削ってJavaを作った

何が言いたいか分かるな?

150 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:34:42.67 ]
>>147
説得力ある説明してるしw
何を言っても無駄とはまさにこのことw
まさか、Pythonを使いこなしているGoogleがそれらの機能を知らないはずがないしな
Googleコーディング規約でも実はネストした内包表記禁止してるくらいだし、
少なくともまともに検討した結果、無い方が良いと判断したのは確実
仮にお前の言うように失敗だったとしても、それなりに根拠があるってこと
本当はそんなに喜ぶほどの価値はないんだよ

151 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:35:06.78 ]
>>149
ポインタは危険だったね。メモリ管理は大変だったね

つまりデメリットを説明しないかきりお前とGoogleは完全に間違ってるということ

152 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:37:00.25 ]
>>151
Googleが完全に間違ってるかどうかは
俺が説明できるかどうかにかかってるのか

すげえな俺
神かw

153 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:37:49.42 ]
内包表記は数学の素養がない馬鹿にとって可読性が低い
(自分が使わなくても、他人が書いたコードは読む必要がある)
だから馬鹿対策で機能を削った

自分達はPythonやC++を使うから、馬鹿は低能向けの言語使っとけってことだ

154 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:39:05.83 ]
>>153
C++には内包表記はないぞ
Pythonにしても、自分たちが使うコーディング規約で内包表記は単純なものだけにしましょう
と言ってるし



155 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:39:17.91 ]
>>150
なんでGoogle事情に詳しいお前が採用しなかった理由を説明できないんだ
あと演算子オーバーロードの恩恵を理解できないとかバカすぎ
いろんな自作クラスに対して直感的な記述は不可能になる
これは科学技術分野では特にありがたい機能だ。だから、Googleの言語はJS同様に劣った言語なんだな

156 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:41:32.06 ]
>>154
演算子オーバーロードがある

157 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:44:46.83 ]
>>149
> 何が言いたいか分かるな?

嘘を言いたいんでしょう?

158 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:45:07.43 ]
>>155
そう思いたければ思えば良い
科学技術に長けたGoogleがC/C++の代替を目指した言語で採用しなかった
お前より頭がいい奴はそう思ってるってだけ

>>156
そして、スタイルガイドにこう記述することになる
「特殊な状況を除き、演算子をオーバーロードしてはいけません。」
理由も載ってるからググってこいよw

159 名前:デフォルトの名無しさん mailto:sage [2013/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 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:45:58.74 ]
PHPer(何を議論しているのかさっぱり分からん・・・^p^)

161 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:46:46.09 ]
>>160
次のターゲットかい?
お前も懲りないね。

162 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:48:46.84 ]
>>159
can beって書いてあるように
あくまで良い場合もあるってだけ
言語に組み込むほどの良さでもないんだろう
悪い面の方がむしろあるってことなんだろうね

163 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:49:07.66 ]
内包表記のネストを避けるのはgoogleだけじゃなくpythonコミュニティ全体の話だ
そんな暗黙のルールはどの言語にもある

>>158
Pythonはお前より頭の良い奴が作ったんだから
お前はPythonに一切の文句を言えないはずだが?

164 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:50:20.65 ]
python開発者より馬鹿な奴がpython批判っておかしくないですか
お前が何を言ってもpythonの設計は正しいということですよね
誰よりも頭が悪いお前は何しにここに来てんだ



165 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:50:32.33 ]
>>162
その通り。can beって書いてあるように
あくまで複雑な内包表記でも読み難くなる場合もあるってだけ

166 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:51:57.20 ]
>>158
え?goは科学技術分野の言語ではないと思うが
googleに詳しいお前の公式見解を聞きたい

167 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:52:47.13 ]
まあ、python作った当時の作者なら俺の方が
新しい言語を知ってる分、この分野に関しての知恵はあるだろうな

pythonの人とやらも今新しく言語を作るなら内包表記採用しないかもなw
googleの場合は歴史的な試行錯誤の末、今採用してないわけでw

168 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:55:25.43 ]
リスト内包表記やLINQを批判してるまともなプログラマなんて見たことないよ

169 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:57:04.12 ]
俺達はいつまでこの既知外の相手をしなければいけないの?

170 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:59:47.53 ]
ちゃっかりLINQを混ぜて何がしたいんだ
LINQなんて採用されてなさすぎだろw

171 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 17:59:48.74 ]
>>167
googleが間違った。正解だというのなら証拠見せろ
また未来に頼るのか?お前そればっかだな
事実ベースで語るならそんなのを正解として出すほうが馬鹿。天才だからーって阿呆か
goやdartの設計思想も説明できないしさあ、お前ゴミすぎるだろ。反論できる?

172 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:01:01.04 ]
>>171
いや、だから、俺は証拠を見せる必要がないと思うから
しないだけ
今の時代にGoogleが間違ったってかw
へー説得力ありますなあ

173 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:06:14.61 ]
実際Google言語はまだ主流じゃないし、馬鹿みたいに正しい言語と言われても嘘っぱちにしかならない

174 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:07:46.41 ]
JSでは勝てなくて逃げ惑う、説明を求められ逃げ回る。これだけ



175 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:08:20.49 ]
golang.jp/go_faq#overloading

> メソッドと演算子のオーバロードをサポートしていない理由は?
>
> メソッドを呼び出す際に、メソッドの型をいちいち調べしなくてよい方がシンプルです。
> 他の言語に接した経験から言えることは、同じ名前で、かつシグネチャが異なるメソッドの寄せ集めを持つことは、
> ときに役に立ちますが、混乱を招くだけで充分に機能しません。
> 型の中で、メソッドが名前だけで検索できるよう制約を課すことは、Go言語の型システムを単純な仕組みにする上での大きな決断でした。

Javaを含む殆どの静的型付けOOPLを全否定だな
これがGoogleの天才が出した結論か

176 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:09:39.92 ]
それが吉と出るか凶と出るかわからないのだが、お前が正しいと思う根拠は何?

177 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:11:17.57 ]
googleがこう言ってるからって自己の無いただのgoogleの代弁者のくせにこの底抜けバカっぷりがすごい
何も理解せずに行き当たりばったりで喋るからこうなる

178 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:11:58.07 ]
主流になることには失敗するかもな
仕様の善し悪しより人気や宣伝の面もあるし

ただ、自分たちが使うことも念頭において開発してる言語だし、
真剣に検討した結果であることは間違いない
仮にそう決断したことが悪い判断だったとしても、
お前が言うように手放しで喜べるような単純なもんでもなく
議論が裏にあるってことだ
少なくとも、浅い考えで「内包表記がないー、オーバーロードがないー
話にならないー、全然違うー」
なんて話ではない
むしろ、そんなものあってもなくても実は生産性に大差はないんだよというのが
説得力を持つ

179 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:13:26.78 ]
> 演算子のオーバーロードに関しては、絶対に必要というより、あれば便利という程度であり、
> 採用しないことでシンプルさを保ちました。

そしてメソッドのオーバーロードは結構批判的なのに、
演算子オーバーロードはそうでもないという

180 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:13:36.88 ]
失敗したら説得力ねーよw

181 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:14:02.28 ]
>>179
C++スタイルガイド見てこいよ
かなり批判的

182 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:16:57.58 ]
>>181
見て来た

> 演算子をオーバーロードするとコードは直感的にわかりやすくなりますが、次のような欠点もあります。
>
> ・コストの高い操作なのに、コストの安い組み込み操作だと思わせてしまう。
> ・オーバーロードした演算子を呼び出している場所を見つけるのが非常に困難になる。== の呼び出しを探すよりも Equals() を探す方がはるかに簡単です。
> ・ポインタにも機能する演算子があるが、これらはバグを生みやすい。Foo + 4 がやることと、&Foo + 4 がやることは全く違います。コンパイラはどちらにも警告を出さないため、デバッグは非常に難しくなります。
> ・オーバーロードには想定外の悪影響もあります。たとえばクラスが単項 operator& をオーバーロードしていると、クラスは安全に前方宣言できません。

基本的に2番目以外はC++固有の問題だと思う

183 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:18:47.69 ]
>>178が必死に話を有耶無耶にしようとしてるところ悪いけどさあ
一長一短あるならリスト内包表記がなければ優れてるとかいう馬鹿な主張をしてる
お前は本当に救いようがない馬鹿だということを自白してることになるし
リスト内包表記やオーバーロードの有用性は未だに否定されてないのだが

184 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:20:36.34 ]
ぶっちゃけ、内包表記と演算子オーバーロードがなくても
>>136レベルの簡潔さにはなるんだろ
十分許容範囲だわw
理解に大きな差が出るとは思えない

>>182
そうかね、一番目は明らかに固有じゃない気がするし、3番や4番も
同類の問題が出てきそうだけど

>>183
有用性とデメリットがあってそのバランスを取った結果採用されなかったってことだろw



185 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:20:49.34 ]
C++の演算子オーバーロードはややこしい
Pythonはシンプルだし。むしろ無いと困る
というかどうせ代替のメソッドを定義することになるが
こうすると式に一貫性がなくなる

186 名前:デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:23:32.13 ]
まあ、人気が言語の良し悪しだと言いたいなら、
お前の嫌いなJavaがPythonより良い言語ってことになるけどいいの?w






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<153KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef