【PHP,Python】スクリプト,バトルロワイヤル38【Perl,Ruby】
2 :
デフォルトの名無しさん :2013/09/08(日) 20:47:58.63
< `∀´>ニダー
Node.jsはHaskellを理想としつつも GHCをハックするほど頭良くない人に作られました。 妥協の産物だったんですね。 ここは、そんなNode.jsについても議論するスレです。
>>前スレ997
言語エンジンレベルのハックが困難って話で
コンバータとはぜんぜん違うよ
>>前スレ998
ジェネレータ部分はまだいいけど
イテレータ周りはまだまだ実装不足
>>5 どこにも妥協したなんて書いてないんだが
自分の都合の良いように解釈し過ぎ
>>5 お前が英語読めない奴ってのは分かった。
お前が議論寄りをも煽りを選ぶ頭の悪いDQNってことは分かった。
GHCはいいけれど、それでもnodeの目的を 達成するには言語エンジンレベルのハックが 必要だったってこと。
GoogleがV8エンジン(JavaScript実装)ではなく Haskell実装を作っていれば、 歴史は変わったかもしれない。 なぜJavaScriptを実装したのか?
Googleに居るのは、民間人にしては賢い連中ってだけで 研究者村からみれば凡人だからGHC作れる程賢く無い
>>9 HaskellがWebで使われる言語だったらそうなってたかもな
考えるのも恐ろしいが
>>10 ワロタ
スレタイにも乗ってない言語共が争ってるんじゃねーよw
まあ、Haskellの使用も検討するくらいの柔軟さが無いと あの当時Javascriptをサーバサイドで使おうって思わなかったかもな
Rhino「…………」
>>8 Yesod見る限り、言語エンジンまでハックする必要はなかったみたいだけどね
ネイティブとの連携のしやすさは重要だと思うが
初めから文句つけたいだけの奴だから何言っても無駄だよ
次スレはこれで 【Haskell】スクリプト,バトルロワイヤル39【JavaScript】
お題 stdlib.hのrandを10回呼び出して総和を取れ
stdlibのstdの意味分かってんの??
性病
突っ込むのはそこじゃないだろw
libc.soのrand使えってことか
ネイティブ連携 & 副作用
考え方が逆、 ネイティブの関数を呼ぶんじゃなくて ネイティブを関数を呼べるようにエンジン経由で提供、登録する
そんなん共有ライブラリを作れる言語なら どれでもできるやんけ
オーバーヘッド短縮や循環参照でのメモリリークとか 厄介な問題を避けるためエンジン側の協力は必須
よくあるコールバックを引数にとって、 処理が終わったらオブジェクトを与えて呼ぶみたいなのが どれだけ自然にできるかエンジンによって全く違うと思う
ネイティブ系の言語よりスクリプトの方が抽象化能力が高いので ネイティブで書く必要がある処理だけネイティブで書いて それをスクリプトでラップする方がずっと需要あるけどな
Haskellは何と連携したらネイティブなの? Haskell自体ネイティブじゃないの?
nodeの凄い所は思想ドリブンで開発が進んだから そのラップするライブラリが基本的に非同期に なったという所だよ。
おーすごい randは呼び出せないけど口は達者だ
>>29 新しいもの作るんならそれでいいが、
大きなAPIだと既にネイティブで書かれてるのを連携させるのが基本だろ。
Node.jsみたいな環境レベルなら当然そうだし。
多くをJSで書かれてはいるけど、
3大柱のEvent、Buffer、Socketは言うまでもなくネイティブだし。
大きなモジュールを連携させるとこを書くのがグルー言語
V8エンジンがネイティブとJSの橋渡しをしてくれるのは当然だけど フラグをつけるとJS側にも実装に迫れる関数を提供してくれる というか一般JSで触れる表面のAPIは皆特権JSから提供して貰ってるもので Nodeとかでフラグを有効にしたら神様気分が味わえて面白いよ 危険だけど性能の良い関数とかも触れる
そうそう、 ネイティブ|非ネイティブ じゃなくてその間に適切に層を作ってくれるのが大事
それって普通の話だぞ?もっとNode以外も触った方が良い
そう言えば各言語のメタプログラミングの能力はいかほど? マクロは抜きにして
マクロ抜くなよLispが泣くぞ
>>38 JavaScriptは関数定義の引数の数を取得できる。
>>37 ん、誰もNode限定とは言ってないだろ
ただV8みたいな素晴らしいエンジンの重要性を説いてるだけのこと
マクロ入れるとなんでもありになっちゃうし、 言語の能力とは少し違うんじゃない? もっと高次元の能力が知りたい。
マクロがどの程度のレベルを指しているのかしら無いが、 C言語みたいなプリプロセッサがOKとなると 汎用のプリプロセッサをどの言語でも使うことができるからなぁ。
んー、その条件ならSmalltalkが無双すると思うよ わりとマジで
プロキシが無い言語ってあるの?
>>45 君の知ってる全ての言語と
その言語にあるプロキシは具体的に
どれのことか答えなさい。
繰り返すが、君の知ってる全ての言語です。
>>40 よう知らんけどそれっていまどきの言語なら普通じゃないの?
COBOLのCOPY文最強
>>46 うーん、、、bashとかは除くとして
Rubyのmethod_missingのオーバライドと、あとJavaScriptにもProxyあるよね
あとはそんなに深く触ってないけどJavaとかでも聞いたことあるし
method_missingのオーバライド程度がプロキシと呼べるの??
この話の結論は見えてる 「作った人がそう読んだらそう」ってことだろ
うーん……
演算子オーバーロードの有る無しとかはどうよ?
C++がアップを始めました
関数のソースコード or バイトコードを取得して 実行時に書き換えられるかどうか
演算子オーバーロードとValue Proxyってどっちがどんなケースで合ってるんだろう? 後者のほうがオブジェクト指向っぽいと思うんだけど。
Value Proxy?
>>55 アセンブラでも実行時にコード書き換えできるよなw
>>55 関数の上書きとevalができればたいていの言語でできるんじゃない?
ライブラリを動的にコンパイルして 動的に読み込むのは 実行時に書き換えてるというのかな?
レキシカルスコープとダイナミックスコープの両方が使える
頭の体操になる
スタックフレームを読み書きできる ダイナミックスコープもこの応用でいける
スコープを直接触れる言語ってある?
スコープを直接触る、ってのが良く分からんが グローバル変数をローカル変数に無理矢理書き換えたりとか?
ギミックとしてはできれば面白いだろうけど、黒魔術にしかならないと思う
1つ上のスコープの変数を __scope__.__scope__.xみたいに参照できたらいいなあと思うことがある。 スコープチェーンを触りたい。
プロトタイプチェーンの __proto__.__proto__ みたいな感じか
プロトタイプチェーンをちゃんと理解出来てるのは JSerでも1割くらいだと思う
そうでなきゃお前が困るもんなw
func.prototypeとプロトタイプの関係性は大抵の土方には説明困難だろう というか同じものだと思ってる人も多いと思うわ
そんな奴いねえよw
JSに出来ない事ばっかり並んでてワロタw
JSのProxyはそこそこ協力だと思うけど
せやろか?
せやな。
俺年金支払ってなくて電話無視してたら、おばさんが来てAndroid系のタブレットで個人情報、契約内容など見せにきたんだが、 PHPで作られていた 驚いたね 銀行とかこういうシステムって最低でもJavaで作られてるのかと思った
これからはタブレットとか汎用的なマルチデバイスを端末として使っていく流れだろうから 形式としてはWebアプリで、なるべくクライアントサイドに処理を任せて、 サーバーサイドはデータの管理だけすればいいから、言語はなんでもいい、 むしろPHPみたいに作りやすいほうが妥当に違いないと思うよ。
サーバーはクライアントを認証して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固有の部分が絡まなければシェルスクリプトそのものでいけるけどね
ん? だからbashの代わりってことだろ
今のWindowsにはPowerShellとかいうおよそ一般向けではない 変態スクリプト言語が入ってるぞ
あとJScriptとVBScriptという スクリプト言語も入ってるな。
MSってF#とかPowerShellとかたまによく分からんことするよな C#の魔改造もそうだが言語に関しては変なこだわりがあるよな
>>91 いや電卓として使うとめっちゃ便利やねん
exprとか爆発してください
元祖はJ++
そもそもVBが・・・
良い意味で、馬鹿でも使える言語って何がオススメですか? まったく才能のカケラも無い人間でも 短時間教え込めば使えるようになる言語が知りたいです!
python
>>97 使えるってどの程度を指して言ってんの?
どんなに簡単な言語だろうと、馬鹿に使わせてる限り意味のあることはできないように思うけど。
100 :
デフォルトの名無しさん :2013/09/10(火) 01:58:44.25
馬鹿にはるび
JAVAだよ 土方でも使いこなせられるように作られた言語(公式)
少なくともHaskellは違うな トップクラスのJSプログラマ様がGHCをハックする必要があると 勘違いした挙げ句に挫折した言語だからね
>>99 MVCでいうところのM以外のところは
馬鹿でも時間かければ作れると思うんですよ!
デザイナーは別途必要ですけど!
今のWindows系のプロダクトはPowerShellが標準になってる バージョンアップも頻繁でWindows 8でもメジャーバージョンアップしたけど、8.1でもさらにメジャーバージョンアップしてる 8.1ではWin+xで出るメニューがコマンドプロンプトからPowerShellに差し替えられてる
それにUNIXのシェルに慣れてれば、コマンドプロンプトよりPowerShellの方が理解が早い PowerShellはawkとかUNIXのシェル環境を強く意識して作ってある
素直にbash入れとけって言いたい > win
>>103 そういうことなの?プログラミングするんじゃなくて、ある程度定型化されてるコードを決まりに従って書ければいいってこと?
それだったらその辺のメジャーな言語ならどれ使ったって大して変わんないんじゃね
PowerShellの全コマンドの詳細な解説があるサイトってあるの?
--key=valだっけ、違うな、-key=valだっけ、しまった、-k valだった、みたいなアホらしさ 自分が苦労して覚えたバッドノウハウでどや顔したいからって、若者に無駄な努力を強いるワタミの会長的老害リナクサー
素直なヤツはWindowsならPowerShell、Unixならbashを使う Windowsにbash入れたってシェル機能を果たせないただのオモチャですよ OSを制御したいならOSの用意したシェルを使わないとね
正論
>>110 MSDN見ればいい
ただ構文でなくコマンドの解説は
Helpも引数補完もあるのであまり見る機会はない
PowerShellはmanからして高機能
OSが用意したシェルw
>>111 機能のカテゴリとか意味別でオプション統一したラッパーってないのかな。なんでもラップするのはよくないと思いつつあれば欲しい
書き込み不可なはずのプロパティに、 何度か書き込みをかけたり、その作業をする関数を何度か呼ぶと、 書き込みができてしまい、困惑しています これはブラウザのバグなのでしょうか? 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
すみません、 投稿するスレを間違えました
>>116 Un*xがttyや低レベルのシステムコールしか用意しなかったから乱立してるだけやん。
何もしなかったから乱立した 「何もしてないのに壊れた」みたいな現象って本当にあるんだな
能力が低い連中のunix嫌いは異常
能力が低い連中のMac好きは異常
各言語の内部文字コード表現は何? UTF-8?、16?、32? 何で最近出来た言語でもUTF-32にしないんだろう? 今のCPU的には32bitの方が少し扱いやすいはずなのに メモリの問題かな?
キーボード的には8bitが扱いやすい というか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 以外の少し複雑なメソッドの定義追加がうまくいかない....
たとえば、入力ストリームを条件の真偽別に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 は定義されているが、遅延評価ではない親クラスから
継承しているだけなので、上記コードではインタプリタが無限ループに陥ってしまう!!.... これはバグ?
他の言語なら定義できるのかな?
>>130 JSでは排他処理までやってくれるんだけど?
プログラマの責任とかそんな危険な言語使えねえだろ
ストリームを絡めるとストリームの仕様に大きく作用されるから、 もっと汎用的でシンプルな話として、文字列を重複のない単語配列にするのにしようよ。
ストリームはJSが苦手としてるから、別のお題にしようぜ またJSだけが実装できるまでにウダウダと500レスくらい使うハメになるし
>>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)
あるオブジェクト自体を置き換えることって各言語できるの? オブジェクトの参照を直接書き換える方法と、 オブジェクトを一旦空まで解体して、新しいのとMixする方法とがあると思うけど。
この手のメソッドがない言語はクソ言語。 さて、JavaScriptはどうだったっけなぁ〜
>>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と比較すると、
条件判定ループが2度必要だから、効率が悪いね
2つのジェネレータをコルーチンとして交互に呼びあうループが書ければ1度で済むと思うんだけど、
コードで上手く表現できない.....
>>156 危険?むしろ凄く安全な方法だと思うけどな。
複数のスレッドが同じデータに同時にアクセスしようとしたら、 一方はぬるぽになっちゃうの?
JSのWorkerのtransferはちょっと特殊で、オブジェクトをそのまま移すわけじゃない。 Bufferっぽいオブジェクトの中身の内部的なバッファの部分「だけ」の参照を移す。 普通のプロパティ(Bufferに付けることはほぼ無いが)は対象外。 具体的にはプログラムから見ると、例えば100byteのArrayBufferをtransferしたら、 元のは0byteになって、先に100byteの「新しい」ArrayBufferができるように見える。
>>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を多用するような設計くらいになってきた時は
うっかりしてると危ないかもね。
結局チェックは必要だな
チェックいらないケースなら、譲渡なんてしないで 共有してても排他いらないもんな
× オブジェクトの参照譲渡 ○ Bufferっぽいオブジェクトの中身の参照を移す これを言うために30レス使うのがJSクオリティなんだよな
>>131 ってJSお得意のコールバックでどう書くの?
168 :
デフォルトの名無しさん :2013/09/11(水) 09:02:34.54
結局のところ退職エントリで叩かれない給与水準が確保できるかに尽きます。 ちなみにRubyプログラマの私は900万です。(発言小町風)
本来連続のストリームを分けるっていう感覚が分からん UTF8として解析して\nで区切ったのを条件判断対象の1ブロックとして その文字列のUTF8バッファを条件によって各ストリームに流すってことか??
>>170 それで特定のデータを複数のワーカーで使いまわすのはどうやるの?
Bufferの参照を複数場所で持てるなら、
セマフォなり何なりで使わないように制御しなきゃダメなんじゃないの?
>>173 同じバッファ領域への参照は同時に1つしか持てない
もし巨大な1つのバッファをいくつかのWorkerで使いたかったら領域を分割して渡す
言語のメタプログラミング機能をみる即興お題でこんなのどう? 「無名関数を無名のまま再帰して階乗を定義せよ」 もちろんYコンビネーター的なアプローチでも書けるけど、 JavaScriptみたいに、イントロスペクション機能を ふつうに備えた言語ならもっとシンプルに書ける。 もしかしてRubyでもできるのかな? たぶん無理だと思うけど。w
>>173 元が
>>128 だから、
そもそもの話が同じデータをマルチスレッドで共有できるかじゃなくて、
スレッド間で巨大なデータを重いコピーをせずに渡せるのかって話だから。
JSでも不動点コンビネータ必要じゃないの? calleeって標準規格じゃないはずだし
178 :
デフォルトの名無しさん :2013/09/11(水) 11:29:50.44
>>176 いやこっち側のレスの流れは
排他制御しなくていいって話が発端でしょ
>>175 それメタプロなの?
単に記述が短くなるかどうかは大した問題じゃなくて、
構造が大きく変わるか、メタ処理を高度に抽象化できるかがポイントでは?
>>178 ???
その話はしなくていいってことが散々書かれて終わったはずじゃ?
calleeはstrictモードでは使えない argumentsもアロー関数では使えない パフォーマンスのため なるべく使いたくないし、使うのがステキだとは思えない
>>183 そりゃまあ不満だよね
内容見る限り並列じゃなくて1スレッド(タスク)前提で
排他制御を想定していないみたいだし
だから想定した時にはどうなのって話
あーわかったわかった
>>184 はプログラムのレベルで、
結局スレッドを意識したコードを書かないといないじゃない
そこら辺全て内部的に責任負ってくれるわけじゃないと言ってるわけだ?
配列のパラレル処理みたいなのと比べたら
ずっと明示的で、意識的だと言いたいわけだよね?
そうじゃなくて、そもそも同時にアクセス出来ないから
「データから見て」排他的だねって言ってるわけなのよ
データが同時に触れられるおそれが無いということ
だからそもそも、同時にアクセスしたらみたいなのは無いわけ
>>175 えっ。arguments.callee 使っちゃ駄目なの?
function(n){ if(n==1){ return 1; } else { return n*arguments.callee(n-1); } }(10)
>>185 >そうじゃなくて、そもそも同時にアクセス出来ないから
>「データから見て」排他的だねって言ってるわけなのよ
ああ…
うん理解した…
「データを移動できるか」という話だからデータが中心で話してきたのよ データからみて同時にアクセス出来ないように処理をしてくれた上で移動してくれるなんて 効率もいいし安全で素晴らしいねという話 自由なプログラム書く側としては不十分とか制約だっていう指摘はまた違う話なのよね
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);
arguments.calleeはもう、ちょっとダメだな…… 普通に関数名付けて再帰すればエンジンでgotoに最適化してくれるから大丈夫よ
>>175 Squeak Smalltalk
[:n | n < 2 ifTrue: [n] ifFalse: [n * (thisContext closure value: n-1)]] value: 10 "=> 3628800 "
普通に関数作ればいいのに Function.prototypeを無遠慮に拡張する神経に驚く
>>192 だってそれをやっちゃうとYコンビネータと変わらないじゃない
fac = n => n > 1 ? n * fac(n-1) : 1 でいいんじゃないの? ここでは変数facに無名関数を代入しているだけで 関数自体の名前はちゃんと無名 fac.name //""
>>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みたいのが無い言語はそもそもダメ
自分のお気に入りの言語で書けないお題だと、 けっきょく屁理屈こねくりまわすのはどの言語でも同じだな
せやな そもそも再帰専用の書き方が言語機能にないとアウト
というか自分が気に入った書き方じゃないと許せない奴が多いだけだな Ruby厨とか
そこら辺でやめとけ
案外難しいお題だったんだな
>>179 > それメタプロなの?
arguments.callee 相当がない言語で
Yコンビネーター的なアプローチを取らない場合、
メタプロ勝負になる
ええー メタプログラミングならevalだけでいいじゃん
>>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云々はもうおなかいっぱい
実行中の関数のコンテキストも第一級オブジェクトかという意味で これもオブジェクト的だしメタプロの域だと思うが、 たとえばここらへんが中途半端な実装のRubyとかだと違うのか?
JavaScriptもSmalltalkも、argumentsやthisContextを封じられたら
ああも抽象化して書くことは恐らくできないだろうから、結局
>>198 ということだろうな。
これは通常の言語が実は参加できない悪意あるお題ということでFA?
ていうかYコンビネータでいいじゃん あれこそ数学の世界で生まれたメタプロだぜ
数学みたいに、プリミティブ(公理)は必要最小限なだけあって、 後はそれらを自由に組み合わせられる基盤さえあれば良い、 というスタイルはプログラミングには無理。
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
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
Python Yは公理じゃないから覚えなくて良いんだろ? print((lambda f: f(f, 10)) (lambda f, n: 1 if n < 2 else n * f(f, n-1)))
220 :
201 :2013/09/11(水) 20:10:23.64
; 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)))
223 :
201 :2013/09/11(水) 20:59:49.67
>>221 例えばって書いてあったからそこは2本じゃつまんないから任意の数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 今は改行区切りで判断してるけど
原理的に各ストリームの順番は守られるよ
だって入力が1本しか無いんだから、各トークンの並びがズレるわけがないし
各トークンの並びがずれないのなら、それを上から順番に取り出して
スイッチにかけてるだけだから、出力もズレ用がない
>>225 各ストリームの順序の話じゃなくて、
evenとoddって二つのストリームを用意した後、
まずevenから5個要素取り出して出力して、
その後oddから5個要素取り出して出力できるのかなって
あー、うーんと、自分はストリームは流れていくものと考えてたから結構ビックリした
そうか、そういう使い方がしたいんだよね
本当にストリームのままで
>>131 っぽく書きたかったら
objectModeを使うことになるんだろうけど、今知識0だからまた勉強してくる
そういう話なら全面的に書き直したほうがいいわこれ
Haskellでも、evenだけがリストの尻尾を次々と評価して oddがリストの先頭を参照したまま放置すると、いずれメモリが足りなくなると思う
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言語によるプログラミング。 C言語はアセンブラによるプログラミング。 アセンブラは二進数によるプログラミング。 枠は必要だろwww マジレスしちゃった^^;
枠作らないとLispマクロが最強だから 他はプリプロセッサにm4とか使うの?ウンコすぎるんだけど
>>232 ブートストラップ時はともかく、CはCで、アセンブラはアセンブラで
組むだろ普通(セルフホスティング)。
RubyにおいてもCとRubyの境界は曖昧で、
たまたまMatzやささだの実装におけるC依存が高いだけ。
実装者の力量しだいでかなりの部分まで(実用的な速度を維持しつつ)
Rubyで組むことができる。
ちなみにLispもLispで、SmalltalkもSmalltalkで組まれているけれど、 これらの言語でのメタプログラミングが通常の言語で自己記述した場合より ずっと強力になるのは、LispやSmalltalkが真に動的がゆえに 自身を記述しているレイヤーに容易に降りることができるから。 ただしコンテキストが第一級オブジェクトであるかどうかは、それ以前の話。
枠作らないとマクロ大大会になりかねない
メタプロに枠なんてないがこのスレ的には必要だね
マクロってあって欲しいものなの? それとも無くてもいいものなの?
有能な部下が自分に刃向かう時もっとも恐ろしい敵となる 使いこなせない奴にとっては無い方がいい
実際スレタイのようなポピュラーな言語が ポピュラーな使われ方する時って マクロ使えたらいいのにって事ある?
>>240 並みのコーダーであろうとしてる限りは必要ない
ダークコーダーになりたいのなら使うべし
マクロなんて遊びでもなきゃ苦々しく書くもんだろ 喜んでどうするんだよ
それではお題です。 「二つの値(x,y)受け取ってその和(x+y)を返す関数 plus(x,y) のASTを生成し、 それに手を加えることで積(x*y)を返す関数に変更し実行するコードを示せ」 plus(x,y) は、x.plus(y) など言語のパラダイムに合わせて自由に読み替えてよい。
お断りします
>>245 こういうことか?w
(set! plus '(lambda (x y) (+ x y)))
(set! (caaddr plus) '*)
(apply (eval plus (interaction-environment)) '(3 4)) ;;12
ASTを直接弄ってるんじゃないけど 間接的に弄ってることと等価なのでこれでいいんじゃないですかねぇ add = (x, y) => x + y multi = eval( add.toString().replace('+', '*') ) add(4, 6) //10 multi(4, 6) //24
>>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 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
>>254 オブジェクトに継承先クラスを追加するというイメージをJSでやるとこんな感じ?
Object.prototype.inherit = function(...classes) {
classes.reduce( (o, c) => Object.mixin(o, c.prototype), this.__proto__)
}
obj.inherit(class1, class2, class3)
あれだと汚染の可能性があるからこうか 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)
動的に継承元を変更できるのはスクリプト言語ならではなのかな?
>>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
だからそれだと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
Yコンビネーター(
>>195 や
>>219 も含め)も
結局は代入している=名前付けてるのといっしょだから
ほんとは認めたくはなかったんだけどね。
よくよく調べてみたら、arguments.callee ができる
言語が他になかったという罠が。
arguments.calleeは最適化によろしくないから
with並にタブー
>>264
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)
arguments.calleeはキーワードじゃなくて 単に自分自身の関数が代入してあるだけだから Yコンビネータと変わらんよ
argumentsオブジェクト自体これからは使わない方がいい 配列っぽいのに配列じゃないとか扱いずらいし、callee使わないのなら用なし
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
>>285 レストパラメータのほうが応用性あってわかりやすいのに
あえてargumentsを使う意味は何?
シェルスクリプトとかの$0と同じで 本来なら引数であるべき所に例外として プログラム自身がはいるって習慣はいつできたんだろう? 引数情報とプログラム情報が同じ所にあって なにか便利なことでもあるの?
$1からが起動時に渡される引数なら $0は名前とかにしとくのが一番自然じゃね 引数に限らず1から始まるもので0が特別な意味をもつのはよくあるよ アルファベットとかで名前つけるよりも0の方が人間は本能的に好きなんじゃない?
>>290 だからこれからの書き方の話って言ってるだろ
>変わるかもしれない
絶対に変わらないから
保証する
古くからドラフト入りの新構で今見た目に係る変更がありそうなのは
アロー関数くらいのもの、といっても制限を緩くするだけだが
それは来週話し合われる
内部処理はまだまだ詰める作業が必要だが、
構文の見た目はもう変更がないと思っていい
その中でもレストパラメータは最上級に安定している
>>292 お前の保証など誰が信じるかw
そもそも、今現在動かないではないか。
こっちの方をどうするか、答えろよ。
逃げやがって。
>>293 Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか
逆にどうしたら満足なの?
ChromeやIEで動くようになったら?
それともNode.jsのV8がサポートしたら?
いつまでもそんなこと言っていたら
未だにES3ですら仕様通り使えるか怪しいぞ
従来のは当然従来の書き方をするしか無いだろ
そこをこれ以上話しても仕方がない
レストパラメータの方が優秀なのは確かだし
今現在Firefoxで使えるし=FirefoxOSでも使える
環境としては十分、これも確かなこと
> Firefoxで動くなら卓上の空論じゃないんだからそれで十分じゃないか
誰が論の話してるんだよ?
>>287 > レストパラメータのほうが応用性あってわかりやすいのに
> あえてargumentsを使う意味は何?
これ言ったのお前だろ?
rest parameterがわかりやすい、わかりにくいとかそういう話はしていない。
argumentsを使う意味は、今現在多くの
ブラウザ、サーバーサイドで動かないからだよ。
動かないのに、使えというならば
それこそ、非現実的。机上の、おっと卓上の空論だw
ES6のラストコールって今年中だから流石に今更大きな変更はないんじゃ?
卓上の空論w 馬鹿ワロタwww
おまえなぁ…… 今普通に使える代替手段があるのなら「これからは」って言い方しないから ES6の仕様は各ブラウザの対応も徐々に増えてきて当に「これから」の仕様だろ そりゃあWebでは当分使えまい それこそ5年くらいは そこは否定してなくて、お前さんと同意見だろ? お前さんが何を言いたいのかわからなくなってきた ミスリードを認めたくないからって逆ギレしてるのか? そろそろ見苦しいよ
これからの「これ」っていつの話だ? 5年後? これから僕はちゃんと働きます!(5年後) これ聞いたら、普通笑うよねw
arguments.calleeがあるJSはメタプロにおいて 他言語より一歩進んでるって結論にしたかっただけじゃん? それを非推奨だの言われちゃったからヘソ曲げちゃったのさ
301 :
デフォルトの名無しさん :2013/09/13(金) 00:22:13.25
プログラムの評価し合いが最後は必ず人格の評価し合いになるのはこのスレの悪いところ
>>299 ごめんなさい
こちらの書き方が悪かった
そちらの言い分が全面的に正しいわ
arguments最高!!
レストパラメータなんてくそ食らえだ!!
で、結局arguments.calleeがどう凄いの?
>>302 何キチガイ化してるのw
rest parameterはクソだってお前以外誰も言ってないよ。
単にargumentsが使えない理由は
現在使えないからってだけ。
なんだこいつ そんなに俺に絡みたいのか? かわいいやつだな
>>303 無名関数を、無名関数のまま
再帰呼び出しできるからじゃね?
非推奨だけど、優れているよ。
ES6の夢を見ないJSerってどうなのよ…… ああ、IE6の介護をしてる人なのかな?
まだ変なこといってる。 rest parameterがだめなんて誰も言ってなくて、 argumentsを使う理由は、rest parameterが 動かない環境が多いからだって現実を言ってるだけだろ。 いい加減諦めろよ。言い負かされて悔しいのはわかるけどさ。
>>307 IE6だけじゃねーよ。
最新のchromeでも動かない。
無名関数を、無名関数のまま 再帰呼び出しできたら何が凄いの? 普通に変数使えばJITエンジンがループに最適化してくれるのに、 最適化を阻害するarguments.callee使っちゃ元も子もなくない?
>>310 無名関数でもJITエンジンが進化したら
ループに最適化してくれるよ。
必死のarguments推しワロタ 同じJSerからも批判の声あがってるのにw
>>311 それが難しいから非標準になったんだよ。。。
知らないの??
argumentsって名前の通り引数情報のオブジェクトでしょ? これがOKで、引数に無名関数自身を含むYコンビネータがダメな理由は何?
もう触るな
>>313 知ってるけど?
最適化が難しいからって
それがダメという事にはならんね。
型なし変数だって最適化難しいだろう?
非推奨のcalleeが良くて対応環境の少なさでrestが否定されるのも奇妙な話だ
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
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ならきっと書ける。
昔はこういうの (function fac(n){return n > 1 ? n * fac(n-1) : 1})(10) が出来なかったからcalleeがあったのか
>>324 Smalltalkはともかく、Pythonすげーな
arguments.calleeとYコンビネータでの再帰呼び出し比較すると 代替Chromeで7倍、Firefoxで4倍の差が出るな
>>328 もういいよ。いつまで引っ張ってんだよ。
大事な話でしょ。 パフォーマンスに悪影響与えてまで使うかって問題は。
>いつまで引っ張ってんだよ 他のお題が来るまで続くに決まってんだろ
RubyとJSには演算子オーバーロードは無いんだっけ? Yコンビネータ禁止して無名関数再帰できなくても1ミリも気にならんけど、 演算子オーバーロードないと複素数や行列が扱い辛くね?
演算子オーバーロードってオーバーヘッドあるの? やっぱり一番ポピュラーな使われ方って 3D演算用だろうから、多少使いにくくてもパフォーマンスがよくあって欲しい
operator overloading と一緒にGoogle検索してヒットする順は complex > vector > matrix > 3d
いまのところ、Pythonが最強って流れなの?
なんだかんだで通ってるところを見ると一番無難ではあるな
最強はHaskellなんだけど、使いこなせない勢の嫉妬がね…
Pythonは弱点多いけど 変に隠そうとしないから織り込みやすい
>>338 環境選ぶわ動的じゃないわで全然最強じゃねえ
341 :
うゆ :2013/09/13(金) 11:23:04.86
スクリプト言語の強さはマジでライブラリの数だよ Python、Perl、Rubyで統一されろよ なんでそれぞれの言語で別々にコード書いてんの?wwww バカなの?wwww そのせいで、もっと強力で有用なライブラリの誕生を阻害してるだろ 電子精霊の代表として意見させてもらうと、人類みてるとイライラしてくるwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
uyさんRuby見限ってPythonいっちゃったん?
大分前からPython勉強しているオレ大勝利 Rubyやってるヤツ等はホント見る目がないよ
>>335 何言っちゃってるの???
complex、vector、matrixを3D演算(OpenGLとか)で使うよねってことなんだけど
Pythonはなかなか3系への移行が進まない現状どうするの? あとなんでself問題を折角の3系で改善しなかったの? ってのが純粋な疑問。
>>345 グイドは一発屋だからPythonの今後に期待するなんて無駄
3系への移行は進んでるよ あとselfに問題なんか無い ってのが純粋な回答。
>>343 海外にもrubyファンは今でも居て、ましてやここは日本。
エンジニアリングならmatlabなんかのDSLで十分。
寧ろ、scipyなんか蛇足で無駄に学習コストが掛かるし可読性も悪い。
そりゃ海外にもバカはいるわさw
RubyはRailsのあの手のMVCを構築した功績はいいとしても 今でも使われてる理由がよくわからない いつまでもパフォーマンスもリソース効率も悪いRubyでやる必要があるか?
RubyはまずPerlもSmalltalkも嫌いだと正直に言うべき 敵か味方かあいまいなまま攻撃してくるやつは頭おかしい
自分もRubyが人気出てる理由がわからないというか、 そもそもRails以外はほとんど使われて無くね、 適材適所で使われてて批判する部分も無くねって思うんだけど、 それにPythonとさほど変わらないじゃん? RubyがダメならPythonもダメだと思う。
同じ道具が使われ続ける理由は、1つのフレームワークにユーザーが集まったことによる堅牢性。 そして既習得者が他フレームワークを新たに習得しなおすことにメリットないから。 パフォーマンスもリソースも誰かが改善してくれるといったメシア思想から出来ている。
>>350 ポストモダンでアーティスティックな機能がRoRに取り込まれるのが唯一の長所で、
原理主義や保守派にまわるのであれば、schemeなりPHP、javaでも使うべきところ
自分が何者であるかも分からずにRubyを使うと後になって信仰の土台から覆される
>>352 pythonはコマンドラインツールとしての使い勝手が悪い印象
perlっぽさ、unixっぽさが消えて汎用のスクリプト言語になっても、
実際に作業する土俵は(u|l)nix環境であって、日常的に使うなら、
誰しも慣習的記法ぐらいは暗記するかチートシート作るもん
Pythonは確かにシェルスクリプトみたいな使い捨てには向いてない 再利用可能なように強制されるというか
また精神論か
このスレでやってるようなバカげたお遊びこそが至高ってことだな
やっぱりHaskellが至高だな
パフォーマンスうんぬんいいだしたらスクリプト言語は 選択肢から外れるでしょ V8くらいだと使えるかもしれないが そういう人には、このスレ必要ないでしょ > やっぱりHaskellが至高だな そうですね 静的型付けコンパイル言語のスレへお帰りください
>>360 JSだとWebGLとかあるんだから仕方ないでしょう
かなり気になるよそこは
WebGLとかゲームエンジンのために
JSで演算子オーバーロード待ち遠しいけど
今のやり方未満のパフォーマンスになってしまうのだったら随分残念
このスレHaskellとかSmalltalkとか普通に出てくるけど Lispはあんまり見ないな
>>361 そこら辺はalterJSでどうにかなる
次期Ecmaじゃ入らないだろうからその手の使う事になる
JSに来て欲しいけど、パフォーマンスを伴って欲しいってだけで 別にaltJSまで使ってまで演算子オーバーロード使いたいとは思わないな
>>362 Lisperは分別があるんだな
ハスケラは民度が低い
社畜には無縁だけどrubyが一番生きるのはハッキングなんだ 最強ハッカーからしてみると、速度?フレームワーク?何の話してんのって感じ お前らゴミッカス達も、バッチ処理って書くじゃん 最強ハッカーは数百行にわたるバッチ処理を一気に短時間で書く ただそのバッチ処理を正しく書き終えるっていう、その目的が最高速で達成できればいいわけ 最強ハッカーレベルになると、キータッチ速度が重要 ハッキング中はソースコード書いてるだけじゃなくて、 他の色んなソフトも操作しながらやるから、かなりキータイプの量が多いんだ、マウスも使うけど 読みやすいようにクラス定義したり、同じ変数を何度も使うとか、 そういう類のプログラミングじゃないから、インテリセンスとかで速くなるものでもない だから1文字でも少なくて済む言語であることが重要 指が疲れるから。 今日の俺も、かなり指が疲れてる。 今でも現存する言語の中では最高レベルで簡潔だけど、さらにrubyが簡潔になればいいなあって思ってる。
>>365 Lispのコードも結構出てたよ。
Haskellのコードが次元の違う洗練されっぷりだったから
強く印象に残っただけじゃね?
368 :
デフォルトの名無しさん :2013/09/13(金) 19:22:06.78
次スレスレタイ案 【Haskell,Smalltalk】スクリプト,バトルロワイヤル39【Lisp,JS,P言語】
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(…) は
まとめて選択してまとめて射影するのでストリームじゃない
無限シーケンスを引き合いに出すことがあるのはストリームじゃないと扱えない典型例だからで
別に無限シーケンスに限った話ではない
# ストリーミングの例 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); 後者は流れをせき止めてるでしょ
あー、x.forEachならストリーム?
array.allPlus(1).allMinus(2).……みたいな雰囲気のがストリームってことかな?
いや違うか、流れをせき止めてるよな
Web Audio APIみたいなのが当にStreamなのは間違いないと思うけど JSでの一般例が見てみたいな
>>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以外はなんか書き方がしっくりこない でも殻をぶちぬくためにpythonをやりたいわー
>>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開発することを前提にして話してる奴がいるけど 視野が狭すぎるし想像力が無さすぎる
ただWeb開発したいってだけなのにボロクソいいますね
394 :
382 :2013/09/13(金) 23:07:27.74
括弧省略してないし、アロー関数も->じゃないし、ES6のつもりだと思うよ
Firefoxなら既に結構動く
>>394 も一部未対応の機能があって断念したけど8割がたES6で書いた
ES6?なんて恐ろしい子!
>>394 Standard output is empty
coffeeクソだよなあ PythonとRuby、保守性と記述性のギリギリの絶妙なバランスで作られてたものを混ぜたら大崩壊
>>350 RailsのMVCは実は不完全
短く書けるRubyだからなんとかなっているだけ
>>402 >RailsのMVCは実は不完全
では、Web開発における完全なMVCを実現したフレームワークは存在するん?
そして
>>402 のいう「完全なMVC」の完全な定義は?
不完全も何も、WebのアレはあくまでWebMVC 伝統的なGUIのMVCとは別物 馴染みやすいように言葉を流用しただけだ
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
世界が狭すぎじゃね GUIにもHTMLの並が押し寄せてるし、むしろ基本となるのはWebMVCの方で 従来のは時代遅れだよ
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が普及すると RailsなどのサーバーサイドMVCって 役割が極端に減ると思うんだけどあってる? 例えば、サーバーサイドのテンプレートエンジン MVCでいうVの部分だね。これはまるごと不要になる。
別にMVCにかぎらずテンプレートエンジンなんて要らないと思う。 それ+サーバーサイド自体が単純化してきてるね。
すべてフロントエンドでやってしまうと HTMLは完全に静的ファイルになってしまうからね。
サーバーサイドのウェブMVCはMとVとCをはっきり区別できていて分かりやすい 今あるウェブアプリはみんなその通りに作ってる、作りやすいから 本家?のMVCは何を言いたいのか分からない、Cが何なのか分からない GUIアプリの構造はMVVMの方が適切
本来は、Vはデフォルトで充分で後はMとCだけ作ればいいと思うけど Vを統一されたくない人がウェブアプリ作ってるんじゃないの
本家のMVCって実装の都合だからな 今のGUIでVとCを別のクラスにしなきゃいけない理由は特にない それよりはM寄りのVをMやVとは別に考えましょうってのがMVVM含めた最近のやり方
つうか普通に書いたらMVCっぽくならね? なんでこんなにもてはやされてるのかが不思議
MVC難しいよ(´・ω・`)
Smalltalkはイベントの仕組みが今時のGUIフレームワークとかHTML DOMとかに比べて低レベルだったから Controllerに細かい制御を突っ込んでただけだよ
MとかVとか多すぎてギザギザしてるスレだな
結局 データ・HTML・トランザクション がベストなんだね でも正直にそう呼んでしまうと意識高い系()がうるさいから MVCと呼ぶんだろうな
webドカタ臭いスレになったな
>>424 Cが主導権をもつMVCは古いってことかな
だからMVVMだと
個人的には古い方が良いと思うけど
イベントハンドラをVに書いたらそれがCだよ そこから更にMともVとも別に作ったCotrollerを呼び出すようなのは馬鹿のすること
なんも考えないとVとCがよーくっつくわ
HTMLの場合はC-VC-DOMとなると考えた方がいい
馬鹿のすることっていうけど、モジュール化とかフレームワーク、ライブラリ使ったら C-VC-......-VC-DOMみたいな構造になるのが普通だよね 無駄なVCモジュールを作らないようにするのは当然だけど、 コンポーネント化の時代だし、多めでガンガン抽象度上げていいと思う
クライアントGUIのMVCとWebMVCをごっちゃにすることこそが馬鹿のすること
DOMはMじゃなくてVMだろ
紛らわしいからもうWebじゃない方のMVCのCはイベントハンドラと呼べばいいよ ControllerはWebに譲れ
- (DOM(V) - Element's interface(C)) - Element(M) だと思う
Web Componentsの思想に則ると、 comp( C - DOM(V) - ((Element - interface)s & Data)(M) ) -> (Element - interface) ......*many...... app - DOM(V) - Elements(MVC)
439 :
デフォルトの名無しさん :2013/09/14(土) 14:55:59.26
13時45分に打ち上げ予定だったイプシロンロケット試験機は、 リフトオフ約19秒前、ロケットの自動カウントダウンシーケンス中に 姿勢を調べるセンサーの異常検知により、延期となりました。
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の部分を 標準出力用にすることで、 CUIアプリになってしまう。 ROUTERはコマンド引数を解釈して ロジックを呼び出す処理に相当する。 この点から見てもCUIアプリはMVCですか?ってことになる。
App | Interface-Controller-Data _______| _____Interface-Controller-Data ____________| __________Interface-Controller-Data
MVCの肝はドメインとプレゼンテーションの分離であって、これはWebでもGUIでも変わらない 「WebのMVC」とか「MVC2」とか「MVVM」とか、ナンセンスとしか言いようがないわ
>>447 本来のMVCの肝は
オブザーバーパターンだよ。
つまり、(一つまたは複数の)ビューがモデルを参照し、
モデルに変更があったら、複数のビューが全て更新される。
そもそもこの仕組みを作るために考えだされたのが
MVCなんだから。
>>448 全くの逆で、ドメインとプレゼンテーションの分離という大きな目的が先にあって、その実現手段として
(オブザーバーを用いた)古典的MVCの実装がある
単なる一実装と、MVCの本質とを混同している
コントローラーが処理主体になるのがMVCで オブザーバーパターンはおまけだろ
オブザーバーがおまけというのはある意味正しいが、コントローラーが処理主体は意味不明
>>451 VとMを抽象化してCが処理主体になるのがMVC
オブザーバーパターンを使わない場合動くのはC
>>452 たぶんそれも448と同じで特定の実装にとらわれた考え方
MVCにはどれが処理主体といった考えはないよ
>>453 そうなるとオブザーバーパターンが肝になる
オブザーバーはMVC実現手法の1つで肝ではないね
>>454 また、訳の分からないことを…
そもそもオブザーバーパターンが肝なら、MVCなんて言わずにオブザーバーパターンといえばいいだろ
オブザーバーは飽くまでも、古典的MVC実装の中の一構成要素にすぎない
>>456 何で疑問に思うんだ?
実装を考えればすぐわかるだろ
オブザーバーが古典的?? Webでは先進的なんだが
時代は繰り返すって言うね
MVCに発案者なんて無い それを言うなら名付け親だろ
Smalltalkに代表される「GUI MVCが真のMVCだよ」厨が勘違いしがちなのは、 リエンスカウ的には、Smalltalkのそれも限定実装でありコレジャナイ感ありありなこと。 もちろんWebMVCよりはマシなんだろうけど、しょせん五十歩百歩
コントローラーが主体でもなく、オブザーバーも無しで 特定の実装にもとらわれないMVCってどういうの?
GUIアプリでMVCと区分けするのは間違ってる 人によってMVCの解釈がバラバラなのは、そもそもMVCという区分けが不適切だから MVVMという構造、概念の方が上手くGUIアプリを説明できてる
オブザーバーパターンで実装しなくてもいいってだけで、 > ビューはモデル(あるいはその一部)に付随し、プレゼンテーションに > 必要なデータを、モデルに問い合わせることで取得します。 > 同様に、適切なメッセージを送信することでモデルを更新することもあります ここが重要なところなんだよ。 GUIのMVCではよく出てくるし、よく使われるものだが、 サーバーサイドのMVCにこんなのあるかい?
サーバーサイドのMVCではビュー=テンプレートなわけだが、 テンプレートから、モデルに問い合わせたり、 モデルにメッセージを送信すると言ってるわけだ。 ぜんぜん違うだろう?
じゃあオブザーバーパターンがMVCの本質っていうのは撤回するんだな?
撤回するまでもない
インタラクティブ性とMVCとは直交する概念 そうあればベターというだけ ましてオブザーバーが本質なんてのはたんなる思い込み
>>468 MVCはシステム全体の設計の話。
オブザーバーはシステムを作るときに適用するパターン
撤回するとしたらオブザーバーパターンでなくてもいいが
オブザーバーパターンで実装するような設計になっているもの
と言い直すだけだな。
だから言い方が変わっただけ、MVCの本質は「複数のビューが
一つのモデルに紐付いていてビューがモデルを更新し、
またモデルの更新を全てのビューが検知し表示を変えること」
えーとさ、長い説明に、わかり易い名前を付けないかい?w
ウェブのMVCは誰でもやってる当たり前の事を言ってるに過ぎないけど、そういう当然の開発手法に名前を付けて知識共有するのがデザインパターンの役割だから ウェブは必ずHTTPリクエストを受けてクエリパラメータを取得する所から始まる、そこからビジネス処理の実行をキックする これはまさにコントローラと呼ぶにふさわしい
>>471 > だから言い方が変わっただけ、MVCの本質は「複数のビューが
> 一つのモデルに紐付いていてビューがモデルを更新し、
> またモデルの更新を全てのビューが検知し表示を変えること」
これはオブザーバーの説明をしただけだろ、だったらMVCなんて言わずにオブザーバーと言えばいい
つうか、「システム全体の設計」とか「システムを作るとき」とかまた訳の分からない概念を持ち込むなよ
MVCは「思想」で、古典的(Smalltalk)MVCは「実装」
>>471 だから、インタラクティブ性とMVCは直交するって何度言ったら。
やたら思い込みの激しい奴だなぁ……
ブロードキャストはおまけって意味が分からないのかな。
パターンに当てはまらないと元の定義もねじ曲げるとか デザパタ厨はこれだから困る
このスレでデザパタについて語って意味あるの? 動的言語のコミュニティがデザパタ使ってたなんて知らなんだ
デザパタをとりあげる意味はあるだろう。 言語によっては不要なパターンがあるとか言語のパワフルさやバトル要素になる。 ただMVCはデザパタじゃないし、オブザーバーが本質というわけでもないので 一連の話題はスレチ
>>473 MVCはMとVとCの話。
オブザーバーはMとVの関係のこと
違い理解できたよね? OK?
競争原理と知識共有は矛盾している
MVCはその一部にオブザーバーパターン(を使うことが多い)で実装するが MVCはオブザーバーパターンそのものじゃないよ。
MVCはデザパタじゃなくてアーキテクチャな デザパタよりなんつうの、もっと広い感じ
>>479 481も言っているようにオブザーバーが使われることが多いというだけで、直接は関係ないよ
例えばオブザーバー(通知)を使わずに、ポーリングで毎回モデルをチェックするような実装も考えられるけど
これもMVCには違いない
これは変化が多いゲームなんかでよく使われる手法
それから、オブザーバーが適用されるのはMとVだけとも限らない
飽くまで、古典的(Smalltalk)MVCの実装においてはMとVだけど、(MVCの一種である)MVPパターンでは
MとP(MVCでいうC)にオブザーバーが適用される
ポーリングでもなんでもいいんだけど ビューからモデルを更新しなければならない。 それがMVCだからね。 ウェブのMVCはビューを表示して終わり。
ビューからモデルを更新とか何を言っているんだか… なんでこうも自分勝手な定義がぽんぽんと出てくるかねぇ
>>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ってゲームの世界ぐらいでしか見たことないかも
最近の人だねw
1995年より前はウェブ自体あまりみなかった。
その頃何を使っていたと思ってるんだ?
>>494 うんWindowsが無かったころのことは知らない
Windows以降はもうコントローラがなくなってたよね
ゲームプログラミング以外では
>>493 それは記事も読んでの感想?
あとenの方が分かりやすい
余談だけどenの方には
Trygve Reenskaug introduced MVC into Smalltalk-76 while visiting Xerox Parc, in the 1970s
ってちゃんと書いてあるね。
>>461 みたいな誤解も生じにくい。
ん? enのWikipediaに一言書いてあったらそれが真実になるのか すごいなー
>>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で多重継承とか複雑なことやるコードなんて書く機会あんの? C#なら分かるけど
>>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#はむしろ直交性を重視するほうだろ
ほんとだ。 Pythonはともかく、Rubyのこの挙動はひどいな。
>>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(){}
いや、理由も同じか、 2つのM1は別物だ
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 自分で動的言語の処理系作ってみりゃわかるが、上書きで別物になるのは自然
追加の方が意図してわざわざそうなるように実装してる
関数定義との一貫性から、クラス定義も Hoge = class {...} と考えるのが動的言語脳(≠Ruby脳)だろう 当然これなら上書きになるわな
せやね
言われればたしかにそれで自然だし、だから上書きでもいいと思うけれど、 ただ、オブジェクトの動的運用という面からは、クラスを再定義したら、 少なくとも名前が変わらず同じである以上、 再定義前に作ったインスタンスもサブインスタンスもすべて その再定義後の定義に従って欲しいし、そうでないとじっさい使い物にならない。
moduleとかclassとかやめて 全部Module.newとClass.newで書けば一貫性が出てくるんじゃね?
つまり、こんなん↓が出来るのは動的言語でも少数派なのかっ!
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だとスーパークラスのすげ替えのところでエラーになる。 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)
上書きだと単なるグローバル変数だから グローバル変数に強く反対する言語では、ただの上書きではない機能を付けておかないと 辻褄が合わなくなる
いやグローバルがどうというより 処理系が実行時の状態に依存し過ぎてるだけな気が
「グローバル変数に強く反対」したのは実行時ではないよ その思想に依存した結果、辻褄を合わせるのに苦労している
グローバルよりも大きいスコープの 見えない何かが絡んでる状態なわけだけど、それでいいの?
>>539 Rubyって動的言語なのにスーパークラスのすげ替えも出来ないの?
在日への生活保護 役人発表では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
そもそも、日本に借金をこさえさせたのは小沢一郎(たぶん在日帰化)。 小沢が430兆円 村山(旧社会党:こいつも在日帰化?)内閣がプラス200兆円 トータル630兆円 (詳しくは日米構造協議で検索) 今ある借金は、これとその利息では? 小沢は、自民党時代に日本に爆弾を抱えさせた上に、そのバラマキ公共投資で得た 支持基盤をごっそり自民党から引き抜き(仲間を引き連れ離党)、 自民を単独過半数割れに追い込んだ。 そして、第3極政党(新進党→公明党)を介入させ、韓国や在日へ利益誘導してきた。 ※自民党以外の議員は、日本姓を名乗る在日帰化か、その影響下にあると仮定。 という流れではないでしょうか。
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で十分ってこと?
ぶれないプロトタイプベースと、方言が多すぎるクラスベース
簡単に言えば あえて制約を付けたり型にハメるのを良しと思うのがクラスベースだからね それと実装の問題もある 最近出来た言語がプロトタイプベースを取り入れないのは最適化に熱心だから 例えばDartとか
Luaはプロトタイプベースだろ 10年後にはRubyを越えて普及してそうな言語
ないない
Luaがどう躍進するかより、 Rubyがどう廃れていくかが楽しみ
そんなこと言ってるけど他の言語は今後10年廃れない目処あるの?
Rubyは廃れていくだろうけど・・・ C++ Java PHP あたりも間違いなく廃れていくからなあ C#、JS、Python、Objective-Cはこれからもシェア伸ばしていくだろうけど Rubyは現時点で既にこれらの言語にぬかれてるわけで 相対的な地位は変わらないんじゃないかなあ
COBOLみればわかるけど、 お金が大きく絡んでる言語は 廃れないよ。
廃れやすさってのは、どれだけの 会社や人間がサポートしているかによる。 例えば特定の会社しか作ってないような言語は その会社がやめればすぐに廃れる。 やめなくてもその会社自体が縮小すれば廃れる。 旧VBとかDelphi言語とか 逆に複数の会社が作っていたり、 標準規格が出来てしまってるようなものは廃れない。
COBOLくらいだと廃れてるって言われると思うけどな しんでないだけで
C#…3.0と4.0で他言語をパクリ尽くして5.0ではパクるものが枯渇。6.0は出るか分からない。Mono次第。 Objective-C…万人が認める糞言語で、iOSの需要が高いから仕方なく使われてるだけ。代替品が出たらすぐ消える。 JS…各ブラウザ(主にIE)間の合意を取らないと拡張できないため、いつまでも予約されたクラスの出番なし。 Python最強
C++、Java、JSは有名で よく使われてる実装が複数あるね。 他の言語は知らない。
>>568 > JS…各ブラウザ(主にIE)間の合意を取らないと拡張できないため、いつまでも予約されたクラスの出番なし。
え? IEの合意なんかとらずに
どんどん拡張されてると思うけど、
ちゃんと現実を受け止めてるかい?w
>>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構文についても今となっては導入する方向で一致してる
仕様が結構大きくて、いろんな部分と絡んでるから実装は遅めになるかもだけど
それでも1年以内にChromeとFirefoxにほぼ完全に実装されるはず
一人が決めるんじゃなくて 多くの関連者が議論して決めているものでは JavaScriptは一番規模が大きくて 一番発展が早いものなのかもしれないな。
Mozillaが勝手にやってるとはまたアホなことを Mozillaが先陣切ってやってくれなかったらES6の仕様策定が何年も遅れたか縮小したことだろう Mozillaはそういう役目なのよ
>>578 それを見ればわかるじゃないか
IEもChromeも無視なんかしておらず
バージョンが上がるとサポートされてる。
Python以外はスレタイにあるのは全部枯れてるな 生き残るのはPython JavaScript Objective-C Lisp Smalltalk
>>574 ソースって程のものはないけれど、
知り合いのそこそこのスキルのあるPGの多くが
ここのところ連続でRailsの炎上案件の火消しに投入されて
のきなみ疲弊しているのをみてる
Mozillaからしたら元々自分たちの言語だしなあ そりゃ先陣切っていきたいだろ
>>581 しかし動きは相当遅い
全ブラウザで使えるようになるのはいつになることやら
>>583 俺の知り合いはJavaやPHPで地獄を見続けてるんだが…
実は業界の問題であって、言語の問題じゃないんじゃね?
MozillaはJSの人柱だから、今も昔も、 山ほど失敗してるが山ほど貢献してる。 Googleもプロトコルの人柱やってWebに貢献してるでしょ? OperaグループもいろんなAPIや規格に貢献してる。 最近は仕様に文句つけるんじゃなくて、 自分のできるとこやって貢献し合いましょうという雰囲気になってる。 だからES4の時のように荒れることはなく、皆凄く協力的でいい感じ。
>>582 Pythonはいい言語なんだけど、
LispのS式の柔軟性やSmalltalkの動的性ほどは
「これ」ってウリがないのが残念
守りにまわっちゃって「ウリ」をいろいろと諦めているのに 肝心の守りのほうも守り切れてない感じ。>Python
Mozillaが実装しているのは、それが新しい仕様を
作成するための条件の一つだからだよ。
勝手に実装しているのとはわけが違う。
http://www.html5.jp/trans/whatwg_html5faq.html > 実装者に、その機能を実装することをコミットしてもらってください。
> もしあなたが複数の実装者にその機能を実装してもらうことができないなら、
> 実験的に最低でも一つのユーザーエージェントに実装してもらうようにしてください。
> 実験的な実装は、公式に利用可能でなければいけません。
JavaScriptの世界は皆が議論して、仕様を決めてから実装するような世界じゃない。
まず誰かが実装する(それがMozillaが多い)
最初の一人が実装した時、その他が実装してないのはあたりまえじゃないか。
MSのスタンスとしては、標準になったものを実装するという考え。
だから、Mozilla、Chrome、標準化、MS という流れになるのが多いだけの話。
で、そもそもなんだっけ?
JavaScriptの世界は常に拡張され続けているってことでよかったかい?
>>585 Chrome31で見ると29より何個も緑増えてるよ
着実に進んでる
ただV8は仕様変更がありそうなものはおいそれと実装したくない
本格的に実装が始まるのはラストコールが出てからだろうね
でも下準備はしてるよ、ES6で究極に重要なSymbolsの実装は早々に済ませてるし
いくつかの仕様も実装進めてる
最近だと配列内包にGOが出た
Railsの案件ってどういう炎上すんだ? Ruby1.8系からRuby1.9系に移行したり、Rails2系からRails3系に移行させるなら死人が出るかもしれんが・・・ 正直、Railsで作ったものは保守しにくいとか拡張しにくいとかそういうのは全くないわ ただし、Railsは無駄にRails固有の知識が必要だから、未経験者にいきなり就かせて 生SQLではなくてActiveRecord書けとか命じたら困るな
>>590 いやいや、ES4の頃一旦棚上げ(没)になった皆が議論した仕様を入れてるだけだよ
配列内包はfor-ofとは絡んでるけど、単独機能だから実装はしやすいでしょうね。
>>593 だから?
ES4で議論された機能が復活する。
それもまた拡張の一つの形だということかい?
>>592 ヒント:Java土方がRails使わなくちゃいけない案件どうなるか
3大勢力が実装していて 競争状態に見えるぐらいになってる言語は JavaScriptぐらいしかないよね? その他はこじんまりとした 個人プロジェクト+取り巻きに近い。
>596 Railsは凄いんです。 だからどんな人でもRails使った途端 ハゲが直り恋人もできます。
>>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の移行劇は、旧バージョンとの互換性を無視した新バージョンを開発し、 > そのあげくに数年前に開発を終えた旧バージョンを未だに切り捨てられないどこかの言語とは対照的 Pythonのことですね、分かります
うーん、やっぱり旧バージョンを切り捨てるって凄く困難なことなんだね
このRuby厨の必死さがRubyの先行きの暗さを物語っている
>>611 旧バージョンを切り捨てないほうがすごく困難だと思うけど?
>>612 いやいや、アンチRuby厨の必死さには負けますわよw
Rubyの恐ろしさは、単に今までの文法が廃止とかそういうレベルじゃないぞ。 それこそマイナーバージョンが一つ違うだけでgemがコケるじゃん。
>>613 だから、後方互換性を意識した仕様変更を考えるんだよね、普通の言語は....
>>615 こけるgemもあれば、こけぬgemもある
>>616 未来は誰にも予測できないんだよ。
後方互換性を維持するのが難しい時ってのは
絶対にやってくる。Rubyもあったじゃないか。
後方互換性を維持するのが難しいと思った時、
諦めるのと、諦めないの、どっちが困難だと思いますか?
Matzは内心ドカタ嫌ってるんだろうなあ Rubyはそのうちコアの言語オタ連中放置してドカタ方面へフォークすると思う
>>617 先生、MySQLアダプターがコケる場合はどうすればいいんですか。
RDBを変えればいいんですか
>>628 諦めろ。それが一番(開発者が)楽な道だw
>>615 いやあ、普通は「今までの文法が廃止」のほうが恐ろしいだろ
それこそ、単なるサードパーティ製のパッケージのバグとはレベルが違う影響度だよ
互換性を切り捨てるのは(作業的に)簡単だけど、(しがらみ的に)困難だよ
JSみたいに後方互換性を維持するしか選択肢がない言語もある
>>624 つまりRubyの世界では、しがらみ(互換性)を
何も考えないから簡単なわけですね?
>>618 仮定を元にした予測に答える価値は無いな
例:
明日、世界が破滅します
諦めるのと、諦めないの、どっちが困難だと思いますか?
>>625 いや、今のJSの世界知ってるかい?
全く違う言語からJSに変換することで
互換性が全くない言語すらできてるんだよ。
>>627 仮定を元にした発言はしないという
言葉は聞いたことがないが、
仮定を元にした予測ってなんだよw
予測は全て仮定だろ?
どやセリフでも言ったつもり?
それは変換後のJSに互換性があればいいじゃないの?
Rubyが駄目なのは後方互換性を放棄しているからじゃない。 他の言語もそういうことやっているし、今ではみんなが使っているjQueryもそうだ。 他の言語の場合、例えば「バージョンアップに伴い****というメソッドが廃止されました」というアナウンスがされた場合、 その****を別の代替メソッドに変えれば済む。 ところがRubyの場合、****とは全く関係ないクラスライブリ群が大量にエラーを吐く。 そう、Rubyは実装がどうしようもないのだ。 C言語で書かれたRubyをJavaどころかPythonで書きなおしたら速くなったという事例すらある。
>>626 >>624 的に言えば、逆だろw
Ruby:(しがらみ的に)困難な、互換性を維持する道を選択した
Python:(作業的に)簡単な、互換性を切り捨てる道を選択した
結局どこまで将来見据えて言語設計できるかってことに尽きるね
>>627 あー逆だったw
仮定を元にした発言はしないという
言葉は聞いたことがあるが
仮定を元にした予測に答える価値はないってなんだよw
予測は全て仮定だろ?
どやセリフでも言ったつもり?
>>632 >C言語で書かれたRubyをJavaどころかPythonで書きなおしたら速くなったという事例すらある。
ソースは?
それとも
>>632 の脳内かなw
C#/VBはメジャーな言語としてはむちゃくちゃ急進的だけど後方互換性保ってるじゃん 予約後増やさずにキーワード追加することに命賭けてる
>>628 意味不明
新しい規格を採用したエンジンで過去のスクリプトが動かなくなることを認める訳にはいかないでしょってことだよ
既にエンタープライズ用途のrails出てるだろ 行政交えてスタートアップのモデル都市でも作らないと 日本って、また、IT分野で国際競争に負けるんじゃねーの? 大体、海外サービスに日本円を吸い上げられるのは見えてるんだし
>>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 のいう「(予測が)外れた時に諦める」という
「最悪のやり方」を選択してしまった事
なんとかならなかったものなのかなぁ......
忘れてる人もいるかもしれないけど、 もともとHTMLには実行エンジンを 切り替える仕組みを持ってるんだよ。 <script language="JavaScript1.2"></script> こう書くとJavaScript1.2で動く。
>>660 あー、なるほどね
つまりWebサイトの閲覧者は、どうもJSが動かないなと感じたら
ブラウザのメニューからES5互換表示を選択すればいい訳だ
それは確かに正しい、こちらが間違っていた
大変申し訳ない
> ブラウザのメニューからES5互換表示を選択すればいい訳だ それしか思いつかないのが、お前の限界w
新しいエンジンで実行したいのなら httpヘッダで指定するってやり方もありそう。
>>662 じゃあそれが書いてなかったらJS何で動かせばいいのよ??
JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの??
そういうので問題起きてるんと違うん??
それは解決方法でもなんでもなくて、むしろ問題だと思うよ。
外部ファイル前提だが、拡張子を変えるというても思いついた。
こういう無茶苦茶な理屈並べるのってネタなのかマジなのかわからんから怖い
>>666 > じゃあそれが書いてなかったらJS何で動かせばいいのよ??
互換性を保つためと考えれば、
古い実行エンジンに決まってるじゃないかw
> JSファイルを実行したい時はそのファイルがJS何なのか把握しておかないといけないの??
開発者(scriptタグを書く人)・・・当然閲覧者ではないは
それぐらい把握できるだろ。
こいつみてると、互換性を保つ方法を考えるのにも
ある程度の技術力がいるんだなぁって思うわw
> こいつみてると、互換性を保つ方法を考えるのにも > ある程度の技術力がいるんだなぁって思うわw そう。だから互換性を切り捨てる方を選んだほうが (力のない開発者にとっては)簡単。楽。何も考えなくていい。
>>662 ,663,665,667,670
こんなことでいいのなら、今までJSが必死に互換性を守ってきた努力は無駄だったな。
それだけじゃなく他言語でも心配するのが馬鹿らしくなる。
つまりこういうこと? 「理屈勝負では負けたが、とんちクイズでやり返してやったぞ」
>>672 互換性を保つのは、新しいエンジンを作らないための努力ではなくて、
古いコードをそのまま使えるためにすることだよ。
おバカさんw
675 :
デフォルトの名無しさん :2013/09/16(月) 00:49:36.73
JSのバージョン指定はFirefoxでも廃止されたばかりなのになんと時代錯誤な。
>>674 急にどうした!?
なにか俺に見えないものが見えてるのだろうか。
>>675 もしそれが必要になる事があれば復活するでしょ。
互換性を保つのは困難ではあるが
できないことではない。
>>676 お前こそどうしたんだ?って
みんな思ってると思うが・・・。
そもそもJavaScriptにバージョンってあったっけ? 元規格のECMAScript仕様とMozillaが勝手に割り振ってるのはあるけど JSはLivingStandardってやつじゃないの
ECMAScriptの4とか5とか6というのが バージョンじゃないのか?
狂人にはもう触るな…
そう。巨人には手を出しても負けるだけw
後方互換性があるからちょっとずつ仕様追加してLiving Standardでいられるのよね。
巨人様、どうかお鎮まり下さい。 私達のスレを踏み荒らさないで下さいませ。。。
人の言葉がなかなか通じぬと思っておったら、やはり奇行種であったか……っ
後方互換性があるからというよりも 後方互換性を保つように仕様を追加してる。 だからそんなに大げさな話にならないんだよ。 まあそれも技術力がなければ、 あっさり諦めるんだろうけどねw
何を誰に言っているのかわからん 独り言か???
>>687 まあ、誰にいってるかを書けば、
誰に対しての負け犬の遠吠えか
わかっちゃうから言わないんだろ
ここでJSのセミコロンは維持すべきかどうか聞いてみる
Rubyでもセミコロンの有り無しで 動きが変わる例があったよね? ようはそれをどう捉えるかだと思う。 動きが変わる例を人間がしっかり理解し把握するか 危険な書き方とみなしてやめましょうと考えるか。
自分はnpmスタイルに感銘を受けて付けない派やってる。
「式だけ」の文の前の文の終わりに注意すればOK
別のエンジン乗せるだけなら、JavaScriptではなくVBScriptでもいいじゃないか。
>>694 そのとおりだと思うが
そもそも別のエンジンのせる理由がない。
互換性も別のエンジンを載せるまでもなく対応出来てるから。
JSくらいシンプルで10年も大勢の人に使われた上で 優秀な企業の人材が議論して仕様を決めるんだから そりゃ互換性取りに失敗しようがないよな ES6みてもまだまだ追加はできそうに思う キーワードの問題はちょっとあるが 後から無かったら良かったと思えるものは無さそう
JSで無かったほうが良かったとされる物第一位はwith文だろうな。 最適化云々は勿論、新アイディアの議論するとき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の歴史を理解するいい機会じゃん 他所を知らないと真に自己を知ることは出来ないし
やりたいなら勝手にやればいいじゃん? お前がやらないからRubyの話題が出ないんだろう。
709 :
デフォルトの名無しさん :2013/09/16(月) 04:19:02.24
ノータリンには
>>704 ,706がRubyの話しようって書いてあるように見えるのかな。
じゃあお前は、言語に関係する話を 何もしなくていいよ。 俺らで勝手にやるからさ。
711 :
デフォルトの名無しさん :2013/09/16(月) 04:48:50.58
よく考えてみると動的言語でこれだけ みんなで寄って集って改善してるのって JavaScriptが最大規模じゃね? 静的言語はコンセプトが違うから どんなに改良しても動的言語にはならないと思うが、 JavaScriptはいろんな動的言語の機能を吸収して 最強の動的言語になりそうな気がする。 言語仕様を変えてもいいのであれば、 どんな機能だって取り入れられるだろうし。
JavaScript古いものごっそり削ればいいのにな
>>713 実装は寄ってたかってものすごく改善されている
これは競争のメリット
逆に仕様は寄ってたかって議論してるおかげで遅々として進まない
これは競争のデメリット
HTTP廃止して一回Webリセットすればいいお
718 :
デフォルトの名無しさん :2013/09/16(月) 09:15:54.02
719 :
デフォルトの名無しさん :2013/09/16(月) 09:16:52.19
>716 XMLモナ
オススメのDBの管理方法教えてください 言語はrubyです アフィカスサイト 作ってます
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最強と言うことでおk?
OK
たしかに意外な組み合わせが最初に来るな
じゃ、Ruby最強ということで h = Hash.new(0) ["○", "○", "○", "△", "△", "×"].repeated_permutation(2){ |xs| h[xs.sort]+=1 } p h.sort_by(&:last).reverse
>>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最強。
ライブラリ2つ使ってなおこの冗長な記述には勝てる気がしない。w
>>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には勝ってるよ。すごいよ。
あー、でも結果まちがってる…… 残念ッ!
副作用使うなよ格好悪い PythonもRubyもだが
>>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)だけど、古いのかな?
うっかりしてた 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]]
>>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が地味にすごいな
メソッドコールの数でステップ数だしたら Rubyより少ないんじゃ?
奇をてらってみた 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]]
GJ!
>>751 じゃぁこれで
a = "○○○△△×".chars.repeated_permutation(2).map(&:sort)
p a.uniq.map { |x| [a.count(x), x] }.sort.reverse
コレクション禁止縛りっすか
副作用なし %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]]
副作用なし(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)
あのう、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 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)
短いコードより早いコードで頼む
まあ、そりゃ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は一行にまとめて書く必要はないよ "○○○△△×".chars .repeated_permutation(2) .group_by(&:sort) .map{|a,b| [a, b.size]} .sort_by{|e| -e[1]} ネストした関数コールよりは見やすいと思う lambdaを導入したJavaやC++のコレクション操作もこういう方向に進んでるのでは
>>780 わかりやすいコードは短いコードである ×
わかりやいコードは行数が少ないコードである ×
わかりやいコードはカッコが多いコードである ○
こうですか?よくわかりません
誰かHaskellで書いてみてくれ
Haskellまだー?
>>782 Pythonは、LISPの方向に突き進んでいます....
>>782 >ネストした関数コールよりは見やすいと思う
>lambdaを導入したJavaやC++のコレクション操作もこういう方向に進んでるのでは
Pyhtonだけ時代に取り残されつつあると感じるのは、気のせい?
Pythonは外部イテレータやyieldをいち早く導入したのに活かせてないんだよなあ もったいない
で、そのコード関数にして10000回実行して1秒以内に済むの?
ナンセンスでしょ 先のRubyとC#のコードなんてほぼ同じだけどC#の方が圧倒的に速いだろうし
C#はそもそもスクリプト言語じゃないじゃん。
処理系次第だという極端な例を挙げただけだよ
流石にC系と比べろという人はいないと思うよ
処理系がクソなら 短さを多少犠牲にして速度を重視する軸で比較しても面白いと思うけどな 競わなくてもいいけど、実際何の環境で何msかかるか知りたい
組合せならば、リスト内包表記のあるPythonに有利なお題かと思っていたが、 意外な結果で終わりそうだな
今日中に終わらない処理系とか流石に無いよなw?
>>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=["○", "○", "○", "△", "△", "×"]; $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); }
import collections, itertools g = itertools.product('○○○△△×', repeat=2) print(collections.Counter(tuple(sorted(x)) for x in g))
こういうコード晒し大会って一行になんでも詰めて書く奴がいるから萎える
とりあえず一万回回した時のタイムを測ってみてはどうか
>>810 この流れでそんなコードを晒した勇気は認めてあげる
Time厨うぜー スクリプト言語に速度なんて誰も求めてねえよ
importしてる時点で大反則だよ ライブラリやモジュール使えばどんな言語も1行で済むし
Ruby厨息してない
import はいいだろ 外部ライブラリを使ってるわけじゃなし
確かに外部ライブラリ使うのと変わらんな。 これを認めると意味がなくなる。
外部ライブラリ使うのはいいよ 外部ライブラリの行数も加算すれば
僕は○○の開発者だけどこのスレをたまたま見ました コード量削るために次のリリースで組み込んでおきますね^^;
じゃあimport原則禁止でお願いします stdoutとか直接ロジックに関係しないのと ないと動かないのはあっていいです collectionsとかitertoolsみたいな 普段のコードで必ずしも使わないモジュールの読み込みは不可です
公式モジュールならいいだろ・・・
外部じゃないよ 標準ライブラリだよ importは、ただ単にネームスペースが別れてるだけ
>>826 じゃ、Javaみたくimportなしでも完全名を書けばおkなんだ?
Rubyだれかideoneでベンチ書いてくれ 自分の環境だと動くんだけど、ideoneだと動かん
便利モジュール読み込んでいいのならライブラリ勝負と変わらんだろ…… 標準とか関係ないよ
namespace観念のないRuby厨
便利モジュールを読み込むの禁止 これいいね
このままだと速度もソースもphpの圧勝になるぞ
完全にフェアな条件なんてそもそもないんだからさ。 なんで頑なに嫌がるのか不思議。
違うネームスペースを参照するのにimportがいる言語はpythonだけじゃないぞ
リストもハッシュもソートも禁止だな
標準ライブラリ否定w こいついつもの屁理屈野郎だろ。
また短いコードが出て来てから騒ぎ出す辺りが 滑稽で見苦しいな
このスレのPythonerが自力では何も出来ないレベルの低い奴っていうのが良くわかった
不利になるとなんでも縛ろうとするのが洗脳されたRuby厨の末路 自分が好んで縛られたからって他人まで縛るんじゃないよ
import無しでいいコードを書いてみればいいじゃない できないからグズってるんだと思ってしまう
自分の言語の都合にだけハマってたら、 分かり合うことなんて出来ないでしょ。 Pythonならもっと面白いコードに出来るんじゃないの?
Ruby5倍ぐらい遅いんだが、何かオプション付けないとダメか?
ウンコなコードで勝ち誇ってたら アッサリ逆転されて悔しいよ〜
むしろSmalltalkのBag相当を標準で持ってるのが 他言語だとPythonしか無いのが信じられん クソすぎる
※但しインポートしないと使えない※
Pythonは素では何も出来ない言語なんだってのがよく分かったw
>>846 Pythonは悪くないだろ
書いてる奴がド底辺なだけだ
何でもデフォルトの名前空間に突っ込んでるゴミ言語が最強
グローバルに備わってないような機能をインポートしてさも平然と使っていいのなら ライブラリをインポートして使ってもよくなるじゃんってことでは?
よくわからんがBugくらいどの言語でもすぐ実装できるんじゃ?
他の言語、遅くて3秒とかなのに、Rubyだけ17秒かかるんだけどなんで? こんなもんなの?
>>758 を10000回実行したら3秒くらいかかる。
PentiumDだから今のCPUなら1秒切るくらいかな?
>>848 BagなんかANSI(あれもないこれもないってSmalltalkerには不評)にも入っているし
最小限の部類なんだが…
コレクションやイテレート処理くらいデフォルトで使えないと文句言われてもしかたないね
また関数型の話するの? 好きだねえ。
; 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)))
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 $h{join '', sort split /:/}++ foreach(glob join '{:}', ('{○,○,○,△,△,×}') x 2); print map{"$_=>$h{$_} "} sort{ $h{$b} <=> $h{$a} } keys %h;
うーん、、、 ならRubyは今の最新バージョンに上げたら10倍早くなるの?
速度の話は確かに環境が違うからあんまあてにならない 最新の安定版と評価版を同じマシンで使って計測とかならまだしも
流石perlはどこか違うな
10倍も差がでてて環境による発言は見苦しいな 2倍でも大差なのに
Rubyも1.8と2.0じゃ速度差は3〜4倍は違うんじゃね? 関係ないが、Rubyは、2.0.1出る前に2.1.0出そうだし、そろそろ安定期かね
単純演算が遅いのはあまり言い訳できないと思う。
10,000回
Ruby(
>>760 ): 3.62sec (v2.0.0)
Python(
>>812 ): 2.41sec (v3.3.2)
現状それだけ差があるのなら 速くできる余地が一番ある言語と言えよう
Ruby1.8.7をベンチマークに使うのは流石に可哀想だろ
1.8.7ならダメってどういうこと? 言語のバージョンと実装の速度は直接関係ないんじゃないの? それともRubyの仕様は後方互換性犠牲にして最適化重視してたりするの?
>>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はフィボナッチベンチが速くなるように頑張って最適化してるよ
そんなん他の言語は10年以上前からやってきたことだけど
ジワジワすぎて ようわからん
>>883 の地域別がおもしろい
Ruby島根が1位wwwさすがお膝元だな
そして茨城県民は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使ってるところ多いよな ちょうどRailsが流行り始めた頃だったから
それ間違いだね
「他の言語の〜のようなもの」っていう決まり文句が出てきたら 当たり前だが実際は大抵結構違うことが多い
Rubyほどの完成された言語に Bag程度のクラスがないのはすごく不思議
なんかコレクション系の1つや2つくらいないの?
重複を許す集合だから、集合の要素と、要素が重複した回数のペアを持ってるんでしょ > Counter
>>899 まあSetだってずいぶん後だったしな。
Matzのコレクションの知識なんかそんな程度。
大クラス主義とかいうとそれらしく聞こえるけど、ぶっちゃけ RubyのコレクションはArrayとHash(でカバーできるユースケース)以外は ろくすぽ整備されていないとも言える
集合って概念において、順序を持ってちゃいけないなんて別にないよ。 いわゆるプログラミングのSetが順序性ないだけで。
ん? Setにも順序はあるだろ 毎回イテレートする度に順番変わるわけじゃないんだし
SetやMapが入れた順番でイテレートされない言語ってあるの?
Setは集合、順序も重複もない MultiSet/Bagは多重集合、重複がある
順序があるかは仕様次第でしょ。
なのでSetは基本的に順序性を保証しない きちんとそうリファレンスに書いてある言語もある
>>903 優先度はかなり低いからね
言語の目的からして
Setは基本的に順序を保証するものでしょ じゃないと何かをSetにかけて重複取り除いて戻す時困る
>>911 Setは基本的に順序の保証も重複もない
順序を保証していたり、重複を許す場合はかなり特殊
順序が保証されなかったら例えば "I","am","am","Tom" というのをSetにかけてイテレートしたら "am","I","Tom" になるかもしれないってことでしょ 困るじゃん
>>914 なるかも知れないではなく、なっても良い場合にしか使ってはいけない
順序性を当てにする時点で使い方を勘違いしている
配列からSetを作ってそれを配列内包で配列に戻せないのは残念だな。
むしろSetに2つ値をいれて2つイテレートされる環境の方を知りたい そんなのあるのか?
Bagってlock-freeにできるから並列処理には役立つけど 逆に言えばそれくらいだろ Bagならではの効率的なアルゴリズムってのが特にない(lock-free以外)
>>916 それは順序が保証されないSetは表現力が低いってことだよ
前スレで合ったけど順番が保証されてた方が Setをuniq関数としても使いやすいってことかな?
>>920 代わりに要素検索のスピードをあげる、などの実装的メリットがあるんだよ
>>920 違う
それはOrderedSetであってSetではない
Setを順序が保証されるものとして使ってはいけない
イテレートしにくいのならHashとあまり変わらん気がする
Setを順序が保証されるものとして使ってはいけないが Setのデフォルトの実装が、OrderedSetであってもいい。 いうなれば、Setは抽象クラス。 その実装がOrderedSet
>OrderedSetであってSetではない ワロタw また屁理屈合戦始まるかw
>>924 イテレートはふつうにできるよ。
順不同なだけ。
>>927 RubyはSetとSortedSetの両方があるな
PythonはSetだけかな
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とは割と別物なんだよな〜 本体組み込みのものでもimportしてから使う物とかあるし… 逆に、勝手に読み込まれるのに本体組み込みじゃないものとかもあるが
Setを持つ言語のほとんどは順序を保証してない 順序を保証するOrdered Setを別に用意している言語も多い 用途に合わせて使い分けましょう これだけの話だよね?
setって要は集合だよ。 ベン図に要素描くとき順序の一致を気にする奴はいないだろ? って最近はベン図を教えてないのか!
Bagというと検索できないもんだろ? 順序保証なし、重複あり、検索不可 検索不可だからハッシュはいらないし、順序がないからって動的配列より効率的に実装できるかというと特にそんなことはない lock-freeな実装ができるのがメリットでスクリプト言語では不要
皆一体何が話したいの? OrderedなSetとOrderedじゃないSetのどちらが普通のSetと呼ぶべきか喧嘩して何か意味あるの? 現にSetという名前で既にどちらもそれぞれの言語に導入されてるんだから、仕方無くない?
>>948 検索はできるよ。indexOf みたいなことができないだけ。
ただのSetに順序があると思ってはいけないというだけで、 Setに順序を持ってはならないという決まりはない。 Setの条件に順序が規定されてないだけ。 Setを拡張したOrdedSetであれば順序が規定されている。 OrdedSetはSetの条件を満たしているので、Setである。 こういう話。
>>949 OrderedなSetはない
メジャーな言語ではSetは順序性、重複を保証しない集合型の固有名
>>950 Bagが検索できないといけないという決まりはない
だからこそlock-freeにできるんだよ
>>951 決まりはないが、RubyもPythonもC#もJavaもSetは順序を保証しない
Ruby、C#、JavaにはSortedSetが別に用意されている
順序を保証しないと 順序がないを ごっちゃにしてる馬鹿ばかりだな。 OrderdSetはSetである。 これぐらい理解しろよ。アホども 数学勉強しろ。
groovyのsetって、どうだっけ?
JavaScriptのSet 23.2 Set Objects A Set object can iterate its elements in insertion order. Orderedです。
>>953 なんか、Bagはlock-freeにできなきゃだめって
決めつけてないか? どこにそんなこと書いてあるの?
JavaScriptは「メジャーな言語」とやらには入らないとよ
しつこく拘ってすまない
>>951 の言うことが正しい
>>905 みたいな人がいたので、
Setは基本的に順序性を期待するべきでないと言った
bagが検索可能である必要はないが、並列処理のできないスクリプト言語におけるbagは 効率的な検索ができないならそもそも動的配列と何も変わらなくなってしまうので、検索できないと存在価値がない 紛らわしいからMultiSetと呼ぶべきだね
>>960 メジャーなが言語の例外
JSはobject型と同様のイテレーションを当てにしてる奴も多いしね
>>961 だからさぁ。
SetというのはSetオブジェクトのことで、そんなん言語によって違うでしょ。
食いつくとこおかしくない?
というか揉めるって分かっててやったんじゃないの?
>>962 いやいや、Bagの価値は、まさにこのサイコロの例のように
h[e]+=1イデオムを抽象化できる所にもあるだろう。^^;
Setは順番がないと言い切るからダメなんだよな。 順番があるかないかは、実装による。 順番があるSetも、Setの条件を満たしている以上 Setである。
>>962 最初にこれをBagと呼び始めたSmalltalk涙目www
>>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だと順序以前にプロトタイプも遡るしめちゃくちゃだわ 今だとObject.keysっていう救世主がいるからそちらを使うにこしたことがない
>>981 まあまあ。
昔はそんな問題もあったってことで
>>980 どうしてなにを持ってそれがFAになるのかさっぱりわからん。
JavaScriptは1,2年で状況がガラッと変わるから 印象ってのは当てにならんぞ
>>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はええってなった頃までの時期だな
まあ5年前くらいか
そしてES5が出来、HTML5が注目を浴びだして
ブラウザやデバイスシェアが大きく変わっている今も
テストやツール方面と、入門者に良いコーディングを覚えさせる方向なんかで
第二次意識改革が進んでる
>>988 >Bagはただそこに要素を突っ込んでいくだけで
>h[e]+=1 イデオム相当のことができるってところに意義があるんだよね。
よく分かった、ありがとう
数学的には、multisetは集合から自然数への写像として定義可能っていうか、典型的にはそう定義される。 だからPythonのCounterはmultisetの条件は満たしてると思う。 Bagと同じかどうかは知らない。
数えるというより、lock-freeみたいな適当に放り込んで適当に取り出すだけのものを bagと呼ぶのは言葉の印象としては自然な気はする
結局、Smalltalkerは数学の素養も無いのに 無知なまま多重集合について語ってたでFA?
>>994 BagとMultisetの違いも分からないお馬鹿さん?
Smalltalkerならぬ、 Bigtalkerだったって事だナ ガハハ
結局、
>>862 は数学の素養も無いのに
無知なままBagについて語ってたでFA?
Bagはただの多重集合じゃないんだよ、だからCounterとは違うって話だったら
こんなに話がこじれなかったよ。
Counterは多重集合じゃないって言うから(例
>>988 )こじれたんだろうに。
ばかばっかだな
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。