[JavaScript,PHP] スクリプト言語33 [Perl,Python] JavaScript, Perl, PHP, Python, …
スクリプト言語をすべて扱うスレッドです。
最強のスクリプト言語は、どれよ？
さあ、死ぬまで語りやがれ！！！
■ スクリプト言語の用途
簡易Webアプリ、シェルスクリプト
■ スクリプト言語の特徴
1レスで書ける程度の使い捨ての短いコードなら作成が容易だが
実行速度は劣っており、2人以上の開発、1000行を超えるソースコード、
10ファイル以上からなるソースコード、大規模になればなるほど
修正時の影響範囲の把握が困難で簡単なスペルミスが
発見しづらいバグを生み、IDEなどの静的解析ツールの適用が難しく
何から何まで人手でやらなければならずプログラマの負担が大きい。
・インタプリタ
・動的型
・正規表現
・クロージャ
などを利用できるものがある。
1レスには収まらないが100行程度の短いコードはここで
ttp://play.island.ac/codepaste/ http://toro.2ch.net/test/read.cgi/tech/1365250318/ さりげなくスレタイからRubyを抜くなw
残念入らなかった。
前スレ
>>999 > リスト内包は集合論とかの数式を見慣れた人には分かりやすいよね
短い場合はそうだと思うけど、
長くなった場合は見にくいよ。
多分その理由は思考の流れと逆に書くからだと思うな。
ディレクトリのように、前から絞り込んでいくやりかたと
後ろから絞り込んでいくやり方がある。
長い場合は、前から絞り込むほうが理にかなっている。
例えばドメインは、後ろから絞り込んでいくやり方だけど
パスの部分は前から絞り込んでいくやり方になってる。
住所を真似して後ろから絞り込んだのはいいが、
途中（パスの部分）で破綻したのではないかな。
GUIのメニューやCSSのセレクタも前から絞り込んでるね。
英語の文化のせいで後ろから絞り込むやり方が存在するけど、
論理的に考えたら前から絞り込むほうがいいのだろう。
日本語は基本的に前から絞り込む文化。
リスト内包表記
>>1 は勝手に内容を変えてんじゃねーよ
スクリプト言語に対する偏見が強すぎるわ
ていうか、前スレでコード書けなかったアホだろ
>>1 は？
「俺はコード書くほど暇人じゃない」とか言っといて
わざわざ文章改悪してスレ立てまでやってんのかよ
ビックリするほど暇人じゃねーか
少し修正
>>8 で思ったんだけど
[x * 2 for (x in A) if (x % 2 == 0)]
こう書いたほうが見やすくね？
こうじゃねーの？
>>5 数学の素養の無いドカタは
無理に内包表記を使う必要は無いよ
>>11 典型的だね。
何も言えないから、とりあえず馬鹿にして満足感を得る。
別にどれも変わらねーよ
リスト内包表記の方が効率が良い
効率が効率がって、公式実装がC言語の100倍遅い言語で言われましてもw
効率は変わらんよｗ
集合は {x| x は偶数 } って書くから x が左に来てないとすわりが悪いかな
うーん、そういう文脈でCを使われるのはなぁ
haskellの内包表記こそが至高
リスト内包表記はリストを返すが、繰り返し文でリスト末尾に追加していくより効率が良い
>>20 >>11 典型的だね。
何も言えないから、とりあえず馬鹿にして満足感を得る。
どうだろう双方向リストなら末尾付加のコストは普通に定数だよね
{x| x は偶数 }
ジェネレータ式の効率が良すぎてどうでもいい
ちょっと簡潔にかけるとか数学に似てるとか
上で言われてるようにジェネレータにもできるからメモリ効率も良い使い方ができる
>>24 関数呼び出しのコストがあるのでオーダーで考えてるんだろうけど実際は係数って無視できないくらい効いてくるので。
>>25 それなら見やすいと思うね。
でもごちゃごちゃしていたら見にくい。
そこが内包表記の限界なのだろう。
30 ：
デフォルトの名無しさん ：2013/05/03(金) 15:04:38.96
>>28 定数オーダーの末尾付加によるリストの作成が無視できないような状況で
pythonとかって、あんまり想像がつかないんだけど
内包表記は数学の式まで完結化できる
>>25 え？式の外でdomainを明示してるんじゃなかったら
数学でもdomainを書く必要があるよ？
>>28 > 上で言われてるようにジェネレータにもできるからメモリ効率も良い使い方ができる
ループで回してもメモリ効率いいと思うけど？
本質的には値を入れた配列を作らずに
値を計算で求めるってだけだし。
>>30 リスト内包表記を使った方が効率が良いという話
実際に比べればわかるし、内包表記を使わない理由がないのだが
{x| x∈A ∧x≡0 (mod 2)}
>>34 その効率の良さも無視できるレベルって話
ジェネレータも呼び出しを遅延させてるだけで
実際はそんな便利な場面は少ない
お前が無視したいだけだろw無視する意味がわからん
これも数学だよね？
>>37 勉強しなおしたが答えは同じだった。
はい、君のターン
○○しろとかいって、自分のターンを飛ばすやつ多いよねｗ
ぼくのかんがえた究極数学猿真似言語
var x = [];
>>42 うん。だから
頭から絞り込む方法も
後ろから絞り込む方法も
所詮慣れでしかないんだよ。
で、何故か世の中の多くは
頭から絞り込んでいく方法。
多くの人が慣れているのは
頭から絞り込む方法だってことさ。
数学かどうかは、記号を使うかどうかだから
記号を使って頭から絞り込むのが一番見やすい。
>>35 情報量が違う式を比べて「数学と比べて複雑」とか言ってるアホ(
>>25 )が滑稽だなって
やっぱりドカタはそういう基本的な事が分からないんだね
>>44 これのほうが良い。だんだん内包表記に似てきたね。
for(i in A) if(isEven(i)) x.push(i);
>>48 正直、何 が 良 い の か 分 か ら な い
全く同じだろ？
ちょっと簡潔になってるだけだろ
そんなくだらない上っ面だけ見て満足なの？
>>49 V8エンジンなら最適化されてるから、CPythonより速い
forやifの一行でも必ず {} でくくること
>>48 みたいな糞コードを量産するねがJS厨だなあ
>>50 え？ 完結に書くことは重要だよ。
それだけ読む量が少ないってことだから。
>>53 やっとこのスレに気づいたか
いつものアンチJS厨さんよぉｗ
>>54 文字数・行数の少なさと、理解する量の多さは違う
読む量(理解量みたいなもの)と理解するスピードは、
少なくとも俺の場合はほぼ全く一緒なのだが
一行に複数のブロックがあるから気持ち悪いんだな
>>52 リスト内包表記に嫉妬しすぎ。お前の代替案は醜すぎ
>>56 100行コードを読むのと、それを関数にして読む場合の
理解のスピードが同じだって？
じゃあお前は関数使うなｗ
知識を使って読むべきコードを減らすのが関数の利点。
一連のコードを知識に置き換えることで読む量を減らす。
lengthまでiをインクリメントしていく。をinの一言で、
(i % 2)==0 を isEvenの一言にすることで、
読むべきコードを減らして、理解するスピードをアップさせている。
例えば
>>59 意味のあるときは関数使うよ
でも、今回の場合、難解度に差はない
>>57 > その場合、結果が先行して書かれた方がわかりやすい
それは慣れの問題だってさ。
英語と日本語の問題と話が全く一緒になった。
結論を頭に持ってくるのが英語風
結論を最後に持ってくるのが日本語風
>>58 醜すぎの理由が書いてない時点で、お前の嫉妬にしか見えんな。
>>60 Perlだと両方かけるよね。
if (x % 2 == 0) hoge;
と
hoge if (x % 2 == 0);
どっちもコンパイルに通る。
この二つに違いはない。
内包表記はfor文を簡潔にするけど、複雑な処理まで簡略化はしてくれない
x % 2 == 0 は慣用句になってるけど
複雑な処理を簡潔にする魔法があるのかよ
>>65 結局そこなんだよ
ぶっちゃけ、for文が長いと言っても慣用句なんだよ
長い慣用句を簡潔な単語で表したところで、
理解力は上がらないんだよ
タイプ量が少なくて済むけど、コピペとかsnippetとかもあるしねえ
>>67 なにいってんだばか？
処理を実行するのはコンピュータ
正確だから処理が複雑かどうかは関係ない。
人間にとって重要なのは、その処理を
どれだけ簡素に見せられるかどうかだろ。
お前はコンピュータか？人間か？言ってみろ。
>>65 関数化よいよね。しかしアホには限界が…
ちなみにipythonでallclose？と入力したらヘルプが表示されるから安心
986/1001:デフォルトの名無しさん[sage]
2013/05/03(金) 10:13:47.88
>>985 しかし現実は
「allclose？mean？axis？arrayで囲ってる？xsとys交換してから比較？linalg？norm？」
Pythonのコードは知的教養レベルが高い人が抽象的な言葉でわけのわからん議論をしてるのに
似てるw
ただ、その割には他の言語でもたいして大変じゃないんだよなあ
>>67 魔法なんてないよ
だから、大差はない
結局ライブラリの差
pythonは今のところ数値計算のライブラリは揃っているけど
内包表記やらが優れているわけではない
>>68 おいおい、お前の言ってる「長い」は
せいぜい20文字ぐらいで限界だろうがw
>>71 当たり前だろ。りすとこんぷりへんしょんなんて今日びまともな言語なら必ず備えてる
標準的な便利機能でしかない。それをできない言語が劣ってるだけ
for文のように書けるというのはよく考えられてるけどね
内包表記もインデックス演算子のオーバーロードもipythonの使い易さも
>>73 １．それが出来ない言語とは？
２．それが出来ない言語で簡単にかけない例は？
（ライブラリを使って簡単にかけることなら却下）
この二つを説明できて
初めて説得力があるというもの。
>>73 お前、天才集団Googleさんに喧嘩売ってるの？
演算子のオーバーロードなんていらねえ！
リスト内包表記なんていらねえ！
Cのように書けば良い！
>>75 このスレに挙がってるリスト内包表記の代替案とかw
挙げ句にわざわざ醜くしてリスト内包表記に似せる始末
JavaScriptで生まれてるのは
二年後って、JSはずいぶん遅れてるんだねえ。まあそれもお得意の妄想だろうけど
>>79 > このスレに挙がってるリスト内包表記の代替案とかw
> 挙げ句にわざわざ醜くしてリスト内包表記に似せる始末
へ？ 普通の書き方じゃね？
うーん、何処にも変な所が見られない。
for(i in A) if(i % 2 == 0) x.push(i);
>>79 実際要らないんじゃないかねえ
天才集団が作った言語、GoやDartにはどちらもないしさ
Cやフォートランと仲良しの言語じゃないとダメだよ
>>81 でもPythonで作られたものよりか
JavaScriptで作られたもののほうが
今は多いよ。
>>84 JavaScriptが低レベルな計算と切り離されてるってのがよくわからん。
高レベルな計算は出来るってことだよな？
低レベルな計算ってなんのことだ？
Javascriptは最近までブラウザの中の言語だったからね
int型の計算のことだろ？
やっぱり低レベルが通じない馬鹿がJSを擁護してた
確かに低レベル。前スレからJS厨のレベルの低さが目立つ
JavaScriptが登場したのは1995年だからね。
確かに新しい言語に内包表記も演算子オーバーロードも入れないGoogleは低レベルだよね
アンチJSが低レベルだと認められる理由。
>>82 JS厨な俺としても、その記法で必須なxの初期化を省いてるのが気になる
>>94 というか、JS厨の俺から見るとvar省いてるのとin使ってるのが気になる
つか、こいつJS知らんだろ
>>92 それ、どこがpythonより優れてんの？天才集団とか権威主義のカスは死んでいいぞ
使ってから喋れ
pythonもJavascriptも使い倒した上で天才集団が新しく作った言語に
あ、アホな方のJS厨はJSすら知らないのかw
まあ本質とは全く関係のないくだらん揚げ足取りだからあえて指摘しなかったけど
>>97 開き直ったら正当化してんのかよ
goとdartを使ってから擁護しろと言ってんたよ
いつから
>>82 がJavaScriptだと思い込んでいた？ｗｗｗｗ
自分がろくに書けない言語の厨になるとはレベル高いなw
敵は皆JS厨じゃあー！
訂正:正当化してんのかよ→正当化されるのかよ
ぶっちゃけ、アホの方のJS厨は
>>100 俺が使おうが使うまいが真実は変わらんだろ？
>>105 説得力ありすぎてこまるw
邪魔すぎてスレタイ変更で追い出されたからな
>>105 ぶっちゃけ、アホな方のアンチJSは妄想癖があると思う
>>106 何が真実かも説明できないやつが何言ってんだ？お話にならない
>>109 真実は、PythonもJavascriptも知り尽くした天才集団が新しく作った言語に
演算子オーバーロードと内包表記が採用されなかったということ
つまり、こんな機能はいらないんだよ
こんなゴミ機能で喜んでる奴はバカ
>>107 皆で一斉にJavaをdisり始めたら、急にJavaを擁護し始めそうだねw
もしかして、内包表記を執拗にdisるのも、Javaに無い機能をdisってるのかも
>>110 で、どこがどう優れてるんだ？
前スレのお題をその２つで綺麗に書いてくれ
goはかなり特殊な言語でオブジェクト思考プログラミングすら、他の言語のようにはしない
コードは冗長になりがち。Cの代替になれるかどうか
dartとかもうどうしようもない言語だと思うが
誰もJava Disに参加しないのであったｗ
Java8も延期になったし、言語自体も古くさくてゴミ
最近思ってもみなかったところから白熱するねこのスレ
敵を見つけないといけないから可哀想だよね。
>>112 俺がその二つで奇麗に書こうが書くまいが真実は全く変わらないのだが？
説得力が欲しいならお前がどうしても汚くなってしまうことをソースで書いてみせれば良いだろ
俺はやらないよ
天才集団が新しく作ったというだけで十分な説得力だし
>>117 > 俺はやらないよ
コード書けない低能だからねw
やりたくても無理だね
どうせ、112は長くなった行数を見て冗長だとか可読性が無いとか言い出す奴だろ
JS厨あらためgo厨 or Dart厨かw
goは何か少ない機能だな。必要最低限というか
>>121 javascriptもそんな感じ
クロージャ使ってmap
表記はあくまで表記であり
>>122 その逃げ回りっぷりを批判されてるってわからんの
自分より先にってなんだよ。こっちに示すもんねーだろ馬鹿か
>>123 今回の流れでJS触ったがクロージャはマジで当たり前のように外部変数壊しててやばいと思った
リスト内包表記はそんなことできない
JSも嫌いじゃないから、こんなアホが使ってると思いたく無かったわ
>>126 むしろそれが出来るからこそ、クラスの代替になるんだけどね
クロージャはJSの中でもみんなが絶賛してる機能
メリットの方が大きい
そりゃJSプログラマがみんなこんなんだったら世界が崩壊してる
>>128 それは制約上の妥協点でしかなくで
関数でクラスの代替？とかやってるのが端から見たら終わってて
普通のクラスじゃダメな理由がわからない
>>125 お前も逃げてるじゃん
示すものがない？
天才集団に楯突くからには、ソース示した方が説得力あるだろw
Pythonのソースだってお前が書いたソースじゃないだろ
アンチJSはまさに虎の威を借る狐
>>130 まあ分かりにくいだろうね
これのおかげで、ブラウザのイベント処理とか、非同期処理とかが
うまく扱えて、インターネットと非常に相性が良かったわけで
今また盛り上がってきてるのにつながるわけだけど
実際に書かないとこれは実感できない
> 天才集団に楯突くからには、
>>131 JS厨ってお前みたいな馬鹿しかいないんだな
何がどう優れてるのか示せない限りただの幻想じゃん
JSでは勝てないから自分も知らない言語に逃げるクズ
JSというかHTML5の熱烈指支持者、アルファブロガーっていうのキュレーターだっけ？アーリーアダプターか？スタバでMac使ってる連中の言うことを真に受けちゃったんだろう。
ちょっと俺がJS厨のフリして煽ったら
numpy.jsがあったらこんな雰囲気になるんだろうな
JS厨は毎日これ
>>133 少なくとも、内包表記と演算子オーバーロードがないことくらいは知ってたから
お前よりはマシじゃね？w
>>138 なんで劣ってる点を挙げて優れてると主張するんだ？キチガイか？
>>137 お前は毎日それを言って過ごしてるってことだなｗ
>>139 劣ってる？
採用されていないんだから、必要ない機能ってことだろ
つまり、劣ってないということ
むしろある方が劣ってるってこと
>>136 そのライブラリの有無が重要なんだと思う
ライブラリを除いた狭義の言語だけ扱っていても
その言語で「実際に」何ができるのかはわからないし
>>142 まあもちろんそうなんだけど、これは歴史的に見てしょうがない気がする
数値計算はまだはっきりと苦手分野
状況が一変し始めてる段階
>>142 ライブラリを比較って意味では、scipy使えばコード書く必要すら無いんだよねkmeans...
>>141 それは反証できない、お前お得意の詐欺だか
現にそれらの機能は広く使われて恩恵がある
リスト内包表記やC#のLINQがないほうが良いとか言ってる天才はいない
だからお前がないほうが良い理由を説明できないならそれはただの欠点でしかない
>>144 kmeans関数さえあればね
それってライブラリさえあればJSでもなんでも変わらんということだけど
>>145 採用されなかった
その事実だけで十分説得力を持つから俺はそれ以上何か言う気はないね
詐欺だと勝手に思いたければ思ってれば？
>>146 説得力のある説明ができないなら、リスト内包表記や演算子がない点については欠陥があるということだから
それ以外で何がなぜ優れてるのか説明しないとお前の論は何も通らない
天才が失敗した、それだけ。
ライブラリさえあればー、誰か膨大なライブラリを用意してくれー、誰かー、JSをまともな言語にしてくれー
かつてSunに居た天才達は、Javaをデザインするときに
>>147 説得力ある説明してるしw
何を言っても無駄とはまさにこのことw
まさか、Pythonを使いこなしているGoogleがそれらの機能を知らないはずがないしな
Googleコーディング規約でも実はネストした内包表記禁止してるくらいだし、
少なくともまともに検討した結果、無い方が良いと判断したのは確実
仮にお前の言うように失敗だったとしても、それなりに根拠があるってこと
本当はそんなに喜ぶほどの価値はないんだよ
>>149 ポインタは危険だったね。メモリ管理は大変だったね
つまりデメリットを説明しないかきりお前とGoogleは完全に間違ってるということ
>>151 Googleが完全に間違ってるかどうかは
俺が説明できるかどうかにかかってるのか
すげえな俺
神かw
内包表記は数学の素養がない馬鹿にとって可読性が低い
>>153 C＋＋には内包表記はないぞ
Pythonにしても、自分たちが使うコーディング規約で内包表記は単純なものだけにしましょう
と言ってるし
>>150 なんでGoogle事情に詳しいお前が採用しなかった理由を説明できないんだ
あと演算子オーバーロードの恩恵を理解できないとかバカすぎ
いろんな自作クラスに対して直感的な記述は不可能になる
これは科学技術分野では特にありがたい機能だ。だから、Googleの言語はJS同様に劣った言語なんだな
>>149 > 何が言いたいか分かるな？
嘘を言いたいんでしょう？
>>155 そう思いたければ思えば良い
科学技術に長けたGoogleがC/C++の代替を目指した言語で採用しなかった
お前より頭がいい奴はそう思ってるってだけ
>>156 そして、スタイルガイドにこう記述することになる
「特殊な状況を除き、演算子をオーバーロードしてはいけません。」
理由も載ってるからググってこいよw
Google Python Style Guide より List Comprehensions の項を引用
PHPer（何を議論しているのかさっぱり分からん・・・^p^）
>>160 次のターゲットかい？
お前も懲りないね。
>>159 can beって書いてあるように
あくまで良い場合もあるってだけ
言語に組み込むほどの良さでもないんだろう
悪い面の方がむしろあるってことなんだろうね
内包表記のネストを避けるのはgoogleだけじゃなくpythonコミュニティ全体の話だ
そんな暗黙のルールはどの言語にもある
>>158 Pythonはお前より頭の良い奴が作ったんだから
お前はPythonに一切の文句を言えないはずだが？
python開発者より馬鹿な奴がpython批判っておかしくないですか
>>162 その通り。can beって書いてあるように
あくまで複雑な内包表記でも読み難くなる場合もあるってだけ
>>158 え？goは科学技術分野の言語ではないと思うが
googleに詳しいお前の公式見解を聞きたい
まあ、python作った当時の作者なら俺の方が
リスト内包表記やLINQを批判してるまともなプログラマなんて見たことないよ
俺達はいつまでこの既知外の相手をしなければいけないの？
ちゃっかりLINQを混ぜて何がしたいんだ
>>167 googleが間違った。正解だというのなら証拠見せろ
また未来に頼るのか？お前そればっかだな
事実ベースで語るならそんなのを正解として出すほうが馬鹿。天才だからーって阿呆か
goやdartの設計思想も説明できないしさあ、お前ゴミすぎるだろ。反論できる？
>>171 いや、だから、俺は証拠を見せる必要がないと思うから
しないだけ
今の時代にGoogleが間違ったってかw
へー説得力ありますなあ
実際Google言語はまだ主流じゃないし、馬鹿みたいに正しい言語と言われても嘘っぱちにしかならない
JSでは勝てなくて逃げ惑う、説明を求められ逃げ回る。これだけ
http://golang.jp/go_faq#overloading > メソッドと演算子のオーバロードをサポートしていない理由は?
>
> メソッドを呼び出す際に、メソッドの型をいちいち調べしなくてよい方がシンプルです。
> 他の言語に接した経験から言えることは、同じ名前で、かつシグネチャが異なるメソッドの寄せ集めを持つことは、
> ときに役に立ちますが、混乱を招くだけで充分に機能しません。
> 型の中で、メソッドが名前だけで検索できるよう制約を課すことは、Go言語の型システムを単純な仕組みにする上での大きな決断でした。
Javaを含む殆どの静的型付けOOPLを全否定だな
これがGoogleの天才が出した結論か
それが吉と出るか凶と出るかわからないのだが、お前が正しいと思う根拠は何？
googleがこう言ってるからって自己の無いただのgoogleの代弁者のくせにこの底抜けバカっぷりがすごい
主流になることには失敗するかもな
> 演算子のオーバーロードに関しては、絶対に必要というより、あれば便利という程度であり、
失敗したら説得力ねーよｗ
>>179 C++スタイルガイド見てこいよ
かなり批判的
>>181 見て来た
> 演算子をオーバーロードするとコードは直感的にわかりやすくなりますが、次のような欠点もあります。
>
> ・コストの高い操作なのに、コストの安い組み込み操作だと思わせてしまう。
> ・オーバーロードした演算子を呼び出している場所を見つけるのが非常に困難になる。== の呼び出しを探すよりも Equals() を探す方がはるかに簡単です。
> ・ポインタにも機能する演算子があるが、これらはバグを生みやすい。Foo + 4 がやることと、&Foo + 4 がやることは全く違います。コンパイラはどちらにも警告を出さないため、デバッグは非常に難しくなります。
> ・オーバーロードには想定外の悪影響もあります。たとえばクラスが単項 operator& をオーバーロードしていると、クラスは安全に前方宣言できません。
基本的に2番目以外はC++固有の問題だと思う
>>178 が必死に話を有耶無耶にしようとしてるところ悪いけどさあ
一長一短あるならリスト内包表記がなければ優れてるとかいう馬鹿な主張をしてる
お前は本当に救いようがない馬鹿だということを自白してることになるし
リスト内包表記やオーバーロードの有用性は未だに否定されてないのだが
ぶっちゃけ、内包表記と演算子オーバーロードがなくても
>>136 レベルの簡潔さにはなるんだろ
十分許容範囲だわw
理解に大きな差が出るとは思えない
>>182 そうかね、一番目は明らかに固有じゃない気がするし、３番や４番も
同類の問題が出てきそうだけど
>>183 有用性とデメリットがあってそのバランスを取った結果採用されなかったってことだろw
C++の演算子オーバーロードはややこしい
まあ、人気が言語の良し悪しだと言いたいなら、
>>184 Googleの天才は採用しなかった、他の天才は採用した
なんでGoogleが一方的に正しいんだ？馬鹿？
>>186 メソッドのオーバーロードがあるJavaなんて
Googleの天才達によって否定済みですけど？
>>186 実際Javaの汎用性やそれに伴うライブラリの豊富さは強いだろ
それに対してPythonはPythonの良さがあると言えるわけ
一ミリも知らない言語をgoogleが作ったから良いと言っちゃう馬鹿と一緒くたにしないでほしいわけ
>>187 一方的に正しいとか、まあそこまでは言ってない
他が天才かどうかは知らんが、仮にそうだとしても、意見が割れてるのは確かだ
その時点で、内包表記の有用性はかなり怪しいものになるんだよ
>>188 そうだね
人気がある方が正しいと考える君の考えは
ここでもGoogleに否定されたわけだ
DartやGoは今のところ人気はない
ただ、だからといって正しくないとは言えない
>>189 結局仕様の良し悪しじゃないじゃんw
>>184 一番目も、C++の場合、オーバーロード無しで演算子が出来る事は
Cと同じだから低コストと思うワケで、
高コストな操作（文字列やリストの連結等）が演算子で書ける言語の場合
演算子だから低コストなんて思わないよ
だから前提からしてC++固有とまでいかなくても、最近の言語には当てはまらない話
>>190 Javaの仕様の悪いところやPythonの仕様の良いところも馬鹿なお前と違って言えるし
それは議論されつくされてる。リスト内包表記が無い方がいいとか言ってる馬鹿はいないけど
実際正解してないgoogleを正解例としてpython批判してる馬鹿が
問題となるコードを例によって一回も出してくれないしこれからも一生出さないと思うと呆れるしか無い
JavaとJavascriptがウンコって結論になれば
言語を一ミリも知らないのはどっちだw
本当は、「まともなプログラマーなら、内包表記や演算子オーバーロードを採用して当たり前！
主要な新しい言語は全部そう！」って思ってたんだろw
正直になれよw
>>191 一番有名な例であるiostreamからして高コストなioだからなあ
JS絶賛から逃げ出して苦し紛れにGoogle擁護してるゴミがどこまで頑張るか観察したい
>>195 まあ別に逃げ出してないし、
俺がどこまで頑張ろうとJSの時代が来ることは変わらんわけでw
指をくわえてみてると良いよw
>>193 そこなんだよな
逆に言えばJS厨はJSが糞だという結論に落ち着きかけたから
Googleをスケープゴートとして使ってるだけ
Googleの言語はまだまだだし、JSが科学で使い物にならないという事実は明らかなのに
>>197 いつ結論が出たんだよw
お前が勝手に勝利宣言してるけど、
真実はライブラリがないだけで、JS自体はちっとも糞ではなく、
これからどんどんライブラリが出ることも確定してるってことだ
>>196 ほら、今がショボいことを認めたくないから現実逃避を続けてるじゃん
はい、今はライブラリがなくて完敗宣言っと
え？確定してんの？
>>199 いや、今はしょぼいよ
数値計算のライブラリがないという点でな
ただ、ウェブ関連は充実してるし、これから
数値計算もこれからしょぼくなくなるけど
>>200 今だけなw
良かったなw
>>201 まあ分かる奴には分かる
ヤバいよ
マジで来る
確定してるわけないだろ。大規模なライブラリはブラッシュアップに時間がかかるし
数値計算で今JS使わなくても良いのは確か
だからー、演算子オーバーロードがないと式の記述が不自然になるんだってｗ
C++のラッパー作るだけで良ければ今頃どの言語にもscipy相当があるよ
>>205 まあそういう奴も安心
なんせ別言語が定義できるくらいだから、別の言語が使えるようになるよ
俺は直接JS使うけどw
>>207 君は科学技術計算に縁のない底辺ドカタなんだから
最初から関係ないよ
いつまでもJSを使っててくれて構わない
>>208 確かにあんまり縁がなかったわw
万一今科学計算が必要でも別にC++やpython使うから良いけどw
使うなよ気持ち悪い
Scipyっての知らなかったけど、面白いな
馬鹿の上にこの気持ち悪さ
伸びてるから何かと思ったら
しかも、Javascriptに一時間程度で簡単に解かれちゃってたw
Linuxのシステムの一部でも使われてるのにそれは無理があるわなあ
まあ、pythonが数値計算向けってのはちょっと違うな
>>213 御題出したのはJS厨
で、解いたんだからお前も解けという流れ
いやJS厨もライブラリ絶賛しまくりだったのに
その何でもかんでもJS厨に見える癖、何とかならんのか
じゃあ論破された馬鹿な主張を繰り返すのやめろよ馬鹿
JS厨っていうか、壮絶なアホが一匹いる
論破された主張って何のことだよw
JSが科学技術分野で追い付くことはないし
>>221 中身のない中傷を繰り返すアンチJSのことか
>>223 そう思うなら反論する必要がない
余裕こいてれば良いだろ
ライブラリがあれば、どの言語も同じようにかけることが
JSがnumpyに追い付く証拠も出さずに妄想を毎日垂れ流す限り一生中傷され続ける
お題だしたのがJS厨って怪しいな
ライブラリの差が
不確定な未来について好き勝手に論じるなら、
言語の差はライブラリで埋まる
JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語と結論でただろ
>>232 Javascriptは全然マシだけど、Javaはウンコすぎて無理
関数オブジェクトすらないゴミでは話にならない
やっぱり言語による差はあるよ
>>231 numpyみたいにコアの処理をCに任せればいいだけ
>>235 それがならないんだなぁ。
証拠は数々上がっている。
>>236 うん、簡単だね
今すぐ実装してきて良いぞ
>>234 ちょっと抽象的すぎて良く分からんな
Lintで検出できないようなもんかね？
>>237 おいおい、JavascriptとJavaを一緒にするなよ
ぶっちぎりでゴミだよJavaは
関数オブジェクトが無いんだよ？信じられんわ
>>234 > JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語
それ、お前が変更しまくらないと
出来ない無能なんですーって
言ってるだけじゃないかｗ
>>241 はいはい、必死だね。
世の中にはクラスすらない言語もあるんだよ。
俺頭悪いので分からんから、具体例で説明してくれ
>>234 それがないとクラスも作れないカス言語
pythonでは明示するしコミュニティでは極力避けてるのに
JSは文化的に積極的にやってる。というかそれがないと無理なんだろうな
だとしたら、意味もなく大量のvar宣言せずにクロージャの宣言をしたほうが良い
Java使いでもEgor Kulikovみたいな奴いるしな
>>245 自分の無知をさらけ出して恥ずかしくないの？ｗ
JavaScriptにはグローバル変数すら無いしね。
>>245 ちょっと具体例で説明して欲しいんだが、
こんな感じのこと？
a = 1;
function() {
a=2; //ああ、変更できちゃったよ！
}
>>244 Cでグローバル変数を使い回すようなもの
それを便利とか言って多様するのは
プログラミング初心者と競技プログラミングだけ
それ以外でもやむを得ず使う場合はあるが
普通は危険な割にメリットが少ないから避ける
>>247 実際に関数を呼び出せば関数外の変数を書き換えるのが当然の言語だろ
違うなら反論よろ
>>249 ちょっと良く分からん
pythonのコード例とjavascriptのコード例を対比させて説明してくれないか？
>>248 そうそうそれのこと。
グローバルな変数を書き換えることができて
それを防ぐ方法がない。
これがJSというカス言語
>>252 防ぐ方法はあるだろ
あんまり変な事書くなよPython使いが皆アホだと思われるだろ
strictモードで防げるじゃん。
Python使いが皆アホということで結論が出ました
なんだ Perl のパクリか（棒）
あれれ～、var宣言があるからクロージャが楽なんじゃなかったの？
>>257 いいから比較して書けよ
話はそれからだ。
無知なPython厨をいたぶるのは楽しいね～ｗ
安全モードがデフォじゃないのは危険な操作が普通に必須だからだろうな
>>259 意味不明。安全モードは英語にしたらsafe modeだ。無知すぎ
JSのデフォである危険モードを対比して言っただけだから
どこから危険モードなんてでてきたんだ？
え？use strictで防げるのか？
strictって日本語に翻訳したら
内側の関数に責任を持つのは通常自分なので、ミスさえしなければ
use strictを使えば通常はvarを強制できる
>>262 デフォは危険だろ。そこは反論できないはずだ
だってそれを防ぐ方法を作ってるんだからw
糞言語すぎ
>>267 頭悪いの？
静的型付け言語が安全って言いたいの？
>>248 そもそもpython以外でこれができない有名言語ってあるの？
静的言語は動的言語より安全だと思うけど
少なくとも、C/C++、Java、Schemeは出来る
そういえば、Haskellは代入自体が出来ないな
>>266 > いきなりスペルミスで変数を宣言してしまう
どんなコード？
>>273 test = 2
teest = 3 #ああ、testを変えたつもりが新しい変数に！
>>274 もっとちゃんとしたコードにしてくれよ
うちのvim + pyflakes だと、宣言だけして未使用の変数は
警告で色付けされるから一目で分かるんだよ
>>277 よくわからんが、こうすればいいのか？
test = 2
use(test)
teest = 3
use(teest) #変数名の間違いに気づかず補完してしまった！
>>278 補完するときに候補が複数でる(testとteest)から気付くよ
もっと真面目に考えてくれよ
アンチJSの人は結構有用なレスしてくれるようになったな
JS厨は何人もいるだろうが、アホなJS厨は一人しかいないと思ってる
>>284 多分、お前は俺も中傷してるけど、他の奴も中傷してると思う
現実とはそんなもん
なめJS厨はスペルミスによって外部変数が変更されうるという事実に気づかないのだろうか
JS厨は優しさが垣間見える
>>285 つまり、今はライブラリないけど将来は必ずあるとか、
google様が考えた言語と違うから糞言語とか言ってるJS厨が複数人いるのか。うわあ
JS厨やべーな・・・
JS厨は最初は句読点で平静を装って妄想を垂れ流すが
>>288 お前が中傷してるのはもっと前からだろう？w
>>282 補完って言い出したの
>>278 だが……
それはともかく、エディタやツール類のサポートは一切考慮しないってこと？
ライブラリの件と同じく、そういうのが大事だと思うが……
>>289 それが一人だと思ってるのか
良く規制に引っかからないな
IP使い分けてるのか
スペルミスは言語の責任じゃないけど
>>291 ちなみに278は283のレスをしてるだろ
>>290 JSは奇跡の言語とかJSで凄い時代になるとか気持ち悪い煽動を始めた辺りから
叩いてるけど懲りずに毎日同じ妄想を垂れ流してる奴が
お前以外にいるのか？おそろしい
あ、あとスペルミスはuse strictして
高機能化して欲しいのになんでブラウザ？
>>293 右クリックの保存の挙動が怪しいの？
今は多分大丈夫と思う
Chrome Canary使ってるけど
>>294 補完が使えるのにコピペなんてしないから、
もっと現実味のある理由を考えて
>>295 俺の前は知らんが、今は俺一人だ
ちなみに俺はソース書いてるJS厨
vimプラグインの補完は凄いと聞く。俺は数行の編集でしか使わないけど
JSでvarつけ忘れて外部変数とぶつかったらどうなるの？教えて！警告でるの？
>>299 実はダブルクリックの方が補完より速い場合あるから
マウス毛嫌いしてないで試してみ？
vimだから嫌いそうだけど
sublimeは実際凄いよ
>>300 ソース書くって、今日も例を示せと数十回言ったけど返ってきた記憶がない
>>305 まあほとんどJSのソースしか書いてないからな
たまに議論のついでにちょろっと小さいコード片をいれるくらい
デタラメを重ねすぎて狼少年にしか見えない
>>297 デバッガとセットになってて欲しいし
HTML上で使う場合はブラウザ使うし
HTMLの画像とか他のファイルも一元管理できた方がよくない？
>>298 今度試してみるかな
とは言え最近はNode.jsばっかり書いてるんだけどね
Node.jsでもブラウザをデバッガとして使うんだけど
ココら辺ももう少し連携しやすくして欲しいなあ
>>302 出ないよ
それで出たら親スコープの変数触れないじゃん
そうじゃなくて明らかに出てきてない変数から代入しようとしてたりするケースみたいなのは
JSエンジンのオプションで出せるようにできる
あとはvarを必至にすることでスペルミス軽減
クラスターのプログラム書くときにベクトルのライブラリをググったら
だからさ、親と子で宣言子付けるのが逆なんだよね
「normって何？」と言ってるJS厨がいて数値計算は相当苦手なんだなあと思った
俺みたいに理系の院行ってるならノルムは当然知ってるけど、それ以外の一般人は
>>310 何言ってるのかさっぱりわからない。
クロージャーは、関数外部の変数を見れたらいけないと言いたいのか？
それはもはやクロージャーではない。
なぜならクロージャーの要件の一つが外部の変数を見れること。
>>311 知ってるか知ってないかの違い
ググればわかるようなことを
自慢げに言われてもなｗ
>>313 pythonが真のクロージャを備えていないことが
よっぽどコンプレックスなんじゃないの
Pythonに真のクロージャがないとか
なんか1周回って戻ってきたな
Javaで内部クラスをクロージャとして使うと
>>314 自慢じゃなくてかなり基本的なことだから、共通基盤が違うんだなあと
ノルムと言って伝わらない人は確かに科学的な計算しないと思う
pythonでも一応外部の変数を「見る」ことはできたはず
>>318 F#とかもそうなんだっけ
そういう安全装置は意味あるし、pythonのスコープがおかしいって指摘が微妙だよな
>>319 そいつは本当に自分が知らないことを聞いているのか
一般的な事柄としてそういう疑問があると言ってるのか、
そしてついでにいえば、そいつがどのレスと同一人物なのか
もう少し注意深く見た方が良い
外部変数に代入したくないときに明示するか（var）、
>>318 それってfinalじゃなくても良くなるって話を随分前に聞いた覚えがあるけど、
Java7でもまだだっけ？
Pythonってどうしてそういう仕様にしたんだろう
もしかして、pythonが簡潔を売りにしてる割にはself地獄なのも似たような思想なのかね
>>323 JSのが明らかに危険なのにどうでもいいってｗ
>>322 それこそ本当にどうでもいいです。
科学的なコードに対して一般的に聞くことにどんな意味が？
JSで書いたほうが良いと言ってた奴だったと思うよ
Python節、まあいいと思うよ
>>328 それは超初心者レベルのプログラミングも分かってないってこと
意図しない副作用に注意するなら、変更する場合に明示するほうが自然だろ
>>327 レス見てきたけど、趣旨としては一般的なことだね
normは確かに数学の用語だけど、norm以外にもいろいろ挙げてる
から意味はあるね
normを揶揄するのは揚げ足取りの類い
>>329 確かに
これはnonlocalの方が優れてるわ
まあselfは気に食わないけど
>>324 final変数しか参照できないって不便だよな。
for(final int i : list) {
//クロージャー呼び出し
}
for(int i : list) {
final int i_ = i;
//クロージャー呼び出し
}
いちいちfinal付けるかfinalつけた変数に代入しないといけないんだよな。
>>329 自分で書いておいてその程度の事が意図しないとかいう感覚がわからない
内側のスコープにその変数を使ってるもんだと思って、
実際には無くて、外側のいじっちゃいけない同名の変数を
意図せず弄って問題が起きることがあるってこと？
簡単な具体例を説明して欲しい
>>334 滅多に起きないけど、varを忘れてしまった場合にありうる
>>335 マジか
これは良い情報
まあ仕事じゃレビューでfinalとってくれって言われるのが落ちだろうけど
>>324 Java8で、final値だと自明な場合はfinalを書かなくても
final変数として参照できるようになる、らしい
クロージャが呼ばれるときその中身は見えないし、その変数はそのクロージャ以外でも使われるのなら
>>336 あー、言いたいことはわかった気がするけど
ちょっといろいろと仮定が都合良すぎるな
確かに一昔前なら実際起きてそうなことだと思うけど
今は皆慣れてコーディングスタイルとかも良くなってきてるし
そのためにstrictmodeもあるしね
strict modeの存在自体が危険性を示唆してるし
クロージャを普通に使うJSではそれが逆に大変になるということだろうな
>>339 それはさ、クロージャをクラスに置き換えても同じことが言えるんじゃない？
var付け忘れというより、varつけて宣言した変数を使うつもりで変数名タイプミスして
グローバル変数になるとかのパターンが、かなり危険だね
なので"use strict"が導入された
>>341 "use strict"は関数毎につける必要はないよ
実質モジュール単位で有効にすればいい
>>341 どういうこと？
今話してた意図せずスコープリークしてしまうのを防ぐ役目があるじゃん？
クロージャにだけ固いスコープが必要？
よくそのメリットがわかんないな
>>344 だからさ、それ本当にuse strictで防げるのか？
俺の手元のテストコードがおかしいのか？
>>343 クラスは変更される変数と独立してないだろ
>>345 クロージャはコードが長くなりがち。
長いコードはスコープが広いのと同じことになる。
つまり何処で変数を変更しているかわかりにくい。
影響範囲を狭くするために
外のスコープに一切アクセス出来ない
クロージャ（？）が必要。
これをクロージャと呼ばないとかどうでもいい
違う名前でいいから、そういうものが必要。
use strict で防げる派と防げない派がいるけど
>>347 メソッドはフィールド変数と独立してるじゃん
同じじゃないの？
外側のクラスに囲まれてるから独立してないというのなら、
クロージャだってさらに外側のクロージャに囲まれているの
だから独立してない
だからさ、varつけて宣言した変数を使うつもりで変数名タイプミスして
>>346 varで宣言してない変数を触ろうとするとエラーになるんだから
意図しない外側の変数やグローバル変数を弄ることがないってことでしょ？
それでも何か不満があるの？
>>348 クロージャは即時関数とも重なるから
むしろだいたい短いと思うんだけど
>>351 varを付け忘れた変数が外側とバッティングする場合はそこまでレアではない
ただ、これもレアっちゃレアだと思うが
>>349 タイプミスして
グローバル変数の宣言になるパターンは防げる
宣言済みの外部変数へのアクセスになるのは防げない
宣言済の変数もゲッター、セッター使えば一応防げる
お前らと話していると、静的型付け言語のほうが
クラス内のメソッドはクロージャで、だからselfを付けるってこと？なるほど
オブジェクトなら簡単に代入参照制限できるし外部関数化もできるけど
>>308 使ったことないけど、Cloud 9とかintelliJ IDEAってのが良いらしい。
ただ、sublimeもlintやdev toolと連携すればそこそこいけるし、
セットってのがそんなに利点かなあ
まあスコープ浸透しない変数が本当にあった方がよくてそれで速度向上するんなら
速度向上？
>>359 最近段々とChromeがOS化してきちゃってさ
というか９割の時間Chromeを全画面表示してるし
>>361 初期のconstみたいに実装に思わぬ負担となる場合がある
浸透しないとその分内側は軽くなると普通思うが
前例があるからどうなるのか心配
普通の変数と変わらない程度なら実装のコンパクト化を考えるといらない
>>364 いや、誰も速度の話なんてしてなかったように思えるのに
急に速度向上の話になったからビックリしただけ
>>356 どうだろうねえ
静的型付けの方がより安全ではあるけど、動的でも
だいぶ頑張れるしねえ
むしろ柔軟性を考えるとデメリットかもしれない
静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
> 静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
静的言語でjQueryの＄関数を実装するとかマジキチ
>>356 このスレではスコープ関係の議論をしてて、スコープについては
ダイナミックスコープより安全なレキシカルスコープが主流になってるから
あんまり違和感が無かった
>>365 誰もしてなくてもJSにとって速度向上はものすごく大事なことなの
>>367 例えばプラグインがメソッドを追加しまくってるけど、
単純な継承では継承の順番を指定しないと駄目だろ
なぜならJSはリアルタイム性が重視される用途によく使われるから。
>>371 プラグインがメソッド追加するのは
jQueryの失敗点の一つだと思ってるけど。
だって、名前かぶったらどうするのさ？
VS+C#は戦車、スクリプト言語は拳銃くらいのイメージ
>>368 いいじゃない
jQuery-C++とかjQuery-Javaとか
JQuery $ = new JQuery();
$(”ul li .hoge”).css("color", "red");
がJavaのコードでも別に良いじゃない
>>373 noconflictとかでなんとかならんかね
実際そんなに問題出てる？
>>375 全然よくない
本当は型によって振る舞いを変えるのは
JIT妨害の代表格みたいなものだからJSでも最悪なんだよ
でもjQueryはブラウザとHTMLの柔らかさや非互換性があるからこそ便利なもの
静的言語でやると悪いことしか産まない
>>375 だよな。作れない理由が思いつかない。
>>376 noconflictは単にjQueryのエイリアスである$を使わない（jQueryだけを使う）
ってだけの意味でしか無いので、何も効果はない。
>>374 C, C#, Java あたりは PC で
スクリプト言語はスマホやタブレットなのかもしれない
Javaで$(”ul li .hoge”)という書き方は内部で$メソッドを定義しない限り
>>378 名前かぶったら別の変数にして使えるじゃん
jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
>>381 $が関数名として使えないとかいう話？
使えるけど？
> $.$()になる
あぁ、staticインポート機能を知らないのか。
>>382 えとね、今はプラグインのメソッド名の話してるの
$オブジェクトを別の変数で使う話してないの
>>385 だから、プラグインのメソッド名がかぶるなら、$オブジェクトを別の変数に入れて
それぞれ使い分ければ良いだろ
staticだと、それこそnoconflictができないよね
無理だって言われてるのに意地張るなよ
>>387 お前馬鹿か？
$をhogeって変数に入れても
プラグインのメソッドは、
$にもhogeにも作られるんだよ。
$はオブジェクト、つまり参照型なんだから
コピーは作られない。
>>388 noconflictもstaticもお前勘違いしてるだろ。
無理に参加しなくていいよｗ
>>383 > jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
> 静的言語で移植するのは１００％無理
JavaとJavaScriptでthisの扱いが違うのだからそれは当然
100%同じインターフェースで実装できるわけじゃないが
実用上困らないレベルでは実装可能。
例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
>>390 何がどう出来ないんだ？
単なるオブジェクトだよ？
クローンも作れるし、それぞれに独自の拡張が出来る
プロトタイプベースの言語に慣れてないのか？
jQueryはJavaでは無理って言われて
>>392 プラグインはjQueryにメソッドを生やす。
jQueryをコピーして作られたjQuery2にメソッドは生やさない。
jQueryに生えたメソッドをjQuery2に移し替えても
プラグインはjQuery2ではなくjQueryを参照する。
まあ実際にjQueryを真似たjsoupというJavaライブラリが存在するしな。
>>393 >100%同じインターフェースで実装できるわけじゃない
>例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
別に昨日が実装できるのは当たり前なんですけど？
あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
http://gihyo.jp/dev/clip/01/orangenews/vol67/0001 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"));
>>398 > あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
具体的には？
>>396 プラグインAでjQueryにメソッドをはやしてから
別名変数にクローンを保存
ブラグインBでjQueryのメソッドを上書き
余裕
https://code.google.com/p/joox/ // 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]");
そのjOOXとやらのプラグインはどうなってるの？
// This will add a new book
>>403 落ち着け
これはXMLをjQuery風に操作できるライブラリ
>>396 jQueryを読み込んでから各プラグインを読み込む間
いつでも変数弄ったり自由にできるんだけど
JQ=DC(jQuery)
プラグイン１を読み込む
[jQuery1,jQuery]=[jQuery,DC(JQ)]
プラグイン２を読み込む
[jQuery2,jQuery]=[jQuery,DC(JQ)]
プラグイン３を読み込む
[jQuery3,jQuery]=[jQuery,DC(JQ)]
でぜんぶ別々のプラグインが使える
>>403 イベント？ Javaはブラウザじゃないんだが
一体誰がイベントを送信するんだ？
イベントとブラウザかどうかは関係ないんだが
409 ：
デフォルトの名無しさん ：2013/05/04(土) 01:17:55.92
>>380 それは汎用性という観点だろうけど、C/C++は別格
汎用性:
C/C++ >>>>>> C#, Java, JVM言語 >>>>>>>>>>>>>>>>>>>> スクリプト言語
プログラミング能力:
Lv6 => C/C++使い
Lv3-5 => C#, Java, JVM言語使い
無能力者～Lv1 => スクリプト言語使い
>>408 > タイマー、ソケット、エラーとかいろいろ発生源はある
だからなんでそれをjQuery風ライブラリで扱わないといかんの？
お前が言ってるのはsetTimeoutでできることを
jQueryでやりましょうって言ってるようなもんだよ。
jQueryが扱う対象はDOMのイベント
DOMのイベントはブラウザが発生させる。
Javaだとメソッドの引数に無名関数渡すようなのはできるのかね
イベントループはユーザーの操作とかと関係ない
クラス相当のものも全部単なるオブジェクト
>>414 無理
真のクロージャじゃない
あと、Javaの場合jsonで渡すのが難しいだろうね
それこそ全部文字列にしないと
イベントとか言ってる人はXMLとかHTMLとかDOMの区別がつかんのだろう
>>408 お前が言ってる云々は意味がわからないな
自分は誰がイベントを送信するんだとか
イベントループをまったく理解してない頓珍漢な言葉に反応しただけですが？
いや最近の静的言語はより安全だしIDEのサポートもあるから難易度は低いよ
420 ：
デフォルトの名無しさん ：2013/05/04(土) 01:23:39.70
まあJavaScriptはスクリプト言語の王様だかな
>>415 サンプルコードを見たいならテストコードを見るのが一番手っ取り早いぞ。一つ賢くなったね。
https://github.com/jOOQ/jOOX/blob/master/jOOX/src/test/java/org/joox/test/JOOXTest.java 830行
@Test
public void testMap() throws Exception {
assertEquals(
Arrays.asList("1", "2", "3", "4", "1", "3", "1", "2"),
$.find("book").map(JOOX.ids()));
assertEquals(
Arrays.asList("Amazon", "Roesslitor", "Orell Fuessli"),
$.find("library").map(JOOX.attrs("name")));
assertEquals(Arrays.asList(0, 1, 2, 3), $.children().first().find("book").map(new Mapper<Integer>() {
@Override
public Integer map(Context context) {
assertEquals(context.element(), context.match());
assertEquals(context.elementIndex(), context.matchIndex());
assertEquals(context.elementSize(), context.matchSize());
assertEquals(4, context.matchSize());
return context.matchIndex();
}
}));
}
なにこの
>>419 「ちゃんとしたプログラミング」が必要な場面で
スクリプト言語を選ぶのは無能
わざわざ遅い言語で書く必要性がない
JavaScriptの速度とかJAVA並なんですけど？
結局プラグインは何一つなしと
>>416 > あと、Javaの場合jsonで渡すのが難しいだろうね
> それこそ全部文字列にしないと
ぷっ。当たり前じゃね？
jsonはJavaScriptの文法から生まれたもので、
JavaScript以外じゃ文字列として渡すしかねーよ。
>>423 なんのためにスレタイを変更したと思う？
今すぐに死んだほうが良い知的障害を寄せ付けないため
JS厨まだ居座ってるんだな
>>426 プラグインはjQueryの設計ミスなんでどうでもいい。
>>423 JSはasm.jsとかParallels.jsで今年末にはC#並の速度の言語になってるよ
今でもJAVAに勝ったり負けたりするレベルにはきてるし
>>430 まあ荒らしが続くようならJAVAドカタと同じ道を辿るだけ
JsonはJavaでも、リフレクションを使って生成すれば何とかなる気がする
>>428 静的言語でjQueryの代わりを作るのが大変だという話だろ
当たり前でも大変なのは変わりねえよ
>>431 プラグイン無しのJQueryとか考えられないんだが
>>434 > JsonはJavaでも、リフレクションを使って生成すれば何とかなる気がする
てんさいがいる気がする。
天災がｗ
何を考えてるのかさっぱりだね。
>>432 馬鹿かｗ
C#並になるわけないわw
JITコンパイルはコードによっては逆に遅くなることもしらない低能JS厨
>>434 素直にC使えよ
JAVAとか文字列の扱いが一番糞なんだから
jQueryの代わりなんぞできた所で激重で使えるわけない
対抗できるのはCくらいのもんだ
>437
ご存知の通り、JS厨が語る未来は現実を完全に無視したSFだから
>>439 asm.jsはJITじゃないんですけど？
それにasm.jsはマイクロベンチや物理演算ベンチではすでにC#並になってるの知らないの？
>>439 JITに限界があるからAOTにするのがasmだろ
知ったか乙
>>443 JITじゃないならなんなんだよ
AOTコンパイラあるのかよ
ぶっちゃけメソッドチェーンは糞だと思うが、
Javaでプラグインをメソッドチェーンで使いたいなら
（
>>421 のJavaライブラリを参考に）
$.children().first().find("book").plugin(MyPlugin.class).map( ～略～
ってやれば出来るだろうね。
これだとクラス名は名前空間があるから
かぶることはないし。
>>438 つ
org.apache.commons.lang3.builder.ReflectionToStringBuilder
>>446 よくわからんが、毎回pluginなんちゃら.classとか書かないと駄目なのか？
>>444 AOTでも型が確定してなければ遅いし
>>443 特定のベンチだけ速くてもいみない
C#並ならソースだしてみろよ
あと「ベンチマークはXより速い」ってのは
実績のない言語のお決まりの宣伝パターンなんだよな
node.js推してる奴もそればっかり言ってたわ
補完って、見た目変わらんのかw
451 ：
デフォルトの名無しさん ：2013/05/04(土) 01:42:39.53
JS厨よお、ちゃんと使い物になってる言語の話はできないのかい？
JSが速くなるわけじゃねーじゃん
>>450 ん？ pluginってメソッドがそんなに気になる？
これはjQuery UIでも用いられてる方法なんだけど
あっちは.pluginではなく.dialogだけどね。
jQuery UIは機能が多すぎ＆似ているため、
jQueryプラグインとしてjQueryオブジェクトにメソッドを生やすと
確実にメソッド名がかぶるだろう。
だから、$( ".selector" ).dialog( "option", { disabled: true } );
のように、.dialogメソッドを介して、.optionメソッドを呼び出している。
自分でjQuery UIのwidgetを作ればわかるよ。
自分で作ったwidgetクラスのメソッドは、このように
dialogメソッドを介して呼び出すことになる。
C#の型推定の方が万倍マシな件について
457 ：
デフォルトの名無しさん ：2013/05/04(土) 01:50:31.14
注目を集めるために実績のない言語が宣伝するのは決まってベンチマーク
そのベンチマークもねつ造でした
http://d.hatena.ne.jp/skymouse/20130323/1363979203 boaoa 2013/03/23 12:52
asm.js、大変興味あるのですが
現在asm.js用のサンプルコードをChromeで動かすと
普通のコードよりなんと60倍も遅くなりました
+等の演算子がJITに悪影響を与えるみたいです
そして、そのasmコードをnightlyビルドで動かしてみても、
普通に書いた時コードのChromeと全然変わりませんでした
普通のコードよりなんと60倍も遅くなりました
普通のコードよりなんと60倍も遅くなりました
普通のコードよりなんと60倍も遅くなりました
asm.jsは型を確定させ、GCを止め、仮想メモリを弄らせるという
JITは面白いが型指定は周回遅れ
半日でここまで来るとかお前ら暇だな
JavaScript使いと
>>455 とりあえずそれ別にoptionメソッドじゃないだろ
optionセットしてるだけ
Javaでやるならこうか
$( ".selector" ).plugin(Dialog.class).option(new Option().disable("true"))
まあちょっと冗長だが目をつぶれないこともないか
>>457 それ、ガチで俺が書いた
興奮気味に書いたからやや大げさだった
FF22じゃなくて23で試してみたらちゃんと早くなったからそこは大丈夫
V8が対応するまで使う気が起きないのは言うまでもないが
それはどんな新機能でも同じ
まずはFFが実験台となって
Parallels.jsとともに精査してほしい
そしてES.nextとぶつかるようなことにならなければ
比較的V8での実装は早いんじゃないかな？
流石に５倍とか早くなるのは大きい
それを書く前に既にV8グループで挙がってたし
早ければ１年後にはってとこかな？
ES7に入る可能性もなくもないかも
そうなったら逆に遅くなるかな
JS厨が散々すごいと吹聴してた未来ってこれかよ
>>463 5倍速くなると言ってもベンチマーク用に用意した
特殊なシチュエーションでそれだけ速くなるだけだと思う
正直、平均的に見たらもう素のJavascriptが5倍程度で収まる気がする
なぜJS厨は息をするように嘘をつくのか
じゃあ他の言語に立派な未来があるのかというと「？」
型の指定みたいな言語の根幹にかかわるところは
>>465 特殊なシチュエーションでいいのよ？
だってJSの速度が気になるのって特殊なシチュエーションだけだし
とくに3D周り
WebGLはなんと行列変換をJSでやらないといけないのよ
気持ち悪いでしょ、なんでネイティブで実装してくれないのって
でもasm.jsは特に型付配列を使った演算が高速になるからまさにぴったし
あと個人的にはJSでボードゲーム作ってるんだけど
ほんと、１％でも早くなって欲しいから期待してる
>>467 なんでキチガイJS厨の「？」な希望的観測に嫉妬しなきゃならんの？頭大丈夫？
>>462 少し例が悪かったね。自分も少し間違ったし。
optionはメソッド。これは変わらない。
http://nbnote.jp/blog/2011/12/jquery-widget-1/ 一部抜粋
// ウィジェット定義
$.widget('test.myWidget', {
// パブリックメソッド
setContent: function(str) {
this.options.content = str;
this._update();
}
}
この独自作成ウィジットのsetContentメソッドを呼び出す方法はこれ。
$('#myWidget').myWidget('setContent', 'piyo');
× $('#myWidget').setContent('piyo');
こうではない。
$( ".selector" ).dialog( "option", { disabled: true } );
これも同じで、dialogウィジットのoptionメソッドを呼び出す書式。
JSアンチは自分の言語を誇らしげに語ろうとはしない
asm.jsのベンチマークのグラフは、素のFFが軒並み素のChromeに大幅に勝ってる時点で
単にCと相性が悪い糞仕様を自作の糞言語で尻拭いしてるだけじゃねーか
>>472 叩くのが好きで、叩かれるのは嫌いだからに決まってるだろｗ
ほら俺の言語を叩いてみろ。何の言語かは教えないけどな！
>>468 asm.jsはライブラリなんかじゃないよ？
asm.jsという名前がちょっとまぎらわしいかね
言語仕様をきっちり決めた新しい言語で、JSとも互換性があるっていうだけ
Cソースをemscriptenでasm.js変換したものならかなり有意な効果がある
asm.jsはマジキチだが
>>472 誇らしげに嘘八百を並べる方が理解不能
>>475 さっさとpython叩けよ
あ、関数内関数のスコープがおかしい、でしたっけ？
JSがおかしいだけだったwww
>>477 > これが普及してしまいそうだとAppleとMSはけっこう焦るだろうなあ
Appleはハード売れなくなるから焦るってのはわかるが、
MSはなんで焦るの？
asm.jsはできるだけ機械変換するものと思っていたほうがいい
>>477 簡単そうって何？また希望的妄想ですかw
それしかないな、本当にそれだけ。自分でもそう思うでしょ？
自分の馬鹿さ加減が嫌にならない？
出たよ。トランスレータがあるからOK
>>483 トランスレータがあるからOKなんじゃなくて、
そもそも最初からトランスレーターで変換することを想定してるの
それがasmという名前がついてる理由
>>484 すごいな
http://d.hatena.ne.jp/satosystems/20121228/1356655565 さて、ぶっちぎりで速いのが Scheme48 のコンパイルバージョン。
なんと 0.004sec。ただこれはタネがあって、コンパイル時に関数を評価して
フィボナッチ数を算出しているためです。したがって、コンパイルがインタプリタで
実行するのと同程度の時間がかかります。ただ、コンパイル時に評価できる
関数は評価してしまうというアプローチは関数型言語の特性をうまく生かした良い方法だと思います。
Scheme48 を除いたら、Java がトップでした（追記:[2012/12/30] Haskell の
型宣言を指定したら、Jhc に抜かれてしまいました）。JIT が効いているのは当然として、
Java VM の動作や実装を熟知している身としては、よくこんな短時間で
ブートストラップクラスを初期化できるものだと感心してしまいま
Oracle の最新の Java VM を使えば、速くなるんじゃないでしょうか。いやはや。
メンヘラの妄想に付き合うの疲れるなあ
C (gcc -O2) 1.18
たしかV8のグループでは
もう希望的観測はいいから…
確認した事実・・・。
>>489 単純な四則演算はもう十分に早いよ
でも実物になるとまだCの10倍遅い
JITの限界とか、GCとか、メモリアクセスとかがネックになってるらしい
もうここいらで限界みたい
そこを改善して実物でもCの２倍の実行時間で済ませようとするのが
asm.jsサブセット
長文で妄想垂れ流したいだけならブログでいいと思うよ
嘘をついているという自覚がないっぽいのが本当に怖い
確認した事実 ↓
C言語というJavaScriptとは全く違った文法から
でもこれだけJSの高速化が盛んになってくると気軽に書けなくなる
昔はVBが一世を風靡していたとき、
>>493 単純な四則演算ではない実物ってのがよくわからない
再帰のフィボナッチはスタック使いまくりだよね
スタック領域のアクセスは良いけどヒープが駄目ってこと？
V8の登場以降からブラックボックス度は高まりつつあるよね
まーた始まった。無知が自分に酔いしれて一人妄想を語る
もうスレ半分使っちまったのかｗ
>>500 には言葉が通じず対話が不可能で一切の意味のあるレスをしないから害悪でしかない
もう嘘しか言わないキチガイJS厨の相手をするのはよそう。時間の無駄だ
@A = 1..10;
確かに
>>500 はちょっと間違ってるな
VBは遅かったが、Javascriptは十分に速い
速度が必要な場合にもJavascriptを使うことが多くなる
他の言語で書くようになるとか妄想はブログでやって欲しい
JSの話をやめた所で他の言語の話をする奴がいなさそうなんだが……
>>507 > もう嘘しか言わないキチガイJS厨の相手をするのはよそう。時間の無駄だ
消える宣言した以上、ちゃんと消えろよな。
レスなんかしたら見苦しいぞ。
よし、キチガイが消えたｗ
JavaScriptはあとはメモリアクセスだよなあ
>>510 別に無理に伸ばす必要ない
JS厨が荒らすだけのスレならJSスレに行ってくれ。邪魔
特にブラウザの話しかできないやつ見ると明らかに他のスクリプト言語から浮いてる
というかWebは板違いじゃね。日常で使うスクリプトという話は皆無
もういいよJSの話は。次スレから外して問題ない
イキイキと荒らす馬鹿が目障り
ピットボード？
スクリプト言語からWebやWebサーバーを取ったら……
>>508 @A=1..10;
@x=map{$_ %2 ? () : $_*2} @A;
再帰や遅延評価を使うまでもないリスト処理は面白くないんだよね…
Webはちゃんと板があるし
>>513 > JS厨が荒らすだけのスレならJSスレに行ってくれ。邪魔
毎回思うんだけど、そんなこと言っても
いうこと聞くわけ無いだろう？
>>513 を苦しませるには
JSの話題をどんどんやったほうがよさそうだｗ
自分からやられて嫌なことを語るなんて
馬鹿だなぁ。
>>518 そうだよ。JS厨は死ぬまで己の馬鹿を晒し続ける
すまんｗｗ
>>513 普通に言語の速度とか、node.jsとか、科学計算とか、クロージャとか
内包表記とか、Javaの話とかPythonの話とか
ブラウザ以外の話も豊富じゃん
>>522 奴には見えてないのですよ。
標的意外なにもね。
>>519 論破されたから悪意を持って荒らすだけのゴミになったんだよね
ゴミすぎる自分をどう評価してる？いきる価値ないと思うよね。死んで良いよ
というか他の言語って何が原因で遅くなってるの？
>>524 死んでいいよと言われても死ぬわけないしｗ
お前の願い、死んでほしい？
残念、お前の願いは棄却されましたぁぁぁｗ
>>523 本当に妄想以外で議論が出来るなら、JS厨はなんで嘘で荒らし続けるわけ？
どうせJSのことも何も知らないんだろ。幻想を語るだけなら黙ってろ
>>524 端から見てるとお前も悪意持ってて怖いわw
今までJS厨は人の中傷はあまりしてなかったが、519の人が
やり始めたな
お前が嘘だというのが
>>530 だって開発者がPerl6なんてやってて
Perl5は放置状態だもの。
>>529 そうだな、嘘でも本当でもない、不確定のゴミ情報
というかお前の存在自体がゴミ。１つもまともな情報を出さずにオナニーしてるだけ
醜すぎるわ。反論できる？
>>530 何かどうでもいい話
性能なら別の手段つかうさ
>>532 面倒くさいやつだなｗ
お前はキチガイ。反論できる？
>>525 他の言語も頑張ってる
V8作ったGoogleが天才すぎるだけ
>>534 できないね。お前みたいなゴミカス荒らしに唯一構ってるんだからな
普通の人間はヤバいキチガイを見たら邪魔だなあ、早くどっか行けと思いつつ関わらない
お前はそう思われてるんだよ。分かるか？なんで荒らすんだ。妄想なら他所でやればいいじゃないか
Googleが頑張ってほかの言語エンジンも改良すれば世界が良くなるな
>>536 残念、またしても
お前の願いは叶えられなかったｗ
V8の開発してるのは以前はSunでJavaのJITのVMの開発で活躍してた人だと思った
>>536 ならスルーしろよ
というか、Google天才とか言ってるのはそいつじゃねーからw
お前が誰彼構わずアタックするからこうなっちゃんたんだぞ
>>536 北風と太陽
よそにいけといえば言うほど
このスレにいることになる。
逆にここにいろと言ったほうがいいよ。
そう言ったとしてもここにいるわけだけどなｗｗｗ
>>538 俺の願いじゃなくて、みんなの願いね
心配しなくても、お前の願いであるみんなの迷惑になる行為を続けることは毎日叶えられる
良かったな。もう誰もお前がまともなんて思わない
JS厨の詐欺にはかからない
アンチJS厨が一番うざい。
Goの開発もベル研にいた有名な人たちが参加してるね
まとも面したJS厨がいかにキチガイか周知できれば十分
さて、またJavaScriptの話でもしますか。
最近どんなプラットフォームでも
>>544 各会社から、有名な天才達がGoogleに集まってきているってことだな
Pythonの作者もちょっと前までGoogleだったらしい
今は脱退したようだが
現在広く普及している、スマホ、タブレットはもちろんのこと
例のアンチが消えた途端静かになったなｗ
なんか寂しいな
どんな言語を使おうと避けられないウェブ化によってHTMLが
多分Googleのお陰が５０％だと思う
>>539 そんな奴があんな中二っぽいコード書くのか?
>>554 どんなコード？って聞かれて
答えられないなら、そんなこと言い出すなよ
>>530 PythonでCython使って書いたら相当速くなった（53.98 -> 2.63）
こんな感じに、Perlにも高速化の手段があるんだろう
ソースコードはこれ
cimport cython
cdef fib(int n):
if n < 2: return n
return fib(n - 2) + fib(n - 1)
print(fib(38))
実行結果はこれ（CPython版との比較）
$ time python fib.py
39088169
python fib.py 53.82s user 0.04s system 99% cpu 53.983 total
$ time python fibc.py
39088169
python fibc.py 2.61s user 0.02s system 99% cpu 2.635 total
さすがに悔しいからってPythonじゃない言語を持ち出されても
せめてCythonでググれよ……
wikipediaより
CythonはPythonに型注釈を追加したような言語で、
>>559 Pythonの上位互換って書いてあるだろ
ここ遅いから速くしたいなーってなったら型を書けば良い感じ
で、C言語拡張にコンパイルするから、普通のCPython処理系で動く
>>556 で関数の戻り値の型を書くのを忘れてたので、
cdef int fib(int n):
に変えて実行してみたら、もっと速くなった
$ time python fibc2.py
39088169
python fibc2.py 0.08s user 0.01s system 95% cpu 0.098 total
C のコードはどこまで減らせるんだろうね
Python 界隈はそこらへんの問題に極めて意識的だけど
>>559 自分も別言語だと思う。Python のサブセットである RPython ならともかく
>>560-561 つまりCに変換できるようにしたTypeScriptみたいなもんじゃん
TypeScriptをCやasm.jsに変換したらそりゃ速いよ
>>562 これ最適化でコンパイル時に値を計算したっぽいな
>>564 > これ最適化でコンパイル時に値を計算したっぽい
print(fib(38))をコンパイルに含めずに
実行時にPython側からfib(38)を呼び出しても同じ
>>565 良く分からないんだけど、コンパイル時に計算していないのに、
Cの数十倍速いってこと？
ちょっと良く分からない現象だね
何かタネがあるんだろうけど
>>566 こちらの環境でC（gcc47 -O2）を実行した場合
$ time ./a.out
39088169
./a.out 0.25s user 0.00s system 99% cpu 0.257 total
>>566 こちらの環境でC（gcc47 -O2）を実行した場合
$ time ./a.out
39088169
./a.out 0.25s user 0.00s system 99% cpu 0.257 total
569 ：
567 ：2013/05/04(土) 10:34:54.74
連投すまん
実行環境が違うのか、Cの速度も
>>530 と全然違うね
同じソースコードを使ったんだが
つまり、CPythonの速度がむちゃくちゃ遅い……？Python3.2なんだけど
最後に、比較用にnode.js（v0.10.4）
なんだろう
node.jsはCの4倍程度か
うちでもやってみた。Cython の使い方間違ってたら指摘してくれると助かる
つづき
>>562 みたいに、戻り値の型を書くともっと速くなる？
pythonが200倍遅いからって、他の言語に頼るとは、、、
>>575 うっかりしてた。戻り値記述して再トライ
% cat fib2_py.pyx
cimport cython
cdef int fib(int n):
if n < 2: return n
return fib(n - 2) + fib(n - 1)
print(fib(38))
% cat setup2.py
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
setup(
cmdclass = {'build_ext': build_ext},
ext_modules = [Extension("fib2_py", ["fib2_py.pyx"])]
)
% python setup2.py build_ext --inplace
cythoning fib2_py.pyx to fib2_py.c
[...]
% time python -c 'import fib2_py'
39088169
python -c 'import fib2_py' 0.56s user 0.02s system 99% cpu 0.577 total
% cat fib2_py.c
[...]
__pyx_r = (__pyx_f_7fib2_py_fib((__pyx_v_n - 2)) + __pyx_f_7fib2_py_fib((__pyx_v_n - 1)));
常識レベルの話として長いコードをここに貼るな
node.jsより速いという結果は貼るな
cythonってpythonの拡張モジュール書いたりできるんだろ？
>>580 Pyrex が 2002 年でそこからフォークした Cython が 2007 年
後追いではないと思われ
「今JSが熱い！みんなが熱狂している！薔薇色の未来！」
>>582 JSが熱いってそんなCに変換するだのなんだののくだらない狭い世界の話じゃないんだが
asm.jsを熱弁してる奴がいただけで、JS熱は別次元だよ
node.jsやweb用ライブラリ界隈で起こってる熱狂
>>582 > 「今JSが熱い！みんなが熱狂している！薔薇色の未来！」
> って、他の言語が数年前に通った道なんだね…
いや、その道は他の言語は通っていない（苦笑）
今の話の流れからは「型つけて速くしましょう」という
道しか通ってないだろう？
デスクトップアプリがWEB用アプリに置き換わりはじめてるから、
ああ、asm.jsの奴はJS的にもアレなので
ん？ちょっとまて
Cythonって静的型付け言語ってことでいいの？
ハイブリッド
node.jsって実行速度を自慢する割には、
> node.jsって実行速度を自慢する割には、
静的型付け言語の下位と同じくらいだな
それが一般的なんだけど、nodeは動的言語でも静的言語並に速いから
>>594 Java (OpenJDK) 0.732
C (gcc -O2) 1.18
JavaScript (node.js) 2.62
3倍以上さがついているものは
Scala (case) 1.896 静的
>>597 3倍どころか、普通に静的型付言語がJavascriptに負けてますが
やっぱりこれからはJavaScriptの時代なんだろうな。
GUIはWebアプリで作るのがお手軽だから、
諦めるしかないんだね
>>601 JavascriptはVBとは違うんだよVBとは
IEではJScriptもVBScriptも書けた
しかし今や誰もVBで書いてない
JavaScriptが優れていたのだよ
でも、nodeが出てきたときの世間の反応こんな感じだったよな
革命と自称する大半はただの糞に終わるんだから当然だろ
まあ革命的なものを糞だと言って認めない奴がいるのも世の常だしね
まあ、俺はJavaScriptが
>>608 物事を客観的に見つめて、現実を正しく認識するのって
とても大切な事じゃない？
なんでもかんでもマンセーしてたら一つは当たるだろ
>>611 まずお前は自分の嫌いなものにも長所があるっていう現実を受け入れるところから始めよ
>>612 え、お前の長所ってなに？
妄想垂れ流しとか何もやらなかった武勇伝とかを聞かされても
長所なんて一つもわからないよ
長所がないわけないだろ。信者レスの無意味性、無批判性、無論理性、無情報性を叩かれてるってわからんの？
>>613 お前、そこでなぜJavaScriptを連想せずに人を連想してしまった・・・
そもそも無批判性ってなんだよw
挑戦的な試みっていうのはだいたい失敗する可能性が高いから
少なくともこのスレは結構良い情報あるけどな
>>615-616 クリティカルシンキングだよ
もちろん信者のゴミレスが叩かれてるのはそんな高尚なものじゃない
明らかにゴミだからゴミと言ってるだけ
言われたくなければまともなレスをしろ
>>617 JS厨の妄想レスで有益な情報ってどれ？
アンチJS様がお目覚めになられたようだ
>>618 良いものは良いと認めることも時には大事だよ
JS信者もCythonやSciPyを認めて使い始めただろう
得をしたのはどっちだろうね？
奴が目覚めたな
>>619 JSが盛り上がってるってことを知っただけでも有益だった
>>621 お前の妄想垂れ流しレスは一切良くないのだが？
何を問題としてるか理解できてないだろ。どんだけ馬鹿なの
>>610 少なくともオブジェクト指向は違うみたい。
>>618 クリティカルシンキングと言うならPythonについてしてみたらどうかね？
Pythonがお気に入りみたいだから、
Pythonについて批判したほうが世の中のためになるだろう
>>625 もっと考えてしゃべれよ。デタラメばかりじゃなくてさ
お前がオブジェクト指向の何を知ってるというんだ。何も知らないだろ
>>624 お前がそういう姿勢だからだよ
JavaScriptが盛り上がってるなんて認めたくない！
俺の嫌いなJavaScriptが絶賛されるのは認めたくない！
こんな姿勢ではね
Webアプリを開発してみるなり、アイディアを学ぶなり、
状況を注視してみるなり、他のスレにいくなり、
もっと良いやりようがいろいろあるだろうに
レスの有用性は受け取る側の姿勢によって変わるものだ
>>630 もう言い訳はいいよ。なんで言い訳しか言わないんだ？
お前は妄想垂れ流しで毎日フルボッコされるだけの悲しい人生を送れよ
>>625 妄想垂れ流し野郎じゃないならちゃんと説明してね
>>631 まあ、お前にかかれば、説明＝言い訳だろうからね
そうなるのは当たり前
このスレはなかなか満足している
>>633 まともなJSの説明なら、説明自体は叩かれてないって気づいてる？
そこで初めてJSディスができる
お前が何かを説明してると認識しているものは、説明とは呼べないほど欠陥だらけなんだよ
無条件に馬鹿にされてると思ってるならただの被害妄想、自分の無能を他人のせいにするな
>>625 根拠なく言ったんだな
テキトーに言えば誰かが代弁してくれるとでも思ったか
デタラメ言ったのならさっさと謝れクズ
>>635 2ch歴短い？
多分、2chというものを誤解してるんじゃないかな
ネタにくだらんレスにウケ狙い、推測に主観
そんなもんに腹立ててたらキリがないぞ
レスする方も高度なレスをする気なんかこれっぽっちもないよ
お前こそ、人に要求する前にスルースキル学べよ
自分で妥当性を考えろ
人格攻撃はスルーして
まあ、JS厨の俺から見て、レスの質はともかくアンチJSの人は
優秀な人は直感とか推測とか主観が大抵当たるから
>>637 ,640,641
最悪の自己弁護だな。つまりまた言い訳。それしかできない
どんなレスをしようが勝手だが
ただ気持ち悪いだけのレスが叩かれるのは当然のこと
穴を指摘されたらちゃんと根拠を説明しろよ。それが出来ないのは中身が空っぽだから
はぐらかすな、逃げ回るな
>>639 仕様や科学計算ライブラリについては知ってるし確認した上でかなりレスしてるが
コードを投下してるのは優れていて優しい別の人な場合が多い
>>642 ああ、コード投下してる奴は別の奴だったのか
なるほど
ドンマイw
>>637 本当にそんなつもりでレスしてるなら
指摘されて妄想じゃない！と反発し続ける意味がわからない
それでいて当然ながら証明はできない
>>643 > ああ、コード投下してる奴は別の奴だったのか
そりゃそうだろｗ
アンチJSの人はただのキチガイだもんなｗ
>>644 具体的にはどのレスの事？
別に「妄想じゃない！」って反発してるわけではないと思うんだが
「妄想」を「客観的に根拠の不十分な推測」と捉えてるなら
反論の余地はない
確かにその通り
ただ、少なくとも「実際には間違っている主観」ではないと思ってるから
その部分について反発があるのは当たり前
ネタでなければ言ってる本人は自分の意見が間違いではないと思ってるはずだ
証明ができるかどうかは状況、気分次第
まあネタと言うか、ちょっと大げさに言う傾向はあるけどね
>>646 証明も反証もできないよ。だから詐欺だと言ってるわけ
もちろん、そんな正論を受け付けないだろうがね
>>648 お前が要求してるのは、「〇〇が熱い！」「将来はこうなる！」ってことの
証明でしょ？
まあ特に後者は無理だろw
前者はURLとかちらほら出てたけど、それを「証明」と認めるかどうかは
お前次第だし、まあ無理だろw
結局、間違ってるという結論先にありきなんだよ
だから詐欺だといって満足したいんだろう
正しいという結論ありきだからおかしいとしてるだけだが
説得力の問題だろう
> 正しいという結論ありきだからおかしいとしてるだけだが
>>652 証明も反証もできない宣伝だから詐欺なんだよ。分かるか？
>>653 > 証明も反証もできない宣伝だから詐欺なんだよ。分かるか？
そもそもそれが間違っとる。
>>650 「おかしい」ってのは「客観的に見て納得できるだけの証拠がない」ことを指してるんでしょ
ならその通りだよ
ただの主観だし
別に反論しようとも思わん
現実にどちらが正しいかは、誰彼の意見とは
一切関係ないがねw
JS厨は主観的な操作感などを評価してるわけじゃない
「連続体仮説は証明も反証もできない命題である」
>>654 ,657
どうとでも言える主張は詐欺でしかないんだよ
>>656 反感を買いやすいとか、一般的な意見のように言ってるけど、
要するに、
>>656 個人が
個人的希望はきらいだって言ってるにすぎない。
>>656 個人が、みんな俺と同じ気持なんだと
みんな俺の考えに賛同していると
思い込んで書き込んでる。
それだけ。
>>656 はキチガイにすぎない。
>>658 あー、はいはい。
どうとでも言える主張は詐欺なんだよ。
俺が言ったから詐欺なんだよ。
みんな詐欺と思ってるんだよ。
俺の考えは正しいんだよ。
ですね。わかりますｗ
「どうとでも言える主張＝詐欺」という前提ならその通り
「詐欺」には明確な定義があるけどな
ま、そんなの
>>658 には関係なく
俺が詐欺と言ったら詐欺なんだ。
なんだろうな。
JavaScriptは今後モバイル系から始まりディスプレイがついてる大抵の電化製品の
>>659 良いこと言うね。みんながJSに熱狂しているとか言ってるキチガイはそろそろ自分の間違いに気づいただろうか
>>664 それも「みんな」の定義によるな
率で言えば少ない、数で言えば多い
俺も一瞬で見ぬいたｗ
>>661 いやむしろ無自覚な方がヤバイし
さんざん指摘しても
>>663 のように悪意を持って印象操作してるだけだから
キチガイ＝個性
>>668 > さんざん指摘しても
>>663 のように悪意を持って印象操作してるだけだから
お前が書き込んだんだろ
タイミング良すぎるわｗ
>>671 俺はこんな気持ち悪い文章を思いつけないし
何を言ってるかも理解できないがJS厨には
ごく自然なことなんだろいな
>>668 まあ、一人じゃないしねw
少なくとも俺は663ではないし、悪意を持ってる自覚はないな
ヤバいかもw
>>663 > JavaScriptは今後モバイル系から始まりディスプレイがついてる大抵の電化製品の
> 「ネイティブ」言語としての位置づけになっていくことは確定してる
検証してみよう。
スマホ・・・JavaScript対応
テレビ・・・一部JavaScript対応
JavaScript以外の言語は？＝対応していない。
>>673 良心の呵責を受けないなら犯罪者に向いてるよ
というか論理的思考ができてないから他のまともな仕事は無理
実際にJavaScriptがモバイル系や家電で使えるのは事実なわけで
>>674 いや、ちょっとまて
ネイティブ言語が何をさすのか知らんが、
俺の知る限り、Objective-C、Java、C/C++はお前の言うネイティブ対応されてるっぽい気がするぞw
スクリプト言語という意味か？
それもLuaとかあるしな
>>675 まともな定職に就いてしまってる可能性を考えて保険をかけてるところが
可愛いなw
TizenOS,FireFoxOS,ChromeOSのアプリ、一部のTVのアプリがHTML5になってきていることは現実
>>679 スマフォで言えば、一旦HTML５が浸透していきかけたけど、
今は少し足踏みしてる状態に見える
やっぱりまだパフォーマンスや互換性など様々な問題がある
ただ、今後はわからんけどね
家電って何を指してるんだ？一般的な家電はほとんど組み込みだろw
未来のことは言わずに、現在どうなっているかを言えば
>>680 足踏みも何もTizenOSやFirefoxOSでは基本HTML5でしかアプリが作れないんだけど？
そして今年度中から日本でそれ搭載のスマホが売られるの知らないの？
互換性なんて既存のスマホアプリのJAVAやobjectiv-Cに比べたら些細なもんだよ
アレだって複数のプラットフォーム向けに作るの大変だし
だから最近ハイブリットアプリが流行ってるんでしょ
C/C++とかはメーカーの人しか使えない言語。
>>683 それは知らんかったが、現状ではまだ浸透してないだろ？
今のスマフォはiOSとAndroidで、後は誤差だから無視して構わない
そして、iOSとAndroidでJavascriptを使ったアプローチは
今はそれほど伸びてない
有名な企業がとりやめて、普通にネイティブに戻したりとか
> 有名な企業がとりやめて、普通にネイティブに戻したりとか
>>686 後俺が知ってるのはLinkedIn
まあ二つしか知らんけどw
>>684 他の言語の話ができないのはわかった
それは別のスレを立てて、このスレはその他マイナー言語専用スレでいいかな？
やっぱり明らかに用途が違うから
>>685 既存のスマホはそもそもWebアプリを作れる環境が整ってないでしょ
それを整えたのが去年から出始めた各種モダンOS
>>668 まあ、そういうのもあるんだけど、アプリの大半を占める
ゲーム分野とかは普通にパフォーマンス重視のネイティブ多いままだし
どんどん浸透って感じではないと思う
たんなる実感だけど
692 ：
デフォルトの名無しさん ：2013/05/04(土) 23:08:21.69
JS+HTMLスレ立ったら誘導してね
>>691 ソフトウェア業界の歴史を見てみろよ。
昔はアセンブラだった
開発効率向上のためCになった。
遅いと言われたが時間が解決した。
開発効率向上のためC++になった。
遅いと言われたが時間が解決した。
UI向上のためWindowsになった。
DOSに比べて遅いと言われたが時間が解決した。
ウェブアプリ化のためHTML+JavaScriptになった。
遅いと言われたがデスクトップ機では時間が解決した。
モバイル端末が出た。当時のガラケーはスペックが低くかったが
時間が解決し、ガラケーでもゲームが出来るようになった。
ずっとな、何かしらの理由で「遅い環境」に変わるが
時間が解決し続ける。これこそがソフトウェア業界の本質といえるんだよ。
そうかな
デスクップもネイティブアプリだらけじゃん
>>693 まあ確かに時間が経てばいずれはそうなるかも
ただ、現状、一時期と違って増加スピードは鈍ってるってのがマジな実感
>>694 そうかね
まあ、単に俺の実感がずれてるだけかもしれん
データとかも検索すれば出てくるかもしれんが、まあいいや
この議論はこの辺で打ち止めだな
ゲームとか既存のスマホでは当然向かないというか、
>>695 現状はな
今はまだ「気づけばちらほらと出てきてる」程度だね
特に開発者好みのエディタとか
Komodoとか、Cluod 9、Markdownのエディタ
ただ、デスクトップに関しては今後加速すると思う
理由は、インターネットが重要性を増してる事と、クロスプラットフォームな事、
ビジュアルの表現力がある事など
ハイブリッドアプリは審査なくても
>>696 HTML5が悪いんじゃない
wayohoo.com/facebook/news/fastbook.html
荒らし（＝例のアンチJS）がいなくなると
Sublime Text 2も設定ファイルがJSONだし、UIがChromeっぽい
>>706 いきなり何なのか知らんが、
スクリプト言語じゃないだろうな
>>704 普通に議論に参加してますが？
いきいきと妄想がはかどってるね
HTMLの時代だからJS！と言われたら何も言えないわ
そろそろ他の言語の議論させてくれないかな
それとも、このスレは永久にJSの夢物語を並べる場所になるのか
キチガイ地獄もいいところだな。JS厨に侵略され、JS以外スレとかいう暴挙も許し
全てがJSの不確定な将来をあれこれと語り合うJS厨の楽園スレ…終わったよ、全てが
>>704 アイツ一人で荒らしてるんだよ。
自覚無さそうだけどな。真性ってやつ。
>>708 まあ仕方がない
現実、そういう時代だし
ただ、PythonでHTML5とかも開発できるようになると思うけど
711 ：
デフォルトの名無しさん ：2013/05/04(土) 23:34:03.62
ただのデファクトスタンダードが勘違いした結果、糞スレ化が確定した
>>706 設定ファイルはJSのJSON形式、プラグインはPythonで、カラースキームとかはXMLで書かれてるな
かなりごった煮だわ
>>711 いや、クロージャ、プロトタイプベース、DOM連携とかかなり良い言語だと思う
Pythonと比べるとそうでもないかもしれんが
俺はJS厨だが他の言語が嫌いなわけじゃないぜ
このスレにおいてJSに対する一切の批判は受け入れられてないからな
>>714 どんなに良いことがあっても無駄だろ
この世界はHTML5で、それに関われないカス言語はまず議論のステージに立てないのだから
JS以外はお断りだよ。JS以外スレを立てたんだからそっちに行ってもらうしかない
不満を愚痴るんならまだわかるけど批判なんかしてどうするの？
>>714 スコープの違いって
外部の変数を書き換えるのに宣言必要になればいいんだろ？
互換性を切り捨ててやろうと思えば余裕だと思うが、
切り捨てるだけのメリットがないってだけだと思う
だからJSにおいてはここで何の議論も発生しない。全く無関係の言語だから
>>603 VBScriptが普及しなかったのは、IE以外のブラウザの台頭と、Ajaxがなかったから
とはいえループの中で変数宣言できないVBScriptはJSより糞なのは間違いない
>>718 子に浸透にないスコープを持つ変数はできると思うよ
そうじゃなくて他にもクロージャはデフォでそうすべきとかいろいろ
言語の根幹の問題があったからさ、そういうのは無理
>>716 普通にCoffeeとか別言語出てきてるし、Python等の既存の言語が関わる事も余裕でしょ
つうか、今既に出来るわけで
HTMLの世界でJavascriptがどこまで王者として勝ち残るかどうかはかなり不透明
ただ、長い間勝ち残ったとしても俺はあまり不満はないけどね
ここはバトルロワイヤルスレに端を発していたし
>>720 VBScriptって悪名高いけど他に何か大きな問題があったの？
そして何故こんなに廃れた今になって尚質問サイトでちょくちょく見かけるのか不思議
>>722 いいか？coffeeはJSだ。JSから逃げることはできない
不満がある奴は生きる価値なし。それを口に出すなんてもってのほか
>>725 んー、ちょっと賛同できないかなあ
CoffeeはCoffeeでしょ？
君の言う、JSってどういう定義なの？
PythonをJSにコンパイルするやつはやっぱりPythonと言うべきだと思うけど
>>726 JSの糞コードを読まなければならないものはJSと言う他ない
>>724 単にIE以外ではサポートされてなかったのが問題
あとJSが爆発的に流行ることになったのは、FireFoxでもサポートされていたのと
GoogleがMapで使い始めたから。
もしGoogle MapがVBSで作られていたら、歴史は変わったと思う
ただ、継承すらできないのに、クラスベースのオブジェクト指向型言語だったから
普及していたらJSと同じく、変換言語が複数出ていたのは間違いない
Googleが素晴らしいMap作れたのはJSが良い言語だったからだよ
というか時代が追いついた感じだな
>>727 読まなくてはいけないってほどでもないと思う
昔はC使ってる時にデバッグモードでアセンブラ見てたらしいけど
今はそんな事もあまりないのと同じで時間が解決するよ
まあ、最初は読んだ方が良いかもな
732 ：
デフォルトの名無しさん ：2013/05/05(日) 00:27:46.88
歴代の素晴らしいアプリは無数にあって、その多くは糞言語で作られてる事実
パフォーマンスと仕様のバランスを考えれば、C言語は当時としては良言語の部類だったと思うけどね
すべてがブラウザなんて少なくとも数年はありえんぞ。クロームOSも受けてないし
>>734 そりゃまあ
「全てが」なんて言い出したらな
ただ、それが主流になるのは数年後にはひょっとしたらあるかもな
それも、もの凄い勢いで普及した場合だな
node.jsが作られた理由・・・JSに非同期IOのライブラリがあったから
>>721 クロージャはデフォでそうすべきって意味がわからない
JSはすべての関数がクロージャだよね？
なんか動きがあるとワーって騒いで、ああこれで世界がいきなり変わるんじゃないかとか妄想するんだけど
選択肢は普通にあるよ
この世界がHTMLだけでできてるのは確定事項だから
別にクソじゃないだろ。
>>740 この世界はJSによってのみ作られる。それを理解しろ
ちなみに、Javaも普通に競合する言語たくさんあるんだが
JS以外の選択肢を口にだそうものなら途端に総攻撃に合うことは覚悟すべき
>>744 最近の話ね。Javaは割とオワコン化してる
一応使われ続けるだろうが盛り上がりはしないだろうなあ
糞言語でもJavaは革命だった。それこそJS以上にね
天上天下唯我独尊、C並みの高速JSがネイティブ言語である確定事項を覆せないのなら
PHPとかPerlとかC(CGI)、VB(ASP)も昔のJavaの競合だよ
>>744 いや、C#は静的型づけでVMで動作する以外にJavaとの共通点がないだろ
普通はOSをWindowsにするかどうか、それでほぼ決まるし。
もちろんWindowsでもJavaは動くがC#やVBと比べたら論外だから
むしろJavaが競合するのは、PHPとかだろ
既存のすべてのCコードはJSの資産なので
>>749 ASP.NETとサーバーサイドJavaは競合しとりますがな
まあどっちかというとOS合戦の面は否めないが
JavaはWEBのサーバサイド以外でもけっこう使われてるしね
>>751 言うように、それは言語以前にOS選びの時点で決まっているから言語の競合じゃない。
もちろんWindowsでWebアプリを作る場合もASP.NETじゃなくてStrutsやSpringを使う馬鹿が0じゃない訳じゃないけど、
ただの馬鹿だからな、それ。
MSが宗教的な理由で嫌いとか、.NET土方が集まらずJava土方しかいなかったからとか、
そういう理由がなければ劣化C#2.0のJavaを選ぶ必要性などない。
世界のすべてのアプリは今すぐにでもJSになる。まあ見てろ（ニヤッ
JSが世界の中心であることは疑いようのない歴然とした事実は
>>753 それは全くその通りだな
でも、本当にJavaが優れていたら、WindowsでもSpring使われていたはずだ
結局、言語の優劣で決まってると思うぞ
そもそもJSに関わってこなかった人間はブラウザで何かしようなんて初めから考えてなかったはずが、もうそれは許されない
インターネット時代がやっと追い付いてきた
他の確定事項としては、ubuntuの次のバージョンはブラウザベースになり、pythonやperlなどははじめからインストールされない。必要ないからだ
>>759 一つは間違いで一つは正しい。
間違いというのは、すべての家電がネットに接続するということ。
これは間違い。
正しいというのは、ネットに繋がった家電を操作できるならば
それはJavaScriptであるということ。
さすがのJS厨の俺でもどっちも間違いだって分かるわw
Node.jsが受けたのはV8の設計が神だったことが大きい
JS厨とアンチJS厨がもともと同一人物説
革命に対するはじめの反応は往々にしてこんなものか
JSは他の言語とは比較にならないほどの神言語である
うーん、これは…
シンパシーを感じた真性JS厨である
>>761 だけが崩壊してる論理に真面目に取り合っててワロタ
HTMLのscriptタグはJavaScript以外にも
つまりJS以外の言語は何も考慮する必要がないただのノイズだし
アンチJSの奴がついに俺のマネをし出したw
考えて見れば恐ろしいもので、
pythonで科学技術計算？プラグイン？perlでワンライナ？RoR？
JSはこの世界を支配しているが安心しろ
asm.jsが脅威だわ。
君たちのHDDにある大量のCのソースコード
わかってる人間は既に変換し終えたころか
ほとんどの言語はCで書かれている
>>765 それで。オブジェクト指向は革命ではなかった。
>>779 この手の議論はまず、意図を明らかにしないと不毛
革命ではなかったとは？
君の考える革命とは何で、その定義のどこがオブジェクト指向に足りない？
2000年代はウェブの隆盛でPerlやPHPのようなスクリプト言語も隆盛になったんだけど、すでにピーク過ぎてる。
node.js触ってみたけど、面白い言語だねぇ
>>782 それってJavaScript的には間違ってるわけじゃない
undefinedという概念があるから
それのおかげで、様々なブラウザやバージョンに対応できた側面がある
まあ、様々な環境に対応させたり、探りを入れたりするには、
>>784 f(1)の方はundefinedじゃなくてNaNが返ってくるよ
NaNの概念がある言語は沢山あるけど、引数の数をチェックしない言語は少ないと思う
>>787 最初にundefinedになった後、その値を計算に使用したからNaNになる
引数チェックしないのは、今ではオーバーロードをエミュレートするのに
使われてるけど、そもそもオーバーロードにした方が良かったかもしれないね
バージョン違いで引数が増えてたりといった事が日常茶飯事だったと想像
>>788 なるほど、fの引数のyがundefinedになってるんだね
納得
>>789 そうだね
'undefined'を変数名として使えるという変態言語w
function (a, b, undefined)とすればちゃんとundefinedがundefinedになるという
バッドノウハウもあるw
でもこういう柔軟性結構好きなんだよねw
function(x, y){return x + y}('foo')
文字列として結合したのか
動的型付けのRubyは "foo" + nil で例外投げるし、Pythonも 'foo' + None で例外投げる
>>755 とかネタ混じりで言ってるんだろうけど
似たような傾向の人がスレ乱立とかスレタイテンプレ勝手にいじるのはやめてほしいな
googleはpythonも使ってるとか、Javaも使ってるとか可愛い勘違いするなよ
>>795 例外投げるのが正しいし、それ以外は危険以外のなにものでもないけど
例えばPythonでは
class myStr(str):
def __init__(self, s):
self.s = s
def __add__(self, s):
if s is None:
return self.s
elif isinstance(s, int):
return self.s + str(s)
else:
return self.s + s
foo_str = myStr('foo')
print foo_str + 'bar'
print foo_str + 100
print foo_str + None
デフォルトが安全側に寄ってるのが大事なんだよ
ごめん間違えた＞＜
pythonコード貼ってる人がやってるホイトスペースの置き換えがわからん
>>795 例外投げるのが正しいし、それ以外は危険以外のなにものでもないけど
Pythonではその挙動を自分の好きなように定義したいとき
たとえばこうするんだけど、他の言語ではどうやるのかな
特に妄想垂れ流しキチガイJS厨にはよく聞きたい
class myStr(str):
def __init__(self, s):
self.s = s
def __add__(self, s):
if s is None:
return self.s
elif isinstance(s, int):
return self.s + str(s)
else:
return self.s + s
foo_str = myStr('foo')
print foo_str + 'bar' # 'foobar'
print foo_str + 100 # 'foo100'
print foo_str + None # 'foo'
>>801 これで見れる？
>>801 今は 10 進数の数値参照でないといけないっぽい
& # 160; をスペース抜きで
>>343 ,350はやっぱり違うな。少なくともpythonはクラス内のメソッドに引数でselfを渡すし
外部変数にはselfを付けてるという意味で独立してない
JSは無条件でクロージャだから全部メソッド外の変数を間違って弄れる
>>804 ただの例だから。自作の型同士で定義するのが正しい使い方だろうね
>>804 myStrに次のメソッドを追加すると対称性を確保できる
def __radd__(self, s):
return self.__add__(s)
numpy 等で
1 + array([0, 1, 2])
って書いたら array([1, 2, 3]) が返ってくるのも同じ
808 ：
デフォルトの名無しさん ：2013/05/05(日) 13:53:44.40
>>808 いやselfの変数とそれ以外のローカル変数は明らかに性質が違う
コードを追うときもいちいち宣言の有無を確認しなくていいので可読性は上がる
ま、来たるHTML5＋JSの時代にはどんなまともな設計でも意味ないんですけど
>>809 簡潔に書けるのが良いのに、最初のメソッドにいちいちselfを明示的に宣言するところとか
邪魔でしょうがない
それだと一貫性がなくなるから
第一引数と変数の前にselfを書くことで簡潔さが失われるのか甚だ疑問
エラー起こしたときに python やクラス書いた人の考える引数の個数（self 込み）と
but 2 were given がなければ、pythonユーザーでも混乱するかもね
学習という面でPythonは論外だね。初心者に厳しすぎる
selfが無い場合、デコレータがselfを参照できるようにするのは
windowsにプリインストールされていない点は関門ではあるが
この世界はHTML5＋JSの時代であるという大前提を忘れてないか？
無視してたけどさ、
>>819 みたいな書き込みって絶対アンチJSだろｗ
JSの時代になって得するのは誰か
文才はあるなw
自分の主張がとおらないと暴れだすとか最悪だよ
>>823 2ch歴短い？
多分、2chというものを誤解してるんじゃないかな
ネタにくだらんレスにウケ狙い、推測に主観
そんなもんに腹立ててたらキリがないぞ
レスする方も高度なレスをする気なんかこれっぽっちもないよ
お前こそ、人に要求する前にスルースキル学べよ
自分で妥当性を考えろ
2ch歴が短いと、むかついた時に
真摯に誠実に真実しか語ってないのにあっちいけとか言われる意味がわからないしね
自分の文章に酔って気持ちよくなってるっぽいのが
こっちは正しいことを言ってるだけだから
>>827 JSの素晴らしさを布教することより気持ちがいいことはないからね
時代のビッグウェーブに乗ることの気持ちよさ
君もこっちに来なよ
スルースキル学べよｗｗｗｗｗｗ
スルーしても無意味、反応しても無意味。残酷なJSが支配する
アンチjsが自作自演で暴れ出したぞw
仮に暴れていても本人がそう思ってないなら
アンチ自作自演
JSがいかに素晴らしいか主観によって語ることが批判されるとかおかしくね？
例えば未来のJSでは
>>801 ,806はもっと簡潔に、もっとセキュアに記述できる
JSの型がユルユルなのは結構やばそうなんだけど
JSは自由な言語だから。ちゃんとわかってコーディングすれば何の問題もない
>>838 あ、実際に開発してない人の意見はいいです
俺が開発してるかどうかは問題じゃない
sublime linter いいよ
>>840 それは言語じゃなくてブラウザのAPIと実装のおかげ
結局JS厨はブラウザで動くという意外のメリットを提示できないんだね
>>837 シンタックスのチェックなら実際に動かしてみれば検出される
ある程度の規模になるならモジュールテスト書いて動かす
Lintツールも使いたい奴は使う
>>792 >>795 JavaとJavascriptはダメだなぁ
特にJavaは静的型言語特有の冗長さ全開なのに
肝心なところで穴が開いてて酷いわ
RubyとPythonは文字列の足し算も出来ないのか
文字列連結と出力に何の関係が……？
'foo' + nullでfoonullになったら何かまずいことあるのか？
>>847 write 'debug value = ' + value
ここでいちいち動作が中断するし、出力も出来ないんだろ
>>848 それもfoonullになって欲しいわ
まずnullの中身が文字列'null'なのがおかしいだろｗ
>>> value = None
obj が null のまま加算することがあってはならないのに
nullの中身？
>>852 ほら、結局そういうのかまさないと駄目なんだろ
めんどくさ
出力以外でそんな加算をしたらバグなのにエラーも吐かずにプログラム続行
nullやundefinedが文字列と連結出来なくても
そのためにコンマという演算子を定義して仕様のシンプルさを
この点に関してはPythonの方がいいだろ
Python3 (または Python2 で from __future__ import print_function使用時) では
printはただの可変長引数の関数で、カンマに特殊な意味はない（引数を区切るだけ）
当然 print('debug value =', value) で
>>851 と同じ出力が得られる
>>860 可変長引数は危険だな
引数間違えてもエラーで止まらない
>>861 引数間違えたら困る関数に
可変長引数を使わなきゃ良い
まあブラウザでは多少エラーが出ても
お、今日はJSアンチきてないのか。
>>863 それは分かる
でもデバッグ用にもっとstrictなモードがあっても良いような
use strictがそのうちもっと厳しくなるんじゃね
>>864 ずっと書き込んでますが？ソースも晒してますが？
今日はいつものように妄想垂れ流さないですか？
>>868 GoやHaskellには可変長引数は基本は無い
基本はね
>>869 で、printが可変長で何が問題？
GoやHaskellはwrite 'debug value = ' + valueが出力できるのか？
本当にお前らの言い分聞いてると、
メリットとデメリットを天秤にかけてるだけでしょ
>>872 動的だからこそ実行時エラーを捕まえる必要がある
>>870 haskellのは特殊
でもpythonは基本的な普通の言語機能として可変長が定義できる
>>875 お前が言ってるのはwhileループが止まらないかもしれないと言ってるのと同じ
>>874 実行時のエラーなんて解釈によって変わるじゃん
>>878 危険なものを簡単に定義できちゃうのは危険
>>877 まあ、解釈によるのは事実なので
>>801 みたいな抜け道はあっても良いと思うよ
でもデフォルトはstrictな方が良いでしょう
>>879 可変長はデフォでもなければ推奨されてるわけでもない
>>880 デフォで型についてもstrictな方がいいとは思わんの？
>>879 うっかりミスで気付かないうちに
可変長引数を定義したことなんてねーよ
>>882 型についてstrictな方が良いって話をしてるんだろ
>>883 うっかり引数書き忘れたりすることはあるだろ
それがエラーにならない
そして簡単にできちゃったら、便利だから乱発するもんだろ
それが良くない
>>885 引数を何に使うのか知ってれば可変長の方が便利で乱発するとか言えないと思うのだが
何が来るのか分からない方が便利なのか？
>>885 > そして簡単にできちゃったら、便利だから乱発するもんだろ
お前と一緒にすんな
別に可変長引数は常に便利ってワケじゃねーよ
むしろ関数を定義する側は面倒臭いわ
>>886 型付けを静的に行うか動的に行うかと、
型付けの強い弱いを混同するな
Cは静的に型付けを行うが型付けは弱いし、Javaだって文字列連結に関しては弱い
>>888 誰も常に便利だとか言ってないし、全く面倒ではないとまでは
言ってないのだが
>>890 言いがかりが苦しすぎるつってんだよ
プログラミングしたことないだろ？
まあ、心配せんでも乱発はしないよ、常識的に
>>889 でも、静的に行うことによって、動的に型を変更できなくなるのだから
その点ではstrictだろ？
>>892 言語の思想として制限する言語があるくらいだし、
的外れでもないんだけどな
よくわからないけどこれは名言かもしれない
strictがいいなら、値の変更代入自体出来ないhaskell最強だろう
JavaScriptはデフォで全てのfunctionが可変引数ですが何か？
まんこ
JSのfunctionひどすぎるだろ…
７２ ◆/6c/RpHY/o 「 #&%#)&'%#()'$&'#(&)#('&)#$('&～!!!!!（意味不明ｗ 」
function fib(n) {
javascriptは柔軟性が高いんだよ
個人的には、こんなイメージ
>>903 余計なincludeしなくても始めから使えるところはいいね。
argumentsの最大の罠は
まあ確かにこうして見るとJavaScriptは酷いな
問題になってるからJavascriptへコンパイルする言語が
ここでも「JSのバッドノウハウ」が顔を出す
CとJSはなんか雰囲気似てるよね
いくらCでもデフォルトで可変引数なんてことはないぞ
次のテンプレに可変長引数がデフォの言語はスレ違いですって入れとくか
arguments使わなければよい
問題は呼び出される側じゃなくて、呼び出す側が全く引数リストに縛られないことだろ
950あたりになったらちゃんとしたスレタイで立て直すから削除依頼出してこいよ
いや、しかしなんでデフォルトで可変引数なんだ？
rubyがフェイドアウトしている件w
>>908 でも問題視している発言は確かにあまり聞かない
>>918 前スレから荒らしてたJS厨がスレタイとテンプレを改変した
ついでのJS以外スレというのも立てた
>>919 型がユルユルなことは常に問題視されまくってるじゃん
>>921 俺が言ってるのはデフォルトで可変長引数になる問題な
というか、気づいてないやつが大半な気すらする
>>922 確かに。ありえないから自分の言語と比較しようとちょっと触ったくらいじゃ試さないしねｗ
ちょっと衝撃だった。引数を間違えても動いてしまうというデメリットしかない
>>915 またアンチJSが立てたか
おまえpythonに泥塗ってる罠
仮に100歩譲ってデフォルトが可変長引数なのは良しとしよう（良くないけど）
>>926 普通はundefinedをチェックして足りないことは検出するね
と言ってもエラーにすることは普通はしない
デフォルトの値を割り当てて継続するのが普通
あと、多すぎる場合は、普通は無視する
どうしてもエラーにしたかったら、arguments.lengthのチェックだな
全ての言語のに劣る糞仕様だな
実際はそういう言語設計ミスも揚げ足取りの類だよ
いやー、困ってるんじゃないかなぁ
どんなに困ってても使わなければいけないというだけ
困ってるなら、これを指摘して文句をいうブログなりなんなりが
こんだけ糞仕様なのに素晴らしい言語だから使われてるとか
糞なところもあるけれど、
JSをどげんかせんといかんと思ってる人は本当に多いよ
>>933 並以下とは思わんね
最近までメジャーな言語ではクロージャない言語の方が多かったわけだし
問題があるとしたらfunctionが長ったらしいのと
外部の変数がどうのとかってのくらいで、基本は素晴らしい機能だと思う
普及した原因は言語の良し悪しとは一切関係ない
他にない素晴らしいコード、安全なコードを見せてくれよ
>>936 最近までとか予防線張ってるところが虚しいな
問題はあるし、他の言語では当たり前だし
JSの価値はHTMLにさないって事実になぜ気づかない？
言語としては本当にゴミだよ
個人的にはES5準拠で常にuse strict出来るならjsのままでもいいかな
HTMLにしかない
javascriptへコンパイルする言語が多いのは、不満が多いからというより、
>>937 実際、最近のメジャーな言語はクロージャを備え出したんで、
予防線でも何でもなく事実
javaも備える予定だし
たとえばPythonをJSにコンパイルするとかってPython完コピは無理なんだなって感じ
普通にwikipediaの例
例えば、var mod = requrie('module');
>>946 pythonは良い言語だからね
たいていはpython持ち出しとけばできるし
>>943 無理なのは同じ書き方であって、
そのコードで実現していることは
どの言語でも実現できるよね？
>>945 作れるから？
それによってできる、他の言語では実現が難しい操作って何？
クラスのインスタンスと同じように見えるが
CでもJavaでも出来ますね
>>951 関数ポインタでも無名クラスでもダメ
クロージャーがない言語は
クロージャーで作れない。
糞仕様を利用したとんでもないショートカットはあるかもしれないが
>>947 CもJavaも無理だね
>>949 書き方がかなり違っても良いのならそりゃ出来るけど
Cで出来る事はアセンブリ言語で出来るのと一緒で
>>950 ちょっと前に、jQueryのプラグインの議論であったじゃない
ああいう感じのこと
他の言語ではクラスのインスタンスにメソッドを追加するのが
出来なかったりする
rubyではできるし、pythonは知らないけど多分出来るだろうが
>>951 どちらも記述が違いすぎて気軽には使えないね
それに、Javaはfinalしか参照できないし、Cは外側の環境は基本参照できないし
無理 → 気軽にできない
>>952 はあ？じゃあクロージャでクラスはできないんだな
聞いてた話と違うわ。そんな言葉遊びしかできのか
結局いつものJS厨だな
これも一例かな
>>955 それでいいよ
まあ、正確な事言えば無理な事なんて基本はないからw
はい草。いつものJS厨でしたとさ
Javascriptご自慢のfunctionの挙動がキモい（実行はnode.js）
そうだねjavaでクロージャの記述は大変だね
>>961 気軽にかけるよ
functionは実はクラス相当
結局HTMLに逃げるしかないんだからこの板に向いてないよ
JSはデフォルト引数もだせえな
C言語で
>>943 を実装するなら
こんなんのでいいんじゃねーの？
int newCounter(void) {
return 0;
}
int getCount(int *i) {
return i++; // ポインタってこんな書き方でよかったっけ？忘れた。
}
int counter1 = newCounter();
print("%d", getCount(&counter1));
>>960 そういうのがあるのと、統一的な理解のしやすさの理由から
var a= function()やa:function()の書き方の方をfunction a()の書き方よりも推奨する人が多い
多分有名なライブラリは後者の書き方はしてないんじゃないかな
んで、
>>943 をJavaで書くのなら
こんな感じか？ こっちも書き方忘れたが。
class Counter {
private int i = 0;
public int get() {
i++;
return i;
}
}
行数おんなじ。
>>960 何もキモくないな。
宣言はコンパイルフェーズに行われて
代入は実行フェーズに行われるだけ。
>>966 だからそれのことを言ってるんだが。pyjsはないので試してない
それはせっかく3に対応してるのにnonlocal使えない（JSのせいか？）し
>>801 みたいな組込型の継承もできなかった
完コピは無理だろうが洗練していけばcoffeeとかより100倍マシだろうな
そもそもPythonを使ってる俺はブラウザでやる意味がないので使わないけど
>>968 それだとnew Counterとかやらなくちゃいけなくなるよ
期せずして、クロージャがクラス相当ってのがわかりやすいコードだね
クロージャはクラスの機能を潜在的に持っていると言われる所以
>>970 原理的には何でも出来るだろ
ただ、追いついていないだけで
よし、じゃあjavascriptで作られた有名ソフトと
>>971 > それだとnew Counterとかやらなくちゃいけなくなるよ
やればいいんじゃね？
クロージャー使ってもnewCounterってやるだろ？
まあ別にnewCounter() {return new Counter() }って
staticメソッド作ってもいいけど？
クロージャーが気軽っていうわりに
クラスがないのにクラスっぽいのができて嬉しかっただけで
>>974 それだと、メソッドがまた一つ増える上に
Counter.newCounter().get()になる上に
毎回インスタンス作ってるなw
>>975 俺はJavaでクラスとか気軽に作れないけど
>>977 いやさ、使う方も大差ないよねって言ってるんだけど、わかる？
function newCounter() {
var i = 0;
return function() { // 無名関数
i = i + 1;
return i;
}
}
var counter1 = newCounter();
print counter1();
と
Counter counter1 = new Counter();
print counter1.get();
>>977 > 俺はJavaでクラスとか気軽に作れないけど
知らんがな。お前の知識不足なんか。
俺は普通に一つのファイル内に
複数のクラスを気軽に作ってる。
>>969 キリッとしてるところ申し訳ないんだけど、
Firefoxで実行すると a, b, c, d になるんですよ
>>977 もしかしてお前、
JavaScriptのコードで、newCounter()を呼び出すごとに
カウントアップするとか思ってね？
newCounter()を呼び出すごとにJavaScript風インスタンス作ってるんだけど。
カウントアップするときは、newCounterで生成したインスタンスの
メソッド（と同等のクロージャ）呼び出すんだけど？
>>973 どこが公平なんだよ
JSでデスクトップアプリ作るのなんてXUL以降くらいからだろw
>>976 「別に」とは思わんねえ
javaのインターフェースやクラスでdomイベント扱うコードとか書きたくない
>>978 それだと(newCounter())();でいいんじゃないの？
javaの方はインスタンス作っちゃうから一旦変数に入れるけどw
>>982 クラスがある言語はJavaだけじゃないよ
>>979 俺も作ってるけど、クロージャほど気軽じゃないな
やっぱり、名前付けなくちゃいけないし、インスタンス作るからか
>>982 だからさ、他の言語と全然話題を共有できないでしょ
これがブラウザでは相性が良いとか意味不明な言い訳するばかりで
それって他の言語には関係のない都合じゃん
単純に気持ちの悪いだけの設計ミスを挙げたら切りがない
最終的にはHTML5だから使うって結論に落ち着く
じゃあJSファミリーのスレを立てればいいじゃんとだいぶ前にも進言したはずだが
>>982 > それだと(newCounter())();でいいんじゃないの？
> javaの方はインスタンス作っちゃうから一旦変数に入れるけどw
JavaScriptでも一旦変数に入れてるだろ。
> var counter1 = newCounter();
> print counter1();
それともお前、カウンタなのに一回使って終わりか？
二回目どうするんだ？言ってみろ。
>984
>>982 > それだと(newCounter())();でいいんじゃないの？
Javaだと同じコードは
(new Counter()).get();
別に一旦変数に入れる必要はない。
>>986 スマンそこは俺が間違ってた
>>987 いや、それはその例が付けてるだけで
クロージャは定義して即引数に渡したり呼び出したりする場合に
付けなくて良い
>>988 そうだな
まあgetが冗長だけど
無理→気軽にできない→getが冗長
>>990 getが冗長だし、名前もつけなくちゃいけない
結果として気軽に出来ない
ほら見て、たった4文字の争いｗ
getはたいしたことはないが、名前考える負担は大きいよ
クロージャ（メソッド一つのインスタンス）
>>985 有名なデスクトップアプリ挙げれば良いんだろ？
C++が明らかに有利だけど意味あるの？
ちょっと検索して見つけたのは
Mozilla Thunderbird
Komodo Editor
>>994 ライブラリによってcallだったりapplyだったりfだったりしそう
で、同じクロージャなのに、あっちのライブラリでは使えるけど
こっちには使えないとか発生しそう
>>996 超些細な問題。
どうせドット押せばわかること。
え？それはダサいよ
おい、最後 Javascript vs Java になってるじゃねーか
1000 ：
結論 ：2013/05/06(月) 04:34:03.66
Python >> 越えられない壁 >> Java >= Javascript
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。