13/05/03 18:08:20.49
URLﾘﾝｸ(golang.jp)
> メソッドと演算子のオーバロードをサポートしていない理由は?
>
> メソッドを呼び出す際に、メソッドの型をいちいち調べしなくてよい方がシンプルです。
> 他の言語に接した経験から言えることは、同じ名前で、かつシグネチャが異なるメソッドの寄せ集めを持つことは、
> ときに役に立ちますが、混乱を招くだけで充分に機能しません。
> 型の中で、メソッドが名前だけで検索できるよう制約を課すことは、Go言語の型システムを単純な仕組みにする上での大きな決断でした。
Javaを含む殆どの静的型付けOOPLを全否定だな
これがGoogleの天才が出した結論か
176:デフォルトの名無しさん
13/05/03 18:09:39.92
それが吉と出るか凶と出るかわからないのだが、お前が正しいと思う根拠は何？
177:デフォルトの名無しさん
13/05/03 18:11:17.57
googleがこう言ってるからって自己の無いただのgoogleの代弁者のくせにこの底抜けバカっぷりがすごい
何も理解せずに行き当たりばったりで喋るからこうなる
178:デフォルトの名無しさん
13/05/03 18:11:58.07
主流になることには失敗するかもな
仕様の善し悪しより人気や宣伝の面もあるし
ただ、自分たちが使うことも念頭において開発してる言語だし、
真剣に検討した結果であることは間違いない
仮にそう決断したことが悪い判断だったとしても、
お前が言うように手放しで喜べるような単純なもんでもなく
議論が裏にあるってことだ
少なくとも、浅い考えで「内包表記がないー、オーバーロードがないー
話にならないー、全然違うー」
なんて話ではない
むしろ、そんなものあってもなくても実は生産性に大差はないんだよというのが
説得力を持つ
179:デフォルトの名無しさん
13/05/03 18:13:26.78
> 演算子のオーバーロードに関しては、絶対に必要というより、あれば便利という程度であり、
> 採用しないことでシンプルさを保ちました。
そしてメソッドのオーバーロードは結構批判的なのに、
演算子オーバーロードはそうでもないという
180:デフォルトの名無しさん
13/05/03 18:13:36.88
失敗したら説得力ねーよｗ
181:デフォルトの名無しさん
13/05/03 18:14:02.28
>>179
C++スタイルガイド見てこいよ
かなり批判的
182:デフォルトの名無しさん
13/05/03 18:16:57.58
>>181
見て来た
> 演算子をオーバーロードするとコードは直感的にわかりやすくなりますが、次のような欠点もあります。
>
> ・コストの高い操作なのに、コストの安い組み込み操作だと思わせてしまう。
> ・オーバーロードした演算子を呼び出している場所を見つけるのが非常に困難になる。== の呼び出しを探すよりも Equals() を探す方がはるかに簡単です。
> ・ポインタにも機能する演算子があるが、これらはバグを生みやすい。Foo + 4 がやることと、&Foo + 4 がやることは全く違います。コンパイラはどちらにも警告を出さないため、デバッグは非常に難しくなります。
> ・オーバーロードには想定外の悪影響もあります。たとえばクラスが単項 operator& をオーバーロードしていると、クラスは安全に前方宣言できません。
基本的に2番目以外はC++固有の問題だと思う
183:デフォルトの名無しさん
13/05/03 18:18:47.69
>>178が必死に話を有耶無耶にしようとしてるところ悪いけどさあ
一長一短あるならリスト内包表記がなければ優れてるとかいう馬鹿な主張をしてる
お前は本当に救いようがない馬鹿だということを自白してることになるし
リスト内包表記やオーバーロードの有用性は未だに否定されてないのだが
184:デフォルトの名無しさん
13/05/03 18:20:36.34
ぶっちゃけ、内包表記と演算子オーバーロードがなくても
>>136レベルの簡潔さにはなるんだろ
十分許容範囲だわw
理解に大きな差が出るとは思えない
>>182
そうかね、一番目は明らかに固有じゃない気がするし、３番や４番も
同類の問題が出てきそうだけど
>>183
有用性とデメリットがあってそのバランスを取った結果採用されなかったってことだろw
185:デフォルトの名無しさん
13/05/03 18:20:49.34
C++の演算子オーバーロードはややこしい
Pythonはシンプルだし。むしろ無いと困る
というかどうせ代替のメソッドを定義することになるが
こうすると式に一貫性がなくなる
186:デフォルトの名無しさん
13/05/03 18:23:32.13
まあ、人気が言語の良し悪しだと言いたいなら、
お前の嫌いなJavaがPythonより良い言語ってことになるけどいいの？w
187:デフォルトの名無しさん
13/05/03 18:25:34.62
>>184
Googleの天才は採用しなかった、他の天才は採用した
なんでGoogleが一方的に正しいんだ？馬鹿？
188:デフォルトの名無しさん
13/05/03 18:25:39.44
>>186
メソッドのオーバーロードがあるJavaなんて
Googleの天才達によって否定済みですけど？
189:デフォルトの名無しさん
13/05/03 18:31:49.51
>>186
実際Javaの汎用性やそれに伴うライブラリの豊富さは強いだろ
それに対してPythonはPythonの良さがあると言えるわけ
一ミリも知らない言語をgoogleが作ったから良いと言っちゃう馬鹿と一緒くたにしないでほしいわけ
190:デフォルトの名無しさん
13/05/03 18:38:56.67
>>187
一方的に正しいとか、まあそこまでは言ってない
他が天才かどうかは知らんが、仮にそうだとしても、意見が割れてるのは確かだ
その時点で、内包表記の有用性はかなり怪しいものになるんだよ
>>188
そうだね
人気がある方が正しいと考える君の考えは
ここでもGoogleに否定されたわけだ
DartやGoは今のところ人気はない
ただ、だからといって正しくないとは言えない
>>189
結局仕様の良し悪しじゃないじゃんw
191:デフォルトの名無しさん
13/05/03 18:42:25.20
>>184
一番目も、C++の場合、オーバーロード無しで演算子が出来る事は
Cと同じだから低コストと思うワケで、
高コストな操作（文字列やリストの連結等）が演算子で書ける言語の場合
演算子だから低コストなんて思わないよ
だから前提からしてC++固有とまでいかなくても、最近の言語には当てはまらない話
192:デフォルトの名無しさん
13/05/03 18:42:58.87
>>190
Javaの仕様の悪いところやPythonの仕様の良いところも馬鹿なお前と違って言えるし
それは議論されつくされてる。リスト内包表記が無い方がいいとか言ってる馬鹿はいないけど
実際正解してないgoogleを正解例としてpython批判してる馬鹿が
問題となるコードを例によって一回も出してくれないしこれからも一生出さないと思うと呆れるしか無い
193:デフォルトの名無しさん
13/05/03 18:44:20.90
JavaとJavascriptがウンコって結論になれば
別にGoが最高の言語という結論になっても構わない俺がいるw
194:デフォルトの名無しさん
13/05/03 18:45:04.15
言語を一ミリも知らないのはどっちだw
本当は、「まともなプログラマーなら、内包表記や演算子オーバーロードを採用して当たり前！
主要な新しい言語は全部そう！」って思ってたんだろw
正直になれよw
>>191
一番有名な例であるiostreamからして高コストなioだからなあ
195:デフォルトの名無しさん
13/05/03 18:45:51.61
JS絶賛から逃げ出して苦し紛れにGoogle擁護してるゴミがどこまで頑張るか観察したい
頑張ってると言っても正しさは一切ないけど
196:デフォルトの名無しさん
13/05/03 18:47:42.52
>>195
まあ別に逃げ出してないし、
俺がどこまで頑張ろうとJSの時代が来ることは変わらんわけでw
指をくわえてみてると良いよw
197:デフォルトの名無しさん
13/05/03 18:48:40.93
>>193
そこなんだよな
逆に言えばJS厨はJSが糞だという結論に落ち着きかけたから
Googleをスケープゴートとして使ってるだけ
Googleの言語はまだまだだし、JSが科学で使い物にならないという事実は明らかなのに
198:デフォルトの名無しさん
13/05/03 18:50:12.24
>>197
いつ結論が出たんだよw
お前が勝手に勝利宣言してるけど、
真実はライブラリがないだけで、JS自体はちっとも糞ではなく、
これからどんどんライブラリが出ることも確定してるってことだ
199:デフォルトの名無しさん
13/05/03 18:50:48.10
>>196
ほら、今がショボいことを認めたくないから現実逃避を続けてるじゃん
200:デフォルトの名無しさん
13/05/03 18:52:08.63
はい、今はライブラリがなくて完敗宣言っと
201:デフォルトの名無しさん
13/05/03 18:52:14.65
え？確定してんの？
202:デフォルトの名無しさん
13/05/03 18:53:26.65
>>199
いや、今はしょぼいよ
数値計算のライブラリがないという点でな
ただ、ウェブ関連は充実してるし、これから
数値計算もこれからしょぼくなくなるけど
>>200
今だけなw
良かったなw
>>201
まあ分かる奴には分かる
ヤバいよ
マジで来る
203:デフォルトの名無しさん
13/05/03 18:54:20.74
確定してるわけないだろ。大規模なライブラリはブラッシュアップに時間がかかるし
万が一、数年後にまともなライブラリができるとして今JSを使う必要性はまったくない
完成してから吠えてくれw
204:デフォルトの名無しさん
13/05/03 18:55:10.59
数値計算で今JS使わなくても良いのは確か
というかまず、充実したC++ライブラリのラッパーがくるんじゃないかね
205:デフォルトの名無しさん
13/05/03 18:58:32.08
だからー、演算子オーバーロードがないと式の記述が不自然になるんだってｗ
JSは一生ねーよ
206:デフォルトの名無しさん
13/05/03 19:00:33.36
C++のラッパー作るだけで良ければ今頃どの言語にもscipy相当があるよ
Railsクローンが色んな言語にあるようにな
なのに、scipy相当がPythonにしか無い時点で察しろって話
207:デフォルトの名無しさん
13/05/03 19:01:27.55
>>205
まあそういう奴も安心
なんせ別言語が定義できるくらいだから、別の言語が使えるようになるよ
俺は直接JS使うけどw
208:デフォルトの名無しさん
13/05/03 19:04:09.87
>>207
君は科学技術計算に縁のない底辺ドカタなんだから
最初から関係ないよ
いつまでもJSを使っててくれて構わない
209:デフォルトの名無しさん
13/05/03 19:05:36.81
>>208
確かにあんまり縁がなかったわw
万一今科学計算が必要でも別にC++やpython使うから良いけどw
210:デフォルトの名無しさん
13/05/03 19:07:10.00
使うなよ気持ち悪い
211:デフォルトの名無しさん
13/05/03 20:27:01.00
Scipyっての知らなかったけど、面白いな
遺伝的アルゴリズムとかもあるのか
ちょっと遊ぶのにいいかもしれん
このスレでJavascriptの良さを力説するのも無駄じゃなかったw
212:デフォルトの名無しさん
13/05/03 20:51:38.70
馬鹿の上にこの気持ち悪さ
これは凄い
213:デフォルトの名無しさん
13/05/03 21:42:10.23
伸びてるから何かと思ったら
数値計算向けの言語pythonで数値計算のお題出して
しかもライブラリ借りて解いて喜んでいるのか
dom操作のお題出したあとjQuery使って解いて
Javascriptスゲーと言ってるようなもんだわ
214:デフォルトの名無しさん
13/05/03 21:45:20.48
しかも、Javascriptに一時間程度で簡単に解かれちゃってたw
215:デフォルトの名無しさん
13/05/03 21:46:20.69
Linuxのシステムの一部でも使われてるのにそれは無理があるわなあ
実際JSってあらゆる普段使いに向かないんだからさ
216:デフォルトの名無しさん
13/05/03 21:48:29.92
まあ、pythonが数値計算向けってのはちょっと違うな
もともとは汎用スクリプト言語
JSはブラウザ用言語だったが、今となっては広範囲に使える汎用言語
ただ、数値計算は凄いライブラリがある関係上、pythonが今のところ有利
217:デフォルトの名無しさん
13/05/03 21:49:01.94
>>213
御題出したのはJS厨
で、解いたんだからお前も解けという流れ
218:デフォルトの名無しさん
13/05/03 21:49:07.31
いやJS厨もライブラリ絶賛しまくりだったのに
返り討ちに合った途端にライブラリがある問題はダメってなんなん
自演下手過ぎだし
219:デフォルトの名無しさん
13/05/03 21:50:26.18
その何でもかんでもJS厨に見える癖、何とかならんのか
しかも一人か二人だと思ってるようだし
220:デフォルトの名無しさん
13/05/03 21:51:28.84
じゃあ論破された馬鹿な主張を繰り返すのやめろよ馬鹿
221:デフォルトの名無しさん
13/05/03 21:51:41.74
JS厨っていうか、壮絶なアホが一匹いる
222:デフォルトの名無しさん
13/05/03 21:52:15.14
論破された主張って何のことだよw
223:デフォルトの名無しさん
13/05/03 21:52:38.61
JSが科学技術分野で追い付くことはないし
不確定な遠い未来しか武器がないなら黙ってろ
224:デフォルトの名無しさん
13/05/03 21:52:50.82
>>221
中身のない中傷を繰り返すアンチJSのことか
225:デフォルトの名無しさん
13/05/03 21:54:34.52
>>223
そう思うなら反論する必要がない
余裕こいてれば良いだろ
226:デフォルトの名無しさん
13/05/03 21:55:04.23
ライブラリがあれば、どの言語も同じようにかけることが
証明されてしまったからな。
これからどう反論する？
227:デフォルトの名無しさん
13/05/03 21:55:19.39
JSがnumpyに追い付く証拠も出さずに妄想を毎日垂れ流す限り一生中傷され続ける
自分がデタラメを並べてると気付いてないわけじゃないだろ
悪ふざけはやめろキチガイ
228:デフォルトの名無しさん
13/05/03 21:55:44.21
お題だしたのがJS厨って怪しいな
scipyやnumpy知ってたっぽいし、むしろpython厨っぽい
229:デフォルトの名無しさん
13/05/03 21:56:46.68
ライブラリの差が
言語の差になってるうちは
言語の優位性なんて語れないぞ。
言語だけの範囲で語ろうぜ。
230:デフォルトの名無しさん
13/05/03 21:56:49.77
>>225
お前のペテンを批判してるだけ
231:デフォルトの名無しさん
13/05/03 21:58:00.15
不確定な未来について好き勝手に論じるなら、
科学技術計算でJavascriptがPythonに追いつく未来より、
asm.jsで中間言語に落ちぶれる未来の方が
遥かに実現する可能性が高そう
少なくとも、asm.jsは既に存在するわけだし、Googleも興味を持ってる
232:デフォルトの名無しさん
13/05/03 21:58:01.92
言語の差はライブラリで埋まる
証拠は数々上がっている。
233:デフォルトの名無しさん
13/05/03 21:58:55.14
状況証拠みたいなものしかないけど、Javascriptが熱いというのはマジだってば
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
234:デフォルトの名無しさん
13/05/03 22:02:22.45
JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語と結論でただろ
JS厨がpythonに対してスコープは絞るべきとか言ってたのは今考えたら悪うしかない
かなり危険な糞仕様
235:デフォルトの名無しさん
13/05/03 22:02:27.12
>>232
Javascriptは全然マシだけど、Javaはウンコすぎて無理
関数オブジェクトすらないゴミでは話にならない
やっぱり言語による差はあるよ
236:デフォルトの名無しさん
13/05/03 22:02:53.80
>>231
numpyみたいにコアの処理をCに任せればいいだけ
237:デフォルトの名無しさん
13/05/03 22:03:41.07
>>235
それがならないんだなぁ。
証拠は数々上がっている。
238:デフォルトの名無しさん
13/05/03 22:03:58.27
>>236
うん、簡単だね
今すぐ実装してきて良いぞ
239:デフォルトの名無しさん
13/05/03 22:04:42.82
>>234
ちょっと抽象的すぎて良く分からんな
Lintで検出できないようなもんかね？
240:デフォルトの名無しさん
13/05/03 22:06:16.82
>>239
変更するのがデフォだからテストも通る
241:デフォルトの名無しさん
13/05/03 22:06:24.11
>>237
おいおい、JavascriptとJavaを一緒にするなよ
ぶっちぎりでゴミだよJavaは
関数オブジェクトが無いんだよ？信じられんわ
242:デフォルトの名無しさん
13/05/03 22:07:06.29
>>234
> JSは外部の変数を暗示的に変更しまくらないと何もできないヤバい言語
それ、お前が変更しまくらないと
出来ない無能なんですーって
言ってるだけじゃないかｗ
243:デフォルトの名無しさん
13/05/03 22:07:44.91
>>241
はいはい、必死だね。
世の中にはクラスすらない言語もあるんだよ。
244:デフォルトの名無しさん
13/05/03 22:08:55.68
俺頭悪いので分からんから、具体例で説明してくれ
245:デフォルトの名無しさん
13/05/03 22:11:07.96
>>234
それがないとクラスも作れないカス言語
pythonでは明示するしコミュニティでは極力避けてるのに
JSは文化的に積極的にやってる。というかそれがないと無理なんだろうな
だとしたら、意味もなく大量のvar宣言せずにクロージャの宣言をしたほうが良い
246:デフォルトの名無しさん
13/05/03 22:12:40.24
Java使いでもEgor Kulikovみたいな奴いるしな
Egorの1/10もプログラム書けない奴が大半だろ
言語というよりやっぱ個人差の方が大きい
247:デフォルトの名無しさん
13/05/03 22:13:49.80
>>245
自分の無知をさらけ出して恥ずかしくないの？ｗ
JavaScriptにはグローバル変数すら無いしね。
248:デフォルトの名無しさん
13/05/03 22:14:11.17
>>245
ちょっと具体例で説明して欲しいんだが、
こんな感じのこと？
a = 1;
function() {
a=2; //ああ、変更できちゃったよ！
}
249:デフォルトの名無しさん
13/05/03 22:14:14.08
>>244
Cでグローバル変数を使い回すようなもの
それを便利とか言って多様するのは
プログラミング初心者と競技プログラミングだけ
それ以外でもやむを得ず使う場合はあるが
普通は危険な割にメリットが少ないから避ける
250:デフォルトの名無しさん
13/05/03 22:15:53.62
>>247
実際に関数を呼び出せば関数外の変数を書き換えるのが当然の言語だろ
違うなら反論よろ
251:デフォルトの名無しさん
13/05/03 22:16:14.21
>>249
ちょっと良く分からん
pythonのコード例とjavascriptのコード例を対比させて説明してくれないか？
252:デフォルトの名無しさん
13/05/03 22:16:21.63
>>248
そうそうそれのこと。
グローバルな変数を書き換えることができて
それを防ぐ方法がない。
これがJSというカス言語
253:デフォルトの名無しさん
13/05/03 22:17:49.08
>>252
防ぐ方法はあるだろ
あんまり変な事書くなよPython使いが皆アホだと思われるだろ
254:デフォルトの名無しさん
13/05/03 22:18:30.76
strictモードで防げるじゃん。
やっぱり無知だったか。
アハハハハ
255:デフォルトの名無しさん
13/05/03 22:20:41.17
Python使いが皆アホということで結論が出ました
はい、撤収ーｗ
256:デフォルトの名無しさん
13/05/03 22:21:32.60
なんだ Perl のパクリか（棒）
257:デフォルトの名無しさん
13/05/03 22:24:06.89
あれれ～、var宣言があるからクロージャが楽なんじゃなかったの？
その代わり｢普通の｣関数には宣言がいるのか、トホホ…
危険を承知で糞仕様にしたから、あとから継ぎ接ぎ対策したのか
そしたら一層、大量のvar宣言がつくづく無駄でしかないのだが？
258:デフォルトの名無しさん
13/05/03 22:25:36.30
>>257
いいから比較して書けよ
話はそれからだ。
無知なPython厨をいたぶるのは楽しいね～ｗ
259:デフォルトの名無しさん
13/05/03 22:26:25.56
安全モードがデフォじゃないのは危険な操作が普通に必須だからだろうな
260:デフォルトの名無しさん
13/05/03 22:28:24.21
>>259
意味不明。安全モードは英語にしたらsafe modeだ。無知すぎ
261:デフォルトの名無しさん
13/05/03 22:29:17.26
JSのデフォである危険モードを対比して言っただけだから
262:デフォルトの名無しさん
13/05/03 22:30:58.95
どこから危険モードなんてでてきたんだ？
危険モードが有るんだったら
安全モードがあるのかよ？
無いよ。安全モードなんてねｗ
263:デフォルトの名無しさん
13/05/03 22:31:03.56
え？use strictで防げるのか？
JS厨だがそれは知らなかった
通常var忘れるのは防げるが、外の変数とかぶっても防げたのか
264:デフォルトの名無しさん
13/05/03 22:34:47.93
strictって日本語に翻訳したら
安全って単語だが？
ってどや顔していってほしいｗｗｗｗ
265:デフォルトの名無しさん
13/05/03 22:35:45.16
内側の関数に責任を持つのは通常自分なので、ミスさえしなければ
通常問題は起きないのが救い
メリットとデメリットを考えるとメリットの方が大きいけど
クラスだけではjavascriptはとっくに廃れてた
266:デフォルトの名無しさん
13/05/03 22:38:23.25
use strictを使えば通常はvarを強制できる
いきなりスペルミスで変数を宣言してしまうpythonの方がよっぽど危険
267:デフォルトの名無しさん
13/05/03 22:39:54.89
>>262
デフォは危険だろ。そこは反論できないはずだ
だってそれを防ぐ方法を作ってるんだからw
糞言語すぎ
268:デフォルトの名無しさん
13/05/03 22:41:14.88
>>267
頭悪いの？
静的型付け言語が安全って言いたいの？
269:デフォルトの名無しさん
13/05/03 22:43:15.91
>>248
そもそもpython以外でこれができない有名言語ってあるの？
270:デフォルトの名無しさん
13/05/03 22:44:28.11
静的言語は動的言語より安全だと思うけど
静的言語でもスペルミスによる意図しない変数の変更は防げないだろうねｗ
で、デフォで危険な事実は否定できてないなあ
271:デフォルトの名無しさん
13/05/03 22:44:33.40
少なくとも、C/C++、Java、Schemeは出来る
272:デフォルトの名無しさん
13/05/03 22:45:10.61
そういえば、Haskellは代入自体が出来ないな
273:デフォルトの名無しさん
13/05/03 22:45:21.36
>>266
> いきなりスペルミスで変数を宣言してしまう
どんなコード？
274:デフォルトの名無しさん
13/05/03 22:46:36.11
>>273
test = 2
teest = 3 #ああ、testを変えたつもりが新しい変数に！
275:デフォルトの名無しさん
13/05/03 22:46:41.67
>>263
ここで暴れてるのは偽JS厨だから
276:デフォルトの名無しさん
13/05/03 22:47:13.79
>>274
それは危険だなｗｗｗｗ
277:デフォルトの名無しさん
13/05/03 22:47:59.28
>>274
もっとちゃんとしたコードにしてくれよ
うちのvim + pyflakes だと、宣言だけして未使用の変数は
警告で色付けされるから一目で分かるんだよ
278:デフォルトの名無しさん
13/05/03 22:50:15.59
>>277
よくわからんが、こうすればいいのか？
test = 2
use(test)
teest = 3
use(teest) #変数名の間違いに気づかず補完してしまった！
279:デフォルトの名無しさん
13/05/03 22:51:32.54
>>263
どういうこと？
280:デフォルトの名無しさん
13/05/03 22:51:37.52
>>278
補完するときに候補が複数でる(testとteest)から気付くよ
もっと真面目に考えてくれよ
281:デフォルトの名無しさん
13/05/03 22:52:03.00
アンチJSの人は結構有用なレスしてくれるようになったな
人格批判ばかりするのとは別人か
282:デフォルトの名無しさん
13/05/03 22:54:28.40
>>280
補完は言語の機能ではありません。
283:デフォルトの名無しさん
13/05/03 22:55:04.20
>>280
じゃあ、補完じゃなくてコピペで
284:デフォルトの名無しさん
13/05/03 22:55:13.05
JS厨は何人もいるだろうが、アホなJS厨は一人しかいないと思ってる
そこでここのアホなJS厨（中傷されてるお前だよ）に聞きたいのだが
お前は以外にもアホなJS厨（毎日一日中妄想垂れ流し野郎）はいるのか？
お前みたいなのが複数人いるとかさぶいぼ立つけどアホなJS厨は何人いる？
285:デフォルトの名無しさん
13/05/03 22:56:42.63
>>284
多分、お前は俺も中傷してるけど、他の奴も中傷してると思う
現実とはそんなもん
286:デフォルトの名無しさん
13/05/03 22:57:02.77
なめJS厨はスペルミスによって外部変数が変更されうるという事実に気づかないのだろうか
287:デフォルトの名無しさん
13/05/03 22:59:06.53
JS厨は優しさが垣間見える
あまり他人の中傷はしない
288:デフォルトの名無しさん
13/05/03 22:59:37.30
>>285
つまり、今はライブラリないけど将来は必ずあるとか、
google様が考えた言語と違うから糞言語とか言ってるJS厨が複数人いるのか。うわあ
JS厨やべーな・・・
289:デフォルトの名無しさん
13/05/03 23:01:10.82
JS厨は最初は句読点で平静を装って妄想を垂れ流すが
痛いところを疲れると草を生やして開き直って煽りまくる
290:デフォルトの名無しさん
13/05/03 23:01:26.58
>>288
お前が中傷してるのはもっと前からだろう？w
291:デフォルトの名無しさん
13/05/03 23:02:17.13
>>282
補完って言い出したの>>278だが……
それはともかく、エディタやツール類のサポートは一切考慮しないってこと？
ライブラリの件と同じく、そういうのが大事だと思うが……
292:デフォルトの名無しさん
13/05/03 23:02:49.86
>>289
それが一人だと思ってるのか
良く規制に引っかからないな
IP使い分けてるのか
293:デフォルトの名無しさん
13/05/03 23:03:43.54
スペルミスは言語の責任じゃないけど
これだけ使われてる言語にしてはまともな開発環境がないのが問題だよな
いっそブラウザに載せればいいのに
今でもChromeのコンソール使うと一応保管や保存できるが
前使った時はどうも挙動があやしいのでやめた
新しいファイルは作れないから
一旦別のエディッタで作ってからみたいになるし
294:デフォルトの名無しさん
13/05/03 23:04:33.28
>>291
ちなみに278は283のレスをしてるだろ
295:デフォルトの名無しさん
13/05/03 23:05:24.80
>>290
JSは奇跡の言語とかJSで凄い時代になるとか気持ち悪い煽動を始めた辺りから
叩いてるけど懲りずに毎日同じ妄想を垂れ流してる奴が
お前以外にいるのか？おそろしい
296:デフォルトの名無しさん
13/05/03 23:07:18.07
あ、あとスペルミスはuse strictして
JSエンジンの設定弄ればV8でもFFのやつでも警告でたはず（実行前に）
JSでも静的解析はできるがevalとかがある都合上OFFになってる
297:デフォルトの名無しさん
13/05/03 23:08:28.58
高機能化して欲しいのになんでブラウザ？
一番高機能なIDEであるVSがブラウザで動いてるところを想像できない
298:デフォルトの名無しさん
13/05/03 23:08:41.67
>>293
右クリックの保存の挙動が怪しいの？
今は多分大丈夫と思う
Chrome Canary使ってるけど
299:デフォルトの名無しさん
13/05/03 23:08:55.20
>>294
補完が使えるのにコピペなんてしないから、
もっと現実味のある理由を考えて
300:デフォルトの名無しさん
13/05/03 23:09:52.95
>>295
俺の前は知らんが、今は俺一人だ
ちなみに俺はソース書いてるJS厨
301:デフォルトの名無しさん
13/05/03 23:10:47.73
vimプラグインの補完は凄いと聞く。俺は数行の編集でしか使わないけど
あと最近はsublimeのステマをやたら聞く
302:デフォルトの名無しさん
13/05/03 23:11:20.89
JSでvarつけ忘れて外部変数とぶつかったらどうなるの？教えて！警告でるの？
303:デフォルトの名無しさん
13/05/03 23:11:48.81
>>299
実はダブルクリックの方が補完より速い場合あるから
マウス毛嫌いしてないで試してみ？
vimだから嫌いそうだけど
304:デフォルトの名無しさん
13/05/03 23:12:23.20
sublimeは実際凄いよ
vimよりいいかも
305:デフォルトの名無しさん
13/05/03 23:13:25.80
>>300
ソース書くって、今日も例を示せと数十回言ったけど返ってきた記憶がない
306:デフォルトの名無しさん
13/05/03 23:14:37.56
>>305
まあほとんどJSのソースしか書いてないからな
たまに議論のついでにちょろっと小さいコード片をいれるくらい
307:デフォルトの名無しさん
13/05/03 23:17:00.39
デタラメを重ねすぎて狼少年にしか見えない
308:デフォルトの名無しさん
13/05/03 23:17:21.27
>>297
デバッガとセットになってて欲しいし
HTML上で使う場合はブラウザ使うし
HTMLの画像とか他のファイルも一元管理できた方がよくない？
>>298
今度試してみるかな
とは言え最近はNode.jsばっかり書いてるんだけどね
Node.jsでもブラウザをデバッガとして使うんだけど
ココら辺ももう少し連携しやすくして欲しいなあ
>>302
出ないよ
それで出たら親スコープの変数触れないじゃん
そうじゃなくて明らかに出てきてない変数から代入しようとしてたりするケースみたいなのは
JSエンジンのオプションで出せるようにできる
あとはvarを必至にすることでスペルミス軽減
309:デフォルトの名無しさん
13/05/03 23:17:47.57
クラスターのプログラム書くときにベクトルのライブラリをググったら
sylvesterとかいうのしか引っかからなかったから
数値計算は相当苦手なのはわかった
まあ低機能だから適当に説明読んで即使えたけどw
310:デフォルトの名無しさん
13/05/03 23:18:48.12
だからさ、親と子で宣言子付けるのが逆なんだよね
それで意味もなくvarだらけのコードになる
311:デフォルトの名無しさん
13/05/03 23:20:04.26
「normって何？」と言ってるJS厨がいて数値計算は相当苦手なんだなあと思った
312:デフォルトの名無しさん
13/05/03 23:21:19.40
俺みたいに理系の院行ってるならノルムは当然知ってるけど、それ以外の一般人は
普通に分からんだろうね
313:デフォルトの名無しさん
13/05/03 23:21:56.12
>>310
何言ってるのかさっぱりわからない。
クロージャーは、関数外部の変数を見れたらいけないと言いたいのか？
それはもはやクロージャーではない。
なぜならクロージャーの要件の一つが外部の変数を見れること。
314:デフォルトの名無しさん
13/05/03 23:22:37.48
>>311
知ってるか知ってないかの違い
ググればわかるようなことを
自慢げに言われてもなｗ
315:デフォルトの名無しさん
13/05/03 23:22:44.91
>>313
pythonが真のクロージャを備えていないことが
よっぽどコンプレックスなんじゃないの
316:デフォルトの名無しさん
13/05/03 23:25:11.17
Pythonに真のクロージャがないとか
JSのクロージャは危険じゃないとか
言ってる奴はアホだろ
317:デフォルトの名無しさん
13/05/03 23:25:46.24
なんか1周回って戻ってきたな
Pythonのレキシカルスコープがちょっと変わってるんで、それを調べてから書き込んだほうがいい
JS厨の俺としてもうんざりですよ
318:デフォルトの名無しさん
13/05/03 23:26:21.82
Javaで内部クラスをクロージャとして使うと
外部スコープはfinal変数しか参照できないけど、
そんな感じで、読むのは良いけど書くのはダメってのは
わりとありがち
319:デフォルトの名無しさん
13/05/03 23:27:56.20
>>314
自慢じゃなくてかなり基本的なことだから、共通基盤が違うんだなあと
ノルムと言って伝わらない人は確かに科学的な計算しないと思う
320:デフォルトの名無しさん
13/05/03 23:27:56.92
pythonでも一応外部の変数を「見る」ことはできたはず
代入が出来ないだけ
321:デフォルトの名無しさん
13/05/03 23:29:53.60
>>318
F#とかもそうなんだっけ
そういう安全装置は意味あるし、pythonのスコープがおかしいって指摘が微妙だよな
322:デフォルトの名無しさん
13/05/03 23:30:47.60
>>319
そいつは本当に自分が知らないことを聞いているのか
一般的な事柄としてそういう疑問があると言ってるのか、
そしてついでにいえば、そいつがどのレスと同一人物なのか
もう少し注意深く見た方が良い
323:デフォルトの名無しさん
13/05/03 23:31:14.37
外部変数に代入したくないときに明示するか（var）、
代入したいときに明示するか（nonlocal）の違いじゃないの？
激しくどうでもいい
324:デフォルトの名無しさん
13/05/03 23:31:45.32
>>318
それってfinalじゃなくても良くなるって話を随分前に聞いた覚えがあるけど、
Java7でもまだだっけ？
325:デフォルトの名無しさん
13/05/03 23:32:15.33
Pythonってどうしてそういう仕様にしたんだろう
当然良いことも悪いこともあると思うが
自分には他の言事の差別化が大きいのかなと思ってしまう
326:デフォルトの名無しさん
13/05/03 23:33:03.21
もしかして、pythonが簡潔を売りにしてる割にはself地獄なのも似たような思想なのかね
危険だとか
327:デフォルトの名無しさん
13/05/03 23:35:13.75
>>323
JSのが明らかに危険なのにどうでもいいってｗ
>>322
それこそ本当にどうでもいいです。
科学的なコードに対して一般的に聞くことにどんな意味が？
JSで書いたほうが良いと言ってた奴だったと思うよ
328:デフォルトの名無しさん
13/05/03 23:36:21.07
Python節、まあいいと思うよ
でも外側のスコープ変数変更出来ない方が普通だとは思わないな
変更されない、方を特殊に扱った方が自然だと思う
JSだってそれはできるし
329:デフォルトの名無しさん
13/05/03 23:38:22.45
>>328
それは超初心者レベルのプログラミングも分かってないってこと
意図しない副作用に注意するなら、変更する場合に明示するほうが自然だろ
330:デフォルトの名無しさん
13/05/03 23:38:27.76
>>327
レス見てきたけど、趣旨としては一般的なことだね
normは確かに数学の用語だけど、norm以外にもいろいろ挙げてる
から意味はあるね
normを揶揄するのは揚げ足取りの類い
331:デフォルトの名無しさん
13/05/03 23:39:53.56
>>285
変更不可な変数の宣言と混同してる
332:デフォルトの名無しさん
13/05/03 23:39:58.67
>>329
確かに
これはnonlocalの方が優れてるわ
まあselfは気に食わないけど
333:デフォルトの名無しさん
13/05/03 23:40:33.94
>>324
final変数しか参照できないって不便だよな。
for(final int i : list) {
//クロージャー呼び出し
}
for(int i : list) {
final int i_ = i;
//クロージャー呼び出し
}
いちいちfinal付けるかfinalつけた変数に代入しないといけないんだよな。
334:デフォルトの名無しさん
13/05/03 23:41:43.58
>>329
自分で書いておいてその程度の事が意図しないとかいう感覚がわからない
内側のスコープにその変数を使ってるもんだと思って、
実際には無くて、外側のいじっちゃいけない同名の変数を
意図せず弄って問題が起きることがあるってこと？
簡単な具体例を説明して欲しい
335:デフォルトの名無しさん
13/05/03 23:42:38.02
>>333
拡張forでfinal宣言するのは常識
> Java セキュアコーディングスタンダード > 01. 宣言と初期化 (DCL)
DCL02-J. 拡張 for 文のループ変数は必ず final 宣言する
URLﾘﾝｸ(www.jpcert.or.jp)
336:デフォルトの名無しさん
13/05/03 23:42:51.63
>>334
滅多に起きないけど、varを忘れてしまった場合にありうる
337:デフォルトの名無しさん
13/05/03 23:44:09.47
>>335
マジか
これは良い情報
まあ仕事じゃレビューでfinalとってくれって言われるのが落ちだろうけど
338:デフォルトの名無しさん
13/05/03 23:45:06.87
>>324
Java8で、final値だと自明な場合はfinalを書かなくても
final変数として参照できるようになる、らしい
339:デフォルトの名無しさん
13/05/03 23:45:58.38
クロージャが呼ばれるときその中身は見えないし、その変数はそのクロージャ以外でも使われるのなら
変数の中身は当然追いにくくなるし、クロージャは基本的にメリットない気がする
なんで引数で渡したりしないの？
340:デフォルトの名無しさん
13/05/03 23:46:33.01
>>336
あー、言いたいことはわかった気がするけど
ちょっといろいろと仮定が都合良すぎるな
確かに一昔前なら実際起きてそうなことだと思うけど
今は皆慣れてコーディングスタイルとかも良くなってきてるし
そのためにstrictmodeもあるしね
341:デフォルトの名無しさん
13/05/03 23:48:11.95
strict modeの存在自体が危険性を示唆してるし
なんで普通の関数にそんなものを付けなきゃいけないのか謎
クロージャにだけ付ければ良いし、そしたらvar宣言自体が無駄
という結論ではダメですか
342:デフォルトの名無しさん
13/05/03 23:49:43.39
クロージャを普通に使うJSではそれが逆に大変になるということだろうな
343:デフォルトの名無しさん
13/05/03 23:52:10.68
>>339
それはさ、クロージャをクラスに置き換えても同じことが言えるんじゃない？
344:デフォルトの名無しさん
13/05/03 23:52:23.01
var付け忘れというより、varつけて宣言した変数を使うつもりで変数名タイプミスして
グローバル変数になるとかのパターンが、かなり危険だね
なので"use strict"が導入された
>>341
"use strict"は関数毎につける必要はないよ
実質モジュール単位で有効にすればいい
345:デフォルトの名無しさん
13/05/03 23:52:59.24
>>341
どういうこと？
今話してた意図せずスコープリークしてしまうのを防ぐ役目があるじゃん？
クロージャにだけ固いスコープが必要？
よくそのメリットがわかんないな
346:デフォルトの名無しさん
13/05/03 23:53:54.26
>>344
だからさ、それ本当にuse strictで防げるのか？
俺の手元のテストコードがおかしいのか？
347:デフォルトの名無しさん
13/05/03 23:54:23.89
>>343
クラスは変更される変数と独立してないだろ
348:デフォルトの名無しさん
13/05/03 23:55:28.33
>>345
クロージャはコードが長くなりがち。
長いコードはスコープが広いのと同じことになる。
つまり何処で変数を変更しているかわかりにくい。
影響範囲を狭くするために
外のスコープに一切アクセス出来ない
クロージャ（？）が必要。
これをクロージャと呼ばないとかどうでもいい
違う名前でいいから、そういうものが必要。
349:デフォルトの名無しさん
13/05/03 23:55:53.00
use strict で防げる派と防げない派がいるけど
350:デフォルトの名無しさん
13/05/03 23:56:01.24
>>347
メソッドはフィールド変数と独立してるじゃん
同じじゃないの？
外側のクラスに囲まれてるから独立してないというのなら、
クロージャだってさらに外側のクロージャに囲まれているの
だから独立してない
351:デフォルトの名無しさん
13/05/03 23:57:09.50
だからさ、varつけて宣言した変数を使うつもりで変数名タイプミスして
それが偶然グローバル変数とバッティングした場合は
use strict付けてても無力ってことだろ
そんなレアケースどうでもいいわ
352:デフォルトの名無しさん
13/05/03 23:57:31.88
>>346
varで宣言してない変数を触ろうとするとエラーになるんだから
意図しない外側の変数やグローバル変数を弄ることがないってことでしょ？
それでも何か不満があるの？
>>348
クロージャは即時関数とも重なるから
むしろだいたい短いと思うんだけど
353:デフォルトの名無しさん
13/05/03 23:57:58.80
>>351
varを付け忘れた変数が外側とバッティングする場合はそこまでレアではない
ただ、これもレアっちゃレアだと思うが
354:デフォルトの名無しさん
13/05/03 23:58:11.69
>>349
タイプミスして
グローバル変数の宣言になるパターンは防げる
宣言済みの外部変数へのアクセスになるのは防げない
355:デフォルトの名無しさん
13/05/03 23:59:44.13
宣言済の変数もゲッター、セッター使えば一応防げる
356:デフォルトの名無しさん
13/05/04 00:02:52.85
お前らと話していると、静的型付け言語のほうが
優れていると言ってるとしか思えなくなって来るな。
人間ミスをする生き物だ。ミスしても謝ればいいだけ。
誰もそれを責める権利は持っていない。
ミスが怖いならコンピュータにでもなれよ。
357:デフォルトの名無しさん
13/05/04 00:03:35.37
クラス内のメソッドはクロージャで、だからselfを付けるってこと？なるほど
358:デフォルトの名無しさん
13/05/04 00:04:36.54
オブジェクトなら簡単に代入参照制限できるし外部関数化もできるけど
プリミティブ型はちょっと面倒だな
まあPython-JSコンバータつくるときはいいかも
359:デフォルトの名無しさん
13/05/04 00:12:48.16
>>308
使ったことないけど、Cloud 9とかintelliJ IDEAってのが良いらしい。
ただ、sublimeもlintやdev toolと連携すればそこそこいけるし、
セットってのがそんなに利点かなあ
360:デフォルトの名無しさん
13/05/04 00:13:13.68
まあスコープ浸透しない変数が本当にあった方がよくてそれで速度向上するんなら
ES.strawmanくらいには挙がってないとおかしいんだが
361:デフォルトの名無しさん
13/05/04 00:15:26.73
速度向上？
362:デフォルトの名無しさん
13/05/04 00:16:09.51
>>359
最近段々とChromeがOS化してきちゃってさ
というか９割の時間Chromeを全画面表示してるし
363:デフォルトの名無しさん
13/05/04 00:16:25.04
Colud 9 IDE
URLﾘﾝｸ(www.publickey1.jp)
凄い時代だよなあ
クラウドでIDEとか
Javascriptすげえ
364:デフォルトの名無しさん
13/05/04 00:19:51.95
>>361
初期のconstみたいに実装に思わぬ負担となる場合がある
浸透しないとその分内側は軽くなると普通思うが
前例があるからどうなるのか心配
普通の変数と変わらない程度なら実装のコンパクト化を考えるといらない
365:デフォルトの名無しさん
13/05/04 00:22:14.41
>>364
いや、誰も速度の話なんてしてなかったように思えるのに
急に速度向上の話になったからビックリしただけ
366:デフォルトの名無しさん
13/05/04 00:23:47.20
>>356
どうだろうねえ
静的型付けの方がより安全ではあるけど、動的でも
だいぶ頑張れるしねえ
むしろ柔軟性を考えるとデメリットかもしれない
静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
367:デフォルトの名無しさん
13/05/04 00:26:41.58
> 静的型付け言語だったとしたら、jQueryだのが生まれるイメージがあまり湧かない
そうか？
jQueryのキモは、セレクタ文字列から、jQueryオブジェクト型を返すだけだろ？
普通に型つきオブジェクト指向のやり方だと思うけど。
368:デフォルトの名無しさん
13/05/04 00:29:22.65
静的言語でjQueryの＄関数を実装するとかマジキチ
業界を破門レベル
369:デフォルトの名無しさん
13/05/04 00:29:32.64
>>356
このスレではスコープ関係の議論をしてて、スコープについては
ダイナミックスコープより安全なレキシカルスコープが主流になってるから
あんまり違和感が無かった
370:デフォルトの名無しさん
13/05/04 00:30:34.51
>>365
誰もしてなくてもJSにとって速度向上はものすごく大事なことなの
371:デフォルトの名無しさん
13/05/04 00:31:25.32
>>367
例えばプラグインがメソッドを追加しまくってるけど、
単純な継承では継承の順番を指定しないと駄目だろ
372:デフォルトの名無しさん
13/05/04 00:31:48.16
なぜならJSはリアルタイム性が重視される用途によく使われるから。
GUIとか、その動作速度でさくさく感が大きく変わる。
373:デフォルトの名無しさん
13/05/04 00:33:23.12
>>371
プラグインがメソッド追加するのは
jQueryの失敗点の一つだと思ってるけど。
だって、名前かぶったらどうするのさ？
374:デフォルトの名無しさん
13/05/04 00:35:19.53
VS+C#は戦車、スクリプト言語は拳銃くらいのイメージ
375:デフォルトの名無しさん
13/05/04 00:35:20.19
>>368
いいじゃない
jQuery-C++とかjQuery-Javaとか
JQuery $ = new JQuery();
$(”ul li .hoge”).css("color", "red");
がJavaのコードでも別に良いじゃない
376:デフォルトの名無しさん
13/05/04 00:37:20.94
>>373
noconflictとかでなんとかならんかね
実際そんなに問題出てる？
377:デフォルトの名無しさん
13/05/04 00:39:15.03
>>375
全然よくない
本当は型によって振る舞いを変えるのは
JIT妨害の代表格みたいなものだからJSでも最悪なんだよ
でもjQueryはブラウザとHTMLの柔らかさや非互換性があるからこそ便利なもの
静的言語でやると悪いことしか産まない
378:デフォルトの名無しさん
13/05/04 00:39:50.55
>>375
だよな。作れない理由が思いつかない。
>>376
noconflictは単にjQueryのエイリアスである$を使わない（jQueryだけを使う）
ってだけの意味でしか無いので、何も効果はない。
379:デフォルトの名無しさん
13/05/04 00:41:11.04
>>377
具体的な理由何一つ言ってないなｗ
380:デフォルトの名無しさん
13/05/04 00:41:20.53
>>374
C, C#, Java あたりは PC で
スクリプト言語はスマホやタブレットなのかもしれない
381:デフォルトの名無しさん
13/05/04 00:41:31.07
Javaで$(”ul li .hoge”)という書き方は内部で$メソッドを定義しない限り
残念ながら出来ない
どうしても、$.$()になる
Cなら出来るだろうけどそれこそ破門レベルw
あと当然extends JQueryはそれぞれ別のクラスになってしまう
382:デフォルトの名無しさん
13/05/04 00:42:49.00
>>378
名前かぶったら別の変数にして使えるじゃん
383:デフォルトの名無しさん
13/05/04 00:42:57.27
jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
静的言語で移植するのは１００％無理
ブラウザのDOM関数叩ける、V8のライブラリとして作るのならなんとかというところ
384:デフォルトの名無しさん
13/05/04 00:44:09.85
>>381
$が関数名として使えないとかいう話？
使えるけど？
> $.$()になる
あぁ、staticインポート機能を知らないのか。
385:デフォルトの名無しさん
13/05/04 00:45:24.42
>>382
えとね、今はプラグインのメソッド名の話してるの
$オブジェクトを別の変数で使う話してないの
386:デフォルトの名無しさん
13/05/04 00:45:25.53
>>384
ああ忘れてたわ
すまん
387:デフォルトの名無しさん
13/05/04 00:46:12.63
>>385
だから、プラグインのメソッド名がかぶるなら、$オブジェクトを別の変数に入れて
それぞれ使い分ければ良いだろ
388:デフォルトの名無しさん
13/05/04 00:47:39.72
staticだと、それこそnoconflictができないよね
まあ何か考えれば方法があるのかもしれないが
389:デフォルトの名無しさん
13/05/04 00:47:41.21
無理だって言われてるのに意地張るなよ
それともチューリング完全だからとかいうのか？
390:デフォルトの名無しさん
13/05/04 00:50:57.95
>>387
お前馬鹿か？
$をhogeって変数に入れても
プラグインのメソッドは、
$にもhogeにも作られるんだよ。
$はオブジェクト、つまり参照型なんだから
コピーは作られない。
391:デフォルトの名無しさん
13/05/04 00:54:19.33
>>388
noconflictもstaticもお前勘違いしてるだろ。
無理に参加しなくていいよｗ
392:デフォルトの名無しさん
13/05/04 00:55:26.14
>>390
deep copyすればいいじゃない
393:デフォルトの名無しさん
13/05/04 00:58:42.91
>>383
> jQueryはイベントハンドラとかthisの上書きとかいろいろJSならではのことやってるから
> 静的言語で移植するのは１００％無理
JavaとJavaScriptでthisの扱いが違うのだからそれは当然
100%同じインターフェースで実装できるわけじゃないが
実用上困らないレベルでは実装可能。
例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
394:デフォルトの名無しさん
13/05/04 00:59:10.41
>>390
何がどう出来ないんだ？
単なるオブジェクトだよ？
クローンも作れるし、それぞれに独自の拡張が出来る
プロトタイプベースの言語に慣れてないのか？
395:デフォルトの名無しさん
13/05/04 01:00:22.56
jQueryはJavaでは無理って言われて
ついにJavaドカタが本性を現した、の巻
396:デフォルトの名無しさん
13/05/04 01:00:54.91
>>392
プラグインはjQueryにメソッドを生やす。
jQueryをコピーして作られたjQuery2にメソッドは生やさない。
jQueryに生えたメソッドをjQuery2に移し替えても
プラグインはjQuery2ではなくjQueryを参照する。
397:デフォルトの名無しさん
13/05/04 01:02:33.63
まあ実際にjQueryを真似たjsoupというJavaライブラリが存在するしな。
実証されてることをうだうだ言っても意味が無い。
398:デフォルトの名無しさん
13/05/04 01:03:16.21
>>393
>100%同じインターフェースで実装できるわけじゃない
>例えばthisは、クロージャー（Javaでは匿名クラス）の第一引数にすれば良い。
別に昨日が実装できるのは当たり前なんですけど？
あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
399:デフォルトの名無しさん
13/05/04 01:03:40.69
URLﾘﾝｸ(gihyo.jp)
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"));
400:デフォルトの名無しさん
13/05/04 01:04:18.51
>>398
> あの簡素で柔軟なインターフェースは静的言語では困難って話をしてるんだけど
具体的には？
401:デフォルトの名無しさん
13/05/04 01:04:39.83
>>396
プラグインAでjQueryにメソッドをはやしてから
別名変数にクローンを保存
ブラグインBでjQueryのメソッドを上書き
余裕
402:デフォルトの名無しさん
13/05/04 01:05:30.54
URLﾘﾝｸ(code.google.com)
// 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]");
403:デフォルトの名無しさん
13/05/04 01:05:59.81
そのjOOXとやらのプラグインはどうなってるの？
イベント操作は？
404:デフォルトの名無しさん
13/05/04 01:07:39.75
// This will add a new book
$(document).find("books").append("<book id=\"5\"><name>Harry Potter</name></book>");
// But so does this
$(document).find("book").filter(ids(5)).after("<book id=\"6\"/>");
// This will remove book ID = 1
$(document).find("book").filter(ids(1)).remove();
// Or this
$(document).find("book").remove(ids(1));
405:デフォルトの名無しさん
13/05/04 01:08:41.21
>>403
落ち着け
これはXMLをjQuery風に操作できるライブラリ
406:デフォルトの名無しさん
13/05/04 01:08:52.25
>>396
jQueryを読み込んでから各プラグインを読み込む間
いつでも変数弄ったり自由にできるんだけど
JQ=DC(jQuery)
プラグイン１を読み込む
[jQuery1,jQuery]=[jQuery,DC(JQ)]
プラグイン２を読み込む
[jQuery2,jQuery]=[jQuery,DC(JQ)]
プラグイン３を読み込む
[jQuery3,jQuery]=[jQuery,DC(JQ)]
でぜんぶ別々のプラグインが使える
407:デフォルトの名無しさん
13/05/04 01:14:14.18
>>403
イベント？ Javaはブラウザじゃないんだが
一体誰がイベントを送信するんだ？
408:デフォルトの名無しさん
13/05/04 01:15:37.17
イベントとブラウザかどうかは関係ないんだが
タイマー、ソケット、エラーとかいろいろ発生源はある
409:デフォルトの名無しさん
13/05/04 01:17:55.92
>>380
それは汎用性という観点だろうけど、C/C++は別格
汎用性:
C/C++ >>>>>> C#, Java, JVM言語 >>>>>>>>>>>>>>>>>>>> スクリプト言語
プログラミング能力:
Lv6 => C/C++使い
Lv3-5 => C#, Java, JVM言語使い
無能力者～Lv1 => スクリプト言語使い
410:デフォルトの名無しさん
13/05/04 01:18:22.60
>>408
> タイマー、ソケット、エラーとかいろいろ発生源はある
だからなんでそれをjQuery風ライブラリで扱わないといかんの？
お前が言ってるのはsetTimeoutでできることを
jQueryでやりましょうって言ってるようなもんだよ。
jQueryが扱う対象はDOMのイベント
DOMのイベントはブラウザが発生させる。
411:デフォルトの名無しさん
13/05/04 01:18:39.92
Javaだとメソッドの引数に無名関数渡すようなのはできるのかね
jQueryのメソッドにはそういうのけっこうあるんだが
412:デフォルトの名無しさん
13/05/04 01:19:00.89
イベントループはユーザーの操作とかと関係ない
シングルスレッド、IOフリーのJSと相性がいいだけ
413:デフォルトの名無しさん
13/05/04 01:19:09.33
クラス相当のものも全部単なるオブジェクト
うひょおおおかっこいい
さすがJavascriptすげーw
クラスをコピーしたりできない他の言語とはひと味違うぜw
414:デフォルトの名無しさん
13/05/04 01:19:26.74
>>411
匿名クラスで可能。
415:デフォルトの名無しさん
13/05/04 01:20:27.00
>>414
jOOXの例で書いてみてくれよ
416:デフォルトの名無しさん
13/05/04 01:21:22.65
>>414
無理
真のクロージャじゃない
あと、Javaの場合jsonで渡すのが難しいだろうね
それこそ全部文字列にしないと
417:デフォルトの名無しさん
13/05/04 01:21:23.43
イベントとか言ってる人はXMLとかHTMLとかDOMの区別がつかんのだろう
418:デフォルトの名無しさん
13/05/04 01:21:30.25
>>408
お前が言ってる云々は意味がわからないな
自分は誰がイベントを送信するんだとか
イベントループをまったく理解してない頓珍漢な言葉に反応しただけですが？
419:デフォルトの名無しさん
13/05/04 01:21:34.90
いや最近の静的言語はより安全だしIDEのサポートもあるから難易度は低いよ
スクリプト言語でちゃんとプログラミングするのはC++並みに難しい
まあ、不等号を間抜けに並べる奴に正論は通じないけど
420:デフォルトの名無しさん
13/05/04 01:23:39.70
まあJavaScriptはスクリプト言語の王様だかな
妬み、文句を付けたがる落ち目な言語開発者の気持ちはわかるｗ
421:デフォルトの名無しさん
13/05/04 01:23:48.47
>>415
サンプルコードを見たいならテストコードを見るのが一番手っ取り早いぞ。一つ賢くなったね。
URLﾘﾝｸ(github.com)
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();
}
}));
}
422:デフォルトの名無しさん
13/05/04 01:25:00.06
なにこの
糞
みたいな言語
423:デフォルトの名無しさん
13/05/04 01:25:11.88
>>419
「ちゃんとしたプログラミング」が必要な場面で
スクリプト言語を選ぶのは無能
わざわざ遅い言語で書く必要性がない
424:デフォルトの名無しさん
13/05/04 01:25:40.10
>>421
本当にできるもんだなぁｗ
425:デフォルトの名無しさん
13/05/04 01:26:16.00
JavaScriptの速度とかJAVA並なんですけど？
426:デフォルトの名無しさん
13/05/04 01:26:28.29
結局プラグインは何一つなしと
427:デフォルトの名無しさん
13/05/04 01:27:20.30
>>421
うひょ～～～ｗ
ワロス
428:デフォルトの名無しさん
13/05/04 01:27:44.41
>>416
> あと、Javaの場合jsonで渡すのが難しいだろうね
> それこそ全部文字列にしないと
ぷっ。当たり前じゃね？
jsonはJavaScriptの文法から生まれたもので、
JavaScript以外じゃ文字列として渡すしかねーよ。
429:デフォルトの名無しさん
13/05/04 01:27:59.77
>>423
なんのためにスレタイを変更したと思う？
今すぐに死んだほうが良い知的障害を寄せ付けないため
430:デフォルトの名無しさん
13/05/04 01:28:03.91
JS厨まだ居座ってるんだな
スレタイからRuby消して最初にJavaScript持って来てるし
431:デフォルトの名無しさん
13/05/04 01:28:50.25
>>426
プラグインはjQueryの設計ミスなんでどうでもいい。
432:デフォルトの名無しさん
13/05/04 01:29:46.37
>>423
JSはasm.jsとかParallels.jsで今年末にはC#並の速度の言語になってるよ
今でもJAVAに勝ったり負けたりするレベルにはきてるし
433:デフォルトの名無しさん
13/05/04 01:30:10.70
>>430
まあ荒らしが続くようならJAVAドカタと同じ道を辿るだけ
434:デフォルトの名無しさん
13/05/04 01:31:08.74
JsonはJavaでも、リフレクションを使って生成すれば何とかなる気がする
プラグイン側がクラスを用意する必要があるがな
ただ、静的言語でこれやるのは破門レベルとされてるから
それをやる奴は出てこないだろうw
435:デフォルトの名無しさん
13/05/04 01:31:12.27
>>433
それが狙いｗ
436:デフォルトの名無しさん
13/05/04 01:31:15.95
>>428
静的言語でjQueryの代わりを作るのが大変だという話だろ
当たり前でも大変なのは変わりねえよ
437:デフォルトの名無しさん
13/05/04 01:31:41.69
>>431
プラグイン無しのJQueryとか考えられないんだが
438:デフォルトの名無しさん
13/05/04 01:32:53.25
>>434
> JsonはJavaでも、リフレクションを使って生成すれば何とかなる気がする
てんさいがいる気がする。
天災がｗ
何を考えてるのかさっぱりだね。
439:デフォルトの名無しさん
13/05/04 01:34:07.78
>>432
馬鹿かｗ
C#並になるわけないわw
JITコンパイルはコードによっては逆に遅くなることもしらない低能JS厨
440:デフォルトの名無しさん
13/05/04 01:34:51.79
>>434
素直にC使えよ
JAVAとか文字列の扱いが一番糞なんだから
jQueryの代わりなんぞできた所で激重で使えるわけない
対抗できるのはCくらいのもんだ
441:デフォルトの名無しさん
13/05/04 01:35:40.80
>437
普通にクラスを作ればいいだけだよ。
普通にjQueryオブジェクトを引数にして
jQueryオブジェクトを返すメソッドを作れば
それがプラグインになる。
メソッドチェーンができないだけ。
442:デフォルトの名無しさん
13/05/04 01:35:43.27
ご存知の通り、JS厨が語る未来は現実を完全に無視したSFだから
443:デフォルトの名無しさん
13/05/04 01:36:42.31
>>439
asm.jsはJITじゃないんですけど？
それにasm.jsはマイクロベンチや物理演算ベンチではすでにC#並になってるの知らないの？
444:デフォルトの名無しさん
13/05/04 01:38:57.03
>>439
JITに限界があるからAOTにするのがasmだろ
知ったか乙
445:デフォルトの名無しさん
13/05/04 01:39:09.76
>>443
JITじゃないならなんなんだよ
AOTコンパイラあるのかよ
446:デフォルトの名無しさん
13/05/04 01:39:34.14
ぶっちゃけメソッドチェーンは糞だと思うが、
Javaでプラグインをメソッドチェーンで使いたいなら
（>>421のJavaライブラリを参考に）
$.children().first().find("book").plugin(MyPlugin.class).map( ～略～
ってやれば出来るだろうね。
これだとクラス名は名前空間があるから
かぶることはないし。
447:デフォルトの名無しさん
13/05/04 01:41:18.33
>>438
つ
org.apache.commons.lang3.builder.ReflectionToStringBuilder
>>446
よくわからんが、毎回pluginなんちゃら.classとか書かないと駄目なのか？
448:デフォルトの名無しさん
13/05/04 01:42:09.78
>>447
書かなくていいよ。
補完されるｗ
449:デフォルトの名無しさん
13/05/04 01:42:32.76
>>444
AOTでも型が確定してなければ遅いし
>>443
特定のベンチだけ速くてもいみない
C#並ならソースだしてみろよ
あと「ベンチマークはXより速い」ってのは
実績のない言語のお決まりの宣伝パターンなんだよな
node.js推してる奴もそればっかり言ってたわ
450:デフォルトの名無しさん
13/05/04 01:42:39.16
補完って、見た目変わらんのかw
ワロスw
451:デフォルトの名無しさん
13/05/04 01:42:39.53
JS厨よお、ちゃんと使い物になってる言語の話はできないのかい？
Googleの天才言語とか普及してないベンチとか大好きだな。頭大丈夫か
452:デフォルトの名無しさん
13/05/04 01:44:37.26
>>449
asm.jsは型が確定してる
453:デフォルトの名無しさん
13/05/04 01:45:38.57
>>443
ある、というか最近出た
まだ完璧ではないけど
一部計算をマルチスレッドでさせるParallels.js（こっちはまだまだ）と合わせて
JAVAのポテンシャルを抜くことは確実
JAVAはプリミティブ型の扱いを中間コードにする仕方が悪いらしく
そこの部分ではもうだめ
>>449
型を確定させる書き方をするんだよ
a = a|0
ならaはintみたいに
ちったあ調べろ
URLﾘﾝｸ(j15r.com)
454:デフォルトの名無しさん
13/05/04 01:47:25.72
JSが速くなるわけじゃねーじゃん
型を指示する魔改造なんてほかにもある
ただの糞言語
455:デフォルトの名無しさん
13/05/04 01:49:17.92
>>450
ん？ pluginってメソッドがそんなに気になる？
これはjQuery UIでも用いられてる方法なんだけど
あっちは.pluginではなく.dialogだけどね。
jQuery UIは機能が多すぎ＆似ているため、
jQueryプラグインとしてjQueryオブジェクトにメソッドを生やすと
確実にメソッド名がかぶるだろう。
だから、$( ".selector" ).dialog( "option", { disabled: true } );
のように、.dialogメソッドを介して、.optionメソッドを呼び出している。
自分でjQuery UIのwidgetを作ればわかるよ。
自分で作ったwidgetクラスのメソッドは、このように
dialogメソッドを介して呼び出すことになる。
456:デフォルトの名無しさん
13/05/04 01:49:25.67
C#の型推定の方が万倍マシな件について
457:デフォルトの名無しさん
13/05/04 01:50:31.14
注目を集めるために実績のない言語が宣伝するのは決まってベンチマーク
そのベンチマークもねつ造でした
URLﾘﾝｸ(d.hatena.ne.jp)
boaoa 2013/03/23 12:52
asm.js、大変興味あるのですが
現在asm.js用のサンプルコードをChromeで動かすと
普通のコードよりなんと60倍も遅くなりました
+等の演算子がJITに悪影響を与えるみたいです
そして、そのasmコードをnightlyビルドで動かしてみても、
普通に書いた時コードのChromeと全然変わりませんでした
普通のコードよりなんと60倍も遅くなりました
普通のコードよりなんと60倍も遅くなりました
普通のコードよりなんと60倍も遅くなりました
458:デフォルトの名無しさん
13/05/04 01:50:54.69
asm.jsは型を確定させ、GCを止め、仮想メモリを弄らせるという
鬼畜サブセットだから当然速度はC系に追いつく
当然これを全部で使う野郎はいないだろうが
ライブラリ、特に物理演算やゲームエンジンがサポートしたり
関数単位で使えるから「要所」で使うことで劇的にパフォーマンスがよくなる
459:デフォルトの名無しさん
13/05/04 01:52:33.71
JITは面白いが型指定は周回遅れ
460:デフォルトの名無しさん
13/05/04 01:54:29.29
半日でここまで来るとかお前ら暇だな
461:デフォルトの名無しさん
13/05/04 01:55:21.25
JavaScript使いと
それに嫉妬するその他のスレになってるね。
462:デフォルトの名無しさん
13/05/04 01:56:52.81
>>455
とりあえずそれ別にoptionメソッドじゃないだろ
optionセットしてるだけ
Javaでやるならこうか
$( ".selector" ).plugin(Dialog.class).option(new Option().disable("true"))
まあちょっと冗長だが目をつぶれないこともないか
463:デフォルトの名無しさん
13/05/04 01:59:00.83
>>457
それ、ガチで俺が書いた
興奮気味に書いたからやや大げさだった
FF22じゃなくて23で試してみたらちゃんと早くなったからそこは大丈夫
V8が対応するまで使う気が起きないのは言うまでもないが
それはどんな新機能でも同じ
まずはFFが実験台となって
Parallels.jsとともに精査してほしい
そしてES.nextとぶつかるようなことにならなければ
比較的V8での実装は早いんじゃないかな？
流石に５倍とか早くなるのは大きい
それを書く前に既にV8グループで挙がってたし
早ければ１年後にはってとこかな？
ES7に入る可能性もなくもないかも
そうなったら逆に遅くなるかな
464:デフォルトの名無しさん
13/05/04 02:01:31.38
JS厨が散々すごいと吹聴してた未来ってこれかよ
互換性のための無理やり感がダサすぎw
もうJS厨のこと何も信じられない(胡散臭すぎてはじめから何も真に受けてないけど
465:デフォルトの名無しさん
13/05/04 02:01:49.13
>>463
5倍速くなると言ってもベンチマーク用に用意した
特殊なシチュエーションでそれだけ速くなるだけだと思う
正直、平均的に見たらもう素のJavascriptが5倍程度で収まる気がする
466:デフォルトの名無しさん
13/05/04 02:03:29.01
なぜJS厨は息をするように嘘をつくのか
467:デフォルトの名無しさん
13/05/04 02:03:53.66
じゃあ他の言語に立派な未来があるのかというと「？」
これはもう嫉妬にしか見えない
468:デフォルトの名無しさん
13/05/04 02:05:49.77
型の指定みたいな言語の根幹にかかわるところは
言語の仕様としてきっちり定義しないとダメにきまってる。
asm.jsのようにライブラリで魔改造して別言語にするアプローチは腐ってる
互換性のないコードが一時的に氾濫するだけ。
その後はだれも使わなくなる。
469:デフォルトの名無しさん
13/05/04 02:07:51.88
>>465
特殊なシチュエーションでいいのよ？
だってJSの速度が気になるのって特殊なシチュエーションだけだし
とくに3D周り
WebGLはなんと行列変換をJSでやらないといけないのよ
気持ち悪いでしょ、なんでネイティブで実装してくれないのって
でもasm.jsは特に型付配列を使った演算が高速になるからまさにぴったし
あと個人的にはJSでボードゲーム作ってるんだけど
ほんと、１％でも早くなって欲しいから期待してる
470:デフォルトの名無しさん
13/05/04 02:08:05.73
>>467
なんでキチガイJS厨の「？」な希望的観測に嫉妬しなきゃならんの？頭大丈夫？
471:デフォルトの名無しさん
13/05/04 02:08:30.85
>>462
少し例が悪かったね。自分も少し間違ったし。
optionはメソッド。これは変わらない。
URLﾘﾝｸ(nbnote.jp)
一部抜粋
// ウィジェット定義
$.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メソッドを呼び出す書式。
472:デフォルトの名無しさん
13/05/04 02:10:22.97
JSアンチは自分の言語を誇らしげに語ろうとはしない
なぜ？
473:デフォルトの名無しさん
13/05/04 02:10:57.21
asm.jsのベンチマークのグラフは、素のFFが軒並み素のChromeに大幅に勝ってる時点で
都合のいい状況選んだんだろうな感が満載なんだがw
474:デフォルトの名無しさん
13/05/04 02:11:14.94
単にCと相性が悪い糞仕様を自作の糞言語で尻拭いしてるだけじゃねーか
糞JS固有の問題とかどうでもいいし特に優位性もない
475:デフォルトの名無しさん
13/05/04 02:11:24.93
>>472
叩くのが好きで、叩かれるのは嫌いだからに決まってるだろｗ
ほら俺の言語を叩いてみろ。何の言語かは教えないけどな！
476:デフォルトの名無しさん
13/05/04 02:12:01.08
>>468
asm.jsはライブラリなんかじゃないよ？
asm.jsという名前がちょっとまぎらわしいかね
言語仕様をきっちり決めた新しい言語で、JSとも互換性があるっていうだけ
477:デフォルトの名無しさん
13/05/04 02:12:54.41
Cソースをemscriptenでasm.js変換したものならかなり有意な効果がある
V8のasm.js対応はわりと簡単そう
これが普及してしまいそうだとAppleとMSはけっこう焦るだろうなあ
478:デフォルトの名無しさん
13/05/04 02:13:15.67
asm.jsはマジキチだが
逆にそれがいいｗ
ただし現状では、100行を超えるコードのasm化は人間には無理
今はIDEもデバッガも皆無
早急に整備すべし
479:デフォルトの名無しさん
13/05/04 02:13:59.86
>>472
誇らしげに嘘八百を並べる方が理解不能
>>475
さっさとpython叩けよ
あ、関数内関数のスコープがおかしい、でしたっけ？
JSがおかしいだけだったwww
480:デフォルトの名無しさん
13/05/04 02:15:16.88
>>477
> これが普及してしまいそうだとAppleとMSはけっこう焦るだろうなあ
Appleはハード売れなくなるから焦るってのはわかるが、
MSはなんで焦るの？
481:デフォルトの名無しさん
13/05/04 02:15:43.78
asm.jsはできるだけ機械変換するものと思っていたほうがいい
asm.jsを手で書くのはCでasmを書くのと近い
482:デフォルトの名無しさん
13/05/04 02:16:55.81
>>477
簡単そうって何？また希望的妄想ですかw
それしかないな、本当にそれだけ。自分でもそう思うでしょ？
自分の馬鹿さ加減が嫌にならない？
483:デフォルトの名無しさん
13/05/04 02:18:27.03
出たよ。トランスレータがあるからOK
デジャブ感が半端ない
484:デフォルトの名無しさん
13/05/04 02:18:37.80
Pythonは良い言語だから叩かないわ
ブラウザでインタラクティブなことが出来たら良いんだけどね
ちなみにJavascriptの最近のベンチマークな
URLﾘﾝｸ(d.hatena.ne.jp)
485:デフォルトの名無しさん
13/05/04 02:19:31.05
>>473
マイクロベンチではFFの方が早い
V8はアプリ単位になると早くなる
URLﾘﾝｸ(kripken.github.io)
URLﾘﾝｸ(kripken.github.io)
486:デフォルトの名無しさん
13/05/04 02:20:02.69
>>483
トランスレータがあるからOKなんじゃなくて、
そもそも最初からトランスレーターで変換することを想定してるの
それがasmという名前がついてる理由
487:デフォルトの名無しさん
13/05/04 02:22:39.48
>>484
すごいな
URLﾘﾝｸ(d.hatena.ne.jp)
さて、ぶっちぎりで速いのが Scheme48 のコンパイルバージョン。
なんと 0.004sec。ただこれはタネがあって、コンパイル時に関数を評価して
フィボナッチ数を算出しているためです。したがって、コンパイルがインタプリタで
実行するのと同程度の時間がかかります。ただ、コンパイル時に評価できる
関数は評価してしまうというアプローチは関数型言語の特性をうまく生かした良い方法だと思います。
Scheme48 を除いたら、Java がトップでした（追記:[2012/12/30] Haskell の
型宣言を指定したら、Jhc に抜かれてしまいました）。JIT が効いているのは当然として、
Java VM の動作や実装を熟知している身としては、よくこんな短時間で
ブートストラップクラスを初期化できるものだと感心してしまいま
Oracle の最新の Java VM を使えば、速くなるんじゃないでしょうか。いやはや。
488:デフォルトの名無しさん
13/05/04 02:23:09.04
メンヘラの妄想に付き合うの疲れるなあ
脱洗脳のカウンセラーとかの辛さがわかる
現実に生きてない。都合の悪い話が聞こえてない
さっさとCのコードをこの場で変換してみせろ！
489:デフォルトの名無しさん
13/05/04 02:23:51.79
C (gcc -O2) 1.18
JavaScript (node.js) 2.62
速いwww
もう下手な静的言語並みになってるw
490:デフォルトの名無しさん
13/05/04 02:24:53.21
たしかV8のグループでは
Node.jsとかが挙がってた
ブラウザの中だけで考えると押しが弱いけど
これからJSは広がっていくし
例えば昨今ではモバイルOSの「ネイティブ」として使われ始めたところを見ると
V8も気にはなると思う
あと、asm.js部分は基本的に特定のエンジンに依存しない形になってるらしい
というか既存のコンパイラの上にasm.jsコンパイラが乗る形
だから多分V8での実装は困難ではないはず
491:デフォルトの名無しさん
13/05/04 02:26:40.56
もう希望的観測はいいから…
お願いだから確認した事実を喋ってくれ、お願いだから…
492:デフォルトの名無しさん
13/05/04 02:27:54.77
確認した事実・・・。
JavaScriptはここまで広く使われている。
493:デフォルトの名無しさん
13/05/04 02:27:55.09
>>489
単純な四則演算はもう十分に早いよ
でも実物になるとまだCの10倍遅い
JITの限界とか、GCとか、メモリアクセスとかがネックになってるらしい
もうここいらで限界みたい
そこを改善して実物でもCの２倍の実行時間で済ませようとするのが
asm.jsサブセット
494:デフォルトの名無しさん
13/05/04 02:29:12.50
長文で妄想垂れ流したいだけならブログでいいと思うよ
デタラメで本人すら確認のしようもない、再現性もないことで議論とか無理だし
だからこそいくらでも大きなことが言える。ログが誇大妄想で埋まってる
495:デフォルトの名無しさん
13/05/04 02:29:12.84
>>44
f(i % 2) {
496:デフォルトの名無しさん
13/05/04 02:30:58.35
嘘をついているという自覚がないっぽいのが本当に怖い
497:デフォルトの名無しさん
13/05/04 02:31:10.91
確認した事実 ↓
Python (CPython) 53.651
498:デフォルトの名無しさん
13/05/04 02:32:07.97
C言語というJavaScriptとは全く違った文法から
asm.jsの力を借りてブラウザで実行するコードを生成できる
ということは、JavaScriptを改良した言語から
asm.jsの力を借りてブラウザで実行するコードを生成できるということでもある。
JavaScriptを進化させるのにブラウザのバージョンアップを
またなくて良くなる世界ができつつある。
499:デフォルトの名無しさん
13/05/04 02:33:27.08
でもこれだけJSの高速化が盛んになってくると気軽に書けなくなる
if(i % 2)
と
if(i % 2 == 1)
ってどのくらい違うのか
でも将来の賢いコンパイラにとってはどちらも同じ意味にとられるかもと考えてしまう
これは大げさな例だけど本当に難しい
500:デフォルトの名無しさん
13/05/04 02:36:29.15
昔はVBが一世を風靡していたとき、
GUIは作るのが簡単なVBで
速度が必要な場合はC++でDLLを作る。
という手法が使われていた。
それと同じ構図がブラウザの世界にもできつつある。
JavaScriptはブラウザで動くGUIを作るのが簡単である。
だからJavaScriptでの開発というのはこれからもメインになるだろう。
そして速度が必要な場合のみ、他の言語で開発することもある。
501:デフォルトの名無しさん
13/05/04 02:38:33.70
>>493
単純な四則演算ではない実物ってのがよくわからない
再帰のフィボナッチはスタック使いまくりだよね
スタック領域のアクセスは良いけどヒープが駄目ってこと？
502:デフォルトの名無しさん
13/05/04 02:39:23.21
V8の登場以降からブラックボックス度は高まりつつあるよね
今では内部的にintを使うとか当たり前だし
それを考えると
for(i=2^31-1; i>=0; ++i) //iはfloat型と推論される
と
for(i=2^31; i>=0; ++i) //iはint型と推論される
の違いとかきになる
あとなんかfor文は結構書き方によって最適化されてるらしい
iが0からじゃなくて10からとかだと特別な意味があるのではと思われるという「噂」もあるくらい
503:デフォルトの名無しさん
13/05/04 02:40:28.29
まーた始まった。無知が自分に酔いしれて一人妄想を語る
テキトー言うだけならブログでやれよキチガイ
504:デフォルトの名無しさん
13/05/04 02:41:51.85
もうスレ半分使っちまったのかｗ
505:デフォルトの名無しさん
13/05/04 02:42:16.55
>>500には言葉が通じず対話が不可能で一切の意味のあるレスをしないから害悪でしかない
506:デフォルトの名無しさん
13/05/04 02:44:57.13
>>501
すまん、正直にいうと詳細はわからん
でもこの手のマイクロベンチだといつも2,3倍だが
大きなベンチになるとCの十数倍になるのを多く見てきた
URLﾘﾝｸ(kripken.github.io)
URLﾘﾝｸ(kripken.github.io)
asm.jsの説明によると
型チェックやGCが遅くしてる原因らしい
それでたしかasmはMath関数にも手を入れたり追加してるんだっけか
そのあたりがネックなんだと思う
あとasmでは型付配列をよく使う
そこもいくらか最適化されてるらしい
507:デフォルトの名無しさん
13/05/04 02:45:55.49
もう嘘しか言わないキチガイJS厨の相手をするのはよそう。時間の無駄だ
中身は空っぽの荒らしスクリプトなんだから。もちろんJSで記述されててバグがてんこ盛り
508:デフォルトの名無しさん
13/05/04 02:48:02.13
@A = 1..10;
@x = map {$_ * 2}
grep{$_ % 2 == 0} @A;
509:デフォルトの名無しさん
13/05/04 02:49:07.77
確かに>>500はちょっと間違ってるな
VBは遅かったが、Javascriptは十分に速い
速度が必要な場合にもJavascriptを使うことが多くなる
他の言語で書くようになるとか妄想はブログでやって欲しい
510:デフォルトの名無しさん
13/05/04 02:49:18.23
JSの話をやめた所で他の言語の話をする奴がいなさそうなんだが……
511:デフォルトの名無しさん
13/05/04 02:51:50.40
>>507
> もう嘘しか言わないキチガイJS厨の相手をするのはよそう。時間の無駄だ
消える宣言した以上、ちゃんと消えろよな。
レスなんかしたら見苦しいぞ。
よし、キチガイが消えたｗ
512:デフォルトの名無しさん
13/05/04 02:51:58.75
JavaScriptはあとはメモリアクセスだよなあ
せめてピットボードを用意して欲しい
その辺が自由になれば巨大数の問題とか解決できるのに
あとは演算子オーバーロードだな
513:デフォルトの名無しさん
13/05/04 02:53:38.99
>>510
別に無理に伸ばす必要ない
JS厨が荒らすだけのスレならJSスレに行ってくれ。邪魔
特にブラウザの話しかできないやつ見ると明らかに他のスクリプト言語から浮いてる
というかWebは板違いじゃね。日常で使うスクリプトという話は皆無
もういいよJSの話は。次スレから外して問題ない
イキイキと荒らす馬鹿が目障り
514:デフォルトの名無しさん
13/05/04 02:54:47.54
ピットボード？
さっきのボードゲーム作ってる奴でビットボードと間違えたとか？
515:デフォルトの名無しさん
13/05/04 02:55:07.15
スクリプト言語からWebやWebサーバーを取ったら……
516:デフォルトの名無しさん
13/05/04 02:55:14.34
>>508
@A=1..10;
@x=map{$_ %2 ? () : $_*2} @A;
再帰や遅延評価を使うまでもないリスト処理は面白くないんだよね…
517:デフォルトの名無しさん
13/05/04 02:55:57.32
Webはちゃんと板があるし
ブラウザは共通の話題ないし比較もできない
518:デフォルトの名無しさん
13/05/04 02:56:16.36
>>513
> JS厨が荒らすだけのスレならJSスレに行ってくれ。邪魔
毎回思うんだけど、そんなこと言っても
いうこと聞くわけ無いだろう？
519:デフォルトの名無しさん
13/05/04 02:57:08.98
>>513を苦しませるには
JSの話題をどんどんやったほうがよさそうだｗ
自分からやられて嫌なことを語るなんて
馬鹿だなぁ。
520:デフォルトの名無しさん
13/05/04 02:57:27.51
>>518
そうだよ。JS厨は死ぬまで己の馬鹿を晒し続ける
521:デフォルトの名無しさん
13/05/04 02:57:35.07
すまんｗｗ
ビットボードと入力してもピットボードになってしまう
GoogleIME
522:デフォルトの名無しさん
13/05/04 02:57:58.03
>>513
普通に言語の速度とか、node.jsとか、科学計算とか、クロージャとか
内包表記とか、Javaの話とかPythonの話とか
ブラウザ以外の話も豊富じゃん
523:デフォルトの名無しさん
13/05/04 02:59:45.56
>>522
奴には見えてないのですよ。
標的意外なにもね。
524:デフォルトの名無しさん
13/05/04 02:59:51.38
>>519
論破されたから悪意を持って荒らすだけのゴミになったんだよね
ゴミすぎる自分をどう評価してる？いきる価値ないと思うよね。死んで良いよ
525:デフォルトの名無しさん
13/05/04 03:01:02.15
というか他の言語って何が原因で遅くなってるの？
ただ高速化の需要が少ないだけ？
JSでエンジン作った方が早そうな勢いなんだけど
526:デフォルトの名無しさん
13/05/04 03:01:08.04
>>524
死んでいいよと言われても死ぬわけないしｗ
お前の願い、死んでほしい？
残念、お前の願いは棄却されましたぁぁぁｗ
527:デフォルトの名無しさん
13/05/04 03:01:51.39
>>523
本当に妄想以外で議論が出来るなら、JS厨はなんで嘘で荒らし続けるわけ？
どうせJSのことも何も知らないんだろ。幻想を語るだけなら黙ってろ
528:デフォルトの名無しさん
13/05/04 03:02:16.46
>>524
端から見てるとお前も悪意持ってて怖いわw
今までJS厨は人の中傷はあまりしてなかったが、519の人が
やり始めたな
529:デフォルトの名無しさん
13/05/04 03:02:28.00
お前が嘘だというのが
間違いなだけだろ。
冷静になれよ。
530:デフォルトの名無しさん
13/05/04 03:04:04.81
URLﾘﾝｸ(d.hatena.ne.jp)
とかみるとPerlがこんなに、PHPよりも遅いのが意外
Perlと言えば歴史ある言語だし
その正規表現は今なお他の言語(JSも)に影響を与えている
素晴らしい言語なのになぜ計算は遅いのか？
531:デフォルトの名無しさん
13/05/04 03:05:24.12
>>530
だって開発者がPerl6なんてやってて
Perl5は放置状態だもの。
532:デフォルトの名無しさん
13/05/04 03:06:00.32
>>529
そうだな、嘘でも本当でもない、不確定のゴミ情報
というかお前の存在自体がゴミ。１つもまともな情報を出さずにオナニーしてるだけ
醜すぎるわ。反論できる？
533:デフォルトの名無しさん
13/05/04 03:06:22.45
>>530
何かどうでもいい話
性能なら別の手段つかうさ
534:デフォルトの名無しさん
13/05/04 03:07:28.74
>>532
面倒くさいやつだなｗ
お前はキチガイ。反論できる？
535:デフォルトの名無しさん
13/05/04 03:07:44.25
>>525
他の言語も頑張ってる
V8作ったGoogleが天才すぎるだけ
536:デフォルトの名無しさん
13/05/04 03:10:20.95
>>534
できないね。お前みたいなゴミカス荒らしに唯一構ってるんだからな
普通の人間はヤバいキチガイを見たら邪魔だなあ、早くどっか行けと思いつつ関わらない
お前はそう思われてるんだよ。分かるか？なんで荒らすんだ。妄想なら他所でやればいいじゃないか
537:デフォルトの名無しさん
13/05/04 03:11:18.10
Googleが頑張ってほかの言語エンジンも改良すれば世界が良くなるな
538:デフォルトの名無しさん
13/05/04 03:11:53.35
>>536
残念、またしても
お前の願いは叶えられなかったｗ
539:デフォルトの名無しさん
13/05/04 03:12:10.97
V8の開発してるのは以前はSunでJavaのJITのVMの開発で活躍してた人だと思った
JIT関連のノウハウで圧倒的に先行してるんだろう
540:デフォルトの名無しさん
13/05/04 03:12:54.30
>>536
ならスルーしろよ
というか、Google天才とか言ってるのはそいつじゃねーからw
お前が誰彼構わずアタックするからこうなっちゃんたんだぞ
541:デフォルトの名無しさん
13/05/04 03:13:46.51
>>536
北風と太陽
よそにいけといえば言うほど
このスレにいることになる。
逆にここにいろと言ったほうがいいよ。
そう言ったとしてもここにいるわけだけどなｗｗｗ
542:デフォルトの名無しさん
13/05/04 03:14:51.46
>>538
俺の願いじゃなくて、みんなの願いね
心配しなくても、お前の願いであるみんなの迷惑になる行為を続けることは毎日叶えられる
良かったな。もう誰もお前がまともなんて思わない
JS厨の詐欺にはかからない
543:デフォルトの名無しさん
13/05/04 03:15:46.09
アンチJS厨が一番うざい。
だからみんな誰もお前にレスしてないんだぞ？
544:デフォルトの名無しさん
13/05/04 03:15:54.79
Goの開発もベル研にいた有名な人たちが参加してるね
545:デフォルトの名無しさん
13/05/04 03:16:24.75
まとも面したJS厨がいかにキチガイか周知できれば十分
546:デフォルトの名無しさん
13/05/04 03:16:30.42
さて、またJavaScriptの話でもしますか。
547:デフォルトの名無しさん
13/05/04 03:19:07.64
最近どんなプラットフォームでも
HTML＋CSS＋JavaScriptを使うことが標準的になっている。
これらは一例。
Google Chrome add-ons
Mozilla XUL apps and Firefox extensions
Firefox OS apps
Chrome OS apps
Windows 8 Store (“Modern/Metro UI”) apps
BlackBerry 10 WebWorks apps
PhoneGap/Cordova apps
Apple UIWebView class
Microsoft WebBrowser control
node.js (combined with jsdom or similar)
548:デフォルトの名無しさん
13/05/04 03:20:29.60
>>544
各会社から、有名な天才達がGoogleに集まってきているってことだな
Pythonの作者もちょっと前までGoogleだったらしい
今は脱退したようだが
549:デフォルトの名無しさん
13/05/04 03:23:46.29
現在広く普及している、スマホ、タブレットはもちろんのこと
テレビでもJavaScriptが動く時代だからな。
550:デフォルトの名無しさん
13/05/04 04:19:23.91
例のアンチが消えた途端静かになったなｗ
551:デフォルトの名無しさん
13/05/04 04:25:52.97
なんか寂しいな
俺も寝るか
552:デフォルトの名無しさん
13/05/04 04:42:23.52
どんな言語を使おうと避けられないウェブ化によってHTMLが
ユーザーインターフェースになるのは避けられなかったわけで。
jQueryが一番うまくHTMLを扱えたことが
JavaScriptの大ヒットに繋がったんだろうな。
553:デフォルトの名無しさん
13/05/04 05:16:59.66
多分Googleのお陰が５０％だと思う
やっぱり再注目のきっかけになったのは
検索とかマップのAjaxだし
554:デフォルトの名無しさん
13/05/04 07:19:47.60
>>539
そんな奴があんな中二っぽいコード書くのか?
555:デフォルトの名無しさん
13/05/04 07:27:41.67
>>554
どんなコード？って聞かれて
答えられないなら、そんなこと言い出すなよ
556:デフォルトの名無しさん
13/05/04 09:13:59.47
>>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
557:デフォルトの名無しさん
13/05/04 09:16:22.92
さすがに悔しいからってPythonじゃない言語を持ち出されても
「int n」でバレるぞw
558:デフォルトの名無しさん
13/05/04 09:17:55.49
せめてCythonでググれよ……
559:デフォルトの名無しさん
13/05/04 09:22:18.87
wikipediaより
>Cython は、C言語によるPythonの拡張モジュールの作成の労力を軽減することを
>目的として開発されたプログラミング言語である。
>その言語仕様はほとんど Python のものと同じ (上位互換) だが、Cの関数を直接呼び出したり、
>C言語の変数の型やクラスを宣言できるなどの拡張が行われている。
Pythonじゃない別言語じゃん
TypeScriptを持ち出してJavaScriptはええって言ってるようなもん
560:デフォルトの名無しさん
13/05/04 09:22:49.55
CythonはPythonに型注釈を追加したような言語で、
コンパイルしてPythonのC言語拡張を作る事が出来る
Cythonで書かれた関数やクラスはPythonから呼び出す事ができるし
Pythonで書かれた関数やクラスをCythonから呼び出す事もできるよ
561:デフォルトの名無しさん
13/05/04 09:25:31.15
>>559
Pythonの上位互換って書いてあるだろ
ここ遅いから速くしたいなーってなったら型を書けば良い感じ
で、C言語拡張にコンパイルするから、普通のCPython処理系で動く
562:デフォルトの名無しさん
13/05/04 09:48:47.64
>>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
563:デフォルトの名無しさん
13/05/04 09:54:22.94
C のコードはどこまで減らせるんだろうね
Python 界隈はそこらへんの問題に極めて意識的だけど
>>559
自分も別言語だと思う。Python のサブセットである RPython ならともかく
564:デフォルトの名無しさん
13/05/04 10:12:13.17
>>560-561
つまりCに変換できるようにしたTypeScriptみたいなもんじゃん
TypeScriptをCやasm.jsに変換したらそりゃ速いよ
>>562
これ最適化でコンパイル時に値を計算したっぽいな
565:デフォルトの名無しさん
13/05/04 10:15:36.41
>>564
> これ最適化でコンパイル時に値を計算したっぽい
print(fib(38))をコンパイルに含めずに
実行時にPython側からfib(38)を呼び出しても同じ
566:デフォルトの名無しさん
13/05/04 10:19:10.38
>>565
良く分からないんだけど、コンパイル時に計算していないのに、
Cの数十倍速いってこと？
ちょっと良く分からない現象だね
何かタネがあるんだろうけど
567:デフォルトの名無しさん
13/05/04 10:26:25.09
>>566
こちらの環境でC（gcc47 -O2）を実行した場合
$ time ./a.out
39088169
./a.out 0.25s user 0.00s system 99% cpu 0.257 total
568:デフォルトの名無しさん
13/05/04 10:27:02.43
>>566
こちらの環境でC（gcc47 -O2）を実行した場合
$ time ./a.out
39088169
./a.out 0.25s user 0.00s system 99% cpu 0.257 total
569:567
13/05/04 10:34:54.74
連投すまん
実行環境が違うのか、Cの速度も>>530と全然違うね
同じソースコードを使ったんだが
つまり、CPythonの速度がむちゃくちゃ遅い……？Python3.2なんだけど
570:デフォルトの名無しさん
13/05/04 10:51:19.53
最後に、比較用にnode.js（v0.10.4）
$ time node fib.js
39088169
node fib.js 1.06s user 0.03s system 100% cpu 1.080 total