[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/ 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 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厨っていうか、壮絶なアホが一匹いる

---

---

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

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