12/02/11 01:53:56.00
>>618
俺の意見じゃなくて一般論の話をしてるんだけど
読みやすいとかは数値化しずらいだろうが
どう見ても大多数の意見がそうなってるだろ
620:デフォルトの名無しさん
12/02/11 01:57:16.98
>>605
Pythonは日本語のドキュメントあるよ。それも十分detailedなのが。
URLﾘﾝｸ(www.python.jp)
> but Python doesn't provide it.
なんていったら、翻訳してくれた人たちに失礼すぎる。
なんでそう思うに至ったのかの経緯に興味あるな
池沼かもな
621:デフォルトの名無しさん
12/02/11 01:57:19.38
>>576
３つに分けて返答するよ
[二分岐(>>555,558)]
・すでに指摘されているけど、Pythonのif式の構文は特異/異常なもの
自分の知る限り、<then> if <cond> else <false> という
構文を採用しているのはPythonだけ
・直感的に、Pythonの構文はフローチャートやPAD等の分岐図と一致しない
特にこのような分岐がネストする場合には、それが顕著になる
コード全体の構造を見れば、Pythonだけが異質なのは明白
[多分岐(>>561,562)]
・Pyhtonには多分岐式が存在しないため、ハッシュを用いた
「トリッキー」なコードを書かなければならない
・もちろんRubyでもハッシュによる同様なコードを書けるが、
・ハッシュを使わなければ書けないPythonと
・ハッシュを使っても使わなくても書けるRubyとの間には
表現力に雲泥の差があるのは明白
[局所宣言(>>565,566)]
・Ruby/ML/Haskellの間には
それぞれメソッドチェーン/高階関数/リスト内包表記という差異はあるが、
それ以外の全体的なコード構造に関しては類似性がある
・異質なコードはPythonだけであり、
これはPythonに局所宣言(ブロック/let式/where節)が存在しないことに起因する
これらから「Pythonは関数型プログラミングには適さない言語である」という
結論に至った
622:デフォルトの名無しさん
12/02/11 01:58:53.48
関数型プログラミングに適した言語なんて一般的には全然好まれてないじゃん
623:デフォルトの名無しさん
12/02/11 01:59:07.22
>>619
>どう見ても大多数の意見がそうなってるだろ
それが主観的ってことでしょ。
主観的でいいなら、「Pythonの内包表記よりRubyのメソッドチェーンの方がわかりやすい」と思う人は多数いるよ。
624:デフォルトの名無しさん
12/02/11 02:01:05.67
>>619
そ、そうか。カンファレンスでアンケートでも取ったのか？
625:デフォルトの名無しさん
12/02/11 02:01:23.67
>>623
だから何？pythonがrubyより読みやすいのは事実だろ。何を否定したいのか分からん
rubyがpythonより読みやすいのなら、なんで「関数型プログラミング」にも適したrubyがpythonに負けてるわけ？
626:621
12/02/11 02:04:00.13
>>621の[二分岐(>>555,558)]への補足として、
前スレでのPythonの異質さに関する解説をコピペする
>711 名前: 682 Mail: sage 投稿日: 2011/12/29(木) 15:05:28.17
>>>695のPythonコードが読みづらい原因はif演算子の構文にある
>条件判定が式である言語に限定して、それらの構文を比較してみる
>
>Ruby:
> if 条件式 then 式1 else 式2 end
>Smalltalk:
> 条件式 ifTrue: [ 式1 ] ifFalse: [ 式2 ]
>Lisp:
> ( if 条件式 式1 式2 )
>ML:
> if 条件式 then 式1 else 式2
>Haskell:
> if 条件式 then 式1 else 式2
>
>Python:
> 式1 if 条件式 else 式2
>
>普通の言語は「条件式 -> 式1 -> 式2」と左から右へ流れる(それが自然)
>それに対して「Pythonだけ」は「式1 <- 条件式 -> 式2」と
>左へ右へと行ったり来たりしないとコードが読めない
>
>プログラミング言語界の中で「Pythonだけ」が異端な存在で、可読性の悪い構文が採用されている
>これは明らかにPython開発陣の言語設計ミス、あるいは判断ミスだね
627:デフォルトの名無しさん
12/02/11 02:08:44.16
>>626
お前その711の言ってることに賛成なの？
異端という言葉を使って一生懸命印象誘導してるけど、アホにしか見えない
こいつが自然と言ってるのは、それがCに似てるからに過ぎない
式に条件が後続する書き方が明らかに好都合
628:デフォルトの名無しさん
12/02/11 02:16:01.85
>>627
＞式に条件が後続する書き方が明らかに好都合
個人的には理解不能
伝統的なif文（あるいはif式）に対して
どういう利点があるのかさっぱり分からん
629:デフォルトの名無しさん
12/02/11 02:20:38.02
まず一番左をみて条件式があるというのが気持ち悪い
hoge = 条件式～ って条件式が長かったら右辺値がどんな値になるのか分かんねえじゃん
結局先に後ろを見てそれで条件式を見直すことになるだろ
630:621
12/02/11 02:20:45.94
Pythonは英語風だから読みやすいという意見があるけど、本当だろうか？
日本語：もし C であれば T さもなければ F。
英語：If C then T, else F.
ルビー語：if C then T else F
バイソン語：T if C else F
631:デフォルトの名無しさん
12/02/11 02:27:29.52
if文を読むときに
ifが先頭・・・ああ、次の場合条件によって①か②のどちらかを実行しなさいってことね
ifが後ろ・・・ああ、①を実行するのね――っと思ったら例外ありかよ！
みたいな感じ、個人の感覚としては
632:621
12/02/11 02:28:04.76
>>627
「世界中の皆が使っているからPythonを使うべき」という主張は、
Python信者の理屈ではなかったのかな？
同じ理屈を当てはめると、条件式に関して異端なのはPythonのほうになるけど、
違うん？
633:デフォルトの名無しさん
12/02/11 02:30:34.29
>>632
意味不明。どの理屈がどうだって？
634:デフォルトの名無しさん
12/02/11 02:30:58.26
>>631
英語全く読めないでしょ？
635:デフォルトの名無しさん
12/02/11 02:36:43.79
>>634
ああ、結局分かりやすさではなく英語に慣れてるかどうかの問題？
636:デフォルトの名無しさん
12/02/11 02:37:37.60
>>630
英語：T if C. Otherwise, F.
python：T if C else F
637:デフォルトの名無しさん
12/02/11 03:15:57.25
Pythonを分かりやすいと感じる理由を自分の理屈で持って解釈して主張する人もいれば
単に俺は英語に慣れてるから英語に近いPythonは英語に慣れてる分わかりやすいんだと、
突き詰めればそういうことにしかならない人もいるらしい、と、そんな感触
638:621
12/02/11 03:38:05.29
>>631
Python信者の理屈とは「みんなが使っていれば、それは正しい」だろ
>>626のコピペを見れば、
みんなが採用しているのがif <cond> then <true> else <false> であり、
それは正しい
という帰結になるのは猿でも分かるよな？
639:621
12/02/11 03:40:46.63
>>636
>>630は二分岐に関する「Pythonは英語風」に対する疑問であったけれど、
>>636へのレスに代えて、今度は別の切り口で疑問を提起してみる
まず、英語風(=自然言語風)というよりも、これは
「数学における定義と似ている」と言い換えた方が適切だろう
たとえば、[多分岐(>>561,562)]を数式として記述すると以下のようになる
f(X) = T, if X is "Green"
T, if X is "Yellow"
F, otherwise
確かにこれは、Pythonの <true> if <cond> .... という構文と似ている
実際Haskell文化では、>>562(上段)よりも以下のような数式風のコードが好まれる
f x
| x == "Green" = true
| x == "Yellow" = true
| otherwise = false
では、自分はPythonに詳しくないので、>>562(下段)のコードを書き直してみてくれ
Pythonが英語風で関数型プログラミングにも適しているのなら可能なはず(他の人でもいい)
論よりコードだ
640:デフォルトの名無しさん
12/02/11 03:47:38.01
後置ifは、他言語にもあるから別に変でも何でもない。
lenの方がよっぽどきもい。
__len__とか勘弁して欲しい。
641:デフォルトの名無しさん
12/02/11 03:48:02.98
if <cond> then <true> else <false>
が判り易いなんて思い込みだろ
<true> if <cond> else <false>
の方がシンプルで良いじゃん
っていうか何で「ただの値を返すだけの記号」だと思えないんだろう
642:デフォルトの名無しさん
12/02/11 03:50:50.25
>>640
同意
Python 始めて間もないとき
"hoge".len() とか
"hoge".length() とか
期待した結果が得られないのでめっちゃ悩んだ
len("hoge") なんてインチキというか目から鱗というか
C やってたら当たり前なんだろうけど
Ruby しか知らない人には習得は厳しい言語かもしれないな
643:デフォルトの名無しさん
12/02/11 04:08:42.78
>>640
他言語にもあるのかよ。>>621に騙されちゃった
644:デフォルトの名無しさん
12/02/11 04:13:37.65
lenという関数もその名前も別に不満はないが
なぜ文字列やリストオブジェクトのメソッドが__len__なのかは確かに理解出来ない
結局は関数のlenしか使わない
645:621
12/02/11 04:21:48.61
>>640
>後置ifは、他言語にもあるから別に変でも何でもない。
それは話のすり替えだよ
後置if はRubyや他の言語にもあるけど、それらはすべて(式ではなく)文だ
分岐式としてのif構文が後置なのはPythonだけで、それは異端だというのが>>626のコピペ
>>__len__とか勘弁して欲しい。
だよな
__init__ とか勘弁して欲しい
646:デフォルトの名無しさん
12/02/11 04:25:14.17
Cやっててもきもいよ。
ほかは、メソッドになってるのになんでこれだけ関数なんだ。
どっちかに統一してほしい。
647:デフォルトの名無しさん
12/02/11 04:25:25.24
>>639
誰が、pythonが関数型プログラミングに適してるって？
なぜか、関数型プログラミングに適してるほうが勝利という前提で話を進めているけど
それは初めから詭弁だし、お前の文章自体が何かごちゃごちゃしてるのも、その特殊な脳内を表しているの？
よくpythonスレでもリスト内包にlambda式突っ込んでごちゃごちゃやってる人いるけど
無理せずに外に関数として定義してやれば何倍もスッキリするし、そうするべきだと俺は思ってるけど
lambda式自体は使うべきだけど無理して使う必要ない。読む方にも迷惑
648:621
12/02/11 04:26:04.90
>>641
シンプルで良いのなら、>>639で希望したように、
ぜひ極めてシンブルな多分岐処理に対する>>562(下段)のトリッキーなPythonコードを
シンプルで美しいコードに書き直してくれ
繰り返すけど、論よりコードだ
649:デフォルトの名無しさん
12/02/11 04:31:31.50
__init__や__main__は特殊な関数と明示してるから嫌いじゃない
__len__は別に特殊である必要がない
>>648
他のコード見ても何をやりたいのか分からん
650:621
12/02/11 04:36:57.63
>>647
>誰が、pythonが関数型プログラミングに適してるって？
>なぜか、関数型プログラミングに適してるほうが勝利という前提で話を進めているけど
それは「Pythonは関数型プログラミングに適していない」という意見への賛同として
解釈してよいのかな？
>よくpythonスレでもリスト内包にlambda式突っ込んでごちゃごちゃやってる人いるけど
>無理せずに外に関数として定義してやれば何倍もスッキリするし、
まったくそのとおりだと自分も思う
実際、>>566(上段)のHaskellコードは、リスト内包表記内にあるごちゃごちゃしたコードを
where節を使うことで無理にせずスッキリした読みやすいものになっている
>>565のRubyやMLは内包表記ではないけれど、それぞれブロックとlet式を使ってスッキリしている
それに比べて、>>566(下段)のPythonコードはなんともごちゃごちゃした汚いコードだよね
え、Pythonって外で関数定義しないとスッキリさせることができないの？
いったい何のためにラムダ式(無名関数)があるんだろう.....
651:デフォルトの名無しさん
12/02/11 04:39:30.69
>>650
お前がスッキリと言ってるものがどんな処理をしてるのか分からないから説明してくれよ
652:デフォルトの名無しさん
12/02/11 04:41:17.23
>>650
関数型プログラミングには適してないんじゃね。望まれてもいないし
653:621
12/02/11 04:56:47.53
>>648
>他のコード見ても何をやりたいのか分からん
まあ他の言語のコードが読めない、つまりPythonしか知らないのならしかたないなぁ....
というか、他の言語の経験があって、その上でPythonがイイ！と言えるヤシはいないの？
>>651
Python(>>566下段)
リスト内包表記内にごちゃごちゃしたコードを書かざるを得ない
Haskell(>>566上段)
リスト内包表記内のコードを(where節で)外に追い出しているからスッキリしている
654:デフォルトの名無しさん
12/02/11 04:58:15.29
>>653
お前もpythonのこと知らないって言ってんじゃん
実際明らかにそうだし
数学的にって
f(X) = T, if X is "Green"
T, if X is "Yellow"
F, otherwise
↓
def f(x):
return True if x=="Green" \
else True if x=="Yellow" \
else False
こうだろ。何をさせたいのかさっぱり分からん
655:デフォルトの名無しさん
12/02/11 04:59:50.43
>>645
まぁ、そういわれればpythonは異端かもなぁ。
if構文は改行しないとダメだし、演算子の方は後置を強制されるから統一感がないね。
ifをワンライナーで書けるか、演算子が前置できればいいのかも。
LLの中じゃ、pythonは嫌いじゃないけど、ところどころキモくてもどかしいところあるよ。
656:デフォルトの名無しさん
12/02/11 05:05:00.80
>>639
Prologだと、
f(X) :- 'Green'(X).
f(X) :- 'Yellow'(X).
これはこれで多大なコストが掛かっているけど。
657:621
12/02/11 05:06:52.02
>>652
了解した
もしそれがPython支持派の総意であるなら、これ以上はバトルスレで語る事柄ではないと思う
この話題は終わらせてもいいだろう
658:デフォルトの名無しさん
12/02/11 05:08:50.13
逃げんなよ。関数型プログラミングで言語の優劣が決まるのなら
関数型言語の今の惨状は無い
659:デフォルトの名無しさん
12/02/11 05:11:14.38
>>656 if ~ then ~ else ~ の場合はカットが必要なのでは？ f(X) :- 'Green'(X),!. f(X) :- 'Yellow'(X).
660:621
12/02/11 05:11:53.34
>>654
あ、スマン、>>653のカキコ内にあるアンカが間違っていた
訂正する
X: >>566
O: >>562
661:621
12/02/11 05:14:10.19
>>658
逃げる気はないよ
Python信者が関数型プログラミングの議論を続けたいなら、こちらも望むところだ
662:デフォルトの名無しさん
12/02/11 05:17:26.60
単純に学習コストだな。受け入れやすさ。
簡単に使えるようになって、やりたいことが出来るのならそれで問題ない
そうやって皆が使えば資料もライブラリも充実して、さらに学習コストが下がる
関数型プログラミング必須なんて有り得ないし
それで出来上がった「スッキリ」と言われるコードは意味不明だし
やはり一生普及しないだろうと実感した
663:デフォルトの名無しさん
12/02/11 05:34:35.58
>>648
Pythonが特別トリッキーだとは思わないな
いまどきのjavascriptっぽくて好感が持てる
664:656
12/02/11 05:35:19.42
>>659
すみません。間違えました。
f('Green').
f('Yellow').
ですね。カットを入れるかどうかは迷います。Xがどこかに行ってしまいました。
これが嫌なら、
f(X) :- 'Green'==X.
f(X) :- 'Yellow'==X.
かな。
665:621
12/02/11 05:38:05.42
>>654
その文末にある醜い￥記号は何？
Cのマクロ定義なら分かるけど、なんでそんな記号を使わないとならんのだろ
インデント強制のPythonなら、(Haskellのように)インデントで書けないの？
あと、そのコードは未完成
その関数定義をラムダ式にして>>562の(ハッシュを使った)トリッキーなコードを書き換えてほしい
666:デフォルトの名無しさん
12/02/11 05:43:26.06
javascriptで思い出したけど、
なにげに,CoffeeScriptがすごくよさそうだと個人的には思う。
667:621
12/02/11 05:43:37.11
>>663
トリッキーであることそのものは批判していないよ
最初に以下の>>621で書いたように
>・もちろんRubyでもハッシュによる同様なコードを書けるが、
> ・ハッシュを使わなければ書けないPythonと
> ・ハッシュを使っても使わなくても書けるRubyとの間には
> 表現力に雲泥の差があるのは明白
Pythonが(ハッシュを使った)トリッキーなコードでしか表現できないことを問題視している
668:デフォルトの名無しさん
12/02/11 05:49:36.48
(lambda x: x in ["Green", "Yellow"])で良いんじゃね
669:デフォルトの名無しさん
12/02/11 05:50:30.20
ああ、問題を解決できてもダメなのか、関数型プログラミング至上主義的には
670:デフォルトの名無しさん
12/02/11 05:55:27.43
関数型言語とか関係なくダメだと思うよ
というかPython的にすらダメじゃないの
671:デフォルトの名無しさん
12/02/11 05:56:56.45
なぜ？"Green"か"Yellow"なら真、それ以外なら偽じゃないの
672:デフォルトの名無しさん
12/02/11 06:06:43.50
トリッキーだと思わないと言っているのに
>トリッキーであることそのものは批判していないよ
とか論点逸らしひどす
673:デフォルトの名無しさん
12/02/11 06:08:18.97
最初から詭弁による話題誘導しかしてないよ。一番最初から
674:デフォルトの名無しさん
12/02/11 06:22:32.10
お前ら、Scala使えよ
実用的な関数型言語だ
RubyとかPythonとかどうでも良くなるよ。
675:デフォルトの名無しさん
12/02/11 06:25:34.79
ScalaはJava臭が残ってるから好きじゃない
676:デフォルトの名無しさん
12/02/11 06:29:27.42
RubyからScalaに乗り換えた15くらいの理由
URLﾘﾝｸ(wota.jp)
677:デフォルトの名無しさん
12/02/11 06:34:58.63
まずはスレタイに Scala 入れてからだな
678:デフォルトの名無しさん
12/02/11 06:40:43.46
Rubyはいらんだろ
679:621
12/02/11 06:46:38.64
>>673
詭弁であると思うのなら、その時点で(=一番最初に)指摘すればいい
たとえば>>539では、>>510の主張が仮定を元にした詭弁であると即座に反論している
議論が進行してしまってから「一番最初から」うんぬん言うのは、
バトルスレでは自ら敗北を宣言したに等しい
では、>>643を添削しておこう
X: 最初から詭弁による話題誘導しかしてないよ。一番最初から
O: もうこれ以上は技術的な議論しても勝てそうにないので、印象操作しかできません(涙声
680:621
12/02/11 06:55:09.24
>>672
>トリッキーだと思わないと言っているのに
あっそうか、Python(>>562下段)しか知らない蛙さんだったのね
ならばしかたないな....
Ruby(>>561上段)/ML(>>561下段)/Haskell(>>562上段)のコードが読める人なら、
単純にcase...という多分岐構文を使うだけなのに、
ハッシュを使わないと書けないなんてPythonとは変というか不自由な言語だなあって思うよ
681:デフォルトの名無しさん
12/02/11 07:05:58.33
ん？
異質＝トリッキー
だと思ってる馬鹿？
682:デフォルトの名無しさん
12/02/11 07:22:44.59
621は2chに長文書き込んでる暇あったら英語勉強したほうが良いよ？
683:デフォルトの名無しさん
12/02/11 07:26:19.43
キーワード引数をハッシュで代用してる
Ruby使いがハッシュをキモイって言ってもなぁ……
684:デフォルトの名無しさん
12/02/11 07:30:17.42
ハッシュってキーを間違えた時
エラー出る？
685:デフォルトの名無しさん
12/02/11 07:37:26.32
>>679
> 詭弁であると思うのなら、その時点で(=一番最初に)指摘すればいい
> たとえば>>539では、>>510の主張が仮定を元にした詭弁であると即座に反論している
>>504
>・RubyがあったからこそRailsが生まれた
>>510
>> RubyがなかったらPython Railsができていたと思うよ
>>539
> 革新的な発明/発見/発想に対して、後になってから
> 「あんなのは俺にだってできた」と語るのは三流の証(あかし)
>>510 を「あんなのは俺にだってできた」と語っていると考えたのは
馬鹿の証
ただ、証（あかし）ってかっこつけて書きたかったんでしょ。
バーカ
686:デフォルトの名無しさん
12/02/11 07:41:31.82
ならない
キーワード引数をハッシュで模倣するのは
間違った引数を書いてもエラーにならないという
明らかな欠点が存在する
687:デフォルトの名無しさん
12/02/11 07:46:02.36
>>665
ifが式のHaskell様の素晴らしいコード
s = "begin" ++ if True
then "foo"
else "bar"
++ "end"
答え：s = "beginfoo"
あれ？endは？
688:デフォルトの名無しさん
12/02/11 07:54:27.17
>>683
一応2.0では本物のキーワード引数が入るっぽいよ
689:デフォルトの名無しさん
12/02/11 07:56:04.39
とういかさ、なんでそういう基本的な機能を
最初に作らないの？
690:デフォルトの名無しさん
12/02/11 07:59:45.72
>>686
ハッシュで分岐を表現する>>562と違って
ハッシュでキーワード引数を表現するのは
本物のキーワード引数より機能的に劣るってことか
異質とかトリッキーなんて主観よりも明確だな
691:デフォルトの名無しさん
12/02/11 08:02:20.66
Pythonのインデント強制はなにか意味があるのかね？
インデント程度でコードが読みやすくなるわけ無いし。
強制されなくてもインデントするでしょ？
それよりか、スペース強制のほうがいいと思う。
たとえば × foo+bar、○ foo + bar こんな感じ。
英語文化的にこういう場合にはスペースを開けるのが普通。
そしてスペース強制と書いたけど、本当は、
「foo+bar」いう変数名として解釈される。
関数もオブジェクトという考えと同じように
記号もまた名前なんだよ。
692:621
12/02/11 08:03:50.40
>>683
トンチンカンな指摘だなあ
Rubyには(Pythonの)キーワード引数に相当する構文は無いよ
Pythonのディクショナリを展開して関数へ渡す方法に相当するのが、
Rubyのハッシュによる引数渡しになる
>>684
(Pythonの)ディクショナリってキーを間違えた時エラー出る？
>>686,690
上で書いたようにディクショナリに相当するのがハッシュであり、
Pythonのディクショナリ渡しで間違ったキーを書いてもエラーにはならないから、
これまたトンチンカンな指摘だ
ただし、Pythonのキーワード引数そのものはRubyには無い優れた特徴だと思う
693:デフォルトの名無しさん
12/02/11 08:13:35.20
Rubyではキーワード引数をハッシュで代用する話をしてるのに
何でPythonで辞書で渡す話にすり替えてるの？
Pythonにはキーワード引数があるんだから
キーワード引数を使いたい（引数を間違えたときにエラーにしたい）なら
辞書じゃなくてキーワード引数を使うよ
694:621
12/02/11 08:18:15.25
>>693
すり替えたつもりはないよ
>>692にはPythonのキーワード引数は(Rubyには無い)優れた特徴であると
書いてあるのに、読めなかったのかな？
695:デフォルトの名無しさん
12/02/11 09:51:05.87
引数の取り回しは、
オプション引数・デフォルト引数、キーワード引数、型チェック、バリデーション機能
くらいは言語仕様でどの言語も実装してほしいな
696:デフォルトの名無しさん
12/02/11 09:54:49.33
そうだね
ブロック引数もどの言語でも実装してほしいよね
697:621
12/02/11 10:08:24.71
そうだなw
でも、それを言い出すと
PHP: HTML内にコードを埋め込むのはLLならできて当然だよね
Javascript: 今の時代、デフォでWebブラウザ上でも動くのが常識だろ
などと言う輩が続出して、収拾がつかなくなると思われ
698:デフォルトの名無しさん
12/02/11 10:11:40.70
まあ引数の話だし
最低要件PowerShellレベルってことで
699:デフォルトの名無しさん
12/02/11 10:45:37.43
オプション引数（デフォルト引数）とカリー化の相性の悪さは異常
700:デフォルトの名無しさん
12/02/11 10:57:52.50
>>665
ys = (x for x in xs
if (lambda x :
True if x == "Green" else
True if x == "Yellow" else
False)(x))
701:デフォルトの名無しさん
12/02/11 12:05:42.87
実装してほしいとか言うなよ
それは日本語に翻訳してほしいって言うのと同じレベルの発想だ
702:デフォルトの名無しさん
12/02/11 12:33:06.02
Rubyは書き捨てスクリプト専用言語だから
キーワード引数なんて要らない
あれは大きいプログラム用の機能だからね
当然トイプログラム専用言語Haskellにも要らない
703:621
12/02/11 12:39:48.07
>>700
ありがとう
もしも今後関数型プログラミングの議論が再開してコードを引用する場合、
>>700のコードも忘れずに引用します
704:621
12/02/11 12:43:56.75
>>702
だよね
RedMineみたいなプロジェクト管理ツールなんてちっぽけな使い捨てスクリプトだし、
Railsみたいなフレームワークもオモチャみたいなもんだしね
.... .... .... これでいいのかなw
705:デフォルトの名無しさん
12/02/11 12:48:39.90
キーワード引数ってシェルコマンドから来た発想じゃねーの？
706:デフォルトの名無しさん
12/02/11 12:57:13.47
>>704
その辺はRuby本来の使い道を既に外れてると思われ
707:621
12/02/11 12:58:20.60
>>699
オプション引数・デフォルト引数・キーワード引数というのは、
それらを個々にひとまとめとした直積データ構造であると考えた方が自然な気がする
たとえばオプション引数は省略可能な要素から成るタプル型で、
キーワード引数はレコード型であると解釈する
708:デフォルトの名無しさん
12/02/11 13:01:24.42
Ruby本来の用途を外れた使い方された挙げ句
GCが遅いおそい言われてるのを見ると
ちょっと可哀想ではある
709:621
12/02/11 13:18:32.55
>>706
たとえ生まれが使い捨てプログラミング用途だとしても、
可能性があり実現に望ましい性質を持つ言語であるのなら、
どんな用途に使われようと周囲がとやかく言うべきではないと思う
>>706は、子供達を無理矢理自分の枠にはめようとする
逝き遅れたオールドミス数学教師(>>442)の発想だね
Rubyたん(>>437)は、
RailsでメタプログラミングをそしてRakeおよびRSpecで内部DSLという、
これまでにない新しい扉を開いた
まだまだ潜在的な可能性がRubyには残されている
今回議論になった「Rubyによる関数型プログラミング」もそんな可能性の一つ
まだまだ成長と進化を続けていくだろうと思う
710:デフォルトの名無しさん
12/02/11 13:39:24.44
>>709
別に使われること自体は構わないけど
それを基準にするのはおかしくね？ってことだよ
711:621
12/02/11 13:57:29.18
>>710
生まれが書き捨てスクリプト言語であることを基準にする
>>702の発想はおかしくね？ってことだよん
712:デフォルトの名無しさん
12/02/11 14:30:37.38
まぁ、勝手に使っておいて文句ばっかり言うのは
うんｋだな。
713:デフォルトの名無しさん
12/02/11 14:36:27.02
>>711
まあそこはね
無くてもやれるが、その内ほしいな
714:デフォルトの名無しさん
12/02/11 14:52:03.72
主要なものは既に存在する。
まだないのは、マイナーすぎて作れないもの。
マイノリティを肯定しないと作れない。
715:621
12/02/11 15:13:20.36
>>714
そのとおりだと思う
おそらく、それには変人の発想(>>575,578,596)が必要になる
簡単に言うと、周囲のマジョリティーと安易に同調しない強い意志/自我を持つこと
そしてRubyスレによれば、どうやらRubyにはそんな変人達を引きつける魔力があるらしいw
716:621
12/02/11 15:33:40.22
>>713
確かに>>695の中でRubyには欠けている
キーワード引数、型チェック、バリデーション機能は
(欲張りかもしれないが)Rubyにもほしいところだね
ただ、キーワード引数については、Ruby 1.9で順序付きハッシュが導入されたことだし、
Smalltalk(あるいはObjective-C)風のメッセージ式によるメソッド定義のほうが
(Pythonのキーワード引数よりも)可読性が高くて望ましいなぁ
たとえば、def put: str at: point; .... end みたいに
でも、Rubyの構文に大掛かりな変更が必要になるから、採用される見込みは無いだろうw
あと、型チェックとバリデーション機能についてはTestUnit風の
アサーションライブラリ関数で(暫定的に)対応できないかと開発を進めているところ
たとえばこんな感じ
def put_at str, point
ASSERT.kind_of str, String
ASSERT.tuple_of point, [Float, Float]
最終的には、この型アサーション(表明)を関数アノーテーション(注釈)と見なして、
ドキュメント内に型式(あるいは自然言語風の解説)を自動生成することも視野に入れている
717:デフォルトの名無しさん
12/02/11 15:52:16.64
お題って621がlambda式に条件分岐が必要なものを自分で考えたんだろうなあｗ
718:デフォルトの名無しさん
12/02/11 16:13:29.15
Ruby をシェルの変わりに使いたいな
シェルだと、以下のような記述をして実行したとき
rm -rf ${TEMP_DIR}/*.*
変数を定義しているソースの取り込み忘れや、
変数のスペルミスがあったときに悲惨な結果になるんだよな
てかやっちまったんだよ……orz
719:デフォルトの名無しさん
12/02/11 16:20:41.47
まあ型チェックもバリデーションも
Pythonならデコレータで簡単にできるんですがね
720:デフォルトの名無しさん
12/02/11 16:22:25.98
621は人の話を聞かず、正反対の意味に曲解して話を進めるのをやめた方がいい
721:621
12/02/11 16:55:30.71
>>717
そうだよ、今頃気が付いたのw
Ruby/ML/Haskellでは簡潔に書けるけどPythonではそうでないお題を選んでいる
つまり、Pythonは「どちらが関数型プログラミングに適しているか」という勝負に
負けるべくして負け、「不適格」という烙印を押されたことになる
>>720
前にも書いたけど(>>679)、もしも悪意のある曲解があるならその時点で強引にでも止めればいい
その判断が正当なものであれば、いくら強引でも止める行為を非難するヤシはいないはず
後になってから「xxすべき」を言い出すのは、敗者の泣き言(あるいは負け犬の遠吠え)だ
では、>>720を添削しておこう
X: 621は人の話を聞かず、正反対の意味に曲解して話を進めるのをやめた方がいい
O: 技術的な議論では自分の思い通りに話を進められないので、個人攻撃に移るよ
722:デフォルトの名無しさん
12/02/11 16:56:39.82
>>703
せっかくpythonがクールでないというお題を考えたのに残念だったね
723:デフォルトの名無しさん
12/02/11 16:57:07.50
>>721
>>700でちゃんと出来たじゃん。残念
724:デフォルトの名無しさん
12/02/11 16:58:07.24
>>721
そういう議論の進め方が下衆だって言ってるんだよ
725:デフォルトの名無しさん
12/02/11 16:58:29.46
荒らしに何を言っても無駄
726:デフォルトの名無しさん
12/02/11 17:21:47.15
まあバトロワスレなんて基本はこんなもんじゃね
727:デフォルトの名無しさん
12/02/11 17:43:01.03
QZはずっとここにいろ
ここQZ隔離スレにしてよ
728:621
12/02/11 17:47:14.12
>>722,723
３つあるお題の内、多分岐については>>700がコードを示してくれたので
>>621の「Pythonではハッシュを使わなければ書けない」という主張を取り下げる
ただし、もし可能であったなら>>700のコードは前スレで示すべきだった
前スレのPythonな人も難しいと言われるリスト内包表記を使いこなすだけの技量はあったけど、
>>562(下段)のようなハッシュを使うコードしか思いつけなかった
そして今レスでも誰も>>562に対してコードで反論できずにいて、
>>639,665と誘導することによってようやく>>700の「ちゃんとした」コードが完成した
これは、Pythonによる多分岐のコード化が
いかに難解なものであるかを示しているのではないのかな？
Rubyなら簡単に書ける初歩的なお題なんだよ
あと、>>621の残る２つのお題、二分岐と局所宣言に関するPythonへの問題指摘に対しては
明解な反論が無いまま、>>650の
> それは「Pythonは関数型プログラミングに適していない」という意見への賛同として
> 解釈してよいのかな？
という問いかけに対して>>652が
> 関数型プログラミングには適してないんじゃね。望まれてもいないし
と返答しているけど、別人さんなのかな？
それともPython支持派には意見の不統一があるのかな？
>>661で書いたように逃げる気は無いので、議論の続きを再開しても自分はかまわないよ
729:デフォルトの名無しさん
12/02/11 18:01:41.70
>>728
どこが難解なんだよｗ
お前がpythonのことを1ミリも知らなかっただけじゃねえか
もう黙れ。二度と再開するな
730:デフォルトの名無しさん
12/02/11 18:02:57.77
お題が悪い
pythonのlambda式が不便になることがあるのは事実だが、こういうパターンではない
おそらく不便という事実だけ聞いてこの問題を作ったんだろうけど的外れもいいところ
731:デフォルトの名無しさん
12/02/11 18:07:32.90
らむだこりゃ
732:デフォルトの名無しさん
12/02/11 18:09:49.97
／ ..::::::...ヾ,-┐:::::.. ヽ、
／:::::::: :::::::::::::::..ヽ|、::::::::... ヽ、
ラムだっちゃ♥ / :::::::: 、:::::::::::::::::...ヽ::::::::::::.. ヽ
/ ::::: 人、 | ヽ、_:::::::::::::: |:::::::::::::. |
,ｲ´ | :::ﾄ、 | ｀'-,r‐=,､ヽ、 ::: |:::::::::::::: |
rｖ' l´ ヽ、:.| ｒ-、 p ヽ ｀l ,ﾍ::::::::::::::::: |
| | | ヾヽ、 ﾊ ヾ_ﾉ .| |' .|:::::::::::::::::: |
''´￣￣｀ヽ、、_ | | | ヽ､l ゞ ー | レ'::::::::::::::::::: |
´￣ ｀ r-L l ', |｀ ､ ,' |:::::::::::::::::::::: |
_rヾﾆ ｀ヽ ', ヽ、 ｒ‐-ｧ /::|::::::::::::::::::::::::.. |
ヾゝｲ´ ,/ .', ヽ、ゝ' _,.-;ノ:: |:::::::::::: ::::.. |
::.. ﾄ ´ /.... 'ヽ,、＿ ＞r' ／:: /::::::::::::: ::: |
: 〉 .|:::::::::::...... ｀ー-‐'´,-/ /::::: / ｀ヽ、::: |
::.... .:::::::::::| |:::::::::::::::::,､-r―'''´￣ ,.-‐'´:::. ／ |:::::.... . |
:::::::::::::::::::::::::::::::::| ',:::::::::::::∧ヾ V／―／::::::::::: / |:::::::::::.......:::. |
:::::::::::::::::::::::::::::::::| ',:::::::::::ﾄ kl /三／:::::::::: ／ ,'::::::::::::::::::::::: |
:::::::::::::::::::::::::::::::::| ',:::::::::|ヾヾ|、 /::::::::: ,ｲ ,'::::::::::::::::::::::::: | |
:::::::::::::::::::::::::::::::::| ',／ヽ＿_ヾ､|:::::: ∧/ /:::::::::::::::::::::::::: |.|.|
::::::::::::::::::::::::::::::::::', ! / ヾ:: ∠__/ /:::::::::::::::::::::::::: | ||
733:621
12/02/11 18:37:08.10
>>729
いや、Pythonのことは部分的に知っているはずだよ
だって、Pythonの弱点を突けるコードを意図的に選んだのだからw
あと、>>658は「逃げんなよ」と言い、>>729は「二度と再開するな」と言う
同じ人ではないと思うので、別人さんでPython支持派内に意見の不統一があるのかな
いったいぜんたい、どっちにすればいいんだろう
関数型プログラミングへの適合性について議論を再開する or しない、
Python支持派内で意見を統一した上で、どちらにするのか返答を希望する
>>730
だから、もしもお題が悪いのなら、最初にお題が示された時点で(=前スレで)反論しないとね
議論が終わってから「xxが悪い」と言い出しても遅いよ
もし今から反論したいのなら、Python/ML/Haskellでは簡潔に書けるけど
Rubyではそうではない「単純明快な」お題を、Python/ML/Haskellのコードで示してくれ
論よりコードだよ
なお、議論の再開に関しては即答しなくともかまわない
たとえば次スレでバトルの第三ラウンドを始めてもいいよ
判断はそちらにあずける
734:デフォルトの名無しさん
12/02/11 18:48:23.94
前スレも>>700も書いたのは俺
あのときハッシュを使ったのはRubyのコードが例外を投げてたから
最後に関数型っぽいコード
ys = filter(lambda x: x in ["Green", "Yellow"], xs)
735:デフォルトの名無しさん
12/02/11 19:10:15.80
>>733
いや、お前の主張が間違ってたのだからそこで終了だろｗ
結局優位性すら認められずｗ
736:621
12/02/11 19:17:12.53
>>734
>あのときハッシュを使ったのはRubyのコードが例外を投げてたから
お題のコードは変数宣言が欠けているから例外が発生するのは明白
こちらとしては、その程度の壁なら自力で対処できるくらい「Rubyを知っている」と思っていた
また、もしも例外発生を自力で解決できないかったのなら、
その時点でそれを言うべきだったと思うよ
そんな機会はいくらでもあった
例外うんぬんのいい訳は、前スレ(あるいは今スレ>>621)から>>700のレスまで
「ちゃんとしたコード」の完成に時間を要した理由にはならない
>ys = filter(lambda x: x in ["Green", "Yellow"], xs)
ys = xs.select { |x| ["Green", "Yellow"].include? x }
737:デフォルトの名無しさん
12/02/11 19:24:56.68
「Pythonを知らない」奴がなぜ偉そうなのか分からん
738:デフォルトの名無しさん
12/02/11 19:25:20.24
>>736
> お題のコードは変数宣言が欠けているから例外が発生するのは明白
そうじゃなくて、>>561のRubyコードはgreen, yellow, red 以外なら
raise RuntimeError の行で例外を投げてるだろ
739:621
12/02/11 19:26:17.24
>>735
１つの主張が崩れても全体が否定されないよう、意図的にお題は３つに分かれている
残念ながら「Pythonは関数型プログラミングには不適格」という烙印は消えていないw
では、残る２つの主張を崩せる反論の準備をよろしく頼むぜ
議論の再開を待っているよ
740:デフォルトの名無しさん
12/02/11 19:28:30.99
やはりPythonの解答が「明らかに」美しいな。この問題だと
741:621
12/02/11 19:35:15.41
>>738
ML/Haskellといった静的型付け関数型言語は、green, yellow, red 以外なら型エラーになる
それに合わせてRubyは動的型付けだから例外を投げるコードにしている
それがお題だ（関数型言語は知っているんだよね？）
ただし、Pythonでは例外を投げるコードが難しいみたいだったから、
あの時はその部分について「見逃してあげた」だけの話
もし反論があるなら、>>700のコードについて、例外処理を含めて再実装してくれ
742:デフォルトの名無しさん
12/02/11 19:38:43.73
>>741
>>562のPythonのコードも green, yellow, red 以外なら例外投げる
見逃してもらう必要は無い
743:デフォルトの名無しさん
12/02/11 19:40:32.46
非現実的な馬鹿らしいお題だな
744:デフォルトの名無しさん
12/02/11 19:48:13.07
>>737
同意するわ。
こいつPythonのプログラム読めて無いじゃん。
可読性を議論するレベルに達してない。
745:デフォルトの名無しさん
12/02/11 20:06:42.60
PHP最強ということで結論が出たようだな。
746:デフォルトの名無しさん
12/02/11 20:13:32.23
>>561>>562
ML,Haskell,Pyhtonは似てるけどRubyだけ異質で浮いてる。
はっきり言ってRubyだけキモい。
747:621
12/02/11 20:13:33.28
>>742
あっそうなんだ、>>562でもハッシュを投げるんだね
失礼した、謝罪する
では、型エラーまたは例外発生をお題に含めるものとして、
>>621の「Pythonではハッシュを使わなければ書けない」という主張を崩すために、
>>700(あるいは>>734)のコードについて例外処理の実装を追加してみて欲しい
こちらで試したところ、>>700,734とも例外は発生してない
748:621
12/02/11 20:17:06.28
>>740,746
そういった意見は、主観であり客観的な判定材料にならないことは
すでに結論付けられている
だから>>621では具体的で客観的な問題指摘を示した
したがって、同様なレベルの意見を希望する
749:デフォルトの名無しさん
12/02/11 20:31:40.61
いまをときめくFacebookも、ブログシステムてして他の追随を許さないWordPressも
CMSとして最強の呼声高いDrupalも、みんなPHPで作られているんですね。
すごいよなぁ。
750:デフォルトの名無しさん
12/02/11 20:35:29.04
PHP遅すぎてC++に変換したり
苦労しているみたいだけど
751:デフォルトの名無しさん
12/02/11 20:38:45.64
え？ ここLLのスレだよね？
752:デフォルトの名無しさん
12/02/11 20:46:39.95
>>748
>>621は間違ってただろｗさっさと訂正しろよ
753:デフォルトの名無しさん
12/02/11 20:48:52.46
>>748
「ハッシュは異質・トリッキー」が主観で無くて何なんだ？
客観的と言うなら、ハッシュで分岐するのが
キーワード引数の例(>>690)のように
機能的に劣った点があることを示せ
754:デフォルトの名無しさん
12/02/11 20:54:05.79
621が自分の主観を客観的を言ってるんだけど、何なの
755:621
12/02/11 20:58:47.63
>>752
>>742から再実装されたコードが提示されたら、まとめて訂正するつもりだよん
今のままだと>>700のコードは例外を投げないから仕様不整合であり、
>>621の「ハッシュを使わなければ書けない」という主張は崩れていない
>>742が(仕様不整合を)見逃してもらう必要は無いと、明確に意志を示してくれたので、
それを尊重してコードの提示を待っているところ
756:デフォルトの名無しさん
12/02/11 21:07:28.71
>>755
お前はコードの提示を待つ前に>>753に答えるべき
757:デフォルトの名無しさん
12/02/11 21:09:31.44
長文＝客観的
758:621
12/02/11 21:35:08.04
>>756
では、>>753に答えよう（>>753は見落としていたので、指摘ありがとう）
まず、お題の題名が多分岐なのだから、Ruby/ML/Haskellのように
言語仕様に多分岐式を含む言語であれば、多分岐式を用いてコードを実装するのが当たり前
でもPythonは言語仕様に多分岐式を含まないから、
それをハッシュで「代用」しなければならない
次にハッシュで代用することの問題点を述べる
・Ruby/ML/Haskell
予約語 case によってコードが多分岐処理の実装である事は一目で判断できる
・Haskell
コードをじっくり眺めなければ、それが多分岐処理なのか、それとも
本質的にハッシュを用いる処理なのかを判断できない
つまり、Pythonのハッシュによる「代用」は、可読性の悪化という影響をもたらす
759:デフォルトの名無しさん
12/02/11 21:39:05.26
おおむねRubyしか使ってないけど
(趣味プログラマです)
他の言語を知るにつれて
Rubyってメタプログラミング力が弱いような気がしてくる
ちょうどいい感じに使いやすくメタプログラミングできるようになってるだけで
なんか、深い事しようとすると出来ないようなきがする
実際にはそこまでのメタプログラミング能力は要らないのだけど
ブログなどのネタなんかだと、他言語の方がダイナミックなこと出来るなぁ
などと思ってしまう
例えば、Rubyではスクリプトのパース時に細工したりは出来ないし
かといって他の言語に移ろうとかいう気は起こらないけど
760:デフォルトの名無しさん
12/02/11 21:43:08.35
>>758
> 本質的にハッシュを用いる処理なのかを判断できない
これを主観という
761:デフォルトの名無しさん
12/02/11 21:46:44.47
Rubyがプチヒットしたのは
主にRailsのおかげなんだろうけど
たまたま備わっていた
・完全なオブジェクト指向＆オープンクラス
・DSLに向いてたブロック構文
・同メソッド呼び出し括弧の省略
・適度なメタプログラミング力
がマニアにうけたのかなぁ
島根県の公式サイト程度ならまだしも
イギリスの公式サイトがRuby製で製作中なんて
無茶しやがってとか思うけど
よくは知らんがクックパッドとか、そこそこ大きそうなサイトも運営されてるので
大丈夫なんだろうか
GitHubもRailsらしいが
762:621
12/02/11 21:52:05.58
まだ時間があるようなので、>>758を続ける
次にハッシュを用いる事それ自身の問題点を示す
Pythonのハッシュは、そのキーとして用いれるのは不変なデータ型(数値/文字列/タプル)だけ
これは、このお題の入力値が「たまたま」文字列であったから何の問題も無いが、
課題をより一般化して、任意のレコード(オブジェクト/ハッシュ)が渡されたと「仮定」する
この場合、Pythonだと多分岐処理をハッシュでは実装できなくなる
これは「Pythonは拡張性に劣る」という欠点となる
また、Rubyではハッシュのキーとして任意のオブジェクトを用いることができるから、
多分岐処理をcase式とハッシュのどちらでも実装が可能になる
これは「Pythonは表現力に劣る」あるいは「ハッシュの機能性が劣る」という欠点となる
以上
763:デフォルトの名無しさん
12/02/11 21:53:21.33
>>758
ハッシュで代用するというか、Visitorパターンだな
じっくり眺めなければ判断できないという批判は、全てのデザパタに当てはまる
764:名無し~3.EXE
12/02/11 22:02:05.48
ざっと流し読みしたら、一人で頑張ってるのがいるようだけど
大好きなRubyたんのシェアが伸びるどころか落ち込んでるのが
余程気に食わなかったのかね
Railsがありながらシェアが伸びないのは何故なんだろうね
765:デフォルトの名無しさん
12/02/11 22:04:17.12
>>755
def Raise(e): raise e
ys = (x for x in xs
if (lambda x :
True if x == "Green" else
True if x == "Yellow" else
False if x == "Red" else
Raise(KeyError))(x))
766:デフォルトの名無しさん
12/02/11 22:04:40.85
藪をつついてデザパタ全否定
767:621
12/02/11 22:10:36.90
>>760
その判断が一目で(瞬時に)できるか、じっくり眺めなければならないかは、
プログラマの能力に依存する話
そして全世界のあらゆるPythonプログラマが優れた能力を備えていると仮定すれば、
瞬間的な判断の可否は主観と言えるだろう
でも現実は、そうではないハズだ（それとも、これすら主観であると決めつけるのかな？）
経験豊かなプログラマもいれば、ビギナーもいる
従って、これを主観と決めつけることはできないと判断する
また、可読性という評価基準そのものが主観性を含むものだ
「予約語caseがあれば分岐処理の始まりであると一目で分かる」と考える人は多いと思うが、
中には「caseを見落とすかもしれない」と屁理屈をごねる変な人もいるかもしれない
でも、これらはそれぞれの人達の主観であるから客観性は存在しない
では、本当に「可読性」を完全に無視していいのか？という話になる
Pythonの優れた特徴である可読性の良さという利点も無視されるけど、
それでもいいの？という意味だ
判断は>>760に委ねたい
768:デフォルトの名無しさん
12/02/11 22:18:04.10
うんこ
769:デフォルトの名無しさん
12/02/11 22:18:37.53
>>762
> Pythonのハッシュは、そのキーとして用いれるのは不変なデータ型(数値/文字列/タプル)だけ
> これは、このお題の入力値が「たまたま」文字列であったから何の問題も無いが、
いるよな。都合が悪くなると後から条件変えてくる奴。
不変なデータ型ってことにケチつけるなら、
まずHaskellでmutableなデータ型が入力値のときのコードを出せよ
770:デフォルトの名無しさん
12/02/11 22:18:39.79
>>702
>Rubyは書き捨てスクリプト専用言語だから
>キーワード引数なんて要らない
冗談じゃない。
Rubyにも本物のキーワード引数が欲しいし、Matzもそう言っている。だからこそ2.0で導入される予定。
>あれは大きいプログラム用の機能だからね
冗談じゃない。キーワード引数は小さいプログラムでも実に役に立つ。
こんなこというのは、Pythonをまともに使ったことないんだろう。
キーワード引数は、Python使って嬉しかったことの筆頭。
しかしlambdaが文をとれないなど残念な面も多い。RubyのブロックがPythonにも欲しい。
771:デフォルトの名無しさん
12/02/11 22:18:43.40
関数型言語のコードを一見して分かる優れたプログラマばかりなら
621の理屈は通るけどね
772:621
12/02/11 22:18:56.77
>>765
コードありがとう
でも、このコードは外でRaise(e)という関数を定義しているよね
ここまで提示されたすべてのコードには、外部定義は一つもなかった
このままだと「Pythonは外部定義が無ければ書けない」という
批判材料を敵に与えてしまうことになるけど、それでもいいのかな？
もし可能であれば、外部定義の無いコードに書き直して欲しい
773:デフォルトの名無しさん
12/02/11 22:19:55.73
>>772
外部定義をしてはいけない理由はなに？
明らかに全てのコードの中で一番スッキリしてるだろ
774:デフォルトの名無しさん
12/02/11 22:20:40.61
>>772
Raise() は一度定義すれば何度でも使えるけど？
つまり一切のライブラリの使用を禁止ってこと？何の縛りプレイ？
775:デフォルトの名無しさん
12/02/11 22:20:43.38
敵なんてどこにいるんだと思ったが、バトロワスレだからべつにいいか。
776:デフォルトの名無しさん
12/02/11 22:23:53.83
>>775
敵はあなたの心の中に潜んでいるのだよ。
777:デフォルトの名無しさん
12/02/11 22:24:51.58
たしかに
うんこ
と
言わざるを得ない
778:デフォルトの名無しさん
12/02/11 22:25:30.92
今にして見れば、Rubyのコードが終わってる
779:デフォルトの名無しさん
12/02/11 22:26:24.86
うんこーど
780:デフォルトの名無しさん
12/02/11 22:26:33.28
Perlの話もしろよ
781:デフォルトの名無しさん
12/02/11 22:28:45.39
>>772
SML の datatype や Haskell の data も外部定義
782:621
12/02/11 22:29:09.41
>>763
>じっくり眺めなければ判断できないという批判は、全てのデザパタに当てはまる
「じっくり眺めなければ判断できない」ことが全ての言語に当てはまるのなら批判はしない
Ruby/ML/Haskellであれば予約語caseがあるから一目で判断できるのに、
Pythonは「じっくり眺めなければ判断できない」から批判されている
分かるかな？
783:デフォルトの名無しさん
12/02/11 22:32:49.01
今にして見れば、Rubyのコードが一番終わってる
784:621
12/02/11 22:35:01.27
>>769
では、バトル第三ラウンドでは、Haskellでも書ける(imutableな)レコード型を入力値とする
お題を準備することにしよう
もし不満であれば、>>769が別のPythonに有利なお題を準備すればいい
785:デフォルトの名無しさん
12/02/11 22:35:27.55
>>782
予約語 if と True/False を見ても一目で判断できないなら終わっとる
ていうかお前以外誰も「一目で判断できない」と言ってない
お前しか批判してないんだから
> Pythonは「じっくり眺めなければ判断できない」から批判されている
みたいに伝聞のような書き方をするな
786:デフォルトの名無しさん
12/02/11 22:35:51.72
>>784
お前お題の作り方下手糞すぎるからやめとけよｗ
787:デフォルトの名無しさん
12/02/11 22:36:39.12
>>785
長文だから許されるらしいよｗ
788:デフォルトの名無しさん
12/02/11 22:36:56.74
>>784
何でHaskellに合わせてルール決めるんだよ
789:デフォルトの名無しさん
12/02/11 22:39:45.44
Haskellを巻き込むのはやめて欲しいなぁ。
LL同士で勝手にやってほしい。
790:デフォルトの名無しさん
12/02/11 22:41:56.22
>>789
やってるのはRuby信者兼Haskell信者だけどな
791:621
12/02/11 22:43:17.39
>>773,774
Ruby/ML/Haskellのような局所宣言が言語仕様に含まれていれば、
これまでのように局所宣言で書いてもいいし、
あるいは外部定義に書き直してもいい
つまり「表現力が豊かである」という利点になる
ここで、もし「Pythonが外部宣言が無ければ書けない」とすれば、
それは(上記とは逆に)Pythonの欠点となる
この判断は、すべて>>765が示してくれるであろう新しいコードに係っている
792:デフォルトの名無しさん
12/02/11 22:47:07.45
それらコードを見て誰が「表現力が豊か」と思うんだろう
793:デフォルトの名無しさん
12/02/11 22:49:58.16
>>791
だから SML や Haskell でも datatype や data を使わないで書けって
外部定義禁止なんだろ？
794:621
12/02/11 22:51:40.58
>>785
このお題くらい単純なコードなら、誰でも短時間で判断できるだろう
でもコードの規模が大きくそして複雑になれば、誰も瞬間的な判断なんてできなくなるよ
可読性とは、そういった大規模開発で意味のある評価基準だ
というか、こんな反論しかできないとしたら、>>785は大規模ソフトウェア開発の経験ゼロだろ？
795:デフォルトの名無しさん
12/02/11 22:52:03.60
一切の外部関数の使用を禁止して競う表現力の高さw
796:デフォルトの名無しさん
12/02/11 22:55:26.82
機能を制限するのは、フェアじゃない気がするなぁ。
797:デフォルトの名無しさん
12/02/11 22:57:11.35
>>794
お前以外はコードの規模が大きくなっても
一目で判断できると思うぞ
798:621
12/02/11 22:57:43.84
>>786,788
だってバトルなんだから、こちらがRubyに優位な条件にするのは当然だろ
もしもPython支持派がお題を提示してくれれば、それに付き合うよん
では、新たなお題の準備、ヨロシクw
799:デフォルトの名無しさん
12/02/11 22:58:53.67
>>794
> 可読性とは、そういった大規模開発で意味のある評価基準だ
大規模開発なのに外部宣言は禁止なの？www
800:デフォルトの名無しさん
12/02/11 23:03:04.48
>>798
なんでRubyがクソに見えるお題作っちゃったの？
801:621
12/02/11 23:04:36.45
>>793
ML/Haskellは静的型付け言語だから、データ型の定義は認めている
このバトルは Ruby vs. Python なんだから、些細な問題だろ
802:デフォルトの名無しさん
12/02/11 23:07:09.83
>>641
いやいやそこは
<cond> if <true> else <false> then
だろ。
実装によっては
<cond> if <true> else <false> end
でもいいらしいけど。
803:621
12/02/11 23:08:16.62
>>796,799
外部宣言を禁止している訳じゃないよ
>>791を読んでくれ
さすがに長文レスは疲れてきたぜw
804:デフォルトの名無しさん
12/02/11 23:08:27.00
>>801
お前以外は外部定義した関数を使うのは些細な問題だと思ってるよ
805:621
12/02/11 23:09:45.19
>>800
>.... がクソに見える
>>760によれば、これが主観というものらすい
806:デフォルトの名無しさん
12/02/11 23:11:16.09
>>805
お前は自分のレスがクソみたいな主観だって認めてるんだな
その事に驚いた
807:デフォルトの名無しさん
12/02/11 23:13:05.47
>>803
いや、関数内部でデータ型を定義できないのは
明らかに表現能力の制限だから
SMLやHaskellのことだけど
808:デフォルトの名無しさん
12/02/11 23:14:56.82
つーかRubyのコードはホントひでーな
こんなクソコードをドヤ顔で貼ったんだと思うと笑える
809:621
12/02/11 23:20:02.93
>>804
まあ、外部宣言の話は、>>765がコードを示してくれるまで待ったほうがいいんじゃね？
もしも>>765が外部宣言を使用しないようコードを書き直すことができるのなら、
Python陣営に不利な条件は完全に無くなって、
>>621にある３つの主張の中の一つが完全に崩れ去る訳だから
810:デフォルトの名無しさん
12/02/11 23:21:41.92
標準ライブラリに特定の関数（この場合はRaise）が在るか無いかが
言語の表現能力を決めるらしい
811:デフォルトの名無しさん
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) の間違いだろ
信者がそんなミスするなよな