[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/ 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 197 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:48:40.93 ] >>193 そこなんだよな 逆に言えばJS厨はJSが糞だという結論に落ち着きかけたから Googleをスケープゴートとして使ってるだけ Googleの言語はまだまだだし、JSが科学で使い物にならないという事実は明らかなのに 198 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:50:12.24 ] >>197 いつ結論が出たんだよw お前が勝手に勝利宣言してるけど、 真実はライブラリがないだけで、JS自体はちっとも糞ではなく、 これからどんどんライブラリが出ることも確定してるってことだ 199 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:50:48.10 ] >>196 ほら、今がショボいことを認めたくないから現実逃避を続けてるじゃん 200 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:52:08.63 ] はい、今はライブラリがなくて完敗宣言っと 201 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:52:14.65 ] え？確定してんの？ 202 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:53:26.65 ] >>199 いや、今はしょぼいよ 数値計算のライブラリがないという点でな ただ、ウェブ関連は充実してるし、これから 数値計算もこれからしょぼくなくなるけど >>200 今だけなw 良かったなw >>201 まあ分かる奴には分かる ヤバいよ マジで来る 203 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:54:20.74 ] 確定してるわけないだろ。大規模なライブラリはブラッシュアップに時間がかかるし 万が一、数年後にまともなライブラリができるとして今JSを使う必要性はまったくない 完成してから吠えてくれw 204 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:55:10.59 ] 数値計算で今JS使わなくても良いのは確か というかまず、充実したC++ライブラリのラッパーがくるんじゃないかね 205 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 18:58:32.08 ] だからー、演算子オーバーロードがないと式の記述が不自然になるんだってｗ 　JSは一生ねーよ 206 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 19:00:33.36 ] C++のラッパー作るだけで良ければ今頃どの言語にもscipy相当があるよ Railsクローンが色んな言語にあるようにな なのに、scipy相当がPythonにしか無い時点で察しろって話 207 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 19:01:27.55 ] >>205 まあそういう奴も安心 なんせ別言語が定義できるくらいだから、別の言語が使えるようになるよ 俺は直接JS使うけどw 208 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 19:04:09.87 ] >>207 君は科学技術計算に縁のない底辺ドカタなんだから 最初から関係ないよ いつまでもJSを使っててくれて構わない 209 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 19:05:36.81 ] >>208 確かにあんまり縁がなかったわw 万一今科学計算が必要でも別にC++やpython使うから良いけどw 210 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 19:07:10.00 ] 使うなよ気持ち悪い 211 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 20:27:01.00 ] Scipyっての知らなかったけど、面白いな 遺伝的アルゴリズムとかもあるのか ちょっと遊ぶのにいいかもしれん このスレでJavascriptの良さを力説するのも無駄じゃなかったw 212 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 20:51:38.70 ] 馬鹿の上にこの気持ち悪さ これは凄い 213 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:42:10.23 ] 伸びてるから何かと思ったら 数値計算向けの言語pythonで数値計算のお題出して しかもライブラリ借りて解いて喜んでいるのか dom操作のお題出したあとjQuery使って解いて Javascriptスゲーと言ってるようなもんだわ 214 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:45:20.48 ] しかも、Javascriptに一時間程度で簡単に解かれちゃってたw 215 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:46:20.69 ] Linuxのシステムの一部でも使われてるのにそれは無理があるわなあ 実際JSってあらゆる普段使いに向かないんだからさ 216 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:48:29.92 ] まあ、pythonが数値計算向けってのはちょっと違うな もともとは汎用スクリプト言語 JSはブラウザ用言語だったが、今となっては広範囲に使える汎用言語 ただ、数値計算は凄いライブラリがある関係上、pythonが今のところ有利 217 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:49:01.94 ] >>213 御題出したのはJS厨 で、解いたんだからお前も解けという流れ 218 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:49:07.31 ] いやJS厨もライブラリ絶賛しまくりだったのに 返り討ちに合った途端にライブラリがある問題はダメってなんなん 自演下手過ぎだし 219 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:50:26.18 ] その何でもかんでもJS厨に見える癖、何とかならんのか しかも一人か二人だと思ってるようだし 220 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:51:28.84 ] じゃあ論破された馬鹿な主張を繰り返すのやめろよ馬鹿 221 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:51:41.74 ] JS厨っていうか、壮絶なアホが一匹いる 222 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:52:15.14 ] 論破された主張って何のことだよw 223 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:52:38.61 ] JSが科学技術分野で追い付くことはないし 不確定な遠い未来しか武器がないなら黙ってろ 224 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:52:50.82 ] >>221 中身のない中傷を繰り返すアンチJSのことか 225 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:54:34.52 ] >>223 そう思うなら反論する必要がない 余裕こいてれば良いだろ 226 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:55:04.23 ] ライブラリがあれば、どの言語も同じようにかけることが 証明されてしまったからな。 これからどう反論する？ 227 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:55:19.39 ] JSがnumpyに追い付く証拠も出さずに妄想を毎日垂れ流す限り一生中傷され続ける 自分がデタラメを並べてると気付いてないわけじゃないだろ 悪ふざけはやめろキチガイ 228 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:55:44.21 ] お題だしたのがJS厨って怪しいな scipyやnumpy知ってたっぽいし、むしろpython厨っぽい 229 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:56:46.68 ] ライブラリの差が 言語の差になってるうちは 言語の優位性なんて語れないぞ。 言語だけの範囲で語ろうぜ。 230 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:56:49.77 ] >>225 お前のペテンを批判してるだけ 231 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:58:00.15 ] 不確定な未来について好き勝手に論じるなら、 科学技術計算でJavascriptがPythonに追いつく未来より、 asm.jsで中間言語に落ちぶれる未来の方が 遥かに実現する可能性が高そう 少なくとも、asm.jsは既に存在するわけだし、Googleも興味を持ってる 232 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:58:01.92 ] 言語の差はライブラリで埋まる 証拠は数々上がっている。 233 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 21:58:55.14 ] 状況証拠みたいなものしかないけど、Javascriptが熱いというのはマジだってば https://github.com/popular/starred https://github.com/languages 234 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:02:22.45 ] JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語と結論でただろ JS厨がpythonに対してスコープは絞るべきとか言ってたのは今考えたら悪うしかない かなり危険な糞仕様 235 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:02:27.12 ] >>232 Javascriptは全然マシだけど、Javaはウンコすぎて無理 関数オブジェクトすらないゴミでは話にならない やっぱり言語による差はあるよ 236 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:02:53.80 ] >>231 numpyみたいにコアの処理をCに任せればいいだけ 237 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:03:41.07 ] >>235 それがならないんだなぁ。 証拠は数々上がっている。 238 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:03:58.27 ] >>236 うん、簡単だね 今すぐ実装してきて良いぞ 239 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:04:42.82 ] >>234 ちょっと抽象的すぎて良く分からんな Lintで検出できないようなもんかね？ 240 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:06:16.82 ] >>239 変更するのがデフォだからテストも通る 241 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:06:24.11 ] >>237 おいおい、JavascriptとJavaを一緒にするなよ ぶっちぎりでゴミだよJavaは 関数オブジェクトが無いんだよ？信じられんわ 242 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:07:06.29 ] >>234 > JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語 それ、お前が変更しまくらないと 出来ない無能なんですーって 言ってるだけじゃないかｗ 243 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:07:44.91 ] >>241 はいはい、必死だね。 世の中にはクラスすらない言語もあるんだよ。 244 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:08:55.68 ] 俺頭悪いので分からんから、具体例で説明してくれ 245 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:11:07.96 ] >>234 それがないとクラスも作れないカス言語 pythonでは明示するしコミュニティでは極力避けてるのに JSは文化的に積極的にやってる。というかそれがないと無理なんだろうな だとしたら、意味もなく大量のvar宣言せずにクロージャの宣言をしたほうが良い 246 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:12:40.24 ] Java使いでもEgor Kulikovみたいな奴いるしな Egorの1/10もプログラム書けない奴が大半だろ 言語というよりやっぱ個人差の方が大きい 247 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:13:49.80 ] >>245 自分の無知をさらけ出して恥ずかしくないの？ｗ JavaScriptにはグローバル変数すら無いしね。 248 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:14:11.17 ] >>245 ちょっと具体例で説明して欲しいんだが、 こんな感じのこと？ a = 1; function() { 　a=2; //ああ、変更できちゃったよ！ } 249 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:14:14.08 ] >>244 Cでグローバル変数を使い回すようなもの それを便利とか言って多様するのは プログラミング初心者と競技プログラミングだけ それ以外でもやむを得ず使う場合はあるが 普通は危険な割にメリットが少ないから避ける 250 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:15:53.62 ] >>247 実際に関数を呼び出せば関数外の変数を書き換えるのが当然の言語だろ 違うなら反論よろ 251 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:16:14.21 ] >>249 ちょっと良く分からん pythonのコード例とjavascriptのコード例を対比させて説明してくれないか？ 252 名前：デフォルトの名無しさん mailto:sage [2013/05/03(金) 22:16:21.63 ] >>248 そうそうそれのこと。 グローバルな変数を書き換えることができて それを防ぐ方法がない。 これがJSというカス言語

---

---

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

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