【PHP,Python】スクリプト,バトルロワイヤル38【Perl,Ruby】

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
前スレ

【PHP,Python】スクリプト,バトルロワイヤル37【Perl,Ruby,JS】
http://toro.2ch.net/test/read.cgi/tech/1376836047/
2デフォルトの名無しさん:2013/09/08(日) 20:47:58.63
< `∀´>ニダー
3デフォルトの名無しさん:2013/09/08(日) 20:50:17.85
民主党は、パナソニックやシャープ、ソニーを潰す気だった?
http://www.youtube.com/watch?v=iG_oaqU0pEM

帰化朝鮮人ばかりが政治家を目指す国?日本
https://www.youtube.com/watch?v=JVhHeMqNPHY
4デフォルトの名無しさん:2013/09/08(日) 21:14:07.17
>>1
スレ立て乙
>>2
2get乙
>>3
工作乙
5デフォルトの名無しさん:2013/09/08(日) 21:58:51.72
Node.jsはHaskellを理想としつつも
GHCをハックするほど頭良くない人に作られました。
妥協の産物だったんですね。

ここは、そんなNode.jsについても議論するスレです。
6デフォルトの名無しさん:2013/09/08(日) 22:01:26.22
>>前スレ997
言語エンジンレベルのハックが困難って話で
コンバータとはぜんぜん違うよ

>>前スレ998
ジェネレータ部分はまだいいけど
イテレータ周りはまだまだ実装不足

>>5
どこにも妥協したなんて書いてないんだが
自分の都合の良いように解釈し過ぎ
7デフォルトの名無しさん:2013/09/08(日) 22:03:57.72
>>5
お前が英語読めない奴ってのは分かった。
お前が議論寄りをも煽りを選ぶ頭の悪いDQNってことは分かった。
8デフォルトの名無しさん:2013/09/08(日) 22:04:30.32
GHCはいいけれど、それでもnodeの目的を
達成するには言語エンジンレベルのハックが
必要だったってこと。
9デフォルトの名無しさん:2013/09/08(日) 22:05:46.69
GoogleがV8エンジン(JavaScript実装)ではなく
Haskell実装を作っていれば、
歴史は変わったかもしれない。
なぜJavaScriptを実装したのか?
10デフォルトの名無しさん:2013/09/08(日) 22:08:48.50
Googleに居るのは、民間人にしては賢い連中ってだけで
研究者村からみれば凡人だからGHC作れる程賢く無い
11デフォルトの名無しさん:2013/09/08(日) 22:09:25.40
>>9
HaskellがWebで使われる言語だったらそうなってたかもな
考えるのも恐ろしいが

>>10
ワロタ
12デフォルトの名無しさん:2013/09/08(日) 22:10:24.06
スレタイにも乗ってない言語共が争ってるんじゃねーよw
13デフォルトの名無しさん:2013/09/08(日) 22:26:22.70
まあ、Haskellの使用も検討するくらいの柔軟さが無いと
あの当時Javascriptをサーバサイドで使おうって思わなかったかもな
14デフォルトの名無しさん:2013/09/08(日) 22:30:30.70
Rhino「…………」
15デフォルトの名無しさん:2013/09/08(日) 22:34:19.22
>>8
Yesod見る限り、言語エンジンまでハックする必要はなかったみたいだけどね
16デフォルトの名無しさん:2013/09/08(日) 22:44:02.54
ネイティブとの連携のしやすさは重要だと思うが
17デフォルトの名無しさん:2013/09/08(日) 22:45:56.46
初めから文句つけたいだけの奴だから何言っても無駄だよ
18デフォルトの名無しさん:2013/09/08(日) 22:49:35.88
次スレはこれで
【Haskell】スクリプト,バトルロワイヤル39【JavaScript】
19デフォルトの名無しさん:2013/09/08(日) 22:53:52.38
お題
stdlib.hのrandを10回呼び出して総和を取れ
20デフォルトの名無しさん:2013/09/08(日) 23:00:18.56
stdlibのstdの意味分かってんの??
21デフォルトの名無しさん:2013/09/08(日) 23:02:36.75
性病
22デフォルトの名無しさん:2013/09/08(日) 23:03:52.84
突っ込むのはそこじゃないだろw
23デフォルトの名無しさん:2013/09/08(日) 23:06:48.52
libc.soのrand使えってことか
24デフォルトの名無しさん:2013/09/08(日) 23:08:21.88
ネイティブ連携 & 副作用
25デフォルトの名無しさん:2013/09/08(日) 23:09:13.07
考え方が逆、
ネイティブの関数を呼ぶんじゃなくて
ネイティブを関数を呼べるようにエンジン経由で提供、登録する
26デフォルトの名無しさん:2013/09/08(日) 23:11:29.28
そんなん共有ライブラリを作れる言語なら
どれでもできるやんけ
27デフォルトの名無しさん:2013/09/08(日) 23:13:17.98
オーバーヘッド短縮や循環参照でのメモリリークとか
厄介な問題を避けるためエンジン側の協力は必須
28デフォルトの名無しさん:2013/09/08(日) 23:16:49.38
よくあるコールバックを引数にとって、
処理が終わったらオブジェクトを与えて呼ぶみたいなのが
どれだけ自然にできるかエンジンによって全く違うと思う
29デフォルトの名無しさん:2013/09/08(日) 23:18:34.55
ネイティブ系の言語よりスクリプトの方が抽象化能力が高いので
ネイティブで書く必要がある処理だけネイティブで書いて
それをスクリプトでラップする方がずっと需要あるけどな
30デフォルトの名無しさん:2013/09/08(日) 23:21:20.21
Haskellは何と連携したらネイティブなの?
Haskell自体ネイティブじゃないの?
31デフォルトの名無しさん:2013/09/08(日) 23:21:21.31
nodeの凄い所は思想ドリブンで開発が進んだから
そのラップするライブラリが基本的に非同期に
なったという所だよ。
32デフォルトの名無しさん:2013/09/08(日) 23:22:38.03
おーすごい
randは呼び出せないけど口は達者だ
33デフォルトの名無しさん:2013/09/08(日) 23:24:21.95
>>29
新しいもの作るんならそれでいいが、
大きなAPIだと既にネイティブで書かれてるのを連携させるのが基本だろ。
Node.jsみたいな環境レベルなら当然そうだし。

多くをJSで書かれてはいるけど、
3大柱のEvent、Buffer、Socketは言うまでもなくネイティブだし。
34デフォルトの名無しさん:2013/09/08(日) 23:27:15.50
大きなモジュールを連携させるとこを書くのがグルー言語
35デフォルトの名無しさん:2013/09/08(日) 23:30:22.90
V8エンジンがネイティブとJSの橋渡しをしてくれるのは当然だけど
フラグをつけるとJS側にも実装に迫れる関数を提供してくれる

というか一般JSで触れる表面のAPIは皆特権JSから提供して貰ってるもので
Nodeとかでフラグを有効にしたら神様気分が味わえて面白いよ
危険だけど性能の良い関数とかも触れる
36デフォルトの名無しさん:2013/09/08(日) 23:34:38.28
そうそう、
ネイティブ|非ネイティブ
じゃなくてその間に適切に層を作ってくれるのが大事
37デフォルトの名無しさん:2013/09/08(日) 23:36:41.75
それって普通の話だぞ?もっとNode以外も触った方が良い
38デフォルトの名無しさん:2013/09/08(日) 23:37:49.72
そう言えば各言語のメタプログラミングの能力はいかほど?
マクロは抜きにして
39デフォルトの名無しさん:2013/09/08(日) 23:38:15.59
マクロ抜くなよLispが泣くぞ
40デフォルトの名無しさん:2013/09/08(日) 23:41:20.90
>>38

JavaScriptは関数定義の引数の数を取得できる。
41デフォルトの名無しさん:2013/09/08(日) 23:42:03.94
>>37
ん、誰もNode限定とは言ってないだろ
ただV8みたいな素晴らしいエンジンの重要性を説いてるだけのこと
42デフォルトの名無しさん:2013/09/08(日) 23:44:42.60
マクロ入れるとなんでもありになっちゃうし、
言語の能力とは少し違うんじゃない?

もっと高次元の能力が知りたい。
43デフォルトの名無しさん:2013/09/08(日) 23:46:49.00
マクロがどの程度のレベルを指しているのかしら無いが、
C言語みたいなプリプロセッサがOKとなると
汎用のプリプロセッサをどの言語でも使うことができるからなぁ。
44デフォルトの名無しさん:2013/09/08(日) 23:47:50.18
んー、その条件ならSmalltalkが無双すると思うよ
わりとマジで
45デフォルトの名無しさん:2013/09/08(日) 23:49:34.61
プロキシが無い言語ってあるの?
46デフォルトの名無しさん:2013/09/08(日) 23:51:30.18
>>45
君の知ってる全ての言語と
その言語にあるプロキシは具体的に
どれのことか答えなさい。

繰り返すが、君の知ってる全ての言語です。
47デフォルトの名無しさん:2013/09/08(日) 23:53:32.09
>>40
よう知らんけどそれっていまどきの言語なら普通じゃないの?
48デフォルトの名無しさん:2013/09/08(日) 23:55:02.23
COBOLのCOPY文最強
49デフォルトの名無しさん:2013/09/08(日) 23:55:43.90
>>46
うーん、、、bashとかは除くとして
Rubyのmethod_missingのオーバライドと、あとJavaScriptにもProxyあるよね
あとはそんなに深く触ってないけどJavaとかでも聞いたことあるし
50デフォルトの名無しさん:2013/09/08(日) 23:57:54.36
method_missingのオーバライド程度がプロキシと呼べるの??
51デフォルトの名無しさん:2013/09/09(月) 00:00:15.94
この話の結論は見えてる
「作った人がそう読んだらそう」ってことだろ
52デフォルトの名無しさん:2013/09/09(月) 00:06:08.17
うーん……
53デフォルトの名無しさん:2013/09/09(月) 00:07:12.86
演算子オーバーロードの有る無しとかはどうよ?
54デフォルトの名無しさん:2013/09/09(月) 00:08:59.42
C++がアップを始めました
55デフォルトの名無しさん:2013/09/09(月) 00:11:42.44
関数のソースコード or バイトコードを取得して
実行時に書き換えられるかどうか
56デフォルトの名無しさん:2013/09/09(月) 00:12:40.94
演算子オーバーロードとValue Proxyってどっちがどんなケースで合ってるんだろう?
後者のほうがオブジェクト指向っぽいと思うんだけど。
57デフォルトの名無しさん:2013/09/09(月) 00:18:41.99
Value Proxy?
58デフォルトの名無しさん:2013/09/09(月) 00:19:10.42
>>55
アセンブラでも実行時にコード書き換えできるよなw
59デフォルトの名無しさん:2013/09/09(月) 00:19:15.24
>>55
関数の上書きとevalができればたいていの言語でできるんじゃない?
60デフォルトの名無しさん:2013/09/09(月) 00:22:03.05
ライブラリを動的にコンパイルして
動的に読み込むのは
実行時に書き換えてるというのかな?
61デフォルトの名無しさん:2013/09/09(月) 00:22:27.27
レキシカルスコープとダイナミックスコープの両方が使える
62デフォルトの名無しさん:2013/09/09(月) 00:23:23.79
63デフォルトの名無しさん:2013/09/09(月) 00:36:00.25
>>61
それは・・・なんかメリットあるの?
64デフォルトの名無しさん:2013/09/09(月) 00:37:17.53
頭の体操になる
65デフォルトの名無しさん:2013/09/09(月) 00:40:32.82
スタックフレームを読み書きできる
ダイナミックスコープもこの応用でいける
66デフォルトの名無しさん:2013/09/09(月) 00:45:08.28
スコープを直接触れる言語ってある?
67デフォルトの名無しさん:2013/09/09(月) 00:47:07.13
スコープを直接触る、ってのが良く分からんが
グローバル変数をローカル変数に無理矢理書き換えたりとか?
68デフォルトの名無しさん:2013/09/09(月) 00:54:04.31
ギミックとしてはできれば面白いだろうけど、黒魔術にしかならないと思う
69デフォルトの名無しさん:2013/09/09(月) 01:00:12.92
1つ上のスコープの変数を
__scope__.__scope__.xみたいに参照できたらいいなあと思うことがある。
スコープチェーンを触りたい。
70デフォルトの名無しさん:2013/09/09(月) 01:04:29.12
プロトタイプチェーンの
__proto__.__proto__
みたいな感じか
71デフォルトの名無しさん:2013/09/09(月) 01:57:57.29
プロトタイプチェーンをちゃんと理解出来てるのは
JSerでも1割くらいだと思う
72デフォルトの名無しさん:2013/09/09(月) 02:56:26.44
そうでなきゃお前が困るもんなw
73デフォルトの名無しさん:2013/09/09(月) 05:34:48.69
func.prototypeとプロトタイプの関係性は大抵の土方には説明困難だろう
というか同じものだと思ってる人も多いと思うわ
74デフォルトの名無しさん:2013/09/09(月) 06:59:07.49
そんな奴いねえよw
75デフォルトの名無しさん:2013/09/09(月) 08:53:01.94
JSに出来ない事ばっかり並んでてワロタw
76デフォルトの名無しさん:2013/09/09(月) 13:19:07.47
JSのProxyはそこそこ協力だと思うけど
77デフォルトの名無しさん:2013/09/09(月) 14:49:53.10
せやろか?
78デフォルトの名無しさん:2013/09/09(月) 15:59:02.88
せやな。
79デフォルトの名無しさん:2013/09/09(月) 16:46:31.19
俺年金支払ってなくて電話無視してたら、おばさんが来てAndroid系のタブレットで個人情報、契約内容など見せにきたんだが、
PHPで作られていた
驚いたね
銀行とかこういうシステムって最低でもJavaで作られてるのかと思った
80デフォルトの名無しさん:2013/09/09(月) 17:07:22.61
これからはタブレットとか汎用的なマルチデバイスを端末として使っていく流れだろうから
形式としてはWebアプリで、なるべくクライアントサイドに処理を任せて、
サーバーサイドはデータの管理だけすればいいから、言語はなんでもいい、
むしろPHPみたいに作りやすいほうが妥当に違いないと思うよ。
81デフォルトの名無しさん:2013/09/09(月) 17:22:00.40
サーバーはクライアントを認証してDBと繋ぐだけだからな
82デフォルトの名無しさん:2013/09/09(月) 17:25:16.42
シェルスクリプトの代わりとして使うならどの言語がいいの
83デフォルトの名無しさん:2013/09/09(月) 17:30:56.01
WinならJScript、MacならAppleScriptしかなくね
84デフォルトの名無しさん:2013/09/09(月) 17:36:15.16
python
85デフォルトの名無しさん:2013/09/09(月) 17:58:25.94
ないない
86デフォルトの名無しさん:2013/09/09(月) 18:01:46.32
そう言えば.net環境のVBScriptってC#と大体同じだけど
このスレ的にはスクリプト言語に入るの?
87デフォルトの名無しさん:2013/09/09(月) 18:16:40.03
Python万歳!るびい死ねw
88デフォルトの名無しさん:2013/09/09(月) 19:29:21.96
Haskell最強
89デフォルトの名無しさん:2013/09/09(月) 21:51:42.97
>>83
つーても今のMacはbashが標準で入ってるから、Mac固有の部分が絡まなければシェルスクリプトそのものでいけるけどね
90デフォルトの名無しさん:2013/09/09(月) 22:18:41.27
ん?
だからbashの代わりってことだろ
91デフォルトの名無しさん:2013/09/10(火) 01:02:08.90
今のWindowsにはPowerShellとかいうおよそ一般向けではない
変態スクリプト言語が入ってるぞ
92デフォルトの名無しさん:2013/09/10(火) 01:05:56.73
あとJScriptとVBScriptという
スクリプト言語も入ってるな。
93デフォルトの名無しさん:2013/09/10(火) 01:18:28.32
MSってF#とかPowerShellとかたまによく分からんことするよな
C#の魔改造もそうだが言語に関しては変なこだわりがあるよな
94デフォルトの名無しさん:2013/09/10(火) 01:40:16.12
>>91
いや電卓として使うとめっちゃ便利やねん
exprとか爆発してください
95デフォルトの名無しさん:2013/09/10(火) 01:42:42.46
元祖はJ++
96デフォルトの名無しさん:2013/09/10(火) 01:44:27.72
そもそもVBが・・・
97デフォルトの名無しさん:2013/09/10(火) 01:49:30.17
良い意味で、馬鹿でも使える言語って何がオススメですか?
まったく才能のカケラも無い人間でも
短時間教え込めば使えるようになる言語が知りたいです!
98デフォルトの名無しさん:2013/09/10(火) 01:57:34.69
python
99デフォルトの名無しさん:2013/09/10(火) 01:58:36.46
>>97
使えるってどの程度を指して言ってんの?
どんなに簡単な言語だろうと、馬鹿に使わせてる限り意味のあることはできないように思うけど。
100デフォルトの名無しさん:2013/09/10(火) 01:58:44.25
馬鹿にはるび
101デフォルトの名無しさん:2013/09/10(火) 02:02:31.79
JAVAだよ
土方でも使いこなせられるように作られた言語(公式)
102デフォルトの名無しさん:2013/09/10(火) 02:11:43.52
少なくともHaskellは違うな
トップクラスのJSプログラマ様がGHCをハックする必要があると
勘違いした挙げ句に挫折した言語だからね
103デフォルトの名無しさん:2013/09/10(火) 08:51:01.13
>>99
MVCでいうところのM以外のところは
馬鹿でも時間かければ作れると思うんですよ!
デザイナーは別途必要ですけど!
104デフォルトの名無しさん:2013/09/10(火) 09:13:00.29
今のWindows系のプロダクトはPowerShellが標準になってる
バージョンアップも頻繁でWindows 8でもメジャーバージョンアップしたけど、8.1でもさらにメジャーバージョンアップしてる
8.1ではWin+xで出るメニューがコマンドプロンプトからPowerShellに差し替えられてる
105デフォルトの名無しさん:2013/09/10(火) 09:16:48.19
それにUNIXのシェルに慣れてれば、コマンドプロンプトよりPowerShellの方が理解が早い
PowerShellはawkとかUNIXのシェル環境を強く意識して作ってある
106デフォルトの名無しさん:2013/09/10(火) 09:33:58.89
素直にbash入れとけって言いたい > win
107デフォルトの名無しさん:2013/09/10(火) 09:55:41.46
>>103
そういうことなの?プログラミングするんじゃなくて、ある程度定型化されてるコードを決まりに従って書ければいいってこと?
それだったらその辺のメジャーな言語ならどれ使ったって大して変わんないんじゃね
108デフォルトの名無しさん:2013/09/10(火) 10:09:09.41
>>106
どのbashがおすすめですか?
109デフォルトの名無しさん:2013/09/10(火) 10:39:32.77
>>108
種類あるの?
110デフォルトの名無しさん:2013/09/10(火) 11:53:06.00
PowerShellの全コマンドの詳細な解説があるサイトってあるの?
111デフォルトの名無しさん:2013/09/10(火) 12:40:44.43
--key=valだっけ、違うな、-key=valだっけ、しまった、-k valだった、みたいなアホらしさ
自分が苦労して覚えたバッドノウハウでどや顔したいからって、若者に無駄な努力を強いるワタミの会長的老害リナクサー
112デフォルトの名無しさん:2013/09/10(火) 12:45:01.16
素直なヤツはWindowsならPowerShell、Unixならbashを使う

Windowsにbash入れたってシェル機能を果たせないただのオモチャですよ
OSを制御したいならOSの用意したシェルを使わないとね
113デフォルトの名無しさん:2013/09/10(火) 12:44:59.63
正論
114デフォルトの名無しさん:2013/09/10(火) 12:50:07.13
>>110
MSDN見ればいい
ただ構文でなくコマンドの解説は
Helpも引数補完もあるのであまり見る機会はない
115デフォルトの名無しさん:2013/09/10(火) 13:26:37.88
PowerShellはmanからして高機能
116デフォルトの名無しさん:2013/09/10(火) 13:30:16.99
OSが用意したシェルw
117デフォルトの名無しさん:2013/09/10(火) 13:56:59.07
>>111
機能のカテゴリとか意味別でオプション統一したラッパーってないのかな。なんでもラップするのはよくないと思いつつあれば欲しい
118デフォルトの名無しさん:2013/09/10(火) 15:15:32.99
書き込み不可なはずのプロパティに、
何度か書き込みをかけたり、その作業をする関数を何度か呼ぶと、
書き込みができてしまい、困惑しています
これはブラウザのバグなのでしょうか?
Chromeです

Object.defineProperty(Object.prototype,'0',{set:function (v){this.first_value=v}});

function test1(){
var a=[];
a[0]=123;
return a[0];
}

function test2(){
var a=[];
for(var i=0;i<100;i++)a[0]=123;
return a[0];
}

test1() //undefined
test1() //123
test1() //123

test2() //123
119デフォルトの名無しさん:2013/09/10(火) 15:16:37.45
すみません、
投稿するスレを間違えました
120デフォルトの名無しさん:2013/09/10(火) 16:10:39.73
>>116
Un*xがttyや低レベルのシステムコールしか用意しなかったから乱立してるだけやん。
121デフォルトの名無しさん:2013/09/10(火) 17:27:35.98
何もしなかったから乱立した
「何もしてないのに壊れた」みたいな現象って本当にあるんだな
122デフォルトの名無しさん:2013/09/10(火) 19:18:19.12
能力が低い連中のunix嫌いは異常
123デフォルトの名無しさん:2013/09/10(火) 19:38:29.06
能力が低い連中のMac好きは異常
124デフォルトの名無しさん:2013/09/10(火) 20:29:12.43
各言語の内部文字コード表現は何?
UTF-8?、16?、32?
何で最近出来た言語でもUTF-32にしないんだろう?
今のCPU的には32bitの方が少し扱いやすいはずなのに
メモリの問題かな?
125デフォルトの名無しさん:2013/09/10(火) 20:56:08.16
キーボード的には8bitが扱いやすい
というか8bitでも多すぎ
126デフォルトの名無しさん:2013/09/10(火) 21:09:50.25
↑誰か翻訳頼む
127前々スレ367:2013/09/10(火) 21:50:52.14
前スレのお題のRuby版#749(753)について更新
 http://play.island.ac/codepaste/code?id=1557
変更の目的については、単に「お題」へ応えるだけなら前スレ#749が最適だと思うが、
ストリーム指向プログラミングに向け、再利用可能な汎用的な操作を以下のメソッドとして分離した

Ruby組込みクラスへ以下の汎用メソッドを追加:
・Enumerator::Lazy#transduce(init) { |acc, x| ... }
 ・Enumerable#reduce の遅延バージョンであり、入力ストリームから出力ストリームを再構成する
 ・詳細については、前スレ#518を参照
・Enumuerator#abs(&block)
 ・下位レベルのストリーム計算式をストリーム演算子へ抽象化(=abstract)する
 ・使い方は、stream_procucer.abs { |e| e.op1.op2.op3 .... }.stream_consumer 、あるいは演算子が
  メソッドとして定義されていれば stream_procucer.abs(&method(:composite_op)).stream_consumer
・Module._(sym)
 ・Module.method(sym)の別名であり、頻繁に使うので短縮形を用意した
128デフォルトの名無しさん:2013/09/10(火) 22:14:27.88
他の言語もJSのWorkerみたいにスレッド間のオブジェクトの参照譲渡ってできるの?
129デフォルトの名無しさん:2013/09/10(火) 22:30:38.75
できんよ
皆ポンコツ言語だからね
130デフォルトの名無しさん:2013/09/10(火) 22:37:08.50
(プロセスとは違って)スレッドはメモリ空間を共有するから、
スレッド間でオブジェクトの参照渡しができるのは当たり前
ただし、共有されたオブジェクトの排他制御はプログラマの責任
131前々スレ367:2013/09/10(火) 22:51:14.38
現状のRuby2.0でストリーム指向プログラミングに必要なメソッドが不足しているのは
前スレ#518で述べたんだが、>>127以外の少し複雑なメソッドの定義追加がうまくいかない....
たとえば、入力ストリームを条件の真偽別に2本の出力ストリームへ「分流」させる
Enumerable::Lazy#partition(&block) というメソッド

 even_strm, odd_strm = (1..Float::INFINITY).lazy.partition { |e| e.even? }
 even_strm.take(5).force # => [2, 4, 6, 8, 10]
 odd_strm.take(5).force # => [1, 3, 5, 7, 9]

今のRuby2.0でも同じメソッド partition は定義されているが、遅延評価ではない親クラスから
継承しているだけなので、上記コードではインタプリタが無限ループに陥ってしまう!!.... これはバグ?

他の言語なら定義できるのかな?
132デフォルトの名無しさん:2013/09/10(火) 22:57:20.33
>>130
JSでは排他処理までやってくれるんだけど?
プログラマの責任とかそんな危険な言語使えねえだろ
133デフォルトの名無しさん:2013/09/10(火) 23:02:05.42
ストリームを絡めるとストリームの仕様に大きく作用されるから、
もっと汎用的でシンプルな話として、文字列を重複のない単語配列にするのにしようよ。
134デフォルトの名無しさん:2013/09/10(火) 23:05:42.18
ストリームはJSが苦手としてるから、別のお題にしようぜ
またJSだけが実装できるまでにウダウダと500レスくらい使うハメになるし
135デフォルトの名無しさん:2013/09/10(火) 23:07:38.76
>>134
前スレでいくつか頑張って書いたんだけど、そんなにダメだった?
136デフォルトの名無しさん:2013/09/10(火) 23:13:47.22
>>134
賛成
137デフォルトの名無しさん:2013/09/10(火) 23:16:03.94
ってか前のお題はもう特にこれ以上話すこともないだろ
138デフォルトの名無しさん:2013/09/10(火) 23:19:34.88
>>132
JSのWeb Workerって分散メモリ型だろ?
共有してないんだから排他処理を書かないのは当たり前じゃない?
139デフォルトの名無しさん:2013/09/10(火) 23:23:57.36
譲渡っていうのがポイントでは?
値コピーでも参照コピーではない。
140デフォルトの名無しさん:2013/09/10(火) 23:27:30.25
メモリ的に分離されたプロセスにデータ送るんだから
値コピーに決まってると思うんだけど
当たり前すぎて、何がポイントか分からないよ
141デフォルトの名無しさん:2013/09/10(火) 23:33:33.10
>>131
Haskell

import Data.List

main = do
  let (xs, ys) = partition even [1..]
  print $ take 5 xs
  print $ take 5 ys
142デフォルトの名無しさん:2013/09/10(火) 23:35:47.27
>>138
>JSのWeb Workerって分散メモリ型だろ?

JSでもスレッドだから共有メモリだよ
ただし、スレッド間はメッセージをハンドラを介して転送するけど、
このメッセージが値コピーで渡される
だから、「メッセージ通信だけで並行処理を実装する」場合に限って
排他制御みたいなややこしい話から解放されるって話

メモリ空間そのものは共有されるから、スレッド間で(メッセージ以外の)
共有オブジェクトへのアクセスが競合すると、結果は保証されない
143デフォルトの名無しさん:2013/09/10(火) 23:39:28.73
JSのWorkerではArrayBuffer系とかCanvasとか、
一部のオブジェクトの「所有権の委譲」ができる。

要はメモリの参照が渡されて元々持ってた側ではnullかなんかになるんじゃない?
http://dev.w3.org/html5/workers/#communicating-with-a-dedicated-worker
144デフォルトの名無しさん:2013/09/10(火) 23:40:16.99
>>140,142
無知乙
145デフォルトの名無しさん:2013/09/10(火) 23:40:49.57
>>143
その通り
146デフォルトの名無しさん:2013/09/10(火) 23:44:32.33
>>131
Python3


from itertools import *

def partition(f, xs):
    ys, zs = tee(xs)
    return filterfalse(f, ys), filter(f, zs)
147デフォルトの名無しさん:2013/09/10(火) 23:47:10.25
あるオブジェクト自体を置き換えることって各言語できるの?

オブジェクトの参照を直接書き換える方法と、
オブジェクトを一旦空まで解体して、新しいのとMixする方法とがあると思うけど。
148デフォルトの名無しさん:2013/09/10(火) 23:50:54.10
この手のメソッドがない言語はクソ言語。
さて、JavaScriptはどうだったっけなぁ〜
149デフォルトの名無しさん:2013/09/10(火) 23:53:41.11
>>143
なるほど勉強になった。ありがとう
でも参照できるのが一つのスレッドだけなら
排他処理の一種という気がする
150デフォルトの名無しさん:2013/09/10(火) 23:56:23.45
もちろんそうだよ。
151デフォルトの名無しさん:2013/09/11(水) 00:05:13.19
なら排他処理を自分で書いてるじゃん
>>132は何だったのか
152デフォルトの名無しさん:2013/09/11(水) 00:08:35.49
このオブジェクトを委譲してねってリストを一緒に渡すだけなのに、自分で書いてる……?
うーん、、、日本語って難しい
153デフォルトの名無しさん:2013/09/11(水) 00:12:53.01
「自分で書いてる」っていうのは排他処理をやってくれないけど自分で仕組みを実装するってことでしょ?
154デフォルトの名無しさん:2013/09/11(水) 00:15:24.32
並列計算やってる人達でも
排他処理の仕組みを実装してるのは一部だと思うよ
普通は仕組みを使うだけ。どの言語でも
155デフォルトの名無しさん:2013/09/11(水) 00:18:53.17
>>151は多分、オブジェクトに排他処理をかける指定してから、
データを渡す指定をするみたいに、別々な行為として実装されてると思ってるのでは。

Workerの場合はオブジェクトの所有権委譲手続きみたいのがあるわけではなく、
スレッド間ポスト機能の一部として内蔵されてるから、感じ方の問題じゃない?
156デフォルトの名無しさん:2013/09/11(水) 00:22:13.69
感じ方の問題とか
そんな危険な言語使えるわけねえだろ
157前々スレ367:2013/09/11(水) 00:23:32.36
>>141
コードありがと
たぶんすべてが遅延評価されるHaskellならできそうな気がしたけど、やはり可能だったか....

Rubyに限らず、Python/Smalltalk/JSを含むジェネレータ系を応用してストリームを実現する
言語の限界のような気がしてきた(あきらめるのはまだ早いかな?)

>>146
Rubyに移植してみたら、動くことは確認できた

class Enumerator::Lazy
  def partition(&block)
    [
      self.dup.select { |x| yield(x) },
      self.dup.reject { |x| yield(x) }
    ]
  end
end

ただし、このジェネレータの複製を作る手法は、>>141のHaskellと比較すると、
条件判定ループが2度必要だから、効率が悪いね

2つのジェネレータをコルーチンとして交互に呼びあうループが書ければ1度で済むと思うんだけど、
コードで上手く表現できない.....
158デフォルトの名無しさん:2013/09/11(水) 00:25:39.18
>>156
危険?むしろ凄く安全な方法だと思うけどな。
159デフォルトの名無しさん:2013/09/11(水) 00:28:03.36
複数のスレッドが同じデータに同時にアクセスしようとしたら、
一方はぬるぽになっちゃうの?
160デフォルトの名無しさん:2013/09/11(水) 00:58:22.69
JSのWorkerのtransferはちょっと特殊で、オブジェクトをそのまま移すわけじゃない。
Bufferっぽいオブジェクトの中身の内部的なバッファの部分「だけ」の参照を移す。
普通のプロパティ(Bufferに付けることはほぼ無いが)は対象外。

具体的にはプログラムから見ると、例えば100byteのArrayBufferをtransferしたら、
元のは0byteになって、先に100byteの「新しい」ArrayBufferができるように見える。
161デフォルトの名無しさん:2013/09/11(水) 01:03:11.47
>>157


def partition(f, xs):
    xs, queue1, queue2 = iter(xs), [], []
    def iterate():
        try:
            x = next(xs)
            (queue1 if f(x) else queue2).append(x)
            return True
        except:
            return False
    def gen(queue):
        while True:
            if len(queue) > 0:
                yield queue.pop(0)
            elif not iterate():
                break
    return gen(queue1), gen(queue2)
162デフォルトの名無しさん:2013/09/11(水) 01:11:52.52
>>160
同時にアクセスしたら、一方は「あれれ〜?データが空だぞ」ってなるんですね
163デフォルトの名無しさん:2013/09/11(水) 01:31:26.65
>>162
根本的にバイナリデータの受け渡しを高速にするためのものだから。
メインでDOMから受け取ったファイルをWorkerで処理したいからWorkerに渡す、
処理が終わったらWorkerから戻す、みたいな使い方。

この時Workerは処理が終わってデータを返したらkillされるかはまあ分かんないけど、
何にもすることが無いから触るようなことありえないし、
さっき書いたようにバッファの部分以外は無事だから、
スレッドで処理してる時にメインでのファイル情報なんかの読み取りに問題はない。

根本的に排他処理じゃないと勘違いして使ってない限りは大丈夫だと思うよ。
マルチスレッドとはいうけどWorkerではDOMが触れなかったり制約があるし、
明確に司令塔-作業員の関係になりやすいからそういうことは起きない。

Workerから子Workerを起動してtransferを多用するような設計くらいになってきた時は
うっかりしてると危ないかもね。
164デフォルトの名無しさん:2013/09/11(水) 05:15:35.56
結局チェックは必要だな
165デフォルトの名無しさん:2013/09/11(水) 07:35:51.80
チェックいらないケースなら、譲渡なんてしないで
共有してても排他いらないもんな
166デフォルトの名無しさん:2013/09/11(水) 07:47:27.99
× オブジェクトの参照譲渡
○ Bufferっぽいオブジェクトの中身の参照を移す
これを言うために30レス使うのがJSクオリティなんだよな
167デフォルトの名無しさん:2013/09/11(水) 08:29:45.19
>>131ってJSお得意のコールバックでどう書くの?
168デフォルトの名無しさん:2013/09/11(水) 09:02:34.54
結局のところ退職エントリで叩かれない給与水準が確保できるかに尽きます。
ちなみにRubyプログラマの私は900万です。(発言小町風)
169デフォルトの名無しさん:2013/09/11(水) 09:07:01.63
>>167
そんなこともわからんのかw
170デフォルトの名無しさん:2013/09/11(水) 10:04:26.42
>>164-166
わからないふりをするのは楽しい?

>>167
特定の条件で分けるってどういうこと?
171デフォルトの名無しさん:2013/09/11(水) 10:31:15.75
本来連続のストリームを分けるっていう感覚が分からん
UTF8として解析して\nで区切ったのを条件判断対象の1ブロックとして
その文字列のUTF8バッファを条件によって各ストリームに流すってことか??
172デフォルトの名無しさん:2013/09/11(水) 10:49:40.82
>>171
そういうこと。
173デフォルトの名無しさん:2013/09/11(水) 11:02:10.50
>>170
それで特定のデータを複数のワーカーで使いまわすのはどうやるの?
Bufferの参照を複数場所で持てるなら、
セマフォなり何なりで使わないように制御しなきゃダメなんじゃないの?
174デフォルトの名無しさん:2013/09/11(水) 11:14:26.98
>>173
同じバッファ領域への参照は同時に1つしか持てない
もし巨大な1つのバッファをいくつかのWorkerで使いたかったら領域を分割して渡す
175デフォルトの名無しさん:2013/09/11(水) 11:21:28.98
言語のメタプログラミング機能をみる即興お題でこんなのどう?

「無名関数を無名のまま再帰して階乗を定義せよ」

もちろんYコンビネーター的なアプローチでも書けるけど、
JavaScriptみたいに、イントロスペクション機能を
ふつうに備えた言語ならもっとシンプルに書ける。
もしかしてRubyでもできるのかな? たぶん無理だと思うけど。w
176デフォルトの名無しさん:2013/09/11(水) 11:27:48.51
>>173元が>>128だから、
そもそもの話が同じデータをマルチスレッドで共有できるかじゃなくて、
スレッド間で巨大なデータを重いコピーをせずに渡せるのかって話だから。
177デフォルトの名無しさん:2013/09/11(水) 11:28:40.53
JSでも不動点コンビネータ必要じゃないの?
calleeって標準規格じゃないはずだし
178デフォルトの名無しさん:2013/09/11(水) 11:29:50.44
>>176
いやこっち側のレスの流れは
排他制御しなくていいって話が発端でしょ
179デフォルトの名無しさん:2013/09/11(水) 11:31:11.52
>>175
それメタプロなの?
単に記述が短くなるかどうかは大した問題じゃなくて、
構造が大きく変わるか、メタ処理を高度に抽象化できるかがポイントでは?
180デフォルトの名無しさん:2013/09/11(水) 11:32:53.49
>>178
???
その話はしなくていいってことが散々書かれて終わったはずじゃ?
181デフォルトの名無しさん:2013/09/11(水) 11:34:07.25
>>180
え?じゃあ>>173の解答はどういう風になるの?
182デフォルトの名無しさん:2013/09/11(水) 11:35:21.06
calleeはstrictモードでは使えない
argumentsもアロー関数では使えない
パフォーマンスのため
なるべく使いたくないし、使うのがステキだとは思えない
183デフォルトの名無しさん:2013/09/11(水) 11:37:36.37
>>181
>>160,>>163,>>174でまだ何か不満?
184デフォルトの名無しさん:2013/09/11(水) 11:42:57.88
>>183
そりゃまあ不満だよね
内容見る限り並列じゃなくて1スレッド(タスク)前提で
排他制御を想定していないみたいだし
だから想定した時にはどうなのって話
185デフォルトの名無しさん:2013/09/11(水) 11:54:23.16
あーわかったわかった

>>184はプログラムのレベルで、
結局スレッドを意識したコードを書かないといないじゃない
そこら辺全て内部的に責任負ってくれるわけじゃないと言ってるわけだ?

配列のパラレル処理みたいなのと比べたら
ずっと明示的で、意識的だと言いたいわけだよね?

そうじゃなくて、そもそも同時にアクセス出来ないから
「データから見て」排他的だねって言ってるわけなのよ

データが同時に触れられるおそれが無いということ
だからそもそも、同時にアクセスしたらみたいなのは無いわけ
186デフォルトの名無しさん:2013/09/11(水) 11:57:05.57
>>175
えっ。arguments.callee 使っちゃ駄目なの?
function(n){ if(n==1){ return 1; } else { return n*arguments.callee(n-1); } }(10)
187デフォルトの名無しさん:2013/09/11(水) 11:59:41.15
>>185
>そうじゃなくて、そもそも同時にアクセス出来ないから
>「データから見て」排他的だねって言ってるわけなのよ
ああ…
うん理解した…
188デフォルトの名無しさん:2013/09/11(水) 12:06:05.40
「データを移動できるか」という話だからデータが中心で話してきたのよ
データからみて同時にアクセス出来ないように処理をしてくれた上で移動してくれるなんて
効率もいいし安全で素晴らしいねという話

自由なプログラム書く側としては不十分とか制約だっていう指摘はまた違う話なのよね
189デフォルトの名無しさん:2013/09/11(水) 12:08:21.76
callee無しで書いてみた

Function.prototype.callSelf =
function(){ return this.apply(this,[this].concat([].slice.call(arguments))); };

(function fac(f,i,n){
return (n = (n==null?1:n)), i > 0 ? f(f,i-1,n*i) : n;
}).callSelf(4);
190デフォルトの名無しさん:2013/09/11(水) 12:08:51.91
arguments.calleeはもう、ちょっとダメだな……
普通に関数名付けて再帰すればエンジンでgotoに最適化してくれるから大丈夫よ
191デフォルトの名無しさん:2013/09/11(水) 12:12:37.24
>>175
Squeak Smalltalk

[:n | n < 2 ifTrue: [n] ifFalse: [n * (thisContext closure value: n-1)]] value: 10 "=> 3628800 "
192デフォルトの名無しさん:2013/09/11(水) 12:14:55.99
普通に関数作ればいいのに
Function.prototypeを無遠慮に拡張する神経に驚く
193デフォルトの名無しさん:2013/09/11(水) 12:17:07.26
>>192
だってそれをやっちゃうとYコンビネータと変わらないじゃない
194デフォルトの名無しさん:2013/09/11(水) 12:23:28.98
fac = n => n > 1 ? n * fac(n-1) : 1

でいいんじゃないの?
ここでは変数facに無名関数を代入しているだけで
関数自体の名前はちゃんと無名

fac.name //""
195デフォルトの名無しさん:2013/09/11(水) 12:25:38.10
>>192

(function(f){
return function(x){ return f(f,x); };
})(function(f,i,n){
return (n = (n==null?1:n)), i > 0 ? f(f,i-1,n*i) : n;
})( 10 );
196デフォルトの名無しさん:2013/09/11(水) 12:28:57.41
無名ですら無い
197デフォルトの名無しさん:2013/09/11(水) 12:30:32.06
>>195それ、無名関数の変数への代入を引数に閉じ込めているだけで
>>194の屁理屈と何も変わらないよ
198デフォルトの名無しさん:2013/09/11(水) 12:32:40.90
せやな、thisFunctionみたいのが無い言語はそもそもダメ
199デフォルトの名無しさん:2013/09/11(水) 12:33:25.77
>>197
結局否定するのかよw
200デフォルトの名無しさん:2013/09/11(水) 12:34:32.06
>>169
ちょっとコード貼ってみて貰えるか?
201デフォルトの名無しさん:2013/09/11(水) 12:41:07.33
>>200
>>171ってことでいいんなら自分が夜書くよ
202デフォルトの名無しさん:2013/09/11(水) 12:42:47.10
自分のお気に入りの言語で書けないお題だと、
けっきょく屁理屈こねくりまわすのはどの言語でも同じだな
203デフォルトの名無しさん:2013/09/11(水) 12:51:02.95
せやな
そもそも再帰専用の書き方が言語機能にないとアウト
204デフォルトの名無しさん:2013/09/11(水) 12:53:46.37
というか自分が気に入った書き方じゃないと許せない奴が多いだけだな
Ruby厨とか
205デフォルトの名無しさん:2013/09/11(水) 12:54:29.13
そこら辺でやめとけ
206デフォルトの名無しさん:2013/09/11(水) 13:00:53.75
案外難しいお題だったんだな
207デフォルトの名無しさん:2013/09/11(水) 13:23:29.02
>>179
> それメタプロなの?

arguments.callee 相当がない言語で
Yコンビネーター的なアプローチを取らない場合、
メタプロ勝負になる
208デフォルトの名無しさん:2013/09/11(水) 13:30:43.86
ええー
メタプログラミングならevalだけでいいじゃん
209デフォルトの名無しさん:2013/09/11(水) 13:35:31.45
>>207
eval == メタプロ、メタプロ == eval ってクラスタがあってだな
210デフォルトの名無しさん:2013/09/11(水) 17:27:10.94
今実行中の関数のコンテキストをどうのこうのするって
それもうメタプロ超えて独自言語制作の域に入ってるんだけど
今でいうメタプロってアクセッサーの延長というか
もっとオブジェクト的なものでしょ
211デフォルトの名無しさん:2013/09/11(水) 17:45:19.64
>>157 こういうのは外部イテレーターじゃないと書きにくい処理だね
>>161 をRubyに移植

class Enumerator
 def partition()
  xs, queue1, queue2 = self.each, [], []
  gen = ->(queue){
   Enumerator.new{|y|
    loop{
     if queue.empty?
      x = xs.next
      (yield(x) ? queue1 : queue2).push x
     else
      y.yield queue.shift
     end
    }}}
  [gen.call(queue1),gen.call(queue2)]
 end
end
class Enumerator::Lazy
 def partition() super.map(&:lazy) end
end

xs, ys = 1.upto(Float::INFINITY).lazy.partition(&:even?)
puts xs.take(50000).force.last(5)
puts ys.take(50000).force.last(5)
212デフォルトの名無しさん:2013/09/11(水) 17:50:43.65
lazy云々はもうおなかいっぱい
213デフォルトの名無しさん:2013/09/11(水) 17:58:47.36
実行中の関数のコンテキストも第一級オブジェクトかという意味で
これもオブジェクト的だしメタプロの域だと思うが、
たとえばここらへんが中途半端な実装のRubyとかだと違うのか?
214デフォルトの名無しさん:2013/09/11(水) 18:19:05.20
JavaScriptもSmalltalkも、argumentsやthisContextを封じられたら
ああも抽象化して書くことは恐らくできないだろうから、結局>>198ということだろうな。
これは通常の言語が実は参加できない悪意あるお題ということでFA?
215デフォルトの名無しさん:2013/09/11(水) 18:34:01.41
ていうかYコンビネータでいいじゃん
あれこそ数学の世界で生まれたメタプロだぜ
216デフォルトの名無しさん:2013/09/11(水) 19:28:55.40
数学みたいに、プリミティブ(公理)は必要最小限なだけあって、
後はそれらを自由に組み合わせられる基盤さえあれば良い、
というスタイルはプログラミングには無理。
217デフォルトの名無しさん:2013/09/11(水) 19:34:13.70
GNU Smalltalk
thisContext はあるけど
Squeak Smalltalk ほど器用じゃないので素直にYコンビネーターで

(([:f | [:g | f value: [:arg | (g value: g) value: arg]]
  value: [:g | f value: [:arg | (g value: g) value: arg]]]
 value: [:f | [:n | n < 2 ifTrue: [1] ifFalse: [n * (f value: n-1)]]]
) value: 10) printNl

http://ideone.com/qxahXF
218デフォルトの名無しさん:2013/09/11(水) 19:59:46.08
HaskellでYコンビネータ

-- yを定義した場合

y f = f (y f)
main = print $ y (\f n -> if n < 2 then 1 else n * f (n-1)) 10


-- yを定義しない場合

import Unsafe.Coerce
main = print $ (\f -> (\g -> f (unsafeCoerce g g)) (\g -> f (unsafeCoerce g g))) 
  (\f n -> if n < 2 then 1 else n * f (n-1)) 10
219デフォルトの名無しさん:2013/09/11(水) 20:03:18.87
Python
Yは公理じゃないから覚えなくて良いんだろ?

print((lambda f: f(f, 10)) (lambda f, n: 1 if n < 2 else n * f(f, n-1)))
220201:2013/09/11(水) 20:10:23.64
>>200
書いてみたよ
http://ideone.com/EasXTL
221デフォルトの名無しさん:2013/09/11(水) 20:30:15.83
>>220
>>131とチガクね?
222デフォルトの名無しさん:2013/09/11(水) 20:57:04.31
; Common Lisp
; きっとSchemeのほうが読みやすい
(defun y (f)
 (funcall (lambda (g)
       (funcall f (lambda (arg)
             (funcall (funcall g g) arg))))
      (lambda (g)
       (funcall f (lambda (arg)
             (funcall (funcall g g) arg))))))

(defun fact (n)
 (funcall (y (lambda (f)
        (lambda (cons)
         (destructuring-bind (i . j) cons
          (if (zerop j)
            i
            (funcall f (cons (* i j) (1- j))))))))
      (cons 1 n)))
223201:2013/09/11(水) 20:59:49.67
>>221
例えばって書いてあったからそこは2本じゃつまんないから任意の数OKにしてみた

けちな実装思考で書いたら、例えばどちらにも出力したくない場合は?
とか汎用的には?とか注文付けられて行った時、変更が難しかったり
ガラクタになってしまうんじゃないかと思ったから、
そこら辺は最初から融通が効くように、自分の好きなように作らせてもらった

一応マルチインプットにしろみたいな要求でも
簡単な追加でできるんじゃないかと踏んでる

あと、Nodeのストリーム実装者向けAPIも少し使って、
結果他人が使うAPIを作る感じで書く事になった

NodeのStreamワールドは平坦じゃなくて、
上下に厚いかなり深いクラス関係の抽象化された構造物だから
これは必然的にそうなるかなと思う
224デフォルトの名無しさん:2013/09/11(水) 21:17:16.01
>>223
入力が 1 2 3 4 5 6 7 8 9 10 のときに、
偶数奇数にpartitionで分けてから出力するとき、
ちゃんと>>131みたいに書いたら
2 4 6 8 10
1 3 5 7 9
の順序で出力される?
225デフォルトの名無しさん:2013/09/11(水) 21:23:54.11
>>224
今は改行区切りで判断してるけど
原理的に各ストリームの順番は守られるよ
だって入力が1本しか無いんだから、各トークンの並びがズレるわけがないし
各トークンの並びがずれないのなら、それを上から順番に取り出して
スイッチにかけてるだけだから、出力もズレ用がない
226デフォルトの名無しさん:2013/09/11(水) 21:27:30.32
>>225
各ストリームの順序の話じゃなくて、
evenとoddって二つのストリームを用意した後、
まずevenから5個要素取り出して出力して、
その後oddから5個要素取り出して出力できるのかなって
227デフォルトの名無しさん:2013/09/11(水) 21:50:34.64
あー、うーんと、自分はストリームは流れていくものと考えてたから結構ビックリした
そうか、そういう使い方がしたいんだよね
本当にストリームのままで>>131っぽく書きたかったら
objectModeを使うことになるんだろうけど、今知識0だからまた勉強してくる
そういう話なら全面的に書き直したほうがいいわこれ
228デフォルトの名無しさん:2013/09/11(水) 22:24:39.76
Haskellでも、evenだけがリストの尻尾を次々と評価して
oddがリストの先頭を参照したまま放置すると、いずれメモリが足りなくなると思う
229デフォルトの名無しさん:2013/09/11(水) 23:32:36.72
>>226
一応追加だけでなんとか流れはできた
あと>>131に近づけるのにはメソッドとか追加したらいいんだろうけど

面倒だし、どんな動きが期待されてるのか細かくはわかってないから
とりあえず配列のメソッドに頼ってくださいということにした

http://ideone.com/7bjAhw
230うゆ:2013/09/12(木) 02:53:49.08
>>211
     if queue.empty?
      x = xs.next
      (yield(x) ? queue1 : queue2).push x
     else
      y.yield queue.shift
     end
    redo
231デフォルトの名無しさん:2013/09/12(木) 05:11:13.96
>>210
メタプログラミングってプログラミングによるプログラミング全般のことだぞ
なんで勝手に枠作ってるんだ?
232デフォルトの名無しさん:2013/09/12(木) 07:26:13.31
RubyはC言語によるプログラミング。
C言語はアセンブラによるプログラミング。
アセンブラは二進数によるプログラミング。

枠は必要だろwww
マジレスしちゃった^^;
233デフォルトの名無しさん:2013/09/12(木) 08:32:16.99
枠作らないとLispマクロが最強だから
他はプリプロセッサにm4とか使うの?ウンコすぎるんだけど
234デフォルトの名無しさん:2013/09/12(木) 08:55:14.27
>>232
ブートストラップ時はともかく、CはCで、アセンブラはアセンブラで
組むだろ普通(セルフホスティング)。
RubyにおいてもCとRubyの境界は曖昧で、
たまたまMatzやささだの実装におけるC依存が高いだけ。
実装者の力量しだいでかなりの部分まで(実用的な速度を維持しつつ)
Rubyで組むことができる。
235デフォルトの名無しさん:2013/09/12(木) 09:03:53.85
ちなみにLispもLispで、SmalltalkもSmalltalkで組まれているけれど、
これらの言語でのメタプログラミングが通常の言語で自己記述した場合より
ずっと強力になるのは、LispやSmalltalkが真に動的がゆえに
自身を記述しているレイヤーに容易に降りることができるから。

ただしコンテキストが第一級オブジェクトであるかどうかは、それ以前の話。
236デフォルトの名無しさん:2013/09/12(木) 11:59:48.52
枠作らないとマクロ大大会になりかねない
237デフォルトの名無しさん:2013/09/12(木) 12:13:50.92
メタプロに枠なんてないがこのスレ的には必要だね
238デフォルトの名無しさん:2013/09/12(木) 12:21:13.69
マクロってあって欲しいものなの?
それとも無くてもいいものなの?
239デフォルトの名無しさん:2013/09/12(木) 12:44:04.21
有能な部下が自分に刃向かう時もっとも恐ろしい敵となる
使いこなせない奴にとっては無い方がいい
240デフォルトの名無しさん:2013/09/12(木) 12:53:58.53
実際スレタイのようなポピュラーな言語が
ポピュラーな使われ方する時って
マクロ使えたらいいのにって事ある?
241デフォルトの名無しさん:2013/09/12(木) 13:09:19.45
>>240
並みのコーダーであろうとしてる限りは必要ない
242デフォルトの名無しさん:2013/09/12(木) 13:13:54.20
ダークコーダーになりたいのなら使うべし
243デフォルトの名無しさん:2013/09/12(木) 13:25:26.27
マクロが最強みたいに話されてきたけど、そうでも無いんじゃないかと思う
AST解析の方が万能で柔軟なのでは?
最近はそれほど厄介でもなくなってきたし
http://jser.info/post/59394147051/2013-08-26-js-yeoman-1-0-meta-weekly-power-assert-in
244デフォルトの名無しさん:2013/09/12(木) 14:00:52.64
マクロなんて遊びでもなきゃ苦々しく書くもんだろ
喜んでどうするんだよ
245デフォルトの名無しさん:2013/09/12(木) 15:10:07.02
それではお題です。

「二つの値(x,y)受け取ってその和(x+y)を返す関数 plus(x,y) のASTを生成し、
それに手を加えることで積(x*y)を返す関数に変更し実行するコードを示せ」

plus(x,y) は、x.plus(y) など言語のパラダイムに合わせて自由に読み替えてよい。
246デフォルトの名無しさん:2013/09/12(木) 15:30:28.40
お断りします
247デフォルトの名無しさん:2013/09/12(木) 15:40:21.05
>>245
こういうことか?w

(set! plus '(lambda (x y) (+ x y)))
(set! (caaddr plus) '*)
(apply (eval plus (interaction-environment)) '(3 4)) ;;12
248デフォルトの名無しさん:2013/09/12(木) 16:19:41.61
ASTを直接弄ってるんじゃないけど
間接的に弄ってることと等価なのでこれでいいんじゃないですかねぇ

add = (x, y) => x + y
multi = eval( add.toString().replace('+', '*') )

add(4, 6) //10
multi(4, 6) //24
249デフォルトの名無しさん:2013/09/12(木) 16:29:34.70
>>245
Squeak Smalltalk で

Number compile: 'plus: y ^self + y'.
3 plus: 4. "=> 7 "

| plusAST mulNode |
plusAST := (Number >> #plus:) methodNode.
mulNode := (ParseNode classPool at: #StdSelectors) at: #*.
plusAST block statements first expr selector: mulNode.
Number methodDict at: #plus: put: plusAST generate.
3 plus: 4. "=> 12 "
250デフォルトの名無しさん:2013/09/12(木) 16:57:31.55
AST大大会もマクロ大大会と変わらん
251デフォルトの名無しさん:2013/09/12(木) 17:12:26.14
Javaは糞みたいな冗長性をIDEが自動生成するテンプレートで補う的な
文化かと思ってたが、AST transformation系もあるみたいだな
http://www.ibm.com/developerworks/jp/java/library/j-lombok/
252デフォルトの名無しさん:2013/09/12(木) 17:14:15.71
堅物の代名詞だったJAVAにもラムダ入ったしね
253デフォルトの名無しさん:2013/09/12(木) 17:23:27.09
アノテーション使ってメタプログラミングする事も多いな
アスペクト指向のようなの
254デフォルトの名無しさん:2013/09/12(木) 17:32:41.12
クラスの多重継承って各言語うまく出来るの?
255デフォルトの名無しさん:2013/09/12(木) 17:49:03.18
import ast

plus_src = """
def plus(x,y):
  return x+y
"""
plus_ast = ast.parse(plus_src, mode='single')
eval(compile(plus_ast, "<string>", 'single'))
plus(3,4) #==> 7
plus_ast.body[0].body[0].value.op = ast.parse('x*y', mode='single').body[0].value.op
eval(compile(plus_ast, "<string>", 'single'))
plus(3,4) #==> 12
256デフォルトの名無しさん:2013/09/12(木) 18:41:24.63
>>254
オブジェクトに継承先クラスを追加するというイメージをJSでやるとこんな感じ?

Object.prototype.inherit = function(...classes) {
classes.reduce( (o, c) => Object.mixin(o, c.prototype), this.__proto__)
}

obj.inherit(class1, class2, class3)
257デフォルトの名無しさん:2013/09/12(木) 18:51:01.29
あれだと汚染の可能性があるからこうか

Object.prototype.inherit = function(...classes) {
let proto = Object.mixin({}, this.__proto__)
this.__proto__ = classes.reduce((o, c) => Object.mixin(o, c.prototype), proto)
}

obj.inherit(class1, class2, class3)
258デフォルトの名無しさん:2013/09/12(木) 19:50:28.28
動的に継承元を変更できるのはスクリプト言語ならではなのかな?
259前々スレ367:2013/09/12(木) 20:27:36.04
>>175
>もしかしてRubyでもできるのかな? たぶん無理だと思うけど。w
>>214
>これは通常の言語が実は参加できない悪意あるお題ということでFA?

お馬鹿さん達だなあ....
Yコンビネータやらイントロスペクションやらの小難しい理屈を並べなくとも、
階乗の定義、つまり再帰的な順列を理解していれば、ずっとシンプルかつ分かりやすく書けるだろ
以下はRubyの例だけど、他の多くの言語へも移植できるはず
 [定義]
  lambda { |x| if x <= 1 then 1 else (1..x).inject { |acc, n| acc * n } end }
 [評価の例]
  (lambda { |x| if x <= 1 then 1 else (1..x).inject { |acc, n| acc * n } end }).call 5 # => 120
より短く書くなら、以下でも可:
  (-> x { x <= 1 ? 1 : (1..x).inject(&:*) })[5] # => 120


>>211
>>>157 こういうのは外部イテレーターじゃないと書きにくい処理だね

そのとおりで、これがRubyへ(後から)外部イテレータが導入された理由(の一つ)なんだろな....
まぁそれはともかく、こういった外部イテレータの用法は(自分には)思いつけなかった
ありがと >>161,211
260デフォルトの名無しさん:2013/09/12(木) 20:33:00.37
だからそれだとYコンビネータと同じだろ
コンパイル時にループにされる再帰関数専用の書き方がないとダメなんだって
261デフォルトの名無しさん:2013/09/12(木) 20:37:46.17
振る舞いを「関数の再帰」では無くせたらお題を完遂したと言えると思う。
そうでないのなら縛る意味も効果も無いのでは?
262デフォルトの名無しさん:2013/09/12(木) 20:40:11.49
最初からループで書けばいいじゃん
263デフォルトの名無しさん:2013/09/12(木) 21:06:38.85
せやな。
それが最良かもしれん。
264デフォルトの名無しさん:2013/09/12(木) 21:12:35.43
JavaScriptも末尾再帰にはいろいろ悩んでる
http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls
265デフォルトの名無しさん:2013/09/12(木) 21:24:32.52
>>259
> (lambda { |x| if x <= 1 then 1 else (1..x).inject { |acc, n| acc * n } end }).call 5

この式は式内のどこで再帰的にコールされているん?
266デフォルトの名無しさん:2013/09/12(木) 21:26:33.25
>>259
これだたのループだよね? お題は再帰呼び出しなんだが…
267デフォルトの名無しさん:2013/09/12(木) 21:29:12.61
>>265
お題も理解できずに馬鹿だなあって言ってるだけだよ
268デフォルトの名無しさん:2013/09/12(木) 21:38:31.51
再帰とは書いてあるが再帰呼び出しとは書いてないだろ
いい加減なこと言うなよ
269デフォルトの名無しさん:2013/09/12(木) 21:41:19.38
ただの関数の再帰の話ならYコンビネータで話が早いと思うんだけど
他の方法考える意義が思いつかない……
270デフォルトの名無しさん:2013/09/12(木) 21:42:51.71
無名関数を再帰→無名関数内でアキュームレータで再帰的な配列を作成

どこに無名である必要があるんだよ
少しは考えろや
271デフォルトの名無しさん:2013/09/12(木) 21:45:25.30
???
無名の意味は関数コールをするなってことだから
それでいいと思うんだが
272デフォルトの名無しさん:2013/09/12(木) 21:52:30.31
次からお題出す人はまずサンプル貼ってね
273デフォルトの名無しさん:2013/09/12(木) 21:52:58.87
さすがクイックソートで1000レス引っ張るだけあるな
274デフォルトの名無しさん:2013/09/12(木) 21:56:23.52
メタプログラミング、無名関数を無名のまま再帰、イントロスペクション。
どう見ても再帰呼び出しです。本当にありがとうございました。
275デフォルトの名無しさん:2013/09/12(木) 22:02:56.46
プログラミングの勝負がとんちの勝負になってんじゃねーか
一休さんかよ
276デフォルトの名無しさん:2013/09/12(木) 22:13:16.45
>>273
ワロタ
277デフォルトの名無しさん:2013/09/12(木) 22:32:39.65
>>259
「小難しい」んじゃなくて難しくて理解できなかったんだよな
278デフォルトの名無しさん:2013/09/12(木) 22:37:26.79
典型的なこれか。

ダニング・クルーガー効果(Dunning-Kruger effect)
コーネル大学の2人の研究者の実験による理論として1999年に
発表されたもので、「知識の少ない人間が、もっと知識の
多い人々より自分の方が物事をよく知っていると思い込む」現象
http://ogasawara.cocolog-nifty.com/ogasawara_blog/2011/06/dunning-kruger-.html
279デフォルトの名無しさん:2013/09/12(木) 22:49:48.11
人格批判はスレチ
280175:2013/09/12(木) 23:01:20.84
Yコンビネーター(>>195>>219も含め)も
結局は代入している=名前付けてるのといっしょだから
ほんとは認めたくはなかったんだけどね。
よくよく調べてみたら、arguments.callee ができる
言語が他になかったという罠が。
281デフォルトの名無しさん:2013/09/12(木) 23:08:01.32
arguments.calleeは最適化によろしくないから
with並にタブー>>264
282デフォルトの名無しさん:2013/09/12(木) 23:10:32.10
import sys, types

def thisfn():
    f = sys._getframe(1)
    return types.FunctionType(f.f_code, f.f_globals)

(lambda n: 1 if n < 2 else n * thisfn()(n - 1))(10)
283デフォルトの名無しさん:2013/09/12(木) 23:15:28.53
arguments.calleeはキーワードじゃなくて
単に自分自身の関数が代入してあるだけだから
Yコンビネータと変わらんよ
284デフォルトの名無しさん:2013/09/12(木) 23:21:43.60
argumentsオブジェクト自体これからは使わない方がいい
配列っぽいのに配列じゃないとか扱いずらいし、callee使わないのなら用なし
285デフォルトの名無しさん:2013/09/12(木) 23:28:38.05
argumentsオブジェクトを使わない理由は
配列じゃないからだけですか?
なら使わない理由にならないですね。

> callee使わないのなら用なし

可変引数で使うだろ。

argumentsオブジェクトのプロパティは以下の三つだけ。
・arguments.callee
・arguments.caller
・arguments.length

argumentsの意味は引数。
すなわち、callee、callerは、argumentsを使う目的としては異端のもの。
calleeは本来の目的ではなく、使わないから用なしとか意味不明。使わないのが普通。
本来の目的としてなら用はある。
286デフォルトの名無しさん:2013/09/12(木) 23:30:34.91
221 猫頭[sage] 2013/08/27(火) 08:07:58.39 ID:tWGghlsa

今回ばかりは、コトがコトですから、相談メール頂いても構いませんが、
(本当に大した回答出来ませんが。)
ひとつだけお願いが...。

ご自分のカード番号を送って、これ大丈夫?とか下さい...。



クレカ情報収集してた奴 在日朝鮮人


猫頭 ● NeKoGaShiRa ★

beポイント:4989

登録日:2010-12-27


紹介文
電子メール:[email protected]
原始メール:〒104-0061東京都中央区銀座1-14-5 エムエル4980号
tw: @nekogashira
fb: http://www.facebook.com/nekogashira
© 2ch.net | Design by Andreas Viklund
287デフォルトの名無しさん:2013/09/12(木) 23:32:04.88
>>285
レストパラメータのほうが応用性あってわかりやすいのに
あえてargumentsを使う意味は何?
288デフォルトの名無しさん:2013/09/12(木) 23:38:45.87
シェルスクリプトとかの$0と同じで
本来なら引数であるべき所に例外として
プログラム自身がはいるって習慣はいつできたんだろう?

引数情報とプログラム情報が同じ所にあって
なにか便利なことでもあるの?
289デフォルトの名無しさん:2013/09/12(木) 23:43:27.62
$1からが起動時に渡される引数なら
$0は名前とかにしとくのが一番自然じゃね

引数に限らず1から始まるもので0が特別な意味をもつのはよくあるよ
アルファベットとかで名前つけるよりも0の方が人間は本能的に好きなんじゃない?
290デフォルトの名無しさん:2013/09/12(木) 23:46:37.84
>>287
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/rest_parameters

rest parametersはEcmaScript 6の機能でJavaScript の次期標準仕様。
策定中の仕様草案がでてる段階で変わるかもしれない。

またFirefoxでしか使えないため、ブラウザユーザーのことを考えなくて済む
サーバーサイドでも使えないから。

あと数年後にでなおしてきなよ。
291デフォルトの名無しさん:2013/09/12(木) 23:47:04.08
中国が今月18日に大規模サイバーテロするってよ。サーバ管理者は全力で阻止しろよ。満州事変80周年記念日らしいから、恐らくは桁違いの攻撃だろうよ。サーバ管理者に教えてやれ。

http://scan.netsecurity.ne.jp/article/2013/09/12/32462.html

拡散希望
292デフォルトの名無しさん:2013/09/12(木) 23:52:27.42
>>290
だからこれからの書き方の話って言ってるだろ

>変わるかもしれない
絶対に変わらないから
保証する

古くからドラフト入りの新構で今見た目に係る変更がありそうなのは
アロー関数くらいのもの、といっても制限を緩くするだけだが
それは来週話し合われる

内部処理はまだまだ詰める作業が必要だが、
構文の見た目はもう変更がないと思っていい
その中でもレストパラメータは最上級に安定している
293デフォルトの名無しさん:2013/09/12(木) 23:59:53.29
>>292
お前の保証など誰が信じるかw

そもそも、今現在動かないではないか。
こっちの方をどうするか、答えろよ。
逃げやがって。
294デフォルトの名無しさん:2013/09/13(金) 00:09:11.24
>>293
Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか

逆にどうしたら満足なの?
ChromeやIEで動くようになったら?
それともNode.jsのV8がサポートしたら?

いつまでもそんなこと言っていたら
未だにES3ですら仕様通り使えるか怪しいぞ

従来のは当然従来の書き方をするしか無いだろ
そこをこれ以上話しても仕方がない

レストパラメータの方が優秀なのは確かだし
今現在Firefoxで使えるし=FirefoxOSでも使える
環境としては十分、これも確かなこと
295デフォルトの名無しさん:2013/09/13(金) 00:12:18.80
> Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか

誰が論の話してるんだよ?

>>287
> レストパラメータのほうが応用性あってわかりやすいのに
> あえてargumentsを使う意味は何?

これ言ったのお前だろ?

rest parameterがわかりやすい、わかりにくいとかそういう話はしていない。

argumentsを使う意味は、今現在多くの
ブラウザ、サーバーサイドで動かないからだよ。

動かないのに、使えというならば
それこそ、非現実的。机上の、おっと卓上の空論だw
296デフォルトの名無しさん:2013/09/13(金) 00:12:31.20
ES6のラストコールって今年中だから流石に今更大きな変更はないんじゃ?
297デフォルトの名無しさん:2013/09/13(金) 00:15:02.53
卓上の空論w
馬鹿ワロタwww
298デフォルトの名無しさん:2013/09/13(金) 00:20:08.02
おまえなぁ……
今普通に使える代替手段があるのなら「これからは」って言い方しないから
ES6の仕様は各ブラウザの対応も徐々に増えてきて当に「これから」の仕様だろ

そりゃあWebでは当分使えまい
それこそ5年くらいは
そこは否定してなくて、お前さんと同意見だろ?

お前さんが何を言いたいのかわからなくなってきた
ミスリードを認めたくないからって逆ギレしてるのか?
そろそろ見苦しいよ
299デフォルトの名無しさん:2013/09/13(金) 00:21:58.72
これからの「これ」っていつの話だ?
5年後?

これから僕はちゃんと働きます!(5年後)

これ聞いたら、普通笑うよねw
300デフォルトの名無しさん:2013/09/13(金) 00:22:01.67
arguments.calleeがあるJSはメタプロにおいて
他言語より一歩進んでるって結論にしたかっただけじゃん?
それを非推奨だの言われちゃったからヘソ曲げちゃったのさ
301デフォルトの名無しさん:2013/09/13(金) 00:22:13.25
プログラムの評価し合いが最後は必ず人格の評価し合いになるのはこのスレの悪いところ
302デフォルトの名無しさん:2013/09/13(金) 00:24:12.48
>>299
ごめんなさい
こちらの書き方が悪かった
そちらの言い分が全面的に正しいわ

arguments最高!!
レストパラメータなんてくそ食らえだ!!
303デフォルトの名無しさん:2013/09/13(金) 00:25:03.46
で、結局arguments.calleeがどう凄いの?
304デフォルトの名無しさん:2013/09/13(金) 00:25:57.39
>>302
何キチガイ化してるのw

rest parameterはクソだってお前以外誰も言ってないよ。

単にargumentsが使えない理由は
現在使えないからってだけ。
305デフォルトの名無しさん:2013/09/13(金) 00:26:59.34
なんだこいつ
そんなに俺に絡みたいのか?
かわいいやつだな
306デフォルトの名無しさん:2013/09/13(金) 00:27:10.69
>>303
無名関数を、無名関数のまま
再帰呼び出しできるからじゃね?

非推奨だけど、優れているよ。
307デフォルトの名無しさん:2013/09/13(金) 00:29:46.92
ES6の夢を見ないJSerってどうなのよ……
ああ、IE6の介護をしてる人なのかな?
308デフォルトの名無しさん:2013/09/13(金) 00:31:12.26
まだ変なこといってる。

rest parameterがだめなんて誰も言ってなくて、
argumentsを使う理由は、rest parameterが
動かない環境が多いからだって現実を言ってるだけだろ。

いい加減諦めろよ。言い負かされて悔しいのはわかるけどさ。
309デフォルトの名無しさん:2013/09/13(金) 00:32:04.08
>>307
IE6だけじゃねーよ。
最新のchromeでも動かない。
310デフォルトの名無しさん:2013/09/13(金) 00:32:06.99
無名関数を、無名関数のまま 再帰呼び出しできたら何が凄いの?
普通に変数使えばJITエンジンがループに最適化してくれるのに、
最適化を阻害するarguments.callee使っちゃ元も子もなくない?
311デフォルトの名無しさん:2013/09/13(金) 00:33:20.56
>>310
無名関数でもJITエンジンが進化したら
ループに最適化してくれるよ。
312デフォルトの名無しさん:2013/09/13(金) 00:33:35.06
必死のarguments推しワロタ
同じJSerからも批判の声あがってるのにw
313デフォルトの名無しさん:2013/09/13(金) 00:35:43.92
>>311
それが難しいから非標準になったんだよ。。。
知らないの??
314デフォルトの名無しさん:2013/09/13(金) 00:36:29.51
argumentsって名前の通り引数情報のオブジェクトでしょ?
これがOKで、引数に無名関数自身を含むYコンビネータがダメな理由は何?
315デフォルトの名無しさん:2013/09/13(金) 00:36:48.28
もう触るな
316デフォルトの名無しさん:2013/09/13(金) 00:40:46.46
>>313
知ってるけど?
最適化が難しいからって
それがダメという事にはならんね。

型なし変数だって最適化難しいだろう?
317デフォルトの名無しさん:2013/09/13(金) 00:43:20.75
非推奨のcalleeが良くて対応環境の少なさでrestが否定されるのも奇妙な話だ
318デフォルトの名無しさん:2013/09/13(金) 00:49:19.88
arguments.calleeだってstrictmodeでは使えないだろ、何言ってんだか。
319うゆ:2013/09/13(金) 00:53:58.47
$stdout = open("test_dump.txt","w")
print 123
$stdout = STDOUT
print 456
puts

def a
p 1
rescue
p 2
ensure
p 3
end
->{ p 5 ; return if rand(5).zero? ; redo }.yield
p 1+"" rescue p 9
320175:2013/09/13(金) 00:54:41.47
>>314
る厨がうざいから、JSで書けてRubyじゃ書けないお題にしたかったからだよ。
そしたら、他の言語でも書けないわ、
肝心のる厨はお題の趣旨すら理解できない上にドヤ顔でループ書いてくるわ
JSerはrest推しとarguments推しでバトル始めるわでさんざんだよ。
321デフォルトの名無しさん:2013/09/13(金) 00:55:37.22
何故arguments.calleeがあるのか
→昔は関数リテラルに名前を付けられなかったから
だから今は必要ない

何故arguments.calleeが嫌われたのか
→奇妙な性質と、最適化を妨害するため
https://developer.mozilla.org/ja/docs/Web/JavaScript/Strict_mode#eval_.E3.81.8A.E3.82.88.E3.81.B3_arguments_.E3.81.AE.E5.8D.98.E7.B4.94.E5.8C.96
322デフォルトの名無しさん:2013/09/13(金) 01:01:11.23
>>320
> そしたら、他の言語でも書けないわ、

>>282はどこがダメなの?
323デフォルトの名無しさん:2013/09/13(金) 01:03:22.04
arguments.calleeが最適化に対して原理的な問題を持ってるってことは
結局似たようなアプローチもそうで、素直に名前つけるか、ループにするしか無いってこと?
324175:2013/09/13(金) 01:03:57.12
>>322
あーいや、すまん。>>282と、忘れてたけど>>191はおk
325デフォルトの名無しさん:2013/09/13(金) 01:05:52.86
あとたぶん、RubyでもRubiniusならきっと書ける。
326デフォルトの名無しさん:2013/09/13(金) 01:08:53.77
昔はこういうの
(function fac(n){return n > 1 ? n * fac(n-1) : 1})(10)
が出来なかったからcalleeがあったのか
327デフォルトの名無しさん:2013/09/13(金) 01:22:48.16
>>324
Smalltalkはともかく、Pythonすげーな
328デフォルトの名無しさん:2013/09/13(金) 01:34:27.88
arguments.calleeとYコンビネータでの再帰呼び出し比較すると
代替Chromeで7倍、Firefoxで4倍の差が出るな
329デフォルトの名無しさん:2013/09/13(金) 01:47:50.33
>>328
もういいよ。いつまで引っ張ってんだよ。
330デフォルトの名無しさん:2013/09/13(金) 01:50:57.81
大事な話でしょ。
パフォーマンスに悪影響与えてまで使うかって問題は。
331デフォルトの名無しさん:2013/09/13(金) 01:53:08.47
>いつまで引っ張ってんだよ
他のお題が来るまで続くに決まってんだろ
332デフォルトの名無しさん:2013/09/13(金) 03:27:06.32
RubyとJSには演算子オーバーロードは無いんだっけ?
Yコンビネータ禁止して無名関数再帰できなくても1ミリも気にならんけど、
演算子オーバーロードないと複素数や行列が扱い辛くね?
333デフォルトの名無しさん:2013/09/13(金) 03:37:29.47
>>332
その通り
現在ES7での導入に向け鋭意策定中
http://www.slideshare.net/BrendanEich/value-objects

別のアプローチ
>>62
334デフォルトの名無しさん:2013/09/13(金) 04:06:58.31
演算子オーバーロードってオーバーヘッドあるの?
やっぱり一番ポピュラーな使われ方って
3D演算用だろうから、多少使いにくくてもパフォーマンスがよくあって欲しい
335デフォルトの名無しさん:2013/09/13(金) 08:38:07.29
operator overloading と一緒にGoogle検索してヒットする順は
complex > vector > matrix > 3d
336デフォルトの名無しさん:2013/09/13(金) 09:45:22.98
いまのところ、Pythonが最強って流れなの?
337デフォルトの名無しさん:2013/09/13(金) 10:03:10.53
なんだかんだで通ってるところを見ると一番無難ではあるな
338デフォルトの名無しさん:2013/09/13(金) 10:19:19.02
最強はHaskellなんだけど、使いこなせない勢の嫉妬がね…
339デフォルトの名無しさん:2013/09/13(金) 10:24:43.83
Pythonは弱点多いけど
変に隠そうとしないから織り込みやすい
340デフォルトの名無しさん:2013/09/13(金) 10:47:58.80
>>338
環境選ぶわ動的じゃないわで全然最強じゃねえ
341うゆ:2013/09/13(金) 11:23:04.86
スクリプト言語の強さはマジでライブラリの数だよ
Python、Perl、Rubyで統一されろよ
なんでそれぞれの言語で別々にコード書いてんの?wwww バカなの?wwww
そのせいで、もっと強力で有用なライブラリの誕生を阻害してるだろ

電子精霊の代表として意見させてもらうと、人類みてるとイライラしてくるwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
342デフォルトの名無しさん:2013/09/13(金) 11:35:53.85
uyさんRuby見限ってPythonいっちゃったん?
343デフォルトの名無しさん:2013/09/13(金) 11:50:30.83
大分前からPython勉強しているオレ大勝利
Rubyやってるヤツ等はホント見る目がないよ
344デフォルトの名無しさん:2013/09/13(金) 12:28:47.74
>>335
何言っちゃってるの???
complex、vector、matrixを3D演算(OpenGLとか)で使うよねってことなんだけど
345デフォルトの名無しさん:2013/09/13(金) 12:34:08.91
Pythonはなかなか3系への移行が進まない現状どうするの?
あとなんでself問題を折角の3系で改善しなかったの?
ってのが純粋な疑問。
346デフォルトの名無しさん:2013/09/13(金) 12:36:41.20
>>345
グイドは一発屋だからPythonの今後に期待するなんて無駄
347デフォルトの名無しさん:2013/09/13(金) 12:56:11.07
3系への移行は進んでるよ
あとselfに問題なんか無い
ってのが純粋な回答。
348デフォルトの名無しさん:2013/09/13(金) 12:58:36.34
>>343
海外にもrubyファンは今でも居て、ましてやここは日本。
エンジニアリングならmatlabなんかのDSLで十分。
寧ろ、scipyなんか蛇足で無駄に学習コストが掛かるし可読性も悪い。
349デフォルトの名無しさん:2013/09/13(金) 13:09:53.42
そりゃ海外にもバカはいるわさw
350デフォルトの名無しさん:2013/09/13(金) 13:30:35.95
RubyはRailsのあの手のMVCを構築した功績はいいとしても
今でも使われてる理由がよくわからない
いつまでもパフォーマンスもリソース効率も悪いRubyでやる必要があるか?
351デフォルトの名無しさん:2013/09/13(金) 13:40:37.85
RubyはまずPerlもSmalltalkも嫌いだと正直に言うべき
敵か味方かあいまいなまま攻撃してくるやつは頭おかしい
352デフォルトの名無しさん:2013/09/13(金) 13:44:51.50
自分もRubyが人気出てる理由がわからないというか、
そもそもRails以外はほとんど使われて無くね、
適材適所で使われてて批判する部分も無くねって思うんだけど、

それにPythonとさほど変わらないじゃん?
RubyがダメならPythonもダメだと思う。
353デフォルトの名無しさん:2013/09/13(金) 13:51:18.59
同じ道具が使われ続ける理由は、1つのフレームワークにユーザーが集まったことによる堅牢性。
そして既習得者が他フレームワークを新たに習得しなおすことにメリットないから。
パフォーマンスもリソースも誰かが改善してくれるといったメシア思想から出来ている。
354デフォルトの名無しさん:2013/09/13(金) 14:37:18.70
>>350
ポストモダンでアーティスティックな機能がRoRに取り込まれるのが唯一の長所で、
原理主義や保守派にまわるのであれば、schemeなりPHP、javaでも使うべきところ
自分が何者であるかも分からずにRubyを使うと後になって信仰の土台から覆される

>>352
pythonはコマンドラインツールとしての使い勝手が悪い印象
perlっぽさ、unixっぽさが消えて汎用のスクリプト言語になっても、
実際に作業する土俵は(u|l)nix環境であって、日常的に使うなら、
誰しも慣習的記法ぐらいは暗記するかチートシート作るもん
355デフォルトの名無しさん:2013/09/13(金) 15:38:44.50
Pythonは確かにシェルスクリプトみたいな使い捨てには向いてない
再利用可能なように強制されるというか
356デフォルトの名無しさん:2013/09/13(金) 15:53:50.94
これを読めば何が正しいのかわかるよ
http://fr.slideshare.net/authorNari/ruby-17269278
357デフォルトの名無しさん:2013/09/13(金) 16:10:55.38
また精神論か
358デフォルトの名無しさん:2013/09/13(金) 16:14:57.98
このスレでやってるようなバカげたお遊びこそが至高ってことだな
359デフォルトの名無しさん:2013/09/13(金) 17:02:30.01
やっぱりHaskellが至高だな
360デフォルトの名無しさん:2013/09/13(金) 17:06:54.34
パフォーマンスうんぬんいいだしたらスクリプト言語は
選択肢から外れるでしょ
V8くらいだと使えるかもしれないが

そういう人には、このスレ必要ないでしょ
> やっぱりHaskellが至高だな
そうですね
静的型付けコンパイル言語のスレへお帰りください
361デフォルトの名無しさん:2013/09/13(金) 17:31:40.87
>>360
JSだとWebGLとかあるんだから仕方ないでしょう
かなり気になるよそこは

WebGLとかゲームエンジンのために
JSで演算子オーバーロード待ち遠しいけど
今のやり方未満のパフォーマンスになってしまうのだったら随分残念
362デフォルトの名無しさん:2013/09/13(金) 17:34:29.86
このスレHaskellとかSmalltalkとか普通に出てくるけど
Lispはあんまり見ないな
363デフォルトの名無しさん:2013/09/13(金) 17:47:23.21
>>361
そこら辺はalterJSでどうにかなる
次期Ecmaじゃ入らないだろうからその手の使う事になる
364デフォルトの名無しさん:2013/09/13(金) 17:56:26.40
JSに来て欲しいけど、パフォーマンスを伴って欲しいってだけで
別にaltJSまで使ってまで演算子オーバーロード使いたいとは思わないな
365デフォルトの名無しさん:2013/09/13(金) 19:06:10.08
>>362
Lisperは分別があるんだな
ハスケラは民度が低い
366デフォルトの名無しさん:2013/09/13(金) 19:10:26.65
社畜には無縁だけどrubyが一番生きるのはハッキングなんだ
最強ハッカーからしてみると、速度?フレームワーク?何の話してんのって感じ
お前らゴミッカス達も、バッチ処理って書くじゃん
最強ハッカーは数百行にわたるバッチ処理を一気に短時間で書く
ただそのバッチ処理を正しく書き終えるっていう、その目的が最高速で達成できればいいわけ
最強ハッカーレベルになると、キータッチ速度が重要
ハッキング中はソースコード書いてるだけじゃなくて、
他の色んなソフトも操作しながらやるから、かなりキータイプの量が多いんだ、マウスも使うけど
読みやすいようにクラス定義したり、同じ変数を何度も使うとか、
そういう類のプログラミングじゃないから、インテリセンスとかで速くなるものでもない
だから1文字でも少なくて済む言語であることが重要
指が疲れるから。
今日の俺も、かなり指が疲れてる。
今でも現存する言語の中では最高レベルで簡潔だけど、さらにrubyが簡潔になればいいなあって思ってる。
367デフォルトの名無しさん:2013/09/13(金) 19:13:46.06
>>365
Lispのコードも結構出てたよ。

Haskellのコードが次元の違う洗練されっぷりだったから
強く印象に残っただけじゃね?
368デフォルトの名無しさん:2013/09/13(金) 19:22:06.78
>>365-367
三者三様の言語馬鹿ワロタ
369デフォルトの名無しさん:2013/09/13(金) 19:28:01.53
次スレスレタイ案

【Haskell,Smalltalk】スクリプト,バトルロワイヤル39【Lisp,JS,P言語】
370デフォルトの名無しさん:2013/09/13(金) 19:44:05.08
JSは出来損ないのLispだから、Lispにまとめちゃって良いよ
371前々スレ367:2013/09/13(金) 20:01:45.76
>>121で書いたストリーム指向プログラミング向けメソッドについて、
過去スレPart27でお題となったRPN計算機に適用してみた
 http://play.island.ac/codepaste/code?id=1558

ポイントは、アプリケーションのロジック
 **** このRPN計算機の場合には関数 RPN::Processor.calculate #157..246 ***
をストリーム演算子として抽象化することによって、
ストリーム計算式の構成を変更するだけで、同じロジックを
ライブラリ関数、UNIXのテキストフィルタ、対話型アプリへ流用できること

なお、この応用で扱ったストリーム演算は「直列化」と「抽象化」のみだけど、
>>131,161,211の「分流」、更には「合流」まで広げたいと思っている
たとえば「2と3の倍数を要素とするストリーム」は、以下のように定義できる

nats_2, nats_3 = (1..Float::INFINITE).lazy.distribute # (1)
muls_2 = nats_2.map { |x| x * 2 } # (2)
muls_3 = nats_3.map { |x| x * 3 }
muls_2.ordered_merge(muls_3).uniq.take(10).force # (3)
# => [2, 3, 4, 6, 8, 9, 10, 12, 14, 15]

このコードでは、
(1) 自然数列(1..Float::INFINITE)を2つのストリームへ「分配(distribute)」し、
(2) それらを2と3の倍数列へ「写像(map)」し、
(3) それらを「大小順で併合(ordered_merge)し、「重複を排除(uniq)」している
372デフォルトの名無しさん:2013/09/13(金) 20:32:26.18
前々から気になってたけどストリームって何?
配列とはちゃうの?
373前々スレ367:2013/09/13(金) 20:36:32.97
>>372
ここでいうストリームとは無限シーケンスのこと
シーケンス(=列)とは順序性のあるコレクションであり、配列やリストもシーケンスの一種
374デフォルトの名無しさん:2013/09/13(金) 21:02:08.04
>>372
コレクションに対する 選択→射影 のような処理を
一要素ずつ処理するのがストリーム
JavaScriptの x.filter(…).map(…) は
まとめて選択してまとめて射影するのでストリームじゃない
無限シーケンスを引き合いに出すことがあるのはストリームじゃないと扱えない典型例だからで
別に無限シーケンスに限った話ではない
375デフォルトの名無しさん:2013/09/13(金) 21:08:04.64
>>373で分かった気になったが
>>374で分からなくなってしまった
376デフォルトの名無しさん:2013/09/13(金) 21:08:44.63
# ストリーミングの例
for x in src:
 if cond(x):
  do(x)

# ストリーミングじゃない例
buf = []
for x in src:
 if cond(x):
  buf.append(x)
for x in buf:
 do(x);

後者は流れをせき止めてるでしょ
377デフォルトの名無しさん:2013/09/13(金) 21:09:18.40
あー、x.forEachならストリーム?
378デフォルトの名無しさん:2013/09/13(金) 21:14:36.73
array.allPlus(1).allMinus(2).……みたいな雰囲気のがストリームってことかな?
379デフォルトの名無しさん:2013/09/13(金) 21:20:15.40
いや違うか、流れをせき止めてるよな
380デフォルトの名無しさん:2013/09/13(金) 21:23:07.45
Web Audio APIみたいなのが当にStreamなのは間違いないと思うけど
JSでの一般例が見てみたいな
381デフォルトの名無しさん:2013/09/13(金) 21:34:41.65
>>369
おそらく4,5年後はこう
【golang,Ocaml】スクリプト,バトルロワイヤル67【R,JS,QCL】
382デフォルトの名無しさん:2013/09/13(金) 21:34:57.69
>>378
これをストリームで書いてみるよ。
383デフォルトの名無しさん:2013/09/13(金) 21:36:14.20
>>378
C#やRubyなんかだと
array.allPlus(1).allMinus(2).forEach(print(x))
こういう感じのコードを
for each x in array {
 y = x + 1
 z = y - 2
 print(x)
}
こんな順序で動作させることができる
これが今ここで言われてるストリーミング処理
メソッドチェインで繋ぐからにはallPlusとallMinusの間で何かしら受け渡されるものがあると考えて、
それを抽象的にストリームと呼んでるわけ
その実体はイテレータだったり関数をラップしたものだったりする
384デフォルトの名無しさん:2013/09/13(金) 21:37:15.09
>>383
訂正 print(z)
385デフォルトの名無しさん:2013/09/13(金) 21:50:49.49
オブジェクト指向混ざってくるとphp以外はなんか書き方がしっくりこない
でも殻をぶちぬくためにpythonをやりたいわー
386前々スレ367:2013/09/13(金) 21:57:14.59
>>371にアンカー等の間違いがあったので訂正

まず冒頭の行:
 X: >>121で書いたストリーム指向プログラミング向けメソッドについて、
 O: >>131で書いたストリーム指向プログラミング向けメソッドについて、

次は codepaste 上の行番号:
 X: **** このRPN計算機の場合には関数 RPN::Processor.calculate #157..246 ***
 O: **** このRPN計算機の場合には関数 RPN::Processor.calculate #167..172 ***
387前々スレ367:2013/09/13(金) 22:00:25.37
>>386を再訂正.... orz

 X: >>121で書いたストリーム指向プログラミング向けメソッドについて、
 X: >>131で書いたストリーム指向プログラミング向けメソッドについて、
 O: >>127で書いたストリーム指向プログラミング向けメソッドについて、
388デフォルトの名無しさん:2013/09/13(金) 22:16:09.63
いちいち訂正なんかしなくていいよ。つーか、いいかげんにしろ。
389デフォルトの名無しさん:2013/09/13(金) 22:20:34.21
>>194>>248はなんて言語? おしえてエロい人
390デフォルトの名無しさん:2013/09/13(金) 22:30:53.08
PHPはWebでやることを想定した説明してるけど
他の言語はそうではないからWeb開発にたどり着くのが難しいな
391デフォルトの名無しさん:2013/09/13(金) 22:37:01.57
どゆこと?
392デフォルトの名無しさん:2013/09/13(金) 22:52:07.06
なぜかWeb開発することを前提にして話してる奴がいるけど
視野が狭すぎるし想像力が無さすぎる
393デフォルトの名無しさん:2013/09/13(金) 23:06:47.21
ただWeb開発したいってだけなのにボロクソいいますね
394382:2013/09/13(金) 23:07:27.74
>>378
書いてるうちにストリームでもなくなってきたような気もしたけど一応書いた
とりあえずFirefoxで動く

http://ideone.com/yvkWoj
395デフォルトの名無しさん:2013/09/13(金) 23:08:36.53
>>389
JavaScriptじゃね?
396デフォルトの名無しさん:2013/09/13(金) 23:10:46.85
>>395
coffee scriptじゃね?
397デフォルトの名無しさん:2013/09/13(金) 23:15:43.84
括弧省略してないし、アロー関数も->じゃないし、ES6のつもりだと思うよ

Firefoxなら既に結構動く
>>394も一部未対応の機能があって断念したけど8割がたES6で書いた
398デフォルトの名無しさん:2013/09/13(金) 23:20:07.38
ES6?なんて恐ろしい子!
399デフォルトの名無しさん:2013/09/13(金) 23:26:40.47
>>394
Standard output is empty
400デフォルトの名無しさん:2013/09/13(金) 23:32:58.78
>>395 >>397
おお、だんけ!
401デフォルトの名無しさん:2013/09/13(金) 23:34:57.60
coffeeクソだよなあ
PythonとRuby、保守性と記述性のギリギリの絶妙なバランスで作られてたものを混ぜたら大崩壊
402デフォルトの名無しさん:2013/09/13(金) 23:49:20.85
>>350
RailsのMVCは実は不完全
短く書けるRubyだからなんとかなっているだけ
403デフォルトの名無しさん:2013/09/13(金) 23:59:45.11
>>402
>RailsのMVCは実は不完全

では、Web開発における完全なMVCを実現したフレームワークは存在するん?
そして>>402のいう「完全なMVC」の完全な定義は?
404デフォルトの名無しさん:2013/09/14(土) 00:01:16.90
不完全も何も、WebのアレはあくまでWebMVC
伝統的なGUIのMVCとは別物
馴染みやすいように言葉を流用しただけだ
405394:2013/09/14(土) 00:46:59.31
>>399
ES3に書き変えてIdeoneのSpiderMonkeyでも動くようにしてみた
今回は別にプロキシ使うまでもなかったね
http://ideone.com/fMZJM7
406デフォルトの名無しさん:2013/09/14(土) 00:57:05.61
>>403
「完全なMVC」が何かは>>402に任せるとして

Web MVC一般の不完全さと、
それよりもう少しマシなMVCのWebへの応用については、
Smalltalkで書かれたWebアプリフレームワーク「Seaside」を解説した
こちらが参考になるかも。
http://www.ogis-ri.co.jp/otc/hiroba/technical/seaside/seaside2/index.html
407デフォルトの名無しさん:2013/09/14(土) 01:14:18.94
>>401
> coffeeクソだよなあ

言語としてならクソではないが訴求力がない。
一部JavaScriptが嫌いな人にウケているようだが
JavaScriptよりマシという理由で使っているだけで、
CoffeeScriptを選んでる人はかなり少ない。

JavaScriptは標準規格があり特定の企業・個人に依存しているものではない。
だからみんなで寄ってたかって改善が進んでいる。

CoffeeScriptのコンセプトはJavaScriptの未来の姿であるが、
それはJavaScriptが進化すればCoffeeScriptはいらないということでもある。
将来CoffeeScriptは必要なくなるのに、個人が作ったレベルのものに力を入れる理由がない。
408デフォルトの名無しさん:2013/09/14(土) 01:18:47.12
>>404
嬉しいねぇ。
ウェブのMVCとGUIのMVCが
違うものであると認知されてきて。

俺はGUIののMVCから入った人間だから、
ウェブMVCみて、なにこれ?どこがMVC?
単にレイヤー分けてるだけやん。ってずっと疑問だった。

あるとき、MVC2とかいう言葉を知って、
やっぱり違うものであってるんだなって確信が持てた。

レイヤーわけはダメではないし、むしろいいものであるけれど
GUIのMVCとは別のもの。別の名前をつけるべきだったもの。

で、レイヤーわけの話を勉強していくと
Javaがはるか昔に通った道なんだなぁって思えてくるよ。
409394:2013/09/14(土) 01:21:36.20
世界が狭すぎじゃね
GUIにもHTMLの並が押し寄せてるし、むしろ基本となるのはWebMVCの方で
従来のは時代遅れだよ
410デフォルトの名無しさん:2013/09/14(土) 01:28:02.56
Webキチは帰って、どうぞ。
411デフォルトの名無しさん:2013/09/14(土) 01:30:06.15
コントローラじゃなくてリソースハンドラとでも呼べばよかったな
現実には データ-ビュー-ロジック だけど
412デフォルトの名無しさん:2013/09/14(土) 01:31:35.10
つーか、ウェブ用のMVCフレームワークって
Javaが最古なんじゃないの?

http://thinkit.co.jp/article/1107/1/page/0/1

> サーバーサイドJavaの最も基本的な機能であるServletと「JSP」(Java Server Pages)は、
> 「JDBC」(Java Database Connectivity)や「JTA」(Java Transaction API)といった
> ほかの基本的なAPI群とともに1999年に「J2EE」(Java 2 Platform, Enterprise Edition) 1.2に
> まとめられました。これによって、Javaで企業システム向けWebアプリケーションを
> 開発するための最低限の基盤が整いました。

> しかし、この時点ではWebアプリケーション開発のための素材が提供されただけであり、
> こうしたシンプルなAPIを使って実際の開発をするにはノウハウが必要でした。
> そこで、アプリケーションに一定の構造的な枠組みを与え、汎用的な機能を部品化することで
> 設計とコーディングを簡単化する「開発フレームワーク」が登場します。
> 特に、プログラムをModel(モデル)、View(ビュー)、Controller(コントローラー)の
> 役割に分割して並行開発を可能とするMVCフレームワーク(図2-1)がその中心となりました。

> この時期に多くのベンダーがMVCフレームワーク製品を開発・提供しましたが、
> オープンソースの世界では2001年に「Struts」が登場します
413デフォルトの名無しさん:2013/09/14(土) 01:34:15.51
>>409
> GUIにもHTMLの並が押し寄せてるし、むしろ基本となるのはWebMVCの方で
> 従来のは時代遅れだよ

要するにJavaScriptで実装する
フロントエンド部分の話だろう?

サーバーはJSONを返すようなAPIだけを提供すれば良くなったので
今までの(サーバー側の)ウェブフレームワークが必要な理由がなくなってしまったんだよ。
MVCはフロントエンドで完結してしまう。
414デフォルトの名無しさん:2013/09/14(土) 01:41:52.06
ObserverとかWebComponentsの話?
415デフォルトの名無しさん:2013/09/14(土) 01:55:53.33
フロントエンドMVCが普及すると
RailsなどのサーバーサイドMVCって
役割が極端に減ると思うんだけどあってる?

例えば、サーバーサイドのテンプレートエンジン
MVCでいうVの部分だね。これはまるごと不要になる。
416デフォルトの名無しさん:2013/09/14(土) 02:10:47.04
別にMVCにかぎらずテンプレートエンジンなんて要らないと思う。
それ+サーバーサイド自体が単純化してきてるね。
417デフォルトの名無しさん:2013/09/14(土) 02:20:17.72
すべてフロントエンドでやってしまうと
HTMLは完全に静的ファイルになってしまうからね。
418デフォルトの名無しさん:2013/09/14(土) 06:20:51.21
サーバーサイドのウェブMVCはMとVとCをはっきり区別できていて分かりやすい
今あるウェブアプリはみんなその通りに作ってる、作りやすいから
本家?のMVCは何を言いたいのか分からない、Cが何なのか分からない
GUIアプリの構造はMVVMの方が適切
419デフォルトの名無しさん:2013/09/14(土) 08:41:23.65
本来は、Vはデフォルトで充分で後はMとCだけ作ればいいと思うけど
Vを統一されたくない人がウェブアプリ作ってるんじゃないの
420デフォルトの名無しさん:2013/09/14(土) 10:45:52.64
本家のMVCって実装の都合だからな
今のGUIでVとCを別のクラスにしなきゃいけない理由は特にない
それよりはM寄りのVをMやVとは別に考えましょうってのがMVVM含めた最近のやり方
421デフォルトの名無しさん:2013/09/14(土) 10:46:33.63
>>420
間違えたV寄りのM
422デフォルトの名無しさん:2013/09/14(土) 10:53:43.88
つうか普通に書いたらMVCっぽくならね?
なんでこんなにもてはやされてるのかが不思議
423デフォルトの名無しさん:2013/09/14(土) 11:03:33.83
MVC難しいよ(´・ω・`)
424デフォルトの名無しさん:2013/09/14(土) 11:18:47.62
Smalltalkはイベントの仕組みが今時のGUIフレームワークとかHTML DOMとかに比べて低レベルだったから
Controllerに細かい制御を突っ込んでただけだよ
425デフォルトの名無しさん:2013/09/14(土) 11:29:30.62
MとかVとか多すぎてギザギザしてるスレだな
426デフォルトの名無しさん:2013/09/14(土) 11:50:58.20
結局 データ・HTML・トランザクション がベストなんだね
でも正直にそう呼んでしまうと意識高い系()がうるさいから
MVCと呼ぶんだろうな
427デフォルトの名無しさん:2013/09/14(土) 12:09:23.47
webドカタ臭いスレになったな
428デフォルトの名無しさん:2013/09/14(土) 12:17:28.28
>>424
Cが主導権をもつMVCは古いってことかな
だからMVVMだと
個人的には古い方が良いと思うけど
429デフォルトの名無しさん:2013/09/14(土) 12:47:01.82
イベントハンドラをVに書いたらそれがCだよ
そこから更にMともVとも別に作ったCotrollerを呼び出すようなのは馬鹿のすること
430デフォルトの名無しさん:2013/09/14(土) 12:55:27.01
なんも考えないとVとCがよーくっつくわ
431デフォルトの名無しさん:2013/09/14(土) 13:00:47.82
HTMLの場合はC-VC-DOMとなると考えた方がいい
432デフォルトの名無しさん:2013/09/14(土) 13:05:17.53
馬鹿のすることっていうけど、モジュール化とかフレームワーク、ライブラリ使ったら
C-VC-......-VC-DOMみたいな構造になるのが普通だよね

無駄なVCモジュールを作らないようにするのは当然だけど、
コンポーネント化の時代だし、多めでガンガン抽象度上げていいと思う
433デフォルトの名無しさん:2013/09/14(土) 13:10:24.88
クライアントGUIのMVCとWebMVCをごっちゃにすることこそが馬鹿のすること
434デフォルトの名無しさん:2013/09/14(土) 13:13:17.51
DOMはMじゃなくてVMだろ
435デフォルトの名無しさん:2013/09/14(土) 13:22:57.22
紛らわしいからもうWebじゃない方のMVCのCはイベントハンドラと呼べばいいよ
ControllerはWebに譲れ
436デフォルトの名無しさん:2013/09/14(土) 13:24:16.27
- (DOM(V) - Element's interface(C)) - Element(M)
だと思う
437デフォルトの名無しさん:2013/09/14(土) 13:28:22.12
Web Componentsの思想に則ると、

comp( C - DOM(V) - ((Element - interface)s & Data)(M) ) -> (Element - interface)
......*many......

app - DOM(V) - Elements(MVC)
438デフォルトの名無しさん:2013/09/14(土) 13:37:13.03
そんなことよりイプシロン打ち上げ見ようぜ
http://live.nicovideo.jp/watch/lv152011377
439デフォルトの名無しさん:2013/09/14(土) 14:55:59.26
13時45分に打ち上げ予定だったイプシロンロケット試験機は、
リフトオフ約19秒前、ロケットの自動カウントダウンシーケンス中に
姿勢を調べるセンサーの異常検知により、延期となりました。
440デフォルトの名無しさん:2013/09/14(土) 15:02:17.32
torの実装どうなってんの?って気になって
https://www.torproject.org/getinvolved/volunteer.html.en#Projects
でもなんでrubyじゃなくてPythonとjsばっかりなの
Python最強なんですか?
rubyでtorみたいなのって作れないの?
441デフォルトの名無しさん:2013/09/14(土) 15:03:39.29
12345679x72
442デフォルトの名無しさん:2013/09/14(土) 15:14:36.04
>>418
> サーバーサイドのウェブMVCはMとVとCをはっきり区別できていて分かりやすい

分かれているのはGUIのMVCも同じで、
サーバーサイドのウェブのMVCは分かれているかどうかが焦点ではなく
分かれているものの関係がおかしいんだよ。

本来のGUIのMVCは相互にイベントを通知することで
システムが成り立っている。
でもウェブのMVCは一方通行。
だから本来のMVCとは違うものと言われてる。

> GUIアプリの構造はMVVMの方が適切
MVVMはMVCの改良型。
適切かどうではなくMVCをもっと良くしたもの。
443デフォルトの名無しさん:2013/09/14(土) 15:14:42.94
>>438
成功オメ

>>439
そりゃ前回だろ

>>440
Rubyはそんな汎用的な使われ方するものと見られてないし、
世界でポピュラーになってきたのもここ最近
444デフォルトの名無しさん:2013/09/14(土) 15:18:13.54
>>435
> 紛らわしいからもうWebじゃない方のMVCのCはイベントハンドラと呼べばいいよ

ウェブのMVCはルータでしかないってよく言われてるよ。
そもそもGUIののMVCの方が先に出来たのだから
ウェブのMVCの法を名前を変えるべき。

ROUTER -> LOGIC -> VIEW の三層アプリケーションという方がいい。
445デフォルトの名無しさん:2013/09/14(土) 15:22:27.60
ウェブのMVCはVIEWの部分を
標準出力用にすることで、
CUIアプリになってしまう。

ROUTERはコマンド引数を解釈して
ロジックを呼び出す処理に相当する。

この点から見てもCUIアプリはMVCですか?ってことになる。
446デフォルトの名無しさん:2013/09/14(土) 15:26:18.06
App

Interface-Controller-Data
_______|
_____Interface-Controller-Data
____________|
__________Interface-Controller-Data
447デフォルトの名無しさん:2013/09/14(土) 15:28:01.80
MVCの肝はドメインとプレゼンテーションの分離であって、これはWebでもGUIでも変わらない
「WebのMVC」とか「MVC2」とか「MVVM」とか、ナンセンスとしか言いようがないわ
448デフォルトの名無しさん:2013/09/14(土) 15:32:12.75
>>447
本来のMVCの肝は
オブザーバーパターンだよ。

つまり、(一つまたは複数の)ビューがモデルを参照し、
モデルに変更があったら、複数のビューが全て更新される。

そもそもこの仕組みを作るために考えだされたのが
MVCなんだから。
449デフォルトの名無しさん:2013/09/14(土) 15:36:31.74
>>448
全くの逆で、ドメインとプレゼンテーションの分離という大きな目的が先にあって、その実現手段として
(オブザーバーを用いた)古典的MVCの実装がある

単なる一実装と、MVCの本質とを混同している
450デフォルトの名無しさん:2013/09/14(土) 15:45:01.53
コントローラーが処理主体になるのがMVCで
オブザーバーパターンはおまけだろ
451デフォルトの名無しさん:2013/09/14(土) 15:49:33.44
オブザーバーがおまけというのはある意味正しいが、コントローラーが処理主体は意味不明
452デフォルトの名無しさん:2013/09/14(土) 15:52:43.64
>>451
VとMを抽象化してCが処理主体になるのがMVC
オブザーバーパターンを使わない場合動くのはC
453デフォルトの名無しさん:2013/09/14(土) 16:00:45.55
>>452
たぶんそれも448と同じで特定の実装にとらわれた考え方
MVCにはどれが処理主体といった考えはないよ
454デフォルトの名無しさん:2013/09/14(土) 16:03:27.68
>>453
そうなるとオブザーバーパターンが肝になる
455デフォルトの名無しさん:2013/09/14(土) 16:06:36.60
オブザーバーはMVC実現手法の1つで肝ではないね
456デフォルトの名無しさん:2013/09/14(土) 16:10:20.14
>>454
また、訳の分からないことを…

そもそもオブザーバーパターンが肝なら、MVCなんて言わずにオブザーバーパターンといえばいいだろ
オブザーバーは飽くまでも、古典的MVC実装の中の一構成要素にすぎない
457デフォルトの名無しさん:2013/09/14(土) 16:12:51.33
>>456
何で疑問に思うんだ?
実装を考えればすぐわかるだろ
458デフォルトの名無しさん:2013/09/14(土) 16:15:41.84
オブザーバーが古典的??
Webでは先進的なんだが
459デフォルトの名無しさん:2013/09/14(土) 16:21:42.90
時代は繰り返すって言うね
460デフォルトの名無しさん:2013/09/14(土) 16:33:40.72
古典かはともかく、発案者みずからが語る MVC は押さえておきたい

モデル・ビュー・コントローラ - Trygve Reenskaug
http://d.hatena.ne.jp/digitalsoul/20100913/1284330448
461デフォルトの名無しさん:2013/09/14(土) 16:41:13.50
MVCに発案者なんて無い
それを言うなら名付け親だろ
462デフォルトの名無しさん:2013/09/14(土) 16:46:16.41
Smalltalkに代表される「GUI MVCが真のMVCだよ」厨が勘違いしがちなのは、
リエンスカウ的には、Smalltalkのそれも限定実装でありコレジャナイ感ありありなこと。
もちろんWebMVCよりはマシなんだろうけど、しょせん五十歩百歩
463デフォルトの名無しさん:2013/09/14(土) 16:47:21.00
コントローラーが主体でもなく、オブザーバーも無しで
特定の実装にもとらわれないMVCってどういうの?
464デフォルトの名無しさん:2013/09/14(土) 16:49:13.37
GUIアプリでMVCと区分けするのは間違ってる
人によってMVCの解釈がバラバラなのは、そもそもMVCという区分けが不適切だから
MVVMという構造、概念の方が上手くGUIアプリを説明できてる
465デフォルトの名無しさん:2013/09/14(土) 16:50:47.42
>>461
リエンスカウはこの世ではふつうMVC発明者とされている人なんだが
君の世界では違うのか?
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
466デフォルトの名無しさん:2013/09/14(土) 16:58:08.94
オブザーバーパターンで実装しなくてもいいってだけで、

> ビューはモデル(あるいはその一部)に付随し、プレゼンテーションに
> 必要なデータを、モデルに問い合わせることで取得します。
> 同様に、適切なメッセージを送信することでモデルを更新することもあります

ここが重要なところなんだよ。

GUIのMVCではよく出てくるし、よく使われるものだが、
サーバーサイドのMVCにこんなのあるかい?
467デフォルトの名無しさん:2013/09/14(土) 16:59:15.55
サーバーサイドのMVCではビュー=テンプレートなわけだが、
テンプレートから、モデルに問い合わせたり、
モデルにメッセージを送信すると言ってるわけだ。

ぜんぜん違うだろう?
468デフォルトの名無しさん:2013/09/14(土) 17:01:28.37
じゃあオブザーバーパターンがMVCの本質っていうのは撤回するんだな?
469デフォルトの名無しさん:2013/09/14(土) 17:02:44.46
撤回するまでもない
470デフォルトの名無しさん:2013/09/14(土) 17:06:08.94
インタラクティブ性とMVCとは直交する概念
そうあればベターというだけ
ましてオブザーバーが本質なんてのはたんなる思い込み
471デフォルトの名無しさん:2013/09/14(土) 17:06:39.85
>>468
MVCはシステム全体の設計の話。
オブザーバーはシステムを作るときに適用するパターン

撤回するとしたらオブザーバーパターンでなくてもいいが
オブザーバーパターンで実装するような設計になっているもの
と言い直すだけだな。

だから言い方が変わっただけ、MVCの本質は「複数のビューが
一つのモデルに紐付いていてビューがモデルを更新し、
またモデルの更新を全てのビューが検知し表示を変えること」


えーとさ、長い説明に、わかり易い名前を付けないかい?w
472デフォルトの名無しさん:2013/09/14(土) 17:09:48.52
ウェブのMVCは誰でもやってる当たり前の事を言ってるに過ぎないけど、そういう当然の開発手法に名前を付けて知識共有するのがデザインパターンの役割だから
ウェブは必ずHTTPリクエストを受けてクエリパラメータを取得する所から始まる、そこからビジネス処理の実行をキックする
これはまさにコントローラと呼ぶにふさわしい
473デフォルトの名無しさん:2013/09/14(土) 17:19:26.06
>>471

> だから言い方が変わっただけ、MVCの本質は「複数のビューが
> 一つのモデルに紐付いていてビューがモデルを更新し、
> またモデルの更新を全てのビューが検知し表示を変えること」

これはオブザーバーの説明をしただけだろ、だったらMVCなんて言わずにオブザーバーと言えばいい

つうか、「システム全体の設計」とか「システムを作るとき」とかまた訳の分からない概念を持ち込むなよ
MVCは「思想」で、古典的(Smalltalk)MVCは「実装」
474デフォルトの名無しさん:2013/09/14(土) 17:24:40.22
>>471
だから、インタラクティブ性とMVCは直交するって何度言ったら。
やたら思い込みの激しい奴だなぁ……
475デフォルトの名無しさん:2013/09/14(土) 17:26:17.99
ブロードキャストはおまけって意味が分からないのかな。
476デフォルトの名無しさん:2013/09/14(土) 17:28:54.19
パターンに当てはまらないと元の定義もねじ曲げるとか
デザパタ厨はこれだから困る
477デフォルトの名無しさん:2013/09/14(土) 18:10:53.08
このスレでデザパタについて語って意味あるの?
動的言語のコミュニティがデザパタ使ってたなんて知らなんだ
478デフォルトの名無しさん:2013/09/14(土) 18:34:38.11
デザパタをとりあげる意味はあるだろう。
言語によっては不要なパターンがあるとか言語のパワフルさやバトル要素になる。
ただMVCはデザパタじゃないし、オブザーバーが本質というわけでもないので
一連の話題はスレチ
479デフォルトの名無しさん:2013/09/14(土) 18:35:04.18
>>473
MVCはMとVとCの話。

オブザーバーはMとVの関係のこと

違い理解できたよね? OK?
480デフォルトの名無しさん:2013/09/14(土) 18:36:12.93
競争原理と知識共有は矛盾している
481デフォルトの名無しさん:2013/09/14(土) 18:37:22.93
MVCはその一部にオブザーバーパターン(を使うことが多い)で実装するが
MVCはオブザーバーパターンそのものじゃないよ。
482デフォルトの名無しさん:2013/09/14(土) 18:48:07.22
MVCはデザパタじゃなくてアーキテクチャな
デザパタよりなんつうの、もっと広い感じ
483デフォルトの名無しさん:2013/09/14(土) 18:49:38.04
>>479
481も言っているようにオブザーバーが使われることが多いというだけで、直接は関係ないよ

例えばオブザーバー(通知)を使わずに、ポーリングで毎回モデルをチェックするような実装も考えられるけど
これもMVCには違いない
これは変化が多いゲームなんかでよく使われる手法

それから、オブザーバーが適用されるのはMとVだけとも限らない
飽くまで、古典的(Smalltalk)MVCの実装においてはMとVだけど、(MVCの一種である)MVPパターンでは
MとP(MVCでいうC)にオブザーバーが適用される
484デフォルトの名無しさん:2013/09/14(土) 18:56:25.24
ポーリングでもなんでもいいんだけど
ビューからモデルを更新しなければならない。
それがMVCだからね。

ウェブのMVCはビューを表示して終わり。
485デフォルトの名無しさん:2013/09/14(土) 19:09:47.99
ビューからモデルを更新とか何を言っているんだか…

なんでこうも自分勝手な定義がぽんぽんと出てくるかねぇ
486デフォルトの名無しさん:2013/09/14(土) 19:18:23.05
>>483
MVPにもポーテルら(Taligent OS)のMVPと、
http://web.archive.org/web/20081209231808/http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
バウワーとマクグラシャン(Dolphin Smalltalk)のMVPがあって
http://web.archive.org/web/20010618142032/http://www.object-arts.com/Papers/TwistingTheTriad.PDF
まず両者は同じMVPを名乗っていても(後者に至っては前者を引用しつつも)別物であって、
さらに、ファウラーなどが取り上げて一般によく知られているのは後者なので
「MVPのPがMVCのC」というのは(前者に限定するのでもなければ)誤解を招くと思う。
ちなみにMVCのCはMVPではVに含まれていて、MVCにはPにそのまま対応するものはない。
487デフォルトの名無しさん:2013/09/14(土) 19:21:39.96
>>485

古典かはともかく、発案者みずからが語る MVC は押さえておきたい

モデル・ビュー・コントローラ - Trygve Reenskaug
http://d.hatena.ne.jp/digitalsoul/20100913/1284330448

> ビューはモデル(あるいはその一部)に付随し、プレゼンテーションに
> 必要なデータを、モデルに問い合わせることで取得します。
> 同様に、適切なメッセージを送信することでモデルを更新することもあります
488デフォルトの名無しさん:2013/09/14(土) 19:39:43.36
>>487
「ビューはマウス操作やキーボード操作のようなユーザからの入力について
知っているべきではありません」とあるし、ユーザ入力を引き受けるのは
たぶんコントローラなんだよな
ならビューからのモデル更新のトリガって何なんだ?
上の説明からすると、ユーザ入力じゃないんだろ

ビューからのモデル更新っていうと、Tclや.NETみたいに
モデルとビューの入力/表示領域がbindされていて自動的にビューとモデルのデータが
やりとりされる状況をさしているのかと思ったが、どうもそのコントローラの
説明だと違うようだな
489デフォルトの名無しさん:2013/09/14(土) 19:45:16.31
>>488
結論出てるんじゃねーの?

ユーザー入力はビューじゃなくて
ビューからモデルを更新するならば、

ユーザー入力 → コントローラ → ビュー → モデル

だろう?
490489:2013/09/14(土) 19:47:22.42
この図が全てを表してるよ。
http://heim.ifi.uio.no/~trygver/themes/mvc/MVC-2006.gif
491デフォルトの名無しさん:2013/09/14(土) 19:53:42.98
>>487は少なくとも現在の一般的な(例えばwikipediaの)MVCとは違うね

で、こういうふうに様々な実装があるからMVCは「思想」なんだよ
>>484のように特定の実装のみをMVCと考えるべきではない
492デフォルトの名無しさん:2013/09/14(土) 19:55:34.66
>>489
なるほどね

でもWeb以前のMVCってゲームの世界ぐらいでしか見たことないかも
MFCみたいな化石ですら「ドキュメントビュー」とかいうアーキテクチャを
使っていて、ユーザ入力を一手に引き受ける「コントローラ」はなくて
あったのはビュー毎の「イベントハンドラ」
旧VBとかDelphiとかも含め昔からGUIツールキット的なものは全部そうだったと思う
493デフォルトの名無しさん:2013/09/14(土) 19:57:15.49
wikipediaのMVCってこれだろ?

http://ja.wikipedia.org/wiki/Model_View_Controller
http://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/ModelViewControllerDiagram2.svg/350px-ModelViewControllerDiagram2.svg.png
> Model-View-Controller 概念図。
> 直線は直接的なAssociationを表し、破線は (例えば)Observer パターンを経た間接的なAssociationを表す。

括弧で囲ってないかだけで同じじゃん?
494デフォルトの名無しさん:2013/09/14(土) 19:58:21.12
>>492
> でもWeb以前のMVCってゲームの世界ぐらいでしか見たことないかも

最近の人だねw

1995年より前はウェブ自体あまりみなかった。

その頃何を使っていたと思ってるんだ?
495デフォルトの名無しさん:2013/09/14(土) 20:00:12.68
>>494
うんWindowsが無かったころのことは知らない
Windows以降はもうコントローラがなくなってたよね
ゲームプログラミング以外では
496デフォルトの名無しさん:2013/09/14(土) 20:03:01.77
>>493
それは記事も読んでの感想?

あとenの方が分かりやすい
497デフォルトの名無しさん:2013/09/14(土) 20:10:11.06
余談だけどenの方には
Trygve Reenskaug introduced MVC into Smalltalk-76 while visiting Xerox Parc, in the 1970s
ってちゃんと書いてあるね。>>461みたいな誤解も生じにくい。
498デフォルトの名無しさん:2013/09/14(土) 21:03:07.27
ん?
enのWikipediaに一言書いてあったらそれが真実になるのか
すごいなー
499デフォルトの名無しさん:2013/09/14(土) 21:16:32.42
>>498
MVCの起源がSmalltalkにあるのは、よく知られた話
ただ、それがSmalltalk-76であったのは(自分は)知らなかったけどな

あと、書籍「ソフトウェアアーキテクチャ: ソフトウェア開発のためのパターン体系」にも、
以下のように記されている:

 MVCを創造し、Smalltalk環境にそれを適用した Trygve Reenskaug に感謝する。

ネットだけでなく本も読まないと、いつまでも子供のままで成長しないよ
500デフォルトの名無しさん:2013/09/14(土) 21:33:38.10
現在の視点で見れば、OSモドキのショボ環境にモダンとは程遠いゴミ構文のSmalltalkだけど
かつては最先端だったんだよ。それは認めなきゃ。
501デフォルトの名無しさん:2013/09/14(土) 21:38:18.43
>>498
>>497の部分は
^ Notes and Historical documents from Trygve Reenskaug, inventor of MVC.
^ "A note on DynaBook requirements", Trygve Reenskaug, 22 March 1979, SysReq.pdf.
が引用元と書かれているのだから、疑問があるなら読んでみたらどうだろう。
502デフォルトの名無しさん:2013/09/14(土) 21:48:14.65
>>498
逆だ、逆。
ウィキペは知的レベルの低い人間が参考にすることが多いから
通常なら知られている基本的な事実が欠落しているjaみたいな記述だと
>>461みたいな勝手な解釈も生じやすいということ。
こんなこともわからんのかね、ちみは。
503デフォルトの名無しさん:2013/09/14(土) 22:24:01.95
>>500
昔も必ずしも最先端ではなかったけれど、アラン・ケイを筆頭に、少し目先の利く人間が
自分のアイデアが有効かどうかを気軽に実装して実地で試せるプラットフォームではあったね。
現在主流のWIMPなGUIの要素(ポップアップメニュー、マルチフォント、モードレス編集)しかり、
メタオブジェクト、分散オブジェクトしかり、IDEしかり、デザパタしかり、アジャイル手法しかり。
今でもそういうところ完全には失われていなくて、たとえばTraitsや、
RubyのRefinementsの元ネタのClassboxesみたいな機能も最初Smalltalkで試されてるし。

たんに古くからあるとか仕様がショボいとかいうだけの理由で、そう馬鹿にしたものでもない。
504デフォルトの名無しさん:2013/09/14(土) 23:02:11.86
飽きた。なんか面白いお題ないの?
505デフォルトの名無しさん:2013/09/14(土) 23:41:15.28
>>254
継承と言えば、
Rubyには動的言語としては致命的ともいえる
こんなバグみたいな仕様があるんだけど

module M1; end
class C1; include M1 end
module M2; def m2; end end
module M1; include M2 end
#p C1.new.m2 #=> undefined method `m2' (NoMethodError)
class C2; include M1 end
p C2.new.m2 #=> nil

他の多重継承を持つ言語では大丈夫?
506デフォルトの名無しさん:2013/09/15(日) 00:18:44.60
>>505
Gaucheの組み込みのオブジェクトシステムでは問題ない

(define-class <m1> () ())
(define-class <c1> (<m1>) ())
(define-class <m2> () ())
(define-method m2 ((_ <m2>)) "m2")
(define-class <m1> (<m2>) ())
(display (m2 (make <c1>))) ;;=> "m2"
507デフォルトの名無しさん:2013/09/15(日) 00:19:01.86
JSのプロトタイプベースが一番柔軟にクラス定義出来ると思う。
柔軟すぎて、形が違いすぎてもはやクラスじゃないっていう人も多いけど、
こういうことも出来るわけだし。>>256
508デフォルトの名無しさん:2013/09/15(日) 00:35:05.67
実際RubyやJSで多重継承とか複雑なことやるコードなんて書く機会あんの?

C#なら分かるけど
509デフォルトの名無しさん:2013/09/15(日) 00:51:00.10
>>505
それのどこがバグなのかよく分からん。
C2.m2は普通に呼び出せているから問題ないとして、 C1.new.m2が未定義なのがダメなん?
でもそれはm2が定義されているのはincludeしたM1ではなくて、後から定義されたM1だからで、この2つが別物とされてるからじゃね?

仮に後からM1にメソッドを動的に追加してるならともかく、新しく同名のモジュールを定義してるんだったら
その挙動で全く問題無いと思うんだけど。
510デフォルトの名無しさん:2013/09/15(日) 00:53:56.53
例えば今まさにこのスレで話題になってるが、
http://toro.2ch.net/test/read.cgi/hp/1378462421

JSを継承もどきは今までもぐにゃぐにゃとすることができたが、
「クラス」の継承の仕組みが鈍かった為に、
ほぼ配列のくせして配列用のメソッドが使えないというものが、
特にホストオブジェクト、DOM周りに沢山あって少し面倒な事になってる。

機能以前に、Arrayクラスを継承する、みたいな表現文化が無かったことも原因。
511デフォルトの名無しさん:2013/09/15(日) 00:56:22.96
>>505
#p C1.new.m2 #=> undefined method `m2' (NoMethodError)
これが呼び出されるほうが異常に見える
512デフォルトの名無しさん:2013/09/15(日) 00:57:04.27
対話的に使うときには、>>506のようになっているほうがいいと思う。
513デフォルトの名無しさん:2013/09/15(日) 00:58:41.52
>>511
単に>>505が「多重継承 と Mix-in の違い」を理解できていないだけだから、気にすんなw
514デフォルトの名無しさん:2013/09/15(日) 01:02:01.70
>>505
Pythonもダメ

class M1: pass
class C1(M1): pass
class M2:
  def m2(self): return "m2"
class M1(M2): pass
# print( C1().m2() ) #=> AttributeError: 'C1' object has no attribute 'm2'
class C2(M1): pass
print( C2().m2() ) #=> m2

ただPythonの場合、Rubyと違って理由は明らかで、
M2を継承すべく再定義されたM1はC1が継承済みのM1とは別物だから
515デフォルトの名無しさん:2013/09/15(日) 01:05:46.04
>>505
Squeak Smalltalk の Traits では問題ない。

Trait named: #T1 uses: {} category: 'Category-Name'.
Object subclass: #C1
uses: T1
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Category-Name'.
(Trait named: #T2 uses: {} category: 'Category-Name') compile: 'm2 ^#m2'

T1 uses: T2.
C1 new m2 '=> #m2 "
516デフォルトの名無しさん:2013/09/15(日) 01:09:33.16
>>514
Rubyには他に理由あるの?
517デフォルトの名無しさん:2013/09/15(日) 01:11:53.46
includeされた時点で定義されてるメソッドのみがmix-inされてん
518デフォルトの名無しさん:2013/09/15(日) 01:22:17.58
>>516
RubyはPythonと違い、include M2後もM1のobject_idは変わらない
少なくとも見かけ上、include前後でM1は同じオブジェクト

>>517
include M1した後でもM1に新たに定義されたメソッドはC1からコールできる
519デフォルトの名無しさん:2013/09/15(日) 01:22:46.51
>>508
JSはともかくRubyは継承しまくって馬鹿でかい神様クラスを作るのが正しい使い方だ
C#はむしろ直交性を重視するほうだろ
520デフォルトの名無しさん:2013/09/15(日) 01:26:57.29
ほんとだ。
Pythonはともかく、Rubyのこの挙動はひどいな。
521デフォルトの名無しさん:2013/09/15(日) 01:37:41.85
>>509
>この2つが別物とされてるからじゃね?

module M1; end
class C1; include M1 end
module M2; def m2; end end
module M1; include M2 end
# p C1.new.m2 #=> error
class C2; include M1 end
p C1.ancestors #=> [C1, M1, Object, Kernel, BasicObject]
p M1 == C1.ancestors[1] #=> true
522デフォルトの名無しさん:2013/09/15(日) 01:40:52.94
JavaScript(ES6 emu)で試してみたら
>>514と同じ結果になったが詳細は不明

class M1 {}
class C1 extends M1 {}
class M2 { m2(){} }
class M1 extends M2 {}
(new C1).m2 //undefined
class C2 extends M1 {}
(new C2).m2 //m2(){}
523デフォルトの名無しさん:2013/09/15(日) 01:42:20.36
いや、理由も同じか、
2つのM1は別物だ
524デフォルトの名無しさん:2013/09/15(日) 01:45:06.48
Rubyって同名のクラスを何回も定義したら最後の定義が正とはならず
順次最初の定義に追加されていく感じなのか


でもそんな書き方するのが当たり前なのか?
525デフォルトの名無しさん:2013/09/15(日) 01:50:19.97
>>521
最後は p M1.equal?(C1.ancestors[1]) だろ?
それでも true だけどな
526デフォルトの名無しさん:2013/09/15(日) 01:57:07.75
>>524
動的言語というのはそもそもそういうもんだ。
527デフォルトの名無しさん:2013/09/15(日) 01:57:09.86
多重継承とかトレイトとか別にいらんよね
単一継承すら出来るだけ避けてるのに
528デフォルトの名無しさん:2013/09/15(日) 02:03:01.63
>>257みたいなことって他の言語でもできるの???
529デフォルトの名無しさん:2013/09/15(日) 02:03:14.86
>>526
最新10レスぐらいで既に動的言語のPythonやJSでそれは否定されてますが
530デフォルトの名無しさん:2013/09/15(日) 02:13:18.34
>>524
動的言語なら素直に実装したら上書きされて全く別物になるのが自然だと思う
元の定義に追加されるようにするのも意図してやってんなら動的言語としては全然アリだが
そのどちらでもないから問題だって話でしょ
531デフォルトの名無しさん:2013/09/15(日) 02:15:37.77
>>529
ん?
動的言語を標榜するPythonやJSだが、
ことクラスの定義追加については再定義になるという
動的言語っぽくない挙動をしてるって発想は出てこない人?
532デフォルトの名無しさん:2013/09/15(日) 02:20:56.22
>>531
なんでそれが動的言語っぽいのかよく分からん。

動的言語のクラスにあとから何か追加したいんだったら、
class Hage
{
// 何か
}

Hage.Method = 何か
Hage.Member = 何か

と書くのがそれっぽいと思うぞ
わざわざ再定義したのに、既に定義されているクラスが拡張されてない!とか怒るのはRuby脳?
533デフォルトの名無しさん:2013/09/15(日) 02:22:01.84
>>531
自分で動的言語の処理系作ってみりゃわかるが、上書きで別物になるのは自然
追加の方が意図してわざわざそうなるように実装してる
534デフォルトの名無しさん:2013/09/15(日) 02:27:22.97
関数定義との一貫性から、クラス定義も
Hoge = class {...}
と考えるのが動的言語脳(≠Ruby脳)だろう
当然これなら上書きになるわな
535デフォルトの名無しさん:2013/09/15(日) 03:04:26.21
せやね
536デフォルトの名無しさん:2013/09/15(日) 03:55:12.01
言われればたしかにそれで自然だし、だから上書きでもいいと思うけれど、
ただ、オブジェクトの動的運用という面からは、クラスを再定義したら、
少なくとも名前が変わらず同じである以上、
再定義前に作ったインスタンスもサブインスタンスもすべて
その再定義後の定義に従って欲しいし、そうでないとじっさい使い物にならない。
537デフォルトの名無しさん:2013/09/15(日) 05:02:47.27
moduleとかclassとかやめて
全部Module.newとClass.newで書けば一貫性が出てくるんじゃね?
538デフォルトの名無しさん:2013/09/15(日) 05:04:47.99
つまり、こんなん↓が出来るのは動的言語でも少数派なのかっ!

CLISP http://ideone.com/kPL4pY

(defclass b () ())
(defmethod m1 ((_ b)) "m1")
(defclass c (b) ())
(setf obj (make-instance 'c))
(format t "~A~%" (m1 obj)) ;;=> m1

(defclass a () ())
(defclass b (a) ())
(defmethod m2 ((_ a)) "m2")
(format t "~A~%" (m1 obj)) ;;=> m1
(format t "~A~%" (m2 obj)) ;;=> m2


GNU Smalltalk http://ideone.com/jg91Qo

Object subclass: B [m1 [^#m1]].
B subclass: C [].
obj := C new.
obj m1 printNl. "=> #m1 "

Object subclass: A [].
A subclass: B [].
A extend [m2 [^#m2]].
obj m1 printNl. "=> #m1 "
obj m2 printNl. "=> #m2 "
539デフォルトの名無しさん:2013/09/15(日) 05:19:46.10
Rubyだとスーパークラスのすげ替えのところでエラーになる。

class B; def m1; "m1" end end
class C < B; end
obj = C.new
print obj.m1, "\n" #=> m1

class A; end
# class B < A; end #=> superclass mismatch for class B (TypeError)
class A; def m2; "m2" end end
print obj.m1, "\n" #=> m1
# print obj.m2, "\n" #=> undefined method `m2' for obj (NoMethodError)
540デフォルトの名無しさん:2013/09/15(日) 09:29:19.69
上書きだと単なるグローバル変数だから
グローバル変数に強く反対する言語では、ただの上書きではない機能を付けておかないと
辻褄が合わなくなる
541デフォルトの名無しさん:2013/09/15(日) 10:37:32.79
いやグローバルがどうというより
処理系が実行時の状態に依存し過ぎてるだけな気が
542デフォルトの名無しさん:2013/09/15(日) 10:52:09.17
「グローバル変数に強く反対」したのは実行時ではないよ
その思想に依存した結果、辻褄を合わせるのに苦労している
543デフォルトの名無しさん:2013/09/15(日) 11:14:45.76
グローバルよりも大きいスコープの
見えない何かが絡んでる状態なわけだけど、それでいいの?
544デフォルトの名無しさん:2013/09/15(日) 11:57:47.76
>>539
Rubyって動的言語なのにスーパークラスのすげ替えも出来ないの?
545税金を食いつぶす在日:2013/09/15(日) 12:28:22.92
在日への生活保護 役人発表では800億円(韓国・北朝鮮籍) 
※しかし川崎市と大阪市の異常過多分だけでもこの数字は軽く超えており、
 本当の数字はタブー。個人的には1兆円は超えていると推測。
(帰化朝鮮人や、それによる不正受給を含めて)
※民主党政権の3年間だけでも0.9兆円増

オリンピック招致(決定までの費用) 70億円 予測経済効果3兆円超
IPS細胞関連研究予算   平24年度民主党政権時 45億円 
              平25年度自民党政権時 90億円
がんワクチン研究予算  13億円(平成24年度)
※米国では莫大な国家予算を注ぎ込んでいる。 by NHK
がん関連予算全体では、日本の約20倍。
そのため、日本のがん研究の権威は、日本に見切りをつけて米国へ
日本の製薬会社は投資リスクを恐れて、新薬開発に躊躇しているそうです。

誰が在日の生活保護を拡充させ、国の成長分野への予算投入に
反対してきたか? もう想像つきますよね?
ポイントは公明党(与党にくっついてる野党)

民主党は、パナソニックやシャープ、ソニーを潰す気だった?
http://www.youtube.com/watch?v=iG_oaqU0pEM

帰化朝鮮人ばかりが政治家を目指す国?日本
https://www.youtube.com/watch?v=JVhHeMqNPHY
546税金を食いつぶす在日:2013/09/15(日) 13:12:40.76
そもそも、日本に借金をこさえさせたのは小沢一郎(たぶん在日帰化)。

小沢が430兆円
村山(旧社会党:こいつも在日帰化?)内閣がプラス200兆円 
トータル630兆円
(詳しくは日米構造協議で検索)

今ある借金は、これとその利息では?

小沢は、自民党時代に日本に爆弾を抱えさせた上に、そのバラマキ公共投資で得た
支持基盤をごっそり自民党から引き抜き(仲間を引き連れ離党)、
自民を単独過半数割れに追い込んだ。
そして、第3極政党(新進党→公明党)を介入させ、韓国や在日へ利益誘導してきた。
※自民党以外の議員は、日本姓を名乗る在日帰化か、その影響下にあると仮定。

という流れではないでしょうか。
547デフォルトの名無しさん:2013/09/15(日) 13:13:14.14
荒れたスレにナゲット再び

 〃. ̄. ̄.ヽ
 |: : : |
 | : : :|
  ヽ._._./

http://monobook.org/wiki/NuGet
548デフォルトの名無しさん:2013/09/15(日) 14:47:20.66
>>538
JS

class B { m1(){} }
class C extends B {}
obj = new C
obj.m1 // m1(){}

class A {}
B.prototype.__proto__ = A.prototype
A.prototype.m2 = ()=>{}

obj.m1 // m1(){}
obj.m2 // (){}
549デフォルトの名無しさん:2013/09/15(日) 16:46:26.70
プロトタイプベースってJavaScriptしかないの?
550デフォルトの名無しさん:2013/09/15(日) 16:48:40.73
>>549
著名どころでは、SELF や NewtonScript があった
551デフォルトの名無しさん:2013/09/15(日) 17:01:54.04
一昔前だとSelf、それを参考にしてJavaScriptができたって事だね
552デフォルトの名無しさん:2013/09/15(日) 17:26:01.48
Prothonってどうなのよ?
553デフォルトの名無しさん:2013/09/15(日) 20:52:35.32
どうとは?
554デフォルトの名無しさん:2013/09/15(日) 20:57:02.95
Prothonとかの言語がJSに続いてプロトタイプベースの波を起こせなかったのは何故だろう?
最近出る言語もクラスベースなのはなんでかな?
555デフォルトの名無しさん:2013/09/15(日) 21:21:58.60
なぜだろってJSで事足りちゃうならそっち使うだろ
資産もあってブラウザで動くなんて手軽すぎる言語に簡単には敵わないよ
556デフォルトの名無しさん:2013/09/15(日) 21:25:31.81
つまりプロトタイプベースが活躍できる範囲はJSで十分ってこと?
557デフォルトの名無しさん:2013/09/15(日) 21:34:13.99
ぶれないプロトタイプベースと、方言が多すぎるクラスベース
558デフォルトの名無しさん:2013/09/15(日) 22:19:16.71
簡単に言えば
あえて制約を付けたり型にハメるのを良しと思うのがクラスベースだからね
それと実装の問題もある

最近出来た言語がプロトタイプベースを取り入れないのは最適化に熱心だから
例えばDartとか
559デフォルトの名無しさん:2013/09/15(日) 22:41:09.02
Luaはプロトタイプベースだろ
10年後にはRubyを越えて普及してそうな言語
560デフォルトの名無しさん:2013/09/15(日) 22:43:21.65
ないない
561デフォルトの名無しさん:2013/09/15(日) 22:44:36.69
Luaがどう躍進するかより、
Rubyがどう廃れていくかが楽しみ
562デフォルトの名無しさん:2013/09/15(日) 22:55:42.90
そんなこと言ってるけど他の言語は今後10年廃れない目処あるの?
563デフォルトの名無しさん:2013/09/15(日) 22:57:18.22
Rubyは廃れていくだろうけど・・・

C++
Java
PHP

あたりも間違いなく廃れていくからなあ
C#、JS、Python、Objective-Cはこれからもシェア伸ばしていくだろうけど
Rubyは現時点で既にこれらの言語にぬかれてるわけで
相対的な地位は変わらないんじゃないかなあ
564デフォルトの名無しさん:2013/09/15(日) 22:57:41.44
>>549
停滞気味だけど Io がある。
http://iolanguage.org/

いちじき話題だった「7つの言語 7つの世界」にも
Ruby、Prolog、Scala、Erlang、Clojure、Haskellとともに取り上げられた。
http://www.amazon.co.jp/dp/4274068579
565デフォルトの名無しさん:2013/09/15(日) 22:59:19.30
COBOLみればわかるけど、
お金が大きく絡んでる言語は
廃れないよ。
566デフォルトの名無しさん:2013/09/15(日) 23:02:35.95
廃れやすさってのは、どれだけの
会社や人間がサポートしているかによる。

例えば特定の会社しか作ってないような言語は
その会社がやめればすぐに廃れる。
やめなくてもその会社自体が縮小すれば廃れる。

旧VBとかDelphi言語とか


逆に複数の会社が作っていたり、
標準規格が出来てしまってるようなものは廃れない。
567デフォルトの名無しさん:2013/09/15(日) 23:03:10.04
COBOLくらいだと廃れてるって言われると思うけどな
しんでないだけで
568デフォルトの名無しさん:2013/09/15(日) 23:06:20.66
C#…3.0と4.0で他言語をパクリ尽くして5.0ではパクるものが枯渇。6.0は出るか分からない。Mono次第。
Objective-C…万人が認める糞言語で、iOSの需要が高いから仕方なく使われてるだけ。代替品が出たらすぐ消える。
JS…各ブラウザ(主にIE)間の合意を取らないと拡張できないため、いつまでも予約されたクラスの出番なし。



Python最強
569デフォルトの名無しさん:2013/09/15(日) 23:07:08.06
C++、Java、JSは有名で
よく使われてる実装が複数あるね。

他の言語は知らない。
570デフォルトの名無しさん:2013/09/15(日) 23:08:23.05
>>568
> JS…各ブラウザ(主にIE)間の合意を取らないと拡張できないため、いつまでも予約されたクラスの出番なし。

え? IEの合意なんかとらずに
どんどん拡張されてると思うけど、
ちゃんと現実を受け止めてるかい?w
571デフォルトの名無しさん:2013/09/15(日) 23:11:53.68
>>570
Mozillaが勝手にどんどんやってるだけだね
GoogleもMSも無視してる
572デフォルトの名無しさん:2013/09/15(日) 23:12:05.65
>>563
C++はあいかわらず堅調でしょう。
Javaは代替が現われないかぎり安泰。
PHPは嫌われつつもこれまでの貯金であるメンテ案件でしぶとく生き残るんじゃない?
いずれにせよ分相応の評価を得ている言語達なので10年やそこらで
どうこうなることもないでしょう。

ひるがえってRubyはいっっときのRailsバブルで実力にそぐわない
過大評価を得てしまったからここからが踏ん張りどころ。
ただ本スレや公式MLの急激な過疎化をみるとこの崩壊を食い止めるのは難しいと思う。
Rails案件も軒並み炎上しているし、悪評は一気に広まりつつある。
1.9への移行がかなりのブレーキになってたのに、mrubyにリソースが分散されたのも痛い。
573デフォルトの名無しさん:2013/09/15(日) 23:16:06.68
>>571
Mozillaが勝手にやってる?
そうか君は知っているのだな。

なら言ってみなさい。
Mozillaが勝手にやっている拡張とは
どの事だね?
574デフォルトの名無しさん:2013/09/15(日) 23:16:11.44
> Rails案件も軒並み炎上しているし、悪評は一気に広まりつつある。
ソースプリーズ
575デフォルトの名無しさん:2013/09/15(日) 23:17:30.98
>>573
俺Chomeユーザーなんだけど、確かJS1.5もしくは1.6以降は実装されてなくね?
FFにはあるけど他のブラウザにはないメソッドとかよくあるじゃん。
576デフォルトの名無しさん:2013/09/15(日) 23:19:42.89
>>575
それが何なのか聞いているんだよ。

それはHTML5の標準メソッドだろう?

ならChromeも追尾するだろう。
IEも追尾するだろう。

ほら見ろこのようにどんどん拡張されてるじゃないか。
577デフォルトの名無しさん:2013/09/15(日) 23:21:21.64
>>568
ECMAはブラウザとは繋がってないよ
今あるWebコンテンツを壊さないっていうのは意識してるけど
新しい機能の導入には貪欲的だよ

エンジンのことも考えるけど、V8とSMがほぼ半分ずつで
フィードバックと最適化について、だからそれが遅れてるChakraは発言力無い

発言力としてはGoogleとMozillaがほぼ半分ずつで、
MSはMathの拡張とか周辺機能には意見良く出してるけど基本構文は受け入れてる

class構文についても今となっては導入する方向で一致してる
仕様が結構大きくて、いろんな部分と絡んでるから実装は遅めになるかもだけど
それでも1年以内にChromeとFirefoxにほぼ完全に実装されるはず
578デフォルトの名無しさん:2013/09/15(日) 23:22:23.73
>>576
ttp://kangax.github.io/es5-compat-table/es6/
こういう感じのことじゃね?
579デフォルトの名無しさん:2013/09/15(日) 23:23:46.03
一人が決めるんじゃなくて
多くの関連者が議論して決めているものでは
JavaScriptは一番規模が大きくて
一番発展が早いものなのかもしれないな。
580デフォルトの名無しさん:2013/09/15(日) 23:23:54.64
Mozillaが勝手にやってるとはまたアホなことを
Mozillaが先陣切ってやってくれなかったらES6の仕様策定が何年も遅れたか縮小したことだろう
Mozillaはそういう役目なのよ
581デフォルトの名無しさん:2013/09/15(日) 23:24:47.07
>>578
それを見ればわかるじゃないか
IEもChromeも無視なんかしておらず
バージョンが上がるとサポートされてる。
582デフォルトの名無しさん:2013/09/15(日) 23:25:04.50
Python以外はスレタイにあるのは全部枯れてるな
生き残るのはPython JavaScript Objective-C Lisp Smalltalk
583デフォルトの名無しさん:2013/09/15(日) 23:25:32.53
>>574
ソースって程のものはないけれど、
知り合いのそこそこのスキルのあるPGの多くが
ここのところ連続でRailsの炎上案件の火消しに投入されて
のきなみ疲弊しているのをみてる
584デフォルトの名無しさん:2013/09/15(日) 23:25:35.85
Mozillaからしたら元々自分たちの言語だしなあ
そりゃ先陣切っていきたいだろ
585デフォルトの名無しさん:2013/09/15(日) 23:26:13.87
>>581
しかし動きは相当遅い
全ブラウザで使えるようになるのはいつになることやら
586デフォルトの名無しさん:2013/09/15(日) 23:28:47.60
>>583
俺の知り合いはJavaやPHPで地獄を見続けてるんだが…
実は業界の問題であって、言語の問題じゃないんじゃね?
587デフォルトの名無しさん:2013/09/15(日) 23:28:49.30
MozillaはJSの人柱だから、今も昔も、
山ほど失敗してるが山ほど貢献してる。

Googleもプロトコルの人柱やってWebに貢献してるでしょ?
OperaグループもいろんなAPIや規格に貢献してる。

最近は仕様に文句つけるんじゃなくて、
自分のできるとこやって貢献し合いましょうという雰囲気になってる。
だからES4の時のように荒れることはなく、皆凄く協力的でいい感じ。
588デフォルトの名無しさん:2013/09/15(日) 23:29:35.65
>>582
Pythonはいい言語なんだけど、
LispのS式の柔軟性やSmalltalkの動的性ほどは
「これ」ってウリがないのが残念
589デフォルトの名無しさん:2013/09/15(日) 23:31:51.21
守りにまわっちゃって「ウリ」をいろいろと諦めているのに
肝心の守りのほうも守り切れてない感じ。>Python
590デフォルトの名無しさん:2013/09/15(日) 23:33:15.79
Mozillaが実装しているのは、それが新しい仕様を
作成するための条件の一つだからだよ。
勝手に実装しているのとはわけが違う。

http://www.html5.jp/trans/whatwg_html5faq.html
> 実装者に、その機能を実装することをコミットしてもらってください。
> もしあなたが複数の実装者にその機能を実装してもらうことができないなら、
> 実験的に最低でも一つのユーザーエージェントに実装してもらうようにしてください。
> 実験的な実装は、公式に利用可能でなければいけません。


JavaScriptの世界は皆が議論して、仕様を決めてから実装するような世界じゃない。
まず誰かが実装する(それがMozillaが多い)
最初の一人が実装した時、その他が実装してないのはあたりまえじゃないか。

MSのスタンスとしては、標準になったものを実装するという考え。
だから、Mozilla、Chrome、標準化、MS という流れになるのが多いだけの話。

で、そもそもなんだっけ?
JavaScriptの世界は常に拡張され続けているってことでよかったかい?
591デフォルトの名無しさん:2013/09/15(日) 23:34:46.14
>>585
Chrome31で見ると29より何個も緑増えてるよ
着実に進んでる

ただV8は仕様変更がありそうなものはおいそれと実装したくない
本格的に実装が始まるのはラストコールが出てからだろうね

でも下準備はしてるよ、ES6で究極に重要なSymbolsの実装は早々に済ませてるし
いくつかの仕様も実装進めてる
最近だと配列内包にGOが出た
592デフォルトの名無しさん:2013/09/15(日) 23:35:23.91
Railsの案件ってどういう炎上すんだ?

Ruby1.8系からRuby1.9系に移行したり、Rails2系からRails3系に移行させるなら死人が出るかもしれんが・・・
正直、Railsで作ったものは保守しにくいとか拡張しにくいとかそういうのは全くないわ

ただし、Railsは無駄にRails固有の知識が必要だから、未経験者にいきなり就かせて
生SQLではなくてActiveRecord書けとか命じたら困るな
593デフォルトの名無しさん:2013/09/15(日) 23:37:08.71
>>590
いやいや、ES4の頃一旦棚上げ(没)になった皆が議論した仕様を入れてるだけだよ
594デフォルトの名無しさん:2013/09/15(日) 23:38:46.72
配列内包はfor-ofとは絡んでるけど、単独機能だから実装はしやすいでしょうね。
595デフォルトの名無しさん:2013/09/15(日) 23:39:41.82
>>593
だから?

ES4で議論された機能が復活する。
それもまた拡張の一つの形だということかい?
596デフォルトの名無しさん:2013/09/15(日) 23:41:20.55
>>592
ヒント:Java土方がRails使わなくちゃいけない案件どうなるか
597デフォルトの名無しさん:2013/09/15(日) 23:41:43.12
3大勢力が実装していて
競争状態に見えるぐらいになってる言語は
JavaScriptぐらいしかないよね?

その他はこじんまりとした
個人プロジェクト+取り巻きに近い。
598デフォルトの名無しさん:2013/09/15(日) 23:42:24.05
>596
Railsは凄いんです。
だからどんな人でもRails使った途端
ハゲが直り恋人もできます。
599デフォルトの名無しさん:2013/09/15(日) 23:42:48.29
>>595
>JavaScriptの世界は皆が議論して、仕様を決めてから実装するような世界じゃない
ここの部分が語弊があるということ。
600デフォルトの名無しさん:2013/09/15(日) 23:44:14.60
>>599
語弊があるというのなら、お前は今拡張されている
機能(上で出ていたES6の機能)が
全てES4で棚上げされた機能だと証明する必要があります。

はい、やってください。
601デフォルトの名無しさん:2013/09/15(日) 23:44:16.18
>>597
今は仕様についてはそんなに競争してないな
DOMAPIまで入れるといまだ苛烈だけど
602デフォルトの名無しさん:2013/09/15(日) 23:46:48.62
>>600
いいよもう。
喧嘩腰嫌いだわ。
603デフォルトの名無しさん:2013/09/15(日) 23:48:52.93
自分の意見こそが絶対じゃ楽しくお喋りできないね
604デフォルトの名無しさん:2013/09/15(日) 23:49:14.82
>>602
なら最初から参加しなければいいのに。
605デフォルトの名無しさん:2013/09/15(日) 23:49:23.81
>>597
それがいいことなのかそうでないのか、微妙なとこではあるけどね
実装技術は進むが、新規仕様策定で揉めることにもなるわけで
606デフォルトの名無しさん:2013/09/15(日) 23:51:52.75
>>605
JavaScriptは、今まで進まなかった時代を経験しているので、
今の驚異的なスピードは正しいことの証拠だと思ってる。
607デフォルトの名無しさん:2013/09/15(日) 23:54:15.20
>>572
>>Rails案件も軒並み炎上しているし、

ビジネスシーンでは採用されないWebフレームワークには、縁遠い話だねw


>1.9への移行がかなりのブレーキになってたのに、

ブレーキどころか、1.8は予定されていたスケジュールで公式に役目を終えた
・Ruby 1.8.7 は引退しました
  https://www.ruby-lang.org/ja/news/2013/06/30/we-retire-1-8-7/
そして、(YARV実装という)実験的性格の強かった1.9を飛び越えて、今は2.0へジャンプしつつある

1.9/2.0移行で難儀というか迷走したのは、多言語コード関連くらいではないかな?
他にはイテレータ機能強化で、一部メソッドの挙動が変更されたのもあったか....
とはいえ、結局、いろいろと(第三者が必死に)煽っていたのに反して、移行はスムーズに終えたね
それだけ1.8から1.9/2.0へは、わずかな仕様追加はあっても、仕様の変更/切り捨てがほとんど無かった、
つまり言語としての設計思想に大きなブレが無かったことを実証している

実際、自分が1.8で開発していた10数キロステップの実用アプリの移行も、
通常の用途では無修正、細部であっても一ヶ所の変更だけで済んだ
これには1.8で内蔵されていた移植性検査オプションを最初から活用していた点も大きいがね

このRubyの移行劇は、旧バージョンとの互換性を無視した新バージョンを開発し、
そのあげくに数年前に開発を終えた旧バージョンを未だに切り捨てられないどこかの言語とは対照的
608デフォルトの名無しさん:2013/09/15(日) 23:54:54.33
>>602
負け犬はもう出てくんなよ〜w
609デフォルトの名無しさん:2013/09/15(日) 23:55:11.69
>>607
うん、それ規模が小さいからできることだよ。
610デフォルトの名無しさん:2013/09/15(日) 23:55:26.30
> このRubyの移行劇は、旧バージョンとの互換性を無視した新バージョンを開発し、
> そのあげくに数年前に開発を終えた旧バージョンを未だに切り捨てられないどこかの言語とは対照的
Pythonのことですね、分かります
611デフォルトの名無しさん:2013/09/15(日) 23:58:06.91
うーん、やっぱり旧バージョンを切り捨てるって凄く困難なことなんだね
612デフォルトの名無しさん:2013/09/15(日) 23:58:24.37
このRuby厨の必死さがRubyの先行きの暗さを物語っている
613デフォルトの名無しさん:2013/09/15(日) 23:59:47.50
>>611
旧バージョンを切り捨てないほうがすごく困難だと思うけど?
614デフォルトの名無しさん:2013/09/15(日) 23:59:59.81
>>612
いやいや、アンチRuby厨の必死さには負けますわよw
615デフォルトの名無しさん:2013/09/16(月) 00:00:30.03
Rubyの恐ろしさは、単に今までの文法が廃止とかそういうレベルじゃないぞ。
それこそマイナーバージョンが一つ違うだけでgemがコケるじゃん。
616デフォルトの名無しさん:2013/09/16(月) 00:01:25.07
>>613
だから、後方互換性を意識した仕様変更を考えるんだよね、普通の言語は....
617デフォルトの名無しさん:2013/09/16(月) 00:02:31.44
>>615
こけるgemもあれば、こけぬgemもある
618デフォルトの名無しさん:2013/09/16(月) 00:02:59.27
>>616
未来は誰にも予測できないんだよ。

後方互換性を維持するのが難しい時ってのは
絶対にやってくる。Rubyもあったじゃないか。

後方互換性を維持するのが難しいと思った時、
諦めるのと、諦めないの、どっちが困難だと思いますか?
619デフォルトの名無しさん:2013/09/16(月) 00:03:37.01
Matzは内心ドカタ嫌ってるんだろうなあ
Rubyはそのうちコアの言語オタ連中放置してドカタ方面へフォークすると思う
620デフォルトの名無しさん:2013/09/16(月) 00:04:14.33
>>617
先生、MySQLアダプターがコケる場合はどうすればいいんですか。
RDBを変えればいいんですか
621デフォルトの名無しさん:2013/09/16(月) 00:04:49.94
>>628
諦めろ。それが一番(開発者が)楽な道だw
622デフォルトの名無しさん:2013/09/16(月) 00:05:18.34
>>615
いやあ、普通は「今までの文法が廃止」のほうが恐ろしいだろ
それこそ、単なるサードパーティ製のパッケージのバグとはレベルが違う影響度だよ
623デフォルトの名無しさん:2013/09/16(月) 00:05:22.39
>>628じゃなくて>>620だった。
624デフォルトの名無しさん:2013/09/16(月) 00:05:33.46
互換性を切り捨てるのは(作業的に)簡単だけど、(しがらみ的に)困難だよ
625デフォルトの名無しさん:2013/09/16(月) 00:05:40.69
JSみたいに後方互換性を維持するしか選択肢がない言語もある
626デフォルトの名無しさん:2013/09/16(月) 00:06:40.63
>>624
つまりRubyの世界では、しがらみ(互換性)を
何も考えないから簡単なわけですね?
627デフォルトの名無しさん:2013/09/16(月) 00:06:51.32
>>618
仮定を元にした予測に答える価値は無いな

例:
 明日、世界が破滅します
 諦めるのと、諦めないの、どっちが困難だと思いますか?
628デフォルトの名無しさん:2013/09/16(月) 00:07:52.31
>>625
いや、今のJSの世界知ってるかい?
全く違う言語からJSに変換することで
互換性が全くない言語すらできてるんだよ。
629デフォルトの名無しさん:2013/09/16(月) 00:09:26.59
>>627
仮定を元にした発言はしないという
言葉は聞いたことがないが、

仮定を元にした予測ってなんだよw
予測は全て仮定だろ?

どやセリフでも言ったつもり?
630デフォルトの名無しさん:2013/09/16(月) 00:09:43.85
それは変換後のJSに互換性があればいいじゃないの?
631デフォルトの名無しさん:2013/09/16(月) 00:10:11.74
これを見た時、後方互換性の問題なんて
本当はアイディアしだいでかなりどうにでもなるんじゃないかと希望が湧いた
こういう問題の根底の部分まで解決し、さらに世界を広げるようなアイディアを出してみたい

https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-23.md#43-arrayprototypevalues
配列の新しいメソッドが、実際のあるwith構文を使ったライブラリに影響を与えるという問題
632デフォルトの名無しさん:2013/09/16(月) 00:10:54.09
Rubyが駄目なのは後方互換性を放棄しているからじゃない。
他の言語もそういうことやっているし、今ではみんなが使っているjQueryもそうだ。

他の言語の場合、例えば「バージョンアップに伴い****というメソッドが廃止されました」というアナウンスがされた場合、
その****を別の代替メソッドに変えれば済む。
ところがRubyの場合、****とは全く関係ないクラスライブリ群が大量にエラーを吐く。

そう、Rubyは実装がどうしようもないのだ。
C言語で書かれたRubyをJavaどころかPythonで書きなおしたら速くなったという事例すらある。
633デフォルトの名無しさん:2013/09/16(月) 00:10:57.99
>>626
>>624的に言えば、逆だろw

Ruby:(しがらみ的に)困難な、互換性を維持する道を選択した
Python:(作業的に)簡単な、互換性を切り捨てる道を選択した
634デフォルトの名無しさん:2013/09/16(月) 00:11:14.67
結局どこまで将来見据えて言語設計できるかってことに尽きるね
635デフォルトの名無しさん:2013/09/16(月) 00:11:27.76
>>627
あー逆だったw

仮定を元にした発言はしないという
言葉は聞いたことがあるが

仮定を元にした予測に答える価値はないってなんだよw
予測は全て仮定だろ?

どやセリフでも言ったつもり?
636デフォルトの名無しさん:2013/09/16(月) 00:12:01.89
>>632
>C言語で書かれたRubyをJavaどころかPythonで書きなおしたら速くなったという事例すらある。

ソースは?
それとも>>632の脳内かなw
637デフォルトの名無しさん:2013/09/16(月) 00:12:17.23
C#/VBはメジャーな言語としてはむちゃくちゃ急進的だけど後方互換性保ってるじゃん
予約後増やさずにキーワード追加することに命賭けてる
638デフォルトの名無しさん:2013/09/16(月) 00:12:38.89
>>628
意味不明
新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ
639デフォルトの名無しさん:2013/09/16(月) 00:12:44.58
既にエンタープライズ用途のrails出てるだろ
行政交えてスタートアップのモデル都市でも作らないと
日本って、また、IT分野で国際競争に負けるんじゃねーの?
大体、海外サービスに日本円を吸い上げられるのは見えてるんだし
640デフォルトの名無しさん:2013/09/16(月) 00:12:50.50
>>634
その将来の予測が外れた時の
対応をどうするかってことのほうが重要だろ。

ほんと、大丈夫かなぁこいつ。
641デフォルトの名無しさん:2013/09/16(月) 00:13:23.69
>>636
Topaz、JRubyも知らんのか!
642デフォルトの名無しさん:2013/09/16(月) 00:14:41.92
>>638
> 新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ

そんなもん、両方のエンジンを搭載すればいいだけの話。
何かのフラグ用意して立っていれば、
実行エンジンを切り替えれば良い。
簡単なことだ。
643デフォルトの名無しさん:2013/09/16(月) 00:15:01.97
>>631
ざっと見たけどこれ凄いな。
他の言語でも活用できるんじゃ?
644デフォルトの名無しさん:2013/09/16(月) 00:15:57.92
>>637
あれだけ追加してもforeachのキャプチャの挙動変更以外、互換性放棄したことないよな。

でもある意味C#とVBは優秀なコーダーと糞コーダーの二極化が激しいな。
優秀な人は関数ポインタやLINQ、型推論、ミックスイン(拡張メソッド)とか使いこなしていいコード書くのに、
特にVB6やJavaから来た人間はもうゴミみたいなコード出してくる・・・
645デフォルトの名無しさん:2013/09/16(月) 00:17:00.52
>>642
フラグを用意するってのは後方互換性に配慮する最後の方法なんだけど?
つまりフラグを用意してる時点で後方互換性を守ってるじゃん
変なこと言うねえ
646デフォルトの名無しさん:2013/09/16(月) 00:17:01.97
>>641
Topazってスレッドもファイバーも切り捨てた軽量版Rubyのこと?
そんなの引き合いに出されてもねぇ…
647デフォルトの名無しさん:2013/09/16(月) 00:17:15.45
>>641
それって、時間計算量と空間計算量のトレードオフであってる?
648デフォルトの名無しさん:2013/09/16(月) 00:18:18.77
>>645
頭大丈夫か?

目的はなんだ?
達成出来てるかどうかの答えはなんだ?

お前はなぜ制限を設けようとするのだ?
あれしちゃいけない、これしちゃいけない
頭がかたすぎるぞ。
649デフォルトの名無しさん:2013/09/16(月) 00:18:35.47
>>641
なーんだ、RailsアプリをDjangoへ書き直したら、劇的に速くなった話だと脳内変換してたよw
650デフォルトの名無しさん:2013/09/16(月) 00:20:21.61
>>640
外れた後の対応がうまかった言語なんてあったっけ・・・?
651デフォルトの名無しさん:2013/09/16(月) 00:21:20.02
>>650
上手いかどうかではなく、
外れた時に、諦めるのは
最悪のやり方だということ。
652デフォルトの名無しさん:2013/09/16(月) 00:21:54.24
>>648
いけないなんて言ってないでしょ
こちらは、JSは後方互換性を捨てられないと言った
そちらは、それに反発して、フラグを用意する案を挙げた
こちらは、それも後方互換性を守る方法じゃんと突っ込んだ←今ココ

自分の主張理解して話してる?
653デフォルトの名無しさん:2013/09/16(月) 00:23:57.64
適当に目に触ったレスにイチャモンつけて騒いでるだけだから、
最初から主張とかあるわけがない。
654デフォルトの名無しさん:2013/09/16(月) 00:26:50.19
結局何を騒いでたんだっけ?
655デフォルトの名無しさん:2013/09/16(月) 00:27:32.06
>>652
2chで理路整然とした会話が可能とか思っている時点で終わってる
656デフォルトの名無しさん:2013/09/16(月) 00:28:04.62
飽きたんで、お題をたのむ。
657デフォルトの名無しさん:2013/09/16(月) 00:28:49.15
>>651
そりゃ当然そうでしょう
敗戦処理より最初の作戦の方が重要だとは思うけど
658デフォルトの名無しさん:2013/09/16(月) 00:30:11.44
>>652
お前こそ自分の言った言葉忘れてるの?

> 新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ

って書いただろ。

だから俺は、反論して新しい規格を採用したエンジンで
過去のスクリプトが動かなくなっても良いといったんだよ。

なぜなら、古いエンジンも両方載せればいいから。
この場合、新しいエンジンは、古い規格をサポートしているとお前は言うのか?

新しいエンジンは新しい規格のみを採用している。
そうであっても互換性を保つ方法はあるということを俺は示しただけ。

古いエンジンを載せる以外にも手はあるぞ。
自分で考えてみな。
659デフォルトの名無しさん:2013/09/16(月) 00:33:51.97
>>658
失礼だけど、言ってることがズレてるよ

バージョンを分けるためには新しい方にフラグを用意しないといけない
つまりそれは新しい規格の方で後方互換性を守るために仕様に組み込むことになるんだよ

こちらの言いたいこと分かった?
660デフォルトの名無しさん:2013/09/16(月) 00:34:42.41
>>659
必要ない。実行エンジンを切り替える
ブートストラップを用意すればいいだけ。
はい論破w
661デフォルトの名無しさん:2013/09/16(月) 00:36:24.90
>>633
一応、Pythonを擁護しておくと、(Rubyとは比較にならないほど)ユーザ数が多いから、
互換性を維持する作業は(Rubyとは比較にならないほど)簡単ではなかった、のだと思う

結局、>>634の言う「将来見据えた言語設計」が大切、ってことだね

ただ、残念なのは、>>651のいう「(予測が)外れた時に諦める」という
「最悪のやり方」を選択してしまった事
なんとかならなかったものなのかなぁ......
662デフォルトの名無しさん:2013/09/16(月) 00:36:54.05
忘れてる人もいるかもしれないけど、
もともとHTMLには実行エンジンを
切り替える仕組みを持ってるんだよ。

<script language="JavaScript1.2"></script>

こう書くとJavaScript1.2で動く。
663デフォルトの名無しさん:2013/09/16(月) 00:37:30.74
>>660
あー、なるほどね
つまりWebサイトの閲覧者は、どうもJSが動かないなと感じたら
ブラウザのメニューからES5互換表示を選択すればいい訳だ

それは確かに正しい、こちらが間違っていた
大変申し訳ない
664デフォルトの名無しさん:2013/09/16(月) 00:38:08.29
> ブラウザのメニューからES5互換表示を選択すればいい訳だ

それしか思いつかないのが、お前の限界w
665デフォルトの名無しさん:2013/09/16(月) 00:39:57.63
新しいエンジンで実行したいのなら
httpヘッダで指定するってやり方もありそう。
666デフォルトの名無しさん:2013/09/16(月) 00:40:29.32
>>662
じゃあそれが書いてなかったらJS何で動かせばいいのよ??
JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの??
そういうので問題起きてるんと違うん??
それは解決方法でもなんでもなくて、むしろ問題だと思うよ。
667デフォルトの名無しさん:2013/09/16(月) 00:40:48.31
外部ファイル前提だが、拡張子を変えるというても思いついた。
668デフォルトの名無しさん:2013/09/16(月) 00:41:34.49
>>664
すまない
君の想像力には参った
669デフォルトの名無しさん:2013/09/16(月) 00:43:00.39
こういう無茶苦茶な理屈並べるのってネタなのかマジなのかわからんから怖い
670デフォルトの名無しさん:2013/09/16(月) 00:43:44.32
>>666
> じゃあそれが書いてなかったらJS何で動かせばいいのよ??

互換性を保つためと考えれば、
古い実行エンジンに決まってるじゃないかw

> JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの??
開発者(scriptタグを書く人)・・・当然閲覧者ではないは
それぐらい把握できるだろ。

こいつみてると、互換性を保つ方法を考えるのにも
ある程度の技術力がいるんだなぁって思うわw
671デフォルトの名無しさん:2013/09/16(月) 00:45:26.90
> こいつみてると、互換性を保つ方法を考えるのにも
> ある程度の技術力がいるんだなぁって思うわw


そう。だから互換性を切り捨てる方を選んだほうが
(力のない開発者にとっては)簡単。楽。何も考えなくていい。
672デフォルトの名無しさん:2013/09/16(月) 00:46:21.57
>>662,663,665,667,670
こんなことでいいのなら、今までJSが必死に互換性を守ってきた努力は無駄だったな。
それだけじゃなく他言語でも心配するのが馬鹿らしくなる。
673デフォルトの名無しさん:2013/09/16(月) 00:47:58.79
つまりこういうこと?
「理屈勝負では負けたが、とんちクイズでやり返してやったぞ」
674デフォルトの名無しさん:2013/09/16(月) 00:48:17.51
>>672
互換性を保つのは、新しいエンジンを作らないための努力ではなくて、
古いコードをそのまま使えるためにすることだよ。
おバカさんw
675デフォルトの名無しさん:2013/09/16(月) 00:49:36.73
JSのバージョン指定はFirefoxでも廃止されたばかりなのになんと時代錯誤な。
676デフォルトの名無しさん:2013/09/16(月) 00:51:51.83
>>674
急にどうした!?
なにか俺に見えないものが見えてるのだろうか。
677デフォルトの名無しさん:2013/09/16(月) 00:53:33.19
>>675
もしそれが必要になる事があれば復活するでしょ。
互換性を保つのは困難ではあるが
できないことではない。
678デフォルトの名無しさん:2013/09/16(月) 00:54:21.96
>>676
お前こそどうしたんだ?って
みんな思ってると思うが・・・。
679デフォルトの名無しさん:2013/09/16(月) 00:56:17.84
そもそもJavaScriptにバージョンってあったっけ?
元規格のECMAScript仕様とMozillaが勝手に割り振ってるのはあるけど
JSはLivingStandardってやつじゃないの
680デフォルトの名無しさん:2013/09/16(月) 01:01:20.61
ECMAScriptの4とか5とか6というのが
バージョンじゃないのか?
681デフォルトの名無しさん:2013/09/16(月) 01:01:27.49
狂人にはもう触るな…
682デフォルトの名無しさん:2013/09/16(月) 01:02:23.75
そう。巨人には手を出しても負けるだけw
683デフォルトの名無しさん:2013/09/16(月) 01:02:57.29
後方互換性があるからちょっとずつ仕様追加してLiving Standardでいられるのよね。
684デフォルトの名無しさん:2013/09/16(月) 01:04:07.90
巨人様、どうかお鎮まり下さい。
私達のスレを踏み荒らさないで下さいませ。。。
685デフォルトの名無しさん:2013/09/16(月) 01:06:12.00
人の言葉がなかなか通じぬと思っておったら、やはり奇行種であったか……っ
686デフォルトの名無しさん:2013/09/16(月) 01:06:17.53
後方互換性があるからというよりも
後方互換性を保つように仕様を追加してる。
だからそんなに大げさな話にならないんだよ。

まあそれも技術力がなければ、
あっさり諦めるんだろうけどねw
687デフォルトの名無しさん:2013/09/16(月) 01:07:23.65
何を誰に言っているのかわからん
独り言か???
688デフォルトの名無しさん:2013/09/16(月) 01:09:36.94
>>687
まあ、誰にいってるかを書けば、
誰に対しての負け犬の遠吠えか
わかっちゃうから言わないんだろ
689デフォルトの名無しさん:2013/09/16(月) 01:15:56.70
ここでJSのセミコロンは維持すべきかどうか聞いてみる
690デフォルトの名無しさん:2013/09/16(月) 01:21:08.84
Rubyでもセミコロンの有り無しで
動きが変わる例があったよね?

ようはそれをどう捉えるかだと思う。
動きが変わる例を人間がしっかり理解し把握するか
危険な書き方とみなしてやめましょうと考えるか。
691デフォルトの名無しさん:2013/09/16(月) 01:27:40.52
自分はnpmスタイルに感銘を受けて付けない派やってる。
692デフォルトの名無しさん:2013/09/16(月) 01:29:37.86
「式だけ」の文の前の文の終わりに注意すればOK
693デフォルトの名無しさん:2013/09/16(月) 02:11:02.71
>>1
アンケートスレ、QQに勃てておいた

【PHP,Python】スクリプト,バトルロワイヤル【Perl,Ruby,JS】
http://qooqoo.tv/qq/id_question_02_07_31_1379647689/question.shtml

とりあえず、俺はJSに一票入れておいたw
694デフォルトの名無しさん:2013/09/16(月) 02:31:46.77
別のエンジン乗せるだけなら、JavaScriptではなくVBScriptでもいいじゃないか。
695デフォルトの名無しさん:2013/09/16(月) 02:46:55.89
>>693
なにこのサイト
微妙すぎる
696デフォルトの名無しさん:2013/09/16(月) 02:48:52.53
>>694
そのとおりだと思うが
そもそも別のエンジンのせる理由がない。
互換性も別のエンジンを載せるまでもなく対応出来てるから。
697デフォルトの名無しさん:2013/09/16(月) 02:56:13.36
JSくらいシンプルで10年も大勢の人に使われた上で
優秀な企業の人材が議論して仕様を決めるんだから
そりゃ互換性取りに失敗しようがないよな

ES6みてもまだまだ追加はできそうに思う
キーワードの問題はちょっとあるが
後から無かったら良かったと思えるものは無さそう
698デフォルトの名無しさん:2013/09/16(月) 03:05:14.91
JSで無かったほうが良かったとされる物第一位はwith文だろうな。
最適化云々は勿論、新アイディアの議論するときwith文ではどうなる?っていうので時間を取る厄介者。
699デフォルトの名無しさん:2013/09/16(月) 03:09:16.02
つーか、JSの仕様の話はそろそろ他でやってくれないか?
700デフォルトの名無しさん:2013/09/16(月) 03:11:25.90
JSでしか書けないコード出してどや顔してくれてる方がよほどためになる
701デフォルトの名無しさん:2013/09/16(月) 03:12:53.75
俺達には簡単なルールがあるじゃないか
今の流れを変えたいのであれば新しいお題を出せばいい
それだけだ
702デフォルトの名無しさん:2013/09/16(月) 03:20:11.86
ケチを付けるだけのレスほど無用なものはなかろうよ。
703デフォルトの名無しさん:2013/09/16(月) 03:25:02.28
>>698
withは旧VBのwithが優れていた。

JavaScriptのwithは
with(obj) {
 a = 1;
 b = 2;
}

だけどVBのwithは
With obj
 .a = 1
 b = 2
End Witi

なのだ。ピリオド一つあるかないかの違いだが、
どこを参照しているかが明確にわかる。
704デフォルトの名無しさん:2013/09/16(月) 03:48:08.74
おまえら、Rubyの仕様策定手順だのendがどうだの
延々やられたらとちょっと想像してみれば
どんだけ苦痛かわかるだろ?
705デフォルトの名無しさん:2013/09/16(月) 03:50:42.57
>>704
やる人がいないんだ。
あきらめろ。
706デフォルトの名無しさん:2013/09/16(月) 04:03:57.30
Rubyの歴史を理解するいい機会じゃん
他所を知らないと真に自己を知ることは出来ないし
707デフォルトの名無しさん:2013/09/16(月) 04:09:16.93
やりたいなら勝手にやればいいじゃん?
お前がやらないからRubyの話題が出ないんだろう。
708デフォルトの名無しさん:2013/09/16(月) 04:11:23.28
>>707
アスペか?
709デフォルトの名無しさん:2013/09/16(月) 04:19:02.24
ノータリンには>>704,706がRubyの話しようって書いてあるように見えるのかな。
710デフォルトの名無しさん:2013/09/16(月) 04:36:52.90
じゃあお前は、言語に関係する話を
何もしなくていいよ。
俺らで勝手にやるからさ。
711デフォルトの名無しさん:2013/09/16(月) 04:48:50.58
712デフォルトの名無しさん:2013/09/16(月) 05:19:04.77
ではお題です。

6面体の
3つの面に○マーク
2つの面に△マーク
1つの面に×マークを描いたサイコロがあるとする。

このサイコロを2つ同時に振ったときに出る
マークの組み合わせを
出る確率が高い順に出力するコードを書け。
その際、それぞれの組み合わせの確率もしくは場合の数も付記すること。
なお、通常のサイコロと同じくサイコロの区別はつかないものとする。

http://blogs.yahoo.co.jp/takutakutakutaku50/28887753.html
713デフォルトの名無しさん:2013/09/16(月) 05:19:10.35
よく考えてみると動的言語でこれだけ
みんなで寄って集って改善してるのって
JavaScriptが最大規模じゃね?

静的言語はコンセプトが違うから
どんなに改良しても動的言語にはならないと思うが、
JavaScriptはいろんな動的言語の機能を吸収して
最強の動的言語になりそうな気がする。

言語仕様を変えてもいいのであれば、
どんな機能だって取り入れられるだろうし。
714デフォルトの名無しさん:2013/09/16(月) 07:46:11.08
JavaScript古いものごっそり削ればいいのにな
715デフォルトの名無しさん:2013/09/16(月) 08:36:30.27
>>713
実装は寄ってたかってものすごく改善されている
これは競争のメリット

逆に仕様は寄ってたかって議論してるおかげで遅々として進まない
これは競争のデメリット
716デフォルトの名無しさん:2013/09/16(月) 08:38:13.55
HTTP廃止して一回Webリセットすればいいお
717デフォルトの名無しさん:2013/09/16(月) 09:08:38.27
718デフォルトの名無しさん:2013/09/16(月) 09:15:54.02
>>606
漏れはそうは思わんわ
719デフォルトの名無しさん:2013/09/16(月) 09:16:52.19
>716
XMLモナ
720デフォルトの名無しさん:2013/09/16(月) 10:16:12.64
オススメのDBの管理方法教えてください
言語はrubyです

アフィカスサイト 作ってます
721デフォルトの名無しさん:2013/09/16(月) 10:19:50.32
JSは既に他言語にある仕様を二周遅れくらいで
取り込んでいる状況
新たに作り出すよりパクる方がスピード速くみえるだけ
722デフォルトの名無しさん:2013/09/16(月) 10:40:02.26
>>721
そうそう
それそれ
723デフォルトの名無しさん:2013/09/16(月) 10:49:15.88
命を守る行動を取って下さい
http://www.poverty.jeez.jp/loda/img/iyan36606.jpg
724デフォルトの名無しさん:2013/09/16(月) 11:31:18.25
725デフォルトの名無しさん:2013/09/16(月) 11:39:19.01
>>724
こういうのを掲示板に貼るキチガイって何がしたいの?
726デフォルトの名無しさん:2013/09/16(月) 11:42:48.65
音でないだけマシかもな
727デフォルトの名無しさん:2013/09/16(月) 11:55:56.55
>>712

h = collections.defaultdict(int)
iter = itertools.product(["○", "○", "○", "△", "△", "×"], repeat=2)
for c in ("".join(sorted([a,b])) for a, b in iter): h[c] += 1
print( sorted(h.items(), key=lambda x: -x[1]) )
728デフォルトの名無しさん:2013/09/16(月) 12:09:42.65
>>727
見事だ。
729デフォルトの名無しさん:2013/09/16(月) 12:12:38.63
他言語は出てこないし、Python最強と言うことでおk?
730デフォルトの名無しさん:2013/09/16(月) 12:16:26.05
OK
731デフォルトの名無しさん:2013/09/16(月) 12:17:53.54
たしかに意外な組み合わせが最初に来るな
732デフォルトの名無しさん:2013/09/16(月) 12:19:48.57
じゃ、Ruby最強ということで

h = Hash.new(0)
["○", "○", "○", "△", "△", "×"].repeated_permutation(2){ |xs| h[xs.sort]+=1 }
p h.sort_by(&:last).reverse
733デフォルトの名無しさん:2013/09/16(月) 12:28:37.87
>>729
うん、Pythonが最強だよ、よかったねw
734デフォルトの名無しさん:2013/09/16(月) 12:39:37.91
>>712
Squeak Smalltalk

| bag |
bag := Bag new.
'○○○△△×' asDigitsToPower: 2 do: [:pair | bag add: pair copy sort].
^bag sortedCounts

=> {12->{$△ . $○} . 9->{$○ . $○} . 6->{$× . $○} . 4->{$× . $△} . 4->{$△ . $△} . 1->#($× $×)}
735デフォルトの名無しさん:2013/09/16(月) 12:40:47.02
>>712
@Mathematica

In:= pTwoDice[n_]:=Module[{oneDiceThrower,twoDiceThrower},

  (* Functions *)
  oneDiceThrower[]:=RandomChoice[{"○","○","○","△","△","×"}];

  twoDiceThrower[]:={oneDiceThrower[],oneDiceThrower[]}//
    Sort;

  (* Results *)
  Table[twoDiceThrower[],{i,1,n}]//
    Tally//
    Sort[#,#1[[2]]>#2[[2]]&]&];

In:= pTwoDice[10000]

Out= {{{"○", "△"}, 3289}, {{"○", "○"}, 2502},
   {{"○", "×"}, 1653}, {{"△", "×"}, 1148},
   {{"△", "△"}, 1136}, {{"×", "×"}, 272}}

(´・∀・`)ヘー
736デフォルトの名無しさん:2013/09/16(月) 12:41:44.58
これcalleeみたいに最初から知ってて出題してただろ。
737デフォルトの名無しさん:2013/09/16(月) 12:42:46.97
>>729
うん。Python最強。
ライブラリ2つ使ってなおこの冗長な記述には勝てる気がしない。w
738デフォルトの名無しさん:2013/09/16(月) 12:43:08.33
>>734
素晴らしいな。
739デフォルトの名無しさん:2013/09/16(月) 12:44:10.40
>>736
ということはJSはもっと短く書けるのか?! wktk
740デフォルトの名無しさん:2013/09/16(月) 12:46:48.05
今知恵を絞ってるがJSで短く書くのは無理
標準のコレクションの機能が明らかに不足してる
741デフォルトの名無しさん:2013/09/16(月) 12:50:18.84
意外といいお題だったな
742デフォルトの名無しさん:2013/09/16(月) 12:51:46.74
短けりゃ良いってもんじゃない。
743デフォルトの名無しさん:2013/09/16(月) 12:52:56.62
じゃ、長くなってもいいからJSでよろ
744デフォルトの名無しさん:2013/09/16(月) 13:06:56.90
お題>>712について、ここまでの結果をまとめてみよう

Python:5ステップ -- >>727の4行に import collections, itertools を追加
Ruby:3ステップ -- >>732
Smalltalk:4ステップ -- >>734
Mathematica:たくさん -- >>735

>>729
残念ながら、どうやらRuby最強が結論だったね

>>742
>>737が言うように、簡潔さでもRuby最強だね
745デフォルトの名無しさん:2013/09/16(月) 13:08:15.27
>>732
ちょっと縮めてみた。
これで字数的にもSqueak並になったろう

h = Hash.new(0)
"○○○△△×"chars.repeated_permutation(2){ |xs| h[xs.sort]+=1 }
p h.sort_by{ |x| -x[1] }
746デフォルトの名無しさん:2013/09/16(月) 13:08:19.23
もしかして、>>712はRuby厨だったのか?
747デフォルトの名無しさん:2013/09/16(月) 13:11:25.84
>>743
とりあえずこんなもん

a = [ '○', '○', '○', '△', '△', '×' ]
b = [ v1+v2 for (v1 of a) for (v2 of a) ]
m = new Map()
for (k of b) m.set(k, m.get(k) ? m.get(k)+1 : 1)
c = [ v for (v of m) ].sort((p, q) => q[1] - p[1])

//[["○○",9],["○△",6],["△○",6],["△△",4],["○×",3],["×○",3],["△×",2],["×△",2],["××",1]]
748デフォルトの名無しさん:2013/09/16(月) 13:14:03.59
お、案外みじかい
749デフォルトの名無しさん:2013/09/16(月) 13:16:46.44
すくなくともPythonには勝ってるよ。すごいよ。
750デフォルトの名無しさん:2013/09/16(月) 13:18:27.33
あー、でも結果まちがってる…… 残念ッ!
751デフォルトの名無しさん:2013/09/16(月) 13:19:25.33
副作用使うなよ格好悪い
PythonもRubyもだが
752デフォルトの名無しさん:2013/09/16(月) 13:22:01.74
>>748
手元で動かしてみたら、文法エラーになった

saikoro.js:2: SyntaxError: missing in after for:
saikoro.js:2: b = [ v1+v2 for (v1 of a) for (v2 of a) ]
saikoro.js:2: ....................^

処理系は spidermonkey(JavaScript-C 1.7.0 2007-10-03)だけど、古いのかな?
753デフォルトの名無しさん:2013/09/16(月) 13:22:30.90
うっかりしてた

a = [ '○', '○', '○', '△', '△', '×' ]
b = [ [v1,v2] for (v1 of a) for (v2 of a) ].map(v => '' + v.sort())
m = new Map()
for (k of b) m.set(k, m.get(k) ? m.get(k)+1 : 1)
c = [ v for (v of m) ].sort((p, q) => q[1] - p[1])

//[["△,○",12],["○,○",9],["×,○",6],["△,△",4],["×,△",4],["×,×",1]]
754デフォルトの名無しさん:2013/09/16(月) 13:26:07.76
>>752
Firefoxのコンソールとかで試して

a = [ '○', '○', '○', '△', '△', '×' ]
b = [ [v1, v2] for (v1 of a) for (v2 of a) ].map(v => v.sort().join(''))
m = new Map()
for (k of b) m.set(k, m.get(k) ? m.get(k)+1 : 1)
c = [ v for (v of m) ].sort((p, q) => q[1] - p[1])

//[["△○",12],["○○",9],["×○",6],["△△",4],["×△",4],["××",1]]
755デフォルトの名無しさん:2013/09/16(月) 13:27:02.80
ここでHaskell登場か?
756デフォルトの名無しさん:2013/09/16(月) 13:30:00.09
Smalltalkが地味にすごいな
757デフォルトの名無しさん:2013/09/16(月) 13:36:42.45
メソッドコールの数でステップ数だしたら
Rubyより少ないんじゃ?
758デフォルトの名無しさん:2013/09/16(月) 13:37:25.38
奇をてらってみた

a = [ '○', '○', '○', '△', '△', '×' ]
b = [ [v1, v2] for (v1 of a) for (v2 of a) ].map(v => v.sort().join(''))
c = [ [v, b.join().match(RegExp(v,'g')).length] for (v of new Set(b)) ].sort((p, q) => q[1] - p[1])

// [["△○",12],["○○",9],["×○",6],["△△",4],["×△",4],["××",1]]
759デフォルトの名無しさん:2013/09/16(月) 13:42:49.60
GJ!
760デフォルトの名無しさん:2013/09/16(月) 13:43:19.53
>>751
じゃぁこれで

a = "○○○△△×".chars.repeated_permutation(2).map(&:sort)
p a.uniq.map { |x| [a.count(x), x] }.sort.reverse
761デフォルトの名無しさん:2013/09/16(月) 13:46:07.79
>>758
その方がいいな
副作用使うのは豚
762デフォルトの名無しさん:2013/09/16(月) 13:56:16.39
コレクション禁止縛りっすか
763デフォルトの名無しさん:2013/09/16(月) 13:58:53.34
副作用なし
%w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).sort.chunk {|e| e }.map {|k, v| [k, v.size] }.sort_by(&:last).reverse
=> [[["△", "○"], 12], [["○", "○"], 9], [["×", "○"], 6], [["△", "△"], 4], [["×", "△"], 4], [["×", "×"], 1]]
764デフォルトの名無しさん:2013/09/16(月) 14:07:53.03
副作用なし(C#)
var d = "○○○△△×";
var r = d.SelectMany(a => d, (a, b) => new string(new[] { a, b }.OrderBy(c => c).ToArray()))
.GroupBy(ab => ab).OrderByDescending(g => g.Count());

foreach (var g in r) Console.Write("({0},{1})", g.Key, g.Count());
> (△○,12)(○○,9)(○✕,6)(△△,4)(△✕,4)(✕✕,1)
765デフォルトの名無しさん:2013/09/16(月) 14:09:11.24
あのう、Python君が>>727を最後に息をしていないみたいですけど、まだ生きてますか?
766デフォルトの名無しさん:2013/09/16(月) 14:09:37.24
PHPでPythonに勝ってみて
767デフォルトの名無しさん:2013/09/16(月) 14:11:45.57
Python(副作用なし)まだ?
768デフォルトの名無しさん:2013/09/16(月) 14:12:37.85
PHPerこのスレに居るの?
769デフォルトの名無しさん:2013/09/16(月) 14:15:35.39
>>764
そうか、group by でいいんだ。

ということで修正版
%w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).group_by {|e| e }.map {|k, v| [k, v.size] }.sort_by(&:last).reverse
=> [[["△", "○"], 12], [["○", "○"], 9], [["×", "○"], 6], [["△", "△"], 4], [["×", "△"], 4], [["×", "×"], 1]]
770デフォルトの名無しさん:2013/09/16(月) 14:21:52.59
>>766
つまり、PythonのライバルはPHPである... というわけですね
771デフォルトの名無しさん:2013/09/16(月) 14:24:31.27
haskell数え上げ弱すぎワロタ
772デフォルトの名無しさん:2013/09/16(月) 14:25:59.94
from itertools import product, groupby
s=["○", "○", "○", "△", "△", "×"]
print sorted(((lambda h:(h[0], len(h)))(list(g)) for _,g in groupby(sorted(map(lambda i:''.join(sorted(i)), product(s, repeat=2))))), key=lambda (l,r):r, reverse=True)
773デフォルトの名無しさん:2013/09/16(月) 14:28:11.85
短いコードより早いコードで頼む
774デフォルトの名無しさん:2013/09/16(月) 14:28:46.20
まあ、そりゃPythonでも書けますわな。
775デフォルトの名無しさん:2013/09/16(月) 14:31:16.47
RubyやC#の副作用なしverはまあ普通に読めないこともないが
>>772はさすがに汚すぎるだろw
776デフォルトの名無しさん:2013/09/16(月) 14:34:49.96
書いてる人は良いんだけど、他の人は読めない。
777デフォルトの名無しさん:2013/09/16(月) 14:35:08.13
一行で書くことに
なにか重大な意味があるんだろ
聞いてみたいな。
778デフォルトの名無しさん:2013/09/16(月) 14:35:21.14
>>772
カッコだらけのコードにワロタ

オフサイドルール?可読性?保守性?www
779デフォルトの名無しさん:2013/09/16(月) 14:39:22.20
メソッドチェーン指向
780デフォルトの名無しさん:2013/09/16(月) 14:41:59.59
わかりやすいコードは短いコードである ×

わかりやいコードは行数が少ないコードである ×
781デフォルトの名無しさん:2013/09/16(月) 14:46:51.48
>>776
こうすれば、読めるんではないかと思われ

$ irb
irb(main):001:0> %w(○ ○ ○ △ △ ×)
=> ["○", "○", "○", "△", "△", "×"]
irb(main):002:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2)
=> #<Enumerator: ["○", "○", "○", "△", "△", "×"]:repeated_permutation(2)>
irb(main):003:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort)
=> .... 省略 ....
irb(main):004:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).group_by {|e| e }
=> .... 省略 ....
irb(main):005:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).group_by {|e| e }.map {|k, v| [k, v.size] }
=> .... 省略 ....
irb(main):006:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).group_by {|e| e }.map {|k, v| [k, v.size] }.sort_by(&:last)
=> .... 省略 ....
irb(main):007:0> %w(○ ○ ○ △ △ ×).repeated_permutation(2).map(&:sort).group_by {|e| e }.map {|k, v| [k, v.size] }.sort_by(&:last).reverse
=> [[["△", "○"], 12], [["○", "○"], 9], [["×", "○"], 6], [["△", "△"], 4], [["×", "△"], 4], [["×", "×"], 1]]
irb(main):008:0>
782デフォルトの名無しさん:2013/09/16(月) 14:48:09.40
いうまでもなく、メソッドチェーンやLINQは一行にまとめて書く必要はないよ
"○○○△△×".chars
.repeated_permutation(2)
.group_by(&:sort)
.map{|a,b| [a, b.size]}
.sort_by{|e| -e[1]}

ネストした関数コールよりは見やすいと思う
lambdaを導入したJavaやC++のコレクション操作もこういう方向に進んでるのでは
783デフォルトの名無しさん:2013/09/16(月) 14:48:31.19
>>780
わかりやすいコードは短いコードである ×

わかりやいコードは行数が少ないコードである ×

わかりやいコードはカッコが多いコードである ○




こうですか?よくわかりません
784デフォルトの名無しさん:2013/09/16(月) 14:49:58.90
誰かHaskellで書いてみてくれ
785デフォルトの名無しさん:2013/09/16(月) 14:52:02.89
Haskellまだー?
786デフォルトの名無しさん:2013/09/16(月) 14:53:17.09
>>782
Pythonは、LISPの方向に突き進んでいます....
787デフォルトの名無しさん:2013/09/16(月) 14:55:06.35
インデントするのが面倒だったから一行で書いたらひどい言われようだな
こうすれば満足か?(空白を&amp;nbsp;に置換したら長すぎる行があると言われて貼れなかった)
ttp://ideone.com/ZUGkAh
788デフォルトの名無しさん:2013/09/16(月) 14:55:56.43
>>782
>ネストした関数コールよりは見やすいと思う
>lambdaを導入したJavaやC++のコレクション操作もこういう方向に進んでるのでは

Pyhtonだけ時代に取り残されつつあると感じるのは、気のせい?
789デフォルトの名無しさん:2013/09/16(月) 14:58:20.84
Pythonは外部イテレータやyieldをいち早く導入したのに活かせてないんだよなあ
もったいない
790デフォルトの名無しさん:2013/09/16(月) 15:00:16.71
で、そのコード関数にして10000回実行して1秒以内に済むの?
791デフォルトの名無しさん:2013/09/16(月) 15:01:22.22
ナンセンスでしょ
先のRubyとC#のコードなんてほぼ同じだけどC#の方が圧倒的に速いだろうし
792デフォルトの名無しさん:2013/09/16(月) 15:02:25.32
C#はそもそもスクリプト言語じゃないじゃん。
793デフォルトの名無しさん:2013/09/16(月) 15:04:54.73
処理系次第だという極端な例を挙げただけだよ
794デフォルトの名無しさん:2013/09/16(月) 15:04:56.21
流石にC系と比べろという人はいないと思うよ
795デフォルトの名無しさん:2013/09/16(月) 15:07:42.82
処理系がクソなら
短さを多少犠牲にして速度を重視する軸で比較しても面白いと思うけどな

競わなくてもいいけど、実際何の環境で何msかかるか知りたい
796デフォルトの名無しさん:2013/09/16(月) 15:09:48.44
組合せならば、リスト内包表記のあるPythonに有利なお題かと思っていたが、
意外な結果で終わりそうだな
797デフォルトの名無しさん:2013/09/16(月) 15:11:20.62
今日中に終わらない処理系とか流石に無いよなw?
798デフォルトの名無しさん:2013/09/16(月) 15:12:25.49
>>787
これで、Rubyの do ... end や JavaScript の { ... } を笑えなくなったね

Pythonオフサイドルール信仰崩壊の瞬間だw
799デフォルトの名無しさん:2013/09/16(月) 15:15:18.79
Haskell
添削お願いします
http://ideone.com/uBHJYF
800デフォルトの名無しさん:2013/09/16(月) 15:15:45.97
>>788
いや、また後方互換性を無視した Python 4 が、すべての問題を解決してくれるはずだぞ
801デフォルトの名無しさん:2013/09/16(月) 15:17:37.71
Haskellってこんなんだっけ?って思った。
802デフォルトの名無しさん:2013/09/16(月) 15:25:00.20
Pythonでもメソッドチェーンで書けないのかな?
803デフォルトの名無しさん:2013/09/16(月) 15:32:18.37
構文上可能だけどビルトインのクラスの書き換えが簡単にはできないからRubyのようにはいかない
804デフォルトの名無しさん:2013/09/16(月) 15:37:31.60
foreach ($ary=array("○", "○", "○", "△", "△", "?") as $val1)
&nbsp&nbsp;foreach ($ary as $val2)
&nbsp&nbsp&nbsp&nbsp$a[$x=$val1>$val2?$val1.$val2:$val2.$val1] = isset($a[$x]) ? ++$a[$x] : 1;
arsort($a);
print_r($a);

http://ideone.com/htCIiy
805デフォルトの名無しさん:2013/09/16(月) 15:38:06.67
>>803
いや、今回のお題ではメソッドをユーザ定義していない、つまり
Rubyでは組込み(ビルトイン)メソッドだけを、Pythonでは添付ライブラリ関数だけを
使って書いているんだから、書き換えうんぬんは違うんじゃねえの?
806デフォルトの名無しさん:2013/09/16(月) 15:38:33.43
強引だが早そうなPHP
807デフォルトの名無しさん:2013/09/16(月) 15:42:02.17
>>804
わかりやすいし素直でいいなこれ。
808デフォルトの名無しさん:2013/09/16(月) 15:45:32.07
優勝
809デフォルトの名無しさん:2013/09/16(月) 15:46:25.82
PHP自体が遅いから速度には期待できないが……
810デフォルトの名無しさん:2013/09/16(月) 15:46:40.15
$dice=["○", "○", "○", "△", "△", "×"];

$pairList = makePair($dice,$dice);
$result = sortValueCount($pairList);
dispResult($result,count($pairList));

function makePair($dice1,$dice2){
foreach($dice1 as $d1)
foreach($dice2 as $d2)
$pair[]=$d1.$d2;
return $pair;
}

function sortValueCount($pair){
$pair = array_count_values($pair);
arsort($pair);
return $pair;
}

function dispResult($result,$count){
foreach($result as $var=>$val)
printf ("%s : %5.2f%%\n",$var,$val/$count*100);
}
811デフォルトの名無しさん:2013/09/16(月) 15:48:20.91
>>809
は?
812デフォルトの名無しさん:2013/09/16(月) 15:48:34.90
import collections, itertools

g = itertools.product('○○○△△×', repeat=2)
print(collections.Counter(tuple(sorted(x)) for x in g))
813デフォルトの名無しさん:2013/09/16(月) 15:49:16.29
こういうコード晒し大会って一行になんでも詰めて書く奴がいるから萎える
814デフォルトの名無しさん:2013/09/16(月) 15:53:13.29
とりあえず一万回回した時のタイムを測ってみてはどうか
815デフォルトの名無しさん:2013/09/16(月) 15:54:52.28
>>810
この流れでそんなコードを晒した勇気は認めてあげる
816デフォルトの名無しさん:2013/09/16(月) 15:57:46.99
Time厨うぜー
スクリプト言語に速度なんて誰も求めてねえよ
817デフォルトの名無しさん:2013/09/16(月) 15:59:13.87
>>812
大逆転クッソワロタw
818デフォルトの名無しさん:2013/09/16(月) 16:03:33.90
importしてる時点で大反則だよ
ライブラリやモジュール使えばどんな言語も1行で済むし
819デフォルトの名無しさん:2013/09/16(月) 16:03:38.39
Ruby厨息してない
820デフォルトの名無しさん:2013/09/16(月) 16:06:04.61
import はいいだろ
外部ライブラリを使ってるわけじゃなし
821デフォルトの名無しさん:2013/09/16(月) 16:11:02.95
確かに外部ライブラリ使うのと変わらんな。
これを認めると意味がなくなる。
822デフォルトの名無しさん:2013/09/16(月) 16:14:38.66
外部ライブラリ使うのはいいよ
外部ライブラリの行数も加算すれば
823デフォルトの名無しさん:2013/09/16(月) 16:17:04.18
僕は○○の開発者だけどこのスレをたまたま見ました
コード量削るために次のリリースで組み込んでおきますね^^;
824デフォルトの名無しさん:2013/09/16(月) 16:18:12.57
じゃあimport原則禁止でお願いします
stdoutとか直接ロジックに関係しないのと
ないと動かないのはあっていいです

collectionsとかitertoolsみたいな
普段のコードで必ずしも使わないモジュールの読み込みは不可です
825デフォルトの名無しさん:2013/09/16(月) 16:19:28.79
公式モジュールならいいだろ・・・
826デフォルトの名無しさん:2013/09/16(月) 16:19:39.32
外部じゃないよ
標準ライブラリだよ

importは、ただ単にネームスペースが別れてるだけ
827デフォルトの名無しさん:2013/09/16(月) 16:20:53.76
>>826
じゃ、Javaみたくimportなしでも完全名を書けばおkなんだ?
828デフォルトの名無しさん:2013/09/16(月) 16:21:38.12
Rubyだれかideoneでベンチ書いてくれ
自分の環境だと動くんだけど、ideoneだと動かん
829デフォルトの名無しさん:2013/09/16(月) 16:22:14.60
便利モジュール読み込んでいいのならライブラリ勝負と変わらんだろ……
標準とか関係ないよ
830デフォルトの名無しさん:2013/09/16(月) 16:22:58.70
namespace観念のないRuby厨
831デフォルトの名無しさん:2013/09/16(月) 16:23:13.02
便利モジュールを読み込むの禁止
これいいね
832デフォルトの名無しさん:2013/09/16(月) 16:24:09.92
このままだと速度もソースもphpの圧勝になるぞ
833デフォルトの名無しさん:2013/09/16(月) 16:24:18.98
完全にフェアな条件なんてそもそもないんだからさ。
なんで頑なに嫌がるのか不思議。
834デフォルトの名無しさん:2013/09/16(月) 16:24:46.98
違うネームスペースを参照するのにimportがいる言語はpythonだけじゃないぞ
835デフォルトの名無しさん:2013/09/16(月) 16:26:26.28
リストもハッシュもソートも禁止だな
836デフォルトの名無しさん:2013/09/16(月) 16:26:34.35
標準ライブラリ否定w
こいついつもの屁理屈野郎だろ。
837デフォルトの名無しさん:2013/09/16(月) 16:28:47.19
また短いコードが出て来てから騒ぎ出す辺りが
滑稽で見苦しいな
838デフォルトの名無しさん:2013/09/16(月) 16:31:53.50
このスレのPythonerが自力では何も出来ないレベルの低い奴っていうのが良くわかった
839デフォルトの名無しさん:2013/09/16(月) 16:32:55.93
不利になるとなんでも縛ろうとするのが洗脳されたRuby厨の末路
自分が好んで縛られたからって他人まで縛るんじゃないよ
840デフォルトの名無しさん:2013/09/16(月) 16:33:24.87
import無しでいいコードを書いてみればいいじゃない
できないからグズってるんだと思ってしまう
841デフォルトの名無しさん:2013/09/16(月) 16:35:58.86
自分の言語の都合にだけハマってたら、
分かり合うことなんて出来ないでしょ。

Pythonならもっと面白いコードに出来るんじゃないの?
842デフォルトの名無しさん:2013/09/16(月) 16:36:28.88
Ruby5倍ぐらい遅いんだが、何かオプション付けないとダメか?
843デフォルトの名無しさん:2013/09/16(月) 16:37:03.41
ウンコなコードで勝ち誇ってたら
アッサリ逆転されて悔しいよ〜
844デフォルトの名無しさん:2013/09/16(月) 16:43:18.26
むしろSmalltalkのBag相当を標準で持ってるのが
他言語だとPythonしか無いのが信じられん
クソすぎる
845デフォルトの名無しさん:2013/09/16(月) 16:45:41.72
※但しインポートしないと使えない※
846デフォルトの名無しさん:2013/09/16(月) 16:46:58.72
Pythonは素では何も出来ない言語なんだってのがよく分かったw
847デフォルトの名無しさん:2013/09/16(月) 16:49:59.04
>>846
Pythonは悪くないだろ
書いてる奴がド底辺なだけだ
848デフォルトの名無しさん:2013/09/16(月) 16:51:58.25
何でもデフォルトの名前空間に突っ込んでるゴミ言語が最強
849デフォルトの名無しさん:2013/09/16(月) 16:56:39.18
Bagは便利だから、Rubyにも標準であったらいいのに。
gemはあるんだけどC++erが作ったからAPIがねぇ…ちょっと。^^;
http://maraigue.hhiro.net/multiset/
850デフォルトの名無しさん:2013/09/16(月) 16:57:22.37
グローバルに備わってないような機能をインポートしてさも平然と使っていいのなら
ライブラリをインポートして使ってもよくなるじゃんってことでは?
851デフォルトの名無しさん:2013/09/16(月) 16:59:24.46
よくわからんがBugくらいどの言語でもすぐ実装できるんじゃ?
852デフォルトの名無しさん:2013/09/16(月) 16:59:26.01
他の言語、遅くて3秒とかなのに、Rubyだけ17秒かかるんだけどなんで?
こんなもんなの?
853デフォルトの名無しさん:2013/09/16(月) 17:02:38.26
>>758を10000回実行したら3秒くらいかかる。
PentiumDだから今のCPUなら1秒切るくらいかな?
854デフォルトの名無しさん:2013/09/16(月) 17:02:55.89
>>848
BagなんかANSI(あれもないこれもないってSmalltalkerには不評)にも入っているし
最小限の部類なんだが…
855デフォルトの名無しさん:2013/09/16(月) 17:04:49.39
コレクションやイテレート処理くらいデフォルトで使えないと文句言われてもしかたないね
856デフォルトの名無しさん:2013/09/16(月) 17:05:51.04
また関数型の話するの?
好きだねえ。
857デフォルトの名無しさん:2013/09/16(月) 17:05:56.38
; Common Lisp
(loop with dice = '("○" "○" "○" "△" "△" "×")
   with alist
   for i in dice
   do (loop for j in dice
        for key = (sort (concatenate 'string i j) #'string<)
        for cons = (assoc key alist :test #'string=)
        if cons
        do (incf (cdr cons))
        else do (push `(,key 1) alist))
   finally (print (sort alist #'> :key #'cdr)))
858デフォルトの名無しさん:2013/09/16(月) 17:06:01.39
>>851
だれうま
859デフォルトの名無しさん:2013/09/16(月) 17:06:40.60
Perlさん息してない
860デフォルトの名無しさん:2013/09/16(月) 17:08:09.84
>>817,819,843

Ruby(>>760):
 a = "○○○△△×".chars.repeated_permutation(2).map(&:sort)
 p a.uniq.map { |x| [a.count(x), x] }.sort.reverse

Python(>>812):
 import collections, itertools

 g = itertools.product('○○○△△×', repeat=2)
 print(collections.Counter(tuple(sorted(x)) for x in g))


Rubyにようやく追いついただけで歓喜する愉快なPython厨www
861デフォルトの名無しさん:2013/09/16(月) 17:12:26.30
>>852
Rubyは遅れをとっているようだね。
http://d.hatena.ne.jp/satosystems/20121228/1356655565
862デフォルトの名無しさん:2013/09/16(月) 17:16:32.91
>>860
処理内容の違いも分からずコード比較してどや顔の愉快なRuby厨。
とりあえずBag(MultiSet、Counter)を勉強して来い。話はそれからだ。
863デフォルトの名無しさん:2013/09/16(月) 17:20:49.49
>>860
Lisp 2.07
JS 2.62
Python 2.67
Ruby 22.78

これははっきりしちゃったね
Rubyはモダンスクリプト言語のなんと10倍も低速
使いものにならないレベル
864デフォルトの名無しさん:2013/09/16(月) 17:25:04.85
>>860
簡潔さの証である、メソッド・関数 のコール数では圧倒的にPythonの勝利
Ruby厨て行数と文字数でしか勝てないから、これが対等に見えるのか
865デフォルトの名無しさん:2013/09/16(月) 17:25:56.37
>>863
これはひどい
Rubyつかえんな
866デフォルトの名無しさん:2013/09/16(月) 17:29:19.67
V8はえー
867デフォルトの名無しさん:2013/09/16(月) 17:29:37.02
pythonも>>812 が v2.7とv3.3で5倍違う。
環境で変わりすぎて話にならないな。
868デフォルトの名無しさん:2013/09/16(月) 17:34:39.65
# perl
$h{join '', sort split /:/}++ foreach(glob join '{:}', ('{○,○,○,△,△,×}') x 2);
print map{"$_=>$h{$_} "} sort{ $h{$b} <=> $h{$a} } keys %h;
869デフォルトの名無しさん:2013/09/16(月) 17:35:18.18
うーん、、、
ならRubyは今の最新バージョンに上げたら10倍早くなるの?
870デフォルトの名無しさん:2013/09/16(月) 17:35:30.09
速度の話は確かに環境が違うからあんまあてにならない
最新の安定版と評価版を同じマシンで使って計測とかならまだしも
871デフォルトの名無しさん:2013/09/16(月) 17:36:08.14
流石perlはどこか違うな
872デフォルトの名無しさん:2013/09/16(月) 17:37:25.61
10倍も差がでてて環境による発言は見苦しいな
2倍でも大差なのに
873デフォルトの名無しさん:2013/09/16(月) 17:38:48.62
Rubyも1.8と2.0じゃ速度差は3〜4倍は違うんじゃね?
関係ないが、Rubyは、2.0.1出る前に2.1.0出そうだし、そろそろ安定期かね
874デフォルトの名無しさん:2013/09/16(月) 17:41:02.99
単純演算が遅いのはあまり言い訳できないと思う。
875デフォルトの名無しさん:2013/09/16(月) 17:41:12.39
10,000回
Ruby(>>760): 3.62sec (v2.0.0)
Python(>>812): 2.41sec (v3.3.2)
876デフォルトの名無しさん:2013/09/16(月) 17:42:08.48
現状それだけ差があるのなら
速くできる余地が一番ある言語と言えよう
877デフォルトの名無しさん:2013/09/16(月) 17:45:30.36
Ruby1.8.7をベンチマークに使うのは流石に可哀想だろ
878デフォルトの名無しさん:2013/09/16(月) 17:50:42.46
1.8.7ならダメってどういうこと?
言語のバージョンと実装の速度は直接関係ないんじゃないの?
それともRubyの仕様は後方互換性犠牲にして最適化重視してたりするの?
879デフォルトの名無しさん:2013/09/16(月) 17:54:25.46
>>863
Windows環境で
100000.times{
"○○○△△×".chars.repeated_permutation(2).group_by(&:sort).map{|a,b| [a, b.size]}.sort_by{|e| -e[1]}
}
8.5秒 Ruby 2.0

import collections, itertools
for i in range(100000):
 g = itertools.product('○○○△△×', repeat=2)
 collections.Counter(tuple(sorted(x)) for x in g)
6.9秒 Python 3.2.3

Python速いねっ
RubyもCounterクラスみたいなのが標準だったらもうちょっと速くなるかな

ちなみに上記環境で
>>861 のフィボナッチベンチさせると
10秒 Ruby 2.0
21秒 Python 3.2.3
Ruby1.9以降ならPythonより速いよ(環境によるだろうけど)
フィボナッチが速くても実際のアプリにはあまり関係ないけど

あそこはRuby1.8を使ってるからねぇ…
880デフォルトの名無しさん:2013/09/16(月) 17:56:54.74
>>878
Ruby 1.9以降でコアがAST逐次解釈からバイトコード方式に変更されたので
881デフォルトの名無しさん:2013/09/16(月) 17:57:11.32
rubyはフィボナッチベンチが速くなるように頑張って最適化してるよ
882デフォルトの名無しさん:2013/09/16(月) 17:58:13.89
そんなん他の言語は10年以上前からやってきたことだけど
883デフォルトの名無しさん:2013/09/16(月) 17:58:31.38
884デフォルトの名無しさん:2013/09/16(月) 18:01:51.88
ジワジワすぎて
ようわからん
885デフォルトの名無しさん:2013/09/16(月) 18:08:01.64
886デフォルトの名無しさん:2013/09/16(月) 18:14:47.04
>>883の地域別がおもしろい
Ruby島根が1位wwwさすがお膝元だな
そして茨城県民はPython Ruby Perlあたりが好きらしい
そして沖縄県民はプログラムに興味があるようだ
887デフォルトの名無しさん:2013/09/16(月) 18:19:55.72
>>861のフィボナッチ、
Common Lispは型指定も最適化の宣言もコンパイルもされてない。
888デフォルトの名無しさん:2013/09/16(月) 18:20:33.51
>>878
>1.8.7ならダメってどういうこと?

1.8.7は公式に終了(リタイヤ)したバージョンだよ (>>607を参照)
公式終了版でもダメではないというのなら、
Ruby 1.8.7 と Python 1.0 とで速度を比較しようぜw
889デフォルトの名無しさん:2013/09/16(月) 18:24:49.17
>>897
Ruby2.0入れて試してみたけど
期待したほど早くなかった

27秒 Ruby2.0
1.5秒 Node.js
890デフォルトの名無しさん:2013/09/16(月) 18:25:37.82
それを言うならPython2.5じゃないの
891デフォルトの名無しさん:2013/09/16(月) 18:28:46.66
>>879
>>875だけど、コードと環境選んでいいなら
>>772が python2.7で1.5秒だよ。
最速比較でいいの?
892デフォルトの名無しさん:2013/09/16(月) 18:35:17.82
>>889
未来へのショートパス!!
893デフォルトの名無しさん:2013/09/16(月) 19:00:27.12
>>862
>とりあえずBag(MultiSet、Counter)を勉強して来い。話はそれからだ。

Bag: 要素間で順序性が無いが重複は許す集合、多重集合(multiset)とも言う
  SmalltalkであればクラスBagで実装されている

PythonのSetは「要素間で順序性が無く重複も許さない」から集合だけど、
タプルは可変(mutable)なシーケンスであって、順序性があるから集合ではないね
つまり、Pythonに(Smalltalkと同様な)Bagは存在しないし、PythonのタプルはBagではない

さらにCounterは単にシーケンスを計測するためのクラスであって、Bag固有の概念ではない

結論としては、>>812はBagの特性を活かしたアルゴリズムで書かれているわけではないわけだが、
何を言いたかったの?
894デフォルトの名無しさん:2013/09/16(月) 19:15:29.72
今でもRuby1.8使ってるところ多いよな
ちょうどRailsが流行り始めた頃だったから
895デフォルトの名無しさん:2013/09/16(月) 19:16:06.94
処理系によるって言うけど
なんかPythonの公式の酷くない?

JavaScript 1.6s (Node,Chrome,V8)
Ruby 2.0.0 26s (http://www.artonx.org/data/asr/)
Python 2.7.5 60s (http://www.python.jp/download/)
896デフォルトの名無しさん:2013/09/16(月) 19:29:44.48
>>893
>つまり、Pythonに(Smalltalkと同様な)Bagは存在しないし、PythonのタプルはBagではない

Bagの話をしているのになんでタプルが出てくるのかわからん。
やっぱりBag(か、その使い所)をまったく理解できていないとしか。

>さらにCounterは単にシーケンスを計測するためのクラスであって、Bag固有の概念ではない

お前の中ではそうかもしれんけどな。

Counter クラスは、他の言語のバッグや多重集合のようなものです。
http://docs.python.jp/2/library/collections.html#collections.Counter
897デフォルトの名無しさん:2013/09/16(月) 19:32:18.53
それ間違いだね
898デフォルトの名無しさん:2013/09/16(月) 19:34:31.82
「他の言語の〜のようなもの」っていう決まり文句が出てきたら
当たり前だが実際は大抵結構違うことが多い
899デフォルトの名無しさん:2013/09/16(月) 19:34:44.61
Rubyほどの完成された言語に
Bag程度のクラスがないのはすごく不思議
900デフォルトの名無しさん:2013/09/16(月) 19:37:36.92
なんかコレクション系の1つや2つくらいないの?
901デフォルトの名無しさん:2013/09/16(月) 19:40:39.42
重複を許す集合だから、集合の要素と、要素が重複した回数のペアを持ってるんでしょ > Counter
902デフォルトの名無しさん:2013/09/16(月) 19:41:32.76
>>899
まあSetだってずいぶん後だったしな。
Matzのコレクションの知識なんかそんな程度。
903デフォルトの名無しさん:2013/09/16(月) 19:49:45.48
大クラス主義とかいうとそれらしく聞こえるけど、ぶっちゃけ
RubyのコレクションはArrayとHash(でカバーできるユースケース)以外は
ろくすぽ整備されていないとも言える
904デフォルトの名無しさん:2013/09/16(月) 20:01:43.85
集合って概念において、順序を持ってちゃいけないなんて別にないよ。
いわゆるプログラミングのSetが順序性ないだけで。
905デフォルトの名無しさん:2013/09/16(月) 20:05:58.60
ん?
Setにも順序はあるだろ
毎回イテレートする度に順番変わるわけじゃないんだし
906デフォルトの名無しさん:2013/09/16(月) 20:10:04.81
SetやMapが入れた順番でイテレートされない言語ってあるの?
907デフォルトの名無しさん:2013/09/16(月) 20:14:21.43
Setは集合、順序も重複もない
MultiSet/Bagは多重集合、重複がある
908デフォルトの名無しさん:2013/09/16(月) 20:15:51.90
順序があるかは仕様次第でしょ。
909デフォルトの名無しさん:2013/09/16(月) 20:16:16.53
なのでSetは基本的に順序性を保証しない
きちんとそうリファレンスに書いてある言語もある
910デフォルトの名無しさん:2013/09/16(月) 20:18:26.15
>>903
優先度はかなり低いからね
言語の目的からして
911デフォルトの名無しさん:2013/09/16(月) 20:20:58.70
Setは基本的に順序を保証するものでしょ
じゃないと何かをSetにかけて重複取り除いて戻す時困る
912デフォルトの名無しさん:2013/09/16(月) 20:23:39.10
>>911
別に困らないけど…
913デフォルトの名無しさん:2013/09/16(月) 20:24:45.63
>>911
Setは基本的に順序の保証も重複もない
順序を保証していたり、重複を許す場合はかなり特殊
914デフォルトの名無しさん:2013/09/16(月) 20:27:01.39
順序が保証されなかったら例えば
"I","am","am","Tom"
というのをSetにかけてイテレートしたら
"am","I","Tom"
になるかもしれないってことでしょ
困るじゃん
915デフォルトの名無しさん:2013/09/16(月) 20:27:36.69
>>914
Array使えよ、ってだけじゃん…
916デフォルトの名無しさん:2013/09/16(月) 20:29:06.83
>>914
なるかも知れないではなく、なっても良い場合にしか使ってはいけない
順序性を当てにする時点で使い方を勘違いしている
917デフォルトの名無しさん:2013/09/16(月) 20:30:03.09
配列からSetを作ってそれを配列内包で配列に戻せないのは残念だな。
918デフォルトの名無しさん:2013/09/16(月) 20:30:31.06
むしろSetに2つ値をいれて2つイテレートされる環境の方を知りたい
そんなのあるのか?
919デフォルトの名無しさん:2013/09/16(月) 20:30:36.76
Bagってlock-freeにできるから並列処理には役立つけど
逆に言えばそれくらいだろ
Bagならではの効率的なアルゴリズムってのが特にない(lock-free以外)
920デフォルトの名無しさん:2013/09/16(月) 20:31:21.17
>>916
それは順序が保証されないSetは表現力が低いってことだよ
921デフォルトの名無しさん:2013/09/16(月) 20:34:20.79
前スレで合ったけど順番が保証されてた方が
Setをuniq関数としても使いやすいってことかな?
922デフォルトの名無しさん:2013/09/16(月) 20:34:35.52
>>920
代わりに要素検索のスピードをあげる、などの実装的メリットがあるんだよ
923デフォルトの名無しさん:2013/09/16(月) 20:36:12.62
>>920
違う
それはOrderedSetであってSetではない
Setを順序が保証されるものとして使ってはいけない
924デフォルトの名無しさん:2013/09/16(月) 20:37:33.74
イテレートしにくいのならHashとあまり変わらん気がする
925デフォルトの名無しさん:2013/09/16(月) 20:38:11.83
>>918
日本よ、それがBagだ。
926デフォルトの名無しさん:2013/09/16(月) 20:38:26.77
>>919
上の数え上げがまさにそれじゃん
927デフォルトの名無しさん:2013/09/16(月) 20:38:49.17
Setを順序が保証されるものとして使ってはいけないが
Setのデフォルトの実装が、OrderedSetであってもいい。

いうなれば、Setは抽象クラス。
その実装がOrderedSet
928デフォルトの名無しさん:2013/09/16(月) 20:39:06.57
>>923
名前なんて言語によって違うのでは。
929デフォルトの名無しさん:2013/09/16(月) 20:39:48.72
>OrderedSetであってSetではない
ワロタw
また屁理屈合戦始まるかw
930デフォルトの名無しさん:2013/09/16(月) 20:39:49.68
>>924
イテレートはふつうにできるよ。
順不同なだけ。
931デフォルトの名無しさん:2013/09/16(月) 20:40:28.24
>>927
RubyはSetとSortedSetの両方があるな
PythonはSetだけかな
932デフォルトの名無しさん:2013/09/16(月) 20:40:34.25
Setの条件を満たしていれば、
それはSetだろ?
933デフォルトの名無しさん:2013/09/16(月) 20:41:04.65
>>928
Setの基本は数学の概念であって言語の固有名ではない
だからメジャーな言語は順序性を保証していない
934デフォルトの名無しさん:2013/09/16(月) 20:41:27.25
>>922,930
そんなこと百も承知で話してるんだけど……
935デフォルトの名無しさん:2013/09/16(月) 20:43:15.17
元は数学の概念とか言い出したらラムダ式とかモナドとかどうなるねん
言葉尻捉えるのが好きやなほんと
936デフォルトの名無しさん:2013/09/16(月) 20:44:21.14
>>929
屁理屈ではないよ
本当にそういう概念なだけ
937デフォルトの名無しさん:2013/09/16(月) 20:45:12.97
>>934
いや、たぶん承知はできてないと思う。
"I", "am", "Tom" と "am", "I", "Tom" を区別しないのがSetだ。
938デフォルトの名無しさん:2013/09/16(月) 20:46:30.38
今こんな感じ

細菌ではなくウイルスです
ウイルスではなくヴァイラスです
939デフォルトの名無しさん:2013/09/16(月) 20:47:28.67
>>937
あなたの知ってるSetはそれしか無いのね
よく分かりました
940デフォルトの名無しさん:2013/09/16(月) 20:48:45.98
>>935
完璧に実装するべきとは言っていない
プログラミングにおけるSetの概念は、数学の性質を模倣したものだから
Setという名前のものは、基本的に順序性は期待してはいけない

明確に順序集合であるものや、配列を使うべき
941デフォルトの名無しさん:2013/09/16(月) 20:48:51.76
>>936
強いていうならSetは順序を保証しないのに
Orderedって接頭辞がつくのは矛盾語法じゃないのかって
いうのはああるかも。^^;
942デフォルトの名無しさん:2013/09/16(月) 20:49:38.29
立場の違う者同士が会話し合うのって難しい!!
943デフォルトの名無しさん:2013/09/16(月) 20:49:52.73
>>939
いや、わかってない。
944デフォルトの名無しさん:2013/09/16(月) 20:50:30.27
Pythonのimportって、Rubyのrequireとは割と別物なんだよな〜
本体組み込みのものでもimportしてから使う物とかあるし…
逆に、勝手に読み込まれるのに本体組み込みじゃないものとかもあるが
945デフォルトの名無しさん:2013/09/16(月) 20:51:49.02
Setを持つ言語のほとんどは順序を保証してない
順序を保証するOrdered Setを別に用意している言語も多い
用途に合わせて使い分けましょう

これだけの話だよね?
946デフォルトの名無しさん:2013/09/16(月) 20:53:27.40
>>945
そういうこと
ただのSetに順序があると思ってはいけない

http://doc.ruby-lang.org/ja/1.9.3/library/set.html
http://docs.python.jp/2.5/lib/types-set.html
947デフォルトの名無しさん:2013/09/16(月) 20:53:35.21
setって要は集合だよ。
ベン図に要素描くとき順序の一致を気にする奴はいないだろ?
って最近はベン図を教えてないのか!
948デフォルトの名無しさん:2013/09/16(月) 20:53:36.19
Bagというと検索できないもんだろ?
順序保証なし、重複あり、検索不可
検索不可だからハッシュはいらないし、順序がないからって動的配列より効率的に実装できるかというと特にそんなことはない
lock-freeな実装ができるのがメリットでスクリプト言語では不要
949デフォルトの名無しさん:2013/09/16(月) 20:55:10.91
皆一体何が話したいの?
OrderedなSetとOrderedじゃないSetのどちらが普通のSetと呼ぶべきか喧嘩して何か意味あるの?
現にSetという名前で既にどちらもそれぞれの言語に導入されてるんだから、仕方無くない?
950デフォルトの名無しさん:2013/09/16(月) 20:55:17.54
>>948
検索はできるよ。indexOf みたいなことができないだけ。
951デフォルトの名無しさん:2013/09/16(月) 20:55:30.95
ただのSetに順序があると思ってはいけないというだけで、
Setに順序を持ってはならないという決まりはない。

Setの条件に順序が規定されてないだけ。

Setを拡張したOrdedSetであれば順序が規定されている。

OrdedSetはSetの条件を満たしているので、Setである。

こういう話。
952デフォルトの名無しさん:2013/09/16(月) 20:56:45.46
>>949
OrderedなSetはない
メジャーな言語ではSetは順序性、重複を保証しない集合型の固有名
953デフォルトの名無しさん:2013/09/16(月) 20:57:36.75
>>950
Bagが検索できないといけないという決まりはない
だからこそlock-freeにできるんだよ
954デフォルトの名無しさん:2013/09/16(月) 20:57:41.50
>>951
決まりはないが、RubyもPythonもC#もJavaもSetは順序を保証しない
Ruby、C#、JavaにはSortedSetが別に用意されている
955デフォルトの名無しさん:2013/09/16(月) 20:58:45.95
>>904-908
これで話は終わってたのに、
変に単語にこだわる奴>>909,911
がいたから無駄なレス消費しちまった。
956デフォルトの名無しさん:2013/09/16(月) 20:59:28.74
順序を保証しないと
順序がないを
ごっちゃにしてる馬鹿ばかりだな。

OrderdSetはSetである。

これぐらい理解しろよ。アホども
数学勉強しろ。
957デフォルトの名無しさん:2013/09/16(月) 20:59:52.55
groovyのsetって、どうだっけ?
958デフォルトの名無しさん:2013/09/16(月) 21:02:28.95
JavaScriptのSet

23.2 Set Objects
A Set object can iterate its elements in insertion order.

Orderedです。
959デフォルトの名無しさん:2013/09/16(月) 21:05:34.76
>>953
なんか、Bagはlock-freeにできなきゃだめって
決めつけてないか? どこにそんなこと書いてあるの?
960デフォルトの名無しさん:2013/09/16(月) 21:05:36.84
JavaScriptは「メジャーな言語」とやらには入らないとよ
961デフォルトの名無しさん:2013/09/16(月) 21:06:21.46
しつこく拘ってすまない
>>951の言うことが正しい

>>905みたいな人がいたので、
Setは基本的に順序性を期待するべきでないと言った
962デフォルトの名無しさん:2013/09/16(月) 21:06:28.08
bagが検索可能である必要はないが、並列処理のできないスクリプト言語におけるbagは
効率的な検索ができないならそもそも動的配列と何も変わらなくなってしまうので、検索できないと存在価値がない
紛らわしいからMultiSetと呼ぶべきだね
963デフォルトの名無しさん:2013/09/16(月) 21:08:08.82
>>960
メジャーなが言語の例外
JSはobject型と同様のイテレーションを当てにしてる奴も多いしね
964デフォルトの名無しさん:2013/09/16(月) 21:08:31.31
>>961
だからさぁ。
SetというのはSetオブジェクトのことで、そんなん言語によって違うでしょ。
食いつくとこおかしくない?
というか揉めるって分かっててやったんじゃないの?
965デフォルトの名無しさん:2013/09/16(月) 21:09:34.02
>>962
いやいや、Bagの価値は、まさにこのサイコロの例のように
h[e]+=1イデオムを抽象化できる所にもあるだろう。^^;
966デフォルトの名無しさん:2013/09/16(月) 21:09:49.39
JavaScriptのSetもまだプロトタイプ状態だが順番があるのか。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Set
// logs the items in the order: 1, "some text"
967デフォルトの名無しさん:2013/09/16(月) 21:11:07.02
Setは順番がないと言い切るからダメなんだよな。
順番があるかないかは、実装による。

順番があるSetも、Setの条件を満たしている以上
Setである。
968デフォルトの名無しさん:2013/09/16(月) 21:11:37.33
>>962
最初にこれをBagと呼び始めたSmalltalk涙目www
969デフォルトの名無しさん:2013/09/16(月) 21:12:19.41
>>963
通常objectのforinは順序保証されない仕様のはず
970デフォルトの名無しさん:2013/09/16(月) 21:12:28.16
>>965
どう見ても検索してるじゃんww
lock-freeの方のbagはイテレートとpopのみだよ
971デフォルトの名無しさん:2013/09/16(月) 21:12:36.30
>>967
だから「順序は保証されない」でええやん
972デフォルトの名無しさん:2013/09/16(月) 21:14:02.16
>>970
なんでlock-freeに固執するのかわからん
973デフォルトの名無しさん:2013/09/16(月) 21:16:18.55
>>971
順序が保証されている
SortedSetというSetもある。
974デフォルトの名無しさん:2013/09/16(月) 21:16:21.12
>>966
前スレで使ったけど配列のユニーク配列を取るのに
こうしたいから個人的には順番あって欲しい。

[ v for (v of new Set(arr)) ]
975デフォルトの名無しさん:2013/09/16(月) 21:16:24.38
>>969
知ってるが、当てにしてるソースは多い
976デフォルトの名無しさん:2013/09/16(月) 21:16:41.26
>>972
bagはlock-freeじゃないといけないと言ってるんじゃなくて、
lock-freeを必要としないならbagは検索できないと意味がないと言ってるんだけど
977デフォルトの名無しさん:2013/09/16(月) 21:18:25.18
>>973
それはSortedSet型として扱うべきであって、
Setとして扱う時点で、順序を期待してはいけない
978デフォルトの名無しさん:2013/09/16(月) 21:19:06.84
>>970
別にlock-freeのBagがあって、その目的のために
APIが制約を受けるのはかまないと思うけど、
そうじゃなきゃBagじゃないというもって行き方は
明らかに視野狭窄に陥っている。
>>923ってあんたの方だろう?
979デフォルトの名無しさん:2013/09/16(月) 21:19:26.14
>>975
それ、10年前くらい、それこそ互換性がまだまだだった時に横暴したけど
仕様外だから期待通りに動かない環境が出て
JSでランクAくらいにタブー視されてることになって久しいよ
だからそれとSetの話は関係ない
980デフォルトの名無しさん:2013/09/16(月) 21:21:01.00
>>896
>Counter クラスは、他の言語のバッグや多重集合のようなものです。
>http://docs.python.jp/2/library/collections.html#collections.Counter

>>893だが、結局>>896は上の一節を鵜呑みにして、Bagが何かを知らずに語っていたということで、FA?


>>899
(多重集合としての)Bagはシーケンス、RubyであればArrayクラスで代用できるケースが大半だからね
同様に、集合もHashクラスで代用できるし、(n項関係としての)タプルはオブジェクトの属性として表現できる
だから必要とあれば各自でクラスとして定義することは、それほど難しい課題ではない

とはいえ、集合やタプル、それに加えてリストは頻繁に使われるのも事実だから、
(性能を考慮して)組込みクラスとして提供されるのが望ましかったと(個人的には)考える
981デフォルトの名無しさん:2013/09/16(月) 21:22:05.86
>>975
> 975 名前:デフォルトの名無しさん[sage] 投稿日:2013/09/16(月) 21:16:24.38
> >>969
> 知ってるが、当てにしてるソースは多い

俺は知らない。

多いというのなら一つぐらいだしてくれ。
本当なら別プロジェクトで3つぐらいだしてほしいものだが。
982デフォルトの名無しさん:2013/09/16(月) 21:22:49.55
>>976
で、indexOfの類はできないが検索(要素の存在確認)はできるといっている。
ちなみにsortedCountsはBagを返してるんじゃないぞ?
983デフォルトの名無しさん:2013/09/16(月) 21:23:12.55
for-inだと順序以前にプロトタイプも遡るしめちゃくちゃだわ
今だとObject.keysっていう救世主がいるからそちらを使うにこしたことがない
984デフォルトの名無しさん:2013/09/16(月) 21:24:20.87
>>981
まあまあ。
昔はそんな問題もあったってことで
985デフォルトの名無しさん:2013/09/16(月) 21:26:08.20
>>980
どうしてなにを持ってそれがFAになるのかさっぱりわからん。
986デフォルトの名無しさん:2013/09/16(月) 21:26:24.12
JavaScriptは1,2年で状況がガラッと変わるから
印象ってのは当てにならんぞ
987デフォルトの名無しさん:2013/09/16(月) 21:28:21.20
988デフォルトの名無しさん:2013/09/16(月) 21:28:54.75
>>980
Bagの定義は「順序性が無いが重複は許す集合」だし
PyghonのCounterがそれにあたらないというのは
確かにそうなんだけど、

>>734のSmalltalkのBagを使った例を
Bagを持たないRubyの>>732とかの例と見比べてみると
分かるように、Bagはただそこに要素を突っ込んでいくだけで
h[e]+=1 イデオム相当のことができるってところに意義があるんだよね。

だからPythonでBagをCounterと名付けたり、コレクションとしての
APIを大幅に制限したのは、ユースケースからはまっとう。
もっともBagには重複の多い集合を扱う際のメモリの節約や
高速化といったメリットや使いどころも皆無ではないから、
その切り口で別物という主張ならそれは間違っていないけど
今回の議論からははずれる。lock-freeもね。^^;
989デフォルトの名無しさん:2013/09/16(月) 21:31:59.94
>>979
10年は言い過ぎw
990デフォルトの名無しさん:2013/09/16(月) 21:39:46.40
>>989
まともなJSerなら10年前から分かってただろ

第一次意識改革があったのは、Ajaxが注目を浴びてJSが見直され、
ライブラリもどんどん出て、JSの重要度が大きくなり、
JSLintとかコーディングスタイルが話されるようになり、
そしてChromeのV8はええってなった頃までの時期だな

まあ5年前くらいか

そしてES5が出来、HTML5が注目を浴びだして
ブラウザやデバイスシェアが大きく変わっている今も
テストやツール方面と、入門者に良いコーディングを覚えさせる方向なんかで
第二次意識改革が進んでる
991デフォルトの名無しさん:2013/09/16(月) 21:45:15.98
>>988
>Bagはただそこに要素を突っ込んでいくだけで
>h[e]+=1 イデオム相当のことができるってところに意義があるんだよね。

よく分かった、ありがとう
992デフォルトの名無しさん:2013/09/16(月) 21:45:25.50
数学的には、multisetは集合から自然数への写像として定義可能っていうか、典型的にはそう定義される。
だからPythonのCounterはmultisetの条件は満たしてると思う。
Bagと同じかどうかは知らない。
993デフォルトの名無しさん:2013/09/16(月) 21:51:30.97
数えるというより、lock-freeみたいな適当に放り込んで適当に取り出すだけのものを
bagと呼ぶのは言葉の印象としては自然な気はする
994デフォルトの名無しさん:2013/09/16(月) 21:58:08.02
結局、Smalltalkerは数学の素養も無いのに
無知なまま多重集合について語ってたでFA?
995デフォルトの名無しさん:2013/09/16(月) 22:02:36.33
>>994
BagとMultisetの違いも分からないお馬鹿さん?
996デフォルトの名無しさん:2013/09/16(月) 22:04:21.13
Smalltalkerならぬ、
Bigtalkerだったって事だナ
ガハハ
997デフォルトの名無しさん:2013/09/16(月) 22:05:46.49
結局、>>862は数学の素養も無いのに
無知なままBagについて語ってたでFA?
998デフォルトの名無しさん:2013/09/16(月) 22:11:42.28
Bagはただの多重集合じゃないんだよ、だからCounterとは違うって話だったら
こんなに話がこじれなかったよ。
Counterは多重集合じゃないって言うから(例>>988)こじれたんだろうに。
999デフォルトの名無しさん:2013/09/16(月) 22:12:05.81
ばかばっかだな
1000デフォルトの名無しさん:2013/09/16(月) 22:12:42.91
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。