[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/ 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だと思い込んでいた？ｗｗｗｗ 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 で、どこがどう優れてるんだ？ 前スレのお題をその２つで綺麗に書いてくれ goはかなり特殊な言語でオブジェクト思考プログラミングすら、他の言語のようにはしない コードは冗長になりがち。Cの代替になれるかどうか dartとかもうどうしようもない言語だと思うが 113 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 16:31:44.95 ] 誰もJava Disに参加しないのであったｗ 一人でやってろアホ 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厨のフリして煽ったら 見ないうちに荒れやがってｗ ほんと仲間はすぐに寄ってくるな。 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 お前は毎日それを言って過ごしてるってことだなｗ 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 ] 失敗したら説得力ねーよｗ 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 そうかね、一番目は明らかに固有じゃない気がするし、３番や４番も 同類の問題が出てきそうだけど >>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 187 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:25:34.62 ] >>184 Googleの天才は採用しなかった、他の天才は採用した なんでGoogleが一方的に正しいんだ？馬鹿？ 188 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:25:39.44 ] >>186 メソッドのオーバーロードがあるJavaなんて Googleの天才達によって否定済みですけど？ 189 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:31:49.51 ] >>186 実際Javaの汎用性やそれに伴うライブラリの豊富さは強いだろ それに対してPythonはPythonの良さがあると言えるわけ 一ミリも知らない言語をgoogleが作ったから良いと言っちゃう馬鹿と一緒くたにしないでほしいわけ 190 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:38:56.67 ] >>187 一方的に正しいとか、まあそこまでは言ってない 他が天才かどうかは知らんが、仮にそうだとしても、意見が割れてるのは確かだ その時点で、内包表記の有用性はかなり怪しいものになるんだよ >>188 そうだね 人気がある方が正しいと考える君の考えは ここでもGoogleに否定されたわけだ DartやGoは今のところ人気はない ただ、だからといって正しくないとは言えない >>189 結局仕様の良し悪しじゃないじゃんw 191 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:42:25.20 ] >>184 一番目も、C++の場合、オーバーロード無しで演算子が出来る事は Cと同じだから低コストと思うワケで、 高コストな操作（文字列やリストの連結等）が演算子で書ける言語の場合 演算子だから低コストなんて思わないよ だから前提からしてC++固有とまでいかなくても、最近の言語には当てはまらない話 192 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:42:58.87 ] >>190 Javaの仕様の悪いところやPythonの仕様の良いところも馬鹿なお前と違って言えるし それは議論されつくされてる。リスト内包表記が無い方がいいとか言ってる馬鹿はいないけど 実際正解してないgoogleを正解例としてpython批判してる馬鹿が 問題となるコードを例によって一回も出してくれないしこれからも一生出さないと思うと呆れるしか無い 193 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:44:20.90 ] JavaとJavascriptがウンコって結論になれば 別にGoが最高の言語という結論になっても構わない俺がいるw 194 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:45:04.15 ] 言語を一ミリも知らないのはどっちだw 本当は、「まともなプログラマーなら、内包表記や演算子オーバーロードを採用して当たり前！ 主要な新しい言語は全部そう！」って思ってたんだろw 正直になれよw >>191 一番有名な例であるiostreamからして高コストなioだからなあ 195 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:45:51.61 ] JS絶賛から逃げ出して苦し紛れにGoogle擁護してるゴミがどこまで頑張るか観察したい 頑張ってると言っても正しさは一切ないけど 196 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:47:42.52 ] >>195 まあ別に逃げ出してないし、 俺がどこまで頑張ろうとJSの時代が来ることは変わらんわけでw 指をくわえてみてると良いよw

---

---

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

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