12/02/11 23:22:35.94
ねえねえ、Rubyは外部定義すれば「ちゃんと」書けるんだよね？
それならそうした方が良いと思うよ
812:621
12/02/11 23:24:30.47
>>807
だってこれは Ruby vs. Python のバトルなんだもんw
ML/Haskellの表現能力に制限があっても関係ないだろ
813:デフォルトの名無しさん
12/02/11 23:25:30.83
ユーザ定義関数を使用禁止の大規模開発www
814:デフォルトの名無しさん
12/02/11 23:27:41.31
Rubyは結局Perlだから、書き捨てオレオレコードに向いてるって言えば良いのに
815:デフォルトの名無しさん
12/02/11 23:29:36.90
unix系では外部関数どころか外部言語を平気で使うから
優れた言語を一つだけ決めるようなバトルは発生しないんだよな。
一般的に言うと文字列を多用する環境ではバトルがない。
S式やオブジェクトなど、文字列に代わるものを使い始めるとバトルになる。
816:621
12/02/11 23:36:00.12
>>811
うん、書けるよ
でも外部宣言でRubyコードを書く気は無いよ
バトルなんだから、相手に有利なことをするわけないだろ
残念でしたw
817:621
12/02/11 23:38:40.29
>>814
自分の思い通りに話を進められなくて、残念でしたw
818:デフォルトの名無しさん
12/02/11 23:44:20.72
>>816
つまりRubyっていずれにしても汚いコードしか書けないから不利になるってことか
自分のお題で自分の首を絞めるなんてなあ
819:デフォルトの名無しさん
12/02/11 23:55:18.54
>>809
ys = (x for x in xs
if (lambda x :
True if x == "Green" else
True if x == "Yellow" else
False if x == "Red" else
{}[x])(x))
820:デフォルトの名無しさん
12/02/12 00:02:34.21
どいつもこいつも時代が見えてない。
クラウドにおいては、PCはただの端末だ。
動画が見れるミニテルに過ぎん。
クラウドの真ん中に鎮座しているのはMapReduceだ。
もはやPythonやRubyの出る幕はない。
821:デフォルトの名無しさん
12/02/12 00:14:47.14
>>719
デコレータ自体の表現力はいいと思うけど
型チェックやバリデーションのための機能としてみた場合、
なんか書き方が冗長すぎるなぁ
読むのが疲れる
822:デフォルトの名無しさん
12/02/12 00:17:20.70
>>820
もしかしてMapReduceが万能の技術だと思ってる？
あれ、レスポンスタイムが重要なところには使えないんだが。
向いてるのはバッチ処理だけ。
823:デフォルトの名無しさん
12/02/12 00:22:18.19
MapReduceはスケールしやすくて
意外に汎用性がある点で注目されたというだけで
それが全てかというと決してそんなことはない
例えばパイプラインとか、ステンシルとか、
他にも様々なパターンらしきものが見つかっている
824:デフォルトの名無しさん
12/02/12 00:27:22.50
Pythonのlambdaは汚点でしょ、何故あんな中途半端な仕様のまま残ってるのか解らん
いっそ削除してしまえば「ローカル関数作れ」で統一されるという利点にもなるだろうに
825:デフォルトの名無しさん
12/02/12 00:29:33.48
>>821
こんな感じ？
@typecheck
def f(x:int, y:int) -> int:
return x + y
@validate(x=lambda x: -1 < x < 1)
def g(x):
print(x)
826:デフォルトの名無しさん
12/02/12 01:06:45.76
>>641
>if <cond> then <true> else <false>
>が判り易いなんて思い込みだろ
><true> if <cond> else <false>
>の方がシンプルで良いじゃん
何を根拠にそう決め込むのか？
おまえこそ思い込みだろww
>っていうか何で「ただの値を返すだけの記号」だと思えないんだろう
<cond> ? <true> : <false> を「ただの値を返すだけの記号」だと思えないやつが何言ってるんだw
Python信者アホすぎるww
827:621
12/02/12 01:28:13.77
>>819
お疲れさまです
コードを拝見したところ、raise文の代用として、
空のハッシュを入力値で参照することでKeyError例外を投げる実装みたいですね
でも残念ながら、見逃してもらう必要は無いという貴殿の意志を尊重すると、
これは「例外を投げる」という意味では仕様不適合ではないけれども、
任意の例外を投げられるRubyに対して「Pythonでは決まった例外しか投げられない」という、
表現能力におけるPythonの欠点であると評価します
自分としては多分岐の評価項目については完全に引き分けであると判断して、
>>621から項目そのものを削除したいと考えているのですが、
このままでは>>621の改訂版に上記の評価結果を反映せざるを得ません
もし可能であるなら、任意の例外を投げられるコードへの書き換えを希望しますが、
コードの書き直しかそれとも>>819を最終完成品とするのか、どちらを選びますか？
後から非難されるのを繰り返したくないので、お手間をかけますが返答を願います
828:デフォルトの名無しさん
12/02/12 01:28:45.71
>>862
「ただの値を返すだけの記号」だと思えれば良いなら、
条件分岐構文の読みやすさに差はなくて
慣れだけの問題ってことだな
829:828
12/02/12 01:29:38.00
>>826の間違いだった
830:デフォルトの名無しさん
12/02/12 01:33:33.19
>>827
>>700のコードで良いよ。任意の例外を投げれるし
で、「標準関数以外を使えない条件でのみ、投げられる例外に制限がある」と明記しといて
831:デフォルトの名無しさん
12/02/12 01:37:08.14
>>824
代入文等の文を使えないのは関数型の原理主義的には正しい仕様。
832:デフォルトの名無しさん
12/02/12 01:39:16.59
ああ>>765だったね、失礼
まあ、言語の表現能力とやらをどう判断するかは各人の自由だと思うので、
条件だけは正しく明記してください
833:デフォルトの名無しさん
12/02/12 01:42:49.00
じゃあ今度は>>825を各言語で書いてみよう
834:デフォルトの名無しさん
12/02/12 01:47:32.00
>>827
> 自分としては多分岐の評価項目については完全に引き分けであると判断して、
Rubyのコードはクソという意見多数なんだが、どうして引き分けなんだ？www
835:デフォルトの名無しさん
12/02/12 02:02:18.33
>>831
でもそれって文への依存性が低いからこそ言えることじゃね？
本場の関数型ならlet式とか、分岐も式だったりするから実用になるけど
文への依存性が大きい現状のPythonで文が書けないってのは大きなマイナス点よ
836:デフォルトの名無しさん
12/02/12 02:39:44.80
>>763
Vistorパターンはトリッキーで好きだが、難しくしてるだけだろ。
普通にポリモーフィズムでごりごりやった方が楽。
837:621
12/02/12 02:51:02.36
>>830
了解しました
また、その補足文章をそのまま明記することを約束します
では、>>621の改訂に取りかかろうと思いますが、
少し疲れたのでこの辺で一時休息に入ります
改訂版のカキコまで、しばらくお待ちください
838:621
12/02/12 02:55:18.38
いけね、>>832を見落としていた
>>832
了解しました
改訂版は>>765とし、条件は必ず明記します
839:621
12/02/12 03:06:17.34
>>834
このバトルスレは討論により勝敗を決するものであり、多数決で決めるものじゃねえだろ
もしも多数決で決めたかったのなら、
最初に(前スレまたは今スレ>>625)それを主張して皆の同意を得ておくべきだったな
それを今頃になってのこのこ出てきて、多数決などと言い出しても遅すぎるわ
残念だったねw
840:デフォルトの名無しさん
12/02/12 03:19:52.79
>>833
Common Lispで
(declaim (ftype (function (integer integer) integer) f))
(defun f (x y)
(+ x y))
(declaim (ftype (function ((real -1 1)) *) g))
(defun g (x)
(print x))
(g 1) => 1
となるが。
841:デフォルトの名無しさん
12/02/12 03:30:12.69
多数決じゃ逆立ちしても勝ち目がないから、ノイジーマイノリティが勝つ設定じゃないと困るんだろ
関数型言語信者がよくやる手口だな
そんなことやってるという事実が既に負けなんだよね
比較の条件も厳選に厳選、限定に限定を重ねて、やっと優位を示したかと思ったら
クソコードだし、何をやりたいのか分からん
842:デフォルトの名無しさん
12/02/12 06:42:46.88
>>802
馬鹿ですね
わかります
843:デフォルトの名無しさん
12/02/12 09:14:00.97
僕 Python 信者
ここは LL スレだからしかたないかもだけど
Python vs Ruby っていう比較で Python を選んだ人は少ないんじゃないかな
Python 信者の半分は NumPy 信者で、その人たちは Ruby とか最初から眼中になくて
比較相手は Python vs R だと思う
844:デフォルトの名無しさん
12/02/12 10:02:17.67
よく知らんけどScipyやMatplotlib見たかんじでは、RってよりMatlabじゃね
845:デフォルトの名無しさん
12/02/12 10:09:08.63
>>844
金持ちだな
846:デフォルトの名無しさん
12/02/12 10:35:49.63
>>843
Python信者じゃないけど、俺がPython使うのを
選んだ理由と全く同じだわ
847:デフォルトの名無しさん
12/02/12 10:59:41.87
だってRって関数はいっぱいあるけどプログラミング自体は不便なんだもん
848:デフォルトの名無しさん
12/02/12 10:59:48.20
>>825
そんな暗号の様なコードは読み手に不要な知識を要求するので可読性が低い
大規模開発ではこの程度のコード量の増加は誤差の範囲
def f(x, y)
if !x.kind_of?(Integer) then
raise TypeError
end
if !y.kind_of?(Integer) then
raise TypeError
end
z = x + y
if !z.kind_of?(Integer) then
raise TypeError
end
return z
end
def g(x)
if !(-1 < x && x < 1) then
raise RuntimeError
end
print x
end
849:デフォルトの名無しさん
12/02/12 11:00:34.09
>>833
PowerShell
function f ( [int]$x, [int]$y ) {
$x + $y
}
function g {
param ( [ValidateRange(-1,1)]$x )
$x
}
850:デフォルトの名無しさん
12/02/12 11:01:51.99
カスrubyの言い訳が酷い
851:デフォルトの名無しさん
12/02/12 11:25:09.46
>>831
Pythonてそういう原理主義を否定してlenとかjoinとかああいう仕様にしたんじゃなかったっけ？
852:デフォルトの名無しさん
12/02/12 11:26:00.51
>>843,846
数値計算系はrubyは眼中に入らないほどの差がある・・・と（メモメモ
853:デフォルトの名無しさん
12/02/12 11:28:10.78
>>852
お前Rubyとの比較じゃないんじゃないかってところは読めないの？
バカなの？
854:デフォルトの名無しさん
12/02/12 11:32:22.36
>>853
いや、>>382も読んでたんで・・・
855:デフォルトの名無しさん
12/02/12 11:45:27.02
PHPとJavascriptとRubyはこの世から消えて欲しいわ
856:デフォルトの名無しさん
12/02/12 12:00:28.13
バイオインフォマティクスだと Perl > Python > Ruby かな。
857:デフォルトの名無しさん
12/02/12 12:06:16.55
DelphiはDelphi言語で実装されてるし、VC++もC++で実装されてる。GHCもHaslellで実装されてるし、pypyもpythonで実装されてる。
rubyにはrubyで実装されたruby処理系って無いの？
858:デフォルトの名無しさん
12/02/12 13:08:52.80
Rubyデバッガ
859:デフォルトの名無しさん
12/02/12 15:03:12.53
>>857
rubinius
860:Vintevecom(Yokohama)＝娵十＝TEN10(teto)
12/02/12 21:29:02.15
嘩喃人が奪い、中国に送った警察と自衛隊の銃は アジア大陸の七百万人の命を奪った。嘩喃人の立て籠りの２年間に何人が犠牲になったかアジアに確認を。
嘩喃人の河馬兄弟が諦めず、止めない。
人質を捕り、立て籠りを続けながらハッキングをしつこく続けている。
皆、大正生まれの戦犯。原爆投下と枯葉剤を作った人間だ。
今も犠牲者が増えるばかりの 2-Hndred Yars' Wrの最中である事を日本人だけが知らない。
861:デフォルトの名無しさん
12/02/12 22:54:32.85
平和なのもいいけど、退屈だなぁ、、、
862:デフォルトの名無しさん
12/02/13 07:13:18.93
>>843 の改変版
僕 Ruby 信者
ここは LL スレだからしかたないかもだけど
Ruby vs Python っていう比較で Ruby を選んだ人は少ないんじゃないかな
Ruby 信者の半分は Rails 信者で、その人たちは Python とか最初から眼中になくて
比較相手は Ruby vs PHP だと思う
863:デフォルトの名無しさん
12/02/13 07:29:39.88
pgr説
864:デフォルトの名無しさん
12/02/13 08:04:27.55
RubyはPHP並にうんこ説
865:デフォルトの名無しさん
12/02/13 09:03:39.33
>>862
最後の行はRails vs ～とすべきじゃね？
866:デフォルトの名無しさん
12/02/13 09:23:00.91
>>865
オリジナルの>>843が Python vs R だったから、それにあわせた
867:デフォルトの名無しさん
12/02/13 09:43:41.12
|;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ノ|
|丶､ ;;; __;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;_,,: ィ";;_|
ﾄ､;;;;;;;;;;;;;;;｀ ` '' ー -- ‐ '' ";;;;;;;;;,:ィ;:;!
,';:｀`' ‐ｮ ､ ,_ ;;;;;;;;;;;;;;;;;;;;;;;;;;; , - '"l;:;:;:;:l だまりゃ！そのほう麿をなんと心得る！
l;:;:;:;:;:;:;ﾐ ｀ ` '' ｰ -‐ '" ,ﾘ;:;:;:l
l;:;:;:;:;:;:;:ゝ く三) (三ｼ ｀ヾ;:t、 恐れ多くも帝より三位の位を賜わり
fﾐ{;:;:;:;:f'´ , -－-_,, _,ｨ ､_,,ｨ,.-－､ };f }
l ﾄl;:;:;:;:l ､,ィ或tｭ､ﾞ:ミ {,'ィt或ｱﾁ l:l,/ 中納言まで勤めた麿の言うことを聞かなくば
ﾞi,tヾ:;:;:! ｀ヽ 二ノ ﾄ ` ‐''"´ l:l:f
ヽ`ｰ};:l ,r'､ ヽ ﾘ_） どのようなことになるのか分かっておるのか！
｀"^l:l ,/ﾞｰ､ ,r'ヽ l
ﾞi ,ノ `'" 丶. ,' 今一度しか述べぬ！心して聞くがよい！
ﾞl､ ′ ,, ｨrｪェzｭ､,_ 〉 } /
',ヽ ヘヾ'zｪｪｪッ',ｼ' //ヽ
} 丶、 ` ｰ--‐ '"'´,/ノ:.:.:ヽ
/l 丶、 ,.ｲ:.:.:.:.:.:.:.:丶､、
,r'"^l ! ` ー‐;オ´:.:.:.:.:.:.:.:.:.,ノ ,}、
,. -ｧ＝く（:.:.:.l l ／/:.:.:.:.:.:., - '" ,／ ヽ、
何語で話すかにこだわっているうちは六流。
何を話すかにこだわって五流。
何を為すかに思い至ってようやく四流。
思うだけでなく、為せたならば、三流。
為したことを他人に評価されてやっと二流じゃ。
為したことを後世の人間に評価されて初めて一流となる。
主らはいつになったら六流から抜け出すことができるのじゃ。
868:デフォルトの名無しさん
12/02/13 09:47:11.46
>>866
ありゃ、ほんとだ
脳内でNumPy vsに変換されてた
869:デフォルトの名無しさん
12/02/13 09:59:27.07
>>867
麿もたまにはいいことを言うw
870:デフォルトの名無しさん
12/02/13 16:59:19.41
まあRubyのコードは6流だったね
871:デフォルトの名無しさん
12/02/13 19:21:25.79
>>867
おまけ。
下を向いて生きていれば六流。
下を向かずに生きて五流。
自分に目を向けて四流半。
上を向いて生きて三流半。
他人がどうのこうのではないわ！
まず、主自身に目を向けい！
872:デフォルトの名無しさん
12/02/13 20:59:31.21
目は口ほどに物を言う、ってことは目も口も六流
873:デフォルトの名無しさん
12/02/13 21:14:58.21
The eyes are the window of the soul. ・・・「目は心の窓
874:デフォルトの名無しさん
12/02/14 05:58:08.31
Why I left Perl
URLﾘﾝｸ(www.leancrew.com)
875:デフォルトの名無しさん
12/02/14 06:04:08.82
いちいち言い訳せんで
勝手に去れよ
876:デフォルトの名無しさん
12/02/14 06:08:46.94
perlに嫌気が差した人は次の言語としてrubyはperl臭いから選ばないと
877:デフォルトの名無しさん
12/02/14 07:33:39.19
>>876
同意
878:デフォルトの名無しさん
12/02/14 11:56:29.41
で お前らちゃんとメシくえてんの？
879:デフォルトの名無しさん
12/02/14 11:59:58.98
Rubyでは食えてない
Pythonでは食えてる
880:デフォルトの名無しさん
12/02/14 12:12:19.93
咥えるって・・・
キャー///エッチー
881:デフォルトの名無しさん
12/02/14 13:04:44.28
くわ・える〔くはへる〕【×銜える／×啣える／×咥える】
［動ア下一］［文］くは・ふ［ハ下二］
１ 口に軽く挟んで支える。「楊枝(ようじ)を―・える」「物欲しそうに指を―・えている」
２ 引き連れる。伴う。
882:デフォルトの名無しさん
12/02/15 08:15:29.00
>>862
Zopeもあったのに、最初から眼中にすら置いてもらえない Python カワイソスwww
883:デフォルトの名無しさん
12/02/15 19:23:46.58
クソコードの後だから煽りも虚しいな...
884:デフォルトの名無しさん
12/02/16 11:28:52.77
amazon
mixi
モバゲー
にちゃんねる
perlってこのぐらいか？
もう役目を終えつつあるな
885:デフォルトの名無しさん
12/02/16 12:53:58.98
満を持していよいよ、Perl6 の出番か
886:デフォルトの名無しさん
12/02/16 13:58:01.59
pythonもperlも仕事増やしたいから互換性なくしたんだろｗｗｗｗｗｗｗｗｗｗｗｗ
賢いなｗｗｗｗｗｗｗｗｗｗ
htmlも大幅に増やしたしなｗｗｗｗｗｗｗｗｗ
887:デフォルトの名無しさん
12/02/16 14:27:25.82
html5は増えたのもあるけど、減ったのもある。
タグ付けとデザインが完全に分離したから、ある意味すっきりしたともいえる。
888:デフォルトの名無しさん
12/02/16 16:48:40.99
Perl5 はコンテキスト依存で 返り値が変わるのが
いまいち、ちゃんと把握してない
あと、リファレンスとかややこしい
Perl6にいたっては到底覚えられそうにもない(覚える気は無いけど)
大幅に増えた演算子をしっかり理解してないと
ソースを読むのもままならない
よくは知らんがAPLやJみたいな暗号言語に近づいた気がする
わかってる人にはコンパクトにコードがかけて効率がいいのかもしれないが
889:デフォルトの名無しさん
12/02/16 18:41:13.11
結局、PHP最強ということか。
マゾっ毛でも無い限りPHPにしとけ。
890:デフォルトの名無しさん
12/02/16 20:30:34.01
>>887
マークアップとスタイルの分離はXHTMLどころかHTML4の頃から意識されてたでしょ。
891:デフォルトの名無しさん
12/02/16 22:08:12.90
>>890
でも、html4はfontタグでフォントや色を指定したり、tableタグのwidthでボーダーの幅を指定したりとかできたよね。
html5では、タグでこれらの指定はできなくて、デザイン要素は全てCSSで指定するようになったから、分離が徹底されてるよ。
892:デフォルトの名無しさん
12/02/17 06:54:13.30
まあ、Perl5のコンテキストって、現状ほとんど使われて無くて、配列のサイズを取得する時ぐらいしか意識する必要ないけどね。
リファレンスはCのポインタが理解できる程度の能力があれば動って事内。
Perl6は型指定可能なスクリプト言語というのが非常に魅力的。
893:デフォルトの名無しさん
12/02/17 08:25:34.11
>>891
HTML5 よりも HTML4 strict の方が徹底されています
894:デフォルトの名無しさん
12/02/17 09:36:36.44
いーや、html5の方が徹底されてるよ。
895:ぱーる列伝
12/02/17 12:56:31.21
LLの連中は人脈つくりに必死に献本送ってますね
トミタさん
トミタ「うひょおおおおおおおおおおおｗｗｗｗｗｗｗｗｗｗｗｗ人脈つくり楽すぎｗｗｗｗｗｗｗｗ
適当に本書いて、上層部Perl使いや、LL企業関係者におくりまくろうぜｗｗｗｗｗｗｗｗｗ」
ってクールなツラして心の中で思ってるからしょうがねーよな
必死におこぼれにあやかろうと色々なやつが、同じLL使いを褒めあってる
ハテブとかなんかで
「尊敬するPerl使いリスト」みたいな
まじおもしれーわ
生き残りかけてる
896:デフォルトの名無しさん
12/02/17 13:06:38.83
忍者か？
897:デフォルトの名無しさん
12/02/18 09:49:37.64
>>848
>そんな暗号の様なコードは読み手に不要な知識を要求するので可読性が低い
言語仕様に型検査や検証機能が含まれていれば、それを「暗号」とは言わないし、
逆にユーザコードで表現(代用)しなければならないRubyよりも優れていると考える
>大規模開発ではこの程度のコード量の増加は誤差の範囲
開発規模とは無関係に、本質の実装コードが検査/検証コードに埋もれる点で、可読性に問題がある
たとえばこのお題であれば、メソッド f の(本質のコードとは) z = x + y であり、
同様にメソッド g であれば print x だけであるけれど、それが一目で認識しずらくなっている
自分なら>>825のお題について、(後置の)unless修飾子と(メリハリを入れる)空行を使って、
以下のように書く
(続く)
898:デフォルトの名無しさん
12/02/18 09:50:19.16
(>>897の続き)
def f(x, y)
raise TypeError unless x.kind_of?(Integer)
raise TypeError unless y.kind_of?(Integer)
z = x + y
raise TypeError unless z.kind_of?(Integer)
z
end
def g(x)
raise RuntimeError unless -1 < x && x < 1
print x
nil
end
899:デフォルトの名無しさん
12/02/18 12:16:14.51
There's more than one way to do it
900:デフォルトの名無しさん
12/02/18 12:42:03.95
其れは方法が多い
901:デフォルトの名無しさん
12/02/18 12:43:44.32
Here is the battle stage.
Let's fight!
902:デフォルトの名無しさん
12/02/18 14:00:14.38
>>900
903:デフォルトの名無しさん
12/02/18 14:35:27.58
theじゃなくてaだろ
904:デフォルトの名無しさん
12/02/18 14:56:45.22
Pythonは見やすさ重視してるかなと思うけど、RubyとPerlは大差ない。
905:デフォルトの名無しさん
12/02/18 17:20:21.02
>>897
Pythonも別に型検査などが言語機能としてあるわけではなく
単にデコレータを使えばそういうことに「も」書く側で対応できるってだけじゃん
そういうデコレータの汎用性はいいと思うけど、直接実装するのと比べるとやっぱりね
どこまでをどの程度の抽象度で表現できるようにするかってのは、難しいけども
906:デフォルトの名無しさん
12/02/18 17:22:36.12
何この低レベルな争い、、、
907:デフォルトの名無しさん
12/02/18 17:36:17.90
javaのクラスライブラリが使えるだろうjruby一択だろjk
pythonなんて、vbみたいに文法がシンプルな割には、
classに毎度毎度、selfと書かなければならないperl臭さがあってダメポ
実際問題、ハッカーの書いたスクリプト言語に、どれほどの信頼性があるのよ？って怖さがある
シンプルな言語でなければ、言語開発者たちが解析木なり構文木なり、
明文化されてないのを良いことに、バグ放ったらかしてそう
だから使うなら、シンプルなscheme系統が良いけれども
clojure/clojure scriptなんかは開発陣がなんかキモい
そんな理由でjavascriptとluaが大勝利
908:デフォルトの名無しさん
12/02/18 17:42:15.36
変な理屈だなあ
909:897
12/02/18 18:15:13.12
>>905
失礼、説明が足りなかった
自分がうらやましかったのは、f(x:int, y:int) -> int という型式風の関数アノテーション構文
で、それをデコレータと組み合わせると型検査/検証を簡潔に書けてイイ！と
（ただし、デコレータは一種のマクロだから「Rubyとは」相性が悪いように思う）
910:デフォルトの名無しさん
12/02/18 18:20:13.58
rhinoが流行らなかったのは、javaのクラスライブラリとjsの相性が悪すぎたせい
rubyの方がpythonよりも言語の機能が豊富だしOOPとしては優れているのは誰の目にも一目瞭然
perlはもう…（笑）これから、4、5年ぐらいはjsが、かつてのperlと同じポストに着く。
廃れるときも、perlと同じ扱い。
javaは文法というか、色々と冗長すぎるので、
kotlinなりceylonなりポストjavaにjvmのメインストリームを奪われる。というか奪われろ。
関数型は大手ITの社内アプリなんかで徐々に使われだし、
ある程度の方法論とノウハウが蓄積後に業務アプリの開発で主流になる。
911:897
12/02/18 18:35:54.36
>>907
全体としてはいくつか異論があるけれど、
>pythonなんて、vbみたいに文法がシンプルな割には、
>classに毎度毎度、selfと書かなければならないperl臭さがあってダメポ
ここだけは同意
912:デフォルトの名無しさん
12/02/18 19:03:47.00
>>911
selfは慣れる。railsずっとやってたおれが保証する。よく忘れるけど。
それより、Pythonは親クラスのメソッド呼び出しがださすぎる。
super(ClassName, self).method() だっけ？最初見たときバカかと思った。
で、そんなはずはないと思ってもう一回みたら、やっぱりバカばかしかった。
はっきりいってPythonのsuperはPHP以下。Pythonでオブジェクト指向したくなくなる。
あとDjangoがいつまでたっても3に対応しない。Railsは早々に1.9に対応済というのに。クソったれ。
913:デフォルトの名無しさん
12/02/18 19:08:24.43
Perl は5.8辺りで上手く枯れて来たなーと思ったところに色々突っ込んじゃった印象
まあ路線的には専門外だったWebから脱却して
ポストawkというかシェルのお供みたいな位置で落ち着きそうだなと思う
914:897
12/02/18 19:10:31.61
(>>898の続きになる)
>>825はお題であるから>>898のコードが適切だと思うけど、
実際の開発で型検査/検証が必要であれば(>>716で簡単に紹介した)表明メソッドを使う
require 'tmdoc/tmstd'
ASSERT = TmStd::Assertion
def f(x, y)
ASSERT.kind_of x, Integer
ASSERT.kind_of y, Integer
z = x + y
ASSERT.kind_of z, Integer
end
def g(x)
ASSERT.assert -1 < x && x < 1
print x
nil
end
メソッド Assertion.kind_of(およびassert)のコード定義については、以下を参照
URLﾘﾝｸ(www.h6.dion.ne.jp)
(続く)
915:デフォルトの名無しさん
12/02/18 19:11:56.46
>>912
まじPython2のsuperはアホ全開だよな
Python3だとsuper().method()だからマシだけど
916:デフォルトの名無しさん
12/02/18 19:12:20.27
>>912
Pythonは多重継承あるから、勝手に継承元決められるより
親クラス明記のが楽かも…まあ、それでも色々くっ付き過ぎだけどw
917:897
12/02/18 19:14:18.80
(>>913の続き)
実行結果は以下のようになる(等幅フォントを使わないとボックスは奇麗に表示されない)
irb(main):006:0> f("Hoge", 1)
+=== ASSERTION FAIL!! : A is a kind of E. ====
|[EXPECTED(E) TYPE]
| Integer
|-----------------------------------------------------
|[ACTUAL(A) TYPE]
| String
|[ACTUAL(A) VALUE]
| Hoge
+=====================================================
TmStd::Exception::AssertionFail: TmStd::Exception::AssertionFail
from /opt/local/lib/ruby/site_ruby/1.8/tmdoc/tmstd/assertion.rb:55:in `kind_of'
from (irb):4:in `f'
from (irb):6
from :0
918:デフォルトの名無しさん
12/02/18 19:19:45.30
>>916
> Pythonは多重継承あるから、勝手に継承元決められるより
> 親クラス明記のが楽かも
ダウト
Python2でのsuperは親クラスじゃなくて自クラスを指定する
信者乙
＃いやこの程度を間違えるなら信者ではないかも？
919:デフォルトの名無しさん
12/02/18 19:22:06.73
>>916
親クラスを指定するんじゃないんだよ。それなら百歩譲って理解できる
そうじゃなくて自身のクラスを書かなきゃダメなわけ。例えばこんな感じで
class C(B):
def meth(self, arg):
super(C, self).meth(arg)
全く意味不明だろ？w
Pythonユーザの俺でも擁護できんわwww
(なお、Pythonのメソッド呼び出し obj.meth() は C.meth(obj) と等しいので
親クラスを選んで呼ぶのは普通に出来る）
920:デフォルトの名無しさん
12/02/18 19:31:45.45
>>918-919
Ω＜ナ、ナンダッテー
いや普段使わない言語に俄か知識でテケトーな事言ってスマンカッタ
921:デフォルトの名無しさん
12/02/18 19:36:15.72
python使っててそういうコードに出くわした記憶がない
922:デフォルトの名無しさん
12/02/18 19:37:10.33
>>912
>PythonのsuperはPHP以下
そんなこというと、Python信者が暴れるだろうが―！
URLﾘﾝｸ(twitter.com)
> Pythonだと、プログラムを綺麗にしようとするモチベーションが働くけど、
> perlやphpではそういったモチベーションが働きにくくてやっつけコードに
> なるのは、俺の個人的な問題なのか、ある程度言語自体が抱えている問題なのか？
URLﾘﾝｸ(twitter.com)
> php使うとcometとかWebSocketとか対応が難しいし、HandlerSocketの性能も引き出せないし、
> Fluentのphpクライアントも他の言語で普通にできているバッファリングが普通には出来なくて
> 苦労してるらしいし、
923:デフォルトの名無しさん
12/02/18 19:38:52.74
URLﾘﾝｸ(twitter.com)
> 「新しい技術に挑戦する」ことを奨励する企業がphpばかり使ってるのは問題だよね。
Python信者の発言こそ問題だけどな。
924:デフォルトの名無しさん
12/02/18 19:47:15.28
大昔にもツイッターのコピペばかりしてる奴がいたけど復活したのか
925:デフォルトの名無しさん
12/02/18 20:56:41.67
>>915はアンチPythonのふりをしたPython信者
自演キモ
926:デフォルトの名無しさん
12/02/18 21:30:44.44
>>909
> （ただし、デコレータは一種のマクロだから「Rubyとは」相性が悪いように思う）
デコレータはただの高階関数（に対する構文糖）
Rubyと相性が悪いとすれば、それは高階関数と相性悪いってこと
927:デフォルトの名無しさん
12/02/18 22:59:25.08
>>905
もっともなご意見有り難う。そんな事言いだしたら、PerlだってMooseで型制約出来るもんな。切りがない。
928:デフォルトの名無しさん
12/02/19 00:18:28.13
URLﾘﾝｸ(twitter.com)
> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
> 察してください。
ワラタｗ
Python信者が言い訳しとるｗｗ
929:Python信者
12/02/19 00:49:15.04
>>918
馬鹿は黙ってろ
>>912
どうしてもPython2でその書き方が嫌なら
super(ClassName, self).method()
の代わりに
SuperClassName.method()
でもいい
さらに
どうせインスタンス作った後はsuper変えることなんてなさそうだから
__init__の中で
__super=super(ClassName, self)
とした上で
__super.method()
って書いても良い
何でobjectクラスの中でそれが定義されてないのかって突っ込むなら
Railsのまねで
object.__super=
930:デフォルトの名無しさん
12/02/19 08:01:58.01
>>929
objectに属性追加出来ないだろ
本当にPython信者か？
931:デフォルトの名無しさん
12/02/19 08:15:29.58
>>929
>どうしてもPython2でその書き方が嫌なら
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
>でもいい
ださいことには変わりないけどな
>さらに
>どうせインスタンス作った後はsuper変えることなんてなさそうだから
>__init__の中で
>__super=super(ClassName, self)
>とした上で
>__super.method()
>って書いても良い
素人考えだな
それは継承を2段階行ったら破綻するやり方
932:デフォルトの名無しさん
12/02/19 08:29:06.48
Pythonはこんなにダサいのに
いざコードを書かせるとRubyが圧倒的にダサいのは何故だろう？
933:デフォルトの名無しさん
12/02/19 08:35:15.15
>>932
信者だから
934:デフォルトの名無しさん
12/02/19 09:07:08.15
>>932
まったくの主観で笑えるｗ
Python信者がんばれ！
935:デフォルトの名無しさん
12/02/19 09:11:41.50
>>928
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
disってるという自覚はあるのね
信者って、そういう自覚がないままに行動してると思ってた。
>>929
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
SuperClassName.method(self) の間違いだろ
信者がそんなミスするなよな
936:デフォルトの名無しさん
12/02/19 09:29:05.87
>>934
Ruby信者には>>898>>914がダサくないの？
937:デフォルトの名無しさん
12/02/19 09:34:49.37
>SuperClassName.method(self) の間違いだろ
>信者がそんなミスするなよな
それはもちろん気付いてたが
単に()をmethodを代表するものとして付けただけだから
938:デフォルトの名無しさん
12/02/19 10:49:38.33
>>937
苦しーｗ
そんな小さなミスすら、認めようとしないのか
こんな便所の落書きですら自分の体面を保とうとしているとは恐れ入った
939:デフォルトの名無しさん
12/02/19 10:50:09.44
>>926
もしもPythonが高階関数との相性が良いのなら、
高階関数の合成演算(の構文糖)であるメソッドチェーンを
何の不自由も無く使えているはず
でも、現実にはPythonでのメソッドチェーンは使い物にならないから
(あるいは用途が極めて限定されてしまうから)、
「Pythonは高階関数との相性が悪い」とも言えてしまう
だから、>>909では、デコレータがRubyと相性が良くない理由を、
「デコレータが(構文糖である)マクロであるため」と書いている
分かるかな？
940:デフォルトの名無しさん
12/02/19 11:33:07.96
>>939
その主張は「Rubyが高階関数と相性が悪い」の反論になってない
あとデコレータはLipsマクロほど強力じゃない。所詮はただの高階関数
941:デフォルトの名無しさん
12/02/19 11:35:26.31
＞＞936
Rubyもださいね。Pythonのsuperと同じくらいださい。
942:デフォルトの名無しさん
12/02/19 11:38:29.73
>>940
反論になっていないのなら、その理由をkwsk
理由なき主張は、単なる主観だ
943:デフォルトの名無しさん
12/02/19 11:39:59.95
>>942
なんで高階関数に過ぎないデコレータがRubyと相性が悪いの？
もう何度も繰り返してるけどデコレータは高階関数だよ？
「マクロだから」的な反論は間違いだからね
944:デフォルトの名無しさん
12/02/19 11:47:42.48
間違っているのはあなたです。
デコレータのメカニズムは高階関数ですけど、@ほげほげ、という記法は構文糖です。
この構文糖があるからこその「デコレータ」であって、この構文糖がなければ、
デコレータでもなんでもないただの高階関数です。
945:デフォルトの名無しさん
12/02/19 11:49:43.28
お前ん中ではな
946:デフォルトの名無しさん
12/02/19 11:50:08.52
>>944
じゃあ「ただの高階関数」なら使えるってことだよね？
だったら高階関数を使って>>914みたいなダサいコードを
もっと洗練させてよ
直視に耐えないレベルでダサいから
947:デフォルトの名無しさん
12/02/19 11:52:07.09
自分が理解出来ない ＝ ダサい
948:デフォルトの名無しさん
12/02/19 11:57:15.37
>>943
単なる高階関数に過ぎないデコレータ的な機能は、
(Pythonと違って)高階関数との相性が良いRubyであれば
ユーザコードで書ける
(たとえそれが>>898>>914のようにダサいとしても....)
でも、(構文糖である)デコレータ構文そのものの導入は、
ただでさえ複雑なRubyの構文を一層複雑にさせるから、
採用される見込みはないだろうな、という話
関数アノテーションについては、(たとえ構文の追加が必要であっても)、
ぜひとも導入を検討してもらいたいと個人的には思っているけどね
949:デフォルトの名無しさん
12/02/19 11:58:20.06
>>944
Pythonを知らなくてデコレータをマクロだと思ってたんだろ？
指摘されてから「高階関数だって知ってたし」とか笑えるw
じゃあもう一回聞くけど、何故Rubyとデコレータの相性が悪いんだ？
まさか「構文糖だから」か？
950:デフォルトの名無しさん
12/02/19 11:58:53.21
まあ、そもそものRubyの構文がわるいんだろうな。
行き当たりばったりで作ったから、
新しい機能を入れる余地がない。
あー、また互換性切り捨てか。
951:デフォルトの名無しさん
12/02/19 12:02:22.50
>>949
>>948を嫁
952:デフォルトの名無しさん
12/02/19 12:03:36.94
>>950
>行き当たりばったりで作ったから、
そのとおり、Pythonの関数型プログラミング機能と同様に、
行き当たりばったりだね
953:デフォルトの名無しさん
12/02/19 12:08:54.56
>>950
> 行き当たりばったり
> 互換性切り捨て
新旧スタイルクラスに3.0と、Pythonも大概だと思うが…
954:デフォルトの名無しさん
12/02/19 12:33:10.84
950は、よりよい言語にするためだったら互換性は切り捨ててもいいという、
最近のLL系言語に蔓延している風潮それ自体を批判しているんだよ
冒頭のRubyは飾りです、デコレータだけに
955:デフォルトの名無しさん
12/02/19 12:34:34.04
>>928
>URLﾘﾝｸ(twitter.com)
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
>> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
>> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
>> 察してください。
さんざん他の悪口を言っておいて、謝りもせず、なにが「察してください」だよ。
自分を追いつめるためなら何を言ってもいいと思ってんのか？
Python信者クズだな。
956:デフォルトの名無しさん
12/02/19 12:35:22.33
pythonのデコレータ自体は高階関数だけど、
@なにがし、はデコレータで関数を置き換える別の機能だと思うけど、、、
957:デフォルトの名無しさん
12/02/19 12:42:37.21
>>955
このスレのPython信者と一緒だね
958:デフォルトの名無しさん
12/02/19 12:46:02.17
>>954
最後のオチ、ワロスw
959:デフォルトの名無しさん
12/02/19 12:47:35.87
>>956
シンタックスシュガーだね
960:デフォルトの名無しさん
12/02/19 13:16:12.46
デコレーションケーキ
961:デフォルトの名無しさん
12/02/19 14:07:40.29
構文論と意味論がごっちゃになるバカとか、このスレにふさわしい隔離対象じゃあないか
962:デフォルトの名無しさん
12/02/19 14:08:29.48
LL ではない重量級の言語は何メインで使ってる？
LL だけって人もいるかもしれないけど、大抵は重量級と LL の両方使うでしょ。
組み合わせに傾向が出たりしないかな？
自分は C と Python です。
963:デフォルトの名無しさん
12/02/19 14:21:02.32
>>961
暴れているガキのことか？
うーん、いくらここが隔離スレだとしても勘弁して欲しい
ガキのお守りは疲れるから
964:デフォルトの名無しさん
12/02/19 14:24:47.80
>>962
漏れは C と Ruby
ただしどちらの言語ともプラットフォームは UNIX(Mac or Linux) だけど
965:デフォルトの名無しさん
12/02/19 16:10:41.76
「LL ではない重量級の言語」ってのがよくわからんけど、
Rubyや、Perlっぽい言語以外、という分類なら、CとかHaskellとか。
Haskellは慣れからくる惰性で使ってるだけだから、OCamlないし
遅延評価が必要ならもっと別の何かでも構わないと思う。
966:デフォルトの名無しさん
12/02/19 18:11:06.40
>>948
仮に@なにがしの構文糖が使えないとしても、>>825のコードは殆ど冗長にならない
def f(x:int, y:int) -> int:
return x + y
f = typecheck(f)
def g(x):
print(x)
g = validate(x=lambda x: -1 < x < 1)(g)
高階関数と相性の良いRubyなら>>914はもっと簡潔に書けるでしょ
ASSERT.kind_of を毎回書くんじゃなくて別のメソッドに隠蔽すべき
967:デフォルトの名無しさん
12/02/19 20:45:16.47
Rubyのメソッドは一級市民じゃないので高階関数とは相性悪いです
デコレータをRubyでやるなら動的なメソッドの再定義になりますね
元のメソッドを別名にしてそれをラッピングしたメソッドを同名で再定義します
def foo(x,y) x+y end
type_assersion(:foo, Integer, Integer)
見たいなのは実現可能です
順序を逆にして
直後に定義されるメソッドに対するデコレータみたいなのも書けなくはありません
type_assersion(Integer, Integer)
def foo(x,y) x+y end
ググって見つけたところだと
type_assersion(Integer, Integer) do
def foo(x,y) x+y end
def bar(x,y) x-y end
def baz(x,y) x*y end
end
って感じのがありました、これはRubyっぽい気がします
わざわざ型をチェックしたりする必要性はよくわかりませんね
そんなのは仕様とテストに書いてあれば十分な気がするので
968:デフォルトの名無しさん
12/02/19 21:28:50.10
>>964
unix環境でcを使うなら当然ながらgdbは必須なので、
gdbの拡張用スクリプトに公式的に選ばれたpythonつかっといた方が
幸せになれるんじゃなイカ？
個人的な考えでは、gdbの拡張用スクリプトは、luaかguileにすべきだった。
インデントが構文の言語は、対話環境でイジるの面倒杉だし、OOPとしてのpythonは失敗策。
あれなら、まだperlを採用した方がマシ
s-expなんてemacsがあってはじめて幸せになれるようなもんで、
インタラクティブな操作に向くとは到底ながら思えないけれど、
デバッガにはgnu公式のスクリプトを採用した方が組織としての一貫性があった。
ソフトウェアに永遠の命をなどとスローガンを掲げているわりに連中は自らその道を外れた。
ここのところ話題に挙がらない後発のgroovyって流行ってんのかな？
mozillaのrustといい、perlのようなものから
rubyのようなものを生み出した功績は素晴らしいと思う
969:デフォルトの名無しさん
12/02/19 21:44:06.10
>>968
元UNIX系だがgdbなんてほとんど使ったことのないオレが通りますよ。
（カーネル空間なんでgdbはパニックダンプ解析でしか使えないし・・・。）
関わって多言語は、
C(コーディング)、Sparcアセンブラ（デバック時）、Forth(レビュー対象)。
今はPerl、PHP、Javascript、Java、ActionScript、VBA、SQL、色々やってますが、PythonとRubyは未経験でつ。
970:デフォルトの名無しさん
12/02/20 00:04:01.82
Klabっていつの間にかソーシャルゲーム屋になってたんだな。