5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【Perl,PHP】LLバトルロワイヤル12【Ruby,Python】

1 :デフォルトの名無しさん:2010/09/13(月) 21:48:40
最強のLL=軽量プログラム言語は、どれよ?

エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・
さあ、死ぬまで語りやがれ!!!

■LLとは?
軽量プログラミング言語(Lightweight Language,LL)とは、取り回しに優れ、
コードの作成や修正が容易と見なされるプログラミング言語のことを指す。

ここでいう「軽さ」はプログラマの負担の軽重を指し、
実行速度に優れているという意味ではない。

現在の水準では
・インタプリタ
・動的型
・正規表現
・クロージャ
などを利用できるものがLLと呼ばれることが多い。(Wikipediaより)

過去スレは容量オーバーのため>>2に分離

2 :デフォルトの名無しさん:2010/09/13(月) 21:51:53
※前スレ
http://hibari.2ch.net/test/read.cgi/tech/1276128624/
■過去スレ
【Perl,PHP】LLバトルロワイヤル10【Ruby,Python
http://pc12.2ch.net/test/read.cgi/tech/1270996206/
【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1267553581/
【Perl,PHP】LLバトルロワイヤル8【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1259287439/
【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/
【Perl,PHP】LLバトルロワイヤル6【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1244166510/
【Perl,PHP】LLバトルロワイヤル5【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1238720336/
【Perl,PHP】LLバトルロワイヤル4【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1234635513/
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1215319832/
【Perl,PHP】LLバトルロワイヤル2【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1209289408/
【Perl,PHP】LLバトルロワイヤル【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1188997302/

3 :デフォルトの名無しさん:2010/09/13(月) 22:05:55
>>1

4 :デフォルトの名無しさん:2010/09/14(火) 20:28:25
Ruby最強

5 :デフォルトの名無しさん:2010/09/15(水) 16:29:25
あんたも好きねぇ。

6 :デフォルトの名無しさん:2010/09/15(水) 20:59:52
PHP を Perl, Ruby, Python と同じ土俵で比べるのはどうなの?
PHP は R, Maxima みたいに限られた用途に特化した言語だと思う。

7 :デフォルトの名無しさん:2010/09/15(水) 22:07:22
PHP は ASP と比べるべき存在

8 :デフォルトの名無しさん:2010/09/15(水) 22:22:09
Pythonはスコープがちょっと…嫌いかな。
意図してやってるんだろうけど。

9 :デフォルトの名無しさん:2010/09/16(木) 02:08:23
ん?Pythonのスコープってそんなイリーガルなところあったっけ?
ごく普通のスコープだと思うが。
privateメンバが作れない、とかの話?

10 :デフォルトの名無しさん:2010/09/16(木) 02:11:49
Rubyの間違いでした

11 :デフォルトの名無しさん:2010/09/16(木) 10:36:26
Rubyのスコープって、privateが実質無くてprotected相当って辺りとか?

12 :デフォルトの名無しさん:2010/09/16(木) 10:41:43
>>8>>10 は別人な希ガス

13 :デフォルトの名無しさん:2010/09/16(木) 12:07:21
rubyのブロック内のスコープはたしかにちょっとハマりやすい

14 :デフォルトの名無しさん:2010/09/16(木) 18:14:32
JavaScript派が通ります

15 :デフォルトの名無しさん:2010/09/16(木) 18:52:59
JavaScript派はletをECMAScriptに追加するよう懇願するべき

16 :デフォルトの名無しさん:2010/09/16(木) 21:14:44
JSのスコープって論外だよな。こんなんで、アニメーションやらデスクトップアプリ並のUIを制御しろって。

17 :デフォルトの名無しさん:2010/09/16(木) 21:51:34
>>15
http://www.youtube.com/watch?v=P5sWncFiYnA

18 :デフォルトの名無しさん:2010/09/16(木) 22:17:01
>>16
標準ライブラリの不足とかならともかく、スコープのせいで複雑なプログラムが作りにくくなるのか?

どっちかというと問題になりそうなのは宣言していない変数に代入するとグローバルオブジェクトのプロパティになるとか、
宣言してないプロパティを参照してもエラーにならないとか、そっちの方が問題だと思う

19 :デフォルトの名無しさん:2010/09/16(木) 22:54:11
まぁ、そうかもしれない。スコープについては一応汚い解決策があるし
(function pseudo-let(){ })()

20 :デフォルトの名無しさん:2010/09/17(金) 02:50:38
同じ事じゃん。ブロックで局所化出来ない、名前空間がない、PerlのstrictとかPHPのE_ALLのような警告機能もない。プア過ぎる。

21 :デフォルトの名無しさん:2010/09/17(金) 03:30:08
strictはES5で導入される
名前空間も代替することはできる

22 :デフォルトの名無しさん:2010/09/17(金) 04:49:06
ECMAScriptがどうだと言われても、IEでもFirefoxでも動くJavaScriptがそうなってなければ意味ないじゃん。
Perlのオブジェクト指向がよく批判されるけど、統一性のなさから言ってJavaScriptの方がよっぽど酷いじゃん。好き勝手な方法でクラスなりメソッドなり定義してて。

23 :デフォルトの名無しさん:2010/09/17(金) 05:24:09
JavaScriptにはクラスもメソッドも無いんじゃなかったっけ

24 :デフォルトの名無しさん:2010/09/17(金) 05:37:03
クラスは無いけどメソッドはありますよう

25 :デフォルトの名無しさん:2010/09/17(金) 07:03:36
クラスの定義ってそんなにバリエーションあるかな。

hoge.constructor === Hoge
になるのは
hoge = new Hoge();
でオブジェクト作ったときだけで他の方法は王道ではないよね

メソッドの定義も結局は
hoge.method = function() {}
ってやるか
Hoge.prototype.method = function() {}
ってやるかの2通りに還元されるし

26 :デフォルトの名無しさん:2010/09/17(金) 12:08:43
そもそもjsはオブジェクト指向とか目指してなかった。
プロトタイプベースという考え方の上に成り立ってるだけ。
そこでオブジェクト指向チックに遊ぶこともできるだけ。

27 :デフォルトの名無しさん:2010/09/17(金) 12:15:01
classというキーワードは無くても、JavaScriptもPerlもクラス相当のものを使ってプログラミングするけどな。

28 :デフォルトの名無しさん:2010/09/17(金) 12:45:14
それならCでも(C++じゃなく)できるわ

29 :デフォルトの名無しさん:2010/09/17(金) 13:13:58
>>26
x: そもそもjsはオブジェクト指向とか目指してなかった
o: そもそもjsはクラス指向とか目指してなかった

ではないのかな?プロトタイプベースもクラスベースも
オブジェクト指向という(とても曖昧な)概念に含まれると思うよ。

30 :デフォルトの名無しさん:2010/09/17(金) 13:46:50
単なるスロット内蔵のクロージャだからな
schemeをベースに意味論を作れば間違いがなかった
jsはLISP派生として見れば失敗作だ


31 :デフォルトの名無しさん:2010/09/17(金) 13:52:54
カリー化はschemeよりも便利に使えると思う > js

32 :デフォルトの名無しさん:2010/09/17(金) 19:31:48
jsがボコボコに叩かれる流れになるかと見ていたけど、
jsけっこういいかも的な流れになりつつあるなw

33 :デフォルトの名無しさん:2010/09/17(金) 20:40:14
ユーザはエセクラスベースオブジェクト指向じゃなくって、まともなクラスベースオブジェクト指向でプログラミングしたいんだから、そうせざるを得ない。
その要望に応えて、Perl6もECMAScriptもclassを導入してる。


34 :デフォルトの名無しさん:2010/09/17(金) 22:00:02
C/C++/C#/Pythonで問題ある?

35 :デフォルトの名無しさん:2010/09/17(金) 22:03:37
Javaがない

36 :デフォルトの名無しさん:2010/09/17(金) 22:07:43
>>35
ありがとう

37 :デフォルトの名無しさん:2010/09/17(金) 22:09:59
>>32
JSは昔、阿呆なコードが量産されてたから悪い印象持ってる人多いけど
言語仕様としてはちゃんとしてるからなあ

38 :デフォルトの名無しさん:2010/09/17(金) 22:17:55
>>33
プロトタイプベースはそれなりの歴史もあるし、エセオブジェクト指向ではないよ。
C++/Javaみたいなガチガチな静的言語に慣れきったプログラマであれば、
プロトタイプは違和感のある(デザパタで実装しなければならない)不自由なものに見えるけど、
Lisp系やRubyみたいなメタプログラマブルな動的言語を知っていれば、
まあそんなアプローチもあるのかな?程度の印象ですむ。
また、GUI開発のような本質的に動的なオブジェクトを扱うプログラミングの場合、
(クラスベースよりも)プロトタイプベースのほうが適しているとい意見もある。

まあ、大多数のプログラマにとっては、「オブジェクト指向=クラスベース」だから、
>>26,33みたいな勘違いをした意見が出てしまうのは、しかたがない話なのかもしれない

39 :デフォルトの名無しさん:2010/09/17(金) 22:22:34
勘違いではなく事実だろう

40 :デフォルトの名無しさん:2010/09/17(金) 22:26:35
>>26 はともかく、>>33 はちょっと偏見入ってる感じだな
クラスベースだけがまともなOOPL、ではない

41 :デフォルトの名無しさん:2010/09/17(金) 22:27:36
勘違いだよ

この意味がわかっていないひとは経験不足

42 :デフォルトの名無しさん:2010/09/17(金) 22:34:06
ユーがOOPだと思ったものがOOPヨ
OOP感じなかったらそれはOOPとはノットネ

43 :デフォルトの名無しさん:2010/09/17(金) 22:34:17
>>39
自分がプロトタイプベースのプログラミングが上手くできないのを責任転嫁してるだけ

44 :デフォルトの名無しさん:2010/09/17(金) 22:36:52
>>42
別に矛盾はしてないと思うけどなあ。>>38は何か専門用語使いたいだけな感じ

45 :デフォルトの名無しさん:2010/09/17(金) 22:38:59
プロトタイプベースとクラスベースっていう分け方がどうなのか?
PrototypeパターンとかってGOFにもあるわけだし。
動的なOOP言語はどちらかというとプロトタイプ寄りなんだし。
C++とかJavaの方がちょっと異色なんだよ。

46 :デフォルトの名無しさん:2010/09/17(金) 22:39:30
適してる適してないとかいう話に勘違いも糞もあるか

47 :デフォルトの名無しさん:2010/09/17(金) 22:48:15
>>44もプログラマの一人で普段から専門用語を使いまくりのはず
それなのに、自分が知らない言葉だったという理由で>>44を特殊な専門用語扱いするのは
矛盾してる(ダブスタのような)気がする

まあ、プロトタイプベースはもともとマイナーな存在だったのだけど、jsの爆発的普及で
一気に表舞台へ引きずり出された印象がある。だから、今しばらくの間、多くのプログラマが
勘違い/偏見/矛盾した考えを無意識に持つという混乱した状況はしかたがないのかもしれない

48 :デフォルトの名無しさん:2010/09/17(金) 22:49:16
価値観の違いと勘違いは違うだろ。マ板に行ってくださいお願いします

49 :デフォルトの名無しさん:2010/09/17(金) 22:49:43
自己レスで訂正
x: >>44を特殊な専門用語扱いするのは
x: >>38を特殊な専門用語扱いするのは


50 :デフォルトの名無しさん:2010/09/17(金) 22:53:40
とりあえず >>26 が self という言語を知らないことだけは想像できる。


51 :デフォルトの名無しさん:2010/09/17(金) 22:54:15
まあそんなアプローチもあるのかな?程度の印象ならば、違和感がなく自由なものに見えるのだろうか…

52 :デフォルトの名無しさん:2010/09/17(金) 22:54:31
>>48
要はオブジェクト指向とは何か?という定義が曖昧なんだと思う
クラスベースしか認めない、って人にとってjsがエセに見えるんだろ

その定義を価値観と言い換えてもかまわんのだけど

53 :デフォルトの名無しさん:2010/09/17(金) 22:55:34
>>50
全然知らんわw

>>52
だから最初からそう言ってるだろアホ

54 :デフォルトの名無しさん:2010/09/17(金) 23:02:57
      ト、                  ______)
     「::::\┐  _,,. --──- 、..,,_    `ヽ.  で  泣  も
   r-‐'へ::::::::!_'´ __,,,,......,,,,,__    `ヽ、    ', す い  う
   > :、:;::::::>''"´       `"'' 、   ':,   i. よ て   や
  └─ァ''"  /            `':.,  ',.   !!  る  め
     ,:' /   / ,' /  ,' i.  ', ':,  i    ',!  i.  |.   子   て
   / ,'  .,'`メ、!,_,/ ./! 、i__,,!イ .|.  i ,ゝ |  |.   も  .下
   ,'  i   ,!/,.-ァー;' / !/ァ;ー'-r'、 ! /__」  |   |    い  さ
   i   ! ハ!イ i `ハ     i `'ハ Y/ i/  ; |  |.   る   い
  └'^iー! ,iヘ ':,_ン    ':,__ン ノ!'  |  i. i  ,'    ん   ! !
    ,:'  .!.7,.,.,     '     .,.,., ,'!  .!  | |∠,_    ________
 o ゜/  ,:'. ト、   r‐,-‐ ''"´`ヽ. / ;   |  ! !  `Y´ ̄
   ,' .// i. `i:.、.,!/      ,.イ,:' ,'   | ,'i .|
   レヘ_/ヽ. !ァ''"´ `ヾi、ー=''"/ヨ___,/、___!へr三/) LLの定義 (ヽ三/) ))
       /      ヾ!二へ/:::::ト,.-'‐'^ヽ(((i )  ___   ( i)))
       ,'        ',l>く}:::7    rノ/  /     \  ヽ \
     K_    _,r-イYン/ムi:::::/   ,ノ´く  / (●) (●) \  > )
       /Y>ベ´   '';:::::io:/   ,イ\ `/::::::⌒(__人__)⌒:::::\' /
     ,.:':::::ヽ、ン':,    ヽ/   ,イ /゙,ー、 |        ̄      |/
   /:::/:::::::::::::::::ヽ.   '    ,.;'ヾ/、/_/ノ \              /
 ,く:::::::/::::::::::::::::::::::::`ヽ、___,.,.イi `'ー'^''‐'/    \        :::::/

55 :デフォルトの名無しさん:2010/09/17(金) 23:04:21
LLというのは最初にPがつく言語のこと

56 :デフォルトの名無しさん:2010/09/17(金) 23:05:10
>>55
Rubyからクレームがつくぞw

57 :デフォルトの名無しさん:2010/09/17(金) 23:05:59
C++のクラスベースは、Cの構造体をベースにしている。
ほかの言語も、Cに似ていると色々都合が良いみたいだし
クラスベースでいいんじゃね?

58 :デフォルトの名無しさん:2010/09/17(金) 23:07:00
>>53
タリバンや米国みたいな自分達の価値観以外は認めないっていう絶対主義思想は怖いね
だから世界では紛争が絶えない。(同様にスレが荒れるのも絶えない)
これら宗教論には歴史の重みがあるから一概な批判は控えるべきだけど、
>>53は単純な技術的無知からくる偏見でしかないから、お気の毒様とか可哀想としか....

59 :デフォルトの名無しさん:2010/09/17(金) 23:12:11
絶対主義思想はどっちなんだか。>>58だって自分は絶対だって言ってるじゃん
議論を戦争が終わらない理由とかに安易に結び付けるような中学生みたいな奴が何言って寒い

60 :デフォルトの名無しさん:2010/09/17(金) 23:14:42
このブログエントリの汎用性は異常

オブジェクト指向の概念の発明者は誰ですか?
http://d.hatena.ne.jp/sumim/20040525/p1

61 :デフォルトの名無しさん:2010/09/17(金) 23:14:46
戦争が終わらないのは(自分以外の)一部の間違った人間のせいだ(キリッ

62 :デフォルトの名無しさん:2010/09/17(金) 23:15:56
>>60
志村だろ

63 :デフォルトの名無しさん:2010/09/17(金) 23:20:30
>>60
あらー、Simulaは無視っすかw

64 :デフォルトの名無しさん:2010/09/17(金) 23:22:04
>“1”ならもちろん Smalltalk 、“2”なら SIMULA

って書いてある

65 :デフォルトの名無しさん:2010/09/17(金) 23:23:57
>>58
禿だけど同意

66 :デフォルトの名無しさん:2010/09/17(金) 23:26:20
>>52で定義を価値観と言い換えてもかまわないって自分で言っといて何だコイツ

無知に間違いを指摘されて戦争論を語りだしてんのか

67 :デフォルトの名無しさん:2010/09/17(金) 23:29:33
>>64
ああ、確かに。
失礼した。


68 :デフォルトの名無しさん:2010/09/17(金) 23:59:14
シェルスクリプトの延長線上としてのJavaScript、が定着したのがWindowsだけってのがいまだに謎なのだわ

69 :デフォルトの名無しさん:2010/09/18(土) 00:07:21
>>68
Unix 系は Perl がシェルスクリプトの延長線上だからね。
未だに、 ブラウザ組み込みじゃない JavaScript 処理系の決定版もないし。

70 :デフォルトの名無しさん:2010/09/18(土) 00:20:50
仕様が先行して処理系がいまひとつぱっとしない
まるでLispだな

71 :デフォルトの名無しさん:2010/09/18(土) 00:29:38
>>68
どういう意味かよくわからない…

JavaScriptがWindowsでシェルスクリプトのように使われている、ってこと??
その位置には自分が知る限り、VBとかがいるような気がするのだが?

72 :デフォルトの名無しさん:2010/09/18(土) 00:33:09
WSH で Jscript が標準で使えることに対して、定着と言ってるのでは?
流行ってるかどうかは知らない。

73 :デフォルトの名無しさん:2010/09/18(土) 00:35:30
WSH(Windows Scripting Host)を Windows Shell の略語だと思い込んでいるのではないかと

74 :71:2010/09/18(土) 00:37:34
>>72
えー、WSHならVBでしょう?

>>73
あ、そういうことなのか

75 :デフォルトの名無しさん:2010/09/18(土) 01:04:30
>>68
まあ奇跡といえば奇跡だけど
Windowsにまともなシェルスクリプトがなかったからとも言える

76 :デフォルトの名無しさん:2010/09/18(土) 01:06:46
つか、Windowsは今後シェルスクリプトと言えば、
PowerShellではないのか?
個人的にはあんまり好きではないが、確かに.NETライブラリを直接使えるのは
強力だと思う。

77 :デフォルトの名無しさん:2010/09/18(土) 01:10:10
PowerShell は良いけどまだいまいち感がぬぐえない
IronPython とか IronRuby とかに期待


78 :デフォルトの名無しさん:2010/09/18(土) 01:13:01
Iron系はなんか放置されてね?

79 :デフォルトの名無しさん:2010/09/18(土) 01:17:34
IronPythonマンセーしたいけど、
Pythonは日本ではなぜかアレルギー示す人が多くて…(/_;)

80 :デフォルトの名無しさん:2010/09/18(土) 01:18:35
2chではpythonの方が多いから大丈夫

81 :デフォルトの名無しさん:2010/09/18(土) 01:22:21
>>80
え?そうなの?w
それは心強いなw

82 :デフォルトの名無しさん:2010/09/18(土) 01:25:02
ironpythonはVS2010上でポトペタを使ってプログラミング出来ると思ったけどやり方が分からん

83 :デフォルトの名無しさん:2010/09/18(土) 01:33:14
>>80
え?そうなの?w
それは心強いなw

84 :デフォルトの名無しさん:2010/09/18(土) 01:51:06
Iron系は、開発者自体はやる気もあるし、それ以外の趣味や研究対象として興味持ってる社員も少なくないように見えるけど
社全体の方針としては話題性以上のものを期待してないし、リソース割く気もないんじゃないかと傍目に思う

85 :デフォルトの名無しさん:2010/09/18(土) 03:14:38
大体、Iron〜とかって名前がよくねーよ。

86 :デフォルトの名無しさん:2010/09/18(土) 03:18:37
>>80
え?そうなの?w
それは心強いなw

87 :デフォルトの名無しさん:2010/09/18(土) 03:19:25
>>84-85
禿だけど同意

88 :デフォルトの名無しさん:2010/09/18(土) 03:22:28
>>81>>83>>86
うん。大船に乗ったつもりで安心していいよ

89 :デフォルトの名無しさん:2010/09/18(土) 03:24:21
>>88
ごめん。どうでもいいんだけど、俺の専ブラがおかしくて、
複数の書き込みしちゃったみたい。
以後気をつけます。


90 :デフォルトの名無しさん:2010/09/18(土) 03:29:34
cscript.exe上のJScriptは結構使うなあ
Unix系で決定版が無いのは何でだろうな
現状、その使い方ができるECMAScript環境ってUnix系でどんなのがあるっけ?

91 :デフォルトの名無しさん:2010/09/18(土) 03:53:54
emacslisp

92 :デフォルトの名無しさん:2010/09/18(土) 03:56:22
ECMAScriptねえ…
そもそも、シェルスクリプトでCGIまで書けるUNIXにおいては、
需要があるとも思えないんだよなあw

93 :デフォルトの名無しさん:2010/09/18(土) 04:07:18
まあそうなんだけどさw

94 :デフォルトの名無しさん:2010/09/18(土) 04:11:09
間違えた

95 :デフォルトの名無しさん:2010/09/18(土) 04:11:12


96 :デフォルトの名無しさん:2010/09/18(土) 06:45:47
>>85
Iron〜というと、つい「水、水がぁ〜」とか「弱ぇ〜」みたいなイメージが浮かんでしまう

 霧ィ〜の中ァ〜からァ〜〜、Iron・Ki・n・guuu〜〜〜 (^_^;

97 :デフォルトの名無しさん:2010/09/18(土) 09:31:46
>90
C++の悪口を言いながらPerlを愛用するのがUnix系
C++とPerl なぜ差がついたのか

98 :デフォルトの名無しさん:2010/09/18(土) 09:34:05
ん?
C++は残るけどperlは消えるよ

99 :デフォルトの名無しさん:2010/09/18(土) 11:14:41
unix系はCだろ

100 :デフォルトの名無しさん:2010/09/18(土) 11:22:02
>98
Perlは簡単な仕事を簡単にすることが目的だった
C++は難しい仕事のことばかり考えている
簡単な仕事には将来性がないという考え方なんだろうな

101 :デフォルトの名無しさん:2010/09/18(土) 11:33:48
cobolもshも消えないのに、普通に考えればどちらも消えない
古き良きbasicは

102 :デフォルトの名無しさん:2010/09/18(土) 12:15:30
>>90
Rhinoとか最近だとV8かな

103 :デフォルトの名無しさん:2010/09/18(土) 14:10:51
>>102
RhinoとかV8って単品でも使えるのか、知らんかった

104 :デフォルトの名無しさん:2010/09/18(土) 16:39:55
RhinoやGroovyみたいなJVM上のスクリプティング言語は
起動が遅くてどうも使う気になれん

105 :デフォルトの名無しさん:2010/09/18(土) 17:55:02
Scalaもおっそいね

106 :デフォルトの名無しさん:2010/09/18(土) 21:05:35
>>104
たとえ起動が速かったとしても、JVMが冗長言語Javaのためのものだからなー。

Scalaはよさげだけど、やっぱり汚い感じがするし、やっぱりJVMはJavaのためのものな気がする。

107 :デフォルトの名無しさん:2010/09/18(土) 21:14:41
>>106
うーん俺にとっては起動が遅いのが最大のネックであり全てだなあ
OS寄りの低レベルのことがやりにくいって問題はあると思うが
JVM上に乗ってりゃ少なくともライブラリ不足ということはないし
まともなUnicode対応が保証される

そうそう、Clojureとかもあるよな

108 :デフォルトの名無しさん:2010/09/18(土) 21:25:33
>>105,106
ScalaがJava VMベースだからという理由だけで好きになれない

109 :デフォルトの名無しさん:2010/09/18(土) 22:35:18
gooはどうなんだろうな

110 :デフォルトの名無しさん:2010/09/18(土) 23:21:31
>>103
Node.jsはエンジンにV8使ってるよね。

111 :デフォルトの名無しさん:2010/09/20(月) 01:11:16
相対的にではなく、ruby/pythonのメリットでなんだべさ

pythonはライブラリが豊富とか?

112 :デフォルトの名無しさん:2010/09/20(月) 01:16:12
豊富さという言葉も「XXXに対して豊富である」という相対的な評価でしかないんだけどな

113 :デフォルトの名無しさん:2010/09/20(月) 01:19:05
Perl/PHP/JavaScriptなんかと比べてってこと?

Pythonについては、そうだなあ…

・ライブラリが豊富
CPANにゃおとるが、DB関係とかでもまず多言語に遅れをとることはないし。

・標準ライブラリが豊富
結構なんでも標準にある。Webサーバや、smtp,ftp,pop3アクセスやSSLなんかも標準に入ってる

・クラスが柔軟
メタクラスとかかなりいじれる。

・結構アプリケーションからのサポートが多い
OpenOfficeとかVM関係とか

といったところかねえ…

難点としては、ライブラリが豊富過ぎて、デファクトスタンダードといえるようなものが
あまりないこと、とかw

114 :デフォルトの名無しさん:2010/09/20(月) 01:23:45
pythonについては、ぶっちゃけコーディングについての思想に共感できるかできないかって感じ
でもGoogle App Engineで使えるから、そこは今後にとって良いかも

115 :デフォルトの名無しさん:2010/09/20(月) 01:24:37
RubyよりPythonのほうが好きだけど、DjangoよりRailsのほうが好き。
こんな俺はどうしたらいいんだろう。ちなみにweb2pyはPythonぽくなくて好きじゃない。

116 :デフォルトの名無しさん:2010/09/20(月) 01:26:29
TurboGearsじゃだめ?

117 :デフォルトの名無しさん:2010/09/20(月) 01:32:11
rubyはライブラリ少ないのかね。

118 :デフォルトの名無しさん:2010/09/20(月) 01:36:17
俺はruby使いじゃないので、よくは知らんけど、
freshmeatとか見てる限りではPythonよりは
だいぶ少ないと思う。
ま、数があればいいってものでもないんですけどねw
多すぎればそれはそれで問題でw

119 :デフォルトの名無しさん:2010/09/20(月) 01:51:47
>>116
ありがとう。ちょっと調べてみるわ

120 :デフォルトの名無しさん:2010/09/20(月) 02:06:50
rubyの台頭を許したpython側の要因はZopeの失敗にあると思う。

漏れは以前はPHP使いで、ある時、Zopeという素晴らしいものがあって
これでpythonを始めたと、Zope&pythonを知人に勧められたんだけど、
Zopeはあまりに高尚すぎて自分には向かなかった。(理解不能だった)
その後、rubyを知って楽しくプログラミングができそうで興味を持ち始め、
更に(漏れにとっては画期的だった)Railsの登場によって、
PHPを捨ててrubyに走り、現在に至ってる。

もしZopeが世界中のWebプログラマの共感を得られるほど良い物であったなら、
自分はpython使いになっていただろうし、今ほどrubyは普及していなかったと思う。

121 :デフォルトの名無しさん:2010/09/20(月) 02:09:18
web関係とかはrubyの方がライブラリが多い気がする。
あと関係ないけどrubyのライブラリ配布サイトなどのサイトはデザインが綺麗なのが多いね。
オールマイティなのはpythonだね。科学者向けのライブラリとかGUIとか。

122 :デフォルトの名無しさん:2010/09/20(月) 02:13:47
>>115
Djangoを改造してRails風に使えるようにしたFWを自作すると幸せになれる

123 :デフォルトの名無しさん:2010/09/20(月) 02:13:57
>>120
それは結構同意かも。

俺もZopeを使って、いくつかやったけれど、いわれているほど、
生産性があがるとは感じられなかった。
そのために勉強しなければならなかった量を考えると、あんまり
引き合う気はしなかったな…
ってことで、俺はCherryPy+Cheetahとかに逃げたw

124 :デフォルトの名無しさん:2010/09/20(月) 02:14:40
>>116
だめだった

125 :デフォルトの名無しさん:2010/09/20(月) 02:16:32
PylonsとかPloneとか使ってみた人いる?

126 :デフォルトの名無しさん:2010/09/20(月) 04:33:48
>>124
ちなみにどの辺がお眼鏡にかなわないの?

127 :デフォルトの名無しさん:2010/09/20(月) 18:31:19
rubyのダイナミックローカルスコープは
違和感があるんだよな。

128 :デフォルトの名無しさん:2010/09/20(月) 19:51:24
      ,―ヽ____、―
   ,/  ノ       ヽ  ~\
  /   ノ   IPA    ヽ   ~\
/   ノ           ヽ、  `ヽ
|    ノ / ̄\   / ̄~ヽ ヽ    i
|   ノ              |  ノ
\  |  <●>  <●>  (  )
 \ |      | |       i /
    |      /  ヽ       レ
   i     (●_●)      /  
    i、    ,-――-、   ・ /
    i、  <(EEEEE)> ∵/   IPA Rubyがあれば、PHPやPythonなんて必要ない
      i、   \___/  _/
       \       ,ノ       
  ,,.....イ.ヽヽ、ー-―一ノ゙-、.
  :   |  '; \_____ ノ.| ヽ i
      |  \/゙(__)\,|  i |
      >   ヽ. ハ  |   ||



129 :デフォルトの名無しさん:2010/09/22(水) 08:18:07
>>120
Zope知らんからそこはわからないが、PythonはRubyistから見ると堅すぎって感じがする。
文法もそうだけど、それ以上に気になるのはライブラリのAPIかな。

130 :デフォルトの名無しさん:2010/09/22(水) 09:34:20
Pythonはその堅さを求めて使うものって感じじゃね
Rubyはササッと書くにはあのフリーさが丁度いいんだが
ゴリゴリ拡張されると別言語になっちまう

131 :デフォルトの名無しさん:2010/09/22(水) 11:48:15
最初からかっちり書く奴には大差がないということ?

132 :デフォルトの名無しさん:2010/09/22(水) 13:26:48
最初からかっちり書くならどっちもどっちじゃね

133 :デフォルトの名無しさん:2010/09/22(水) 14:18:58
最初からカッチリ書くならpythonが楽に決まってんだろ

134 :デフォルトの名無しさん:2010/09/22(水) 14:35:51
pythonはカッチリしか書けないけど、rubyはカッチリ書く事もフリーで書く事もできるって感じかな。

135 :デフォルトの名無しさん:2010/09/22(水) 15:24:33
Railsが現れて頭のブレーキが外れた感があるなw

136 :デフォルトの名無しさん:2010/09/22(水) 15:28:16
Rubyやめますか
それとも
Railsやめますか

137 :デフォルトの名無しさん:2010/09/22(水) 16:21:45
言語仕様的に嫌いなのではじめません

138 :デフォルトの名無しさん:2010/09/22(水) 16:31:07
ダメ!絶対!!

139 :デフォルトの名無しさん:2010/09/22(水) 17:22:24
>>133
そんなことはない。俺カッチリ派だけどRubyの方が綺麗に書けると思う。楽さは
同じか、わずかにRubyのが楽。

Pythonは普通の関数が前面に出てくるのがいやだ。特にreversed()とlist.reverse()は
許せん。前に誰か書いてたかもしれんけど、nose.tools.assert_equalとかも許せん。

140 :デフォルトの名無しさん:2010/09/22(水) 18:04:47
問題はカッチリじゃないコードが混じる可能性を考慮した場合なんだよね
Rubyもみんなカッチリ書くなら大丈夫なんだが
Pythonほど、そこの強制力がない

141 :デフォルトの名無しさん:2010/09/22(水) 18:07:17
>>139
なんで、そんなことが許せないの?

142 :デフォルトの名無しさん:2010/09/22(水) 18:28:10
>>139
たぶん君は 'delim'.join(lst) も許せないんだろうね

143 :デフォルトの名無しさん:2010/09/22(水) 18:41:38
>>140
rubyはフリーとカッチリのどちらでも書けるから、みんなが同意しないと混じる可能性があるけど、
pythonはカッチリしか書けないからこそ強制力があって、混じる可能性が無い

ということじゃないかと思ったのだけど....。
(pythonは詳しくないんで、漏れが間違って認識してるのだろうか?)

144 :デフォルトの名無しさん:2010/09/22(水) 18:49:10
ちなみに、

reversed(a)というのは、aはシーケンスで、aの要素の順番を逆順に並べかえた新しいシーケンスを返す関数
a.reverse()というのは、aはシーケンスで、aそのもの要素の順番を逆順に並び替えるメソッド


145 :デフォルトの名無しさん:2010/09/22(水) 19:18:56
>>143
pythonが書き方が一通りというのは幻想

146 :デフォルトの名無しさん:2010/09/22(水) 19:31:20
>>145
うーみゅ、幻想なのか....。

でも、そうだとすると「pythonは堅い(>>129,130)けどカッチリしていない言語」ってことなのかな。
「堅い」と「カッチリ」は同じ性質を表していると思ってたけど、なんか混乱してきたw

147 :デフォルトの名無しさん:2010/09/22(水) 19:34:57
Rubyにはpublic, private, protectedの呼び出し制限があるけど
Pythonは全部publicですから

148 :デフォルトの名無しさん:2010/09/22(水) 20:18:36
>>146
普段から使っている身としては、いわれてるほど、かっちりしてるとか
堅いとは思わないな…

3項演算子の導入とかも遅かったけど、結局は導入したし。
インデントにタブだって、結局のところは許してるし。

「Pythonic」っていうのは、単純に堅いとか書き方が一通りみたいな意味合いでは
もう通じなくなってるね。

ただ、型にはうるさいな、確かにw

149 :デフォルトの名無しさん:2010/09/22(水) 20:44:48
Ruby、そしてRailsの大量のDSLは可読性という点では最悪だろ。
ずっとRailsばっかり扱ってる人はそれでいいのかもしれない。
たまにRailsを使ってみると、どこで何をしてるのかサッパリ分からず、デバッグで途方に暮れる。

150 :デフォルトの名無しさん:2010/09/22(水) 20:53:00
RailsはRubyじゃないからRubyを責めるのはかわいそう

151 :デフォルトの名無しさん:2010/09/22(水) 21:10:09
pythonも一行にいくつもの式を詰め込んだり出来るよ
ただ改行するのがpython的ってだけ
キッチリ書かないのは文法違反になるというより思想の問題かな

152 :139:2010/09/22(水) 23:23:48
>>140
カッチリ書くことを推奨する文化はあると思うけど、強制ってのはありえん。
import re; re.compile = 'hogehoge'
これやれば一発で終了よ。

>>141
過去形と現在形だから。命名規則が謎い。名前かぶったからそうしたとしか思えない。
あと、もいっこはassert_equalごときでimportだるい。かといってデフォのは使いたくない。

>>142
それは許せる。むしろRubyのArray#joinがいつも文字列を返すことの方が疑問に感じる。
全部+して返すってのがいいと思ってるんだけど。

>>143
強制する言語はJavaだよ。Pythonはシンプルで明確さを求めるけど、あんまり強制みたいのはない。

>>147
その点に関しては実はPythonのが優れてる。Rubyのprivateはサブクラスから呼べるから、
本物のprivateじゃない。Pythonの_は規約でprotected、__はクラス名で名前修飾するから
継承階層での名前衝突の可能性が大幅に減少する。実質本物のprivateに近い。
_がprotectedという規約はPythonistaならみんな知ってるはずだから、うっかり呼び出すなんて
ことはないはず。Rubyのprivateはリファクタとかして、スーパークラス側でメソッドを切り出した
ときに、サブクラスと衝突する可能性がある。

>>149
自分でも言ってるけど、それはRailsのルールを知らないだけでしょ。規約を覚えて従う
ことで、保守性が向上するのがRails。まあ、Railsはたまに使う人のためのフレームワークでは
ないと思う。ああ、Railsの実装の可読性が最悪なのには同意するw

153 :141:2010/09/22(水) 23:28:53
>>152
命名規則に関しては、元々reverse()メソッドしかなくて、
ちょっとそいつは不便だよ、
って話でreversed()が2.3で追加されたって経緯がある。
その経緯を知っている俺なんかは全く違和感ないけど、
後から覚えた人から見れば、違和感あるのかね?

importに関しては何でもimportしなきゃならないのが、むしろPythonのいいところ。

154 :152:2010/09/22(水) 23:43:03
>>153
ああ、そうなんだ。情報thx
名前ぐらい慣れればないだろうけど、それは洗脳されてるだけだよねって感じかな。

assert_equalに関しては同意できない。何故なら、ほとんどテストクラスの中で使う
ことが確定してるから。やはり、selfが面倒くさかったとしか思えない。

ああ、似たので思い出したけど、TGのexpose系もおかしいよ。
ぜったいコントローラの中で使うじゃん。意味的に考えて、スーパークラスに定義されているべき。
無理だけど。

関数であるべきものをimportするのは良いけど、メソッドであるべきものをimportするのはイヤ。

155 :152:2010/09/22(水) 23:44:02
× 慣れればない
○ 慣れれば問題ない

156 :デフォルトの名無しさん:2010/09/22(水) 23:47:49
>>154
ま、じゃ、reverse()はいいとしてもさ、

noseなんて別に標準じゃない(標準的、ですらない)んだから、嫌だったら他を使えばいいだろうw
さすがに個々の外部ライブラリの文句を言い出したら、多言語だってきりがないだろう。

157 :152:2010/09/22(水) 23:52:15
え、でもnoseってかなり勢力でかくない?w
Pythonの世界あんま知らないけど、少なくともunittest使っていいのは小学生まで
だと思ってた。

158 :152:2010/09/22(水) 23:54:43
標準的ですらないってところ読んでなかった。そうだったのか。

でも今python テストフレームワークとかでググったら、noseっぽいのいくつかでてきたよ。
やっぱりPythonistaもself嫌いなんだよ。

159 :デフォルトの名無しさん:2010/09/22(水) 23:57:45
そういや、selfって名前も強制じゃないな。
これもあくまでも、PEPとかで推奨されているだけで、clsとかしたかったらできるんだよなw
やっぱ文化的な問題なんだろうな。

160 :デフォルトの名無しさん:2010/09/23(木) 00:07:39
なくすこともできるの?

161 :デフォルトの名無しさん:2010/09/23(木) 00:17:43
なくすのは無理。
使わないように、書く、というのは可能だけど。

162 :デフォルトの名無しさん:2010/09/23(木) 00:17:53
それは無理だろw

163 :デフォルトの名無しさん:2010/09/23(木) 00:24:38
def hoge(_, a1, a2):
  _.a = a1
みたいに書ければ気にならなくなるかな

164 :デフォルトの名無しさん:2010/09/23(木) 00:31:01
>>163
…いや、それはやりたければ、できるんだけどさ…

そんなコード見るのは、俺はゴメンだw

165 :デフォルトの名無しさん:2010/09/23(木) 01:09:19
嫌だ

166 :デフォルトの名無しさん:2010/09/23(木) 01:53:32
perlよりまし

167 :デフォルトの名無しさん:2010/09/23(木) 03:18:30

   ┌─┐
   │●│
   └─┤
   _   ∩
  ( ゚∀゚)彡
┌─┬⊂彡
│●│ おっぱい!おっぱい!
└─┘

168 :デフォルトの名無しさん:2010/09/23(木) 04:31:29
nestが深いとpythonの方が見やすいかなー

C構文に慣れてると、どうも } が endだと
一瞬対応するところが分からない…。


どっちも一長一短と思うが…慣れか

169 :デフォルトの名無しさん:2010/09/23(木) 05:41:59
どんな言語・ライブラリだって習熟していれば、それは使い易いだろう。
問題は習熟するまでに時間がかかる、習熟しても時間が空けばまた忘れてしまうって事。だから、Railsはダメ。

170 :デフォルトの名無しさん:2010/09/23(木) 05:51:09
Djangoはいいってこと?

171 :デフォルトの名無しさん:2010/09/23(木) 09:08:59
それはもっとダメ

172 :デフォルトの名無しさん:2010/09/23(木) 10:24:51
じゃあ何がいいんだよ?

173 :デフォルトの名無しさん:2010/09/23(木) 10:27:00
>>169
Perlのラクダ本だったかリャマ本だったか覚えてないけど、
「Perlは毎日Perlでプログラムを書く人に向いている言語です」
みたいな事が書いてあったと思う。

Rubyはその哲学を受け継いでいるような気がするし、Railsもそうだと思うな。
俺の感覚的には、Pythonは慣れれば慣れるほど使いにくくて、Rubyは逆。
Rubyは初めは文法とかがややこしめで難しいが、わかってくると使いやすくなる。
Pythonは初めは簡単だが、いつまでも簡単で冗長な方法に縛られる。

174 :デフォルトの名無しさん:2010/09/23(木) 10:29:00
慣れたらインデントしないの!?

175 :173:2010/09/23(木) 10:31:15
>>174
え?何の話??w

176 :デフォルトの名無しさん:2010/09/23(木) 10:33:41
慣れるとコーディングが汚くなるんでしょ

177 :173:2010/09/23(木) 10:38:23
>>176
慣れても初めに学んだ以上に綺麗に書けないってのはあるけど、
インデントはするよ。当たり前でしょw
ってか、インデントとか局所的な話じゃなくて、ライブラリとか含めた言語全体から
受ける感覚を173に書いた。

あと綺麗に書くというのは超絶技巧という意味ではなくて、普通に読みやすいコードのこと。

178 :デフォルトの名無しさん:2010/09/23(木) 10:49:21
>Pythonは初めは簡単
俺の感覚だと、Pythonは最初のとっつきはそんなに良くないような

例えばgroovyあたりは、慣れている人は
10.times { println it }

(0..<10).each { println it }
と書くかもしれないけど、C風のベタなforループでも書けるので
少なくともC系言語ユーザにとっては入りやすい

Pythonではベタなforループは書けないし、書くなら
for i in range(10): print i
こうだが、groovyの例に比べると、なんだか抽象度が低くて汚い

179 :173:2010/09/23(木) 10:54:06
>>178
あーなるほど。でも、C知ってればシェルスクリプトも知っててすぐわかるような。
あとJavaの拡張for知ってればイチコロだよな。

http://shugo.net/jit/20080114.html
> RubyもRailsも、もともと初心者が何も考えずにプログラムを書ける
> ように作られているわけではない。 CやLispやJavaでもちゃんとした
> プログラムが書ける人が、もっと楽にプログラミングできるように
> 作られているだけだ。見かけの簡単さにつられてプログラムを
> 書きはじめた初心者の周りでは色々な問題が起こる。

これよ。まあPythonもそこまで初心者にやさしくしようって考えはないと思うけどな。
Python3で大量に導入された遅延評価オブジェクトとか考えると。

180 :デフォルトの名無しさん:2010/09/23(木) 11:02:41
>>179
まあfor..inはただの一例なんだけどね
っていうかコレクションに対して for x in xs と書くのは普通に受け入れやすいと
思うんだが、こういうものにrange()を使うってのはナンジャコリャな感じを
受けたよ
メソッドの扱いなどもそうだが、Pythonの作法にはわりと独自のノリがあって、
入りにくいように思った

要は「やさしい」かどうかより「独自のノリ」だと思うな
Pythonの参入障壁は

181 :デフォルトの名無しさん:2010/09/23(木) 11:32:52
inだとかしばらく使わないとすぐ忘れるような構文なんかいらんわ
ま、このスレの言語自体いらないんだけどね

182 :デフォルトの名無しさん:2010/09/23(木) 11:36:23
shのインパクトは忘れられないよな
あれだけ変態だと逆に一発で覚えられる

183 :デフォルトの名無しさん:2010/09/23(木) 12:34:23
>>139
ls.reverse()はls自体を並べ替えろっていう「命令形」。
reversed(ls)はls自体を並べ替えるんでなく、逆順に並べ替えたlsをくれって関数。完了形。

184 :デフォルトの名無しさん:2010/09/23(木) 13:12:30
>>183
Rubyなら
・ls.reverse!()  <-- reverse!()は命令
・new_ls = old_ls.reverse()  <-- reverse()は関数
になるけど、こちらのほうが自然だろってことかな。それなら自分は納得だけど。

185 :デフォルトの名無しさん:2010/09/23(木) 13:22:30
>>183
細かいことだが、reversedって完了形というより過去分詞/受動態じゃないの?

>>184
命令/関数云々というより、単に破壊的操作には!をつけるという
Lisp系の命名規則の影響と思われ
自然というか、少なくとも分かりやすいね

186 :デフォルトの名無しさん:2010/09/23(木) 13:47:42
>>169-172
Djangoは良いよ

187 :デフォルトの名無しさん:2010/09/23(木) 13:52:46
>>178
map(sys.stdout.write, map(str, range(10)))

188 :デフォルトの名無しさん:2010/09/23(木) 13:54:44
>>185
受動態じゃなくて過去分詞の副詞的用法

189 :デフォルトの名無しさん:2010/09/23(木) 13:55:53
ああすまん
過去分詞の形容詞的用法


190 :デフォルトの名無しさん:2010/09/23(木) 14:10:58
>>187
10.times { println it }
に比べて冗長・複雑な上に無駄にリストを生成して返す

何のいいところも無いよね

191 :デフォルトの名無しさん:2010/09/23(木) 14:15:16
>>190
generator だから無駄なリストは作らない

192 :デフォルトの名無しさん:2010/09/23(木) 14:15:55
ああPython3か
2.X系だとリストを返すけどな

193 :デフォルトの名無しさん:2010/09/23(木) 14:26:05
Pythonはlambda式がアレなのが痛い
>>187なんて
map(lambda x: print x, range(10))
でいいのにそう書いてないのは、つまりlambdaを書きたくないんだろ


194 :デフォルトの名無しさん:2010/09/23(木) 14:29:01
python3だったら
list(map(print, range(10))) とかにしないと表示しないね

俺は 10.time { ... よりも for .. in iterable の方が覚えること少なくて好きだなぁ

195 :デフォルトの名無しさん:2010/09/23(木) 14:30:11
っていうか、lambdaの中にprint書きたくても書けないんだったなそういえば

196 :デフォルトの名無しさん:2010/09/23(木) 14:34:21
>>185
そうだね。「自然」よりも「分かりやすい」のほうが適切な表現だ。

あと、リストの逆転という操作について、
・rubyだとreverse関数はリストという抽象化データに付属する(=リストクラスのメソッドである)
というイメージなんだけど、
・pythonだとreverse関数はトップレベルの関数として定義されている
ことが、(rubyに慣れた人には)違和感がある、ってことも思った。

rubyにもトップレベルで定義されているメソッドは数多くあるけど、reverseはリスト操作なんだから、
トップレベルで定義するのは変じゃね?って感じ。

197 :196:2010/09/23(木) 14:36:16
自己レスで訂正。>>196中の reverse は間違い。reversed が正しい。

198 :デフォルトの名無しさん:2010/09/23(木) 14:52:55
>>196
まあRubyもトップレベルでいいのかそれ?と思う関数あるけどな。
ただ、Perlの次を目指して作られたって経緯を考えれば
なるほどトップレベルだなという関数が多い

199 :デフォルトの名無しさん:2010/09/23(木) 15:18:45
>>195
printは文だからね。
3では関数になるので、lambdaの中でも使える。

2.6とかで、
from __future import print
とかでも使える。

200 :デフォルトの名無しさん:2010/09/23(木) 18:58:09
>>197
混乱してるな

201 :デフォルトの名無しさん:2010/09/23(木) 19:07:12
>>198
確かに、書き捨て用途なんかも考慮した
ショートカットなんだろう。Kernel#openとかさ

202 :デフォルトの名無しさん:2010/09/23(木) 19:32:41
>>198
rubyはsmalltalkを目標にオブジェクト指向を徹底した言語設計で、
作者も著書で「perlの皮を被ったsmalltalk」と語っている。
ブロック(クロージャ)の扱いが、その典型例。

それに対して、pythonはそもそもオブジェクト指向言語として設計されておらず、
後付けでオブジェクト指向が追加された、という印象がある。

203 :デフォルトの名無しさん:2010/09/23(木) 20:25:22
>>202
> それに対して、pythonはそもそもオブジェクト指向言語として設計されておらず、
> 後付けでオブジェクト指向が追加された、という印象がある。
というか、印象ではなくて、それは事実。

今でこそ、組み込みオブジェクトとユーザークラスのオブジェクトの間に差はなくなっているけど、
2.1までは別物だったわけで。
2.3で新クラスが導入されるまではclassについてもメソッド探索の仕方に、あまり適切とは
いえない部分があったりもしたし。

ただ、それがPythonの欠点になりうるとは、正直思ったことないな。
Rubyがそういった点において、Pythonに優位に立てる、というのであれば、
それは詳しく説明して欲しいなw

204 :デフォルトの名無しさん:2010/09/23(木) 20:36:16
>>203
Pythonは知らないから、Rubyの優位性とかは分からんし、そんな事は言っていない。
ただ、オブジェクト指向言語として徹底されているから、
一貫性のあるオブジェクト指向プログラミングが可能になるね、ということ。

具体例は、>>196。純粋なオブジェクト指向言語であれば、list.reverse という
リストオブジェクトへ反転メッセージを送るというスタイルになる。
トップレベルのメソッドはシステムへのメッセージだけ。
(Smalltalkの場合は、トップレベルどころか、Smalltalkオブジェクトヘ
 メッセージを送るという形式しか許されておらず、Ruby以上に徹底されている)

でも、Pythonは、そうじゃないみたいだね、って話。それが欠点とは言っていないよ。

205 :デフォルトの名無しさん:2010/09/23(木) 20:37:22
>>203-204
Rubyが遅い理由にはなっているな

206 :デフォルトの名無しさん:2010/09/23(木) 20:38:40
>>204
python の list.reverse は文字通りに動作してる訳だけど?

207 :デフォルトの名無しさん:2010/09/23(木) 20:40:44
>>204
混乱してるのはお前の頭だ

208 :デフォルトの名無しさん:2010/09/23(木) 21:09:16
>>205
その通り。Rubyは実行効率という代償を払って、純粋オブジェクト指向を得た言語。

>>206
もしPythonがオブジェクト指向を導入した時にオブジェクト指向の徹底を判断していれば、
トップレベルのreversedは削除されていたはず。
ただし、繰り返すけど、それがPythonの欠点とは言っていない。
一般的に関数型言語ではリスト処理関数はトップレベルで定義されているから、
Pythonはその流儀を導入したのではないかと想像している。(間違ってたら指摘してくれ)

オブジェクト指向を徹底させなかったのはPythonの設計方針であるし、
それで満足するか不満に思うか、あるいは徹底/非徹底を基準にどちらの言語を選択するかは、
利用者の「好み」の問題でしかない。

>>207
論理的には反論できないので、悔しくて1行レスで人格批判ですか?

209 :デフォルトの名無しさん:2010/09/23(木) 21:17:15
>>208
だから、後から追加されたのはreversed()の方なんだってばw
つまり、Pythonがよりオブジェクト指向を徹底するのであれば、
例えばlist.reversed()と書けるようにするべきだった、ということかい?

現実的に、reversed()がトップレベル関数だということで、他の言語に
くらべて、不便がある、とか、そういう話があるとも思わないしな…
例えば、それで有利になる面があるよ、ってことをいってもらわないと、
単にそれは、宗教的理由にしか見えないし、ああ、そうですか、って
言う他はないのだが。

210 :デフォルトの名無しさん:2010/09/23(木) 21:35:41
>>209
>だから、後から追加されたのはreversed()の方なんだってばw

あれ、そうなんだw 知らなんだ。なぜ後付けする必要があったんだろうか。

>例えばlist.reversed()と書けるようにするべきだった、ということかい?

そう。もし名前が(reverseと)混乱しやすいのなら、list.make_reversing() とか
破壊的操作であることが一目で分かる名前にすればいい。

>例えば、それで有利になる面があるよ、ってことをいってもらわないと、

システム設計では、個々の機能の優劣よりも「一貫性」のほうが大切。無秩序な増築は望ましくない。
ただ、この話は抽象的な設計論だから、自分の技術力では、具体例は示すことができない。

>単にそれは、宗教的理由にしか見えないし、

上に書いた理由で、具体例の無い議論は「宗教論」になるから、これで終わりにするよ。

211 :デフォルトの名無しさん:2010/09/23(木) 21:59:46
ただの推測だけど、sorted()やreversed()がビルトイン関数なのは
それらが任意のiterableなオブジェクトに対して利用できて、
Pythonにおけるiterableなオブジェクトというのはダックタイピング的に
特定の関数(具体的には__iter__())を持つ関数でしかなく、
継承関係などの要請が無いからだと思う。

それこそ「iterable」みたいなクラスからの継承を強制させるんなら
iterableに非破壊版のsort()やreverse()を持たせることが可能で
少なくとも非ダックタイプで継承ベースのOO言語ならそれが普通の設計だろうけど、
継承を強制させるってことは、今の仕様より制限がキツくなるでしょ

212 :211:2010/09/23(木) 22:00:17
×特定の関数(具体的には__iter__())を持つ関数でしかなく、
○特定の関数(具体的には__iter__())を持つオブジェクトでしかなく、


213 :デフォルトの名無しさん:2010/09/23(木) 22:02:19
>>211
同意だな。
reversed(),sorted()はオブジェクト指向というより、ジェネリック指向ってことだね。

214 :211:2010/09/23(木) 22:05:22
>>213
うん、一言で言えばそうだよね
C++のSTLに似てる、あっちもiteratorベースのジェネリックアルゴリズムだし

215 :デフォルトの名無しさん:2010/09/23(木) 22:14:48
>>210
>そう。もし名前が(reverseと)混乱しやすいのなら、list.make_reversing() とか
>破壊的操作であることが一目で分かる名前にすればいい。

破壊的操作なのは reverse の方な
マジボケなのか釣りなのかはっきりしてもらいたいものだ


216 :デフォルトの名無しさん:2010/09/23(木) 22:22:51
Rubyの場合、モジュール(module)と呼ばれる構文要素でジェネリック指向を実現しています。
具体的には、sort/sort!/reverse/reverse!は、リスト(正確にはArray)クラスのメソッドではなく、
モジュール Enumerable 内で定義されているモジュール関数(総称関数)であり、
リストクラスでは、このEnumuerableモジュールをMix-inで継承しています。

ジェネリック指向ですから、列挙的なアクセスが可能なクラスであれば、
eachメソッドを定義してEnumerableモジュールをMix-inしさえすれば、
Enumerableモジュールで定義されたすべてのメソッド(sort/sort!...etc)が利用可能になります。

217 :デフォルトの名無しさん:2010/09/23(木) 22:27:47
>>216
pythonでいうと、EnumerableモジュールのMix-inを要求されないんだな。
eachメソッドさえあれば、sorted()やreversed()は使える、ってこと。

なんだか、かっちりしてんのはrubyの方、みたいな話になってきたなw

218 :デフォルトの名無しさん:2010/09/23(木) 22:55:46
>>215
マジボケですた ........orz

というか、pythonの命名がまぎらわしすぎ!、などと責任転嫁してみる

219 :デフォルトの名無しさん:2010/09/24(金) 02:57:40
>>218
Ruby と逆だから Ruby に慣れてる人は混乱するんだよな

220 :デフォルトの名無しさん:2010/09/24(金) 06:45:09
>>208
> もしPythonがオブジェクト指向を導入した時にオブジェクト指向の徹底を判断していれば、
> トップレベルのreversedは削除されていたはず。

reversedがトップレベルかどうかは関係ないよ。
reversedが関数であってメソッドじゃないという点が大事。
rubyのは破壊的操作も破壊的じゃない操作もメソッドだけど、
pythonは破壊的なものはメソッドでそうでないものは関数になってる。
だからreverseはメソッドだけどreversedは関数。
オブジェクト指向的にはもちろんrubyのほうが徹底しているけど
pythonもそういう観点からみると徹底している。

>>203
なんでpythonな人はすぐにrubyとの優劣に話をもっていこうとするんだろうね。
たんにrubyとpythonの違っている点を話しただけなのに、
> Rubyがそういった点において、Pythonに優位に立てる、というのであれば、
> それは詳しく説明して欲しいなw
とかきもいわ。


221 :デフォルトの名無しさん:2010/09/24(金) 07:31:01
>>220
>たんにrubyとpythonの違っている点を話しただけなのに、
>> Rubyがそういった点において、Pythonに優位に立てる、というのであれば、
>> それは詳しく説明して欲しいなw
>とかきもいわ。

あほか


222 :デフォルトの名無しさん:2010/09/24(金) 07:33:49
皮肉だよな

223 :173:2010/09/24(金) 16:01:11
>>208
> その通り。Rubyは実行効率という代償を払って、純粋オブジェクト指向を得た言語。
適当なこと書くな。RHG読んで出直してこい。RubyのオブジェクトモデルがPythonのオブジェクトモデルより、
スピードの面で不利なところはほぼない。しかし、俺は詳しくないがC++等と比べればたくさんあるだろう。

>>220
> pythonは破壊的なものはメソッドでそうでないものは関数になってる。
そんなルールないでしょ。たまたまそういうのが多いだけ。だって+とか-とかの演算子どうなる?
__getitem__()とかもメソッドよ。

Pythonの関数はポリモーフィックと関連がある。例えば、list.reverse()はリスト専用だが、
__builtins__.reversed()はシーケンス型すべてに使える。

Rubyにはモジュールがあるから、例えば、mapは、Enumerableをシーケンス系の
クラスすべてにインクルードさせることで、どのシーケンスでも使えるようにしている。
Pythonのmap()(あまり使わないけど)は関数として独立させ、シーケンスプロトコルを
満たすすべてのオブジェクトを受けることで、Rubyのモジュールと同じようなことができるようになっている。

この仕組みのどちらが優れているかはなんとも言えない。Rubyの方がメソッドを呼ぶ側としては、
一貫性があってわかりやすく、またオブジェクト指向っぽいのはいい一方、
クラスが肥大化(Ruby哲学らしい)し、名前空間的に問題があるからだ。

あと、勘違いしている人が多いが、Rubyの!は使うのに注意を促すメソッドであり、
必ずしも破壊的なメソッドにつけるわけではない。逆にいうと破壊的なメソッドであっても!が
つかないメソッドは腐る程ある。

俺がreversed嫌っていったのはあくまで命名規則。reversedのように過去分詞形になっている関数は
他に殆ど目にすることがない。

Rubyに慣れきっているとPythonキモいと思うところはたくさんあるが、そういうのはできるだけ
目をつむり、どちらの言語にも慣れているときにどっちの方がどれだけキモい、キモくないのか、
また、使いやすいのかを考えるようにして書いてる。当たり前のことだけど。

224 :173:2010/09/24(金) 16:15:52
スレに張り付きすぎてて、言語の前に自分がキモくなってきたからそろそろROMるが。

>>204
オマイは>>208なのかな。
> Smalltalkの場合は、トップレベルどころか、Smalltalkオブジェクトヘ
> メッセージを送るという形式しか許されておらず、Ruby以上に徹底されている
RubyのトップレベルのselfはObjectクラスのインスタンスで間違いなくRubyオブジェクト。
その点ではSmalltalkと同じぐらい徹底してます。

Smalltalkの方が徹底してるのはif-else等の制御構造等もメッセージ送信でやるところ。

もし>>208なら俺と一緒にROMれ。一見詳しそうに見えて、間違ったこと書くのは
本人にその気がなくても極めて害悪。初心者の悪影響にしかならない。

> 論理的には反論できないので、悔しくて1行レスで人格批判ですか?
しかも何これ。お前の書く言葉じゃない。1行レス人格批判の方が多いにマシです。

225 :デフォルトの名無しさん:2010/09/24(金) 17:57:37
最近Scalaが気になるからScalaも混ぜて話してみてくれ

226 :デフォルトの名無しさん:2010/09/24(金) 18:47:38
reversedみたいなのを関数にするかメソッドにする(オブジェクトに属させる)かについては、
リスコフがCLUの設計の段階でも悩んでいて、結局、効率をとって前者にしたという経緯があります。
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf

別の見方をするならば、
抽象データ型(念のため、リスコフはこれの発案者)という大枠では、どちらにしてもよいわけです。よって、
Pythonはその混在状態で、Ruby(というか、そのネタ元のSmalltalk)はメッセージングというコンセプトに
マッチするので、効率面で多少苦労しても後者に統一したというだけの話でどちらが偉いと言うことは
ないと思います。

Scala は知らん。

227 :デフォルトの名無しさん:2010/09/24(金) 19:10:03
本筋と関係ないけど、発案者っていうより、まとめた人じゃないの?

228 :デフォルトの名無しさん:2010/09/24(金) 20:45:51
抽象データ型やデータ抽象というのは、型によるモジュール化手法で、これは正真正銘
リスコフの発案だよ。その後、勝手定義がはびこったので、それらと混同しているのでは?

229 :デフォルトの名無しさん:2010/09/24(金) 21:25:54
なるほど、勘違いしてました
そういう概念は以前からあったんではないのかな、と思ったのだけど
総称型的な機能を取り入れた最初の言語がCLUなのか

230 :デフォルトの名無しさん:2010/09/24(金) 21:48:20
CLUはなぜ消えてしまったのか

231 :デフォルトの名無しさん:2010/09/24(金) 22:29:05
>>223
>RubyのオブジェクトモデルがPythonのオブジェクトモデルより、スピードの面で不利なところはほぼない。

いくつかあるけど、具体例を2つ挙げる。
・Rubyにはメソッド呼び出しのたびにクラス継承ツリーに沿ってメソッドを動的に探索するオーバヘッドがある。
 Pythonのように関数であれば、動的な探索は不要。
・Pythonでは可変(mutable)なデータ型と不変(imutable)なデータ型を言語仕様で明確に分離している。これは、
 Rubyの(freezeメソッドによる)動的な可変性と比較して、処理効率(アルゴリズム)とメモリ効率の面で優位。

>>224
>> Smalltalkの場合は、トップレベルどころか、Smalltalkオブジェクトヘ
>> メッセージを送るという形式しか許されておらず、Ruby以上に徹底されている
>RubyのトップレベルのselfはObjectクラスのインスタンスで間違いなくRubyオブジェクト。
>その点ではSmalltalkと同じぐらい徹底してます。

この(>>204の)文脈で述べているのは、(送信先オブジェクトに関してではなく、)メッセージ送信の構文について。
Smalltalkの文法では送信先メッセージを明示的に指定する必要がある。システムへの送信は、"Smalltalk" という
名前のクラスオブジェクトを「常に」指定しなければならない。それに対してRubyでは、メッセージ送信先を
省略可能にする(意味論的に曖昧な)文法を採用することで、ユーザからはメッセージ送信があたかも関数呼び出しで
あるかのように見せ、(Perlのような)手続き指向に慣れ親しんだユーザの移行障壁を軽減させた。

誤解をまねかないよう長い説明になったけど、>>204はあまりに短縮しすぎたかもしれない。しかも蛇足だ。反省。

>もし>>208なら俺と一緒にROMれ。

ROMする/しないは個人の自由。ROMるのはお一人でどーぞ。それを押し付けられる(強要される)のは、ご免こうむる。

232 :デフォルトの名無しさん:2010/09/24(金) 22:45:20
レキシカルスコープは理解できるんだが
静的スコープと書かれると、直感的に認識できない。

233 :デフォルトの名無しさん:2010/09/24(金) 22:55:11
>>231
> 手続き指向に慣れ親しんだユーザの移行障壁を軽減させた。

そんなふうに書くと、Matz が狙ってそれを発明したように誤解するる厨がいるかもしれないから
念のため補足しておくけれど、self を省略できる文法はべつに Matz の発明でもなんでもなくて
その名も SELF という言語にすでにあったから。

これに限らず Matz の場合、無知から来る再発明やミスリードを狙うことあっても、発明はない。
これマジ知識な。

234 :デフォルトの名無しさん:2010/09/24(金) 22:55:12
このスレちょっと前は過疎ってる気がしてたけど
きゅうに盛り上がったな

235 :デフォルトの名無しさん:2010/09/24(金) 23:19:15
自演で盛り上がったとは是如何に

236 :デフォルトの名無しさん:2010/09/24(金) 23:54:33
>>233
えーと、>>231では、selfの省略がMatzの発明とは、どこにも書いてないんだけどね。
ミスリードを誘っているかのような書き方は、相手に対して失礼だと思うよ。

RubyについてMatz自身は著書の中で「Perlの皮を被ったSmalltalk」と語っている。
実際、Perlの文法とよく似ているし、ブロック(クロージャ)の書き方はSmalltalkとほとんど同じ。
更にオプション値の指定可能な仮引数宣言はAda譲りだし、Mix-inはLISPで生まれたアイデア。
ちなみに、Rubyのイテレータや例外処理についても、本人が以下のルビマの中で、
CLUの影響を受けたとはっきり語っている。

・Rubyist Magazine - Rubyist のための他言語探訪 【第 2 回】 CLU
  http://jp.rubyist.net/magazine/?0009-Legwork

個人的には、Matzの素晴らしさは、これら既存の言語の優れた要素を巧みな技で見事に「組み合わせ」、
Rubyという一つの言語として「完成させた」点にあると思っている。(自分を含めて、)言語に関するウンチクを持つ、
いわゆる言語オタクは大勢いるけど、理屈先行であって、それを完成させてリリースさせることはできない。
だからこそ、Matzは評価に足る人物だと考える。逆に、

>これに限らず Matz の場合、無知から来る再発明やミスリードを狙うことあっても、発明はない。
>これマジ知識な。

といった「Matzが意図的にミスリードを狙っていた」かのような印象を与えるカキコこそ、
ミスリードを誘う「悪意に満ちた発言」であると判断する。
それは、おそらく(>>233が持つ)日本人固有の僻み/妬みに起因した「足の引っ張り合い精神」によるものだと推測する。
もし反論があるのなら、マジ知識という上の文章のソースを提示してくれ。

237 :デフォルトの名無しさん:2010/09/25(土) 00:48:39
>>236
えーと。まじキチ?

> そんなふうに書くと誤解するる厨がいるかもしれないから念のため補足 →SELF

> Matz の場合、発明はない。 →マジ知識

ここまでようやくすればいいたいことわかるでちゅか? これでも無理か!

238 :デフォルトの名無しさん:2010/09/25(土) 00:55:56
>>237
> Matz の場合、無知から来る再発明やミスリードを狙うことあっても、

この部分に関するソースを求めている。意図的な誤読はみっともないぜ。

239 :デフォルトの名無しさん:2010/09/25(土) 01:01:17
Matzの素晴らしさは、これら既存の言語の優れた要素を巧みな技で見事に「組み合わせ」、
Rubyという一つの言語として「完成させた」点にあると思っている。(自分を含めて、)言語に関するウンチクを持つ、
いわゆる言語オタクは大勢いるけど、理屈先行であって、それを完成させてリリースさせることはできない。
だからこそ、Matzは評価に足る人物だと考える。

240 :デフォルトの名無しさん:2010/09/25(土) 01:19:38
うわぁ…

241 :デフォルトの名無しさん:2010/09/25(土) 01:23:07
>>239
坂本龍馬が似たような評価されてるね

242 :デフォルトの名無しさん:2010/09/25(土) 01:24:57
Matz儲って、ジョブズ儲に似てるね。イタすぎる。

243 :デフォルトの名無しさん:2010/09/25(土) 01:29:07
そりゃ>>239のような自称言語オタク(笑)より評価に足る人物だろうね。今そういう話してるの?
名前もない底辺と比べて素晴らしいなんて議論の余地もないよ

244 :デフォルトの名無しさん:2010/09/25(土) 01:56:43
やめようぜw

作家は作品で評価すべきであって、
プログラム言語の設計者も、設計したプログラム言語で評価すべき。

大体、プログラムでも作家でも、よい作品を出しているやつがいい人間だとか、
そんな話はないわけで。

個人的には、Guido Van Rossumの方を評価したいが、それはどーでもいー。

245 :173:2010/09/25(土) 09:32:38
>>231
Rubyにも可変と不変あるよ。数字とシンボル。Pythonタプルと不変文字列については、
まあ効率いいんでしょう。ちなみに、Rubyの文字列はconcatする分には高速よ。可変ですから。
あと、可変か不変かって純粋なオブジェクト指向と関係あるのか不明。
不変なオブジェクトって自分でも定義
できる(セッター系メソッドを定義しなければいい、idは変わるけどな)から、
不変なオブジェクトのクラスがたくさんあるPythonが純粋でないとは言えないと思うね。

Pythonの関数は、受けたオブジェクトに対してメソッドを呼び出すのが多いから、
結局メソッド読んでるのと同じ。しかも、Pythonの関数呼び出しは、最終的に
ビルトインスコープ(=モジュールオブジェクト=ディクショナリ)を探索する。
つまり動的に探索します。モジュールの関数呼び出す場合も同じ。

>>204の件はどう考えても短縮によって俺が読み違えたとは思えん。
> トップレベルのメソッドはシステムへのメッセージだけ。
うん、読めない。文法的なこといいたいなら、レシーバの省略とかそういう
言葉欲しいよね。しかも、レシーバ省略呼び出しはトップレベルだけでなく、
自クラスのメソッドを呼び出すのにも使うしな。

ROMりたくないなら別にいいっすよ。ムシャクシャして書いただけー。

ああ、そうだPythonの方が明らかに高速なものとしては、内包があったね。
Python3からは、mapとかも遅延評価オブジェクトを返すようになったんだっけ。

246 :173:2010/09/25(土) 09:35:02
×読んでる
○呼んでる
それじゃ消えます。アデュー。

247 :173:2010/09/25(土) 09:48:01
ああ、そうだ1個追加。
Pythonの関数はただのオブジェクトだから()もメソッドだった。関数オブジェクトを探索
してから、()メソッドを起動します。モデルとしてはかっこいいけど、スピード的には
良いとは思えませんね。

248 :デフォルトの名無しさん:2010/09/25(土) 12:21:22
RubyとPythonは似てるようで色々と対極なのが面白いな。
関数中心かメソッド中心か、とか
関数とメソッド、そしてフィールドの関係とか
イテレータが内部か外部か、とか

249 :デフォルトの名無しさん:2010/09/25(土) 14:03:10
>>248
内部イテレータ外部イテレータは、スタックトレース的にどっちが外かという話だから
もし並行処理でスタックが独立していたら、内部でも外部でもないイテレータになる

class中心の考え方は「並行処理はちょっと・・・」という消極的な側面がある
なのに手続きやCUI中心の考え方を見下したりする所がある

だから、class中心ではないPerlにも需要があるのだ

250 :デフォルトの名無しさん:2010/09/25(土) 15:05:51
なんか話が飛躍してないか

ってか、関数型ならともかく
Perlが「並行処理」を理由に需要があるとは知らんかったぞ

251 :デフォルトの名無しさん:2010/09/25(土) 15:39:33
CUIとパイプとワンライナーの需要だ、といったらまた見下してくるんだろうな

252 :デフォルトの名無しさん:2010/09/25(土) 16:04:24
今からPerlを使う理由はない

253 :デフォルトの名無しさん:2010/09/25(土) 16:06:19
今からPHPを使う理由はない

254 :デフォルトの名無しさん:2010/09/25(土) 16:17:01
PHPは何だかんだで使われるんじゃね、言語としては嫌いだけれど
Webアプリのサーバサイドに特化した言語ってのもそうそう無いと思う。
そういう風にも使える汎用の言語ってのはあるけどさ。

255 :デフォルトの名無しさん:2010/09/25(土) 17:00:37
おまえら元祖ワンライナーawkを忘れてないか?

256 :デフォルトの名無しさん:2010/09/25(土) 17:19:49
awkはUnix系だと色々使えるが…

257 :デフォルトの名無しさん:2010/09/25(土) 17:49:38
awkはLinuxとかでいうと、もうbusyboxにまで入っているからなw
個人的な感覚でいうと、LLというよりはもうsortやsedのような
ツールって感じw

258 :デフォルトの名無しさん:2010/09/25(土) 19:44:26
2009-07-16 (木) 22:29日記Object::Simple | perl
Perlという言語について

今時Perlなんて、という話もちらほら聞きます。

上記記事にも記載されているように「前時代的なPerl」については確かに「何もいいことないよなぁ」と思いますが、ちゃんと「今時代(?)のPerl」を学んで使えるようになることが、他のWeb言語(RubyやPHP)の習得の早さにもつながるのかなぁと思ったりします。

#なんて偉そうなこと言えるほどデキるわけじゃ全然ないし、”他のWeb言語”なんて使えないですけどね…。

Perlを覚えればかなりの面倒な作業を楽にできるということは個人的な経験からいうとほぼ正しいことです。Perlは忍者のような言語なのです。

忍者、っていう言葉がしっくりですね。そんなスタンスが更にお気に入りです。

これってUNIX言語とかシェルについての構造と同じなのかな、なんて思ったりします。「LinuxよりはSolarisに触れておこう」とか「zshよりもshから学べ」とか。

私ももっといろいろ試しながら勉強していきたいです。今日は上記サイトのObject::Simpleについて読んでみようっと。



259 :デフォルトの名無しさん:2010/09/25(土) 19:47:43
つか、Perl6ってどうなってるの?

260 :デフォルトの名無しさん:2010/09/25(土) 21:00:53
「Web言語」ってなんだよ

261 :Perl忍者 ◆M5ZWRnXOj6 :2010/09/25(土) 21:04:07
Active PerlへGOGOGO!!!!

262 :デフォルトの名無しさん:2010/09/25(土) 21:10:53
>>258
こういう勘違い馬鹿をもう再生産しないためにも
Perlは撲滅すべきなんだが

263 :デフォルトの名無しさん:2010/09/25(土) 21:18:12
>>262
まああと10年は余裕で使われると思うよ、perlは。
死ぬ死ぬいってたコボルとか余裕で生き残ってるしな。

264 :デフォルトの名無しさん:2010/09/25(土) 22:41:14
> Perlを覚えればかなりの面倒な作業を楽にできるということは個人的な
> 経験からいうとほぼ正しいことです。Perlは忍者のような言語なのです。
まあこれは真だけど、他のLLも同じだっていうね。

265 :デフォルトの名無しさん:2010/09/25(土) 22:56:39
まあ、UNIX系OSのツールだと、Perlは最大勢力だからな。最近はたまにPythonもあるけど。

266 :デフォルトの名無しさん:2010/09/25(土) 22:58:05
perlのアドバンテージったら古い鯖でも大抵入ってるって事くらいだと思う。
選べるんならpythonやらrubyのほうが、そらいいわな。

267 :デフォルトの名無しさん:2010/09/25(土) 23:26:11
PerlはWeb言語なんかじゃ無いんだけどなあ
元々テキスト処理に特化した言語だったから、Web用言語が無かった時代に
テキスト処理を多く利用するWebプログラミングに使われたってだけで

268 :デフォルトの名無しさん:2010/09/25(土) 23:29:49
>>267
昔、CGIといったら、「CGIってのはPerlで書かれているものだ!」とか言ったバカがいたなあ…w

269 :デフォルトの名無しさん:2010/09/26(日) 02:14:37
ウェブアプリでも、PHPは別格としても、その次はPerlでしょう。特に日本じゃミクシイとかDeNAとか、最大手のサイトが採用していて、非常に勢力が強い。
Rubyはクックパッドくらいしか名前聞かないし、Pythonは皆無。

270 :デフォルトの名無しさん:2010/09/26(日) 02:25:19
>>269
お前はGoogleも知らんのかw

271 :デフォルトの名無しさん:2010/09/26(日) 02:28:14
>>267
だよな
Web言語(笑)って言ったらPHPとかjavascriptみたいなのを言うんだよな

272 :デフォルトの名無しさん:2010/09/26(日) 02:40:29
>>269
君の頭が鎖国してるだけ
PHP>Ruby>Python>Perl


273 :デフォルトの名無しさん:2010/09/26(日) 02:44:58
Python on Rails

274 :デフォルトの名無しさん:2010/09/26(日) 03:13:55
どうでもいいが先頭がPなの多いな


275 :デフォルトの名無しさん:2010/09/26(日) 03:28:46
>>274
そうだよ。
だから、「P言語」みたいな言い方もされるし、
最近じゃ、LAMPのPはPythonやPerlでもいいことになってるんだw

で、一応言っとくとRubyはP言語の一つとみなされてるから、その点は安心してw

276 :デフォルトの名無しさん:2010/09/26(日) 03:40:04
Rって見方によってはPに毛が生えたようなもんだからな

277 :デフォルトの名無しさん:2010/09/26(日) 04:18:41


278 :デフォルトの名無しさん:2010/09/26(日) 11:45:33
Rubyはオブジェクト指向に対応したスクリプト言語ではなく、
スクリプティングもできる本格オブジェクト指向言語だからP言語ではない。

と言ってみるテスト。

279 :デフォルトの名無しさん:2010/09/26(日) 12:03:05
英語だとdynamic languageとかいうのかな
Perlって動的型付じゃないような気もするんだけど、どうなんすかエロい人

Perlって変数に$や@や%をつけて(値ではなく)「変数で」型を明示するよね
CやJavaよりずっと型付弱いけど、PythonやRubyのような動的型付ともまた
違う印象

280 :デフォルトの名無しさん:2010/09/26(日) 12:08:32
>>278 よく言われてることに反するけど、Rubyのオブジェクト指向って変わり種なんじゃないかな
中途半端にプロトタイプベースの機能も入ってて
オブジェクトにメソッドを追加出来るから、LSPも満たせない

281 :デフォルトの名無しさん:2010/09/26(日) 12:12:52
ttp://en.wikipedia.org/wiki/Type_system
perlはstatic typingかつdynamic typingな言語

282 :デフォルトの名無しさん:2010/09/26(日) 12:33:11
>>281
なるほどー
どうもです

283 :デフォルトの名無しさん:2010/09/26(日) 14:29:53
>>270
日本のサイトで、だから。それにGoogleの場合、ほとんどはJava、バックエンドにC++で、Pythonはごく一部でしょう。
Python使ってる日本のサイトで有名な所があるなら教えて欲しい。

284 :デフォルトの名無しさん:2010/09/26(日) 14:37:39
>>280
動的型付けだからLSPをいつも満たす必要はないと思うけど、まあ変わり種だろうね。

プロトタイブベースはどうなんだろう。どっちかっていうとプロトタイプが先で
クラスはそれを補助するものって印象。いや、違うか。わからん。

285 :デフォルトの名無しさん:2010/09/26(日) 14:44:43
>>283
なんで日本のサイトに限定するのか意味が分からん。
そんなくだらない情報知りたがるからリストラされるんだよ!

286 :デフォルトの名無しさん:2010/09/26(日) 14:47:47
plone使ってる自治体もある。君が知らないだけで世の中は広い。

287 :デフォルトの名無しさん:2010/09/26(日) 15:27:03
サイトのコンテンツ自体にPythonはあまり使われてなさそうだけど(日本)、サイト
が乗ってるサーバーの管理プログラムにはそれこそクソ使われてるだろう。
Linuxだし。

288 :デフォルトの名無しさん:2010/09/26(日) 15:35:25
youtubeはpythonじゃなかったっけ?

289 :デフォルトの名無しさん:2010/09/26(日) 16:14:41
ちょっと時間が空いたのでGoを使ってみたけどいいねこれ。

290 :デフォルトの名無しさん:2010/09/26(日) 16:25:58
yumはpython

291 :デフォルトの名無しさん:2010/09/26(日) 17:32:51
kwsk
最近新しい言語やる気力が衰えてる

292 :デフォルトの名無しさん:2010/09/26(日) 17:34:58
やる必要もないことをやろうとするからだろ

293 :デフォルトの名無しさん:2010/09/26(日) 17:35:10
歳やね
http://www.youtube.com/watch?v=ona34GVZpHg

294 :291:2010/09/26(日) 17:41:29
あ、アンカー書き忘れた>>288

295 :デフォルトの名無しさん:2010/09/26(日) 19:47:47
>>288
ttp://www.taranfx.com/what-powers-youtube

296 :デフォルトの名無しさん:2010/09/26(日) 20:11:07
>>286
WordPressやMT使ってる自治体の方が遙かに多いから。

297 :デフォルトの名無しさん:2010/09/26(日) 20:27:14
>>296
多い少ないなんて誰も言ってない
PHPがダントツ多いのは明らか

298 :デフォルトの名無しさん:2010/09/26(日) 20:34:13
初めから多い少ないって程度の話をしてるから。PHPが一番多くて、次がPerlのウェブサイトって。

299 :デフォルトの名無しさん:2010/09/26(日) 21:52:46
裾野は広い方が良い

300 :デフォルトの名無しさん:2010/09/26(日) 23:01:24
Ploneは日本ユーザ会が色々とアレでナニなんで
一見死んだコンテンツのように見えるけど
結構底力あって意外と日本でも導入実績あったりする。

地味に活躍してるって表現かな。

301 :デフォルトの名無しさん:2010/09/26(日) 23:02:44
Plone と Pylons はどう違うんだ?

302 :デフォルトの名無しさん:2010/09/26(日) 23:17:09
5文字と6文字

303 :デフォルトの名無しさん:2010/09/27(月) 02:31:52
yが入ってeがsに変わってる

304 :デフォルトの名無しさん:2010/09/27(月) 02:41:24
それを正規表現で書くとどうなりますか?

305 :デフォルトの名無しさん:2010/09/27(月) 02:46:21
s/Plone/Pylons/

306 :デフォルトの名無しさん:2010/09/27(月) 21:32:50
PHPは最近のはフレームワークもしっかりしてきてるし
言語機能も強化されつつあるしまあいいんだけど
一昔前のは本当にひどかったからなあ。
echo "<HTML>"とか出てきたら窓から放り投げたい。perlCGIはいわずもがな。

307 :デフォルトの名無しさん:2010/09/27(月) 21:40:05
意味が分からん

308 :デフォルトの名無しさん:2010/09/27(月) 21:46:01
>>307
わからん方がいい
関わらん方がいい

309 :デフォルトの名無しさん:2010/09/28(火) 03:50:50
>>220
>なんでpythonな人はすぐにrubyとの優劣に話をもっていこうとするんだろうね。

そんなの、Rubyの人気に嫉妬してるからにきまってんだろwwwww
海外ではPythonのほうが人気が高い、海外ではPythonのほうが広まってる、海外ではPythonのほうが・・・
とうわ言のように繰り返すのがPythonistaの意地だからwwww

310 :デフォルトの名無しさん:2010/09/28(火) 05:02:46
禿しく銅でもいい

311 :デフォルトの名無しさん:2010/09/28(火) 09:07:06
>>231
>いくつかあるけど、具体例を2つ挙げる。
>・Rubyにはメソッド呼び出しのたびにクラス継承ツリーに沿ってメソッドを動的に探索するオーバヘッドがある。
> Pythonのように関数であれば、動的な探索は不要。

Pythonの関数には、単にメソッドを起動するだけのものも多い。
len(x)はx.__len__()を、str(x)はx.__str__()を起動する、とかね。
この場合、関数呼び出しに加えてメソッド呼び出しが行われるため、メソッド呼び出しだけですむRubyより効率が悪い。

>・Pythonでは可変(mutable)なデータ型と不変(imutable)なデータ型を言語仕様で明確に分離している。これは、
> Rubyの(freezeメソッドによる)動的な可変性と比較して、処理効率(アルゴリズム)とメモリ効率の面で優位。

これはほとんど処理速度に関係ないよ。

それより、Pythonはメソッド呼び出し事にbound methodオブジェクトをいちいち作ってるから
メソッド呼び出しの効率は良くない。
あとPythonは正規表現ライブラリがトロい。なんとかしてくれ。
RubyはGCが弱い。文字列リテラルが毎回オブジェクトを作成する言語仕様んだから、
GCがもっと優秀であってほしい。

312 :デフォルトの名無しさん:2010/09/28(火) 22:27:28
なんかこういう話題みてると、
プレステ持ってる子とセガサタ持ってる子のケンカを思い出すんだよな。
「サターンの方がCPUが2コ入ってるんだぞ!」みたいな。

313 :デフォルトの名無しさん:2010/09/28(火) 23:35:21
というかRuby厨にさんざん喧嘩売られてPythonistaが過敏になってしまっただけでしょ

314 :デフォルトの名無しさん:2010/09/28(火) 23:42:26
>>312
ゲハも宗教論争だからな。同じようなものだ

315 :デフォルトの名無しさん:2010/09/29(水) 00:11:24
“時給11万2000円のアルバイト”に10万人超えの応募が殺到
http://headlines.yahoo.co.jp/hl?a=20100921-00000031-oric-movi

316 :デフォルトの名無しさん:2010/09/29(水) 00:12:26
誤爆スマソ

317 :デフォルトの名無しさん:2010/09/29(水) 01:38:01
気にするな。
宗教関係の戦争中らしいから、誤爆なんて大した事無い。

318 :デフォルトの名無しさん:2010/09/29(水) 04:28:35
ソースコードで発見した奇妙なコメント集
http://www.webcreatorbox.com/webinfo/comments-source-code/

319 :デフォルトの名無しさん:2010/09/29(水) 08:26:37
暴れてた奴ははRubyの評判を落とそうと意図的にやってただろどう見ても

320 :デフォルトの名無しさん:2010/09/29(水) 08:40:02
Ruby厨はガチ

321 :デフォルトの名無しさん:2010/09/29(水) 15:26:55
mixinが無い時点でPHPはかなり分が悪い。

322 :デフォルトの名無しさん:2010/09/29(水) 15:28:44
Python(2.3以降)みたいな多重継承があればいいんじゃない?
あるかどうかは知らないけど。

323 :デフォルトの名無しさん:2010/10/01(金) 09:07:41
>>311
>この場合、関数呼び出しに加えてメソッド呼び出しが行われるため、メソッド呼び出しだけですむRubyより効率が悪い。
これは一般論としては正しくない。
リストやタプルや辞書といった、利用頻度の高い組み込み型についてはスロットの形になってるから、
一々メソッド探索が行われないので関数の方が速い。
非組み込み型の場合でも、200ナノ秒と400ナノ秒とかその程度の差。

In [3]: class Foo(object):
...: def __len__(self):
...: return 5
In [4]: foo = Foo()
In [5]: %timeit foo.__len__()
1000000 loops, best of 3: 207 ns per loop
In [6]: %timeit len(foo)
1000000 loops, best of 3: 426 ns per loop

In [7]: arr = range(100)
In [8]: %timeit arr.__len__()
10000000 loops, best of 3: 177 ns per loop
In [9]: %timeit len(arr)
10000000 loops, best of 3: 95.9 ns per loop

RubyとPythonの速度に影響する言語仕様としては、Pythonだと属性で済ませるところがRubyだと一々アクセサメソッドに
なっているとか、Rubyだと組み込み型のメソッドを変更可能だからメソッド探索を真面目にしないといけないとかかな。

324 :デフォルトの名無しさん:2010/10/01(金) 14:29:19
メソッド探索は速度に影響するかも知れんが、アクセサメソッドは大して影響ないだろ。
呼び出し自体のオーバーヘッドなんて無視できるレベル。
Pythonのメソッド呼び出しはいちいち属性から関数オブジェクトを引っ張ってくるから
速度に影響する!と言ってるレベルの負荷でしか無いと思われ。

325 :デフォルトの名無しさん:2010/10/01(金) 19:39:03
ちょっと聞きたいんだが、この表現は正しいの?

>無名関数はクロージャとも呼ばれ、 関数名を指定せずに関数を作成できるようにするものです。

>クロージャはラムダ関数,無名関数と呼ばれることもあります。無名関数の名前の通りクロージャは名前が無い関数を定義して利用します。


326 :デフォルトの名無しさん:2010/10/01(金) 20:12:40
PHPのマニュアルに書いてあるのか
なら、PHPの中ではそうなんでしょう
各言語ごとに独自の意味を持つ語って一杯あるよ

327 :デフォルトの名無しさん:2010/10/01(金) 20:52:22
PHPでは無名じゃない普通の関数はクロージャじゃないの?

328 :デフォルトの名無しさん:2010/10/01(金) 21:16:08
むしろ名前が付いてるか付いていないかはこの場合問題ではない

329 :デフォルトの名無しさん:2010/10/01(金) 21:29:40
>> 323
> これは一般論としては正しくない。
いや正しいだろ、一般論としては。
"一般論としては正しいが、組み込み型の場合のみ当てはまらない" ということでしょ。

それから311が書いてるように、Pythonはメソッド呼び出しごとにMethodオブジェクト(かなんかそんなの)
をいちいち作成しているから、メソッド呼び出しは遅いよ。

あと231が主張するようにメソッド呼び出しより関数呼び出しのほうが高速だから
RubyよりPythonのほうが速いというなら、関数だらけであるPHPのほうが速いだろうね。


330 :デフォルトの名無しさん:2010/10/01(金) 21:34:27
魅力的なPython: PsycoでPythonの実行速度をCと同等にする
http://www.ibm.com/developerworks/jp/linux/library/l-psyco/

これは?

331 :デフォルトの名無しさん:2010/10/01(金) 22:58:37
>>329
何が一般かについては共通認識が取れそうにないが、少なくともlenについては __len__ メソッドを
実装したクラスに対して実行されるよりも圧倒的にリストやタプルなどの組み込み型に対して使われる
方が多いから、len()が関数であることがPythonで書かれたアプリケーションを遅くしている訳ではない、
というのは同意してもらえる?

ユーザー定義クラスのメソッド呼び出しはPythonの方がオーバーヘッドが大きいという点については同意する。

phpやRubyがPythonより遅いのには、メソッド呼び出しコストなんかよりも全然違う部分が原因だと考える。

phpは連想配列と配列が一緒になっているとか、関数のインタフェースが練られていなくて余計な処理が
入りがちなのがダメ。例えばPythonならdict.setdefaultで「無ければ挿入」をハッシュテーブルの探索
一回でできるのに、phpだとissetと$arr[$key] = $default_val; で2回探索しないといけない。
Webアプリだと、クラスや設定値などリクエスト間で再利用できるモノも毎回開放して初期化してしまうのが
致命的に遅いし、phpプログラマにはphpの実装自体に興味を持たない人が多いのも問題。

RubyはGCが遅いのと、メソッドチェーンのように余計なオブジェクトを大量に生成してしまう非効率な書きかたを
許容する文化があることが問題。
Pythonだと実行効率と可読性を両立する書きかただけをPythonicとして推奨している。

332 :デフォルトの名無しさん:2010/10/01(金) 23:01:05
>>331
> __len__ メソッドを実装したクラスに対して実行されるよりも
> 圧倒的にリストやタプルなどの組み込み型に対して使われる方が多い

えっ…俺、コンテナ系のクラスとかよく作るんだが…

333 :デフォルトの名無しさん:2010/10/01(金) 23:21:33
>>332
コンテナ系のクラスを作ったとしても、アプリケーションでタプルやリストに比べてその
コンテナクラスを使う事の方が多くなるケースは稀じゃない?

それと、Pythonだとコンテナクラスを作るときに組み込み型を継承して実現できるならそうする
事が推奨されていて、やはり __len__ は自分で実装した物じゃなくて基底の組み込み型の
メソッドが使えることが多い。

というかlenがアプリケーションを遅くするほど呼び出されまくるなんてケースがそもそも考えにくい。

334 :デフォルトの名無しさん:2010/10/02(土) 01:04:50
> len()が関数であることがPythonで書かれたアプリケーションを遅くしている訳ではない、
> というのは同意してもらえる?

なぜ同意を求める?
「len()が関数であるせいでPythonで書かれたアプリケーションが遅くなる」なんて
だれも言ってないよね。
せいぜい、「メソッド呼び出しより関数呼び出しのほうが速いからRubyよりPythonの
ほうが速いんじゃね?」という程度のこと。おまえはまるきり逆に読み違えてる。
ほんと人の話を読まないやつだな。
今話しているのは>>231から始まった話だ。もう一回読み直せ。

> phpやRubyがPythonより遅い

まーたPython使いが根拠のないデマを語りだしたよ。うぜー。
その3つなら速度の違いは大してないだろ。


335 :デフォルトの名無しさん:2010/10/02(土) 01:47:43
Rubyは遅い

336 :デフォルトの名無しさん:2010/10/02(土) 01:48:27
>>334
おまえRubyなめんな
Rubyだけは桁違いに遅い

337 :デフォルトの名無しさん:2010/10/02(土) 01:50:38
Ruby2.0でどうなるかだが、まだまだ先だしなー

338 :デフォルトの名無しさん:2010/10/02(土) 02:40:56
>>337
1.9でもマイクロベンチマークの結果は
おおむね1.8系の2倍ぐらいにはなってるんだけどね
そろそろYARVの最適化オプションも有効にされ始めてるらしいから、
もう少し伸びるかも。あるいは他の処理系が頑張るかも

今のところ本家Ruby1.9.2が早い。JRubyもなかなか
RubiniusやMagLevも良くなってきてるから、今後注目という辺りか

The Great Ruby Shootout
http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/

339 :デフォルトの名無しさん:2010/10/02(土) 04:50:21
●●が2倍おいしくなりました(当社比)
みたいな

340 :デフォルトの名無しさん:2010/10/02(土) 04:54:38
1.9.2使ってみたが、確かに早くなってるな。


341 :デフォルトの名無しさん:2010/10/02(土) 12:15:26
>>334
言語自体の速度の違いは、Ruby 1.9 の登場でほとんどなくなったよ。

でも、>>331に書いている理由でphpのWebアプリはホント重い。requireの平均時間がAPC有効で
0.2msとして、フレームワーク使うと100クラスロードして20msかかるとかザラ。
秒間数十リクエストなら良いけど、数百〜数千リクエストのWebサイトはPythonの何倍もWeb
サーバー用意しないといけない。

Rubyで無駄なオブジェクトを生成する書きかたが許容される文化なのに対して、Pythonは
簡潔さと実行効率を兼ねそろえた書きかたじゃないと「この書きかたはPythonicじゃない」って
否定される文化を持っているのも変わらない。

342 :デフォルトの名無しさん:2010/10/03(日) 15:25:21
Pythonは来年には消えてるだろ

343 :デフォルトの名無しさん:2010/10/03(日) 17:41:19
いやそれはあり得ないから。
少なくともLinux界では今Python抜くと酷い事になる鳥が結構あるぞ。

344 :デフォルトの名無しさん:2010/10/03(日) 17:51:07
酷い事って、「やられたようだな」とか「四天王で最弱」とか言われるだけだろ

345 :デフォルトの名無しさん:2010/10/03(日) 17:59:21
yumでうpでーとできなくなる

346 :デフォルトの名無しさん:2010/10/03(日) 18:55:40
Linuxは来年には消えてるだろ

347 :デフォルトの名無しさん:2010/10/03(日) 23:23:45
この前FreeBSDにPHPをインストールしようとしたら、インストールにPerlが必要なんだな。

348 :デフォルトの名無しさん:2010/10/04(月) 01:53:44
>>344
ワラタwwwwwwwww

349 :デフォルトの名無しさん:2010/10/04(月) 02:09:02
依存関係が少ないLinuxって、やはりSlackwareになるのか。

350 :デフォルトの名無しさん:2010/10/04(月) 02:27:09
FreeBSDはpython依存してなかったっけ?

351 :デフォルトの名無しさん:2010/10/04(月) 08:25:45
何が?

FreeBSDでPythonはportsだし、本体は基本的にportsに依存しないはずだけど。

352 :デフォルトの名無しさん:2010/10/05(火) 09:10:24
>>341
Python信者はほんと・・・。>>331では"phpやRubyがPythonより遅い" って
書いてるんだから、言語処理系の速さについて話してるはずだったのに、
いつのまにかWebアプリの速さの話になってる。
処理系の速さとWebアプリの速さをまぜこぜにするな。Pythonだって遅い
フレームワークつかえば、Symphonyよりも遅い。
もしPythonのフレームワークがPHPのより遅かったら、それはPythonがPHP以下
だという証拠になるかもな。

> Rubyで無駄なオブジェクトを生成する書きかたが許容される文化なのに対して、Pythonは
> 簡潔さと実行効率を兼ねそろえた書きかたじゃないと「この書きかたはPythonicじゃない」って
> 否定される文化を持っているのも変わらない。

なにこの選民思想。技術者なら具体例を示せ。
Rubyは「簡潔だけど効率のあまりよくない書き方」と「ごちゃごちゃしてるけど
効率のいい書き方」のどちらもできる。全体へのパフォーマンスに影響を与えない
部分であれば、積極的に前者の書き方をしているだけ。
どうせマイクロベンチマークで一喜一憂しているPython信者だろ、おまえ。
Pythonistaはいいやつが多いけど、Python信者だけは別だな。

353 :デフォルトの名無しさん:2010/10/05(火) 09:18:49
Pythonistaはいいやつが多いけど、Python信者だけは別だな。(キリッ

354 :デフォルトの名無しさん:2010/10/05(火) 09:27:48
PHPの場合、組込みでテンプレートエンジン、セッション処理が備わってて、$_SERVERとか$_REQUESTが整備されてるもんな。
一つもクラスライブラリ使わずに、標準機能だけでMVC構造持ったウェブアプリが作れる。

355 :デフォルトの名無しさん:2010/10/05(火) 10:03:49
>フレームワークつかえば、Symphonyよりも遅い。
Symfonyより遅いとかありえないだろw
phpで速く動くWebアプリを作るには、>>354の言うようにフレームワークを捨てるしかない。

>なにこの選民思想。技術者なら具体例を示せ。
メソッドチェーン

>Rubyは「簡潔だけど効率のあまりよくない書き方」と「ごちゃごちゃしてるけど
>効率のいい書き方」のどちらもできる。全体へのパフォーマンスに影響を与えない
>部分であれば、積極的に前者の書き方をしているだけ。
一方、Pythonは「簡潔で効率の良い書きかた」をPythonicとしている。

356 :デフォルトの名無しさん:2010/10/05(火) 10:09:05
少し古いが、SymfonyとDjangoの比較
http://www.mellowmorning.com/2008/08/27/django-vs-symfony/

Speedのところを見ると、
> Symfony was stripped down for performance and was only about 30% heavier compared to the lightweight framework.
>When comparing it to Django however, the results showed that Symfony was only able to handle half the load Django could.

Symfonyから必要ない処理をそぎ落として、軽量フレームワーク(って何か知らんが)より30%重いだけになるまで高速化したけど、
無改造のDjangoの方が倍速かったって。

357 :デフォルトの名無しさん:2010/10/05(火) 14:07:09
webアプリの場合は言語の違いというより動作環境の違いが大きい。
pythonはmod_wsgiやfcgiなんかでメモリに全部読み込んで動作させるから速いに決まってる


358 :デフォルトの名無しさん:2010/10/05(火) 17:56:44
皆仲良く全部のプログラミング言語覚えたら良いじゃん。
このスレも平和になるだろ

359 :デフォルトの名無しさん:2010/10/05(火) 19:51:19
>>357
しかし、それはネイティブのPHPと同じ土俵にPythonが乗るってだけの話だぞ。

360 :デフォルトの名無しさん:2010/10/05(火) 20:13:21
PHPはださい
VBと同じにおいがする

361 :デフォルトの名無しさん:2010/10/05(火) 22:18:39
>>357
メソッド呼び出しにかかる時間みたいなマイクロベンチはアプリの速度に直結しないから
アプリの速度を議論したいけど、そもそもphpはWebアプリでしかほとんど使われてないから
Webアプリの話になってしまう。

>>359
同じじゃないんだよ。
mod_phpというインタプリタ自体はメモリに常駐するけど、その上のアプリケーションや、
アプリケーションが読み込む設定ファイルの情報などは、リクエストの度に全部消えて
アプリケーションが1から再起動する。
APCを使えばある程度高速化可能だけど、それはPythonアプリがpycがあるから起動が
速いのと同じ程度であって、アプリケーション自体がメモリに常駐するのに比べると桁違い。

362 :デフォルトの名無しさん:2010/10/05(火) 22:23:04
定性的な話ばっかりだな

363 :デフォルトの名無しさん:2010/10/05(火) 22:26:07
>>361
ふーん。
そうなんだ。

でもさ、それを言ってもしょうがないんじゃないの、そうしたら。
別にそれでPHPの遅さが正当化されるわけでもなんでもないし。
それにfcgiならPHPでもできるよな?やってみたら?

364 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/05(火) 22:26:28
>>360
わかるよそのきもち

365 :デフォルトの名無しさん:2010/10/05(火) 22:38:45
ここ最近groovy(つーかgroovy++)で遊びはじめたけどScalaより全然人気なさそうだな
動的/静的型、コンパイル/インタプリタを選べるし、groovyserv常駐させとけば
高速起動できるし、groovy++だと型推論効いてJavaと同等のコード生成できて
爆速だし、結構悪くないもんだなあと思ったよ
groovyserv知るまではJVMってだけで放置してたわ

ただ抽象度の高いコード書くと遅い
xs.foldLeft(0) { x, y -> x + y }
とか書くと、ベタなループで足し算するのの数十倍は遅い
これはこういう場合の関数呼び出しを消せない言語の宿命かな
PythonでもPsycoかけるとベタなループだけ劇的に高速化してreduce()に圧勝って
感じだね、試してみたら

366 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/05(火) 22:45:43
↑ 試してるだけで成果物がクソな奴
















ふっ(笑)

367 :デフォルトの名無しさん:2010/10/05(火) 23:44:17
ウェブアプリで言語の実行速度ををを比較しても意味ないと思う。
けど、ウェブアプリの実行速度って点でいえば、PHPの場合、月額100円200円くらいのレンタルサーバでもWordPressみたいな高機能なアプリがそれなりの速度で動かせるわけだけど、MTとかその他の言語のCMSじゃそれは無理。
その他の言語もコストを掛けてサーバ環境構築すれば速く出来るけど、コスト掛けて良いならJavaとかC#の方が断然速いわけで。


368 :デフォルトの名無しさん:2010/10/05(火) 23:48:59
webアプリでJavaとかC#の方が断然速いってwww

369 :デフォルトの名無しさん:2010/10/05(火) 23:51:34
>>367
サーバーコストより開発コストの方が断然高くつくんだよボウヤw

370 :デフォルトの名無しさん:2010/10/05(火) 23:53:21
>>367
昔はそれが正解だったけど、今は共有レンタルサーバーだけじゃなくてGAEとかVPSとかあるから、
PHPじゃなくても非CGI動作が可能。

371 :デフォルトの名無しさん:2010/10/06(水) 00:09:03
いや、VPSが共有レンタルサーバより安い事はないし。100円、200円レベルだとPHP以外は実質使い物にならないよ。海外なら無料っていうのもある。
まあ、HipHop for PHPみたいなのをPHPの周辺技術って事にしてしまえば、JavaやC#より速いわね。実績も十分だし。

372 :デフォルトの名無しさん:2010/10/06(水) 00:17:27
言語の速度もしくはウェブアプリの速度の話をしてるのに、開発コストを持ち出すのは頓珍漢と思うけど、非常に複雑高度なアプリケーションを開発する場合、普通Javaとかの非LLでしょう。
それはそういうアプリケーションを開発する場合、LLだと開発コストが高くつくからというのが理由の一つと思う。
もっと限定して、LLはJavaやC#に比べてコードの記述量が少なくて済む、とかだったらその通りだと思うけど。

373 :デフォルトの名無しさん:2010/10/06(水) 01:00:27
言語のパフォーマンスの話と
安価なレンサバがどうたらとかいう趣味グラマ話と
開発コストがどうたらいうエンタープライズの話がごっちゃになっててわけわからん

374 :デフォルトの名無しさん:2010/10/06(水) 01:07:54
Rubyをいじり始め、
phpの配列とハッシュの無差別さはよっかたなと思いつつ
はと、大した差ではないと思い至る。

375 :デフォルトの名無しさん:2010/10/06(水) 01:58:49
>>371
Facebook以外本格的なサービスで使われているのを見たことが無いんだが、、、
Symfonyとか自分でHiphopで動かしてみたことある?苦行以外の何物でもないよ?
Facebookは、たぶんビューにしかphpを使ってないんじゃないかな。

376 :デフォルトの名無しさん:2010/10/07(木) 02:07:38
FacebookはほとんどHipHopに移行してる。トラフィックベースで90%に達してる。
中小規模のサイトは普通のmod_php、大規模高アクセスサイトはHipHopって使い分ければ、他の言語の実行環境は付けいる隙ないな。

377 :デフォルトの名無しさん:2010/10/07(木) 10:10:31
>>376
Hiphop使うくらいならPython使った方が楽に性能出せる。

378 :デフォルトの名無しさん:2010/10/07(木) 11:01:59
>>371
> まあ、HipHop for PHPみたいなのをPHPの周辺技術って事にしてしまえば、
> JavaやC#より速いわね。実績も十分だし。

それマジ?
ネイティブコンパイルできたりJITで動作する動的言語はいっぱいあるけど
JavaやC#より速いものなんて見たことない
静的型指定できれば速くできるだろうけど

379 :デフォルトの名無しさん:2010/10/07(木) 11:32:36
要はソースコードをPHPの文法で書いて、それをC++としてコンパイルして、そのバイナリをウェブアプリとして動かしてるってわけで。もはやPHPとは言えないかな。

380 :デフォルトの名無しさん:2010/10/07(木) 11:53:58
いや、結局C++でphpの動的型の挙動を実装しているので、動的型のオーバーヘッドはしっかり残ってる。
Cythonで型指定した方が速い。

381 :デフォルトの名無しさん:2010/10/07(木) 11:54:24
>>379
そういうもんだとは理解したけど、PHPよく知らんし素人の俺には
型を推論しきれるのかがよくわからない

たとえばJavaScriptで言うと
fuction f(x, y) { return x + y }
でx, yの型は少なくとも静的には推論できないので、動的なコードになると思う
f(1, 2) -> 3
f("a", "b") -> "ab"
とかだし

動的言語だと大抵クラスや何かも動的なので、ポインタ経由のただの
vtbl引きよりずっと複雑な動的検索が必要になると思う

この辺がどうにかできてないと、C++のコードを吐くとはいっても
単にLispのコードをCに落としましたみたいな奴になるのでは?
なので、JavaやC#より速くなるなんて信じられなかった

382 :デフォルトの名無しさん:2010/10/07(木) 11:56:18
>>380
ああやっぱりそうなのね
ありがとう

383 :デフォルトの名無しさん:2010/10/07(木) 11:58:25
Facebook自身が倍速くなったとしか言ってないじゃん。
普通のWebアプリなら、phpからPythonにするだけで、Cythonとか使わなくても倍にはなるよ。

384 :デフォルトの名無しさん:2010/10/07(木) 11:59:56
PHPカンファレンスで、Facebookの人が来てHipHopの解説してる。動画も見られるはず。
型は型推論してて、それなりに最適化されてるようだ。ただし、eval()とかはダメで、多少PHPのコーディングを制約されるようだ。

385 :デフォルトの名無しさん:2010/10/07(木) 12:07:43
>>383
Webアプリのスループット全体で倍とかだと正直よくわかんないなあ
ある意味全体で倍は凄いと思うけど……

Pythonだと
for (i in xs): result += i
みたいなコードなら、psyco使うと100倍近く速くなるかな

386 :デフォルトの名無しさん:2010/10/07(木) 12:09:31
ちなみにPHPは5.4からIntとかをタイプヒンティング出来るようになる。
fuction f(Int $x, Int $y) { return $x + $y }

387 :デフォルトの名無しさん:2010/10/07(木) 13:20:41
>>385
cdef long result = 0
cdef long i
for i in xs: result += i
これなら、Pythonオブジェクトの操作をショートカットして、C言語のlong型で加算が可能。
ただし、xsを巡回する処理はPythonオブジェクトの操作になってしまう。
1回巡回するだけならそれで良いけど、何度もアクセスするならCythonの中からmalloc使って
int の配列作るとかできる。

388 :387:2010/10/07(木) 13:22:09
あ、ごめん、Cythonの話ね。
>>385
Psycoだと静的片付けにはならないから、100倍はムリだと思う。

389 :デフォルトの名無しさん:2010/10/07(木) 13:23:22
>>384
eval もそうだけど、関数を動的に定義するのとか、autoloadとかもダメね。

390 :デフォルトの名無しさん:2010/10/07(木) 13:26:04
>>388
書き方がわるかった
xs = range(1000)
result = 0
for i in xs: result += i
みたいに、intと推論可能なケースのつもりだった
すくなくとも数十倍は早くなったよ

CPythonだと足し算のたびにintオブジェクトを毎回作成破棄するけど
それをスキップしてx86の整数加算に落としてるんじゃないかな

391 :デフォルトの名無しさん:2010/10/07(木) 13:30:12
Cythonは相互運用性としてはJVMや.NET言語に劣るんだよね
「C/C++のコードと」連携したいという前提があるなら、まあそれも仕方ないんだけど


392 :デフォルトの名無しさん:2010/10/07(木) 14:10:17
>>390
インタプリタのコストを削減しているだけで、型に関しては普通にPythonのint型オブジェクトを
使ってると思うよ。
そうじゃないと桁あふれ時の動作が変わるし。

>>391
それはJITエンジン全部にも言える事じゃないか?
IronPythonならC#で拡張書けばいい。

393 :デフォルトの名無しさん:2010/10/10(日) 03:44:33
pythonやrubyを先にやったらPHPが簡単に感じたりする?

394 :デフォルトの名無しさん:2010/10/10(日) 04:57:42
陳腐に感じるかもしれないね…

395 :デフォルトの名無しさん:2010/10/10(日) 08:44:09
面白いライブラリ揃ってるけど、言語としてはガッカリするかも知れん

396 :デフォルトの名無しさん:2010/10/10(日) 11:02:45
PHPバカにしてる奴は俺マイナー言語使っててカッコイイみたいな価値観の奴だから気にするな

397 :デフォルトの名無しさん:2010/10/10(日) 12:25:03
>>355
>Symfonyより遅いとかありえないだろw
いやそんなことない。

まずPython信者の論法がおかしい。DjangoとSymfonyのベンチマークを理由にするなら、
それはあくまでDjangoとSymfonyの速度であって、イコールPythonとPHPの速さではない。
Pythonのフレームワークの中でも速いほうである(らしい)Djangoと、
PHPのフレームワークの中では遅いことで有名なSymhonyを比較してるけど、
それならDjangoのほうが勝つのはわかる。けどやっぱりそれはDjangoとSymfonyの
比較の話であって、それをもって「PythonよりPHPのほうが速い」といわれても困る。
「PHP framework benchmark」でぐぐれば、PHPのフレームワークによって速度に大きな
違いがあることがわかる。
ttp://www.tsujita.jp/blojsom/blog/default/PHP/
比較するなら、せめてSymfonyじゃなくてCodeIgniterにしてほしい。
実際、CodeIgniterはDjangoより高速というベンチマーク結果もある。
ttp://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/
もしDjangoがSymfonyと比べて数10パーセントしか速くないなら、CodeIgniterだけでなく
最近出てきた他のPHPフレームワークや、Synfony2には負けるだろう。
ttp://www.yiiframework.com/performance/
ttp://symfony-reloaded.org/fast
それからDjangoはどうかしらないけど、昔フレームーワークを選定するときにRuby on Railsと
CodeIgniterとTuborbogearsでベンチマークをとったけど、速い順でCodeIgniter、Rails、
Turbogearsだった。TurbogearsはPythonでの有名なフレームワークだけど、遅すぎて
採用する気になれなかった。
だからPython信者に言いたいんだけど、フレームワークの速さをもちだして、それがあたかも
言語の速さのように言うのは頭おかしい (だから信者なんだろうけど)。
Djangoは速いんだろうけど、それはDjangoが速いのであって必ずしもPythonの速さではない。
Symfony1は遅いけどそれはSymfoy1のせいであって必ずしもPHPのせいではない。

あと速度の話は抜きにして、PythonがPHPにとってかわることは少なくともあと数年はない。
理由はWordPressがPHPで作られているから。これはPython信者がどんなに頑張っても無理。

398 :デフォルトの名無しさん:2010/10/10(日) 12:40:43
追加だけど、PHPは毎回クラスを読み込み直すのでその分遅いのは確か。これはPython信者の指摘通り。
しかしそのハンデがないはずのPython製フレームワークが、PHPのフレームワークより遅い場合もあるという事実は、
Webアプリケーションのスピードが一筋縄では決まらないことを表している。
それが分かっていれば「PHPよりPythonのほうが速い」なんてそう簡単にいえるものではない。

あとPython信者はPHPと戦っているようだけど、PythonもPHPもJavaからみたら目糞はなくそでしかない。
PHPは無料レンサバでも実用的に使えるのでそれができないJavaとは棲み分けが可能だけど、
Pythonは直接競合するからね。Google App Engineでも競合してるし。
無料レンサバならPHP一択だけど、VPSが利用できるなら別にPythonである必要はないんだよね。
JavaよりPythonが簡単って言うけど、ScalaやGroovyがある今となってはどうも。


399 :デフォルトの名無しさん:2010/10/10(日) 12:48:31
またコイツ、いや、まだコイツかよ。いい加減オナニーはやめろ
ブログで書け

400 :デフォルトの名無しさん:2010/10/10(日) 12:49:28
どうせ大したこと言ってないんだから簡潔に言えよ
ウンコみたいな文章を読んでもらえると思うなよ

401 :デフォルトの名無しさん:2010/10/10(日) 12:53:34
Djangoが早い方、っていうのは、何と比較して?
Pythonには軽いフレームワークも結構あるし、どちらかというと遅い方だと思うが。
mod_wsgiの話だったら、WSGIに対応しているフレームワーク全部早いし、
その中で、っていう話ならDjangoが早い方には絶対ならんと思うが。

402 :デフォルトの名無しさん:2010/10/10(日) 13:12:27
信者って言葉使うやつのいうこと、まともに相手しないほうがいいよ。
薄っぺらい情報あつめて知ったかぶりするやつばっかりだからw

403 :デフォルトの名無しさん:2010/10/10(日) 13:47:30
>>397
>もしDjangoがSymfonyと比べて数10パーセントしか速くないなら
Symfonyを *軽量化して* 、それでも *2倍* の差があったんだよ?

>TurbogearsはPythonでの有名なフレームワークだけど、遅すぎて
>採用する気になれなかった。
はいはい、環境とか全く出してない記憶だけのベンチマークなんて
信頼できませんよ。

>フレームワークの速さをもちだして、それがあたかも言語の速さのように言うのは頭おかしい
と言っておいて、
>PHPは毎回クラスを読み込み直すのでその分遅いのは確か。これはPython信者の指摘通り。
はどうなの?
最初からPHPは毎回クラスとか設定とか読みこみ直すし、簡単なキャッシュも
一々APCやmemcachedにシリアライズして入れないといけなくてグローバル変数に残せないから
遅いって言ってるのに、認めてるのか認めてないのか意味不明

>PythonもPHPもJavaからみたら目糞はなくそでしかない。
痛てて

404 :デフォルトの名無しさん:2010/10/10(日) 14:23:22
TurboGearsはGenshi使ってるから、それで遅いのかもね。
言語の速度差はあくまでも同じようなアーキテクチャを構築したときの速度差にしか
あらわれなくて、Genshiみたいなプリコンパイルをしてくれない激重テンプレートエンジン
使うとさすがに遅くなる。しかもあれってテキストテンプレートとしても使えるけど、
DOMテンプレートにもなるから、その機能をTGが使っているとやっぱり遅くなる。
TracなんかもGenshiのDOM型テンプレート使っているから重い。

405 :デフォルトの名無しさん:2010/10/10(日) 17:12:17
別にクラスライブラリを毎回読み直しても遅いとは感じないけどな。そのおかげでファイルを設置するだけでデプロイが完了するという、管理しやすさの方にメリットを感じる。
そもそもPHPの場合、標準で何でも揃ってるから、クラスライブラリの必要性薄いし。
言語の速度比較するなら、バブルソートだとかそういうのでベンチマークを取る。
ウェブアプリケーションで、それもウェブフレームワーク、アプリケーションサーバソフトの性格も無視して、速度差を語っても、まるで無意味。

406 :デフォルトの名無しさん:2010/10/10(日) 18:37:59
>>405
その知識のなさで、それだけのことを語れる君に日本の未来を感じたよ!
がんばれ!

407 :デフォルトの名無しさん:2010/10/10(日) 19:59:56
PHPの人ってこういうのが多い

408 :デフォルトの名無しさん:2010/10/10(日) 22:16:35
HTMLが出力されて実用に耐え得ればなんでもいい

409 :デフォルトの名無しさん:2010/10/10(日) 22:29:11
フレームワークも別、アプリケーションサーバも別、こんなんでベンチマーク取る意味ないわ

410 :デフォルトの名無しさん:2010/10/10(日) 23:05:27
http://labs.gree.jp/blog/2010/05/61/
この仕組みでこれだけ速くなるのだから、PHPは(インタプリタではなくて)リクエストの度に
色々ロードし直すという基本設計がネックでフレームワークを使ったWebアプリが数倍遅
くなっているというのは明らか。

逆にPHPのインタプリタがPythonやRubyよりも数倍速いのでなければ、PHPで作ったWeb
アプリはPythonやRubyでだいたい同じように作ったWebアプリよりも遅くなる傾向があると言える。

411 :デフォルトの名無しさん:2010/10/10(日) 23:25:03
永続化しないというのはmod_phpの話だから。
フレームワークが何を指してるのか知らないが、PHPの優れてるのは色々ロードしなくてもほとんどの機能が組み込まれてる所にあるんだから。
処理が重かったらYahooみたいにエクステンションにすればいいし、もっと重ければFacebookみたいにHipHopを使えばいい。これだってPHPを使った開発手法の一つだから。
逆に、ほとんど機能性がない、処理が走らないウェブページなら、APCのようなキャッシュだって使わない方が良い。
すべては要件によって全て変わってくる。
100m走とハードル走比べてどっちが速いとか、まったく無意味。

412 :デフォルトの名無しさん:2010/10/10(日) 23:48:58
>>409
つーか目的はWebページが表示されることなんだからそこだけ条件そろえればいいんじゃね
そして言語のみを取り上げてこの言語は遅いだのカスだの言わないことだな
この言語を使ってこういう実装した場合の優劣みたいな比較をすべき

413 :デフォルトの名無しさん:2010/10/11(月) 00:01:44
Rails3 + ruby 1.9.2も比較してあげて…

414 :デフォルトの名無しさん:2010/10/11(月) 01:12:18
>>411
mod_phpというか、phpの基本ポリシーみたいになっているから、fcgiなんかも含めてすべてそうなってる。
拡張とかHiphopじゃなくて、一般的なフレームワークを使ったWebアプリ開発の話をしている。
実行速度問題ないのにロード速度が重いからってだけで一々拡張作ったりHiphopみたいな面倒で
不安定な仕組みを使わないといけないんじゃ、生産性ガタ落ち。

415 :デフォルトの名無しさん:2010/10/11(月) 09:37:51
ウェブページって言っても、<html>HelloWorld</html>を出すだけなのから、どこまでも複雑な処理を出すのじゃ、全然違う。
PerlでもRubyでも、CGI、mod_perl、passenger、mongrel、CGI::App、Catalyst、Rails、sinatra、それぞれ環境にはそれに応じた目的があって、実行速度もトレードオフで変わってくる。
安定性で言えばCGIがメモリリークも問題にならず一番安定してるし、実行速度を稼ぐには永続化した環境の方が良い。
速度の話なのに生産性を持ち出すのは馬鹿げてるが、PHPの簡単な文法、充実したマニュアル、アプリケーションサーバとして管理しやすさ、これらのおかげでPHPを使った開発は非常に生産性が高いと言える。
だから、PHPの高いシェアがある。

416 :デフォルトの名無しさん:2010/10/11(月) 11:48:30
日本語理解できないのか偏屈なのか

417 :デフォルトの名無しさん:2010/10/11(月) 12:59:05
はいはいWebはPHPちゃんでいいよもう
それ以外は他の言語でやるからさ

418 :デフォルトの名無しさん:2010/10/11(月) 13:56:19
Facebookが全面的に採用してるのにHipHopが不安定というのはあり得ない。

419 :デフォルトの名無しさん:2010/10/11(月) 13:58:40
プログラミングの前に日本語を勉強すべき。

420 :デフォルトの名無しさん:2010/10/11(月) 14:01:53
日本語が出来ないからプログラミングなんてやる羽目になったんだろ

421 :デフォルトの名無しさん:2010/10/11(月) 14:03:53
俺も日本語よりプログラミング言語のが上手く書けるな
特に何かの手順を書き記そうとすると、自然とコードっぽい記述に…w

422 :デフォルトの名無しさん:2010/10/11(月) 14:06:58
つーても、ウェブ以外じゃ、商業ベースでスクリプト言語の使い道はほとんどないから

423 :デフォルトの名無しさん:2010/10/11(月) 14:08:53
テキストフィルタはAWKかPerlかRubyで書きたいな

424 :デフォルトの名無しさん:2010/10/11(月) 14:41:20
>>418
hiphop-dev をウォッチしてる?
自分でhiphop動かしてみた?

セグフォ報告大量にあるし、フレームワークを使ったアプリケーションをビルドするのには何時間もかかるし、
フレームワーク自体をHiphopで動くように改造するのも一苦労。
FacebookってPHPはただのテンプレートエンジンとしてしか使ってないんじゃない?
ビジネスロジックはJavaかScalaかPython使ってる予感。

425 :デフォルトの名無しさん:2010/10/11(月) 14:45:01
>>422
Pythonはスクリプティングにも使える汎用プログラミング言語だから、WebやUnix用スクリプトだけじゃない。
Linuxデスクトップの世界では、PythonがGUIアプリケーション用の言語として浸透している。
DropBoxとかBitTorrentだってPython製アプリで、Windows用はexe形式にパックしてあるだけ。
マクロ・プラグイン・スクリプティングのためにPythonを利用しているゲームエンジン、2D/3D
グラフィックソフトは世の中で広く利用されている。

426 :デフォルトの名無しさん:2010/10/11(月) 14:50:18
PHPはクソだけど使えるから使うってのはPHPの作者を含めて共通認識だろ?
なんで今さらdisったり、それをかばったりするのん?

427 :デフォルトの名無しさん:2010/10/11(月) 14:53:52
>>424
http://developers.facebook.com/blog/post/358
これを読む限りはマジでPHPっぽいぞ

428 :デフォルトの名無しさん:2010/10/11(月) 14:55:05
クソだという事実を認めない人がいるから

429 :デフォルトの名無しさん:2010/10/11(月) 15:01:44
PHP叩いてるPythonの人って、この人かね。
リクエストごとに〜、とか、symfonyが〜、とか、同じこと言ってる。
ttp://twitter.com/methane/status/18084626648
ttp://twitter.com/methane/status/18084751964
ttp://twitter.com/methane/status/18085044326
ttp://twitter.com/methane/status/18085303550
ttp://twitter.com/methane/status/18216664951
ttp://twitter.com/methane/status/18216677887


430 :デフォルトの名無しさん:2010/10/11(月) 16:41:36
Scalaのforループってすごく遅くないですか?
http://codepad.org/EQR8MH0B
何種類かの書き方を試して計測してみたのですが、
上から0.03s→0.22s→0.56s→0.83s
という具合にどんどん遅くなります

sum3()はJavaでも拡張for文で書けるような平凡なコードですが
whileでド汚く書いたsum1()の20倍近く遅いです
Javaの拡張for文なら、sum1()と同等の速度が出ます

431 :デフォルトの名無しさん:2010/10/11(月) 17:26:18
まぁJavaで書いてるんだからJavaより速くはならんだろそりゃ
カツカツ最高速でもJavaと同速度だ

432 :デフォルトの名無しさん:2010/10/12(火) 08:19:05
フロントをPHPで、バックエンドをJavaやC++で書いてる部分はあるかもしれないが、そこにPythonが含まれてる予感はまったくしない。

433 :デフォルトの名無しさん:2010/10/12(火) 09:49:33
>>432
FacebookはFriendFeedを買収したけど、FriendFeedが作ってたリアルタイムWebフレームワークの
TornadoをFacebookでも使ってるよ。
http://developers.facebook.com/blog/post/301

434 :デフォルトの名無しさん:2010/10/12(火) 10:15:27
Pythonの非同期フレームワークだと、コルーチンを用いて実装されているeventletが
普通のコールバックスタイルでなく同期と全く同じpullモデルで書けるし
標準ライブラリのsocketやurllibなどにモンキーパッチを当てて
ほとんどコードを変えずに何事も無かったように非同期化できるんで
特に優れてるように見えたな

今Node.jsとか流行ってるらしいけどどうなんすか

435 :デフォルトの名無しさん:2010/10/12(火) 15:04:26
サーバーサイドで書ける言語をこれ以上増やしてもな
クライアントサイドで書ける言語の選択肢をもっと多くしてくれ

436 :デフォルトの名無しさん:2010/10/12(火) 15:09:07
Java、JavaScript、C#(Silverlight)、Flash。これでも不足?

437 :デフォルトの名無しさん:2010/10/12(火) 15:22:33
>>433
それはPythonで完結する場合だろ?PHPとPythonで有意な速度差があるとは思えない。それなら全部PHP、もしくは全部Pythonで書いた方がメンテしやすい。

438 :デフォルトの名無しさん:2010/10/12(火) 17:57:26
>>429
この人はエキスパートパイソンという本を書いた人みたいだけど、ガチでパイソン信者だなあ。
ルビーも相当嫌いらしいww

ttp://twitter.com/methane/status/26559107342
Pythonの名前付き引数は見た瞬間理解して感動したが、Rubyのシンボルは今でも調べてないので
理解できていない。多言語プログラマの共通言語として、Pythonは素晴らしいと思う。

ttp://twitter.com/methane/status/26558926751
self.は見た瞬間意味を理解したが、@はPerlっぽく見えた。Pythonの. は -> だとすぐわかった
が、Rubyの . がメソッド呼び出しなのは判らなかった。"foo bar".split() は判ったが、
%w[foo bar] は判らなかった。

ttp://twitter.com/methane/status/26558636746
Pythonはチュートリアル流し読みしただけで、Web上でみたいろいろなコードを全く問題なく読め
た。Rubyは勉強しないと読めない。

"Rubyは勉強しないと読めない" とかもはやこじつけ。

439 :デフォルトの名無しさん:2010/10/12(火) 18:13:08
>>438
言い方が過激だけど、内容は間違ってないだろ?
毎日その言語でプログラム書いている人にとってはRubyの方が書きやすいかもしれないけど、
普段その言語を使わないユーザーがたまに修正するにはPythonの方が理解が早い。
俺もC++のプロジェクトのビルドツールやテストツールなら、RubyよりもPythonを選ぶな。

440 :デフォルトの名無しさん:2010/10/12(火) 18:17:51
興味はあるけどイマイチ始めようと思わない言語:関数型言語、ruby

441 :デフォルトの名無しさん:2010/10/12(火) 18:19:24
「エキスパートPythonプログラミング」の翻訳者のひとり?

442 :デフォルトの名無しさん:2010/10/12(火) 18:31:24
これすごいなあ。信者がどんなふうに考えているか知ることができる。つうかもう怖いよ。

ttp://twitter.com/methane/status/16673043960
C++とJavaがある程度分かっていると、Pythonはサラッとチュートリアル読んだだけで、
(メタクラスとか高度な部分を除き)大抵のコードは読むことができた。Rubyはムリ。

ttp://twitter.com/methane/status/16673105203
Rubyの世界では、DRYがよく叫ばれている。Repeatしないために、どんどんルールを作る。
一方、PythonのZenにはDRYがない代わりに、 "Special casesarn't special enough to
break the rules." というものがある。

ttp://twitter.com/methane/status/16673188444
たとえば、Rubyはメソッド呼び出しの括弧を省略できるけど、Pythonは省略できない。
括弧を書くというRepeatを行った分、特殊メソッド以外の呼び出しは一目瞭然。

ttp://twitter.com/methane/status/16673278223
あと、Rubyはsuperの引数を省略すると、自分の引数がそのまま渡される。
Pythonは普通に引数なしで呼び出す。Rubyの方がタイプ数少ないけど、特別な暗黙ルールを
作れば作るほど、一見さんには意味不明になっていく。

ttp://twitter.com/methane/status/17241429240
GREE Fast Processor とか、ぶっちゃけどう考えても非効率なPHPをある程度マトモな形に
無理やり修正しているだけで、最初からPython使っていれば全く問題なく綺麗に効率的な
構成がとれるんですけどね。APCも設定ファイルのコンパイルも、Pythonなら不要。

>>439
本人乙。もうバレバレなんだし、トリップつけたら?

443 :デフォルトの名無しさん:2010/10/12(火) 18:33:06
このスレって文章力ない奴のオナニー長文とツイッターからのコピペで埋まっていくんだな死ね

444 :デフォルトの名無しさん:2010/10/12(火) 18:37:24
アンチ的な主張も自分のブログとかツイッターで主張しろよw

445 :デフォルトの名無しさん:2010/10/12(火) 19:02:52
>>438
2chのPython信者って痛いよなーと前から思ってたけど、その典型例みたいな奴だな

446 :デフォルトの名無しさん:2010/10/12(火) 19:10:51
ポールはLispの宣伝ばかりしてるLisp信者だけど、それのどこが問題なのかな?
とりあえず自分の気に入らない2chのレスやコピペを逐一コピペすんな。目障りだから
誘導すれば興味あるやつは自分で読むだろ

447 :デフォルトの名無しさん:2010/10/12(火) 19:14:01
訂正 2chのレスやツイッターのコピペを連投すんな

448 :デフォルトの名無しさん:2010/10/12(火) 19:21:43
いや、このスレでやらかすぶんには全然かまわないと思うけどどうかね?

449 :デフォルトの名無しさん:2010/10/12(火) 19:24:29
発言主がいないところで「Python信者はさー」ってなんの話だよ。レベル低すぎるわ

450 :デフォルトの名無しさん:2010/10/12(火) 20:02:04
そもそも、「信者」などとレッテルを貼ることでしか、自分の主張を正当化できないのは、
痛すぎる。

451 :デフォルトの名無しさん:2010/10/12(火) 20:08:22
スイッチ入っちゃったみたいだね

452 :デフォルトの名無しさん:2010/10/12(火) 21:05:54
パイソン信者の人は自分の文体が独特なのに気づかないのかな?パイソン以外の言語には頭が回らないのかしら

453 :デフォルトの名無しさん:2010/10/12(火) 21:37:10
本人乙。
>>446
>ポールはLispの宣伝ばかりしてるLisp信者だけど、それのどこが問題なのかな?
別に問題ないんじゃない?Python信者がPythonの宣伝しても何の問題もない。ここはそのためのスレだろ?
コピペくらい気にすることじゃない。

454 :デフォルトの名無しさん:2010/10/12(火) 21:40:08
いやー、パイソンって本当にすばらしい言語ですね。
使ってる人もすばらしい人ばかりで、PHPやRubyとは大違いですね。
ぼくも今からパイソン勉強します。まずエキスパートPythonを読んでみます。

455 :デフォルトの名無しさん:2010/10/12(火) 21:46:08
>>450
>そもそも、「信者」などとレッテルを貼ることでしか、自分の主張を正当化できないのは、
>痛すぎる。
笑うところ?どうみても信者のいってることのほうが痛いだろ。

456 :デフォルトの名無しさん:2010/10/12(火) 21:56:33
>>455
自覚ないのかもしれないけどお前の方が

457 :デフォルトの名無しさん:2010/10/12(火) 21:58:21
コピペ連投馬鹿が「コピペくらい気にすることじゃない」と取り繕うスレ

458 :デフォルトの名無しさん:2010/10/12(火) 22:06:35
まあまあ
すぐ必死になるのが面白いんだからニヤニヤ弄ってればいいんだよ

459 :デフォルトの名無しさん:2010/10/12(火) 22:08:22
>>442
こうやって晒されたのを見た感想としては、
「Rubyは楽しい」に通ずる何かを感じるな

460 :デフォルトの名無しさん:2010/10/12(火) 22:14:03
ぐだぐだ言ってるヒマがあったら一行でもコードを書くべきだな
良い言語というのは言語自体の良し悪しでは無く、それで書かれたアプリによって決まるのだから

461 :デフォルトの名無しさん:2010/10/12(火) 22:15:40
>>442
このひと Ruby と Rails がごっちゃになってるんだな

462 :methane:2010/10/12(火) 23:36:50
本人です。
まず、Twitterでは完全に個人の主観を書いていますが、エキスパートPythonプログラミングでは
個人の主観は入れずに技術的に正しい翻訳本を目指しています。そもそも他言語との比較などは行って
いないし、宗教チックな事もあまりないです。(原本からほんの少しアジャイル臭とZope臭はしますが)

PHPのrequireが云々は、PHPのアプリのチューンを手伝ってて、symfonyが設定ファイル(yml)を
phpファイルに変換してそれをさらにAPCでキャッシュしているのに、それでもそのrequireだけで
10ms以上は使っているのに嘆いて呟いていました。

RubyとPythonの比較は、実際にRubyで書かれたプログラムを読んだ感想です。
読んでいるのはMessagePackだったり社内のRubistが書いたプログラムだったりするので偏りが激しい
かもしれません。しかし、TwitterでつぶやいているようにPythonは意味を推測しにくい記号が少ないのも
他言語ユーザーが読んだ時の読みやすさに影響しているように感じます。
もちろん、Pythonにもリスト・ジェネレータ内包表記のようにJava/C++の経験だけでは面食らう文法も
ありましたが、Rubyのプログラムを読んでいるのに比べるとチュートリアルを読み返す回数は大幅に
少なかったと記憶しています。


463 :デフォルトの名無しさん:2010/10/12(火) 23:46:37
>>442
1つ目:
完全に個人の感想です。Rubyを煽っているように読めるのは、Rubyの人からの反応を見たかったからです。
PythonよりRubyの方がスラスラ読めたという感想とか、Rubyのコードをスラスラ読むためのカギなどあったら
教えてください。

2つ目:
これも感想ですが、Ruby界隈ではDRYというキーワードを見る機会が、Python界隈に比べて多い気がします。

3つ目と4つ目:
2つ目のつぶやきに関して例を挙げただけです。逆に、PythonよりもRubyの方が、暗黙ルールを知らない
多言語ユーザーから見て自明になる文法ってどれくらいありますか?

5つ目:
requireとの戦いに疲れた時の叫びです。間違ったことは言っていないと思いますが。

464 :methane:2010/10/12(火) 23:48:12
>>463 は私です。コテハン記憶のチェックが外れてました。

465 :デフォルトの名無しさん:2010/10/13(水) 00:08:13
本人キタ――(゚∀゚)――!!
このスレで匿名でやいやい言ってもあんまり意味がないし、
意味がないから無責任な発言を連発してるだけなので、あまり気にしなくてもいいのですが、
こんな風に槍玉にあげられたら一言言いたい気持ちも分かります。
個人的には正論だと思います。これからもがんばってください。

466 :デフォルトの名無しさん:2010/10/13(水) 00:50:05
わざわざ、hoge(self, hogehoge)とselfを書く意味が分からんな。
内部動作的になんかあるとか、ちらっと見かけたが。


467 :デフォルトの名無しさん:2010/10/13(水) 01:10:45
これほんとに本人なの?なりすましじゃない?

> Rubyを煽っているように読めるのは、Rubyの人からの反応を見たかったからです。
本人だとしたら、完全に意図的ということか。

> これも感想ですが、Ruby界隈ではDRYというキーワードを見る機会が、Python界隈に比べて多い気がします。
だから何?DRYを推進したら何か悪いの?

> 逆に、PythonよりもRubyの方が、暗黙ルールを知らない多言語ユーザーから見て自明になる文法ってどれくらいありますか?
ないんじゃない?知らないけど。PythonとRubyの両方に詳しい人がいうんだから間違いないでしょう。

> requireとの戦いに疲れた時の叫びです。間違ったことは言っていないと思いますが。
うん、間違ってないと思うよ。RubyよりPHPより素晴らしい言語、それがPython。
これからもこの調子で頑張ってください。本当に本人なら。

468 :デフォルトの名無しさん:2010/10/13(水) 01:13:57
本人はPythonスレにたまに出没するから本人だと思うよ
それを狙った成りすましと言われればなにも言えないが

469 :デフォルトの名無しさん:2010/10/13(水) 01:41:01
http://twitter.com/methane/status/27122796834
http://twitter.com/methane/status/27145580952

たぶん本人じゃないか。時刻はだいたい一致してる。
pythonスレとか別スレのことを言ってるという可能性もないではないが
ダルいからこれ以上の確認は止める。

470 :デフォルトの名無しさん:2010/10/13(水) 01:49:15
2chに書き込んで実名自慢ってかっこ悪いw

471 :デフォルトの名無しさん:2010/10/13(水) 01:54:27
>>466
@classmethod とか
@staticmethod とかを使ったときに
ああ
あって良かったんだと認識出来た

472 :methane:2010/10/13(水) 02:22:17
>>467
>> これも感想ですが、Ruby界隈ではDRYというキーワードを見る機会が、Python界隈に比べて多い気がします。
> だから何?DRYを推進したら何か悪いの?

別にDRY原則自体が悪いというつもりはありません。
ですが、PythonはDRYというよりも「簡潔さ」を目指し、少ない汎用的なルールだけでDRYが実現できない場合は
ある程度の冗長性には目をつぶって明示的なコードを書く文化がある。だから他人の書いたコードの一部だけを
読むときもストレスが少ない。
逆に、頑張って冗長性を排除する代わりに暗黙のルールを導入しているコードを読んで動作を理解するの
には苦痛を伴う。

あくまでもバランス感覚の問題ですが、僕にとって「ルールの少なさ」と「DRY」のバランスはRuby文化より
Python文化の方が好きだ、という意味を込めてのTweetです。

473 :デフォルトの名無しさん:2010/10/13(水) 02:25:58
せっかくだから記念に宣伝しとこう。
エキスパートなPython信者が書いた「エキスパートPythonプログラミング」絶賛発売中!
ttp://www.amazon.co.jp/exec/obidos/ASIN/4048686291/hatena-hamazou-22/
これを読めばあなたもPythonエキスパートになれる!


474 :デフォルトの名無しさん:2010/10/13(水) 02:28:26
アンチ必死過ぎ…w

475 :デフォルトの名無しさん:2010/10/13(水) 02:34:27
>>473
LR違反です
通報しました

476 :デフォルトの名無しさん:2010/10/13(水) 02:54:36
>>472
簡潔さ、というか、可読性といったほうがいいんじゃないかな。

あと、あんまり本人として出てこない方がいいんじゃないかな、と思うんだけど。
別に言ってることは間違ってないし、筋も通ってるとは思うけど、
「誰がいったか」はそもそも問題じゃないし。
論理的に反論する限り、別に本人を名乗らなくてもいいと思うんですが。
気持ちはよくわかるんですけど、荒れる方向にしかいかない気がする。

そもそも、論理的な反論もできないで、「信者」とレッテル張りすることでしか、
自己の主張の正当性を示せないようなやつなんて、相手にしてもしょうがない、
ってのは、みんな理解してると思いますよ。

477 :デフォルトの名無しさん:2010/10/13(水) 03:50:08
ご本人(?)も認めているように、ツイートは「個人的な感覚」であって、
もともとが論理的な主張ではないのだから論理的な反論など無意味
(だからこそ、ここにまで転載するような内容ではないとも思うが……)
あるとしたら水掛け論だけ

superの挙動だが、matzのことだから
元ネタはCommon LispのCLOSのcall-next-method辺りなのかな
それこそtwitterで本人に聞くしかなさそうなw

478 :デフォルトの名無しさん:2010/10/13(水) 04:51:24
>(だからこそ、ここにまで転載するような内容ではないとも思うが……)

本の宣伝だろ
個人的な営利行為は2chでは禁止されてるよ

479 :デフォルトの名無しさん:2010/10/13(水) 04:52:10
>>429
これはどうみても信者だろ。ここまであからさまなのは中々ない。
これを信者じゃないというほうが信者だよ。
なぜそこまでPHPが嫌いなの?symfonyが遅い=PHPが遅いと言っているけど、違うよね。symfony以外のフレームワークは試してみた?
もしPHPが本当に遅いなら、他のPHPフレームワークより遅いPythonフレームワークがあるのはなんで?

>>474
本人乙。必死なのは火消しに躍起になってるほうでしょ。


480 :デフォルトの名無しさん:2010/10/13(水) 05:00:21
>>479
お前の知識が浅いのはよく分かった

481 :デフォルトの名無しさん:2010/10/13(水) 05:00:43
>>479
おれ本人じゃないけど Python 好き PHP は嫌い
好き嫌いに理由なんてないぜ

482 :デフォルトの名無しさん:2010/10/13(水) 07:03:44
俺はたいていの言語大丈夫だけどPythonだけダメだわ
括弧書きたい!!!

483 :デフォルトの名無しさん:2010/10/13(水) 07:54:36
ツイッターでもブログでも、個人が自由に書けばいいじゃん。個人の主観で書けば。
それが他人の主観からみたら信者に見えたってだけでしょ。
個人の主観で書きたいように書くのがありなら、他人が主観で信者だと思うのもありだろう。
それとも信者と言われて何か困るの?

もう今度から「信者」と書いて「エキスパート」と読めばいいんじゃね?
「Python信者」じゃなくて「Pythonエキスパート」。これなら本人も納得するでしょ。


484 :デフォルトの名無しさん:2010/10/13(水) 09:02:41
>>481
でもPHPとRubyが嫌いな理由はちゃんとあるんだろ。あれだけ書いてるんだし。

>>482
括弧書きたいなら、括弧の省略を許さないPythonは最適じゃないか。
流れを変えようとする自演乙。

485 :デフォルトの名無しさん:2010/10/13(水) 09:09:34
>>479>>483
何がしたいの?言語の話する気ないなら死ねよ

486 :デフォルトの名無しさん:2010/10/13(水) 09:15:41
>>484
括弧ってブレースのことじゃないの

487 :デフォルトの名無しさん:2010/10/13(水) 09:22:19
つかDRYを強調してるのは主にRailsじゃね?
上の方にも出てたけど、RubyとRailsごっちゃにしてね?
あとシンボルの意味がわかってなくて、なおかつ理解しようとしてない人のRubv批判なんかまったく信憑性なくね?

ちゃんと使ってから文句言えよ(キリッ

488 :デフォルトの名無しさん:2010/10/13(水) 09:27:44
1995 - オーストラリアがモヒカン刈りの戦士とティナ・ターナーの疾走する砂漠になると
いう漠然とした啓示の実現を回避するため、ユキヒロ・“Mad Matz”・マツモトがRubyを作る。
この言語は後に本当の作者であるデビッド・ハイネマイヤ・ハンソン(DHH)によりRuby on Railsと改名された。
[MatzがRubyという言語を作ったというくだりは間違いだから次に改訂するときに取った方がいいよ ? DHH]

489 :デフォルトの名無しさん:2010/10/13(水) 10:23:28
>>486
>>482は大抵の言語大丈夫つってるから、多分ブレースでもないんじゃね
FORTRAN, COBOL, PASCAL, BASICとかは大丈夫なんだろうし

サードアイを開く訓練が必要だな!

490 :デフォルトの名無しさん:2010/10/13(水) 10:42:10
PHPのrequireが遅いのは、include_pathを探索してファイルの更新チェックをするために、ものすごい量のシステムコールを発行したりするからだね。
デプロイを簡単にするために、パフォーマンスを犠牲にしてるんだよ。フレームワークとかの問題じゃない。
個人のTwitterの愚痴にいちいち反応してる粘着こえーな。

491 :デフォルトの名無しさん:2010/10/13(水) 10:44:57
「Ruby 環境は憶えないといけないことが多いので嫌」ってだけのことで、
そんなもん「慣れた奴が気分よく使えればいいんじゃね」でおわる話だろ。
ギャアギャア噛み付くことじゃあない。

実際 Python と比べて憶えないといけないことが多いのかどうかは知らん。
空文字が偽になる言語は嫌いだからまともに使ってないので。

492 :デフォルトの名無しさん:2010/10/13(水) 11:00:53
$ irb
irb(main):001:0> if "" then "t" else "f" end
(irb):1: warning: string literal in condition
=> "t"

493 :デフォルトの名無しさん:2010/10/13(水) 11:09:24
> 空文字が偽になる言語
これってPythonのことじゃないの

494 :デフォルトの名無しさん:2010/10/13(水) 11:10:04
>>490
じゃぁrequire_onceは遅くないってこと?

495 :デフォルトの名無しさん:2010/10/13(水) 11:28:09
他言語はフレームワークを取り上げて批判してるのに、pythonは言語自体の良さを主張してフレームワークには触れてない
信者の意見なんて偏ってるもんだから仕方ないかもしれんが

496 :methane:2010/10/13(水) 11:51:32
>>479
>symfony以外のフレームワークは試してみた?

私が直接チューンを手伝ったのはSymfonyプロジェクトですが、Cakeで作ったアプリも大概でしたよ。
で、SymfonyではなくてPHPが悪いと言っていているのは、Symfonyをチューンしていてぶつかったのがrequireという
PHPならではの問題だったからです。

>もしPHPが本当に遅いなら、他のPHPフレームワークより遅いPythonフレームワークがあるのはなんで?

具体例を挙げてもらわないとボトルネックの指摘はできません。サーバーの選択ミス(Djangoの開発版サーバーとか)
かもしれませんし、すごく重いテンプレートエンジンやO/Rマッパーを使っているのかもしれませんし、
1プロセスあたりのコネクションプール数が足りなくてコネクションの取り合いをしているのかもしれません。

しかし、PHPとPythonでインタプリタ自体の速度差は大した事は無いので、同じような構成で同じような
処理をするのであれば、処理時間だけのPythonと起動時間+処理時間が必要なPHPではPHPの方が絶対に遅くなります。

加えて言うと、起動時間まで含めたチューニングはとても面倒です。ループでは計測できないので複数回実行する必要があり、
APCを有効にするためにApache経由で動かす必要があり、abで負荷をかけたときの速度はあまり安定しません。

>>490
Symfonyはクラスとファイルの絶対パスとの組み合わせをキャッシュして絶対パスでrequireするので、探索コストはあまりかかりません。
どちらかと言うと、メモリ管理と、名前空間の構築がネックです。
例えば1クラスをロードするのにも、クラス名、クラスオブジェクト、メソッド一覧を保存するHashTable、メソッド名、メソッドオブジェクト、
コードオブジェクト、、、と、大量の emalloc がインタプリタやAPC内部で実行されますし、名前の数だけHashTableへの挿入が実行されます。
OProfileでプロファイリングしたら確認できると思います。

497 :デフォルトの名無しさん:2010/10/13(水) 12:23:11
>>495
文盲のPHP信者は黙ってろよ。

498 :デフォルトの名無しさん:2010/10/13(水) 12:46:48
>>493
Python の空文字は None だから false だ

499 :methane:2010/10/13(水) 13:06:51
>>498
空文字とNoneは別物です。
Pythonでは一般的に、コンテナ型は空(len(x) == 0)のときに偽と判定されます。
便利なことも多いですが、Falseと空コンテナを区別したいときは明示的に比較しないといけませんね。

500 :デフォルトの名無しさん:2010/10/13(水) 14:15:15
Pythonはfilterの使い勝手の悪さがな…まあ、lambdaの仕様のせいなんだが
内包表記が読めるようになるまでは苦痛だった
内包表記に慣れるとmapも要らなくなるのは良いけどさ

Rubyの偽はnilとfalseだけなのは良い仕様だと思う
ゼロは機械語やC言語、空文字は過去のスクリプトの仕様を引きずってるだけかと
空リストは関数型なら必要だと思うが、手続き型なRubyなら偽にする必要はないね

501 :デフォルトの名無しさん:2010/10/13(水) 14:35:33
>>500
nonlocalとかも嫌だな
まあ2.Xではnonlocalすらないけど

def f(n) {{i -> n += i}}

みたいなのを

def f(n):
 def g(i):
  nonlocal n
  n += i
  return n
 return g

とか書かないといけない

502 :methane:2010/10/13(水) 14:35:37
>>500
私もPython始めたころは内包表記は読めるけど書けませんでした。でも、内包表記がかけなくても
ループで書けば良いので、lamdaの制限が悪いとは思いません。
lambdaはフレームを毎回作成するのが重いので、柔軟性と性能を両立するために内包表記を
推奨しているのは正しいと思います。

真偽に関しては、私は一貫性さえあればどの仕様でも良いと思います。
Rubyの仕様も良いと思いますが、Pythonの仕様もオプション処理などで「Noneか空」を偽と判定する
事が多いので便利ですよ。
一方、PHPの "0" が偽になるのは、文字列型なのに数値型としての性質で真偽が決まるので
好きではありません。
C++でプログラミングを覚えたので、数値型とブール型が混ざるのには違和感が無くても、
文字列型と数値型が混ざるのにはすごく違和感を覚えます。

503 :methane:2010/10/13(水) 14:47:32
>>501
nonlocalは確かに一見ダサいけど、 global と一貫性は取れてるし、
ローカル変数に比べると非常に利用する機会が少ないので、別に悪くは無いと思います。
動的言語の名前空間はコンパイル時に決定できる部分とできない部分の境界を言語仕様で
綺麗にまとめるのが難しいです。

ちなみに、キーワード名自体のダサさは意図的なものです。どうせ頻出するキーワードじゃないし、
後付けなので、既存のコードをgrepしまくって使われてない名前を選んであります。

504 :デフォルトの名無しさん:2010/10/13(水) 15:09:14
>>503
ダサいっていうか、この例だと単純に上の奴に比べて行数6倍になってるよね

・自由変数の参照にnonlocal文が必要
・代入は文である
・無名関数の中で文はかけない
・普通の関数では明示的なreturn文が必要

といった要因が組み合わさってどんどん長くなる
そのへんがLLとしてはいかがなもんかな、と

Pythonのgeneratorは便利でいいと思う
つーかそこが売り(だと思う)なのにitertoolsとかいう長い名前のモジュールに
重要な関数を押し込める必要ないのに、とは思うけど

505 :デフォルトの名無しさん:2010/10/13(水) 15:14:48
>・自由変数の参照にnonlocal文が必要
「更新」だね、スマソ

506 :methane:2010/10/13(水) 15:25:21
>>504
LLというかスクリプト言語としては、確かに指摘されている点は面倒ですね。
その辺は、アプリケーションからスクリプトまで一つのLLで済ませたいかどうかだと思います。

ただし、nonlocalについては面倒という以前に殆ど使いません。
たとえば、上記の例だと、Pythonだと普通ジェネレータにします。
# itertools.count 同等のコード
def make_counter(start=0):
    while True:
        yield start
        start += 1

507 :デフォルトの名無しさん:2010/10/13(水) 15:27:57
PythonとPHPのフレームワークでのベンチマークは>>397ですでに出てる。
フレームワークはものによって速度に大きな違いがあって、Djangoよりも速い
PHP製のフレームワークもあれば、Python製でも遅いTurbogearsのようなものもある。
すでに指摘されているのにそれを無視して、自分が知っているフレームワークだけで
「PythonはPHPより綺麗で効率的」と決めつけているから、信者。
でもスレ的には信者は大歓迎。なんったってバトルロワイヤルだからね。
まさにこんな信者を待っていたww


508 :デフォルトの名無しさん:2010/10/13(水) 15:31:58
>>506
そのコードは上の例と等価じゃないよ




509 :methane:2010/10/13(水) 15:32:00
>>507
ベンチマークだけとってなぜ遅いのかを解析せずに結論出しているような風に取られるのは心外です。
私の主張は、
> 同じような構成で同じような処理をするのであれば、処理時間だけのPythonと起動時間+処理時間が
> 必要なPHPではPHPの方が絶対に遅くなります。
というものです。Symfony云々は例でしかありません。

510 :デフォルトの名無しさん:2010/10/13(水) 15:42:32
>>463
>Rubyを煽っているように読めるのは、Rubyの人からの反応を見たかったからです。

わざとかーーー!

> PythonよりRubyの方がスラスラ読めたという感想とか、Rubyのコードをスラスラ読むためのカギなどあったら
> 教えてください。

カギはRubyを勉強することです。Symbolもわかってないのに「Rubyのコードが読めない」とかいいがかりすぐるwwwww
Pythonいいかげんにしろwwwww


511 :methane:2010/10/13(水) 15:46:16
>>508
はい、等価ではありません。
Pythonでカウンタを作る場合にはcallbleよりもiterableを返す方が一般的です。
もしどうしても callable がほしいケースであれば、 count = make_counter(); return count.next でいけます。

>>507
ついでに、>>397のどのグラフor表を見てます?
私にはCodeIgniterよりもDjangoの方が3〜4倍速いように見えるのですが?
ab -c100 だとCIが91req/secに対してDjangoが590req/sec
siege のConcurrent=200 だとCIが126trans/sec に対して Djangoが357req/sec
TurboGearsもDjangoよりは遅いものの、他言語勢は蹴散らしてますよね?

512 :methane:2010/10/13(水) 15:55:42
>>510
>カギはRubyを勉強することです。Symbolもわかってないのに「Rubyのコードが読めない」とかいいがかりすぐるwwwww

やはりちゃんと勉強しないと読めない言語なんですね。別にそれが悪いこととは言いません。
私のTwitterの発言は、Pythonだと記号が少なく構文がシンプルで初心者でも関数リファレンスだけ
見れば大抵のコードが読めるから、複数の言語のプログラマーの共通言語としてのLLとして良いよね、
という意味です。

513 :デフォルトの名無しさん:2010/10/13(水) 15:59:19
カッコの省略が、脊髄反射的にRubyのコードに対し「読めない」感を持たせる原因じゃないかと俺は思う。
というか俺の場合そうだった。単純に、慣れるしかないと思うけど。

514 :デフォルトの名無しさん:2010/10/13(水) 16:03:03
>>511
……だから注意したのに、全然よく読んでいないのね
Pythonの例もあるんだからまさか読めないわけでもあるまいに

>>501は、単に1ずつインクリメントしたいのではない
h = f(2)
h(3) --> 5
h(6) --> 11
のように動作するんです

わかりましたか?

515 :デフォルトの名無しさん:2010/10/13(水) 16:03:28
>>512
Python は、Ruby に比べて構文は単純だし、構文的にブロックみたいなものはないしで
一見とっつきやすそうだけど、ジェネレータとかは一見わかりやすいようで、意味を
把握するのは Ruby のブロックなみに難しいと思うし、基本的なデータ型の操作が
メソッドの形でないので、覚えなくてはならないことが多いし、似たようなもんだと思う。

516 :デフォルトの名無しさん:2010/10/13(水) 16:07:36
>>515
遅延計算が(慣れていない人にとっては)むずかしいのは
別にPythonのせいではないと思うよ
Haskellが分かりにくいといわれるのも、結局その辺が理由なわけだから
(もちろんそれだけではないが)

517 :デフォルトの名無しさん:2010/10/13(水) 16:09:05
もうどうでいいお

518 :methane:2010/10/13(水) 16:26:12
>>514
すみません、よく読まずに勘違いしてました。
確かに、nonlocalが無いとストレートに書けない、例ですね。

無理に関数オブジェクトにしないという選択肢があるので、現実世界で遭遇するのは本当に稀です。
obj.sum = 2 # obj は他の場所と共有できる。
obj.sum += 3
print obj.sum # 5
obj.sum += 6
print obj.sum # 11

519 :デフォルトの名無しさん:2010/10/13(水) 16:39:39
def f(n):
  while True:
    i = (yield n)
    n += i

g = f(2)
next(g)
g.send(3) #=> 5
g.send(6) #=> 11

520 :デフォルトの名無しさん:2010/10/13(水) 16:45:23
>>516
遅延計算?

Haskellの遅延評価と、Pythonのジェネレータとは、基本的には違うものだと思うけど。
遅延ストリームの実装にジェネレータが使えたりとかそういう関連はあるけど。

yield という魔法のキーワードがメソッド中にあると、一見ただの関数なのに、関数とは
違う、そこに書かれたコードを実行するイテレータを返すジェネレータ関数というものに
なってしまう、というのは、Ruby のブロックなみに難しいと思うけどね私は。

で、それはHaskellの遅延評価の難しさとはぜんぜん関係ない。

521 :デフォルトの名無しさん:2010/10/13(水) 16:46:05
メソッド中→関数中

522 :デフォルトの名無しさん:2010/10/13(水) 16:52:34
>>520
なるほど、「そこ」を難しいと思うのならそうかも
コルーチン的な動きをするわけだから

ただ、そこは「分かればいい」話だし、yieldなんてC#やJS(の新しいやつだっけ?)
にもあるようなもんだから、個人的には全くスルーしてて、
遅延評価的に動くのを「難しい」と言ってるんだと勝手に思ったのよ俺は

523 :デフォルトの名無しさん:2010/10/13(水) 16:58:13
わざと書いてるそうなのでPythonの人に聞きたいんだけど、なんでそんなに他の言語が憎いの?
たとえばこれとか、Rubyが憎いきらいだから書いてるんだよね。
> Pythonの名前付き引数は見た瞬間理解して感動したが、Rubyのシンボルは今でも調べてないので
> 理解できていない。多言語プログラマの共通言語として、Pythonは素晴らしいと思う。
Rubyのシンボルなんて、基本中の基本なのにそれを調べようともしてないし、
それが理解できないからって「多言語プログラマの共通言語として、Pythonは素晴らしい」と
いう結論はどうかと思う(PythonよりJavaScriptでしょ)。まあ信者だから仕方ないんだろうけど。
#これで「Rubyは嫌いじゃありません」という回答だったら笑えるけど。
#あれだけ書いておいて「嫌いじゃない」なんて、だれも信じないし。
Pythonのキーワード引数だっけ?あれは最初みたとき代入してると思ってたけど違った。
じゃあ「Pythonのキーワード引数は代入と勘違いするから嫌い」と書いたらバカだよね?
それと同じだと思うけどね。「Rubyにくけりゃシンボルまで憎い」じゃないけど、なんでそんなにRubyや他の言語を嫌いのか教えて。


524 :methane:2010/10/13(水) 17:01:39
>>519 うまい!
yield式も可読性が悪いのであまり使われないけど、レアケースにおいては非常にコードを簡潔にできますね。
nonlocalと違って2.5以降で使えるのがうれしい。

525 :デフォルトの名無しさん:2010/10/13(水) 17:03:04
>>523
シンボル知らないってことは、当然だがLispやSmalltalkも知らないんだろうね

ま、面白いから、生暖かい目で見守ってればいいのさ


526 :デフォルトの名無しさん:2010/10/13(水) 17:17:13
> PythonよりJavaScriptでしょ

それはない。ありえない。

527 :methane:2010/10/13(水) 17:21:28
>>523
繰り返しになりますが、Pythonは初心者だったときも他人が書いたコードをすらすら読めたのに、
Rubyは現在初心者ですが、他人が書いたコードをすらすら読めないと感じています。
Twitterでそれをつぶやいているのは、共感意見が多ければ本当にそういう傾向があるんだろうし、
反対意見が多ければ単に僕の勘違いなので、そういった意見が欲しかったのです。

Rubyのシンボルは、意味は調べて Python の intern(s) と同義だと理解しましたが、なんで記号や
専用の構文を割り当てるほどの意味があるのかまではまだ理解できていません。
反応が「シンボルはしょうがないねー」だったらシンボルだけ特別なんだと納得できるのですが、
「シンボルも判らないで」と批判されるとやっぱりRubyは一見さんお断りな言語なんだなと感じます。
ここでは後者の意見が多いですが、Twitter上では前者の意見もありました。

あまり使いたくない他の言語も挙げておくと、
Perl : 他人の書いたコードどころか、1年経ったら文法忘れて自分の書いたコードも読めなかった。
モダンPerlとか言ってオブジェクト指向のために非標準ライブラリを使ったり面倒な書き方をするのも悪印象。
JavaScript: スタンドアロンで使う為の標準的な実装とライブラリが判らない。あくまでもブラウザ内での言語だと思う。
ActionScript: JavaScriptと同じく、Flash内の言語であって、それ以外では環境が整っていない。

528 :デフォルトの名無しさん:2010/10/13(水) 17:26:02
Rubyのシンボルなんてただのhashだろ

529 :デフォルトの名無しさん:2010/10/13(水) 17:27:09
Lispを知ってたら、ああ、シンボルね、で終わりなんだよなぁ...

というわけで、背景知識がこの人の場合Python向きでした、ということで終わりな気がする。

530 :methane:2010/10/13(水) 17:32:34
>>529
なるほど、僕の場合背景知識がC++やJavaだったのでPythonがとっつきやすかったのに対して、
SmalltalkやLispが背景知識の人にとってはRubyがとっつき易いという事でしょうか?

531 :デフォルトの名無しさん:2010/10/13(水) 17:33:39
>>「シンボルも判らないで」と批判されるとやっぱりRubyは一見さんお断りな言語なんだなと感じます。
結局はこういう極論もちだすから信者って馬鹿にされるんだよw

お前Pythonはチュートリアル読めば簡単に理解できるって言って
Rubyはチュートリアル読んでないのか?シンボルはチュートリアルの範囲を超えてるほどのことなのか?


532 :デフォルトの名無しさん:2010/10/13(水) 17:44:29
rubyはきもいと感じ内でもない
儲が、と言う話しでもあるけど。


533 :デフォルトの名無しさん:2010/10/13(水) 17:45:11
シンボルは別にそんなに難しい話じゃないよ
どの言語でも内部的には同じだと思うが、よく使う文字列をハッシュテーブルに
登録してやることで、文字列比較じゃなくてアドレスやIDみたいなもんで
比較できるようにするんだよ、そのほうがずっと高速で扱いやすいからな
これをinternという

出自はLispだと思うが、JavaのStringにもintern()というメソッドはあるし
XやWindowsにもこれを実現するための専用の仕組(Atomという)がある
Pythonだって、短い文字列リテラルを内部的にinternしてると思ったぞ

534 :methane:2010/10/13(水) 17:47:14
>>531
例えば、Pythonのキーワード引数は、チュートリアルを流し読みするだけで使い方も何が嬉しいのかも理解できました。
C++で同じ型の引数の順序を間違えてハマッた経験があるので、始めて見たときから可読性の高い構文だなと感動しました。
http://www.python.jp/doc/2.5/tut/node6.html#SECTION006720000000000000000

Rubyのシンボルは、構文だけは判るものの、具体的にどう使うのか、何が嬉しいのか判らないので、
実際にシンボルを使ったコードを見たときに「コレなんだっけ?」となってしまいました。
http://doc.ruby-lang.org/ja/1.8.7/doc/spec=2fliteral.html#hash

たぶん、関数という背景知識があるからキーワード引数が直ぐに理解できて、シンボルは背景知識が無いから
理解できなかっただけなんでしょうね。

535 :methane:2010/10/13(水) 17:51:22
>>533
はい、internはもちろん知ってますし、最適化のために使ったりもしています。
PHPも5.3からは関数名等が自動的にinternされるようになってずいぶん速くなりましたよね。

結局、シンボルって intern("foo") 以上の意味や専用の使い方は無いんですね?

536 :デフォルトの名無しさん:2010/10/13(水) 17:56:36
>>535
> 結局、シンボルって intern("foo") 以上の意味や専用の使い方は無いんですね?

いや実装がそうだというわけで、用途がそうだというわけじゃないよ
Lispだとシンボルは文字列がわりにもなるし
シンボルに値や関数を束縛するので、変数にもなる

537 :デフォルトの名無しさん:2010/10/13(水) 17:59:12
>>530
俺はJavaPHP流れだけど余裕でRuby選ぶよ

538 :methane:2010/10/13(水) 18:00:59
>>536
あぁ、やっぱり専用の構文になっているのは、internをコンパイル時に実行して高速化する以上の意味があるんだ。。

先ほどTwitterでもつぶやいたんですが、単純にPythonは公式チュートリアルがあって構文の使い方まで
説明しているのに対して、Rubyはあくまでもリファレンスであって構文の使い方、何が嬉しいのかが説明されて
いないんですよね。
RubyはWeb上に丁寧な公式チュートリアルってありますか?そっちを読めば他人の書いたRubyコードも
すらすら読めるようになるかもしれません。

539 :デフォルトの名無しさん:2010/10/13(水) 18:01:05
Javaは正直あまりくわしくないんだが、確か1.5あたりでenumが追加されたんだよな
ああいうのは、本来シンボルがあればシンボル使えばいいような話だと思う

540 :デフォルトの名無しさん:2010/10/13(水) 18:01:42
なんかな。本来比較対象でないものを必死に比較対象にしてる感がひしひしとするのよね。
Pythonのキーワード引数と、Rubyのシンボルって。
確かにRubyにはキーワード引数がなくて、シンボルをキーにしたハッシュを渡すことで代用するから、
似たような場面で出てくるという関連がないわけじゃないけどさ。

どこが違うと言われたら :foo のようなリテラルの記法があって、id になってるもの、としか
言いようがないけど。
ハッシュのキーにすると、文字列だと毎回ハッシュ値を計算するので性能が落ちるけど、
シンボルなら id だから速いとか。

541 :デフォルトの名無しさん:2010/10/13(水) 18:03:02
> RubyはWeb上に丁寧な公式チュートリアルってありますか?そっちを読めば他人の書いたRubyコードも
> すらすら読めるようになるかもしれません。

ありません。
ていうかどれが公式でどれが非公式なのか線引きさえよくわかんないぐらい。

542 :methane:2010/10/13(水) 18:06:25
>>540
キーワード引数を例に挙げたのは、>>523 がシンボルに対してPython側の判りにくい構文の例として挙げたからで、
同じような機能だという主張はしていません。

543 :デフォルトの名無しさん:2010/10/13(水) 18:10:08
結局 Ruby のチュートリアルが判りにくいっていう話で FA?

544 :methane:2010/10/13(水) 18:23:45
>>541
了解です。社内にはRuby書きが何人かいるので、お勧めの本を借りて斜め読みしてみます。
Pythonに比べて記号を多用するのは可読性の点でやはり好きではありませんが、入門書を読めば
Rubyもすらすら読めるようになるかもしれません。


あと、PHPについて >>507 とか >>397 とか、「言語には関係ない、ただのフレームワークの問題だ」
という意見の方は、>>511 に反論ありますか?

545 :デフォルトの名無しさん:2010/10/13(水) 18:28:17
Rubyは本買えってことだよ。実際,Rubyの方が圧倒的に本が多い

546 :デフォルトの名無しさん:2010/10/13(水) 18:40:51
糞本ばっかじゃねーか

547 :デフォルトの名無しさん:2010/10/13(水) 18:44:40
なんで関係のないPerlが貶されないといかんのだ。
しかも、文法忘れたから読めないって、そりゃ、どんな言語でもそうだろうに。
プンスカ。

そんな私から見れば、Rubyの方が読みやすい。
こんなもん、知識量や偏りで左右もんだろうに、クソッタレ。

548 :デフォルトの名無しさん:2010/10/13(水) 18:46:58
Pythonを叩くスレだからPerlは関係ありませんよね^^;

549 :デフォルトの名無しさん:2010/10/13(水) 18:47:36
>なんで関係のないPerlが貶されないといかんのだ。

その原因を作ったのは Matz 本人だろ

550 :デフォルトの名無しさん:2010/10/13(水) 18:49:13
るびまの固定コンテンツ「Ruby の歩き方」で紹介してるのは、るびまの過去の連載か。
ttp://jp.rubyist.net/magazine/?0002-FirstProgramming

これが一番公式っぽいチュートリアル、ってことになるのかなぁ。

551 :デフォルトの名無しさん:2010/10/13(水) 18:49:31
>>547
何が「驚き最小限の原則」だよって話だな
Rubyで書かれたコードの美しさにいつも驚かされてるぞ

552 :デフォルトの名無しさん:2010/10/13(水) 18:50:05
いろいろな言語使ってきたやつはPython派が多い気がする


553 :デフォルトの名無しさん:2010/10/13(水) 18:51:16
>>551
当然皮肉だよな

554 :デフォルトの名無しさん:2010/10/13(水) 18:52:14
Rubyはプログラムが好きというより、物作りが好きなやつが多い気がする

555 :デフォルトの名無しさん:2010/10/13(水) 18:52:48
555

556 :デフォルトの名無しさん:2010/10/13(水) 18:53:26
驚き最小の原則なんて、Rubyではだいぶ昔に放棄されてるぞ。

557 :デフォルトの名無しさん:2010/10/13(水) 18:53:33
>>554
漏れはもの作り好きだけどPython派

558 :methane:2010/10/13(水) 18:58:04
http://www.swlab.it.okayama-u.ac.jp/man/ruby/uguide/uguide15.html
コレ見てシンボルの利用例が少しわかった。

Pythonだと関数やメソッドももただのオブジェクトでしかも括弧の省略ができないから、
foo = staticmethod(foo) # fooは関数
ってできるけど、Rubyだと関数を普通の変数として扱えないから、
private :foo
みたいに、シンボル経由で呼び出してるんですね。

http://www.ruby-lang.org/ja/man/html/Module.html
引数無しで呼び出したら、「それ以降」がprivateになるのか、、、C++のprivate: と同じだから良いんだけど、
構文じゃなくてただのメソッドのクセに影響範囲が予想外に広いのがちょっと気持ち悪い。

驚き最小の原則とか聞いたことあるけど、メソッドが見た目上構文に影響を与えるのは予想内なのかな。
それとも「メソッドが」みたいな論理的な予想じゃなくて、見た目と動作の間の驚きを最小にしてるのかな?

559 :デフォルトの名無しさん:2010/10/13(水) 19:09:28
考え方としてはPerlのTMTOWTDIが好きだな
プログラミング言語としては置いといて

560 :デフォルトの名無しさん:2010/10/13(水) 19:11:04
Rubyがおかしいんじゃなくてオブジェクト指向がおかしい
メソッドがオブジェクトなら、メソッドがcallメソッドをもつのか? おかしいだろ

561 :デフォルトの名無しさん:2010/10/13(水) 19:11:15
> Rubyだと関数を普通の変数として扱えないから、

だからそういう風にいちいちPythonに翻訳して考えていては、どんな概念でもまわりくどく
めんどくさくなると思うんですが。

> 驚き最小の原則

このへんで「驚き」を検索してみてくれ。
ttp://slashdot.jp/developers/03/03/14/0258247.shtml?topic=86

562 :デフォルトの名無しさん:2010/10/13(水) 19:34:22
今時ゴルフとか

563 :デフォルトの名無しさん:2010/10/13(水) 19:40:14
>>558
> Rubyだと関数を普通の変数として扱えないから、
これだと、Python は関数を値の入れものに使えると書かれてるように思える。

564 :methane:2010/10/13(水) 20:04:37
「少し気持ち悪い」は言い過ぎた。よく考えたらすごく特定要素のメソッドだし、別に問題ないや。

>>563
「関数は変数に代入されたオブジェクトじゃないから」といっても正確じゃないよなぁ。
実際、なんで Ruby は foo = bar で foo という変数に bar という関数を代入しなかったのか今でも不思議だ。
変数の仕組み自体(値ではなくてオブジェクトへの参照を格納するとか)はPythonに似てるのに。

565 :デフォルトの名無しさん:2010/10/13(水) 20:19:29
まぁパイソン信者の人はハナっから穿った見かたしてんだから、まともな比較なんかできてるわけないよな

仕方ないから、俺様がするどいパイソン批判をしてやる












パイソンはパイソンという名前がダサいから嫌い
だから使わない
パイパイとか人前で発せれないレベル

566 :デフォルトの名無しさん:2010/10/13(水) 20:20:17
Javaでクラスがオブジェクトじゃないみたいに、
メソッドはオブジェクトじゃない、という決定をしたから、なんだけど。
なんでそうしたかは知らない。Lisp-1じゃなくてLisp-2だね、みたいなことをどっかで
話してた記憶はある。

567 :デフォルトの名無しさん:2010/10/13(水) 20:20:28
>>518
遅レスだけど
「nonlocalが現実世界で遭遇するのは本当に稀」ってことはないんじゃないかなー

ま、まがりなりにもOO言語であるPythonなんだし、nonlocalとか言わなくとも
classで書けば勿論かけるよ?
こういう単純な例でclassをいちいち書いてたら、classとか__init__とかselfとか
タイプする分、格段に長くなるだけで
でも、classを持ってるOO言語の多くがクロージャをも導入していること、
Python自身もクロージャを持ってるということを過小評価してはいけないと思うんだ

少なくともPythonでは束縛された自由変数への更新を行うような
クロージャを書きにくいってのは、ただの事実なんだから、素直に認めればいいのに


568 :methane:2010/10/13(水) 21:49:47
>>567
> 少なくともPythonでは束縛された自由変数への更新を行うような
> クロージャを書きにくいってのは、ただの事実なんだから、素直に認めればいいのに

これに関しては最初から否定していません。

> 「nonlocalが現実世界で遭遇するのは本当に稀」ってことはないんじゃないかなー

Pythonでそれなりの量のコードを読み書きしてきましたが、nonlocal代わりにリストを使うなどのハックには
滅多に遭遇しませんでした。
例えばデコレータを作るときは受け取った引数を参照しかしません。
イベントハンドラを作るときは、そもそも更新する変数はローカル変数じゃなくてselfなどの属性になっている
ので、 self.foo += 1 とか self._on_hoge_changed() のように書きます。

むしろ、クロージャをまるで一時的に定義された定数のように参照することが多いので、

>>> L = [lambda: i for i in range(10)]
>>> L[3]() # 3 を期待してしまっているが、
9 # 関数オブジェクト定義後にiが書き換わっている。

この結果にハマった事の方が多いです。(GUIで複数個似たコンポーネントがあってそれぞれに同じような
イベントハンドラを設定する場合とか)

多分ですが、他の言語であればmap+lambdaとか、コード片を高階関数として使う場面で、Pythonはイテレータ、
ループ、内包表記を使うので、本当の意味でのクロージャはあまり利用されていない印象を受けます。

もちろん、nonlocalが無かったためにクロージャの利用が避けられていた面もあると思うので、Python3ではより
普通のクロージャがある言語に近づくと思います。

569 :デフォルトの名無しさん:2010/10/13(水) 22:08:39
>>568
要はPythonで書きにくいやりかたはPythonに慣れたユーザは最初から避ける、という
当たり前の結論だよね
俺もそうなんだろうと思うYO

自由変数を更新するクロージャってのはつまりイミュータブルなオブジェクトで、
Schemeあたりでそのように振舞う「もの」を書く場合は
そういう書き方になるんだけどね

だから、そんなものは現実にはないんだよ!みたいに言われると
えーっって感じなんだけど
Lispをご存知じゃないようなんで、仕方ないのかな

570 :methane:2010/10/13(水) 22:29:10
>>569
Lispっぽく書けないから避けてた面もあるでしょうが、そもそもLispっぽいのがPythonicじゃないから
避けてた面の方が大きいと思いますよ?
nonlocalができたからっていきなりlamdaが高機能になったりはしないだろうし、これからも
一時的なクロージャを高階関数に渡す書き方よりもイテレータを受け取ってループする書き方の方が
Pythonicであり続けるし。

nonlocalはpython3.0で導入されたけど、とりあえずPython3.2a3の標準ライブラリをgrepした限りは
symbol.py keyword.py pydoc_data/topics.py とテストからしかヒットせず、ライブラリ内では全く
利用されて無いようです。

571 :デフォルトの名無しさん:2010/10/13(水) 23:01:07
>>558
Module#method_addedを使えばprivateみたいのはRubyレベルで実装できるし、
そんなにキモくない。

メソッドがデフォルトでオブジェクトにならないのは括弧の省略やself省略等、
構文上メソッドを特別扱いするためだと思われ。メソッドがファーストクラスオブジェクト
でないのは欠点かもしれないけど、括弧等の省略による表現力の高さを考えると十分許容できる。

>>561も言ってるけども、RubyにはRubyの考え方があるんだから、一度それを受け入れてから
キモいのかそうでないのか考えるべき。自分でPythonicとか言っちゃうぐらいなんだから、
Ruby Wayがあることも理解できるでしょ。

572 :デフォルトの名無しさん:2010/10/13(水) 23:06:21
クロージャはOOじゃないからなあ
しかしOOを擁護しながらRubyを論破するのは無理だ
要領悪すぎる

573 :デフォルトの名無しさん:2010/10/13(水) 23:10:25
>>571
>括弧等の省略による表現力の高さを考えると十分許容できる。

いや、これは明確に失敗だったと思うけどな。

574 :571:2010/10/13(水) 23:18:06
>>572
何をもってOOというのかを考えるとキリがないけど、クロージャがOOでないと言うのは
言いすぎだと思うね。コードブロックを固めて持ち運べるようにするのがクロージャだからな。
そもそもRubyのクロージャはSmallTalk由来らしいし。

>>573
じゃあ君はrequireにもattr_accessorにもraiseにもpにもそしてprivateにも
括弧をつけたいのかい?
それらを予約語にすべきだというのなら、それはRubyの言語としての表現力を大きく
失なることになる。

575 :デフォルトの名無しさん:2010/10/13(水) 23:33:37
>>571
>メソッドがファーストクラスオブジェクトでないのは欠点かもしれないけど、

いや、Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。
つまりオブジェクトとメソッドは明確に区別されているわけで、
それを引き継いだRubyがメソッドをオブジェクト扱いしないのは自然なのよ。

メソッドを関数として扱うのは、LISP系のオブジェクト指向拡張の流れを組むもの。
LISPはラムダ計算が基本だから、関数が(他のデータ)と同様にファーストクラスであるのは当然。
そして、そういった関数型言語の影響を強く受けたPythonが関数をファーストクラスとして扱えるのも自然なこと。

その片方(Python)しか知らないmethane君が、他方(Ruby)を見て、自分の知ってるのと違うから変だ!間違ってる!と
Twitterで喚き散らすのも、恥ずかしいけど中学生にありがちなことではないかと。

576 :デフォルトの名無しさん:2010/10/13(水) 23:39:44
そんなこと言ったらどの言語も過去の流れを汲んでて素晴らしいってことになるじゃんw

577 :デフォルトの名無しさん:2010/10/13(水) 23:42:08
問題にしてるのは違いがあるという事実だけだろ
そこから先、どちらが良いかは宗教戦争だから
全部知ってるから全部良いと言おうが、一つ知ってる素晴らしいものと違うから良くないと言うのは同じことだよ

578 :デフォルトの名無しさん:2010/10/13(水) 23:47:20
>>574
Smalltalk由来ではなく、CLU由来らしいよ。

579 :デフォルトの名無しさん:2010/10/13(水) 23:49:17
>>575
> Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。

どうしてるび厨はよく知りもしないでそういう嘘をつくかなぁ。
はっきりいって、Smalltalk流儀のOOPLでメソッドがオブジェクトじゃないのはRubyぐらいだろ。

| methodObj |
methodObj := Integer compiledMethodAt: #factorial.
methodObj valueWithReceiver: 10 arguments: #() "=> 3628800 "

580 :デフォルトの名無しさん:2010/10/13(水) 23:50:12
>>579
るび厨というよりむしろ知ったかぶりな感じがする

581 :571:2010/10/13(水) 23:50:24
>>575
ああそうだったのか。むしろ自然なのか。
ってかTって小文字なんだorz

>>577
宗教だからどちらが良いかなんて関係ないって考えるのは思考停止だと俺は思う。
まあ、ほとんど宗教だけどな。

582 :デフォルトの名無しさん:2010/10/13(水) 23:50:56
さいきんついったでやってなかったか
MatzはSmalltalkほとんど知らんらしいぞ

583 :デフォルトの名無しさん:2010/10/13(水) 23:51:04
メソッドがfirst-classでオブジェクトじゃないのは
当時のmatzの趣味だか不勉強だかのせいかと。
が、今となっては明らかに言語内DSLの作りやすさというメリットの方が大きい。

584 :デフォルトの名無しさん:2010/10/13(水) 23:58:17
>>583
え、それはないでしょ。Smalltalkの話は置いておくとして、
もしメソッドがfirst-classオブジェクトだったら、今の形のrequireや
attr_accessorが実現できないじゃん。RubyがLispっぽいのはこういうところだし。

ブロックは今みたいな使い方がされるとは思ってなかったって、
どこかに書いてあったけど。

585 :デフォルトの名無しさん:2010/10/13(水) 23:59:32
RubyがLispっぽいとしたらそれだけでマイナス。ソースはLisp

586 :デフォルトの名無しさん:2010/10/14(木) 00:03:56
>>585
えーw
オマイにとってマイナスなだけで、多くのRubyistはRubyがLispのような
柔軟な言語であって欲しいと思ってるはずだ。

Lispがああなっちゃったのは、かっこのせいだ。かっこが少なくて、Lispに匹敵する
柔軟性を持つRubyこそ最強の言語。

と言ってみるテスト

587 :デフォルトの名無しさん:2010/10/14(木) 00:17:21
>>579
これはメソッドをオブジェクトに変換しているように見える
オブジェクトではないものをオブジェクトに変換しているのでは?

588 :methane:2010/10/14(木) 00:29:33
不勉強なのでLispはifすら関数とかそういうレベルの知識しかありませんが、、、

>LISPはラムダ計算が基本だから、関数が(他のデータ)と同様にファーストクラスであるのは当然。
>そして、そういった関数型言語の影響を強く受けたPythonが関数をファーストクラスとして扱えるのも自然なこと。

Pythonが関数をファーストクラスとしているのは、単に変数と名前空間を統一した方がシンプルだからであって、
Lispに習っているわけではないと思いますよ。
Paul Graham がPythonはLispだと言って明確に否定されていたし、Lispは参考にしている言語の一つではあるけど、
「Lisp系言語だからこういう仕様なんだ」ってのは違うと思います。

JavaScript だって、Lispを真似てではなく、関数の名前空間を汚したくないからという理由で function foo() よりも
var foo = function() という書き方が好まれる場合が多いですよね。

589 :デフォルトの名無しさん:2010/10/14(木) 00:43:50
> Lispはifすら関数
いやLispはごく普通の正格言語だからifを関数にはできないよ

仮にifが関数だったとしたら
(if expr then else)
って書いたら、expr, then, elseがまず評価されるってことね

590 :デフォルトの名無しさん:2010/10/14(木) 00:47:49
Pythonの方がRubyよりLisp(Scheme)っぽさを感じる
RubyなんてSmalltalkとPerlのあいのこだろ
たまたまPerlがLispに影響を受けてるだけで

591 :デフォルトの名無しさん:2010/10/14(木) 00:56:12
>>590
釣られないクマー

592 :methane:2010/10/14(木) 01:01:25
>>589
恥ずかしながら、 (xxx aaa bbb ccc) の形はすべて xxx という関数に aaa bbb ccc という値を渡す、
(if (X) (Y) (Z)) だと if は S式3つを受け取って、 (X) を評価した後に (Y) と (Z) のどちらかを評価すると
勘違いしてました。関数と式って別物なんですね。もう黙ります。

593 :デフォルトの名無しさん:2010/10/14(木) 01:09:24
>>587
> オブジェクトではないものをオブジェクトに変換しているのでは?

ほんとるび厨は自分の無知を棚に上げて言いがかりだけはいっちょ前だね。
#compiledMethodAt: の定義みて、どこで変換しているか言ってみろよ。

Behavior >> compiledMethodAt: selector
  ^ self methodDict at: selector

594 :デフォルトの名無しさん:2010/10/14(木) 01:22:30
>>586
テストって事は容赦なく叩いていいのか?
パーザーもろくにいじれない程度の柔軟性でよくLispに匹敵するとか臆面もなく言えるなと。

595 :デフォルトの名無しさん:2010/10/14(木) 01:25:19
>>564
> なんで Ruby は foo = bar で foo という変数に bar という関数を代入しなかったのか

というか、Pythonでは、その文は値がクロージャなだけで単なる変数から変数への代入だろう。
変数に入っているのがクロージャだから関数と呼ばれ、括弧を付ければ呼び出せるだけだ。
流石にRubyでも、barが(メソッドではなく)変数であれば、それをそのままfooへ代入するよ。

その上で、直接の理由は「bar」が(もし変数でないのなら)関数の呼び出しだから。
(正確にはメソッドの呼び出しだけれどね
 Pythonにあるのがクロージャの入った変数であるように、Rubyにあるのはself=トップレベルであるメソッド
 Rubyではクロージャが単独で存在することはあり得ない、手続きをパックするためのクラスはあるけれども)
括弧の省略が可能なRubyでその文がMethodオブジェクトの代入だとすると、それが
括弧が省略された引数無しのメソッド呼び出しなのか、Methodオブジェクトの代入なのか判らない。

じゃあ何故Rubyはメソッド呼び出しの括弧を省略可能にしたのか?3つの理由が考えられる。
Rubyという言語名からも判るがPerlを意識していたこと。
あと、括弧の有無も所詮は宗教でしかないってこと。括弧を付けない言語なんて沢山ある。

そして「属性」の実装に都合が良かったことじゃないかな。あくまで仮説だけれども。

Pythonでは「属性」の表現は簡単だ。何故ならオブジェクトが持つのは属性そのものだから。
メソッドも公開フィールドに「クロージャという属性」を入れたものに過ぎない。
それ故に括弧を付ければ呼び出しに、付けなければクロージャを取り出すことになる。

だがRubyは公開フィールドの存在を許さず、オブジェクトが持つデータは全て外部には非公開だ。
オブジェクトが持つデータへのアクセスは、全てメソッドを経由しなければならない。
そうすることで、カプセル化を言語仕様として強制している。

カプセル化強制と、Perlに由来する括弧省略は「一見すると属性に見える、メソッド呼び出し」
という形で上手くマッチしたんだと思うよ。

596 :デフォルトの名無しさん:2010/10/14(木) 01:36:54
ttp://togetter.com/li/54495
matzlispなんてのはジョークだと本人も認めてるしな

597 :デフォルトの名無しさん:2010/10/14(木) 01:38:05
>>592
> 関数と式って別物なんですね。
気になってしまったので……、
関数と式は比較対象ですか?
Lispでは全てが式です。Pythonのように式と文に分かれていません。
ただ、関数呼び出しと同様に表記できる、特殊フォームがあるだけです。

598 :デフォルトの名無しさん:2010/10/14(木) 01:39:44
>>579
>どうしてるび厨はよく知りもしないでそういう嘘をつくかなぁ。
>はっきりいって、Smalltalk流儀のOOPLでメソッドがオブジェクトじゃないのはRubyぐらいだろ。

何を根拠に言ってるのか分からんよ。>>579のコードならRubyでも以下のように書ける。

 methodObj = lambda { x | x.factorial } % オブジェクトの生成
 methodObj.call(10) --> 3628800 % オブジェクトヘメソッド call(10) を送信

逆にRubyでもSmalltalkでも書けないのは以下のようなコード(どちらも構文エラーになる)

 receiver = MyReceiver.new % 受信者オブジェクトの生成
 methodObj = lambda { x | x.factorial } % メソッドをオブジェクトとして生成
 receiver.methodObj(10) --> 3628800 % 受信者オブジェクトヘメソッドオブジェクトを送信

 | receiver methodObj |
 methodObj := [ :x | x factorial ]. "メソッドをオブジェクトとして生成"
 receiver methodObj: 10. --> 3628800 "受信者オブジェクトヘメソッドオブジェクトを送信"

すまんが、正しい事を言ってるつもりなら、適切な例(コード)に書き直してから反論してくれ。

599 :デフォルトの名無しさん:2010/10/14(木) 01:41:38
>>588
>Lispに習っているわけではないと思いますよ。

確かに、Lispという言葉の引用は不適切でした。関数型言語という言葉に置き換えてください。

600 :デフォルトの名無しさん:2010/10/14(木) 02:14:21
>>590
歴史的には、
・Carl Hewtt が SIMULA 67 と Smalltalk にヒントを得てアクター言語 Plasma を考案し、
・Guy L. Steele Jr. が Plasma を簡潔にしたLisp風の構文を持つ小さな言語 Scheme を開発。
・最初期のSchemeは、(Lispの関数を定義するラムダ式ではなく)、アクターを定義するアルファ式をモデルとしていた。
・アルファ式とは、今で言うところのCPS(継続渡しスタイル)そのもの、
ということらしい。-- bit/April 1996/Vol.28 No.4「Scheme 過去・現在・未来(全編)」による

Rubyが(細部に差異はあったとしても)Smalltalkを参考に作られたのは事実だろうし、
Schemeの継続(continuation)がLispを含む関数型言語全般に影響を与えたのも間違いない。
だから、PythonとRubyとで、どちらがLisp(Scheme)と似ているか?とか
どちらが強い影響を受けたのか?という話に、大きな意味は無かったりする。議論は自由だろうけどね。

601 :デフォルトの名無しさん:2010/10/14(木) 02:17:11
>>598
最低限、無名関数(Stではブロック。RbではProc)とメソッドの区別くらいはつけてから反論しようよ。
君、自分で気づいていないみたいだけど、言っていることめちゃくちゃだよ。
嘘だと思うならMatzに聞いてごらん。どこが違うかおしえてくれるはず。

602 :デフォルトの名無しさん:2010/10/14(木) 02:27:03
>>601
結局、自分の口では説明できないし、Smalltalkでは書けてRubyでは書けないコードは示せないのね。
了解した。(説明が面倒なら、コード書いてくれるだけでいいのに....。)

603 :デフォルトの名無しさん:2010/10/14(木) 02:30:26
>>601
判ってるなら自分で説明しろよケチ

604 :デフォルトの名無しさん:2010/10/14(木) 02:35:11
Rubyで書くとこうだよ。バカる厨どもが。

meth_obj = Integer.instance_method(:fact)
meth_obj.bind(10).call #=> 3628800

で、もう一匹のアホがこれに絡めて言いがかりをつけた587、それの反証の593に繋がるんだよ。
偉ぶる前に、自分のレベルが2段階ほど至っていないことにいい加減気づけよ。

605 :デフォルトの名無しさん:2010/10/14(木) 02:47:36
Rubyはなんで meth_obj.call(10) って素直に書けないの?

606 :デフォルトの名無しさん:2010/10/14(木) 03:06:38
Matzに技量がないから。

607 :デフォルトの名無しさん:2010/10/14(木) 03:31:56
ファーストクラスオブジェクトとしてのメソッド
http://yugui.jp/articles/741

608 :デフォルトの名無しさん:2010/10/14(木) 03:43:31
>>605
メソッドにはレシーバが必要。
メソッド内でのselfはどうすんの?

609 :デフォルトの名無しさん:2010/10/14(木) 03:57:13
>>604
えーと、>>601>>604は同一人物かな?違う人なのかな?もし別人だったら、スマンがスルーしてね。

>>598のカキコでは、>>575

>はっきりいって、Smalltalk流儀のOOPLでメソッドがオブジェクトじゃないのはRubyぐらいだろ。

この一文、これは、
・Smalltalkではメソッドもオブジェクトだから書けるのに、Rubyはそうじゃないから書けないコードがある。
・だからRubyはOOPLとして欠陥言語だ
と解釈した。ここまでは良いかい?

で、>>575で書いてくれたSmalltalkのコードが、その「Rubyじゃ書けないコード」の具体例だと解釈して、
>>598では「いや、Rubyでもこう書けるよ」と反論したわけ。
だから期待しているのは「Smalltalkでは書けるのに、Rubyでは書けないコード」なんだ。理解してもらえるかな?

>>604のコードはRubyでも書ける例だよね? 手元のRuby(1.8.7)で試したら、正しく動いた。
Ruby のクラス Integer にはメソッド fact は定義されていないから、代わりに modulo (商の余り)にしているよ。

 irb(main):024:0> meth_obj = Integer.instance_method(:modulo)
 => #<UnboundMethod: Integer(Numeric)#modulo>
 irb(main):025:0> meth_obj.bind(9).call(5)
 => 4

だとしたら、>>598への反論になっていないんだけど....。(>>601=>>604と仮定して)繰り返すよ、

「Smalltalkでは書けるのに、Rubyでは書けないコード」をお願いします。>>601

PS. アンカの付け方くらい学びなさいな。

610 :デフォルトの名無しさん:2010/10/14(木) 03:58:39
痛い

611 :609:2010/10/14(木) 04:00:33
自己レスで訂正。>>609内のアンカ>>575は間違い。正しくは>>579。スマン。

612 :methane:2010/10/14(木) 05:44:57
>>597
>>589 を受けてのレスです。(foo (x y)) の form で、もし遅延評価ならifも含めてすべて関数という扱いにすることが
できるけど、実際には関数は正格評価だから、foo が示すのは関数かもしれないし式かもしれないんだな、という
意味で「別物なんだな」と言いました。

>>607
Yuguiさんの考察、非常に参考になりました。

> でも、名前空間を一緒くたにすると「selfを省略可能」「引数の括弧を省略可能」というのは難しくなってしまう。
> Rubyとしては、高階関数を綺麗に書けることよりもこれらのほうが重要だろうと判断しての選択だ、
> とまつもとさんは言っていた。

確かに、Ruby方式には引数省略だけじゃなくて第一引数selfも自然に省略できるというメリットもありましたね。
Pythonだと第一引数を省略しようとすると、省略するかどうかを選ぶ構文の追加が必要になるので「タイプ数かわんねーし
構文規則が複雑になるだけ」と第一引数selfが残り続け、他言語ユーザーに「面倒そう」と思われる原因になってます。

613 :デフォルトの名無しさん:2010/10/14(木) 06:50:36
今更だけど気になったので

>>588
>JavaScript だって、Lispを真似てではなく、関数の名前空間を汚したくないからという理由で function foo() よりも
>var foo = function() という書き方が好まれる場合が多いですよね。
JavaScriptには関数の名前空間と変数の名前空間に区別は無い。
function foo() {} と var foo = function() {} はどちらもfooという変数に関数が代入される。
違うのは代入が行われるタイミング(スコープに入った時・文の実行時)

あとJavaScriptの設計者はScheme大好きで、ブラウザ上にSchemeを実装するつもりで作った言語らしいから、
Lispを真似てこういう仕様になった可能性は十分あり得る

614 :デフォルトの名無しさん:2010/10/14(木) 07:30:10
真似たというならLispというよりSchemeだな。
Scheme以外のLispはLisp 2が多い。

615 :デフォルトの名無しさん:2010/10/14(木) 09:02:37
>>609
メソッドがオブジェクトな Smalltalk には出来て、そうでない Ruby には出来ない事の例でもいいんだよね?

Integer.instance_method(:even?).eql? Integer.instance_method(:even?) #=> false

(Integer compiledMethodAt: #even) == (Integer compiledMethodAt: #even) "=> true "

念のため、Smalltalk の #== は Ruby の #== ではなくて、#eql? と等価なメソッドです。

616 :デフォルトの名無しさん:2010/10/14(木) 09:08:58
>>608
メソッドを関数と見なした場合、第一引数を self と見なすのが通常だから問題ないかと。

617 :デフォルトの名無しさん:2010/10/14(木) 09:48:58
>>612
揚げ足取りだと自分でも分かってるけど……、
> foo が示すのは関数かもしれないし式かもしれないんだな、
lispでは関数は結局ラムダ式
普通の関数とifが別物なのはそうだよ。

言語によって、同じ言葉でも意味が異なるので、「Pythonでいう何々」とか言ったほうがいいよ。

618 :デフォルトの名無しさん:2010/10/14(木) 09:56:49
>>609
> 期待しているのは「Smalltalkでは書けるのに、Rubyでは書けないコード」

書ける書けないということであれば、こっちの方がわかりやすいかな。

"Smalltalk"
Object compile: 'foo ^3'.
Object new foo. "=> 3"
(Object compiledMethodAt: #foo) literalAt: 1 put: 4.
Object new foo. "=> 4"

#Rubyでの擬似コード
class Object; def foo; 3 end end
Object.new.foo #=> 3
#これ以降は、Rubyのなんちゃってファーストクラスメソッドでは実現不可
Object.instance_method(:foo).literal[0] = 4
Object.new.foo #=> 4

619 :デフォルトの名無しさん:2010/10/14(木) 10:45:43
なかなかいい感じにスレタイ的展開が続いているな

620 :609:2010/10/14(木) 14:33:36
>>609
これは、Rubyがメソッド instance_method が呼ばれるたびに UnboundObject を新規生成しているのに対して、
Smalltalkでは(毎回新規生成するのではなく)セレクタをキーとする辞書の要素への参照を返しているという、仕様の差異ですよね。
だとすれば、「できる、できない」の話とはズレている気がしますよ。
RubyはSmalltalkの強い影響を受けていますけど、完全な互換性まで保証している訳じゃありませんから。
(Smalltalk -> Ruby コード移植を除くと、)普通のRubyプログラミングの中で、UnboundObjectが毎回生成されることが、
「なんちゃってOOPLとか欠陥言語」と言われるほどの問題であるとは、とうてい思えないのですが....。

>>618
コードの一部(Object compiledMethodAt: #foo)を 'Inspect It' してみたら、以下のように表示されました。

Squeak --> 9 <20> pushConstant: 3,  VisualWorks --> <D8 03> push 3

で、それに続くメッセージ literalAt: 1 put: 4 というのは、byte codeへのパッチ(pushオペランドの更新)ですね。
うーみゅ、確かにこれは「Smalltalkでは書けるのに、Rubyでは書けないコード」だ。おみそれしました。
というか、OOPL界広しといえど、こんなリフレクションを書けるのは(byte-codeへパッチを当てられるのは)Lisp系を除くと、
Smalltalkくらいのものじゃないかという気もしますけどw (.... Ruby 1.9 ならVMだから可能なのかな?)

そうか、本物のSmalltalkerからすれば、(エディタ/ブラウザ/GUI...etcを含む)完璧に統合された実行環境を含まないOOPLは、
すべからく「なんちゃってOOPLで欠陥言語」ということなのでしょうか? もしそうなら、大いに納得(同意)しますよ。
それを実現できているのは、Smalltalkしかありませんから。(当然、GNU-Smalltalkもなんちゃっての欠陥品ですよね)

621 :609:2010/10/14(木) 14:36:38
アンカーを間違えていました。>>620の最初の行にある>>609は誤りで、>>615が正しいレス先です。

622 :デフォルトの名無しさん:2010/10/14(木) 14:59:56
(CompiledMethod superclass) == ByteArray

ByteArrayの方が抽象度が高いというのがおもしろいね

623 :デフォルトの名無しさん:2010/10/14(木) 15:59:37
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import new
>>> def hello(): return "Hello"
...
>>> print hello()
Hello
>>> f = hello.func_code
>>> hello.func_code = new.code(f.co_argcount, f.co_nlocals, f.co_stacksize,\
... f.co_flags, f.co_code, (None, 'Goodye'), f.co_names,\
... f.co_varnames, f.co_filename, f.co_name, f.co_firstlineno,\
... f.co_lnotab, f.co_freevars, f.co_cellvars)
>>> print hello()
Goodye


624 :デフォルトの名無しさん:2010/10/14(木) 17:41:51
>>> def hello(): return "Hello"
...
>>> print hello()
Hello
>>> hello = lambda: "Goodbye"
>>> print hello()
Goodbye

625 :586:2010/10/14(木) 20:17:43
>>594
うんやっぱりS式は最強だよね。嫌いだけど。

626 :デフォルトの名無しさん:2010/10/14(木) 22:19:28
>>620
> 完璧に統合された実行環境を含まないOOPLは、
> すべからく「なんちゃってOOPLで欠陥言語」ということなのでしょうか?

なんでそう攻撃的になるの? わけわからん。
いちおうマジレスしておくと、Smalltalk の GUI や IDEツール群、ライブラリ等は、じつのところ飾りだし、
その一部、あるいは全部が Ruby に揃っていないから欠陥品だとか言いがかりを付ける奴は
はっきり言って Smalltalk のド素人だからそんなのは無視していいよ。

627 :デフォルトの名無しさん:2010/10/14(木) 22:25:07
多くの動的 OOPL では、メソッドはたいていオブジェクトで静的に関数としてもコールできる。
Smalltalk も同じ。ところが Ruby はメソッドいちいちオブジェクト化しないといけないし、
オブジェクト化してきてもその都度レシーバーを bind しないとそのままでは静的なコールもできない。

この事実を踏まえた上で、

>>575
> いや、Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。
> つまりオブジェクトとメソッドは明確に区別されているわけで、
> それを引き継いだRubyがメソッドをオブジェクト扱いしないのは自然なのよ。

って、Rubyが現状のような仕様であることを「自然」と思うかどうかは本人の勝手かもしれないけど、
そうなった事情を説明するのに Smalltalk を巻き込むのはどうかやめて欲しい。

Objective-C の nil のクソ仕様も、ともすると Smalltalk のせいにされがちでホント参っている。

628 :デフォルトの名無しさん:2010/10/14(木) 23:05:26
巻き込まれたくないなら「オブジェクト指向」なんてグループから抜けてしまえばいい
ただの手続き型なら、こんな下らないトラブルに巻き込まれずにすむ

629 :デフォルトの名無しさん:2010/10/14(木) 23:30:55
じゃあ俺Objective-Ruby作るわ

630 :デフォルトの名無しさん:2010/10/14(木) 23:40:53
>>620
>これは、Rubyがメソッド instance_method が呼ばれるたびに UnboundObject を新規生成しているのに対して、
>Smalltalkでは(毎回新規生成するのではなく)セレクタをキーとする辞書の要素への参照を返しているという、仕様の差異ですよね。
>だとすれば、「できる、できない」の話とはズレている気がしますよ。

これは、Smalltalkのメソッドエンティティがオブジェクトである一方で、Rubyのメソッドはそうではないという
証拠じゃないの? どっちの話がズレているのだか。

631 :デフォルトの名無しさん:2010/10/15(金) 00:02:21
>>623
さしもの Python にもこれは出来まい。w

| foo |
Object compile: 'foo ^3+4'.
Object new foo. "=> 7 "
foo := Object compiledMethodAt: #foo.
foo decompileString. "=> 'foo ^3+4' "
foo byteAt: 23 put: 16rB8.
foo decompileString. "=> 'foo ^3*4' "
Object new foo. "=> 12 "

632 :デフォルトの名無しさん:2010/10/15(金) 00:47:33
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import new
>>> import dis
>>>
>>> def add(x, y): return x + y
...
>>> dis.dis(add)
1 0 LOAD_FAST 0 (x)
3 LOAD_FAST 1 (y)
6 BINARY_ADD
7 RETURN_VALUE
>>> add(3, 4)
7
>>> f = add.func_code
>>> add.func_code = new.code(f.co_argcount, f.co_nlocals, f.co_stacksize,\
... f.co_flags, \
... f.co_code[:6] + '\x14' + f.co_code[7:], \
... f.co_consts, f.co_names,\
... f.co_varnames, f.co_filename, f.co_name, f.co_firstlineno,\
... f.co_lnotab, f.co_freevars, f.co_cellvars)
>>> dis.dis(add)
1 0 LOAD_FAST 0 (x)
3 LOAD_FAST 1 (y)
6 BINARY_MULTIPLY
7 RETURN_VALUE
>>> add(3, 4)
12


633 :デフォルトの名無しさん:2010/10/15(金) 01:20:44
>>632
あーいや。そうじゃなくてバイトコードの直接書き換え。
たしかPythonでは仕様で禁じられているから、処理系に手を入れない限り不可能なはず。
バイトコード列を新たに作って差し替えるって処理なら、Smalltalkではこんなかんじ。

| new |
Integer compile: 'add: other ^self+other'.
3 add: 4. "=> 7 "
new := (Parser new parse: 'dummy: other ^self*other' class: Integer) generate.
Integer methodDict at: #add: put: new.
3 add: 4. "=> 12 "

634 :デフォルトの名無しさん:2010/10/15(金) 01:26:19
>>633
うん、それは出来ないね
func_code自体は書き換えられるけど、属性がreadonlyなので
ここでは別のcodeオブジェクトを生成して突っ込んでるだけ

635 :デフォルトの名無しさん:2010/10/15(金) 03:32:02
> (defun add (x y) (declare (compile)) (+ x y))
ADD
> (disassemble #'add)
Disassembly of function ADD
2 required arguments
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0 (LOAD&PUSH 2)
1 (LOAD&PUSH 2)
2 (CALLSR 2 55) ; +
5 (SKIP&RET 3)
NIL
> (setf (aref (sys::closure-codevec #'add) 14) 57)
57
> (disassemble #'add)
Disassembly of function ADD
2 required arguments
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0 (LOAD&PUSH 2)
1 (LOAD&PUSH 2)
2 (CALLSR 2 57) ; *
5 (SKIP&RET 3)
NIL
> (add 3 4)
12

636 :デフォルトの名無しさん:2010/10/15(金) 09:25:27
>>622
> ByteArrayの方が抽象度が高いというのがおもしろいね

そう? コンパイル済みメソッドはバイトコード列だからバイト配列でっていう継承関係は
ごく当たり前のことのような気がしていたのだけれども。他の言語の感覚では違うのかな。

637 :デフォルトの名無しさん:2010/10/15(金) 10:31:25
>>636
カプセル化が当たり前の言語では、バイトコードは公開しない。
バイトコードを外から操作できたら、非公開メンバーも操作できるから。

638 :デフォルトの名無しさん:2010/10/15(金) 12:30:07
「カプセル化が当たり前の言語」って例えば?

639 :デフォルトの名無しさん:2010/10/15(金) 12:52:13
>>620
>というか、OOPL界広しといえど、こんなリフレクションを書けるのは(byte-codeへパッチを当てられるのは)Lisp系を除くと、
>Smalltalkくらいのものじゃないかという気もしますけどw (.... Ruby 1.9 ならVMだから可能なのかな?)

RubyでもRubiniusならできるね。OOPL界はけっこう広いよ。

def foo; 3*4 end
method(:foo).executable.literals[0] = :+
foo #=> 7

640 :デフォルトの名無しさん:2010/10/15(金) 14:59:45
>>638
Rubyじゃね
あれカプセル化が強制されてるし

641 :デフォルトの名無しさん:2010/10/15(金) 15:26:52
>>639
Lisp 系はソースコードがオブジェクトだった。
OOPL はバイトコードをオブジェクトにした。

でも結局 literalAt: や literals[] は
クロージャが自由変数を管理するのと同じテクニックだから
世界はやっぱり狭いと思う。

642 :デフォルトの名無しさん:2010/10/15(金) 16:17:47
>>640
Rubyがカプセル化を強制してるってならSmalltalkも同じな希ガス
バイトコード列をいじれる言語はカプセル化が当然じゃないって
主張なんだから矛盾するじゃん。Javaとかのことを言っているのかな。

643 :デフォルトの名無しさん:2010/10/15(金) 21:41:13
きっとものすごーく狭いOOPL界で満足できてる人なんだよ。

644 :デフォルトの名無しさん:2010/10/15(金) 23:03:32
>>641
>でも結局 literalAt: や literals[] は
>クロージャが自由変数を管理するのと同じテクニックだから

まったく意味不明なんだが、何とか解読してみると、
SmalltalkのliteralAt:put:はLisp由来でOOPL的ではないし異端だ、とかいう話?

645 :デフォルトの名無しさん:2010/10/15(金) 23:11:45
>>644
クロージャで同じことができるって意味だよ

my $bar = sub { $_[0] * $_[1] };
sub foo { $bar->(3, 4) }
$bar = sub { $_[0] + $_[1] };
print foo();

646 :デフォルトの名無しさん:2010/10/15(金) 23:55:56
TIOBE Programming Community Index for October 2010
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

PHP
http://www.tiobe.com/index.php/paperinfo/tpci/PHP.html
Python
http://www.tiobe.com/index.php/paperinfo/tpci/Python.html
Perl
http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html
Ruby
http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html

647 :デフォルトの名無しさん:2010/10/16(土) 00:54:08
Perlはもうだめだな
はやくきえてほしい

iPhoneはがんばってるな

648 :デフォルトの名無しさん:2010/10/16(土) 02:03:24
boostなんて出てきたし、Perlはいらない子だな

649 :デフォルトの名無しさん:2010/10/16(土) 05:07:08
それ、あんまり意味ある指標だとは思わない。
PHP 76件
Perl 27件
Ruby 19件
Python 4件

http://www.pasonatech.co.jp/index.jsp
キーワードで検索


650 :デフォルトの名無しさん:2010/10/16(土) 08:24:42
perl6は大幅変更なんだべ。

651 :デフォルトの名無しさん:2010/10/16(土) 11:15:22
>>442
>あと、Rubyはsuperの引数を省略すると、自分の引数がそのまま渡される。
>Pythonは普通に引数なしで呼び出す。Rubyの方がタイプ数少ないけど、特別な暗黙ルールを
>作れば作るほど、一見さんには意味不明になっていく

Rubyのsuperは引数なしだと現在の引数をそのまま渡すけど、これはsuperを呼び出す時は
多くの場合同じ引数をそのまま渡すケースが多いからそういう仕様になっているわけで、
理由がわかればすごく合理的な仕様ですよ。
「super」とあるだけで「同じ引数を渡している」ことが一発でわかるし、実際便利だし。
これはルールを増やすに値するだけの機能だし、そのルールだって別に難しくない。
それより「super(クラス名, self).メソッド名(引数1, 引数2, 引数3)」のほうがよっぽど・・・


652 :デフォルトの名無しさん:2010/10/16(土) 11:24:42
Rubyの場合
class ParentClass
 def initialize(arg1, arg2, arg3)
  # do something
 end
end
class ChildClass < ParentClass
 def initialize(arg1, arg2, arg3)
  super ← 同じ引数で呼び出していることがすぐわかる(もちろん勉強する必要はあるよ!)
  # do something
 end
end

Pythonの場合
class ParentClass(object):
 def __init__(self, arg1, arg2, arg3):
  # do something
class ChildClass(ParentClass):
 def __init__(self, arg1, arg2, arg3):
  super(ChildClass, self).__init__(arg1, arg2, arg3) ← なぜかクラス名が必要
  # do something

「.__init__(arg1, arg2, arg3)」はまだ許せるけど「super(ChildClass, self)」って何だよ。せめて「super(self)」だろ。


653 :デフォルトの名無しさん:2010/10/16(土) 11:54:05
>>439
>言い方が過激だけど、内容は間違ってないだろ?

間違ってるよ。最低限の勉強をしなけりゃ、Pythonでもコードを読むのは難しい。
この人がPythonをすぐ理解できたと言っているのは、Pythonでもほんと基礎的な部分だけでしょ。
ジェネレータや高階関数をPython学習しはじめの人がすぐに理解できるわけないよ。
Rubyのシンボルが理解できないというのは、単にシンボルという機能を持つ他の言語(Lispとか)を勉強したことがないだけ。
つまりバックグラウンドとなる知識がなかっただけだよね。それで他の言語を批判するのは間違い(というか勘違い?)。
新しい言語を学ぶときに、それを簡単に学べるかどうかは、持っているバックグラウンドの知識で大きく変わる。
なのに「Rubyは勉強しないと読めない」とか「Pythonはプログラマの共通言語として素晴らしい」と言っちゃてるんだから、批判されておかしくない。

ほかのPython使いの人はこの人に何も注意しないの?それとも本気でこの人のいうことが正しいと思ってるんだ、Pythonな人は。

654 :デフォルトの名無しさん:2010/10/16(土) 12:12:55
>>442
> Rubyの方がタイプ数少ないけど、特別な暗黙ルールを
> 作れば作るほど、一見さんには意味不明になっていく。

特別なルールはPythonにもたくさんあると思うけど、どうかね。
objectを継承する・しないで挙動が変わるとか。
関数定義の中にyieldがあると意味が変わるとか。
def f(n):
 for i in xrange(n):
  yield i # yield があるだけで普通の関数じゃなくなる

メソッド定義ではn個の引数だったのに呼び出す時はn-1個になってるとか。
class A:
 def f(self, n):
  print n
a = A()
a.f(1) # なぜか引数の数が減っている(そのせいで引数の数を間違えた時のエラーメッセージがわかりにくい)

インスタンスメソッドのはずなのにクラスオブジェクトを介して呼び出せるとか。
class Parent:
 def __init__(self):
  # pass
class Child(Parent):
 def __init__(self):
  Parent.__init__(self) # インスタンスメソッドのはずなのに?


655 :デフォルトの名無しさん:2010/10/16(土) 12:20:09
続き。
引数なしでraiseを使うとか。引数なしのsuperを批判するなら引数なしのraiseも批判されるべき。
try:
 # pass
except Exception:
 raise  # 例外オブジェクトを指定せずにraise?何のこと?

for文が実はイテレータを使っているとか。
class MyObject:
 def __iter__(self): ... # for文で使えるオブジェクトを作りたかったら
 def next(self): ... # イテレータを理解しないといけない(初心者にはムリ)。

listやstrは関数かと思ったら実はtypeだったり。
if isinstance(data, (list, tuple)): # あれ?listって関数じゃないの?

listがあるのになぜかtupleがあるとか。しかも書き方がわかりにくいし。
data = (1)  # これは数字の1
data = (1, ) # これは1を要素とするタプル

656 :デフォルトの名無しさん:2010/10/16(土) 12:28:40
ちょうど最近Pythonを勉強したから言うけど、Pythonだって勉強しないと簡単なプログラムすら読めない。
上で書いたのは、勉強した時に引っかかったところ。勉強なしでこれを理解するのは無理。
あとジェネレータとデコレータとメタクラスは勉強したけど理解できない。そのくせメジャーな機能っぽいから
これを理解できてないとオープンソースのコードが読めない。
Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった(未だにユニコードのエラーが解消できない)。
Pythonは勉強しなくても(あるいはちょっと勉強するだけで)すらすら読めるようになるというのは、ウソ。
ダイエットや英語教材のうさんくさい広告並みにウソ。


657 :デフォルトの名無しさん:2010/10/16(土) 13:00:04
Pythonは何かとめんどくさい。道具としてはRubyの方が優秀

658 :methane:2010/10/16(土) 15:02:06
super(MyClass, self) があまりにも面倒すぎるのはそのとおりで、実際Python3ではさすがに
ちょっと無理して(superの中でハック的なことをして)でも super() と書けるようになった。

でも、 super().__init__(arg1, arg2) なら、親クラスの同名メソッドを呼び出していることが一目瞭然だけど、
super だけだと同名メソッド呼び出してるんだろうなくらいまでは推測できても、まさか引数まで渡されてるとは
推測できない。superが通常の引数無しのメソッド呼び出し構文と同じだから。

>関数定義の中にyieldがあると意味が変わるとか。
ジェネレータや内包表記は確かに、チュートリアルの構文周りを一度でも軽く流し読みしてないと読めないね。
関数が無い言語から来たら関数が判らないのと同じレベル。

>メソッド定義ではn個の引数だったのに呼び出す時はn-1個になってるとか。
>インスタンスメソッドのはずなのにクラスオブジェクトを介して呼び出せるとか。
これって、初心者がコードを書くときの話であって、読むときの話じゃないよね?
むしろ、クラスの書き方のチュートリアル読まないでコード読んでも、selfをみて「Pythonではこうするんだ」って
推測できる。

>引数なしでraiseを使うとか。引数なしのsuperを批判するなら引数なしのraiseも批判されるべき。
まず、raiseは関数呼び出し構文と違うので、関数呼び出しのルールが通用しないのに不自然さはない。
問題にしているのは、見た目は完全に「引数無しの呼び出し」であること。
次に、省略されているのは例外オブジェクトだけじゃなくてスタックトレースなどの情報も含まれている。
raise e とかしてしまうと、その例外はそこから発生したことになってしまう。

>for文で使えるオブジェクトを作りたかったらイテレータを理解しないといけない(初心者にはムリ)。
繰り返しになるけど、僕は読むときの話をしていて、書くときの話をしていない。
さらに言えば、初心者はイテレータプロトコルを実装したオブジェクトを作らなくても、たいていの場合はリストを返せば事足りる。

659 :methane:2010/10/16(土) 15:10:08
>listやstrは関数かと思ったら実はtypeだったり。
list や str に限らず、全ての型は関数オブジェクトであって、呼び出したらその型のオブジェクトが返るようになっている。
全く特別ルールではない。

>listがあるのになぜかtupleがあるとか。しかも書き方がわかりにくいし。
>data = (1)  # これは数字の1
>data = (1, ) # これは1を要素とするタプル

要素が1つ、あるいは0個の場合は確かに特殊だね。
でも、これも書くときの問題であって、読むときに引っかかる部分ではない。
書くときに引っかかる部分は、丁寧にチュートリアルで解説されている。

>あとジェネレータとデコレータとメタクラスは勉強したけど理解できない。そのくせメジャーな機能っぽいから
>これを理解できてないとオープンソースのコードが読めない。
メタクラスは知らなくても大抵困らない。
ジェネレータとデコレータって、こんなに丁寧にチュートリアル書いてあるのに理解できない?
デコレータなんて
@foo
def bar():

def bar():
bar = foo(bar)
ってなるだけだし。

>(未だにユニコードのエラーが解消できない)。
これは、なんとなく偶然に動くよりも明示的にエラーにしようっていう方針。
「動いてるけどどこかで文字化けしている」ってなる前に、例外だして問題の
あるところを指摘してくれてるんだよ?むしろ優しいじゃないか。

660 :methane:2010/10/16(土) 15:19:55
誰かが貼ってたURLだけど、 http://slashdot.jp/developers/article.pl?sid=03/03/14/0258247 で、Matz自身が
>少なくともRubyの目指すポジションは「Rubyに十分に慣れた人が最高のパワーを発揮できる道具」です。
...
>Ruby のやり方に十分に慣れた人が持つ常識が一貫して通用するという意味です。

って言ってるんだよね。

一方、僕はC++がメインでJavaやアセンブラを使うプログラマで、当時はスクリプト言語を格下に思ってすらいたけど、
バッチ処理やスクリプト、ログ解析などのためにPythonを使い出した。デコレータもジェネレータもメタクラスも使わなかったけど、
「Pythonに十分に慣れた人」ではない僕にも十分なパワーを発揮してくれた。

それをTwitterに書いて、同意するつぶやきもあったし、 http://practical-scheme.net/trans/IsPythonLisp-j.html でも
> 彼がちょっとハックしたいなと 思ったら、彼は自分の頭の「1ページ」に収まって、必要な時にすぐにスワップインして
> またすぐにスワップアウトできるような言語を使いたがるだろう。 Pythonがその言語だ。
とか書かれている。

661 :デフォルトの名無しさん:2010/10/16(土) 19:11:50
>>659
ジェネレータは難しいんじゃないかな
こういうコードは字面だけはシンプルだが、何をやってるか、なれてる人でないと
まず理解できんとと思うよ

def add(x,y):
    yield x+y

def main():
    r = yield add(2,2)
    yield

def run():
    m      = main()       
    sub    = m.send(None)             
    result = sub.send(None)
    m.send(result)

run()


662 :デフォルトの名無しさん:2010/10/16(土) 20:28:44
>>658
例題に対しておまえの書いたsuper、1個引数たりねーじゃねーかwww
「省略できる」というルールさえおぼえれば、おまえが犯したようなミスをせずにすむってことだよwwwww

ほかの反論も、シンボルが理解出来ないレベルにしてはずいぶん小難しい話してるなwwww
pythonの時だけ都合よく頭が働くのかwwwwプゲラ


663 :デフォルトの名無しさん:2010/10/16(土) 20:35:17
>>662
揚げ足取りしか反論出来ないのはは恥ずかしいよw

664 :デフォルトの名無しさん:2010/10/16(土) 20:39:31
「Pythonならこうするんだ」って推測できる(キリッ
全く特別ルールではない(キリッ
こんなに丁寧にチュートリアル書いてあるのに理解できない?(ドヤッ

どんだけ上から目線wwwww
液パイ如きがちょーしこいてんじゃねーwwww

665 :デフォルトの名無しさん:2010/10/16(土) 20:43:22
言い方はひどいが指摘としてはもっともだね。

666 :デフォルトの名無しさん:2010/10/16(土) 20:44:42
>>663
揚げ足取りっつーか、Pythonの文法じゃめんどくさい上にそういうミスを犯す可能性があることを信者自身が示してくれたんだろ?www ご苦労様ですwwww

667 :methane:2010/10/16(土) 20:59:47
>>662
悪い、普段は new style class かどうか確認するのが面倒で 親クラス名.__init__(self, arg1, arg2) って書いてるから、
super() の使い方覚えてなかった。

でも、使い方覚えてなくてミスってもエラーになるからわかるでしょ。
僕が問題にしているのは最初から読むときの推測のしやすさ。

668 :デフォルトの名無しさん:2010/10/16(土) 21:07:07
>>667
大丈夫だ、問題ない


ニヤニヤ

669 :methane:2010/10/16(土) 21:08:48
>>661
メタクラスとかsendとか、殆ど出てこない機能はさすがに推測だけじゃ無理だよ。

チュートリアルを1度流し読みするだけで、普通のプログラム内で頻繁に出てくる程度の文法の
殆どは推測できるようになり、ライブラリのリファレンス以外は殆ど見ないで済むという主張しかしてない。

670 :デフォルトの名無しさん:2010/10/16(土) 21:24:17
ていうかさ

「誰が書いても同じように書ける」的なことを掲げてるPythonが比較的読みやすいのなんておまえに言われなくてもみんなわかってるわwwww

楽しく書けるRubyや、歯ブラシのPHPは、読みやすさを売りにしてるわけじゃないんだから、Pythonの得意な土俵だけで比較しても不利だし、そんな偏った比較は意味ないだろwwww

それをドヤ顏で「読む時の推測のしやすさしか問題にしてない」ってアホかwwwww

チュートリアル、チュートリアルって連呼してるが、普通の入門者は読むためよりも自分でプログラムを書くためにチュートリアルで勉強するもんだろwwwwwおまえの言ってること破綻しすぎwwww()笑www

671 :デフォルトの名無しさん:2010/10/16(土) 21:31:07
>>658-659
デコレータは読んでも全然理解出来んかったな。
Pythonの中でもかなり感覚に反する機能だと思う。

あと
> 繰り返しになるけど、僕は読むときの話をしていて、書くときの話をしていない。

スクリプト言語は「書く」ことが重要な分野だと思うが。
そこらの大規模言語は読むことが最重要だろうけど
各自が「書く」ことこそスクリプト言語が生きるところだと思う。

まあ、それでも同じスクリプト言語って分類でも
Pythonは読みやすい、Rubyは書きやすいってのは思うけどね。

672 :デフォルトの名無しさん:2010/10/16(土) 22:17:18
Lispから来たんだけど俺はPythonの方がいいな
Rubyはストレスがたまる
Perlの方がよっぽどマシ

673 :デフォルトの名無しさん:2010/10/16(土) 22:21:47
Pythonは一度書いたコードを書き直していくと、だんだん綺麗になっていくのが好きだ。癒される。


674 :デフォルトの名無しさん:2010/10/16(土) 22:26:15
>>671
デコレータは高階関数に慣れてないと難しい概念になるんじゃないかな?
高階関数を普通に作る/使うようになれば、単に糖衣構文だし。


675 :デフォルトの名無しさん:2010/10/16(土) 23:03:15
引数を取るデコレータを作る場合、関数を返す関数を返す関数を作るので、
多分混乱するんだと思う。

bind1st = lambda arg: lambda f: lambda *args, **kw: f(arg, *args, **kw)

@bind1st(1)
def add(x, y): return x + y


676 :デフォルトの名無しさん:2010/10/16(土) 23:11:38
PythonよりもJavaScriptの方が読みやすい・分かりやすいと思うんだけどなあ

677 :デフォルトの名無しさん:2010/10/16(土) 23:11:51
>>673
その感覚すごくわかる。たしかに癒される。
Pythonに特有のことというわけじゃないんだけど、
Pythonの場合スタイルの縛りが厳しいせいか
比較的早く達成感的なサムシングが得られる気がする。

678 :デフォルトの名無しさん:2010/10/16(土) 23:42:09
Python信者こわい

679 :デフォルトの名無しさん:2010/10/16(土) 23:42:47
まぁpythonは日本じゃ今後も流行らなさそう

680 :デフォルトの名無しさん:2010/10/16(土) 23:47:21
チュートリアルさえ読めば問題ないが通るなら
rubyのsuperとかも別に問題ないな

681 :デフォルトの名無しさん:2010/10/16(土) 23:56:53
エキスパートPythonの訳者?のおかげで、なんかPythonのイメージが悪くなった
あと歯ブラシのPHPってなに?

682 :デフォルトの名無しさん:2010/10/17(日) 00:05:03
>>680
使ってる身からしても、Rubyの
入門向けのオンライン資料が足りないってのは否定しないけどね
ただ例の人の言ってることはちょっと変な方向に行っちゃってるとは思う

まあ、ある意味バトルっぽくていいがw

683 :デフォルトの名無しさん:2010/10/17(日) 00:20:19
Python好きな人ってMっけあるんじゃない?

684 :デフォルトの名無しさん:2010/10/17(日) 00:26:02
いや色々だよ
ただ信者クラスになると妙に頭が固いというか、排他的な気はする

685 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/17(日) 00:26:34
PHPとかきもいんだよ

ケーキPHPとか歯ブラシとか

なんかバカが キャラ名に すきやき やきにく 歯ブラシ とかつける感覚なんだろ?

ふざけてるっていうか なんていうか

しねごみ

686 :デフォルトの名無しさん:2010/10/17(日) 00:30:52
Pythonの日本語ドキュメントって2.5で止まってんだな
Rubyもドキュメントは全然整備されてないし
その点PHPは頑張ってるな

687 :デフォルトの名無しさん:2010/10/17(日) 00:36:13
本ぐらい買え

688 :デフォルトの名無しさん:2010/10/17(日) 00:37:12
あぁ、やっぱりドキュメントそうなんだ


689 :methane:2010/10/17(日) 00:40:35
翻訳遅くてすみません。2.6の翻訳中のものはこちらにあります。2.6出したときに比べると
大幅にスピードダウンしてますが、一応細々と続いてます。
http://pythonjp.sourceforge.jp/dev/
ライブラリリファレンスは殆ど終わってますが、チュートリアルの翻訳率はまだ低いです。
# といっても、チュートリアルはあまり2.5から変更なさそうですが。

690 :デフォルトの名無しさん:2010/10/17(日) 00:50:06
日本語の書籍という観点で見るとRubyが圧倒的に多い感じだな
次点でPerl? 僅差でPHP
Pythonはほとんどなかったが、最近ちょろちょろ出てるな



691 :デフォルトの名無しさん:2010/10/17(日) 01:03:24
日本にRuby信者が多いわけだ

692 :デフォルトの名無しさん:2010/10/17(日) 01:05:58
英語の書籍でもRubyの方が多い

693 :デフォルトの名無しさん:2010/10/17(日) 01:16:35
ttp://www.amazon.com/s/ref=nb_sb_noss?url=node%3D5&field-keywords=Ruby&x=0&y=0
ttp://www.amazon.com/s/ref=nb_sb_noss?url=node%3D5&field-keywords=Python&x=0&y=0

694 :デフォルトの名無しさん:2010/10/17(日) 01:18:22
ttp://www.amazon.com/s/ref=nb_sb_noss?url=node%3D5&field-keywords=Perl&x=0&y=0
ttp://www.amazon.com/s/ref=nb_sb_noss?url=node%3D5&field-keywords=PHP&x=0&y=0

695 :デフォルトの名無しさん:2010/10/17(日) 01:34:07
Pythonはチュートリアルだけでもそこそこいけるからな

696 :デフォルトの名無しさん:2010/10/17(日) 03:32:40
>>656
>Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった(未だにユニコードのエラーが解消できない)。

馬鹿には無理です


697 :デフォルトの名無しさん:2010/10/17(日) 08:11:26
日本限定でも、RubyとPythonだったら、Pythonの方が将来性あるだろう。


698 :デフォルトの名無しさん:2010/10/17(日) 08:18:05
PHPのドキュメントは圧倒的に優れてるな。日本語翻訳のスピード、質の高さが半端ない。MSとかと比べても全然優れてる。
それに公式サイトの作りが秀逸。上に説明があって、下に掲示板があって、掲示板まで読めば使いどころとか注意点まで全部分かる。

699 :デフォルトの名無しさん:2010/10/17(日) 08:23:00
>>690
といっても、Rubyでもやっぱり
良書とされる書籍は原語が英語のことが多い
『初めてのRuby』とか日本語ネイティブのいい本もあるんだけどね

700 :デフォルトの名無しさん:2010/10/17(日) 09:03:47
>>676
JavaScriptは環境が不自然
いくら便利な環境を作ったとしても、デフォルト・強制にしたらダメ

701 :デフォルトの名無しさん:2010/10/17(日) 09:18:44
>>696
あれ、コテの人の発言と矛盾してるね

702 :デフォルトの名無しさん:2010/10/17(日) 10:15:17
>>696
http://bugs.python.org/issue5911
これ、コテの人のunicode絡みのfeature requestで、rejectされてるわけだが

http://dsas.blog.klab.org/archives/51390187.html
こことかでも同種の問題が指摘されているね

さすがシンボルみたいな基本も知らないレベルで他の言語disれる
Python信者は一味違うね


703 :デフォルトの名無しさん:2010/10/17(日) 10:39:15
信者よりストーカーのほうがきもいよ

704 :デフォルトの名無しさん:2010/10/17(日) 11:17:31
methaneなんぞいちいちストークするかボケ
>>702に上げたPython 2.x系の問題は2chのPythonスレにも上がってたし
Pythonユーザなら知ってるだろ

705 :デフォルトの名無しさん:2010/10/17(日) 12:49:22
Python信者はよくありがちな自画自賛タイプだが
Ruby信者はストーカータイプ(笑)

706 :methane:2010/10/17(日) 12:55:28
>>702
後者のBlogも僕だったりしますが、、、
compileは内部のコンパイラとのI/Fなので特殊な事例ですが、確かに

そもそも、Rubyは初心者にとって読みにくい気がするって、初心者視点で感想を言ってただけなんですが、
シンボル判らないと初心者以下ですか?

シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、Ruby、Lispの
シンボルは独特で、Java、JavaScript、PHP、C/C++その他メジャーな言語では出てきません。
それなのに
> シンボルは任意の文字列と一対一に対応するオブジェクトです。
だけで、Rubyにおいてシンボルがどういう役割を持っているのかが一切説明されていないのですが、
これで判れという方が厳しくありませんか?

707 :デフォルトの名無しさん:2010/10/17(日) 14:17:10
おいおい、いつの間にかRuby信者にされちゃったよw
俺はRubyだったらPythonのほうがまだ詳しいぞ

compile()は確かに初心者が直接使うもんではないかもしれないが
compile()を内部的に用いているプログラムは初心者も普通に使う可能性が
高いわけで、間接的にエンコーディングに関するトラブルが出るのが
問題なんだろ?
methaneは自分でバグレポ出したぐらいなんだから、んなことは百も承知だろうがな

俺は>>656ではないが、>>696のような厨房の言い草には腹が立った
Pythonをちょっと知ってるぐらいで、一体何様のつもりだよ


708 :デフォルトの名無しさん:2010/10/17(日) 14:39:00
http://www.google.co.jp/trends?q=python+programming,+ruby+programming,+perl+programming,+php+programming&ctab=0&geo=all&date=all&sort=0

709 :デフォルトの名無しさん:2010/10/17(日) 15:47:28
>>708
PHPよりPythonのほうが多いのはびっくりした

710 :デフォルトの名無しさん:2010/10/17(日) 17:45:05
Railsブームってやっぱすごかったんだな

711 :methane:2010/10/17(日) 19:10:56
>>707
うん、unicodeが難しい例としてcompileが相応しくないという指摘をしているだけ。
もうちょっと詳しく言うと、compile()の結果がutf-8で良いなら現行のAPIでもBlogに書いたような
修正をすれば問題なくて、Windows上でcp932使いたい場合に今のcompile()が問題になる。

bzrっていうバージョン管理ソフトもPythonで作られてるんだけど、sys.argvがunicodeじゃなくて
バイト列なんで、Windows環境でユニコードファイル名使うために GetCommandLineW() 使って
引数を取り直したりとにかくめんどくさい。
WindowsでのUnicodeとcp932の問題が面倒なのはPythonだけの問題じゃないけどね。

712 :デフォルトの名無しさん:2010/10/17(日) 21:07:48
>>707
>俺は>>656ではないが、>>696のような厨房の言い草には腹が立った
>Pythonをちょっと知ってるぐらいで、一体何様のつもりだよ

Pythonスレじゃ挨拶代わりなんだぜ

713 :デフォルトの名無しさん:2010/10/17(日) 21:46:29
>>658
> でも、 super().__init__(arg1, arg2) なら、親クラスの同名メソッドを呼び出していることが一目瞭然だけど、
> super だけだと同名メソッド呼び出してるんだろうなくらいまでは推測できても、まさか引数まで渡されてるとは
> 推測できない。superが通常の引数無しのメソッド呼び出し構文と同じだから。
superは予約語だから関数呼び出しとは違うよ。
それに、推測する必要ないでしょ。どの入門書でもそのくらい書いてあることだから。

> まず、raiseは関数呼び出し構文と違うので、関数呼び出しのルールが通用しないのに不自然さはない。
superも関数呼び出しとは違うので、ルールが違っても不自然さはない。
またこのルールは651にあるように、ちゃんと意味があってのこと。それを理解せずに文句足れてもね。

> 問題にしているのは、見た目は完全に「引数無しの呼び出し」であること。
もし見た目が同じだから問題というなら、もうRubyを使うのは無理。
while foo.bar do
 ...
end

foo.bar.each do
 ...
end
は見た目が一緒だから問題と言い張るようなもの。
もしsuperが関数呼び出しとまったく違う使い方だったら、それこそ問題。

> むしろ、クラスの書き方のチュートリアル読まないでコード読んでも、selfをみて「Pythonではこうするんだ」って
> 推測できる。
できない。自分ができたからといって、他人もできるとは限らない。
メソッド定義と呼び出す時で引数の数が変わるのに、Python知らない人が推測できるわけがない。

全体的にいって、入門書の一冊でも読めばひっかからないようなことに対して、Pythonの人がろくに勉強もせずに文句ばかり言ってるだけにしか見えない。

714 :デフォルトの名無しさん:2010/10/17(日) 21:57:48
>>706
>そもそも、Rubyは初心者にとって読みにくい気がするって、初心者視点で感想を言ってただけなんですが、
>シンボル判らないと初心者以下ですか?
初心者以下かどうかは知らないけど、シンボルわかってないなら間違いなく初心者。

>シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、Ruby、Lispの
>シンボルは独特で、Java、JavaScript、PHP、C/C++その他メジャーな言語では出てきません。
なにをもってメジャーな言語とするかわかんないけど、LispやSchemeはメジャーじゃないってことか。ふーん。
それ、「メジャーな言語では出てこない」じゃなくて「自分がしってる言語では出てこない」の間違いじゃない?
なんというか、JavaやC++にはクロージャが出てこないので・・・とか、mix-inはRuby以外の言語には見られないので・・・とか言いそう。
Pythonならジェネレータとかまさにそうだと思うけど。
自分が知らないなら勉強すればいいだけだと思うけどな。

>それなのに
>> シンボルは任意の文字列と一対一に対応するオブジェクトです。
>だけで、Rubyにおいてシンボルがどういう役割を持っているのかが一切説明されていないのですが、
>これで判れという方が厳しくありませんか?
別にRubyに限らないけど、シンボルは単に記号を表すだけ。数値処理や文字列処理と同じように記号処理ができるというそれだけのこと。
どういう説明が欲しいの?

715 :デフォルトの名無しさん:2010/10/17(日) 22:04:07
>>659
>list や str に限らず、全ての型は関数オブジェクトであって、呼び出したらその型のオブジェクトが返るようになっている。
>全く特別ルールではない。

これって他のメジャーな言語でも見られるの?
型を呼び出すことができるという時点で、まったくもって推測できなかったんだけど。
これを「全く特別なルールではない」とか、君はほんとに信者だな。

716 :デフォルトの名無しさん:2010/10/17(日) 22:23:56
>>660
>誰かが貼ってたURLだけど、 http://slashdot.jp/developers/article.pl?sid=03/03/14/0258247 で、Matz自身が
>>少なくともRubyの目指すポジションは「Rubyに十分に慣れた人が最高のパワーを発揮できる道具」です。
>...
>>Ruby のやり方に十分に慣れた人が持つ常識が一貫して通用するという意味です。
>
>って言ってるんだよね。

うん、そうだよ。
そして、それはきみの勉強不足とはまるで関係ないよね。
入門書を読んで勉強したけど分からなかった、という話なら仕方ないけど
入門書も読まずに文句をいってる人が引用する言葉じゃない。

717 :デフォルトの名無しさん:2010/10/17(日) 22:26:11
よく見たら

>>706
>シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、

って書いてあるじゃない。internが分かっててシンボルが分からないという理屈が分からない。


718 :デフォルトの名無しさん:2010/10/17(日) 22:47:42
これだからRuby厨って・・
Lisp使いだけど残念ながらメジャーとは言えないと思う
CやJavaから来た人ならシンボルを知らなくても当然でしょ

719 :デフォルトの名無しさん:2010/10/17(日) 22:51:35
シンボルも知らないのか馬鹿!
メソッドチェーンも知らないのか馬鹿!

720 :デフォルトの名無しさん:2010/10/17(日) 23:11:15
>>715
インスタンス化と関数コールの見た目が同じ(ついでに関数のように扱える
クラスオブジェクトもある)一番メジャーな言語はたぶんC++かな
ま、C++とPythonでは内部の意味や原理が違うけど

Pythonだと、tがTのインスタンスであるとき、
t()はt.__call__()やT.__call__(t)と同じ意味で、実際以下のように書ける
sum([1, 2, 3]) --> 6
type(sum).__call__(sum, [1, 2, 3]) --> 6
dict() --> {}
type(dict).__call__(dict) --> {}

要は全部構文上は本当に同じもので、
Pythonにおいてはメタクラスの__call__()が、たまたま
インスタンス化の機能をもっているというわけだ
そういう意味で、methaneの言ってる「特別ルールではない」ってのは事実

まー、気持ちとしては意味が違うものなのに、全部
x = f()
とか書いてあると区別がつかなくて混乱する、というのは分からんではないし
Pythonのやりかたが特に初心者に理解しやすいとも思わんが

なにしろこの説明で既にメタクラスが出てしまってるぐらいだしな

721 :デフォルトの名無しさん:2010/10/17(日) 23:26:58
アンダースコア2個で囲まれたメソッドってなんかキモいんだけど、どっかの慣例?

722 :デフォルトの名無しさん:2010/10/17(日) 23:28:13
C

723 :デフォルトの名無しさん:2010/10/17(日) 23:42:33
Java,Cやってる人は、Python派
PHP,Perlやってる人は、Ruby派
でFA?

724 :デフォルトの名無しさん:2010/10/17(日) 23:50:53
元はCだと思うが(もっと古いのかも)
__FILE__みたいなのってPerlやRubyやPHPにもあるだろ

>>721が一体どんな言語を使ってるのか興味あるなw

725 :デフォルトの名無しさん:2010/10/17(日) 23:51:21
c++がperlとして、javaにシンパシーを感じるのがPythonで
c#ならrubyって感じがする

726 :デフォルトの名無しさん:2010/10/18(月) 01:12:42
>>659
>>(未だにユニコードのエラーが解消できない)。
>これは、なんとなく偶然に動くよりも明示的にエラーにしようっていう方針。
>「動いてるけどどこかで文字化けしている」ってなる前に、例外だして問題の
>あるところを指摘してくれてるんだよ?むしろ優しいじゃないか。

勘違いしてるね。問題にしてるのは、エラーが起きたことじゃなくてそれを解消できないこと。
問題があるときにエラーになるのは当然でしょ。それは別に結構なこと。
そうじゃなくてPythonのユニコードがらみのエラーは、少なくとも初心者には解決が難しく、
エラーメッセージもわかりにくい。

まあPythonな人はチュートリアルを読めばわかると言い張るんだろうけどw

727 :デフォルトの名無しさん:2010/10/18(月) 01:19:03
>>718
>これだからRuby厨って・・
>Lisp使いだけど残念ながらメジャーとは言えないと思う
>CやJavaから来た人ならシンボルを知らなくても当然でしょ

これだからPython厨って・・
彼が非難されているのはシンボルを知らないことじゃなくて
入門書の一冊でも読めばわかることを、勉強もせずに「読んでもわからない」と
言い張っていること。
「Lisp使い」なんて見え見えの隠れ蓑やめたら?Pythonさん。
Lispがメジャーでないなら、日本でのPythonもまったくメジャーじゃないね。

あ、だから他の言語を必死にけなしてるのか。

728 :デフォルトの名無しさん:2010/10/18(月) 01:24:06
Rubyには公式のチュートリアルがない、という批判ならまだ理解できるけど
Pythonな人の文句はそうじゃないからなあ。
自分が理解できないRubyが悪い、と言われても、勉強してください、としか言いようがない。

729 :methane:2010/10/18(月) 01:26:04
>>716
Rubyが判りにくい言語だと文句を言っているわけではないです。
あくまでもPythonに比べての相対的な感想でしかありません。

僕が挙げた例が全て妥当だとはいえないかもしれませんが、
Rubyだと開発者本人が、「十分にRubyに慣れた人のための言語」と言っているのに対して、
Pythonだと僕以外にも「十分にPythonに慣れていない人にも使いやすい」と感じているのは事実です。

>>721
特別な意味を持った名前は特別な命名規則を与える事で、
1. 初心者がそのメソッド名を見たときに「これは特別な意味を持ったメソッドなんだ」と瞬時に理解できる。
2. 初心者が普通のメソッドを作ろうとして、他の意味を期待されてしまう名前を使ってしまう心配が無い。
というメリットがあります。

730 :デフォルトの名無しさん:2010/10/18(月) 01:30:55
>>Lispがメジャーでないなら、日本でのPythonもまったくメジャーじゃないね。
これはさすがに無茶苦茶いいすぎ

731 :デフォルトの名無しさん:2010/10/18(月) 01:34:41
>>729
普遍的に、万人にとって使いやすいの?

pythonと相対的に他の言語をみて、分かりやすい使いやすい言語は?


732 :デフォルトの名無しさん:2010/10/18(月) 01:43:47
C,Lisp,Perlをいじってた状況でPythonとRubyに触れてみたんだが
Pythonの方がRubyよりは楽だったんだけどな

733 :methane:2010/10/18(月) 01:44:51
>>726
Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
という事でしょうか?
非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね?

Pythonの問題は、Python2ではunicodeとstrに対する方針が(標準ライブラリでさえも)ライブラリごとに
まちまちになってしまっているために、ライブラリとの受け渡しでエラーが発生しやすいことだと思います。
(Python 3.2 でやっと標準ライブラリの統一が取れる予定です。)

この問題が多くの日本人を悩ませていることは十分承知しています。
エキスパートPythonプログラミングで1章だけ追加章を書き下ろしたのも、この問題の深刻さを理解しているからです。

734 :デフォルトの名無しさん:2010/10/18(月) 01:54:23
>>731
一つでも例外があったら駄目みたいな言い方だけど、
一般的にはpythonの方が使いやすいだろ

735 :デフォルトの名無しさん:2010/10/18(月) 01:56:02
>>729
後者で言ってることってRubyのシンボルにもそのまんま当てはまるんじゃないの?


736 :デフォルトの名無しさん:2010/10/18(月) 02:03:13
わかりやすいことと、つかいやすいことは必ずしも一致しない

今回の場合の「使いやすい」は、書きやすいという意味で使ってるのか?
事実とか一般的にとか、何を根拠に言ってるんだ?

737 :デフォルトの名無しさん:2010/10/18(月) 02:04:47
つまり少なくともRubyは分かりにくくはあるわけだね

738 :デフォルトの名無しさん:2010/10/18(月) 02:18:00
>>734
何がどう使いやすいのさ

739 :デフォルトの名無しさん:2010/10/18(月) 02:58:26
>>738
ライブラリが豊富で、標準ライブラリも豊富で
言語もくせがないところかな。

740 :デフォルトの名無しさん:2010/10/18(月) 02:58:44
Python信者って煽りは案外的確だった。

741 :デフォルトの名無しさん:2010/10/18(月) 03:09:02
>>733
>>726
>Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
>という事でしょうか?

そうじゃないよな
一般的な他の言語では(文字化けするのに)エラーにならないから
なんとなく動いてるからとりあえずこれでいいやって放置されるのが問題

つまり初心者(またはLatin-1しか知らない外国人やrubyist)は一般的な他の言語では
そこに問題があることすら気付かないし欠陥プログラムを量産してしまうのが迷惑


742 :デフォルトの名無しさん:2010/10/18(月) 03:13:45
>>729
> Rubyが判りにくい言語だと文句を言っているわけではないです。
どう好意的にみてもそうは見えない。

> Pythonだと僕以外にも「十分にPythonに慣れていない人にも使いやすい」と感じているのは事実です。
それはPython信者とその仲間の話だよね。


743 :デフォルトの名無しさん:2010/10/18(月) 03:16:16
>一般的な他の言語では(文字化けするのに)エラーにならないから
>なんとなく動いてるからとりあえずこれでいいやって放置されるのが問題
webアプリだとエラーになるより文字化けしてでも表示してくれたほうがいいよね

744 :デフォルトの名無しさん:2010/10/18(月) 03:18:50
>>743
それはPHPだけで通じる話だw

>>742
世界的に見たらPythonプログラマの方がRubyプログラマより圧倒的に多い罠
日本だけだろ、PythonとRubyが拮抗するのは。

745 :デフォルトの名無しさん:2010/10/18(月) 03:19:04
>>739
相対的に言うなら、perlのライブラリの方が充実してるんじゃない?

746 :デフォルトの名無しさん:2010/10/18(月) 03:22:11
>>745
もちろん。
ライブラリの数でいったら、Perlにはどの言語もかなわないよ。
その点に関してはCPAN最強。
ってか、まあ、あとはC、というかこれは範疇違うから比べてもしょうがないし。
Perl > Python > PHP > Ruby
こんな感じじゃない?

747 :デフォルトの名無しさん:2010/10/18(月) 03:24:46
Perlはずっと圏外な感じだったが、ここに来てようやく登場か……。

748 :デフォルトの名無しさん:2010/10/18(月) 03:39:42
>>733
>Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
>という事でしょうか?
そうです。ユニコード文字列とふつうのバイナリ文字列がごちゃまぜになりやすい仕様なので。
チュートリアル読んでも、初心者ではなかなか解決できない。どうせ信者は否定するでしょうけど。

>非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね?
Javaではこんな面倒なこと起きなかったのにPythonではしょっちゅう。



749 :デフォルトの名無しさん:2010/10/18(月) 03:45:00
>>748
別に解決は難しくないよ。
わからなくなったら、ちゃんと全部unicodeにすりゃあいいの。
それだけ。

エラーが出なかったらバイナリでもいいけど、ねw

750 :デフォルトの名無しさん:2010/10/18(月) 03:46:02
>>743
http://boost.cppll.jp/
ここはあきらめたらしい

751 :デフォルトの名無しさん:2010/10/18(月) 03:48:41
>そうです。ユニコード文字列とふつうのバイナリ文字列がごちゃまぜになりやすい仕様なので。

まぜるな危険
と誰が見ても判りやすい場所に書いておくべきだね

>>非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね?
>Javaではこんな面倒なこと起きなかったのにPythonではしょっちゅう。

馬鹿だからさ


752 :デフォルトの名無しさん:2010/10/18(月) 03:49:31
Javaは長いこと文字コード大問題だったじゃんw


753 :デフォルトの名無しさん:2010/10/18(月) 03:50:50
>>720
丁寧な説明はありがとうだけどそれを「特別ルールではない」と思えるのはエキスパートだけでしょ。
クラスや型もオブジェクトであることまではいいとしても、それらを関数のように呼び出せるのは
Pythonを知らない人から見てどうみても特殊。
Pythonのこういうところは擁護するくせに「superの見た目が関数と同じなのが嫌い」とかアホか。

754 :デフォルトの名無しさん:2010/10/18(月) 03:52:06
ま、でも、Pythonも今のunicode仕様に行き着くまでに紆余曲折、というか、
ポカもしてるわけで。
Python 1.6とか今やなかったことになってるからなw

755 :デフォルトの名無しさん:2010/10/18(月) 03:52:56
>>752
それはunicodeとsjisのマッピングの話であって、ユニコード文字列とバイナリ文字列が混じりやすいというPythonの問題とは別。
冷静に考えればすぐわかる。頭冷やせ。


756 :デフォルトの名無しさん:2010/10/18(月) 03:57:27
>>755
頭冷やすとかじゃないだろw
「問題」だろ、それも大問題だろ?w

あとさ、老婆心ながら、忠告しとくと、
Pythonせめるなら文字コードよりDB系の方がいいよ?
今でこそ、DB-API2.0が認知されてきちんとライブラリ出揃ったからいいけれど、
ちょっと前までは結構悲惨だったからな。
Postgre使うか、MySQL使うか、まさに悩みどころだったわさ。

757 :デフォルトの名無しさん:2010/10/18(月) 03:58:45
>>755
>ユニコード文字列とバイナリ文字列が混じりやすいというPythonの問題

そんな問題ねーよ
isinstance(hoge, str)
isinstance(hoge, unicode)
でちゃんと区別出来るし
勝手に混ぜられないからエラーが出るんだよ

ぐちゃぐちゃまざってんのはお前の頭だろ

758 :methane:2010/10/18(月) 04:13:56
>>753
あー、C++だとキャストで int() とか書けるし、ある型のインスタンス生成に型名+()なのは違和感無かったし、
それが関数呼び出しなのはC++で「変数宣言してるつもりが関数宣言してた」みたいな文法よりもすっきり
してると思ったけど、確かにC++以外の人にとっては 型名() は推測しにくいのかな?

superは、C++でもJavaでも明示的に引数は指定するから、Rubyのコード読んでるときに引数が
渡ってることになかなか気づかなくてハマったんだけど、i = int(s) とか、 L = list(x) とか、
実際に読んでてハマった?
できればPython勉強する前のバックグラウンドとなる言語とか教えて。

>>751, 755
静的型付けのJavaに比べると、さすがに初心者にとってのエラーの解消しやすさは違うね。
コンパイルエラー>実行時型エラー>暗黙の文字化け
とすると、初心者はコンパイルエラーと実行時型エラーの間に大きな壁があるし、
非初心者はエラーと暗黙に化けるの間に大きな壁がある。

でも、逆にJavaだときっちりしすぎてて、System.getenv()がStringを返す(Unix環境ではバイト列を
格納できるのに、それを取得できない)とか、汎用性にはかけてしまう。

759 :デフォルトの名無しさん:2010/10/18(月) 04:23:36
>>758
俺も先にCを使っていたからかもしれんが、int()とか、()をつければ関数コールとかは違和感ない。
ってか、むしろ、「くせのない」仕様と感じるが。
これをくせがある、と感じる奴いるわけ?w

760 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/18(月) 07:33:54
いねえよばかが

761 :デフォルトの名無しさん:2010/10/18(月) 09:09:10
379 デフォルトの名無しさん [sage] 2010/10/18(月) 07:49:37 ID: Be:
    suge------
    http://www.atmarkit.co.jp/fdotnet/csharp4/csharp4_04/csharp4_04_01.html

380 デフォルトの名無しさん [sage] 2010/10/18(月) 08:40:52 ID: Be:
    オプション引数・名前付き引数 (C# によるプログラミング入門)
    http://ufcpp.net/study/csharp/sp4_optional.html


    これか。C#にデフォルト引数がついてなかったとは知らなかったな。
    呼び出し側で評価されるゆえの実装の都合なのかこれ
    名前付き引数がVBにあったというのは衝撃的

    しかし何故C#4?

762 :methane:2010/10/18(月) 09:31:52
>>761
名前付き引数は本当に良い機能。
単に辞書・ハッシュを引数に渡すのに比べると、メソッドの宣言を見ただけで引き数がわかりやすいし、
受け取り側での名前のバリデーションが自動で実行される。

763 :デフォルトの名無しさん:2010/10/18(月) 09:41:19
少なくともその C#4 の仕様みたいに、仮引数(パラメータ)の名前が、明示的指示なしに
勝手に API の一部になるのはクソだろ。

プログラマの従来の感覚では、仮引数の名前はローカル変数の名前と同じで、関数の
ローカルに閉じたものだったんだから。うっかり名前を変更できないわけだから。

764 :デフォルトの名無しさん:2010/10/18(月) 10:34:25
4で導入されたダックタイピングもそうだが、COMサポートの
意味がでかいと思う
VBやVBScriptでは昔からあたりまえにオプション引数使えてたのに
C#だと使えないので、そのページにあるように

Workbook workbook = excelApp.Workbooks.Open(
"sample.xsl", Type.Missing, true, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);

とか書かないといけなくて
オートメーションのコードはC#よりVBのほうが書きやすいのが常識だった

765 :デフォルトの名無しさん:2010/10/18(月) 11:19:20
C#もやっとpythonなみになってきたな

766 :デフォルトの名無しさん:2010/10/18(月) 11:40:26
Javaと違ってC#はかなり強力なので、.NET上のほかの言語があまり流行る感じがないな
MS謹製のF#もScalaほど注目されてないように見える

767 :デフォルトの名無しさん:2010/10/18(月) 11:44:37
   ┌─┐
   │●│
   └─┤
   _   ∩
  ( ゚∀゚)彡
┌─┬⊂彡
│●│ おっぱい!おっぱい!
└─┘

768 :デフォルトの名無しさん:2010/10/18(月) 13:39:44
>>723
俺は逆。
Perlやってるから、.Rubyに必要性を感じない。Pythonの方がいい。
PHPの人はどっちにも興味ないと思う。

769 :デフォルトの名無しさん:2010/10/18(月) 13:56:21
Rubyってアップルから捨てられたみたいだけど、この先勢いを
取り戻す事はく消えるだけですよね。


770 :デフォルトの名無しさん:2010/10/18(月) 14:03:47
そう思いたいならそう思っていたほうが、精神の安定になると思いますよ。

771 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/18(月) 14:05:22
Ruby-Cocoa(苦笑)

772 :デフォルトの名無しさん:2010/10/18(月) 14:32:43
MacRubyの開発してるけど

773 :デフォルトの名無しさん:2010/10/18(月) 15:07:08
ruby / python 両方覚えればいいと

774 :デフォルトの名無しさん:2010/10/18(月) 15:40:10
Ruby使ってないけどMacRubyはかっこいいと思う

775 :デフォルトの名無しさん:2010/10/18(月) 16:19:08
>>773
わしにはそんな時間もうないのじゃ

776 :デフォルトの名無しさん:2010/10/18(月) 16:48:39
>>775
諸行無常だね…

777 :まつもとひろゆき:2010/10/18(月) 16:48:43
木下誠 っていうクソマカ
vs
Perler



778 :デフォルトの名無しさん:2010/10/18(月) 18:52:02
必要を感じたら学べばいいんじゃないか?
そして必要に応じて深く学ぶと

779 :デフォルトの名無しさん:2010/10/18(月) 19:05:49
>>758
俺は>>753では無いが、型名()は何やってるのか推測しにくいぞ。

C++でもいくつかある書き方の1つでしかないし
C++での他の書き方やJavaに倣って new 型名() を使う形式も多い。JavaScriptとかPerlとか。
Delphiは 型名.Create() と、コンストラクタ名(大概のクラスでは Create という名称)を直接書く。

Pythonでハマッた点は…int()を関数だと思ってしまって意味が解らなくなったことならある。
まさかintが型名で、インスタンス生成の形式になってるとは思わなかった。
ドキュメント読めば解るがそれはRubyのsuperも同じ。
…でも引数の不一致はコードを追う過程で自然と判ると思うのだが?

でも一番ハマッたのはclass文の「新形式」かな。
新形式とは何か、旧形式とは何か、が
(少なくとも俺が読んだ当時のドキュメントには)書かれてなくて
自分が書いたclass文が旧形式だとは知らずに困った。
旧形式って言うぐらいだから、class文すら使わないような形式だと思ってたよ。

780 :779:2010/10/18(月) 19:09:22
その勘違いの原因の1つに、objectをわざわざ継承しなければならないってところもあったかな。
JavaもDelphiも…そしてRubyもだが、基本的に「全ての基底となるクラス」があって
継承元を省略した場合には、そのクラスを継承したことになるってのが当たり前だと思ってたから。

781 :デフォルトの名無しさん:2010/10/18(月) 19:18:10
ああ、そこオレもはまったよw

782 :デフォルトの名無しさん:2010/10/18(月) 22:14:19
ほら、な?
Python批判するのは馬鹿ばっかりだろ?

783 :デフォルトの名無しさん:2010/10/18(月) 22:41:19
Python信者もシンボルが理解できないくらい馬鹿だけどな

784 :デフォルトの名無しさん:2010/10/18(月) 22:43:33
>>724
Rubyの場合はメソッドじゃなくて疑似変数だね。
CやPerlの語彙を借りてるだけで、アンダーバーを使いたいわけではない。

785 :デフォルトの名無しさん:2010/10/18(月) 22:51:10
俺が理解できないことは万民にとってそれが分かり難いものだというだけのこと
俺が理解できることを理解できない奴は全員馬鹿

786 :methane:2010/10/18(月) 23:02:43
新形式クラスとか旧形式クラスとか、Pythonの統一が取れてない面だけど、
別に知らなくてもコード読めてた気がするんだけどなぁ。
本当に、他人のコードを読んで大体の動作をつかむ上でそこに引っかかる?

787 :デフォルトの名無しさん:2010/10/18(月) 23:04:23
>>784
Rubyにも__send__みたいメソッドはあるよ
sendの再定義に備えて用意してある

788 :methane:2010/10/18(月) 23:05:07
あと、Python自体が統一が無いと認めてPython3で修正するような問題(Pythonicで無い部分)と、
Ruby1.9でも変わらず、Ruby2.0でもきっと変わらないRubyらしい部分を比較するのも、フェアじゃない気がする。

789 :デフォルトの名無しさん:2010/10/18(月) 23:07:11
>フェアじゃない気がする。

本日の「お前が言うな」ですね

790 :デフォルトの名無しさん:2010/10/18(月) 23:12:39
フェアじゃない気がする。(キリッ

791 :デフォルトの名無しさん:2010/10/18(月) 23:16:36
>>786
いや、それならシンボルも別に知らなくても大体の動作はつかめるよね。。。

792 :methane:2010/10/18(月) 23:33:21
シンボルが引数なのは割とよく出るけど、新クラスと旧クラスの挙動の違いがコード読むときに
関係することはあんまり無いと思うんだけど、、、僕だけ?ごめんなさい。

793 :デフォルトの名無しさん:2010/10/18(月) 23:38:27
>>696
>>Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった(未だにユニコードのエラーが解消できない)。
>
>馬鹿には無理です

なるほど、Pythonは馬鹿には無理ですか。
Pythonエキスパートにそう言われると仕方ありません。あきらめます。
馬鹿には無理なPythonをマスターしているエキスパートはほんとうに頭がいいですね。うらやましいです。

794 :デフォルトの名無しさん:2010/10/18(月) 23:40:28
>>782
>ほら、な?
>Python批判するのは馬鹿ばっかりだろ?

はいそうですね。Pythonは馬鹿には無理なので、Pythonを批判するのはマスターえきなかった馬鹿どものしわざです。
さすがPythonエキスパートさん。Pythonは頭のいいスマートな人が使う、素晴らしい言語ですね。

795 :methane:2010/10/18(月) 23:48:06
とりあえず、みんなそれぞれいろんな点で引っかかるのは判ったから、個別の事例は忘れて。

RubyとPythonを比べると、似てる部分が多いけど、どちらかというとPythonの方が構文がシンプルで
記号もキーワードも少なくて覚えることが少ない。
Rubyは「Rubyに慣れた人にとっての使いやすさ」を目指していて、Pythonはもう少し万人向け。
ここまでは殆どの人は異論無いよね?

もちろん、Rubyにもスクリプト言語やDSLとして使うときのタイプ数の少なさなど、Pythonに勝っている
部分もあるのは十分承知している。

796 :methane:2010/10/18(月) 23:51:35
>>793
そんなあなたに「エキスパートPythonプログラミング」。
UnicodeErrorがなぜ発生するのかの説明、安全な操作と安全じゃない操作の分類、
unicode未対応ライブラリとの付き合い方、Python3でどうなるかまで解説しています。
これを読めばあなたもエキスパートの仲間入り。UnicodeErrorなんて怖くない。

797 :デフォルトの名無しさん:2010/10/18(月) 23:55:24
>>795
つまりどちらかのエキスパートを目指すなら、RubyのほうがいいということでOKですか?

798 :デフォルトの名無しさん:2010/10/19(火) 00:04:01
>>795
構文や言語仕様がシンプルかどうかの比較ってそんなに重要かな
PythonってSchemeに比べると随分複雑な言語だけど
Scheme興味ないんでしょ?

799 :methane:2010/10/19(火) 00:17:31
>>797
人それぞれ。多人数が参加するオープンソースの世界ではPythonの方が選ばれていることが多いし、
少数精鋭で一気に素晴らしいWebサービスを立ち上げる事例はRubyの方が多いと思う。

>>798
似てる言語だから比べてるんであって、全然違うシステムの言語と比べても意味が無い。
せめて、オブジェクト指向をサポートした手続き型言語の範囲に絞って。

800 :デフォルトの名無しさん:2010/10/19(火) 00:19:59
JavaScripterな俺から見ればPythonですら複雑すぎる

801 :デフォルトの名無しさん:2010/10/19(火) 00:22:35
> オブジェクト指向をサポートした手続き型言語
なんでそこに拘るんだか意味わかんねえ
CommonLispはオブジェクト指向をサポートしたマルチパラダイム言語だけど、
CommonLispならいいの?

802 :デフォルトの名無しさん:2010/10/19(火) 00:25:20
言語仕様がシンプルがシンプルなのは、複雑なのよりずっと良い

803 :デフォルトの名無しさん:2010/10/19(火) 00:26:25
>>795
この文章だけ読んでも、Rubyを下に見ている感が溢れでまくってるね
滲み出るとかのレベルじゃなく、溢れまくり
Ruby信者って怖いなあって思うことが多々あったけど、Python信者さんは格が違った 恐れ入る

804 :デフォルトの名無しさん:2010/10/19(火) 00:27:03
>>802
俺もそう思うけど、そういう思想でLisp族をスルーするのは解せないね

805 :デフォルトの名無しさん:2010/10/19(火) 00:29:13
Pythonクックブックにも、
Pythonは何でもできるけど、Lispも何でもできる。あの括弧だらけのコードに堪えられればの話だが
みたいな文章があったよ

806 :methane:2010/10/19(火) 00:31:25
>>801
構文だけでなく、バラダイムまで習得しないといけないから、構文のシンプルさが
学習コストの低減に繋がらない。
アセンブラ/C/C++/Java に加えて一つスクリプト言語やアプリケーション作成向けの
言語を覚えようと思ったら、手続き型+オブジェクト指向の方が直ぐに覚えて高い生産性を
発揮できる。

自分ひとりなら趣味で選べても、例えばC++のプロジェクトのビルドやテスト用にスクリプトを
書くとして、自分以外にもいろんな人が読み書きする可能性があるのにCommonLispが
妥当な環境って少ないと思う。
逆に、なんでPythonやRubyじゃなくてLispに拘るの?

807 :デフォルトの名無しさん:2010/10/19(火) 00:32:10
>>803
漏れはそんな風に感じなかった
藻前がそう思ったならそれは藻前のコンプレックスがそうさせているんだ

808 :デフォルトの名無しさん:2010/10/19(火) 00:33:05
>>807
というかMatzでも普通に同意するんじゃないかな

809 :デフォルトの名無しさん:2010/10/19(火) 00:33:41
> 逆に、なんでPythonやRubyじゃなくてLispに拘るの?
俺は特にこだわってないよ
要は、あなたは構文のシンプルさを重視しているようで、実は重視してないんでしょ?
生産性のほうが重要だからPythonを選ぶと自分でいっているわけだ

ならRubyを選びたがる人の気持ちもおのずと分かりそうなもんだけど、
そうでもないのが面白いね

810 :デフォルトの名無しさん:2010/10/19(火) 00:34:54
> 学習コストの低減
云々も、結局そのユーザのバックグラウンド次第でしょ
情報科学の専門教育を受けた人間なら、たいていSchemeやらMLやらの
関数型言語ぐらい弄ってるだろうし

811 :デフォルトの名無しさん:2010/10/19(火) 00:35:36
なぜ二者択一なのか分からん。一部を重視したら他全部は捨てることになるのかよ

812 :methane:2010/10/19(火) 00:38:30
>>809
生産性と同じくらい、習得のしやすさや、読みやすさ、毎日その言語を使うわけではない人にも
気軽に使える事を重視しているだけだよ。
自分が書いたコードは同僚にもメンテして欲しいし、同僚が書いたコードは俺もメンテしないと
いけないからね。

813 :デフォルトの名無しさん:2010/10/19(火) 00:42:05
>>812
つまりさ、それはあなたの条件にとってPythonが最善だった(少なくともあなたは
そう判断した)ってだけの話じゃないの?

PythonがシンプルだからとかRubyは複雑だみたいな話に
そこだけ取り出して持っていったところで、
Pythonなんかよりずっとシンプルな言語いくらでもあるし
一般的な主張としては、大して意味無いように見えるのだけどね

だいたいあなた、習得しやすさ等を考慮して判断してるかのごとくに言ってるけど
Lispについては判断以前に何もしらないんでしょ?


814 :デフォルトの名無しさん:2010/10/19(火) 00:45:43
>>812
個別のことを忘れようと書きながら、
>>806
> アセンブラ/C/C++/Java に加えて一つスクリプト言語やアプリケーション作成
> 向けの言語を覚えようと思ったら、手続き型+オブジェクト指向の方が直ぐに
> 覚えて高い生産性を発揮できる。
と十分個別のことを書いてるように思える。

815 :methane:2010/10/19(火) 00:57:13
>>813
そもそもPythonとRubyを比べたTwitterの書き込みに批判があったからそれについて
話してただけなのに、なんで他のパラダイムの言語まで含めた一般論をしないといけないの?

Lispがライブラリの数や質まで考慮に入れてPythonよりも生産性が高いとは思いにくいし、
そもそも興味が無い。

>>814
個別の事例ってのは、superとか名前付き引数とかselfとか、PythonとRubyの個々の構文の違い
という意味で言ってた。
PythonとRubyどころか手続き志向言語から話題が離れると全く専門外だから、これ以上僕に
向かって話題振らないでくれ。

816 :デフォルトの名無しさん:2010/10/19(火) 01:07:35
Lisp使いでPythonも好きなんだけど流石にこれはちょっと引く
Python使いの全てがこんなのとは思って欲しくない

817 :デフォルトの名無しさん:2010/10/19(火) 01:10:19
またLisp使いの人かよ

818 :デフォルトの名無しさん:2010/10/19(火) 01:16:23
> これ以上僕に向かって話題振らないでくれ。
はいはい、じゃあねバイバイw

819 :デフォルトの名無しさん:2010/10/19(火) 01:17:29
Lisp厨が一番痛い。スレタイ嫁

820 :デフォルトの名無しさん:2010/10/19(火) 01:19:04
まあ色々まぜるとPythonが威張れないからね

821 :デフォルトの名無しさん:2010/10/19(火) 01:22:06
しかしその人気のなさにも関わらず、LISP (現在では “Lisp”、もしくは“Arc”と書かれる)は
「マクロ」や「見下し」といった強力なプログラミングテクニックによって影響力ある言語であり続けている

822 :デフォルトの名無しさん:2010/10/19(火) 01:24:22
>>821
そのページは、JavaとC#だけネタでも何でもないただの事実が書いてあって
それがそのままネタになってるのが面白かったな

823 :779:2010/10/19(火) 01:37:06
>>786
読む上で引っかかることはあまりないけど、書く上で引っかかる。

というか盛んに読むことのみを見てRubyを批判するけど
プログラムってのは読むだけでは終わらないでしょ?
書く為に読むんじゃないか?読むだけのプログラミングって何?

Pythonが読むのに向いてるのは認めるよ。というか
自分も割とPythonを使うから、読みやすいのは百も承知。
他人のコードや、随分前の自分のコードも読めるのは良い点だ。
個人的なものなら、Rubyで書いたコードをPythonに移植することも多い。
後から見返すにはそのほうが楽な場合もあるからね。
(一部、文字列関連の処理はRubyのが少なくとも俺は読みやすいのでそこは除く)

ただ、書くなら俺はRubyのほうへ分があると考えている。
だから読む部分だけ見て批判するのはフェアではない。
いや、批判しても良いのだけれど、どうもその言い方に引っかかるものがある。
Rubyのコードを書いたことがあるのかな、と。
読んだだけで批判してやいないか、と思ってしまう。
いや、Pythonのコードもさほど書いていないのではないのか、と疑ってしまう。

もちろん読むことは大事だ。でもさ、読むのは最終的に書くためにするんだろ?
他人のコードただ読んでそれで終わりってプログラミングって無いんじゃね?
ただ読むだけでも、それは後に書くのに繋げるものじゃね?
なんか読みだけで見るのっておかしくね?

824 :デフォルトの名無しさん:2010/10/19(火) 01:40:07
> いや、Pythonのコードもさほど書いていないのではないのか、と疑ってしまう。
書いてはいるんだろうけど
比べる相手がアセンブラにC, C++じゃあ、そりゃ天国みたいなもんだろうね
Pythonは

825 :デフォルトの名無しさん:2010/10/19(火) 01:45:16
もう600レスほど使って無意味な会話続けてるけど、Pythonってこんなに貧しい言語じゃないよ。

826 :デフォルトの名無しさん:2010/10/19(火) 01:50:20
結局、各言語のマスタークラスがいないわけね。ここには

827 :デフォルトの名無しさん:2010/10/19(火) 01:52:11
タコツボ視野の自称マスターじゃ意味ない

828 :methane:2010/10/19(火) 02:14:09
>>823
書くために読んでるのは認めるけれど、書く量の数十倍のコードを読まない?
量じゃなくて時間で言っても、やっぱり書く時間より読んでる時間が長くない?

たぶん、この書きやすさと読みやすさのバランスがPythonとRubyの一番の違いだと思う。

両極端で言うと、ライブラリの不具合を直す数行のパッチを作るために何百行、何千行も
読むケースと、新規のWebサービスを短時間で立ち上げるために勝手知ったるフレーム
ワーク上でひたすら書くことに集中するケース。

僕の場合は前者はあるけど、後者は無いな。もちろん読み書き比率が100倍超えるようなのは
エッジケースだけど、平均しても数十倍はあると思う。

829 :デフォルトの名無しさん:2010/10/19(火) 02:19:08
最近は、フレームワークしか使えない人
というのも居てなんだかな

830 :デフォルトの名無しさん:2010/10/19(火) 02:35:28
特にRailsとRubyの区別が付いてない人が身近に多い。
キラーアプリみたいなもんだったからな。

831 :デフォルトの名無しさん:2010/10/19(火) 02:39:39
コード読む量のが多いとかチームで仕事とかなら性的肩言語のほうがいいなあ
LLは書き散らしてこそ花だと思ってるわ

832 :デフォルトの名無しさん:2010/10/19(火) 02:42:50
抽象化された表面部分だけなぞるってのも
何か切なくなってくるな。時代か。

誰もがマイケルの様に踊れるわけでもないか。

833 :デフォルトの名無しさん:2010/10/19(火) 02:44:16
性的言語はちょっとな
仕事では読みたくないな

834 :デフォルトの名無しさん:2010/10/19(火) 02:44:32
人生で使える時間は限られてるからな

835 :デフォルトの名無しさん:2010/10/19(火) 02:48:08
>>834はエロい>>833へのレスじゃないぞ
ねんのため

836 :デフォルトの名無しさん:2010/10/19(火) 02:48:47
いずれは低層部分も、何らかのパラダイムシフトがあるんだろうか

837 :デフォルトの名無しさん:2010/10/19(火) 02:50:52
このごろは論理回路の動作も理解してないド素人が増えた。
そんなんでWebアプリケーションなど書けると思ってんのかっ。

838 :デフォルトの名無しさん:2010/10/19(火) 02:52:12
お前らが偉そうにやってることはド素人でもちょちょいと出来ることだったんだよ

839 :デフォルトの名無しさん:2010/10/19(火) 02:54:49
と偉そうに語るRails信者であった。

840 :デフォルトの名無しさん:2010/10/19(火) 03:47:57
>>828
Pythonは言語として読むケースのほうが多いが、Rubyはツールとして書くことが多いな。
Railsとかその辺で開発言語としての側面が見られるようにはなったけど
そもそものポジション、目的は随分と違うと思うんだ。

「開発者」が「開発言語」として用いるものをややライトにした言語がPythonじゃないかな、と俺は思う。
インデントの強制など、「読み手」を重視した仕様で多人数や長期開発でも読みやすく
言語仕様は必要充分かつ最低限に抑え、様々なライブラリを標準のセットにしている。
反面、コードはやや長くなりがちで、コピペだけでもエディタの補助が欲しくなる。
組み込みライブラリは最低限なので、どうしてもライブラリに頼ることになる。

Rubyは逆で「ユーザ」が「ツール」として使うのがそもそも根底にあると思う。Perlの次って名前なぐらいだし。
左から右へと最小限のバックで書き足して行け、DSL的な拡張もしやすいため生産性はそれなりに高い。
多様な機能を言語に組み込み、標準機能と組み込みライブラリだけでも文字列処理などが出来る。
反面、DSL的拡張されたコードは長くなればなるほど読み難く、外部ライブラリの選択/利用には手間取ることも多い。
パースし辛い仕様のため正確なコード解析をしてくれる高機能エディタには滅多にお目に掛かれない。

もちろん、両者とも一部にあべこべな部分はあるのだけど…基本的にはこんな感じかと。
結局ね、適材適所だと思うんよ。よく比較される両者だけど、そもそもは全然違う。
片方の分野だけで語るのは、そこだけで完結する話ならいいんだけど
それを基準にもう片方をまるで全否定するような話は違うと思うんだよ。

841 :デフォルトの名無しさん:2010/10/19(火) 04:01:52
なるほど、要するにrubyは素人用ホビー言語だ

842 :デフォルトの名無しさん:2010/10/19(火) 04:25:26
masterminds of programmingでそこらへん
開発者が明確に書くかなーと思ったが、
Matzの話が短すぎたわ

843 :デフォルトの名無しさん:2010/10/19(火) 04:30:25
Matzはあちこちでちょくちょく話してるイメージ
そもそも原著にはMatz入ってないし、コードの世界でも読めばいいんじゃね

844 :デフォルトの名無しさん:2010/10/19(火) 04:37:36
matzはまとまった話を書かないからなあ
っていうか記録自体も苦手らしく、
たぶんストラウストラップのD&Eみたいな本は書けないだろうw

まあこれまでの断片的な発言と、
Rubyの仕様・歴史から読み取っていくしかない

845 :デフォルトの名無しさん:2010/10/19(火) 05:06:01
masterminds of programmingって
awkの章はでかいのにMatzの話が短すぎ
なのに日本版表紙はMatzがawkを潰してる

846 :デフォルトの名無しさん:2010/10/19(火) 07:30:56
なんかRubyのほうが読みにくいという話になってるけど、Rubyは十分読みやすいよ。
PythonよりRubyのほうが覚えることが多いというのならわかるんだけど、Pythonのほうが読みやすいというのは同意できないね。
Pythonの人はどうしても「RubyよりPythonのほうが読みやすい」という結論にもっていきたいようだけど、
あの人が批判されているのは、最低限の勉強もせずに「Rubyは読めない」と決めつつけていることでしょ。
それに対する反省もなさそうだし。
・superは俺が想像したのと違った。だからPythonのほうが読みやすい。
・symbolは俺が知っている言語にはなかった。だからPythonのほうが読みやすい。
こんな話をまじで主張してるんだぜ?だれが納得できるんだよ。


847 :デフォルトの名無しさん:2010/10/19(火) 07:55:47
Pythonが読みやすいのは一般論だから、むしろ>>846に同意しかねるわ
どういう根拠で読みやすいとか言ってんの?

848 :デフォルトの名無しさん:2010/10/19(火) 08:14:52
あたまから一般論とか決めつけてかかられても困るわ。
だったらこっちとしても、Rubyが読みやすいのは一般論、とさせてもらおうw

849 :デフォルトの名無しさん:2010/10/19(火) 08:15:58
methaneさんは個人的な体験を拡張しすぎてないか。
俺もずっとpythonが読みやすいと思ってたんだけど、ここの議論を追ってるうちに自信がぐらついた。

850 :デフォルトの名無しさん:2010/10/19(火) 08:18:59
Rubyは文法の自由度が高いからトリッキーな書き方もできる
Pythonはそこをあえて縛ってるから統一された書き方に集約される
どっちが上というわけじゃないけど、
書くときはRubyの方が楽、読むときはPythonの方が楽という印象

851 :デフォルトの名無しさん:2010/10/19(火) 08:24:46
IDEの話がちろっと出てたけど、Pythonってまともに補完やリファクタリングできるエディタもしくはeclipseのプラグイン出てるの?あるなら興味出てくるなー

Rubyの今後の課題はこれだとおもうわ
「まともなIDEが一つもない」

852 :デフォルトの名無しさん:2010/10/19(火) 08:31:28
>・superは俺が想像したのと違った。だからPythonのほうが読みやすい。
>・symbolは俺が知っている言語にはなかった。だからPythonのほうが読みやすい。
>こんな話をまじで主張してるんだぜ?だれが納得できるんだよ。

驚き最小の原則から言えば間違った主張ではないな

853 :デフォルトの名無しさん:2010/10/19(火) 08:41:59
「俺の知ってるX言語ではこうだから」って言われるのがウザい、というのが、
驚き最小って言うのをやめた結構大きな理由だったな、確か。

854 :デフォルトの名無しさん:2010/10/19(火) 08:46:58
ttp://slashdot.jp/developers/03/03/14/0258247.shtml
> Rubyが「驚き最小の原則」と言う場合には、さまざまなバックグラウンドの人々
> すべてを驚かせないことではなく(それはそもそも不可能でしょう)、
> Ruby のやり方に十分に慣れた人が持つ常識が一貫して通用するという意味です。

ということらしいから。

「さまざまなバックグラウンドの人々すべてを驚かせないこと」という意味では
Pythonの方が驚き最小の原則を重視してる気がする。

855 :デフォルトの名無しさん:2010/10/19(火) 08:53:12
>>854
そういう驚き最小ならPHPでいいんじゃないの?
インデントでスコープとかいきなり驚きだよ

856 :デフォルトの名無しさん:2010/10/19(火) 09:22:00
EclipseのJavaと、そこらへんのテキストエディタのRubyなら、前者の方が読みやすいし書きやすい

言語レベルで多少違っても今はIDEが吸収してしまう
リファクタリング、ユニットテスト、バージョン管理なども含んでくるとなおさら

ゆとり世代にEmacsやVim使えというのは、言語レベルの読みやすさ書きやすさの議論が吹き飛ぶほど本末転倒


857 :デフォルトの名無しさん:2010/10/19(火) 09:56:20
pythonが読みやすいってのは、整形が強制されてるから。という意味なの?





858 :デフォルトの名無しさん:2010/10/19(火) 09:57:37
>>785
そう言うやつは万民と馬鹿の境界値

859 :デフォルトの名無しさん:2010/10/19(火) 10:07:21
>>848
そういう思想で設計されてるから。

860 :デフォルトの名無しさん:2010/10/19(火) 10:26:44
>>855
入口だけはそう見えるかもしれないが、実際はPHPのほうがびっくり仕様満載だろ。
"0" == false, 0.0 == false, 0.0 == "0.0" なのに "0.0" != false とか。

スコープの話だとグローバルレベルと関数レベルしかないってのもびっくりだったな。
おかげで reference と同名の通常変数を関数内で使いまわしてハマったり。

861 :methane:2010/10/19(火) 10:37:31
>>846
私は「他言語ユーザーが」「読みにくい気がする」という感想を述べて、具体的に
Rubyのコードを読んでたときにハマった点を挙げていただけです。

一般論としてRubyが読めないという主張はしていませんん。むしろ、自分の感想が
一般的かどうかを知りたくてTwitterでつぶやいたんです。
そう聴こえたならごめんなさい。ちょっと熱くなり過ぎていました。

>>850
Pythonの方がコードレベルでは「Pythonicな書き方は1つが良い」を標榜しているのですが、
それがどれくらい読みやすさに貢献してるかは(記号の少なさと同じく)不明ですね。
多人数がメンテナンスしていても複数のスタイルが混ざることが無いので、オープンソースアプリの
メンテナンスは楽になると思います。
少なくとも、低レベルにおいてはインデントなどが「4スペ推奨」が決まっているので、
プロジェクトごとにエディタの設定を変更する必要がありません。

>>855
Pythonの世界では驚き最小とは言いませんね。for文のelse節とか他言語ユーザーには
すごい驚きですが、キーワードの追加なしにすごく読みやすくなると思います。
C++でイテレータを扱うときの if (it != itend) はもう何度も書いているので読むときに引っかかる
ことは無いですが、やはりPythonの方が直感的です。

862 :デフォルトの名無しさん:2010/10/19(火) 10:42:41
>>860
クラスレベルのスコープは欲しいよね。
そうすればselfが少なくなって読むのも書くのも楽になりそう。

863 :デフォルトの名無しさん:2010/10/19(火) 12:52:37
>>855
こまかいことだけど、Pythonのインデントとスコープは関係ないよ
そもそもPythonにはC系言語のブロックスコープという概念がないし
{
 int x = 1;
 printf("%d\n", x);
}
に似たことをやる場合、Pythonでは
def _():
 x = 1
 print x
_()
とでもなるのかな多分

864 :デフォルトの名無しさん:2010/10/19(火) 13:31:14
x = 1
def f():
    print x
    x = 2
    print x
f()
print x

これはf()の最初のprint文で未初期化変数の参照エラーになるのだが
この辺もPython知らない人にとっては驚きの要因だと思う

865 :デフォルトの名無しさん:2010/10/19(火) 13:48:09
C++だと、これは期待通りに動く

template <typename T> void p(T x) { std::cout << x << std::endl; }
main()
{
    int x = 1;
    {
        p(x);
        int x = 2;
        p(x);
    }
    p(x);
}

もっとも、こうすると動かない
main()
{
    int x = 1;
    {
        p(x);
        int x = x;
        ++x;
        p(x);
    }
    p(x);
}

新たなバインディングを定義している初期化式 x = xの中で既に新しいxが
有効になっているので、右辺のxは新しいxであると解釈され、
未初期化変数を参照していることになる

866 :デフォルトの名無しさん:2010/10/19(火) 14:43:02
質問です。下記のように関数内関数を用意するとします。
---
function A(){
function X(){
printf("AのXが呼び出された。");
}

X(); // ←ここA
}

function B(){
function X(){
printf("BのXが呼び出された。");
}

X(); // ←ここB
}
---
関数内関数名を同じ名前にした場合、ここAとここBは同じそれぞれの関数内関数を呼んでくれるのでしょうか。
それとも、エラーになって実行できないのでしょうか。

867 :デフォルトの名無しさん:2010/10/19(火) 15:12:41
>>864
それ驚くほどのことなの?

868 :デフォルトの名無しさん:2010/10/19(火) 15:29:20
初期化と代入の違いが明示されていない。
「implicitよりもexplicitのほうがよい」と考えなかったことが驚き。

869 :デフォルトの名無しさん:2010/10/19(火) 15:39:06
>>867
Pythonはレキシカルスコープで上位のスコープの変数を普通に参照できるのだが
新しく導入した束縛のスコープは現在の関数全体になるので
このようにスコープの途中で導入した束縛変数は
それより前の式や文では使えないにも関わらず、他の名前を隠す

そういう仕様だと理解していれば特に驚くには当たらない
が、Pythonのレキシカルスコープは、Pythonを知らない人にとっては地雷原だと思うよ

870 :デフォルトの名無しさん:2010/10/19(火) 16:18:20
my $x = 1;
{
    print "$x\n";
    my $x = $x + 1;
    print "$x\n";
}
print "$x\n";

この例で見る限り、PerlのスコープはC++よりまともだね

871 :methane:2010/10/19(火) 16:54:03
>>870
その仕様がマトモと見る人と、C++の仕様の方がマトモと見る人、どちらもいると思う。
僕はC++の、同じスコープで同じ名前は必ず同じ実体を指すルールの方が好き。

872 :デフォルトの名無しさん:2010/10/19(火) 16:55:57
> 僕はC++の、同じスコープで同じ名前は必ず同じ実体を指すルールの方が好き。

>>865の最初のp(x)は1と出力し
2番目のp(x)は2と出力するのがC++だよ

何でそんな勘違いをするようになったのか知りたいね

873 :methane:2010/10/19(火) 16:59:19
>>872
うわ、マジか。
そうか、後方参照できるのはクラス定義内だけだったな。
>>871は s/C++/Python/ と言い換えてくれ。

874 :デフォルトの名無しさん:2010/10/19(火) 17:03:55
スコープ関連だとレキシカルもダイナミックも両方使えるPerlが一番すごいと思う

875 :デフォルトの名無しさん:2010/10/19(火) 17:07:39
>>874
じゃあ有効期間(エクステント)まで制御できる
Common Lispはもっとすごいのか……? なんか違くね?

876 :デフォルトの名無しさん:2010/10/19(火) 17:07:46
CommonLispも両方使えるよ

877 :デフォルトの名無しさん:2010/10/19(火) 17:09:12
scopeの問題じゃなくてparseの違いだと思うんだが

878 :デフォルトの名無しさん:2010/10/19(火) 17:12:27
ちなみに>>870で「まとも」だ、と言ってる理由は、
C++は変数を「基本的には」使えるようになってから可視にしてるんだが、
その変数の初期化式の右辺値式というタイミングでは、まだ使えないのに
可視にしてしまっているから
要は残念賞

Pythonの仕様は「ユーザにとっては」得になるところが何も無いと思うよ
その変数を使えないところで、無意味に他を隠されてもね

勿論それ以前の問題として、>>868が指摘しているように、>>864
x = 2が自由変数への代入だか新しい束縛変数の初期化だか
初心者には分からないだとか、
同じ名前の自由変数があってもデフォルトで新しい束縛変数を作る仕様なので
挙動を変える為にはnonlocal文が必要になる(3より前は手段がない)とか、
問題山積みなわけだけど


879 :デフォルトの名無しさん:2010/10/19(火) 17:23:09
>>878
初期化子時点で宣言したての変数を有効にするのは

int i = sizeof(i);

みたいな記述を許すためじゃなかったっけ?
まあこの仕様が良いかはともかく・・・・
以前のC質問スレで嵌ってる人を見た記憶がある

880 :デフォルトの名無しさん:2010/10/19(火) 17:24:09
>>875
すごい≠便利 だからそこは区別するべき
Common Lisp はすごい ってのは間違っていないと思う

881 :デフォルトの名無しさん:2010/10/19(火) 17:57:51
Perlの構文はCライクだけど、スコープのベースはLispなんだよな多分
だからスコープに関してはまとも、というか

882 :methane:2010/10/19(火) 18:07:06
>>878
>Pythonの仕様は「ユーザにとっては」得になるところが何も無いと思うよ
少なくとも、フールプルーフの点では意味があると思う。
例えば、C++だと、継承したクラスで親クラスと同名でシグネチャの違うメソッドを定義したら
勝手に多重定義にせずに親側を隠蔽するのも同じ理由。

エラーにならずに意図しない動作でプログラムが動き続けるより、エラーになった方が良い。
この例で言えば、外のスコープの変数と内のスコープの変数両方にアクセスしたいのであれば、
単に別の名前を使えば良いんだから、仕様がきつくても生産性は落ちない。
むしろ、変にハマって解決に時間がかかることが減るので、生産性が上がるかもしれない。

883 :デフォルトの名無しさん:2010/10/19(火) 18:27:33
>>882
フールプルーフとかいうのなら、ちゃんと代入と束縛の区別をして、
さらにそういうのがお好みなら、そもそもC#のように自由変数と同じ名前の変数を
作れないようにするほうが何倍も役に立つと思うよ

なんか役に立たないところで無駄にユーザの自由を縛ってるよね

884 :デフォルトの名無しさん:2010/10/19(火) 18:34:07
LLスレで、Lispの方がーC#の方がー

885 :デフォルトの名無しさん:2010/10/19(火) 18:38:06
例えばPerlなら、use strictしてれば、代入のつもりがtypoで
新しい変数をつくってました、みたいな馬鹿げたエラーはありえないし
エラーはバイトコンパイル時に即座に検出されるよ
フールプルーフってそういうことじゃないの

一方>>864は、Pythonは実行時検出だから、f()を呼んで動かして
はじめて分かるエラーだよ
フールプルーフなんてご立派なものじゃないと思うけどね

886 :デフォルトの名無しさん:2010/10/19(火) 19:11:49
PyはFAQに、利用前にglobal文に宣言が必要なのは、
 ・関数にはクラスと違い代入による糞 自動コピーinstantiationは無くマニュアルコピーだから、
 ・globalの改造前にはコピー取ってねというメモ・思い出して貰う為の仕様
とあったような。


887 :デフォルトの名無しさん:2010/10/19(火) 19:15:38
>>864
要は、関数内のスコープが完全に分離されていて、
値を渡す/戻したいなら、明示的に書けということでしょ?


888 :デフォルトの名無しさん:2010/10/19(火) 19:23:32
>>887
?ちょっと何が言いたいかよくわからない
x = 1
def POOR_MANS_BLOCK():
    print x
    y = x + 1
    print y
POOR_MANS_BLOCK()
print x

こんな風に自分でα変換すれば勿論動くよ
違う変数名をつけるというのは、要するにそういうこと

889 :デフォルトの名無しさん:2010/10/19(火) 19:38:39
あぁ、なるほど。
thx 意味わかった。



890 :デフォルトの名無しさん:2010/10/19(火) 19:57:30
rubyならblockになるが、こんな感じか


x = 1

o = lambda {
  p x
  x = x + 1
  p x
}

o.call()
p x

# 1
# 2
# 2

891 :デフォルトの名無しさん:2010/10/19(火) 20:06:13
これはJavaScriptの仕様が一番落とし穴になりそうだな
var x = 1;
(function() {
alert(x);
var x = x + 1;
alert(x)
})();
alert(x);
// => undefined, NaN, 1

892 :デフォルトの名無しさん:2010/10/19(火) 20:11:10
x = 1;
(function() {
alert(x);
x = x + 1;
alert(x)
})();
alert(x);
// => 1, 2, 2

893 :デフォルトの名無しさん:2010/10/19(火) 21:12:23
今まで、LispはLLだと思ってたけど、違うの?

894 :デフォルトの名無しさん:2010/10/19(火) 21:41:25
>>892
それは内側のスコープで変数宣言してないからそうなるのは当たり前でしょ

>>893
>>1の定義に従うとLispはLLっぽいね
条件全部満たしてるし

895 :デフォルトの名無しさん:2010/10/19(火) 22:09:55
bash

896 :デフォルトの名無しさん:2010/10/19(火) 22:31:13
ブロックスコープとかコンパイルエラーに関しては、Perlずっとやってて、スクリプト言語でもこれが当たり前なんだと思ってたら、RubyやPythonじゃ違うんだって知って驚いたな。

897 :デフォルトの名無しさん:2010/10/19(火) 22:33:16
そういう意味で言うと、phpは毛色が違うな

898 :デフォルトの名無しさん:2010/10/19(火) 22:33:59
perlはさっさと絶滅して欲しいね。COBOLじゃあるまいし。

899 :デフォルトの名無しさん:2010/10/20(水) 00:14:20
>>886
なるほど、ちゃんと理由はあったのね
ttp://docs.python.org/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value
自分もPythonがなぜこういう仕様なのか不思議に思ってたので参考になった

900 :デフォルトの名無しさん:2010/10/20(水) 02:22:19
privateは無いのに、そういう所にお節介入れてくるのは
どういう理屈なんだべ。

901 :デフォルトの名無しさん:2010/10/20(水) 04:02:47
>>900
privateがそもそも不要
だから無い

902 :デフォルトの名無しさん:2010/10/20(水) 04:42:01
それは、pythonには不要という意味?

903 :デフォルトの名無しさん:2010/10/20(水) 05:27:19
pythonじゃなくても不要

904 :デフォルトの名無しさん:2010/10/20(水) 05:52:32
というかよく引き合いに出されるRubyも
Javaみたいな意味のprivateは無いしな

905 :デフォルトの名無しさん:2010/10/20(水) 06:29:06
matzは互換性の観点から変更は不可能だと述べていたが、
Rubyの可視性は微妙に設計ミスっぽい
確か今年のRuby会議で話題になっていたと思う

現行方式にはそれほどメリットが無い割に、混乱の元

906 :デフォルトの名無しさん:2010/10/20(水) 06:53:08
>>890
それで思い出したけど、ブロックローカルな変数が宣言できるようになったね

x = 1

o = lambda { |;x|
  p x
  x = x + 1
  p x
}

o.call()
p x

907 :デフォルトの名無しさん:2010/10/20(水) 08:32:20
>Rubyの可視性は微妙に設計ミスっぽい

それを言うならpythonも設計ミスと言い張ることも出来てしまう


908 :デフォルトの名無しさん:2010/10/20(水) 08:51:12
はあ。

909 :デフォルトの名無しさん:2010/10/20(水) 09:16:27
C++ も設計ミスらしいな

910 :デフォルトの名無しさん:2010/10/20(水) 09:27:56
なんでPythonな人はRubyがきらいなん?
なんでPerlな人はPHPがきらいなん?
なんでJavaな人はCOBOLがきらいなん?

おしえてエキスパートなひと。

911 :デフォルトの名無しさん:2010/10/20(水) 09:40:03
おれの予想だけど

>なんでPythonな人はRubyがきらいなん?
そんなことはない
>>910 の被害妄想

>なんでPerlな人はPHPがきらいなん?
/cgi-bin じゃなくて /htdocs にファイルを置くから

>なんでJavaな人はCOBOLがきらいなん?
似たもの同士だから

912 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/20(水) 11:09:13
同族嫌悪

913 :デフォルトの名無しさん:2010/10/20(水) 11:43:58
>>911
じゃあ質問を変えよう。
PythonのエキスパートはなんでRubyがきらいなん?


914 :methane:2010/10/20(水) 12:02:48
>>913
僕の事を言ってるのであれば、別に嫌ってはないよ。
Pythonと同じく、汎用で生産性が高くて(Perlに比べた個人の感想としては)文法がすっきりしている、
良い言語。比べてたのはあまりに似ているから。

ただ、Pythonと守備範囲がほとんど同じだから真面目勉強する意欲が沸かないし、
時々同僚の書いたコードのメンテナンスができれば十分。

915 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/20(水) 12:03:10
なん?なん?なん?

そんなにナンが好きなのか!!!!!

916 :Perl忍者 ◆M5ZWRnXOj6 :2010/10/20(水) 12:08:50
・・・ なんx4

おれはこれを何かの暗号だと疑問に思い始めた

なんなんなんなん・・・いや4 よん よん

そう・・・あれだ 





キム・4なん?

917 :デフォルトの名無しさん:2010/10/20(水) 12:13:47
Rubyに出来てPythonにできないことってどんなのがある?
オープンクラスとか?

winでの使い勝手がrubyはひどいからpythonに鞍替えしてみようかな

918 :デフォルトの名無しさん:2010/10/20(水) 12:33:18
>>914
> 僕の事を言ってるのであれば、別に嫌ってはないよ。
え、あんだけさんざん書いておいて嫌ってないだって?どの口が言ってる?
もういちど自分のかいたのを読み返したら?>>438とか>>442とか。
こんなの嫌いだから書いてるに決まってるじゃん


919 :デフォルトの名無しさん:2010/10/20(水) 13:03:22
本当に嫌いな人はRubyの名前すら出さないよ

920 :デフォルトの名無しさん:2010/10/20(水) 13:22:17
反応を見るためにわざとそういう書き方をしましたってやつでしょw

921 :デフォルトの名無しさん:2010/10/20(水) 13:28:39
いわゆる後釣り宣言ですねわかります


922 :デフォルトの名無しさん:2010/10/20(水) 13:33:31
http://www.google.co.jp/search?q=python%E3%81%AE%E3%81%8A%E5%8B%89%E5%BC%B7+ruby%E5%8E%A8&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox

嫌ってるように見えるけど

923 :デフォルトの名無しさん:2010/10/20(水) 16:30:04
>>914
守備範囲は被ってる部分もあるが
それらを「ほとんど同じ」と称するなら
多くのLLは同じになってしまわないかな?
被る部分ばかり使うわけでもあるまいし…
下手をすればJavaですら「ほとんど同じ」になりゃしないか

>>917
ワンライナーとかかな
Windowsのコマンドプロンプトでは痒いところを
けっこう補助してくれるよ

924 :563から代行レス:2010/10/20(水) 16:30:34
>>564>>566
対戦相手との距離はそれでわかると思うけど
ダブルバトルでの味方のポケモン同士の距離はわからなくね?
ルールでは許容範囲でなるべく近い距離の方がいいからどっちかと言うとそっちのが知りたい

何で近い方がいいかと言うと>>479>>480でポケモンを「でんじは」という技から光速反応にできそう
ダブルバトルでは味方同士でも攻撃可能でかつその距離ででんじはを回避可能だから
なのでなるべく近い距離から求めた方がいい
ちなみに俺はコロシアムは持ってないから測定はできない

925 :デフォルトの名無しさん:2010/10/20(水) 16:34:11
なんでまたこんな誤爆が

926 :デフォルトの名無しさん:2010/10/20(水) 17:02:04
>>923
でもRubyをコマンドプロンプトで使うと文字コード的にダメすぎない?
同じコマンドプロンプトでもPythonだと文字化けがあんまりおきないみたいなんだろうけど、何が違うんだろう?


927 :デフォルトの名無しさん:2010/10/20(水) 17:14:58
iroiro

928 :methane:2010/10/20(水) 17:16:17
>>923
例えばJavaは起動が遅かったりメモリ食いだったり、ヘビーなので済み分けられますよね?
JavaScriptは、スクリプトとして使おうにも標準の処理系が無いですよね。
PHPは仕様がweb向けになっている部分があり、例えばGUIアプリ作ったりするのには向きませんよね?

スクリプトもサーバーもGUIアプリも書ける汎用のLLという性質がPythonとRubyに共通しています。
PerlはGUIアプリどうなんだろう?汎用というには少しスクリプト寄りな気がする。

929 :デフォルトの名無しさん:2010/10/20(水) 17:21:57
Ruby は GUI 作りに向いてないぞw

930 :デフォルトの名無しさん:2010/10/20(水) 17:42:26
PerlTk使ってる人いますか?

931 :デフォルトの名無しさん:2010/10/20(水) 18:02:00
>>925
ルビー/サファイアなるバージョンがあった気が

932 :デフォルトの名無しさん:2010/10/20(水) 18:04:57
ダイヤモンド・パールというバージョンも

933 :デフォルトの名無しさん:2010/10/20(水) 18:24:04
>>928
参考までに、Gtk+の対応状況を
http://www.gtk.org/language-bindings.html

# ニュアンスは分かる気がするけど、LLとスクリプトてどう違う?

934 :デフォルトの名無しさん:2010/10/20(水) 18:26:13
ruby -e はいいね。

935 :デフォルトの名無しさん:2010/10/20(水) 19:21:00
>>928
JavaScriptはWindows限定でもいいならWSHのJScriptがあって、これは割と活用されてると思うし、
インストール数ベースで言ったら他の追従を許さないんじゃないだろうか
Windows以外でもRhinoは以前からあったし、最近だとnode.jsなどサーバサイドJSも注目を集めてる

まあどっちにしろ手近な作業をするための言語として見たらWindows以外では Ruby/Python に敵わないとは思うけど、
「標準の処理系が無いからスクリプトとして使えない」ってのは理由になってないんじゃないかと思った

936 :デフォルトの名無しさん:2010/10/20(水) 19:53:51
>>922
PythonスレがRuby厨に荒らされたからだろ

937 :デフォルトの名無しさん:2010/10/20(水) 20:04:36
>>917
ActivePerlがさいきょう!


938 :デフォルトの名無しさん:2010/10/20(水) 20:40:02
ECMA-262には入出力や(基本的なもの以外の)ライブラリの規定がない、という意味じゃないの。
つまりjsはなんらかの独自ライブラリ実装や拡張をした実装じゃないとロクに使えない。
しかもライブラリとJavaScriptとのバインドするAPIは各実装ごとに異なっている。
どちらかというと、組み込んで使うタイプの言語だと思う。
WScirpt/CScriptって要はWindowsに組み込んだjsみたいな位置づけでしょ?

939 :デフォルトの名無しさん:2010/10/20(水) 21:08:02
awk

940 :デフォルトの名無しさん:2010/10/20(水) 21:11:09
そういえばAdobeの、いわゆるCSシリーズにもjs組み込まれてたね。Photoshopとか。

941 :デフォルトの名無しさん:2010/10/20(水) 21:11:55
Rubyなんて使わなくてPerlでええんちゃう?

942 :デフォルトの名無しさん:2010/10/20(水) 21:19:06
>>939
俺もワンライナーならawkやsed結構使うよ

943 :デフォルトの名無しさん:2010/10/20(水) 21:33:28
>>942
俺もsedやawkは使うけど、制御自体は
シェルスクリプトでやることが多いかな。

944 :デフォルトの名無しさん:2010/10/20(水) 23:14:44
>>914
うん、あんた他人にフェアな比較がどうこうって言える立場じゃないよ(キリッ

945 :デフォルトの名無しさん:2010/10/20(水) 23:22:51
みんなはどんな理由で python or rubyを選択したんだ?


946 :methane:2010/10/20(水) 23:41:12
>>929,933
へぇ。
UbuntuのデフォルトGUIアプリでRuby採用されてないのは単にPerl、Pythonに加えて
RubyまでインストールするとライブCDの容量が苦しいからかと思ってたんだけど、
そもそもサポートがそんなにされてないのか。

言語仕様から見ると特定用途に偏ってるようには見えない(正規表現がリテラルだったり、
Pythonより少しPerlよりだけど)のに、Webとそれ以外でRubyの盛り上がり方の差が
激しいのはなんでだろう。
Railsの知名度がすごすぎて、Web系言語と思われてWeb系以外の技術者流入が少ない?

947 :デフォルトの名無しさん:2010/10/20(水) 23:52:41
Mirahは?
http://www.engineyard.com/v/WlsD2FiBIbg

948 :デフォルトの名無しさん:2010/10/21(木) 00:11:21
>>945
たまたま使ってた影舞ってツールがRubyだったんで
改造する必要があってRubyをやった。
んで、Pythonのツールは改造したこと無いんで
Pythonは知らない。

あんまり積極的には選択してないね。

949 :デフォルトの名無しさん:2010/10/21(木) 09:25:45
>>945
自分は趣味WEBプログラマーなんであんまり参考にならんかもしれんけど、自分のホームページに
掲示板を付け加えたくて、Perlのフリー掲示板を組み入れた。

それを改造したくてPerlを勉強。
オブジェクト指向言語のほうがいいのかなと思い、Perlに近いRubyを勉強したって感じ。

950 :デフォルトの名無しさん:2010/10/21(木) 09:26:49
インタープリタのソースを見たら、Rubyを使う気がしなくなった。

あんまり積極的には選択してないね。

951 :デフォルトの名無しさん:2010/10/21(木) 10:28:52
Ruby使っていたんだが目糞鼻糞だから
前に使ってたPerlにチェンジしたわ

952 :デフォルトの名無しさん:2010/10/21(木) 12:55:57
>>946
> 特定用途に偏ってるようには見えない(正規表現がリテラルだったり

それは充分偏ってると言って良いのでは。
Pythonではライブラリで実装するレベルでしょ、正規表現って。
それをライブラリで実装せず、わざわざリテラルにしているってことは
言語仕様として文字列処理を重視している、ということ。

953 :デフォルトの名無しさん:2010/10/21(木) 12:57:18
>>926
Cygwin版使ってない?
mswin版でならそれほどでも無かった気がする。

954 :953:2010/10/21(木) 13:02:28
>>926
あ、あとソースコードのロケールもSJIS(というかMS-CP932か)で揃えたほうが良いかな。
RubyはJavaやPythonみたいにUnicodeにすればいい、みたいなのとは真逆で
基本的には全てその環境に合ったものに揃えたほうが楽だと思う。
バイナリはmswin、ロケールはMS-CP932って感じで。

955 :デフォルトの名無しさん:2010/10/21(木) 14:38:28
たしかに、正規表現を言語仕様に入れるのは汎用言語としては、ちょっとね。
正規表現って高速なの実装するとけっこう規模でかいんだよな。PCREとか。

956 :デフォルトの名無しさん:2010/10/21(木) 16:27:50
Pythonの正規表現ってre.compileしてもPerlやRubyより遅いの?

957 :デフォルトの名無しさん:2010/10/21(木) 17:09:01
どれも遅いんじゃないの

importe re
pattern = re.compile('a?' * 30 + 'a' * 30)
pattern.search('a' * 30)

しばらく返ってこないよ
Perlも同じ
Tclのは速いんじゃなかったかな

$ python -c 'print "a"*30' | egrep `python -c 'print "a?"*30 + "a"*30'`
これは瞬時に返るけどね
(一応言っとくと、↑はaを沢山打つのが面倒だから文字列の生成に
Pythonを使ってるけど、パターンマッチを行ってるのはegrep)

958 :デフォルトの名無しさん:2010/10/21(木) 19:34:37
文字列処理はどの言語がはやいの?

959 :デフォルトの名無しさん:2010/10/21(木) 21:41:13
正規表現は、Tcl最強伝説

960 :デフォルトの名無しさん:2010/10/21(木) 22:17:30


961 :デフォルトの名無しさん:2010/10/21(木) 22:22:09
Perl,PHP,Ruby,Python
どれもJava以下のくそ言語どもか

962 :デフォルトの名無しさん:2010/10/21(木) 22:58:51
Javaの正規表現実装は残念だとかなんとか……
さんざん苦戦したJRubyの中の人は、最終的に鬼車のポートを採用した

高速だという売り込みで話題になっていたのは
ぐーぐる謹製のre2とかか
cl-irregsexpなんてのも聞いたことがある

963 :デフォルトの名無しさん:2010/10/21(木) 23:17:50
誰かPerl/TK使ってる人いますか?

964 :デフォルトの名無しさん:2010/10/21(木) 23:38:43
鬼車も普通に遅いよね
戻ってくるまですんげー待たされる

#include <stdio.h>
#include <oniguruma.h>

main()
{
    regex_t *re;
    const char *pattern =
        "a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?"
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
    const char *s = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
    OnigErrorInfo error;

    if (onig_new(&re, pattern, pattern + 90,
                ONIG_OPTION_DEFAULT, ONIG_ENCODING_ASCII,
                ONIG_SYNTAX_POSIX_EXTENDED, &error) != ONIG_NORMAL)
        return fputs("onig_new", stderr), 2;
    printf("%d\n", onig_search(re, s, s + 30, s, s + 30, 0, 0));
}


965 :デフォルトの名無しさん:2010/10/22(金) 00:08:38
採用したアルゴリズムの関係で苦手なパターンがあるってことじゃなかったけ?
どんなパターンでも常に遅い訳ではないよね。

966 :デフォルトの名無しさん:2010/10/22(金) 00:13:22
http://swtch.com/~rsc/regexp/regexp1.html

967 :デフォルトの名無しさん:2010/10/22(金) 00:21:53
鬼車のウリは高速実装というより多エンコーディング対応じゃないの

968 :デフォルトの名無しさん:2010/10/22(金) 00:26:17
処理が深ーーーくなったときに打ちきるなんてのがあったな。


969 :デフォルトの名無しさん:2010/10/22(金) 00:37:49
>>968
boost::regexはそうだった
バックリファレンス含みのパターンの場合はかなり早い段階で諦めて例外を出す

970 :デフォルトの名無しさん:2010/10/22(金) 00:56:16
COMBINATION_EXPLOSION。

971 :デフォルトの名無しさん:2010/10/22(金) 01:50:34
オブジェクトのアロケーション・解放が速いのはどれ?

972 :デフォルトの名無しさん:2010/10/22(金) 02:09:37
C++

973 :デフォルトの名無しさん:2010/10/22(金) 13:07:28
>>946
このへん言葉にし辛いが、
Rubyをやってる人が高速リッチな、Ruby/Tkや単純なHTML+Webサーバで済まないGUIを必要とした場合は
素直に他のGUIが得意な言語で作る

Ruby自体、
「この分野はRubyが苦手そうだけど、頑張ればなんとかRubyでも書けるかもしれんのでやってみるか」
とか思わせない言語なので(Cで書かれた第三者拡張ライブラリ多すぎだ)、
そもそも無理してRubyで書いてみようというモチベーションが上がらないのが文化として根付いてる

無理してRubyで書く必要ないじゃん? みたいな

974 :デフォルトの名無しさん:2010/10/22(金) 13:13:55
無理したのが CGI.rb

975 :デフォルトの名無しさん:2010/10/22(金) 13:21:14
cgi.rbはまだrubyのプログラミングについての知見が足らない頃に書かれたから

976 :デフォルトの名無しさん:2010/10/22(金) 13:29:14
cgi.rbは、どの辺が駄目なの?

977 :デフォルトの名無しさん:2010/10/22(金) 13:57:44
cgi.rb がイケてない 12 の理由
http://jp.rubyist.net/magazine/?0023-Cgirb

978 :デフォルトの名無しさん:2010/10/22(金) 14:32:40
CGI.pmと同じようなの速攻で添付すればRuby普及に一役買うんじゃね?
あっRubyってなんか超イケてる書き方とかできてすごくねヤバくね?

という古代Rubyの2要素が絡み合ってできた負の遺産がCGI.rb


実のところ頑張って中身は現代風に直したんだが(オリジナルのCGI.rbはもう添付されていない)
インタフェース消すわけにはいかんので現在もまだちょっと微妙

979 :デフォルトの名無しさん:2010/10/22(金) 16:02:04
速度でいったらC/C++には敵わんな

980 :デフォルトの名無しさん:2010/10/22(金) 16:45:43
>>978
5年くらい前ならそれでよかったかもね

981 :デフォルトの名無しさん:2010/10/22(金) 17:17:17
pythonとrubyは使えるんだけど、perlだけはどうしても生理的に受け付けなかった。
でもCPANを無視するもの勿体なかったので、我慢し続けてperlを使い続けてたら
perl使いになっちゃったよ。

982 :デフォルトの名無しさん:2010/10/22(金) 17:24:48
cgi.rbは、昔ソースを読もうとしたら超読みにくかったんで
俺はruby向いてないのかもと暗い気持ちになった思い出があるが、
あれはコードの方が悪かったのか。


983 :デフォルトの名無しさん:2010/10/22(金) 17:25:52
そっれはないw

984 :デフォルトの名無しさん:2010/10/23(土) 08:17:57
パイソンってWEBのサーバー側の言語として使える?
VBみたくコンパイルしてEXEファイルとか作れるの?

できるならパイソンって最強じゃね?と思ったんだけど。

985 :デフォルトの名無しさん:2010/10/23(土) 08:43:35
webサーバも書けるし、その上で動くアプリも書ける。
一応exe化もできる。DropBoxとか、Pythonをexe化してるアプリの例。

986 :デフォルトの名無しさん:2010/10/23(土) 08:46:27
python -> javascript のコンパイラもあるね pyjamas とか

987 :デフォルトの名無しさん:2010/10/23(土) 08:54:27
レスサンキュー。パイソンすごいね。

でも、仕事で言うとPHPが圧倒的だよね?
パイソン経験者募集ってあんま見たことない。

そんな自分はVBS…おわた\(´∀`)/

988 :デフォルトの名無しさん:2010/10/23(土) 09:04:17
dropboxのクライアントってPythonで書かれてるのか Mac版やLinux版もPythonベースのアプリ?

989 :デフォルトの名無しさん:2010/10/23(土) 09:44:25
MacのDropbox.appの中にはpythonインタプリタとかlib以下とか
丸ごと放り込まれてるな。ネイティブ部分もあるけど。



990 :デフォルトの名無しさん:2010/10/24(日) 06:57:40
ふむ

991 :デフォルトの名無しさん:2010/10/24(日) 12:10:16
MacのDropBoxって低機能だよな。

992 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 12:54:18
Mac使ってるやつってPHP比率とRuby比率が多くてキモいからさ
しね
しね?なあ?死んで?お願いだからさ?おいぉいぉぃおいぉぃおぃ死んじまえば?

きもちわりいんだよマック製品について熱弁して

ipad重いとかmacいいよねとか ばか?
iphoeがどうたらとか クソマカってほんとカメラとiphoneとipadばっかりだよな

マカーってどくとくの痛さがあるよなほんと
マカー=初音ミクオタのオタのおおさが異常だけおさ
アニオタ比率たかいし脳みそもたりてねえしさ

993 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 12:58:06
マカーの系のアニオタはスクリプトもくめねえただのパクリ野郎ばっかりだからな
koregaとかw製品についてのレビューとかジェット大輔あたりみたいなそんなぬるい音楽オタ+アニオタばっかり


マカーの作るサイトってどくとくの痛さがあってね
シンプルイズザベストみたいな考えがあったり
アクア風とかステンレそういうオタがおおくてさ

あとアップルマークのロゴいれてんだよねwwwwwwwww
まあApple社からみれば宣伝ありがとうぐらいでしょ
ジョブスやたらとマンセーするしカスそのものだよ

あとサカナクションっていうマカー専用ゴミバンドがあんだけど
シンセカイだっけなんかアップルの製品まるだしでさw しかもギターにAppleシールはってるかすw
マックつかえば芸術性があるとおもいこんでる模倣バカw

マカーはごみしかいねえよホンマw

994 :デフォルトの名無しさん:2010/10/24(日) 12:58:27
相変わらずの毒舌ぶり

995 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:03:18
だいたいこれ当てはまってんだよね
俺が腐るほどの林檎ユーザー(アップルユーザーとせっしてきたからw


統計結果がこれだよw

まあバカマカー自体 カルチャーっていうかネットでの居場所もかぎられてるから
変な団結力があるからねw排他的というか村社会というかw

カスマカーはアスペルガーがおおいよw 自営業とかおおいしねw

マカーの定めだからねw

だからマカーがPHP+Rubyをやるのは ターミナルとかxcodeとか入門で入りやすいところだねw
ここが3キモ言語発生だよwマックから開発環境を消し去ればうんこみたいな3キモ言語バカが生まれることはないからさw

おれは次のosxからターミナルとかunix系のものをすべて破壊するからw
ここがweb土方マカーのspawn場所だよ

996 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:10:13
バカマカは無駄にiphoneもってるしさw
ろくな仕事してねえのにw生活が便利にすらなってない情弱w

iphoneに群がるバカそのものだよマカはw

まだまだスマートじゃねえのに使いやがってwオツムがたりてないのかなw

まあ得意な言葉がw

「買いたいときが買い時」
とかわめいてiphoneかってるヴァカもいるしwwwwwwwwwww

そもそもipad iphoneに金つぎ込んでるバカはいたすぎるw
物の価値がわからねえごみwwwwwwwwww
言い訳
「物の価値はひとそれぞれ」
wwwwwwwwwwwwwwwwwwwwwwwwwww
とかいって逃げるはなくそっぷりw

それで自分がiphoneを金はらってることが情弱じゃないように切り替えしてくるんだよw

あいつらはライフスタイルがクソだけど俺が
君たちスマートじゃないのにスマートフォンもって仕事の効率あがるとおもってんお?っていうと

仕事の効率じゃなくて 好きだから使ってるとかわめいてくるしw

っで何に使ってるの?ってきくと
youtube ゲーム メール ネットサーフィン appstore 電話
くらいかなwwwwwwwwwwwwwwwとかわめいてくるwwwwwwwwww

まああいつらバカだからさ ケイタイに金つぎこんでさw
まじばかだとおもうよw

997 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:11:29
こいつらバカを問いつめると

そんな効率的な生き方をしていてつまらなくない?

とか絶対いってくるからなwwwwwwwwwwwwwwwwwwwwwww

バカだからなマカーは直感抱けで生きてるごみ
考えられない

998 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:14:50
カスマカーはマイナー好きだからねw

これがカスマカーの定めw

出没するコミュニティもマイナーな場所w

海外オタがおおくて英語かじってるばかがおおいw
:)とかつかったりなw
wow!!とかw カスみたいな美徳ひきづっていきてるマカーは消えろ

カスマカはイラストつくってお絵描きしてればいだよw

999 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:15:54
Macっていうきめ単語をみると

虫唾が走るからねw


1000 :(信は力なり)Perl忍者 ◆M5ZWRnXOj6 :2010/10/24(日) 13:17:15
早くマカーは死ねばいいw

終了ーーーーーーーーーーーーーーーーーーーーーーーーーーーーw

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

317 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)