【PHP,Python】ｽｸﾘﾌﾟﾄ,ﾊﾞﾄﾙﾛﾜｲﾔﾙ38【Perl,Ruby】 2 ：
デフォルトの名無しさん ：2013/09/08(日) 20:47:58.63
< ｀∀´>ﾆﾀﾞｰ
Node.jsはHaskellを理想としつつも
>>前スレ997
言語エンジンレベルのハックが困難って話で
コンバータとはぜんぜん違うよ
>>前スレ998
ジェネレータ部分はまだいいけど
イテレータ周りはまだまだ実装不足
>>5 どこにも妥協したなんて書いてないんだが
自分の都合の良いように解釈し過ぎ
>>5 お前が英語読めない奴ってのは分かった。
お前が議論寄りをも煽りを選ぶ頭の悪いDQNってことは分かった。
GHCはいいけれど、それでもnodeの目的を
GoogleがV8エンジン（JavaScript実装）ではなく
Googleに居るのは、民間人にしては賢い連中ってだけで
>>9 HaskellがWebで使われる言語だったらそうなってたかもな
考えるのも恐ろしいが
>>10 ワロタ
スレタイにも乗ってない言語共が争ってるんじゃねーよｗ
まあ、Haskellの使用も検討するくらいの柔軟さが無いと
Rhino「…………」
>>8 Yesod見る限り、言語エンジンまでハックする必要はなかったみたいだけどね
ネイティブとの連携のしやすさは重要だと思うが
初めから文句つけたいだけの奴だから何言っても無駄だよ
次スレはこれで
お題
stdlibのstdの意味分かってんの？？
性病
突っ込むのはそこじゃないだろｗ
libc.soのrand使えってことか
ネイティブ連携 & 副作用
考え方が逆、
そんなん共有ライブラリを作れる言語なら
オーバーヘッド短縮や循環参照でのメモリリークとか
よくあるコールバックを引数にとって、
ネイティブ系の言語よりスクリプトの方が抽象化能力が高いので
Haskellは何と連携したらネイティブなの？
nodeの凄い所は思想ドリブンで開発が進んだから
おーすごい
>>29 新しいもの作るんならそれでいいが、
大きなAPIだと既にネイティブで書かれてるのを連携させるのが基本だろ。
Node.jsみたいな環境レベルなら当然そうだし。
多くをJSで書かれてはいるけど、
３大柱のEvent、Buffer、Socketは言うまでもなくネイティブだし。
大きなモジュールを連携させるとこを書くのがグルー言語
V8エンジンがネイティブとJSの橋渡しをしてくれるのは当然だけど
そうそう、
それって普通の話だぞ？もっとNode以外も触った方が良い
そう言えば各言語のメタプログラミングの能力はいかほど？
マクロ抜くなよLispが泣くぞ
>>38 JavaScriptは関数定義の引数の数を取得できる。
>>37 ん、誰もNode限定とは言ってないだろ
ただV8みたいな素晴らしいエンジンの重要性を説いてるだけのこと
マクロ入れるとなんでもありになっちゃうし、
マクロがどの程度のレベルを指しているのかしら無いが、
んー、その条件ならSmalltalkが無双すると思うよ
プロキシが無い言語ってあるの？
>>45 君の知ってる全ての言語と
その言語にあるプロキシは具体的に
どれのことか答えなさい。
繰り返すが、君の知ってる全ての言語です。
>>40 よう知らんけどそれっていまどきの言語なら普通じゃないの？
COBOLのCOPY文最強
>>46 うーん、、、bashとかは除くとして
Rubyのmethod_missingのオーバライドと、あとJavaScriptにもProxyあるよね
あとはそんなに深く触ってないけどJavaとかでも聞いたことあるし
method_missingのオーバライド程度がプロキシと呼べるの？？
この話の結論は見えてる
うーん……
演算子オーバーロードの有る無しとかはどうよ？
C++がアップを始めました
関数のソースコード or バイトコードを取得して
演算子オーバーロードとValue Proxyってどっちがどんなケースで合ってるんだろう？
Value Proxy?
>>55 アセンブラでも実行時にコード書き換えできるよなｗ
>>55 関数の上書きとevalができればたいていの言語でできるんじゃない？
ライブラリを動的にコンパイルして
レキシカルスコープとダイナミックスコープの両方が使える
頭の体操になる
スタックフレームを読み書きできる
スコープを直接触れる言語ってある？
スコープを直接触る、ってのが良く分からんが
ギミックとしてはできれば面白いだろうけど、黒魔術にしかならないと思う
１つ上のスコープの変数を
プロトタイプチェーンの
プロトタイプチェーンをちゃんと理解出来てるのは
そうでなきゃお前が困るもんなｗ
func.prototypeとプロトタイプの関係性は大抵の土方には説明困難だろう
そんな奴いねえよｗ
JSに出来ない事ばっかり並んでてワロタw
JSのProxyはそこそこ協力だと思うけど
せやろか？
せやな。
俺年金支払ってなくて電話無視してたら、おばさんが来てAndroid系のタブレットで個人情報、契約内容など見せにきたんだが、
これからはタブレットとか汎用的なマルチデバイスを端末として使っていく流れだろうから
サーバーはクライアントを認証してDBと繋ぐだけだからな
82 ：
デフォルトの名無しさん ：2013/09/09(月) 17:25:16.42
シェルスクリプトの代わりとして使うならどの言語がいいの
WinならJScript、MacならAppleScriptしかなくね
python
ないない
そう言えば.net環境のVBScriptってC#と大体同じだけど
87 ：
デフォルトの名無しさん ：2013/09/09(月) 18:16:40.03
Python万歳！るびい死ねw
Haskell最強
>>83 つーても今のMacはbashが標準で入ってるから、Mac固有の部分が絡まなければシェルスクリプトそのものでいけるけどね
ん？
今のWindowsにはPowerShellとかいうおよそ一般向けではない
あとJScriptとVBScriptという
MSってF#とかPowerShellとかたまによく分からんことするよな
>>91 いや電卓として使うとめっちゃ便利やねん
exprとか爆発してください
元祖はJ++
そもそもVBが・・・
良い意味で、馬鹿でも使える言語って何がオススメですか？
python
>>97 使えるってどの程度を指して言ってんの？
どんなに簡単な言語だろうと、馬鹿に使わせてる限り意味のあることはできないように思うけど。
100 ：
デフォルトの名無しさん ：2013/09/10(火) 01:58:44.25
馬鹿にはるび
JAVAだよ
少なくともHaskellは違うな
>>99 MVCでいうところのM以外のところは
馬鹿でも時間かければ作れると思うんですよ！
デザイナーは別途必要ですけど！
今のWindows系のプロダクトはPowerShellが標準になってる
それにUNIXのシェルに慣れてれば、コマンドプロンプトよりPowerShellの方が理解が早い
素直にbash入れとけって言いたい > win
>>103 そういうことなの？プログラミングするんじゃなくて、ある程度定型化されてるコードを決まりに従って書ければいいってこと？
それだったらその辺のメジャーな言語ならどれ使ったって大して変わんないんじゃね
PowerShellの全コマンドの詳細な解説があるサイトってあるの？
--key=valだっけ、違うな、-key=valだっけ、しまった、-k valだった、みたいなアホらしさ
素直なヤツはWindowsならPowerShell、Unixならbashを使う
正論
>>110 MSDN見ればいい
ただ構文でなくコマンドの解説は
Helpも引数補完もあるのであまり見る機会はない
PowerShellはmanからして高機能
OSが用意したシェルｗ
>>111 機能のカテゴリとか意味別でオプション統一したラッパーってないのかな。なんでもラップするのはよくないと思いつつあれば欲しい
書き込み不可なはずのプロパティに、
すみません、
>>116 Un*xがttyや低レベルのシステムコールしか用意しなかったから乱立してるだけやん。
何もしなかったから乱立した
能力が低い連中のunix嫌いは異常
能力が低い連中のMac好きは異常
各言語の内部文字コード表現は何？
キーボード的には8bitが扱いやすい
↑誰か翻訳頼む
前スレのお題の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)の別名であり、頻繁に使うので短縮形を用意した
他の言語もJSのWorkerみたいにスレッド間のオブジェクトの参照譲渡ってできるの？
129 ：
デフォルトの名無しさん ：2013/09/10(火) 22:30:38.75
できんよ
(プロセスとは違って)スレッドはメモリ空間を共有するから、
現状のRuby2.0でストリーム指向プログラミングに必要なメソッドが不足しているのは
前スレ#518で述べたんだが、
>>127 以外の少し複雑なメソッドの定義追加がうまくいかない....
たとえば、入力ストリームを条件の真偽別に２本の出力ストリームへ「分流」させる
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 は定義されているが、遅延評価ではない親クラスから
継承しているだけなので、上記コードではインタプリタが無限ループに陥ってしまう！！.... これはバグ？
他の言語なら定義できるのかな？
>>130 JSでは排他処理までやってくれるんだけど？
プログラマの責任とかそんな危険な言語使えねえだろ
ストリームを絡めるとストリームの仕様に大きく作用されるから、
ストリームはJSが苦手としてるから、別のお題にしようぜ
>>134 前スレでいくつか頑張って書いたんだけど、そんなにダメだった？
ってか前のお題はもう特にこれ以上話すこともないだろ
>>132 JSのWeb Workerって分散メモリ型だろ？
共有してないんだから排他処理を書かないのは当たり前じゃない？
譲渡っていうのがポイントでは？
メモリ的に分離されたプロセスにデータ送るんだから
>>131 Haskell
import Data.List
main = do
let (xs, ys) = partition even [1..]
print $ take 5 xs
print $ take 5 ys
>>138 >JSのWeb Workerって分散メモリ型だろ？
JSでもスレッドだから共有メモリだよ
ただし、スレッド間はメッセージをハンドラを介して転送するけど、
このメッセージが値コピーで渡される
だから、「メッセージ通信だけで並行処理を実装する」場合に限って
排他制御みたいなややこしい話から解放されるって話
メモリ空間そのものは共有されるから、スレッド間で(メッセージ以外の)
共有オブジェクトへのアクセスが競合すると、結果は保証されない
>>131 Python3
from itertools import *
def partition(f, xs):
ys, zs = tee(xs)
return filterfalse(f, ys), filter(f, zs)
あるオブジェクト自体を置き換えることって各言語できるの？
この手のメソッドがない言語はクソ言語。
>>143 なるほど勉強になった。ありがとう
でも参照できるのが一つのスレッドだけなら
排他処理の一種という気がする
もちろんそうだよ。
なら排他処理を自分で書いてるじゃん
>>132 は何だったのか
このオブジェクトを委譲してねってリストを一緒に渡すだけなのに、自分で書いてる……？
「自分で書いてる」っていうのは排他処理をやってくれないけど自分で仕組みを実装するってことでしょ？
並列計算やってる人達でも
>>151 は多分、オブジェクトに排他処理をかける指定してから、
データを渡す指定をするみたいに、別々な行為として実装されてると思ってるのでは。
Workerの場合はオブジェクトの所有権委譲手続きみたいのがあるわけではなく、
スレッド間ポスト機能の一部として内蔵されてるから、感じ方の問題じゃない？
感じ方の問題とか
>>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と比較すると、
条件判定ループが２度必要だから、効率が悪いね
２つのジェネレータをコルーチンとして交互に呼びあうループが書ければ１度で済むと思うんだけど、
コードで上手く表現できない.....
>>156 危険？むしろ凄く安全な方法だと思うけどな。
複数のスレッドが同じデータに同時にアクセスしようとしたら、
JSのWorkerのtransferはちょっと特殊で、オブジェクトをそのまま移すわけじゃない。
>>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)
>>160 同時にアクセスしたら、一方は「あれれ～？データが空だぞ」ってなるんですね
>>162 根本的にバイナリデータの受け渡しを高速にするためのものだから。
メインでDOMから受け取ったファイルをWorkerで処理したいからWorkerに渡す、
処理が終わったらWorkerから戻す、みたいな使い方。
この時Workerは処理が終わってデータを返したらkillされるかはまあ分かんないけど、
何にもすることが無いから触るようなことありえないし、
さっき書いたようにバッファの部分以外は無事だから、
スレッドで処理してる時にメインでのファイル情報なんかの読み取りに問題はない。
根本的に排他処理じゃないと勘違いして使ってない限りは大丈夫だと思うよ。
マルチスレッドとはいうけどWorkerではDOMが触れなかったり制約があるし、
明確に司令塔-作業員の関係になりやすいからそういうことは起きない。
Workerから子Workerを起動してtransferを多用するような設計くらいになってきた時は
うっかりしてると危ないかもね。
結局チェックは必要だな
チェックいらないケースなら、譲渡なんてしないで
× オブジェクトの参照譲渡
>>131 ってJSお得意のコールバックでどう書くの？
168 ：
デフォルトの名無しさん ：2013/09/11(水) 09:02:34.54
結局のところ退職エントリで叩かれない給与水準が確保できるかに尽きます。
本来連続のストリームを分けるっていう感覚が分からん
>>170 それで特定のデータを複数のワーカーで使いまわすのはどうやるの？
Bufferの参照を複数場所で持てるなら、
セマフォなり何なりで使わないように制御しなきゃダメなんじゃないの？
>>173 同じバッファ領域への参照は同時に１つしか持てない
もし巨大な１つのバッファをいくつかのWorkerで使いたかったら領域を分割して渡す
言語のメタプログラミング機能をみる即興お題でこんなのどう？
>>173 元が
>>128 だから、
そもそもの話が同じデータをマルチスレッドで共有できるかじゃなくて、
スレッド間で巨大なデータを重いコピーをせずに渡せるのかって話だから。
JSでも不動点コンビネータ必要じゃないの？
178 ：
デフォルトの名無しさん ：2013/09/11(水) 11:29:50.44
>>176 いやこっち側のレスの流れは
排他制御しなくていいって話が発端でしょ
>>175 それメタプロなの？
単に記述が短くなるかどうかは大した問題じゃなくて、
構造が大きく変わるか、メタ処理を高度に抽象化できるかがポイントでは？
>>178 ？？？
その話はしなくていいってことが散々書かれて終わったはずじゃ？
calleeはstrictモードでは使えない
>>183 そりゃまあ不満だよね
内容見る限り並列じゃなくて1スレッド(タスク)前提で
排他制御を想定していないみたいだし
だから想定した時にはどうなのって話
あーわかったわかった
>>184 はプログラムのレベルで、
結局スレッドを意識したコードを書かないといないじゃない
そこら辺全て内部的に責任負ってくれるわけじゃないと言ってるわけだ？
配列のパラレル処理みたいなのと比べたら
ずっと明示的で、意識的だと言いたいわけだよね？
そうじゃなくて、そもそも同時にアクセス出来ないから
「データから見て」排他的だねって言ってるわけなのよ
データが同時に触れられるおそれが無いということ
だからそもそも、同時にアクセスしたらみたいなのは無いわけ
>>175 えっ。arguments.callee 使っちゃ駄目なの？
function(n){ if(n==1){ return 1; } else { return n*arguments.callee(n-1); } }(10)
>>185 >そうじゃなくて、そもそも同時にアクセス出来ないから
>「データから見て」排他的だねって言ってるわけなのよ
ああ…
うん理解した…
「データを移動できるか」という話だからデータが中心で話してきたのよ
callee無しで書いてみた
arguments.calleeはもう、ちょっとダメだな……
>>175 Squeak Smalltalk
[:n | n < 2 ifTrue: [n] ifFalse: [n * (thisContext closure value: n-1)]] value: 10 "=> 3628800 "
普通に関数作ればいいのに
>>192 だってそれをやっちゃうとYコンビネータと変わらないじゃない
fac = n => n > 1 ? n * fac(n-1) : 1
>>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 );
無名ですら無い
>>195 それ、無名関数の変数への代入を引数に閉じ込めているだけで
>>194 の屁理屈と何も変わらないよ
せやな、thisFunctionみたいのが無い言語はそもそもダメ
自分のお気に入りの言語で書けないお題だと、
せやな
というか自分が気に入った書き方じゃないと許せない奴が多いだけだな
そこら辺でやめとけ
案外難しいお題だったんだな
>>179 > それメタプロなの？
arguments.callee 相当がない言語で
Ｙコンビネーター的なアプローチを取らない場合、
メタプロ勝負になる
ええー
>>207 eval == メタプロ、メタプロ == eval ってクラスタがあってだな
今実行中の関数のコンテキストをどうのこうのするって
>>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)
lazy云々はもうおなかいっぱい
実行中の関数のコンテキストも第一級オブジェクトかという意味で
JavaScriptもSmalltalkも、argumentsやthisContextを封じられたら
ああも抽象化して書くことは恐らくできないだろうから、結局
>>198 ということだろうな。
これは通常の言語が実は参加できない悪意あるお題ということでFA？
ていうかYコンビネータでいいじゃん
数学みたいに、プリミティブ（公理）は必要最小限なだけあって、
GNU Smalltalk
thisContext はあるけど
Squeak Smalltalk ほど器用じゃないので素直にＹコンビネーターで
(([: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 HaskellでYコンビネータ
Python
220 ：
201 ：2013/09/11(水) 20:10:23.64
; Common Lisp
223 ：
201 ：2013/09/11(水) 20:59:49.67
>>221 例えばって書いてあったからそこは２本じゃつまんないから任意の数OKにしてみた
けちな実装思考で書いたら、例えばどちらにも出力したくない場合は？
とか汎用的には？とか注文付けられて行った時、変更が難しかったり
ガラクタになってしまうんじゃないかと思ったから、
そこら辺は最初から融通が効くように、自分の好きなように作らせてもらった
一応マルチインプットにしろみたいな要求でも
簡単な追加でできるんじゃないかと踏んでる
あと、Nodeのストリーム実装者向けAPIも少し使って、
結果他人が使うAPIを作る感じで書く事になった
NodeのStreamワールドは平坦じゃなくて、
上下に厚いかなり深いクラス関係の抽象化された構造物だから
これは必然的にそうなるかなと思う
>>223 入力が 1 2 3 4 5 6 7 8 9 10 のときに、
偶数奇数にpartitionで分けてから出力するとき、
ちゃんと
>>131 みたいに書いたら
2 4 6 8 10
1 3 5 7 9
の順序で出力される？
>>224 今は改行区切りで判断してるけど
原理的に各ストリームの順番は守られるよ
だって入力が１本しか無いんだから、各トークンの並びがズレるわけがないし
各トークンの並びがずれないのなら、それを上から順番に取り出して
スイッチにかけてるだけだから、出力もズレ用がない
>>225 各ストリームの順序の話じゃなくて、
evenとoddって二つのストリームを用意した後、
まずevenから5個要素取り出して出力して、
その後oddから5個要素取り出して出力できるのかなって
あー、うーんと、自分はストリームは流れていくものと考えてたから結構ビックリした
そうか、そういう使い方がしたいんだよね
本当にストリームのままで
>>131 っぽく書きたかったら
objectModeを使うことになるんだろうけど、今知識０だからまた勉強してくる
そういう話なら全面的に書き直したほうがいいわこれ
Haskellでも、evenだけがリストの尻尾を次々と評価して
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
>>210 メタプログラミングってプログラミングによるプログラミング全般のことだぞ
なんで勝手に枠作ってるんだ？
232 ：
デフォルトの名無しさん ：2013/09/12(木) 07:26:13.31
RubyはC言語によるプログラミング。
枠作らないとLispマクロが最強だから
>>232 ブートストラップ時はともかく、CはCで、アセンブラはアセンブラで
組むだろ普通（セルフホスティング）。
RubyにおいてもCとRubyの境界は曖昧で、
たまたまMatzやささだの実装におけるC依存が高いだけ。
実装者の力量しだいでかなりの部分まで（実用的な速度を維持しつつ）
Rubyで組むことができる。
ちなみにLispもLispで、SmalltalkもSmalltalkで組まれているけれど、
枠作らないとマクロ大大会になりかねない
メタプロに枠なんてないがこのスレ的には必要だね
マクロってあって欲しいものなの？
有能な部下が自分に刃向かう時もっとも恐ろしい敵となる
実際スレタイのようなポピュラーな言語が
>>240 並みのコーダーであろうとしてる限りは必要ない
ダークコーダーになりたいのなら使うべし
マクロなんて遊びでもなきゃ苦々しく書くもんだろ
それではお題です。
お断りします
>>245 こういうことか？ｗ
(set! plus '(lambda (x y) (+ x y)))
(set! (caaddr plus) '*)
(apply (eval plus (interaction-environment)) '(3 4)) ;;12
ASTを直接弄ってるんじゃないけど
>>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 "
AST大大会もマクロ大大会と変わらん
堅物の代名詞だったJAVAにもラムダ入ったしね
アノテーション使ってメタプログラミングする事も多いな
クラスの多重継承って各言語うまく出来るの？
import ast
>>254 オブジェクトに継承先クラスを追加するというイメージをJSでやるとこんな感じ？
Object.prototype.inherit = function(...classes) {
classes.reduce( (o, c) => Object.mixin(o, c.prototype), this.__proto__)
}
obj.inherit(class1, class2, class3)
あれだと汚染の可能性があるからこうか
動的に継承元を変更できるのはスクリプト言語ならではなのかな？
>>175 >もしかしてRubyでもできるのかな？ たぶん無理だと思うけど。ｗ
>>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
だからそれだとYコンビネータと同じだろ
振る舞いを「関数の再帰」では無くせたらお題を完遂したと言えると思う。
最初からループで書けばいいじゃん
せやな。
>>259 > (lambda { |x| if x <= 1 then 1 else (1..x).inject { |acc, n| acc * n } end }).call 5
この式は式内のどこで再帰的にコールされているん？
>>259 これだたのループだよね？ お題は再帰呼び出しなんだが…
>>265 お題も理解できずに馬鹿だなあって言ってるだけだよ
再帰とは書いてあるが再帰呼び出しとは書いてないだろ
ただの関数の再帰の話ならYコンビネータで話が早いと思うんだけど
無名関数を再帰→無名関数内でアキュームレータで再帰的な配列を作成
？？？
次からお題出す人はまずサンプル貼ってね
さすがクイックソートで1000レス引っ張るだけあるな
メタプログラミング、無名関数を無名のまま再帰、イントロスペクション。
プログラミングの勝負がとんちの勝負になってんじゃねーか
>>259 「小難しい」んじゃなくて難しくて理解できなかったんだよな
人格批判はスレチ
280 ：
175 ：2013/09/12(木) 23:01:20.84
Ｙコンビネーター（
>>195 や
>>219 も含め）も
結局は代入している＝名前付けてるのといっしょだから
ほんとは認めたくはなかったんだけどね。
よくよく調べてみたら、arguments.callee ができる
言語が他になかったという罠が。
arguments.calleeは最適化によろしくないから
with並にタブー
>>264 import sys, types
arguments.calleeはキーワードじゃなくて
argumentsオブジェクト自体これからは使わない方がいい
argumentsオブジェクトを使わない理由は
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
紹介文
電子メール：nekogashira@gmail.com
原始メール：〒104-0061東京都中央区銀座1-14-5 エムエル4980号
tw: @nekogashira
fb:
http://www.facebook.com/nekogashira © 2ch.net | Design by Andreas Viklund
>>285 レストパラメータのほうが応用性あってわかりやすいのに
あえてargumentsを使う意味は何？
シェルスクリプトとかの$0と同じで
$1からが起動時に渡される引数なら
>>290 だからこれからの書き方の話って言ってるだろ
＞変わるかもしれない
絶対に変わらないから
保証する
古くからドラフト入りの新構で今見た目に係る変更がありそうなのは
アロー関数くらいのもの、といっても制限を緩くするだけだが
それは来週話し合われる
内部処理はまだまだ詰める作業が必要だが、
構文の見た目はもう変更がないと思っていい
その中でもレストパラメータは最上級に安定している
>>292 お前の保証など誰が信じるかｗ
そもそも、今現在動かないではないか。
こっちの方をどうするか、答えろよ。
逃げやがって。
>>293 Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか
逆にどうしたら満足なの？
ChromeやIEで動くようになったら？
それともNode.jsのV8がサポートしたら？
いつまでもそんなこと言っていたら
未だにES3ですら仕様通り使えるか怪しいぞ
従来のは当然従来の書き方をするしか無いだろ
そこをこれ以上話しても仕方がない
レストパラメータの方が優秀なのは確かだし
今現在Firefoxで使えるし＝FirefoxOSでも使える
環境としては十分、これも確かなこと
> Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか
誰が論の話してるんだよ？
>>287 > レストパラメータのほうが応用性あってわかりやすいのに
> あえてargumentsを使う意味は何？
これ言ったのお前だろ？
rest parameterがわかりやすい、わかりにくいとかそういう話はしていない。
argumentsを使う意味は、今現在多くの
ブラウザ、サーバーサイドで動かないからだよ。
動かないのに、使えというならば
それこそ、非現実的。机上の、おっと卓上の空論だｗ
ES6のラストコールって今年中だから流石に今更大きな変更はないんじゃ？
卓上の空論ｗ
おまえなぁ……
これからの「これ」っていつの話だ？
arguments.calleeがあるJSはメタプロにおいて
301 ：
デフォルトの名無しさん ：2013/09/13(金) 00:22:13.25
プログラムの評価し合いが最後は必ず人格の評価し合いになるのはこのスレの悪いところ
>>299 ごめんなさい
こちらの書き方が悪かった
そちらの言い分が全面的に正しいわ
arguments最高！！
レストパラメータなんてくそ食らえだ！！
で、結局arguments.calleeがどう凄いの？
>>302 何キチガイ化してるのｗ
rest parameterはクソだってお前以外誰も言ってないよ。
単にargumentsが使えない理由は
現在使えないからってだけ。
なんだこいつ
>>303 無名関数を、無名関数のまま
再帰呼び出しできるからじゃね？
非推奨だけど、優れているよ。
ES6の夢を見ないJSerってどうなのよ……
まだ変なこといってる。
>>307 IE6だけじゃねーよ。
最新のchromeでも動かない。
無名関数を、無名関数のまま 再帰呼び出しできたら何が凄いの？
>>310 無名関数でもJITエンジンが進化したら
ループに最適化してくれるよ。
必死のarguments推しワロタ
>>311 それが難しいから非標準になったんだよ。。。
知らないの？？
argumentsって名前の通り引数情報のオブジェクトでしょ？
もう触るな
>>313 知ってるけど？
最適化が難しいからって
それがダメという事にはならんね。
型なし変数だって最適化難しいだろう？
非推奨のcalleeが良くて対応環境の少なさでrestが否定されるのも奇妙な話だ
arguments.calleeだってstrictmodeでは使えないだろ、何言ってんだか。
319 ：
うゆ ：2013/09/13(金) 00:53:58.47
$stdout = open("test_dump.txt","w")
320 ：
175 ：2013/09/13(金) 00:54:41.47
>>314 る厨がうざいから、JSで書けてRubyじゃ書けないお題にしたかったからだよ。
そしたら、他の言語でも書けないわ、
肝心のる厨はお題の趣旨すら理解できない上にドヤ顔でループ書いてくるわ
JSerはrest推しとarguments推しでバトル始めるわでさんざんだよ。
arguments.calleeが最適化に対して原理的な問題を持ってるってことは
324 ：
175 ：2013/09/13(金) 01:03:57.12
あとたぶん、RubyでもRubiniusならきっと書ける。
昔はこういうの
>>324 Smalltalkはともかく、Pythonすげーな
arguments.calleeとYコンビネータでの再帰呼び出し比較すると
>>328 もういいよ。いつまで引っ張ってんだよ。
大事な話でしょ。
＞いつまで引っ張ってんだよ
RubyとJSには演算子オーバーロードは無いんだっけ？
演算子オーバーロードってオーバーヘッドあるの？
operator overloading と一緒にGoogle検索してヒットする順は
いまのところ、Pythonが最強って流れなの？
なんだかんだで通ってるところを見ると一番無難ではあるな
最強はHaskellなんだけど、使いこなせない勢の嫉妬がね…
Pythonは弱点多いけど
>>338 環境選ぶわ動的じゃないわで全然最強じゃねえ
341 ：
うゆ ：2013/09/13(金) 11:23:04.86
スクリプト言語の強さはマジでライブラリの数だよ
uyさんRuby見限ってPythonいっちゃったん？
大分前からPython勉強しているオレ大勝利
>>335 何言っちゃってるの？？？
complex、vector、matrixを3D演算（OpenGLとか）で使うよねってことなんだけど
Pythonはなかなか3系への移行が進まない現状どうするの？
>>345 グイドは一発屋だからPythonの今後に期待するなんて無駄
３系への移行は進んでるよ
>>343 海外にもrubyファンは今でも居て、ましてやここは日本。
エンジニアリングならmatlabなんかのDSLで十分。
寧ろ、scipyなんか蛇足で無駄に学習コストが掛かるし可読性も悪い。
そりゃ海外にもバカはいるわさｗ
RubyはRailsのあの手のMVCを構築した功績はいいとしても
RubyはまずPerlもSmalltalkも嫌いだと正直に言うべき
自分もRubyが人気出てる理由がわからないというか、
同じ道具が使われ続ける理由は、１つのフレームワークにユーザーが集まったことによる堅牢性。
>>350 ポストモダンでアーティスティックな機能がRoRに取り込まれるのが唯一の長所で、
原理主義や保守派にまわるのであれば、schemeなりPHP、javaでも使うべきところ
自分が何者であるかも分からずにRubyを使うと後になって信仰の土台から覆される
>>352 pythonはコマンドラインツールとしての使い勝手が悪い印象
perlっぽさ、unixっぽさが消えて汎用のスクリプト言語になっても、
実際に作業する土俵は(u|l)nix環境であって、日常的に使うなら、
誰しも慣習的記法ぐらいは暗記するかチートシート作るもん
Pythonは確かにシェルスクリプトみたいな使い捨てには向いてない
また精神論か
このスレでやってるようなバカげたお遊びこそが至高ってことだな
やっぱりHaskellが至高だな
パフォーマンスうんぬんいいだしたらスクリプト言語は
>>360 JSだとWebGLとかあるんだから仕方ないでしょう
かなり気になるよそこは
WebGLとかゲームエンジンのために
JSで演算子オーバーロード待ち遠しいけど
今のやり方未満のパフォーマンスになってしまうのだったら随分残念
このスレHaskellとかSmalltalkとか普通に出てくるけど
>>361 そこら辺はalterJSでどうにかなる
次期Ecmaじゃ入らないだろうからその手の使う事になる
JSに来て欲しいけど、パフォーマンスを伴って欲しいってだけで
>>362 Lisperは分別があるんだな
ハスケラは民度が低い
社畜には無縁だけどrubyが一番生きるのはハッキングなんだ
>>365 Lispのコードも結構出てたよ。
Haskellのコードが次元の違う洗練されっぷりだったから
強く印象に残っただけじゃね？
368 ：
デフォルトの名無しさん ：2013/09/13(金) 19:22:06.78
次スレスレタイ案
JSは出来損ないのLispだから、Lispにまとめちゃって良いよ
>>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 ここでいうストリームとは無限シーケンスのこと
シーケンス(=列)とは順序性のあるコレクションであり、配列やリストもシーケンスの一種
>>372 コレクションに対する 選択→射影 のような処理を
一要素ずつ処理するのがストリーム
JavaScriptの x.filter(…).map(…) は
まとめて選択してまとめて射影するのでストリームじゃない
無限シーケンスを引き合いに出すことがあるのはストリームじゃないと扱えない典型例だからで
別に無限シーケンスに限った話ではない
# ストリーミングの例
あー、x.forEachならストリーム？
array.allPlus(1).allMinus(2).……みたいな雰囲気のがストリームってことかな？
いや違うか、流れをせき止めてるよな
Web Audio APIみたいなのが当にStreamなのは間違いないと思うけど
>>369 おそらく4,5年後はこう
【golang,Ocaml】ｽｸﾘﾌﾟﾄ,ﾊﾞﾄﾙﾛﾜｲﾔﾙ67【R,JS,QCL】
>>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の間で何かしら受け渡されるものがあると考えて、
それを抽象的にストリームと呼んでるわけ
その実体はイテレータだったり関数をラップしたものだったりする
オブジェクト指向混ざってくるとphp以外はなんか書き方がしっくりこない
>>371 にアンカー等の間違いがあったので訂正
まず冒頭の行：
X:
>>121 で書いたストリーム指向プログラミング向けメソッドについて、
O:
>>131 で書いたストリーム指向プログラミング向けメソッドについて、
次は codepaste 上の行番号：
X: **** このRPN計算機の場合には関数 RPN::Processor.calculate #157..246 ***
O: **** このRPN計算機の場合には関数 RPN::Processor.calculate #167..172 ***
>>386 を再訂正.... orz
X:
>>121 で書いたストリーム指向プログラミング向けメソッドについて、
X:
>>131 で書いたストリーム指向プログラミング向けメソッドについて、
O:
>>127 で書いたストリーム指向プログラミング向けメソッドについて、
いちいち訂正なんかしなくていいよ。つーか、いいかげんにしろ。
PHPはWebでやることを想定した説明してるけど
どゆこと？
なぜかWeb開発することを前提にして話してる奴がいるけど
ただWeb開発したいってだけなのにボロクソいいますね
394 ：
382 ：2013/09/13(金) 23:07:27.74
括弧省略してないし、アロー関数も->じゃないし、ES6のつもりだと思うよ
Firefoxなら既に結構動く
>>394 も一部未対応の機能があって断念したけど８割がたES6で書いた
ES6？なんて恐ろしい子！
>>394 Standard output is empty
coffeeクソだよなあ
>>350 RailsのMVCは実は不完全
短く書けるRubyだからなんとかなっているだけ
>>402 >RailsのMVCは実は不完全
では、Web開発における完全なMVCを実現したフレームワークは存在するん？
そして
>>402 のいう「完全なMVC」の完全な定義は？
不完全も何も、WebのアレはあくまでWebMVC
405 ：
394 ：2013/09/14(土) 00:46:59.31
>>401 > coffeeクソだよなあ
言語としてならクソではないが訴求力がない。
一部JavaScriptが嫌いな人にウケているようだが
JavaScriptよりマシという理由で使っているだけで、
CoffeeScriptを選んでる人はかなり少ない。
JavaScriptは標準規格があり特定の企業・個人に依存しているものではない。
だからみんなで寄ってたかって改善が進んでいる。
CoffeeScriptのコンセプトはJavaScriptの未来の姿であるが、
それはJavaScriptが進化すればCoffeeScriptはいらないということでもある。
将来CoffeeScriptは必要なくなるのに、個人が作ったレベルのものに力を入れる理由がない。
>>404 嬉しいねぇ。
ウェブのMVCとGUIのMVCが
違うものであると認知されてきて。
俺はGUIののMVCから入った人間だから、
ウェブMVCみて、なにこれ？どこがMVC？
単にレイヤー分けてるだけやん。ってずっと疑問だった。
あるとき、MVC2とかいう言葉を知って、
やっぱり違うものであってるんだなって確信が持てた。
レイヤーわけはダメではないし、むしろいいものであるけれど
GUIのMVCとは別のもの。別の名前をつけるべきだったもの。
で、レイヤーわけの話を勉強していくと
Javaがはるか昔に通った道なんだなぁって思えてくるよ。
409 ：
394 ：2013/09/14(土) 01:21:36.20
世界が狭すぎじゃね
Webキチは帰って、どうぞ。
コントローラじゃなくてリソースハンドラとでも呼べばよかったな
つーか、ウェブ用の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」が登場します
>>409 > GUIにもHTMLの並が押し寄せてるし、むしろ基本となるのはWebMVCの方で
> 従来のは時代遅れだよ
要するにJavaScriptで実装する
フロントエンド部分の話だろう？
サーバーはJSONを返すようなAPIだけを提供すれば良くなったので
今までの（サーバー側の）ウェブフレームワークが必要な理由がなくなってしまったんだよ。
MVCはフロントエンドで完結してしまう。
ObserverとかWebComponentsの話？
フロントエンドMVCが普及すると
別にMVCにかぎらずテンプレートエンジンなんて要らないと思う。
すべてフロントエンドでやってしまうと
サーバーサイドのウェブMVCはMとVとCをはっきり区別できていて分かりやすい
本来は、Vはデフォルトで充分で後はMとCだけ作ればいいと思うけど
本家のMVCって実装の都合だからな
つうか普通に書いたらMVCっぽくならね？
MVC難しいよ(´・ω・｀)
Smalltalkはイベントの仕組みが今時のGUIフレームワークとかHTML DOMとかに比べて低レベルだったから
MとかVとか多すぎてギザギザしてるスレだな
結局 データ・HTML・トランザクション がベストなんだね
webドカタ臭いスレになったな
>>424 Cが主導権をもつMVCは古いってことかな
だからMVVMだと
個人的には古い方が良いと思うけど
イベントハンドラをVに書いたらそれがCだよ
なんも考えないとVとCがよーくっつくわ
HTMLの場合はC-VC-DOMとなると考えた方がいい
馬鹿のすることっていうけど、モジュール化とかフレームワーク、ライブラリ使ったら
クライアントGUIのMVCとWebMVCをごっちゃにすることこそが馬鹿のすること
DOMはMじゃなくてVMだろ
紛らわしいからもうWebじゃない方のMVCのCはイベントハンドラと呼べばいいよ
- (DOM(V) - Element's interface(C)) - Element(M)
Web Componentsの思想に則ると、
439 ：
デフォルトの名無しさん ：2013/09/14(土) 14:55:59.26
13時45分に打ち上げ予定だったイプシロンロケット試験機は、
12345679x72
>>418 > サーバーサイドのウェブMVCはMとVとCをはっきり区別できていて分かりやすい
分かれているのはGUIのMVCも同じで、
サーバーサイドのウェブのMVCは分かれているかどうかが焦点ではなく
分かれているものの関係がおかしいんだよ。
本来のGUIのMVCは相互にイベントを通知することで
システムが成り立っている。
でもウェブのMVCは一方通行。
だから本来のMVCとは違うものと言われてる。
> GUIアプリの構造はMVVMの方が適切
MVVMはMVCの改良型。
適切かどうではなくMVCをもっと良くしたもの。
>>438 成功オメ
>>439 そりゃ前回だろ
>>440 Rubyはそんな汎用的な使われ方するものと見られてないし、
世界でポピュラーになってきたのもここ最近
>>435 > 紛らわしいからもうWebじゃない方のMVCのCはイベントハンドラと呼べばいいよ
ウェブのMVCはルータでしかないってよく言われてるよ。
そもそもGUIののMVCの方が先に出来たのだから
ウェブのMVCの法を名前を変えるべき。
ROUTER -> LOGIC -> VIEW の三層アプリケーションという方がいい。
ウェブのMVCはVIEWの部分を
App
MVCの肝はドメインとプレゼンテーションの分離であって、これはWebでもGUIでも変わらない
>>447 本来のMVCの肝は
オブザーバーパターンだよ。
つまり、（一つまたは複数の）ビューがモデルを参照し、
モデルに変更があったら、複数のビューが全て更新される。
そもそもこの仕組みを作るために考えだされたのが
MVCなんだから。
>>448 全くの逆で、ドメインとプレゼンテーションの分離という大きな目的が先にあって、その実現手段として
（オブザーバーを用いた）古典的MVCの実装がある
単なる一実装と、MVCの本質とを混同している
コントローラーが処理主体になるのがMVCで
オブザーバーがおまけというのはある意味正しいが、コントローラーが処理主体は意味不明
>>451 VとMを抽象化してCが処理主体になるのがMVC
オブザーバーパターンを使わない場合動くのはC
>>452 たぶんそれも448と同じで特定の実装にとらわれた考え方
MVCにはどれが処理主体といった考えはないよ
>>453 そうなるとオブザーバーパターンが肝になる
オブザーバーはMVC実現手法の１つで肝ではないね
>>454 また、訳の分からないことを…
そもそもオブザーバーパターンが肝なら、MVCなんて言わずにオブザーバーパターンといえばいいだろ
オブザーバーは飽くまでも、古典的MVC実装の中の一構成要素にすぎない
>>456 何で疑問に思うんだ？
実装を考えればすぐわかるだろ
オブザーバーが古典的？？
時代は繰り返すって言うね
MVCに発案者なんて無い
Smalltalkに代表される「GUI MVCが真のMVCだよ」厨が勘違いしがちなのは、
コントローラーが主体でもなく、オブザーバーも無しで
GUIアプリでMVCと区分けするのは間違ってる
オブザーバーパターンで実装しなくてもいいってだけで、
サーバーサイドのMVCではビュー＝テンプレートなわけだが、
じゃあオブザーバーパターンがMVCの本質っていうのは撤回するんだな？
撤回するまでもない
インタラクティブ性とMVCとは直交する概念
>>468 MVCはシステム全体の設計の話。
オブザーバーはシステムを作るときに適用するパターン
撤回するとしたらオブザーバーパターンでなくてもいいが
オブザーバーパターンで実装するような設計になっているもの
と言い直すだけだな。
だから言い方が変わっただけ、MVCの本質は「複数のビューが
一つのモデルに紐付いていてビューがモデルを更新し、
またモデルの更新を全てのビューが検知し表示を変えること」
えーとさ、長い説明に、わかり易い名前を付けないかい？ｗ
ウェブのMVCは誰でもやってる当たり前の事を言ってるに過ぎないけど、そういう当然の開発手法に名前を付けて知識共有するのがデザインパターンの役割だから
>>471 > だから言い方が変わっただけ、MVCの本質は「複数のビューが
> 一つのモデルに紐付いていてビューがモデルを更新し、
> またモデルの更新を全てのビューが検知し表示を変えること」
これはオブザーバーの説明をしただけだろ、だったらMVCなんて言わずにオブザーバーと言えばいい
つうか、「システム全体の設計」とか「システムを作るとき」とかまた訳の分からない概念を持ち込むなよ
MVCは「思想」で、古典的（Smalltalk）MVCは「実装」
>>471 だから、インタラクティブ性とMVCは直交するって何度言ったら。
やたら思い込みの激しい奴だなぁ……
ブロードキャストはおまけって意味が分からないのかな。
パターンに当てはまらないと元の定義もねじ曲げるとか
このスレでデザパタについて語って意味あるの？
デザパタをとりあげる意味はあるだろう。
>>473 MVCはMとVとCの話。
オブザーバーはMとVの関係のこと
違い理解できたよね？ OK？
競争原理と知識共有は矛盾している
MVCはその一部にオブザーバーパターン（を使うことが多い）で実装するが
MVCはデザパタじゃなくてアーキテクチャな
>>479 481も言っているようにオブザーバーが使われることが多いというだけで、直接は関係ないよ
例えばオブザーバー（通知）を使わずに、ポーリングで毎回モデルをチェックするような実装も考えられるけど
これもMVCには違いない
これは変化が多いゲームなんかでよく使われる手法
それから、オブザーバーが適用されるのはMとVだけとも限らない
飽くまで、古典的（Smalltalk）MVCの実装においてはMとVだけど、（MVCの一種である）MVPパターンでは
MとP（MVCでいうC）にオブザーバーが適用される
ポーリングでもなんでもいいんだけど
ビューからモデルを更新とか何を言っているんだか…
>>487 「ビューはマウス操作やキーボード操作のようなユーザからの入力について
知っているべきではありません」とあるし、ユーザ入力を引き受けるのは
たぶんコントローラなんだよな
ならビューからのモデル更新のトリガって何なんだ？
上の説明からすると、ユーザ入力じゃないんだろ
ビューからのモデル更新っていうと、Tclや.NETみたいに
モデルとビューの入力／表示領域がbindされていて自動的にビューとモデルのデータが
やりとりされる状況をさしているのかと思ったが、どうもそのコントローラの
説明だと違うようだな
>>488 結論出てるんじゃねーの？
ユーザー入力はビューじゃなくて
ビューからモデルを更新するならば、
ユーザー入力 → コントローラ → ビュー → モデル
だろう？
490 ：
489 ：2013/09/14(土) 19:47:22.42
>>487 は少なくとも現在の一般的な（例えばwikipediaの）MVCとは違うね
で、こういうふうに様々な実装があるからMVCは「思想」なんだよ
>>484 のように特定の実装のみをMVCと考えるべきではない
>>489 なるほどね
でもWeb以前のMVCってゲームの世界ぐらいでしか見たことないかも
MFCみたいな化石ですら「ドキュメントビュー」とかいうアーキテクチャを
使っていて、ユーザ入力を一手に引き受ける「コントローラ」はなくて
あったのはビュー毎の「イベントハンドラ」
旧VBとかDelphiとかも含め昔からGUIツールキット的なものは全部そうだったと思う
>>492 > でもWeb以前のMVCってゲームの世界ぐらいでしか見たことないかも
最近の人だねｗ
1995年より前はウェブ自体あまりみなかった。
その頃何を使っていたと思ってるんだ？
>>494 うんWindowsが無かったころのことは知らない
Windows以降はもうコントローラがなくなってたよね
ゲームプログラミング以外では
>>493 それは記事も読んでの感想？
あとenの方が分かりやすい
余談だけどenの方には
Trygve Reenskaug introduced MVC into Smalltalk-76 while visiting Xerox Parc, in the 1970s
ってちゃんと書いてあるね。
>>461 みたいな誤解も生じにくい。
ん？
>>498 MVCの起源がSmalltalkにあるのは、よく知られた話
ただ、それがSmalltalk-76であったのは(自分は)知らなかったけどな
あと、書籍「ソフトウェアアーキテクチャ: ソフトウェア開発のためのパターン体系」にも、
以下のように記されている：
MVCを創造し、Smalltalk環境にそれを適用した Trygve Reenskaug に感謝する。
ネットだけでなく本も読まないと、いつまでも子供のままで成長しないよ
現在の視点で見れば、OSモドキのショボ環境にモダンとは程遠いゴミ構文のSmalltalkだけど
>>498 >>497 の部分は
^ Notes and Historical documents from Trygve Reenskaug, inventor of MVC.
^ "A note on DynaBook requirements", Trygve Reenskaug, 22 March 1979, SysReq.pdf.
が引用元と書かれているのだから、疑問があるなら読んでみたらどうだろう。
>>498 逆だ、逆。
ウィキペは知的レベルの低い人間が参考にすることが多いから
通常なら知られている基本的な事実が欠落しているjaみたいな記述だと
>>461 みたいな勝手な解釈も生じやすいということ。
こんなこともわからんのかね、ちみは。
>>500 昔も必ずしも最先端ではなかったけれど、アラン・ケイを筆頭に、少し目先の利く人間が
自分のアイデアが有効かどうかを気軽に実装して実地で試せるプラットフォームではあったね。
現在主流のWIMPなGUIの要素（ポップアップメニュー、マルチフォント、モードレス編集）しかり、
メタオブジェクト、分散オブジェクトしかり、IDEしかり、デザパタしかり、アジャイル手法しかり。
今でもそういうところ完全には失われていなくて、たとえばTraitsや、
RubyのRefinementsの元ネタのClassboxesみたいな機能も最初Smalltalkで試されてるし。
たんに古くからあるとか仕様がショボいとかいうだけの理由で、そう馬鹿にしたものでもない。
飽きた。なんか面白いお題ないの？
>>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
他の多重継承を持つ言語では大丈夫？
>>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"
JSのプロトタイプベースが一番柔軟にクラス定義出来ると思う。
柔軟すぎて、形が違いすぎてもはやクラスじゃないっていう人も多いけど、
こういうことも出来るわけだし。
>>256 実際RubyやJSで多重継承とか複雑なことやるコードなんて書く機会あんの？
>>505 それのどこがバグなのかよく分からん。
C2.m2は普通に呼び出せているから問題ないとして、 C1.new.m2が未定義なのがダメなん？
でもそれはm2が定義されているのはincludeしたM1ではなくて、後から定義されたM1だからで、この2つが別物とされてるからじゃね？
仮に後からM1にメソッドを動的に追加してるならともかく、新しく同名のモジュールを定義してるんだったら
その挙動で全く問題無いと思うんだけど。
>>505 #p C1.new.m2 #=> undefined method `m2' (NoMethodError)
これが呼び出されるほうが異常に見える
対話的に使うときには、
>>506 のようになっているほうがいいと思う。
>>511 単に
>>505 が「多重継承 と Mix-in の違い」を理解できていないだけだから、気にすんなw
>>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とは別物だから
>>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 "
includeされた時点で定義されてるメソッドのみがmix-inされてん
>>516 RubyはPythonと違い、include M2後もM1のobject_idは変わらない
少なくとも見かけ上、include前後でM1は同じオブジェクト
>>517 include M1した後でもM1に新たに定義されたメソッドはC1からコールできる
>>508 JSはともかくRubyは継承しまくって馬鹿でかい神様クラスを作るのが正しい使い方だ
C#はむしろ直交性を重視するほうだろ
ほんとだ。
>>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
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(){}
いや、理由も同じか、
Rubyって同名のクラスを何回も定義したら最後の定義が正とはならず
>>521 最後は p M1.equal?(C1.ancestors[1]) だろ？
それでも true だけどな
>>524 動的言語というのはそもそもそういうもんだ。
多重継承とかトレイトとか別にいらんよね
>>257 みたいなことって他の言語でもできるの？？？
>>526 最新10レスぐらいで既に動的言語のPythonやJSでそれは否定されてますが
>>524 動的言語なら素直に実装したら上書きされて全く別物になるのが自然だと思う
元の定義に追加されるようにするのも意図してやってんなら動的言語としては全然アリだが
そのどちらでもないから問題だって話でしょ
>>529 ん？
動的言語を標榜するPythonやJSだが、
ことクラスの定義追加については再定義になるという
動的言語っぽくない挙動をしてるって発想は出てこない人？
>>531 なんでそれが動的言語っぽいのかよく分からん。
動的言語のクラスにあとから何か追加したいんだったら、
class Hage
{
// 何か
}
Hage.Method = 何か
Hage.Member = 何か
と書くのがそれっぽいと思うぞ
わざわざ再定義したのに、既に定義されているクラスが拡張されてない！とか怒るのはRuby脳？
>>531 自分で動的言語の処理系作ってみりゃわかるが、上書きで別物になるのは自然
追加の方が意図してわざわざそうなるように実装してる
関数定義との一貫性から、クラス定義も
せやね
言われればたしかにそれで自然だし、だから上書きでもいいと思うけれど、
moduleとかclassとかやめて
つまり、こんなん↓が出来るのは動的言語でも少数派なのかっ！
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 "
Rubyだとスーパークラスのすげ替えのところでエラーになる。
上書きだと単なるグローバル変数だから
いやグローバルがどうというより
「グローバル変数に強く反対」したのは実行時ではないよ
グローバルよりも大きいスコープの
>>539 Rubyって動的言語なのにスーパークラスのすげ替えも出来ないの？
在日への生活保護 役人発表では800億円（韓国・北朝鮮籍）
※しかし川崎市と大阪市の異常過多分だけでもこの数字は軽く超えており、
本当の数字はタブー。個人的には１兆円は超えていると推測。
(帰化朝鮮人や、それによる不正受給を含めて)
※民主党政権の３年間だけでも0.9兆円増
オリンピック招致(決定までの費用) 70億円 予測経済効果３兆円超
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 そもそも、日本に借金をこさえさせたのは小沢一郎（たぶん在日帰化）。
547 ：
デフォルトの名無しさん ：2013/09/15(日) 13:13:14.14
>>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 // (){}
プロトタイプベースってJavaScriptしかないの？
>>549 著名どころでは、SELF や NewtonScript があった
一昔前だとSelf、それを参考にしてJavaScriptができたって事だね
Prothonってどうなのよ？
どうとは？
Prothonとかの言語がJSに続いてプロトタイプベースの波を起こせなかったのは何故だろう？
なぜだろってJSで事足りちゃうならそっち使うだろ
つまりプロトタイプベースが活躍できる範囲はJSで十分ってこと？
ぶれないプロトタイプベースと、方言が多すぎるクラスベース
簡単に言えば
Luaはプロトタイプベースだろ
ないない
Luaがどう躍進するかより、
そんなこと言ってるけど他の言語は今後10年廃れない目処あるの？
Rubyは廃れていくだろうけど・・・
COBOLみればわかるけど、
廃れやすさってのは、どれだけの
COBOLくらいだと廃れてるって言われると思うけどな
C#…3.0と4.0で他言語をパクリ尽くして5.0ではパクるものが枯渇。6.0は出るか分からない。Mono次第。
C++、Java、JSは有名で
>>568 > JS…各ブラウザ(主にIE)間の合意を取らないと拡張できないため、いつまでも予約されたクラスの出番なし。
え？ IEの合意なんかとらずに
どんどん拡張されてると思うけど、
ちゃんと現実を受け止めてるかい？ｗ
>>570 Mozillaが勝手にどんどんやってるだけだね
GoogleもMSも無視してる
>>563 C++はあいかわらず堅調でしょう。
Javaは代替が現われないかぎり安泰。
PHPは嫌われつつもこれまでの貯金であるメンテ案件でしぶとく生き残るんじゃない？
いずれにせよ分相応の評価を得ている言語達なので10年やそこらで
どうこうなることもないでしょう。
ひるがえってRubyはいっっときのRailsバブルで実力にそぐわない
過大評価を得てしまったからここからが踏ん張りどころ。
ただ本スレや公式MLの急激な過疎化をみるとこの崩壊を食い止めるのは難しいと思う。
Rails案件も軒並み炎上しているし、悪評は一気に広まりつつある。
1.9への移行がかなりのブレーキになってたのに、mrubyにリソースが分散されたのも痛い。
>>571 Mozillaが勝手にやってる？
そうか君は知っているのだな。
なら言ってみなさい。
Mozillaが勝手にやっている拡張とは
どの事だね？
> Rails案件も軒並み炎上しているし、悪評は一気に広まりつつある。
>>573 俺Chomeユーザーなんだけど、確かJS1.5もしくは1.6以降は実装されてなくね？
FFにはあるけど他のブラウザにはないメソッドとかよくあるじゃん。
>>575 それが何なのか聞いているんだよ。
それはHTML5の標準メソッドだろう？
ならChromeも追尾するだろう。
IEも追尾するだろう。
ほら見ろこのようにどんどん拡張されてるじゃないか。
>>568 ECMAはブラウザとは繋がってないよ
今あるWebコンテンツを壊さないっていうのは意識してるけど
新しい機能の導入には貪欲的だよ
エンジンのことも考えるけど、V8とSMがほぼ半分ずつで
フィードバックと最適化について、だからそれが遅れてるChakraは発言力無い
発言力としてはGoogleとMozillaがほぼ半分ずつで、
MSはMathの拡張とか周辺機能には意見良く出してるけど基本構文は受け入れてる
class構文についても今となっては導入する方向で一致してる
仕様が結構大きくて、いろんな部分と絡んでるから実装は遅めになるかもだけど
それでも１年以内にChromeとFirefoxにほぼ完全に実装されるはず
一人が決めるんじゃなくて
Mozillaが勝手にやってるとはまたアホなことを
>>578 それを見ればわかるじゃないか
IEもChromeも無視なんかしておらず
バージョンが上がるとサポートされてる。
Python以外はスレタイにあるのは全部枯れてるな
>>574 ソースって程のものはないけれど、
知り合いのそこそこのスキルのあるＰＧの多くが
ここのところ連続でRailsの炎上案件の火消しに投入されて
のきなみ疲弊しているのをみてる
Mozillaからしたら元々自分たちの言語だしなあ
>>581 しかし動きは相当遅い
全ブラウザで使えるようになるのはいつになることやら
>>583 俺の知り合いはJavaやPHPで地獄を見続けてるんだが…
実は業界の問題であって、言語の問題じゃないんじゃね？
MozillaはJSの人柱だから、今も昔も、
>>582 Pythonはいい言語なんだけど、
LispのS式の柔軟性やSmalltalkの動的性ほどは
「これ」ってウリがないのが残念
守りにまわっちゃって「ウリ」をいろいろと諦めているのに
Mozillaが実装しているのは、それが新しい仕様を
作成するための条件の一つだからだよ。
勝手に実装しているのとはわけが違う。
http://www.html5.jp/trans/whatwg_html5faq.html > 実装者に、その機能を実装することをコミットしてもらってください。
> もしあなたが複数の実装者にその機能を実装してもらうことができないなら、
> 実験的に最低でも一つのユーザーエージェントに実装してもらうようにしてください。
> 実験的な実装は、公式に利用可能でなければいけません。
JavaScriptの世界は皆が議論して、仕様を決めてから実装するような世界じゃない。
まず誰かが実装する（それがMozillaが多い）
最初の一人が実装した時、その他が実装してないのはあたりまえじゃないか。
MSのスタンスとしては、標準になったものを実装するという考え。
だから、Mozilla、Chrome、標準化、MS という流れになるのが多いだけの話。
で、そもそもなんだっけ？
JavaScriptの世界は常に拡張され続けているってことでよかったかい？
>>585 Chrome31で見ると29より何個も緑増えてるよ
着実に進んでる
ただV8は仕様変更がありそうなものはおいそれと実装したくない
本格的に実装が始まるのはラストコールが出てからだろうね
でも下準備はしてるよ、ES6で究極に重要なSymbolsの実装は早々に済ませてるし
いくつかの仕様も実装進めてる
最近だと配列内包にGOが出た
Railsの案件ってどういう炎上すんだ？
>>590 いやいや、ES4の頃一旦棚上げ（没）になった皆が議論した仕様を入れてるだけだよ
配列内包はfor-ofとは絡んでるけど、単独機能だから実装はしやすいでしょうね。
>>593 だから？
ES4で議論された機能が復活する。
それもまた拡張の一つの形だということかい？
>>592 ヒント：Java土方がRails使わなくちゃいけない案件どうなるか
3大勢力が実装していて
>596
>>595 ＞JavaScriptの世界は皆が議論して、仕様を決めてから実装するような世界じゃない
ここの部分が語弊があるということ。
>>599 語弊があるというのなら、お前は今拡張されている
機能（上で出ていたES6の機能）が
全てES4で棚上げされた機能だと証明する必要があります。
はい、やってください。
>>597 今は仕様についてはそんなに競争してないな
DOMAPIまで入れるといまだ苛烈だけど
自分の意見こそが絶対じゃ楽しくお喋りできないね
>>597 それがいいことなのかそうでないのか、微妙なとこではあるけどね
実装技術は進むが、新規仕様策定で揉めることにもなるわけで
>>605 JavaScriptは、今まで進まなかった時代を経験しているので、
今の驚異的なスピードは正しいことの証拠だと思ってる。
>>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の移行劇は、旧バージョンとの互換性を無視した新バージョンを開発し、
そのあげくに数年前に開発を終えた旧バージョンを未だに切り捨てられないどこかの言語とは対照的
>>607 うん、それ規模が小さいからできることだよ。
> このRubyの移行劇は、旧バージョンとの互換性を無視した新バージョンを開発し、
うーん、やっぱり旧バージョンを切り捨てるって凄く困難なことなんだね
このRuby厨の必死さがRubyの先行きの暗さを物語っている
>>611 旧バージョンを切り捨てないほうがすごく困難だと思うけど？
>>612 いやいや、アンチRuby厨の必死さには負けますわよw
Rubyの恐ろしさは、単に今までの文法が廃止とかそういうレベルじゃないぞ。
>>613 だから、後方互換性を意識した仕様変更を考えるんだよね、普通の言語は....
>>615 こけるgemもあれば、こけぬgemもある
>>616 未来は誰にも予測できないんだよ。
後方互換性を維持するのが難しい時ってのは
絶対にやってくる。Rubyもあったじゃないか。
後方互換性を維持するのが難しいと思った時、
諦めるのと、諦めないの、どっちが困難だと思いますか？
Matzは内心ドカタ嫌ってるんだろうなあ
>>617 先生、MySQLアダプターがコケる場合はどうすればいいんですか。
RDBを変えればいいんですか
>>628 諦めろ。それが一番（開発者が）楽な道だｗ
>>615 いやあ、普通は「今までの文法が廃止」のほうが恐ろしいだろ
それこそ、単なるサードパーティ製のパッケージのバグとはレベルが違う影響度だよ
互換性を切り捨てるのは（作業的に）簡単だけど、（しがらみ的に）困難だよ
JSみたいに後方互換性を維持するしか選択肢がない言語もある
>>624 つまりRubyの世界では、しがらみ（互換性）を
何も考えないから簡単なわけですね？
>>618 仮定を元にした予測に答える価値は無いな
例：
明日、世界が破滅します
諦めるのと、諦めないの、どっちが困難だと思いますか？
>>625 いや、今のJSの世界知ってるかい？
全く違う言語からJSに変換することで
互換性が全くない言語すらできてるんだよ。
>>627 仮定を元にした発言はしないという
言葉は聞いたことがないが、
仮定を元にした予測ってなんだよｗ
予測は全て仮定だろ？
どやセリフでも言ったつもり？
それは変換後のJSに互換性があればいいじゃないの？
Rubyが駄目なのは後方互換性を放棄しているからじゃない。
>>626 >>624 的に言えば、逆だろw
Ruby：（しがらみ的に）困難な、互換性を維持する道を選択した
Python：（作業的に）簡単な、互換性を切り捨てる道を選択した
結局どこまで将来見据えて言語設計できるかってことに尽きるね
>>627 あー逆だったｗ
仮定を元にした発言はしないという
言葉は聞いたことがあるが
仮定を元にした予測に答える価値はないってなんだよｗ
予測は全て仮定だろ？
どやセリフでも言ったつもり？
>>632 >C言語で書かれたRubyをJavaどころかPythonで書きなおしたら速くなったという事例すらある。
ソースは？
それとも
>>632 の脳内かなw
C#/VBはメジャーな言語としてはむちゃくちゃ急進的だけど後方互換性保ってるじゃん
>>628 意味不明
新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ
既にエンタープライズ用途のrails出てるだろ
>>634 その将来の予測が外れた時の
対応をどうするかってことのほうが重要だろ。
ほんと、大丈夫かなぁこいつ。
>>638 > 新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ
そんなもん、両方のエンジンを搭載すればいいだけの話。
何かのフラグ用意して立っていれば、
実行エンジンを切り替えれば良い。
簡単なことだ。
>>631 ざっと見たけどこれ凄いな。
他の言語でも活用できるんじゃ？
>>637 あれだけ追加してもforeachのキャプチャの挙動変更以外、互換性放棄したことないよな。
でもある意味C#とVBは優秀なコーダーと糞コーダーの二極化が激しいな。
優秀な人は関数ポインタやLINQ、型推論、ミックスイン(拡張メソッド)とか使いこなしていいコード書くのに、
特にVB6やJavaから来た人間はもうゴミみたいなコード出してくる・・・
>>642 フラグを用意するってのは後方互換性に配慮する最後の方法なんだけど？
つまりフラグを用意してる時点で後方互換性を守ってるじゃん
変なこと言うねえ
>>641 Topazってスレッドもファイバーも切り捨てた軽量版Rubyのこと？
そんなの引き合いに出されてもねぇ…
>>641 それって、時間計算量と空間計算量のトレードオフであってる？
>>645 頭大丈夫か？
目的はなんだ？
達成出来てるかどうかの答えはなんだ？
お前はなぜ制限を設けようとするのだ？
あれしちゃいけない、これしちゃいけない
頭がかたすぎるぞ。
>>641 なーんだ、RailsアプリをDjangoへ書き直したら、劇的に速くなった話だと脳内変換してたよw
>>640 外れた後の対応がうまかった言語なんてあったっけ・・・？
>>650 上手いかどうかではなく、
外れた時に、諦めるのは
最悪のやり方だということ。
>>648 いけないなんて言ってないでしょ
こちらは、JSは後方互換性を捨てられないと言った
そちらは、それに反発して、フラグを用意する案を挙げた
こちらは、それも後方互換性を守る方法じゃんと突っ込んだ←今ココ
自分の主張理解して話してる？
適当に目に触ったレスにイチャモンつけて騒いでるだけだから、
結局何を騒いでたんだっけ？
>>652 2chで理路整然とした会話が可能とか思っている時点で終わってる
飽きたんで、お題をたのむ。
>>651 そりゃ当然そうでしょう
敗戦処理より最初の作戦の方が重要だとは思うけど
>>652 お前こそ自分の言った言葉忘れてるの？
> 新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ
って書いただろ。
だから俺は、反論して新しい規格を採用したエンジンで
過去のスクリプトが動かなくなっても良いといったんだよ。
なぜなら、古いエンジンも両方載せればいいから。
この場合、新しいエンジンは、古い規格をサポートしているとお前は言うのか？
新しいエンジンは新しい規格のみを採用している。
そうであっても互換性を保つ方法はあるということを俺は示しただけ。
古いエンジンを載せる以外にも手はあるぞ。
自分で考えてみな。
>>658 失礼だけど、言ってることがズレてるよ
バージョンを分けるためには新しい方にフラグを用意しないといけない
つまりそれは新しい規格の方で後方互換性を守るために仕様に組み込むことになるんだよ
こちらの言いたいこと分かった？
>>659 必要ない。実行エンジンを切り替える
ブートストラップを用意すればいいだけ。
はい論破w
>>633 一応、Pythonを擁護しておくと、(Rubyとは比較にならないほど)ユーザ数が多いから、
互換性を維持する作業は(Rubyとは比較にならないほど)簡単ではなかった、のだと思う
結局、
>>634 の言う「将来見据えた言語設計」が大切、ってことだね
ただ、残念なのは、
>>651 のいう「(予測が)外れた時に諦める」という
「最悪のやり方」を選択してしまった事
なんとかならなかったものなのかなぁ......
忘れてる人もいるかもしれないけど、
>>660 あー、なるほどね
つまりWebサイトの閲覧者は、どうもJSが動かないなと感じたら
ブラウザのメニューからES5互換表示を選択すればいい訳だ
それは確かに正しい、こちらが間違っていた
大変申し訳ない
> ブラウザのメニューからES5互換表示を選択すればいい訳だ
新しいエンジンで実行したいのなら
>>662 じゃあそれが書いてなかったらJS何で動かせばいいのよ？？
JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの？？
そういうので問題起きてるんと違うん？？
それは解決方法でもなんでもなくて、むしろ問題だと思うよ。
外部ファイル前提だが、拡張子を変えるというても思いついた。
こういう無茶苦茶な理屈並べるのってネタなのかマジなのかわからんから怖い
>>666 > じゃあそれが書いてなかったらJS何で動かせばいいのよ？？
互換性を保つためと考えれば、
古い実行エンジンに決まってるじゃないかｗ
> JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの？？
開発者（scriptタグを書く人）・・・当然閲覧者ではないは
それぐらい把握できるだろ。
こいつみてると、互換性を保つ方法を考えるのにも
ある程度の技術力がいるんだなぁって思うわｗ
> こいつみてると、互換性を保つ方法を考えるのにも
>>662 ,663,665,667,670
こんなことでいいのなら、今までJSが必死に互換性を守ってきた努力は無駄だったな。
それだけじゃなく他言語でも心配するのが馬鹿らしくなる。
つまりこういうこと？
>>672 互換性を保つのは、新しいエンジンを作らないための努力ではなくて、
古いコードをそのまま使えるためにすることだよ。
おバカさんｗ
675 ：
デフォルトの名無しさん ：2013/09/16(月) 00:49:36.73
JSのバージョン指定はFirefoxでも廃止されたばかりなのになんと時代錯誤な。
>>674 急にどうした！？
なにか俺に見えないものが見えてるのだろうか。
>>675 もしそれが必要になる事があれば復活するでしょ。
互換性を保つのは困難ではあるが
できないことではない。
>>676 お前こそどうしたんだ？って
みんな思ってると思うが・・・。
そもそもJavaScriptにバージョンってあったっけ？
ECMAScriptの4とか5とか6というのが
狂人にはもう触るな…
そう。巨人には手を出しても負けるだけｗ
後方互換性があるからちょっとずつ仕様追加してLiving Standardでいられるのよね。
巨人様、どうかお鎮まり下さい。
人の言葉がなかなか通じぬと思っておったら、やはり奇行種であったか……っ
後方互換性があるからというよりも
何を誰に言っているのかわからん
>>687 まあ、誰にいってるかを書けば、
誰に対しての負け犬の遠吠えか
わかっちゃうから言わないんだろ
ここでJSのセミコロンは維持すべきかどうか聞いてみる
Rubyでもセミコロンの有り無しで
自分はnpmスタイルに感銘を受けて付けない派やってる。
「式だけ」の文の前の文の終わりに注意すればOK
別のエンジン乗せるだけなら、JavaScriptではなくVBScriptでもいいじゃないか。
>>694 そのとおりだと思うが
そもそも別のエンジンのせる理由がない。
互換性も別のエンジンを載せるまでもなく対応出来てるから。
JSくらいシンプルで10年も大勢の人に使われた上で
JSで無かったほうが良かったとされる物第一位はwith文だろうな。
つーか、JSの仕様の話はそろそろ他でやってくれないか？
JSでしか書けないコード出してどや顔してくれてる方がよほどためになる
俺達には簡単なルールがあるじゃないか
ケチを付けるだけのレスほど無用なものはなかろうよ。
>>698 withは旧VBのwithが優れていた。
JavaScriptのwithは
with(obj) {
a = 1;
b = 2;
}
だけどVBのwithは
With obj
.a = 1
b = 2
End Witi
なのだ。ピリオド一つあるかないかの違いだが、
どこを参照しているかが明確にわかる。
おまえら、Rubyの仕様策定手順だのendがどうだの
Rubyの歴史を理解するいい機会じゃん
やりたいなら勝手にやればいいじゃん？
709 ：
デフォルトの名無しさん ：2013/09/16(月) 04:19:02.24
ノータリンには
>>704 ,706がRubyの話しようって書いてあるように見えるのかな。
じゃあお前は、言語に関係する話を
711 ：
デフォルトの名無しさん ：2013/09/16(月) 04:48:50.58
よく考えてみると動的言語でこれだけ
JavaScript古いものごっそり削ればいいのにな
>>713 実装は寄ってたかってものすごく改善されている
これは競争のメリット
逆に仕様は寄ってたかって議論してるおかげで遅々として進まない
これは競争のデメリット
HTTP廃止して一回Webリセットすればいいお
718 ：
デフォルトの名無しさん ：2013/09/16(月) 09:15:54.02
719 ：
デフォルトの名無しさん ：2013/09/16(月) 09:16:52.19
>716
オススメのDBの管理方法教えてください
JSは既に他言語にある仕様を二周遅れくらいで
723 ：
デフォルトの名無しさん ：2013/09/16(月) 10:49:15.88
>>724 こういうのを掲示板に貼るキチガイって何がしたいの？
726 ：
デフォルトの名無しさん ：2013/09/16(月) 11:42:48.65
音でないだけマシかもな
>>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]) )
他言語は出てこないし、Python最強と言うことでおｋ？
OK
たしかに意外な組み合わせが最初に来るな
じゃ、Ruby最強ということで
>>729 うん、Pythonが最強だよ、よかったねw
>>712 Squeak Smalltalk
| bag |
bag := Bag new.
'○○○△△×' asDigitsToPower: 2 do: [:pair | bag add: pair copy sort].
^bag sortedCounts
=> {12->{$△ . $○} . 9->{$○ . $○} . 6->{$× . $○} . 4->{$× . $△} . 4->{$△ . $△} . 1->#($× $×)}
>>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}}
（´･∀･`）ﾍｰ
これcalleeみたいに最初から知ってて出題してただろ。
>>729 うん。Python最強。
ライブラリ２つ使ってなおこの冗長な記述には勝てる気がしない。ｗ
>>736 ということはJSはもっと短く書けるのか？！ wktk
今知恵を絞ってるがJSで短く書くのは無理
意外といいお題だったな
短けりゃ良いってもんじゃない。
じゃ、長くなってもいいからJSでよろ
お題
>>712 について、ここまでの結果をまとめてみよう
Python：5ステップ --
>>727 の4行に import collections, itertools を追加
Ruby：3ステップ --
>>732 Smalltalk：4ステップ --
>>734 Mathematica：たくさん --
>>735 >>729 残念ながら、どうやらRuby最強が結論だったね
>>742 >>737 が言うように、簡潔さでもRuby最強だね
>>732 ちょっと縮めてみた。
これで字数的にもSqueak並になったろう
h = Hash.new(0)
"○○○△△×"chars.repeated_permutation(2){ |xs| h[xs.sort]+=1 }
p h.sort_by{ |x| -x[1] }
>>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]]
お、案外みじかい
すくなくともPythonには勝ってるよ。すごいよ。
あー、でも結果まちがってる…… 残念ッ！
副作用使うなよ格好悪い
>>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)だけど、古いのかな？
うっかりしてた
>>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]]
ここでHaskell登場か？
Smalltalkが地味にすごいな
メソッドコールの数でステップ数だしたら
奇をてらってみた
GJ!
>>751 じゃぁこれで
a = "○○○△△×".chars.repeated_permutation(2).map(&:sort)
p a.uniq.map { |x| [a.count(x), x] }.sort.reverse
コレクション禁止縛りっすか
副作用なし
副作用なし(C#)
あのう、Python君が
>>727 を最後に息をしていないみたいですけど、まだ生きてますか？
PHPでPythonに勝ってみて
Python(副作用なし)まだ?
PHPerこのスレに居るの？
>>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]]
>>766 つまり、PythonのライバルはPHPである... というわけですね
haskell数え上げ弱すぎワロタ
from itertools import product, groupby
短いコードより早いコードで頼む
まあ、そりゃPythonでも書けますわな。
RubyやC#の副作用なしverはまあ普通に読めないこともないが
>>772 はさすがに汚すぎるだろw
書いてる人は良いんだけど、他の人は読めない。
一行で書くことに
>>772 カッコだらけのコードにワロタ
オフサイドルール？可読性？保守性？www
メソッドチェーン指向
わかりやすいコードは短いコードである ×
>>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>
いうまでもなく、メソッドチェーンやLINQは一行にまとめて書く必要はないよ
>>780 わかりやすいコードは短いコードである ×
わかりやいコードは行数が少ないコードである ×
わかりやいコードはカッコが多いコードである ○
こうですか？よくわかりません
誰かHaskellで書いてみてくれ
Haskellまだー？
>>782 Pythonは、LISPの方向に突き進んでいます....
>>782 >ネストした関数コールよりは見やすいと思う
>lambdaを導入したJavaやC++のコレクション操作もこういう方向に進んでるのでは
Pyhtonだけ時代に取り残されつつあると感じるのは、気のせい？
Pythonは外部イテレータやyieldをいち早く導入したのに活かせてないんだよなあ
で、そのコード関数にして10000回実行して1秒以内に済むの？
ナンセンスでしょ
C#はそもそもスクリプト言語じゃないじゃん。
処理系次第だという極端な例を挙げただけだよ
流石にC系と比べろという人はいないと思うよ
処理系がクソなら
組合せならば、リスト内包表記のあるPythonに有利なお題かと思っていたが、
今日中に終わらない処理系とか流石に無いよなｗ？
>>787 これで、Rubyの do ... end や JavaScript の { ... } を笑えなくなったね
Pythonオフサイドルール信仰崩壊の瞬間だw
>>788 いや、また後方互換性を無視した Python 4 が、すべての問題を解決してくれるはずだぞ
Haskellってこんなんだっけ？って思った。
Pythonでもメソッドチェーンで書けないのかな？
構文上可能だけどビルトインのクラスの書き換えが簡単にはできないからRubyのようにはいかない
foreach ($ary=array("○", "○", "○", "△", "△", "?") as $val1)
  foreach ($ary as $val2)
    $a[$x=$val1>$val2?$val1.$val2:$val2.$val1] = isset($a[$x]) ? ++$a[$x] : 1;
arsort($a);
print_r($a);
http://ideone.com/htCIiy >>803 いや、今回のお題ではメソッドをユーザ定義していない、つまり
Rubyでは組込み(ビルトイン)メソッドだけを、Pythonでは添付ライブラリ関数だけを
使って書いているんだから、書き換えうんぬんは違うんじゃねえの？
強引だが早そうなPHP
優勝
PHP自体が遅いから速度には期待できないが……
$dice=["○", "○", "○", "△", "△", "×"];
import collections, itertools
こういうコード晒し大会って一行になんでも詰めて書く奴がいるから萎える
とりあえず一万回回した時のタイムを測ってみてはどうか
>>810 この流れでそんなコードを晒した勇気は認めてあげる
Time厨うぜー
importしてる時点で大反則だよ
Ruby厨息してない
import はいいだろ
確かに外部ライブラリ使うのと変わらんな。
外部ライブラリ使うのはいいよ
僕は○○の開発者だけどこのスレをたまたま見ました
じゃあimport原則禁止でお願いします
公式モジュールならいいだろ・・・
外部じゃないよ
>>826 じゃ、Javaみたくimportなしでも完全名を書けばおｋなんだ？
Rubyだれかideoneでベンチ書いてくれ
便利モジュール読み込んでいいのならライブラリ勝負と変わらんだろ……
namespace観念のないRuby厨
便利モジュールを読み込むの禁止
このままだと速度もソースもphpの圧勝になるぞ
完全にフェアな条件なんてそもそもないんだからさ。
違うネームスペースを参照するのにimportがいる言語はpythonだけじゃないぞ
リストもハッシュもソートも禁止だな
標準ライブラリ否定ｗ
また短いコードが出て来てから騒ぎ出す辺りが
このスレのPythonerが自力では何も出来ないレベルの低い奴っていうのが良くわかった
不利になるとなんでも縛ろうとするのが洗脳されたRuby厨の末路
import無しでいいコードを書いてみればいいじゃない
自分の言語の都合にだけハマってたら、
Ruby5倍ぐらい遅いんだが、何かオプション付けないとダメか？
ウンコなコードで勝ち誇ってたら
むしろSmalltalkのBag相当を標準で持ってるのが
※但しインポートしないと使えない※
Pythonは素では何も出来ない言語なんだってのがよく分かったｗ
>>846 Pythonは悪くないだろ
書いてる奴がド底辺なだけだ
何でもデフォルトの名前空間に突っ込んでるゴミ言語が最強
グローバルに備わってないような機能をインポートしてさも平然と使っていいのなら
よくわからんがBugくらいどの言語でもすぐ実装できるんじゃ？
他の言語、遅くて3秒とかなのに、Rubyだけ17秒かかるんだけどなんで？
>>758 を１００００回実行したら３秒くらいかかる。
PentiumDだから今のCPUなら１秒切るくらいかな？
>>848 BagなんかANSI（あれもないこれもないってSmalltalkerには不評）にも入っているし
最小限の部類なんだが…
コレクションやイテレート処理くらいデフォルトで使えないと文句言われてもしかたないね
また関数型の話するの？
; Common Lisp
Perlさん息してない
>>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
>>860 処理内容の違いも分からずコード比較してどや顔の愉快なRuby厨。
とりあえずBag（MultiSet、Counter）を勉強して来い。話はそれからだ。
>>860 Lisp 2.07
JS 2.62
Python 2.67
Ruby 22.78
これははっきりしちゃったね
Rubyはモダンスクリプト言語のなんと10倍も低速
使いものにならないレベル
>>860 簡潔さの証である、メソッド・関数 のコール数では圧倒的にPythonの勝利
Ruby厨て行数と文字数でしか勝てないから、これが対等に見えるのか
V8はえー
pythonも
>>812 が v2.7とv3.3で5倍違う。
環境で変わりすぎて話にならないな。
# perl
うーん、、、
速度の話は確かに環境が違うからあんまあてにならない
流石perlはどこか違うな
10倍も差がでてて環境による発言は見苦しいな
Rubyも1.8と2.0じゃ速度差は3～4倍は違うんじゃね？
単純演算が遅いのはあまり言い訳できないと思う。
10,000回
Ruby(
>>760 )： 3.62sec (v2.0.0)
Python(
>>812 )： 2.41sec (v3.3.2)
現状それだけ差があるのなら
Ruby1.8.7をベンチマークに使うのは流石に可哀想だろ
1.8.7ならダメってどういうこと？
>>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を使ってるからねぇ…
>>878 Ruby 1.9以降でコアがAST逐次解釈からバイトコード方式に変更されたので
rubyはフィボナッチベンチが速くなるように頑張って最適化してるよ
そんなん他の言語は１０年以上前からやってきたことだけど
ジワジワすぎて
>>883 の地域別がおもしろい
Ruby島根が1位ｗｗｗさすがお膝元だな
そして茨城県民はPython Ruby Perlあたりが好きらしい
そして沖縄県民はプログラムに興味があるようだ
>>861 のフィボナッチ、
Common Lispは型指定も最適化の宣言もコンパイルもされてない。
>>878 >1.8.7ならダメってどういうこと？
1.8.7は公式に終了(リタイヤ)したバージョンだよ (
>>607 を参照)
公式終了版でもダメではないというのなら、
Ruby 1.8.7 と Python 1.0 とで速度を比較しようぜw
>>897 Ruby2.0入れて試してみたけど
期待したほど早くなかった
27秒 Ruby2.0
1.5秒 Node.js
それを言うならPython2.5じゃないの
>>862 >とりあえずBag（MultiSet、Counter）を勉強して来い。話はそれからだ。
Bag: 要素間で順序性が無いが重複は許す集合、多重集合(multiset)とも言う
SmalltalkであればクラスBagで実装されている
PythonのSetは「要素間で順序性が無く重複も許さない」から集合だけど、
タプルは可変(mutable)なシーケンスであって、順序性があるから集合ではないね
つまり、Pythonに(Smalltalkと同様な)Bagは存在しないし、PythonのタプルはBagではない
さらにCounterは単にシーケンスを計測するためのクラスであって、Bag固有の概念ではない
結論としては、
>>812 はBagの特性を活かしたアルゴリズムで書かれているわけではないわけだが、
何を言いたかったの？
今でもRuby1.8使ってるところ多いよな
それ間違いだね
「他の言語の～のようなもの」っていう決まり文句が出てきたら
Rubyほどの完成された言語に
なんかコレクション系の１つや２つくらいないの？
重複を許す集合だから、集合の要素と、要素が重複した回数のペアを持ってるんでしょ > Counter
>>899 まあSetだってずいぶん後だったしな。
Matzのコレクションの知識なんかそんな程度。
大クラス主義とかいうとそれらしく聞こえるけど、ぶっちゃけ
集合って概念において、順序を持ってちゃいけないなんて別にないよ。
ん？
SetやMapが入れた順番でイテレートされない言語ってあるの？
Setは集合、順序も重複もない
順序があるかは仕様次第でしょ。
なのでSetは基本的に順序性を保証しない
>>903 優先度はかなり低いからね
言語の目的からして
Setは基本的に順序を保証するものでしょ
>>911 Setは基本的に順序の保証も重複もない
順序を保証していたり、重複を許す場合はかなり特殊
順序が保証されなかったら例えば
>>914 なるかも知れないではなく、なっても良い場合にしか使ってはいけない
順序性を当てにする時点で使い方を勘違いしている
配列からSetを作ってそれを配列内包で配列に戻せないのは残念だな。
むしろSetに2つ値をいれて2つイテレートされる環境の方を知りたい
Bagってlock-freeにできるから並列処理には役立つけど
>>916 それは順序が保証されないSetは表現力が低いってことだよ
前スレで合ったけど順番が保証されてた方が
>>920 代わりに要素検索のスピードをあげる、などの実装的メリットがあるんだよ
>>920 違う
それはOrderedSetであってSetではない
Setを順序が保証されるものとして使ってはいけない
イテレートしにくいのならHashとあまり変わらん気がする
Setを順序が保証されるものとして使ってはいけないが
＞OrderedSetであってSetではない
>>924 イテレートはふつうにできるよ。
順不同なだけ。
>>927 RubyはSetとSortedSetの両方があるな
PythonはSetだけかな
Setの条件を満たしていれば、
>>928 Setの基本は数学の概念であって言語の固有名ではない
だからメジャーな言語は順序性を保証していない
>>922 ,930
そんなこと百も承知で話してるんだけど……
元は数学の概念とか言い出したらラムダ式とかモナドとかどうなるねん
>>929 屁理屈ではないよ
本当にそういう概念なだけ
>>934 いや、たぶん承知はできてないと思う。
"I", "am", "Tom" と "am", "I", "Tom" を区別しないのがSetだ。
今こんな感じ
>>937 あなたの知ってるSetはそれしか無いのね
よく分かりました
>>935 完璧に実装するべきとは言っていない
プログラミングにおけるSetの概念は、数学の性質を模倣したものだから
Setという名前のものは、基本的に順序性は期待してはいけない
明確に順序集合であるものや、配列を使うべき
>>936 強いていうならSetは順序を保証しないのに
Orderedって接頭辞がつくのは矛盾語法じゃないのかって
いうのはああるかも。^^;
立場の違う者同士が会話し合うのって難しい!!
Pythonのimportって、Rubyのrequireとは割と別物なんだよな～
Setを持つ言語のほとんどは順序を保証してない
setって要は集合だよ。
Bagというと検索できないもんだろ?
皆一体何が話したいの？
>>948 検索はできるよ。indexOf みたいなことができないだけ。
ただのSetに順序があると思ってはいけないというだけで、
>>949 OrderedなSetはない
メジャーな言語ではSetは順序性、重複を保証しない集合型の固有名
>>950 Bagが検索できないといけないという決まりはない
だからこそlock-freeにできるんだよ
>>951 決まりはないが、RubyもPythonもC#もJavaもSetは順序を保証しない
Ruby、C#、JavaにはSortedSetが別に用意されている
順序を保証しないと
groovyのsetって、どうだっけ？
JavaScriptのSet
>>953 なんか、Bagはlock-freeにできなきゃだめって
決めつけてないか？ どこにそんなこと書いてあるの？
JavaScriptは「メジャーな言語」とやらには入らないとよ
しつこく拘ってすまない
>>951 の言うことが正しい
>>905 みたいな人がいたので、
Setは基本的に順序性を期待するべきでないと言った
bagが検索可能である必要はないが、並列処理のできないスクリプト言語におけるbagは
>>960 メジャーなが言語の例外
JSはobject型と同様のイテレーションを当てにしてる奴も多いしね
>>961 だからさぁ。
SetというのはSetオブジェクトのことで、そんなん言語によって違うでしょ。
食いつくとこおかしくない？
というか揉めるって分かっててやったんじゃないの？
>>962 いやいや、Bagの価値は、まさにこのサイコロの例のように
h[e]+=1イデオムを抽象化できる所にもあるだろう。^^;
Setは順番がないと言い切るからダメなんだよな。
>>962 最初にこれをBagと呼び始めたSmalltalk涙目ｗｗｗ
>>963 通常objectのforinは順序保証されない仕様のはず
>>965 どう見ても検索してるじゃんww
lock-freeの方のbagはイテレートとpopのみだよ
>>967 だから「順序は保証されない」でええやん
>>970 なんでlock-freeに固執するのかわからん
>>971 順序が保証されている
SortedSetというSetもある。
>>966 前スレで使ったけど配列のユニーク配列を取るのに
こうしたいから個人的には順番あって欲しい。
[ v for (v of new Set(arr)) ]
>>972 bagはlock-freeじゃないといけないと言ってるんじゃなくて、
lock-freeを必要としないならbagは検索できないと意味がないと言ってるんだけど
>>973 それはSortedSet型として扱うべきであって、
Setとして扱う時点で、順序を期待してはいけない
>>970 別にlock-freeのBagがあって、その目的のために
APIが制約を受けるのはかまないと思うけど、
そうじゃなきゃBagじゃないというもって行き方は
明らかに視野狭窄に陥っている。
>>923 ってあんたの方だろう？
>>975 それ、10年前くらい、それこそ互換性がまだまだだった時に横暴したけど
仕様外だから期待通りに動かない環境が出て
JSでランクAくらいにタブー視されてることになって久しいよ
だからそれとSetの話は関係ない
>>975 > 975 名前：デフォルトの名無しさん[sage] 投稿日：2013/09/16(月) 21:16:24.38
>
>>969 > 知ってるが、当てにしてるソースは多い
俺は知らない。
多いというのなら一つぐらいだしてくれ。
本当なら別プロジェクトで3つぐらいだしてほしいものだが。
>>976 で、indexOfの類はできないが検索（要素の存在確認）はできるといっている。
ちなみにsortedCountsはBagを返してるんじゃないぞ？
for-inだと順序以前にプロトタイプも遡るしめちゃくちゃだわ
>>981 まあまあ。
昔はそんな問題もあったってことで
>>980 どうしてなにを持ってそれがＦＡになるのかさっぱりわからん。
JavaScriptは１，２年で状況がガラッと変わるから
>>980 Bagの定義は「順序性が無いが重複は許す集合」だし
PyghonのCounterがそれにあたらないというのは
確かにそうなんだけど、
>>734 のSmalltalkのBagを使った例を
Bagを持たないRubyの
>>732 とかの例と見比べてみると
分かるように、Bagはただそこに要素を突っ込んでいくだけで
h[e]+=1 イデオム相当のことができるってところに意義があるんだよね。
だからPythonでBagをCounterと名付けたり、コレクションとしての
APIを大幅に制限したのは、ユースケースからはまっとう。
もっともBagには重複の多い集合を扱う際のメモリの節約や
高速化といったメリットや使いどころも皆無ではないから、
その切り口で別物という主張ならそれは間違っていないけど
今回の議論からははずれる。lock-freeもね。^^;
>>989 まともなJSerなら10年前から分かってただろ
第一次意識改革があったのは、Ajaxが注目を浴びてJSが見直され、
ライブラリもどんどん出て、JSの重要度が大きくなり、
JSLintとかコーディングスタイルが話されるようになり、
そしてChromeのV8はええってなった頃までの時期だな
まあ５年前くらいか
そしてES5が出来、HTML5が注目を浴びだして
ブラウザやデバイスシェアが大きく変わっている今も
テストやツール方面と、入門者に良いコーディングを覚えさせる方向なんかで
第二次意識改革が進んでる
>>988 >Bagはただそこに要素を突っ込んでいくだけで
>h[e]+=1 イデオム相当のことができるってところに意義があるんだよね。
よく分かった、ありがとう
数学的には、multisetは集合から自然数への写像として定義可能っていうか、典型的にはそう定義される。
数えるというより、lock-freeみたいな適当に放り込んで適当に取り出すだけのものを
結局、Smalltalkerは数学の素養も無いのに
>>994 BagとMultisetの違いも分からないお馬鹿さん？
Smalltalkerならぬ、
結局、
>>862 は数学の素養も無いのに
無知なままBagについて語ってたでFA?
Bagはただの多重集合じゃないんだよ、だからCounterとは違うって話だったら
こんなに話がこじれなかったよ。
Counterは多重集合じゃないって言うから（例
>>988 ）こじれたんだろうに。
ばかばっかだな
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。
