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

最強のＬＬ＝軽量プログラム言語は、どれよ？

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

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

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

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

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

※前スレ
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バトルロワイヤル２【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1209289408/
【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】
http://pc11.2ch.net/test/read.cgi/tech/1188997302/

>>1乙

Ruby最強

あんたも好きねぇ。

PHP を Perl, Ruby, Python と同じ土俵で比べるのはどうなの？
PHP は R, Maxima みたいに限られた用途に特化した言語だと思う。

PHP は ASP と比べるべき存在

Pythonはスコープがちょっと…嫌いかな。
意図してやってるんだろうけど。

ん？Pythonのスコープってそんなイリーガルなところあったっけ？
ごく普通のスコープだと思うが。
privateメンバが作れない、とかの話？

Rubyの間違いでした

Rubyのスコープって、privateが実質無くてprotected相当って辺りとか？

>>8 と >>10 は別人な希ガス

rubyのブロック内のスコープはたしかにちょっとハマりやすい

JavaScript派が通ります

JavaScript派はletをECMAScriptに追加するよう懇願するべき

JSのスコープって論外だよな。こんなんで、アニメーションやらデスクトップアプリ並のUIを制御しろって。

>>15
http://www.youtube.com/watch?v=P5sWncFiYnA

>>16
標準ライブラリの不足とかならともかく、スコープのせいで複雑なプログラムが作りにくくなるのか？

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

まぁ、そうかもしれない。スコープについては一応汚い解決策があるし
(function pseudo-let(){ })()

同じ事じゃん。ブロックで局所化出来ない、名前空間がない、PerlのstrictとかPHPのE_ALLのような警告機能もない。プア過ぎる。

strictはES5で導入される
名前空間も代替することはできる

ECMAScriptがどうだと言われても、IEでもFirefoxでも動くJavaScriptがそうなってなければ意味ないじゃん。
Perlのオブジェクト指向がよく批判されるけど、統一性のなさから言ってJavaScriptの方がよっぽど酷いじゃん。好き勝手な方法でクラスなりメソッドなり定義してて。

JavaScriptにはクラスもメソッドも無いんじゃなかったっけ

クラスは無いけどメソッドはありますよう

クラスの定義ってそんなにバリエーションあるかな。

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

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

そもそもjsはオブジェクト指向とか目指してなかった。
プロトタイプベースという考え方の上に成り立ってるだけ。
そこでオブジェクト指向チックに遊ぶこともできるだけ。

classというキーワードは無くても、JavaScriptもPerlもクラス相当のものを使ってプログラミングするけどな。

それならCでも(C++じゃなく)できるわ

>>26
x: そもそもjsはオブジェクト指向とか目指してなかった
o: そもそもjsはクラス指向とか目指してなかった

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

単なるスロット内蔵のクロージャだからな
schemeをベースに意味論を作れば間違いがなかった
jsはLISP派生として見れば失敗作だ

カリー化はschemeよりも便利に使えると思う > js

jsがボコボコに叩かれる流れになるかと見ていたけど、
jsけっこういいかも的な流れになりつつあるなw

ユーザはエセクラスベースオブジェクト指向じゃなくって、まともなクラスベースオブジェクト指向でプログラミングしたいんだから、そうせざるを得ない。
その要望に応えて、Perl6もECMAScriptもclassを導入してる。

C/C++/C#/Pythonで問題ある？

Javaがない

>>35
ありがとう

>>32
JSは昔、阿呆なコードが量産されてたから悪い印象持ってる人多いけど
言語仕様としてはちゃんとしてるからなあ

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

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

勘違いではなく事実だろう

>>26 はともかく、>>33 はちょっと偏見入ってる感じだな
クラスベースだけがまともなOOPL、ではない

勘違いだよ

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

ユーがOOPだと思ったものがOOPヨ
OOP感じなかったらそれはOOPとはノットネ

>>39
自分がプロトタイプベースのプログラミングが上手くできないのを責任転嫁してるだけ

>>42
別に矛盾はしてないと思うけどなあ。>>38は何か専門用語使いたいだけな感じ

プロトタイプベースとクラスベースっていう分け方がどうなのか？
PrototypeパターンとかってGOFにもあるわけだし。
動的なOOP言語はどちらかというとプロトタイプ寄りなんだし。
C++とかJavaの方がちょっと異色なんだよ。

適してる適してないとかいう話に勘違いも糞もあるか

>>44もプログラマの一人で普段から専門用語を使いまくりのはず
それなのに、自分が知らない言葉だったという理由で>>44を特殊な専門用語扱いするのは
矛盾してる(ダブスタのような)気がする

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

価値観の違いと勘違いは違うだろ。マ板に行ってくださいお願いします

自己レスで訂正
x: >>44を特殊な専門用語扱いするのは
x: >>38を特殊な専門用語扱いするのは

とりあえず >>26 が self という言語を知らないことだけは想像できる。

まあそんなアプローチもあるのかな？程度の印象ならば、違和感がなく自由なものに見えるのだろうか…

>>48
要はオブジェクト指向とは何か？という定義が曖昧なんだと思う
クラスベースしか認めない、って人にとってjsがエセに見えるんだろ

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

>>50
全然知らんわｗ

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

　　　　 　ﾄ､　　　　　　　　　　　　　　　　　　______）
　　　　 「::::＼┐　 _,,.　--──- ､..,,_　　　　｀ヽ.　 で　 泣　　も
　　 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＞く}:::７　　　 rﾉ／　　／ 　　　　＼　　ヽ ＼
　　　　　K_ 　　　_,r-イYﾝ/ﾑi:::::/　　 ,ノ´く　　／　(●)　(●)　＼　　>　）
　　 　 　 /Y＞ﾍﾞ´　 　'';:::::io:／　　 ,ｲ＼　｀／::::::⌒（__人__）⌒:::::＼'　/
　　 　 ,.:':::::ヽ､ン':,　　　 ヽ／　　　,ｲ /ﾞ,ｰ､ |　　　　　　 ￣　 　　　　|/
　　 ／:::/:::::::::::::::::ヽ.　 　'　　 　,.;'ヾ/､/_/ﾉ ＼ 　　 　 　　　 　 　 ／
　,く:::::::/::::::::::::::::::::::::`ヽ､___,.,.イi `'ｰ'^''‐'/ 　　 ＼ 　　　　　　　:::::/

LLというのは最初にPがつく言語のこと

>>55
Rubyからクレームがつくぞw

C++のクラスベースは、Cの構造体をベースにしている。
ほかの言語も、Cに似ていると色々都合が良いみたいだし
クラスベースでいいんじゃね？

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

絶対主義思想はどっちなんだか。>>58だって自分は絶対だって言ってるじゃん
議論を戦争が終わらない理由とかに安易に結び付けるような中学生みたいな奴が何言って寒い

このブログエントリの汎用性は異常

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

戦争が終わらないのは（自分以外の）一部の間違った人間のせいだ(ｷﾘｯ

>>60
志村だろ

>>60
あらー、Simulaは無視っすかw

>“1”ならもちろん Smalltalk 、“2”なら SIMULA

って書いてある

>>58
禿だけど同意

>>52で定義を価値観と言い換えてもかまわないって自分で言っといて何だコイツ

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

>>64
ああ、確かに。
失礼した。

シェルスクリプトの延長線上としてのJavaScript、が定着したのがWindowsだけってのがいまだに謎なのだわ

>>68
Unix 系は Perl がシェルスクリプトの延長線上だからね。
未だに、 ブラウザ組み込みじゃない JavaScript 処理系の決定版もないし。

仕様が先行して処理系がいまひとつぱっとしない
まるでLispだな

>>68
どういう意味かよくわからない…

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

WSH で Jscript が標準で使えることに対して、定着と言ってるのでは？
流行ってるかどうかは知らない。

WSH(Windows Scripting Host)を Windows Shell の略語だと思い込んでいるのではないかと

>>72
えー、WSHならVBでしょう？

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

>>68
まあ奇跡といえば奇跡だけど
Windowsにまともなシェルスクリプトがなかったからとも言える

つか、Windowsは今後シェルスクリプトと言えば、
PowerShellではないのか？
個人的にはあんまり好きではないが、確かに.NETライブラリを直接使えるのは
強力だと思う。

PowerShell は良いけどまだいまいち感がぬぐえない
IronPython とか IronRuby とかに期待

Iron系はなんか放置されてね？

IronPythonマンセーしたいけど、
Pythonは日本ではなぜかアレルギー示す人が多くて…(/_;)

2chではpythonの方が多いから大丈夫

>>80
え？そうなの？w
それは心強いなw

ironpythonはVS2010上でポトペタを使ってプログラミング出来ると思ったけどやり方が分からん

>>80
え？そうなの？w
それは心強いなw

Iron系は、開発者自体はやる気もあるし、それ以外の趣味や研究対象として興味持ってる社員も少なくないように見えるけど
社全体の方針としては話題性以上のものを期待してないし、リソース割く気もないんじゃないかと傍目に思う

大体、Iron〜とかって名前がよくねーよ。

>>80
え？そうなの？w
それは心強いなw

>>84-85
禿だけど同意

>>81>>83>>86
うん。大船に乗ったつもりで安心していいよ

>>88
ごめん。どうでもいいんだけど、俺の専ブラがおかしくて、
複数の書き込みしちゃったみたい。
以後気をつけます。

cscript.exe上のJScriptは結構使うなあ
Unix系で決定版が無いのは何でだろうな
現状、その使い方ができるECMAScript環境ってUnix系でどんなのがあるっけ？

emacslisp

ECMAScriptねえ…
そもそも、シェルスクリプトでCGIまで書けるUNIXにおいては、
需要があるとも思えないんだよなあw

まあそうなんだけどさw

間違えた

ｗ

>>85
Iron〜というと、つい「水、水がぁ〜」とか「弱ぇ〜」みたいなイメージが浮かんでしまう

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

>90
C++の悪口を言いながらPerlを愛用するのがUnix系
C++とPerl なぜ差がついたのか

ん？
C++は残るけどperlは消えるよ

unix系はCだろ

>98
Perlは簡単な仕事を簡単にすることが目的だった
C++は難しい仕事のことばかり考えている
簡単な仕事には将来性がないという考え方なんだろうな

cobolもshも消えないのに、普通に考えればどちらも消えない
古き良きbasicは

>>90
Rhinoとか最近だとV8かな

>>102
RhinoとかV8って単品でも使えるのか、知らんかった

RhinoやGroovyみたいなJVM上のスクリプティング言語は
起動が遅くてどうも使う気になれん

Scalaもおっそいね

>>104
たとえ起動が速かったとしても、JVMが冗長言語Javaのためのものだからなー。

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

>>106
うーん俺にとっては起動が遅いのが最大のネックであり全てだなあ
OS寄りの低レベルのことがやりにくいって問題はあると思うが
JVM上に乗ってりゃ少なくともライブラリ不足ということはないし
まともなUnicode対応が保証される

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

>>105,106
ScalaがJava VMベースだからという理由だけで好きになれない

gooはどうなんだろうな

>>103
Node.jsはエンジンにV8使ってるよね。

相対的にではなく、ruby/pythonのメリットでなんだべさ

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

豊富さという言葉も「XXXに対して豊富である」という相対的な評価でしかないんだけどな

Perl/PHP/JavaScriptなんかと比べてってこと？

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

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

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

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

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

といったところかねえ…

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

pythonについては、ぶっちゃけコーディングについての思想に共感できるかできないかって感じ
でもGoogle App Engineで使えるから、そこは今後にとって良いかも

RubyよりPythonのほうが好きだけど、DjangoよりRailsのほうが好き。
こんな俺はどうしたらいいんだろう。ちなみにweb2pyはPythonぽくなくて好きじゃない。

TurboGearsじゃだめ？

rubyはライブラリ少ないのかね。

俺はruby使いじゃないので、よくは知らんけど、
freshmeatとか見てる限りではPythonよりは
だいぶ少ないと思う。
ま、数があればいいってものでもないんですけどねw
多すぎればそれはそれで問題でw

>>116
ありがとう。ちょっと調べてみるわ

rubyの台頭を許したpython側の要因はZopeの失敗にあると思う。

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

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

web関係とかはrubyの方がライブラリが多い気がする。
あと関係ないけどrubyのライブラリ配布サイトなどのサイトはデザインが綺麗なのが多いね。
オールマイティなのはpythonだね。科学者向けのライブラリとかGUIとか。

>>115
Djangoを改造してRails風に使えるようにしたFWを自作すると幸せになれる

>>120
それは結構同意かも。

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

>>116
だめだった

PylonsとかPloneとか使ってみた人いる？

>>124
ちなみにどの辺がお眼鏡にかなわないの？

rubyのダイナミックローカルスコープは
違和感があるんだよな。

　　　 　 ,―ヽ＿＿＿＿、―
　　　,／　　ノ　　　　　　　ヽ　　~＼
　 ／　　 ノ　　　ＩＰＡ　　　　ヽ　　　~＼
／　　　ノ　　　　　　　　　　　ヽ、　　`ヽ
|　　　 ﾉ /￣＼　　　／￣~ヽ　ヽ 　　 i
|　　 ノ　　　　　　　　　　　　　　|　　ノ
＼　 |　　＜●＞　　＜●＞　 （　 ）
　＼ |　　　　　 ｜　|　　　　　　 i /
　 　 |　　　　　 /　　ヽ　 　 　 　ﾚ
　　　i　　　　　（●_●）　 　　　 /　　
　　　 i、　　　 ,-――-、　 　・ /
　　　　i、　　<（EEEEE）>　∵/　　　ＩＰＡ Rubyがあれば、PHPやPythonなんて必要ない
　　　 　 i、 　 ＼＿__／　　_/
　　　 　　 ＼　　　　　　 ,ノ　　　　　　　
　　,,.....イ.ヽヽ、ー-―一ノﾞ-､.
　　:　 　| 　';　＼_____ ノ.| ヽ　i
　　　 　 |　　＼/ﾞ（__)＼,| 　i　|
　　　 　 ＞　　 ヽ. ハ　 | 　 |｜

>>120
Zope知らんからそこはわからないが、PythonはRubyistから見ると堅すぎって感じがする。
文法もそうだけど、それ以上に気になるのはライブラリのAPIかな。

Pythonはその堅さを求めて使うものって感じじゃね
Rubyはササッと書くにはあのフリーさが丁度いいんだが
ゴリゴリ拡張されると別言語になっちまう

最初からかっちり書く奴には大差がないということ？

最初からかっちり書くならどっちもどっちじゃね

最初からカッチリ書くならpythonが楽に決まってんだろ

pythonはカッチリしか書けないけど、rubyはカッチリ書く事もフリーで書く事もできるって感じかな。

Railsが現れて頭のブレーキが外れた感があるなｗ

Rubyやめますか
それとも
Railsやめますか

言語仕様的に嫌いなのではじめません

ダメ！絶対！！

>>133
そんなことはない。俺カッチリ派だけどRubyの方が綺麗に書けると思う。楽さは
同じか、わずかにRubyのが楽。

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

問題はカッチリじゃないコードが混じる可能性を考慮した場合なんだよね
Rubyもみんなカッチリ書くなら大丈夫なんだが
Pythonほど、そこの強制力がない

>>139
なんで、そんなことが許せないの？

>>139
たぶん君は 'delim'.join(lst) も許せないんだろうね

>>140
rubyはフリーとカッチリのどちらでも書けるから、みんなが同意しないと混じる可能性があるけど、
pythonはカッチリしか書けないからこそ強制力があって、混じる可能性が無い

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

ちなみに、

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

>>143
pythonが書き方が一通りというのは幻想

>>145
うーみゅ、幻想なのか....。

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

Rubyにはpublic, private, protectedの呼び出し制限があるけど
Pythonは全部publicですから

>>146
普段から使っている身としては、いわれてるほど、かっちりしてるとか
堅いとは思わないな…

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

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

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

Ruby、そしてRailsの大量のDSLは可読性という点では最悪だろ。
ずっとRailsばっかり扱ってる人はそれでいいのかもしれない。
たまにRailsを使ってみると、どこで何をしてるのかサッパリ分からず、デバッグで途方に暮れる。

RailsはRubyじゃないからRubyを責めるのはかわいそう

pythonも一行にいくつもの式を詰め込んだり出来るよ
ただ改行するのがpython的ってだけ
キッチリ書かないのは文法違反になるというより思想の問題かな

>>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

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

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

>>153
ああ、そうなんだ。情報thx
名前ぐらい慣れればないだろうけど、それは洗脳されてるだけだよねって感じかな。

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

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

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

× 慣れればない
○ 慣れれば問題ない

>>154
ま、じゃ、reverse()はいいとしてもさ、

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

え、でもnoseってかなり勢力でかくない？w
Pythonの世界あんま知らないけど、少なくともunittest使っていいのは小学生まで
だと思ってた。

標準的ですらないってところ読んでなかった。そうだったのか。

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

そういや、selfって名前も強制じゃないな。
これもあくまでも、PEPとかで推奨されているだけで、clsとかしたかったらできるんだよなw
やっぱ文化的な問題なんだろうな。

なくすこともできるの？

なくすのは無理。
使わないように、書く、というのは可能だけど。

それは無理だろw

def hoge(_, a1, a2):
  _.a = a1
みたいに書ければ気にならなくなるかな

>>163
…いや、それはやりたければ、できるんだけどさ…

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

嫌だ

perlよりまし

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

nestが深いとpythonの方が見やすいかなー

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


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

どんな言語・ライブラリだって習熟していれば、それは使い易いだろう。
問題は習熟するまでに時間がかかる、習熟しても時間が空けばまた忘れてしまうって事。だから、Railsはダメ。

Djangoはいいってこと？

それはもっとダメ

じゃあ何がいいんだよ？

>>169
Perlのラクダ本だったかリャマ本だったか覚えてないけど、
「Perlは毎日Perlでプログラムを書く人に向いている言語です」
みたいな事が書いてあったと思う。

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

慣れたらインデントしないの！？

>>174
え？何の話？？w

慣れるとコーディングが汚くなるんでしょ

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

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

＞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の例に比べると、なんだか抽象度が低くて汚い

>>178
あーなるほど。でも、C知ってればシェルスクリプトも知っててすぐわかるような。
あとJavaの拡張for知ってればイチコロだよな。

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

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

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

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

inだとかしばらく使わないとすぐ忘れるような構文なんかいらんわ
ま、このスレの言語自体いらないんだけどね

shのインパクトは忘れられないよな
あれだけ変態だと逆に一発で覚えられる

>>139
ls.reverse()はls自体を並べ替えろっていう「命令形」。
reversed(ls)はls自体を並べ替えるんでなく、逆順に並べ替えたlsをくれって関数。完了形。

>>183
Rubyなら
・ls.reverse!()　　<-- reverse!()は命令
・new_ls = old_ls.reverse()　　<-- reverse()は関数
になるけど、こちらのほうが自然だろってことかな。それなら自分は納得だけど。

>>183
細かいことだが、reversedって完了形というより過去分詞／受動態じゃないの？

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

>>169-172
Djangoは良いよ

>>178
map(sys.stdout.write, map(str, range(10)))

>>185
受動態じゃなくて過去分詞の副詞的用法

ああすまん
過去分詞の形容詞的用法
か

>>187
10.times { println it }
に比べて冗長・複雑な上に無駄にリストを生成して返す

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

>>190
generator だから無駄なリストは作らない

ああPython3か
2.X系だとリストを返すけどな

Pythonはlambda式がアレなのが痛い
>>187なんて
map(lambda x: print x, range(10))
でいいのにそう書いてないのは、つまりlambdaを書きたくないんだろ

python3だったら
list(map(print, range(10))) とかにしないと表示しないね

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

っていうか、lambdaの中にprint書きたくても書けないんだったなそういえば

>>185
そうだね。「自然」よりも「分かりやすい」のほうが適切な表現だ。

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

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

自己レスで訂正。>>196中の reverse は間違い。reversed が正しい。

>>196
まあRubyもトップレベルでいいのかそれ？と思う関数あるけどな。
ただ、Perlの次を目指して作られたって経緯を考えれば
なるほどトップレベルだなという関数が多い

>>195
printは文だからね。
３では関数になるので、lambdaの中でも使える。

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

>>197
混乱してるな

>>198
確かに、書き捨て用途なんかも考慮した
ショートカットなんだろう。Kernel#openとかさ

>>198
rubyはsmalltalkを目標にオブジェクト指向を徹底した言語設計で、
作者も著書で「perlの皮を被ったsmalltalk」と語っている。
ブロック(クロージャ)の扱いが、その典型例。

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

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

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

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

>>203
Pythonは知らないから、Rubyの優位性とかは分からんし、そんな事は言っていない。
ただ、オブジェクト指向言語として徹底されているから、
一貫性のあるオブジェクト指向プログラミングが可能になるね、ということ。

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

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

>>203-204
Rubyが遅い理由にはなっているな

>>204
python の list.reverse は文字通りに動作してる訳だけど？

>>204
混乱してるのはお前の頭だ

>>205
その通り。Rubyは実行効率という代償を払って、純粋オブジェクト指向を得た言語。

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

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

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

>>208
だから、後から追加されたのはreversed()の方なんだってばw
つまり、Pythonがよりオブジェクト指向を徹底するのであれば、
例えばlist.reversed()と書けるようにするべきだった、ということかい？

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

>>209
>だから、後から追加されたのはreversed()の方なんだってばw

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

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

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

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

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

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

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

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

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

×特定の関数（具体的には__iter__()）を持つ関数でしかなく、
○特定の関数（具体的には__iter__()）を持つオブジェクトでしかなく、

>>211
同意だな。
reversed(),sorted()はオブジェクト指向というより、ジェネリック指向ってことだね。

>>213
うん、一言で言えばそうだよね
C++のSTLに似てる、あっちもiteratorベースのジェネリックアルゴリズムだし

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

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

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

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

>>216
pythonでいうと、EnumerableモジュールのMix-inを要求されないんだな。
eachメソッドさえあれば、sorted()やreversed()は使える、ってこと。

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

>>215
マジボケですた ........orz

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

>>218
Ruby と逆だから Ruby に慣れてる人は混乱するんだよな

>>208
> もしPythonがオブジェクト指向を導入した時にオブジェクト指向の徹底を判断していれば、
> トップレベルのreversedは削除されていたはず。

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

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

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

あほか

皮肉だよな

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

スレに張り付きすぎてて、言語の前に自分がキモくなってきたからそろそろROMるが。

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

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

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

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

最近Scalaが気になるからScalaも混ぜて話してみてくれ

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

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

Scala は知らん。

本筋と関係ないけど、発案者っていうより、まとめた人じゃないの？

抽象データ型やデータ抽象というのは、型によるモジュール化手法で、これは正真正銘
リスコフの発案だよ。その後、勝手定義がはびこったので、それらと混同しているのでは？

なるほど、勘違いしてました
そういう概念は以前からあったんではないのかな、と思ったのだけど
総称型的な機能を取り入れた最初の言語がCLUなのか

CLUはなぜ消えてしまったのか

>>223
>RubyのオブジェクトモデルがPythonのオブジェクトモデルより、スピードの面で不利なところはほぼない。

いくつかあるけど、具体例を２つ挙げる。
・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るのはお一人でどーぞ。それを押し付けられる(強要される)のは、ご免こうむる。

レキシカルスコープは理解できるんだが
静的スコープと書かれると、直感的に認識できない。

>>231
> 手続き指向に慣れ親しんだユーザの移行障壁を軽減させた。

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

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

このスレちょっと前は過疎ってる気がしてたけど
きゅうに盛り上がったな

自演で盛り上がったとは是如何に

>>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が持つ)日本人固有の僻み/妬みに起因した「足の引っ張り合い精神」によるものだと推測する。
もし反論があるのなら、マジ知識という上の文章のソースを提示してくれ。

>>236
えーと。まじキチ？

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

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

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

>>237
> Matz の場合、無知から来る再発明やミスリードを狙うことあっても、

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

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

うわぁ…

>>239
坂本龍馬が似たような評価されてるね

Matz儲って、ジョブズ儲に似てるね。イタすぎる。

そりゃ>>239のような自称言語オタク(笑)より評価に足る人物だろうね。今そういう話してるの？
名前もない底辺と比べて素晴らしいなんて議論の余地もないよ

やめようぜw

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

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

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

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

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

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

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

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

×読んでる
○呼んでる
それじゃ消えます。アデュー。

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

RubyとPythonは似てるようで色々と対極なのが面白いな。
関数中心かメソッド中心か、とか
関数とメソッド、そしてフィールドの関係とか
イテレータが内部か外部か、とか

>>248
内部イテレータ外部イテレータは、スタックトレース的にどっちが外かという話だから
もし並行処理でスタックが独立していたら、内部でも外部でもないイテレータになる

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

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

なんか話が飛躍してないか

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

CUIとパイプとワンライナーの需要だ、といったらまた見下してくるんだろうな

今からPerlを使う理由はない

今からPHPを使う理由はない

PHPは何だかんだで使われるんじゃね、言語としては嫌いだけれど
Webアプリのサーバサイドに特化した言語ってのもそうそう無いと思う。
そういう風にも使える汎用の言語ってのはあるけどさ。

おまえら元祖ワンライナーawkを忘れてないか？

awkはUnix系だと色々使えるが…

awkはLinuxとかでいうと、もうbusyboxにまで入っているからなw
個人的な感覚でいうと、LLというよりはもうsortやsedのような
ツールって感じw

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について読んでみようっと。

つか、Perl6ってどうなってるの？

「Web言語」ってなんだよ

Ａｃｔｉｖｅ　ＰｅｒｌへＧＯＧＯＧＯ！！！！

>>258
こういう勘違い馬鹿をもう再生産しないためにも
Perlは撲滅すべきなんだが

>>262
まああと10年は余裕で使われると思うよ、perlは。
死ぬ死ぬいってたコボルとか余裕で生き残ってるしな。

> Perlを覚えればかなりの面倒な作業を楽にできるということは個人的な
> 経験からいうとほぼ正しいことです。Perlは忍者のような言語なのです。
まあこれは真だけど、他のLLも同じだっていうね。

まあ、UNIX系OSのツールだと、Perlは最大勢力だからな。最近はたまにPythonもあるけど。

perlのアドバンテージったら古い鯖でも大抵入ってるって事くらいだと思う。
選べるんならpythonやらrubyのほうが、そらいいわな。

PerlはWeb言語なんかじゃ無いんだけどなあ
元々テキスト処理に特化した言語だったから、Web用言語が無かった時代に
テキスト処理を多く利用するWebプログラミングに使われたってだけで

>>267
昔、CGIといったら、「CGIってのはPerlで書かれているものだ！」とか言ったバカがいたなあ…w

ウェブアプリでも、PHPは別格としても、その次はPerlでしょう。特に日本じゃミクシイとかDeNAとか、最大手のサイトが採用していて、非常に勢力が強い。
Rubyはクックパッドくらいしか名前聞かないし、Pythonは皆無。

>>269
お前はGoogleも知らんのかw

>>267
だよな
Web言語(笑)って言ったらPHPとかjavascriptみたいなのを言うんだよな

>>269
君の頭が鎖国してるだけ
PHP>Ruby>Python>Perl

Python on Rails

どうでもいいが先頭がPなの多いな

>>274
そうだよ。
だから、「P言語」みたいな言い方もされるし、
最近じゃ、LAMPのPはPythonやPerlでもいいことになってるんだw

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

Rって見方によってはPに毛が生えたようなもんだからな

ﾄ

Rubyはオブジェクト指向に対応したスクリプト言語ではなく、
スクリプティングもできる本格オブジェクト指向言語だからP言語ではない。

と言ってみるテスト。

英語だとdynamic languageとかいうのかな
Perlって動的型付じゃないような気もするんだけど、どうなんすかエロい人

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

>>278 よく言われてることに反するけど、Rubyのオブジェクト指向って変わり種なんじゃないかな
中途半端にプロトタイプベースの機能も入ってて
オブジェクトにメソッドを追加出来るから、LSPも満たせない

ttp://en.wikipedia.org/wiki/Type_system
perlはstatic typingかつdynamic typingな言語

>>281
なるほどー
どうもです

>>270
日本のサイトで、だから。それにGoogleの場合、ほとんどはJava、バックエンドにC++で、Pythonはごく一部でしょう。
Python使ってる日本のサイトで有名な所があるなら教えて欲しい。

>>280
動的型付けだからLSPをいつも満たす必要はないと思うけど、まあ変わり種だろうね。

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

>>283
なんで日本のサイトに限定するのか意味が分からん。
そんなくだらない情報知りたがるからリストラされるんだよ！

plone使ってる自治体もある。君が知らないだけで世の中は広い。

サイトのコンテンツ自体にPythonはあまり使われてなさそうだけど(日本)、サイト
が乗ってるサーバーの管理プログラムにはそれこそクソ使われてるだろう。
Linuxだし。

youtubeはpythonじゃなかったっけ？

ちょっと時間が空いたのでGoを使ってみたけどいいねこれ。

yumはpython

kwsk
最近新しい言語やる気力が衰えてる

やる必要もないことをやろうとするからだろ

歳やね
http://www.youtube.com/watch?v=ona34GVZpHg

あ、アンカー書き忘れた>>288で

>>288
ttp://www.taranfx.com/what-powers-youtube

>>286
WordPressやMT使ってる自治体の方が遙かに多いから。

>>296
多い少ないなんて誰も言ってない
PHPがダントツ多いのは明らか

初めから多い少ないって程度の話をしてるから。PHPが一番多くて、次がPerlのウェブサイトって。

裾野は広い方が良い

Ploneは日本ユーザ会が色々とアレでナニなんで
一見死んだコンテンツのように見えるけど
結構底力あって意外と日本でも導入実績あったりする。

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

Plone と Pylons はどう違うんだ？

5文字と6文字

yが入ってeがsに変わってる

それを正規表現で書くとどうなりますか？

s/Plone/Pylons/

PHPは最近のはフレームワークもしっかりしてきてるし
言語機能も強化されつつあるしまあいいんだけど
一昔前のは本当にひどかったからなあ。
echo "<HTML>"とか出てきたら窓から放り投げたい。perlCGIはいわずもがな。

意味が分からん

>>307
わからん方がいい
関わらん方がいい

>>220
>なんでpythonな人はすぐにrubyとの優劣に話をもっていこうとするんだろうね。

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

禿しく銅でもいい

>>231
>いくつかあるけど、具体例を２つ挙げる。
>・Rubyにはメソッド呼び出しのたびにクラス継承ツリーに沿ってメソッドを動的に探索するオーバヘッドがある。
>　Pythonのように関数であれば、動的な探索は不要。

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

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

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

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

なんかこういう話題みてると、
プレステ持ってる子とセガサタ持ってる子のケンカを思い出すんだよな。
「サターンの方がCPUが2コ入ってるんだぞ！」みたいな。

というかRuby厨にさんざん喧嘩売られてPythonistaが過敏になってしまっただけでしょ

>>312
ゲハも宗教論争だからな。同じようなものだ

“時給11万2000円のアルバイト”に10万人超えの応募が殺到
http://headlines.yahoo.co.jp/hl?a=20100921-00000031-oric-movi

誤爆ｽﾏｿ

気にするな。
宗教関係の戦争中らしいから、誤爆なんて大した事無い。

ソースコードで発見した奇妙なコメント集
http://www.webcreatorbox.com/webinfo/comments-source-code/

暴れてた奴ははRubyの評判を落とそうと意図的にやってただろどう見ても

Ruby厨はガチ

mixinが無い時点でPHPはかなり分が悪い。

Python（2.3以降）みたいな多重継承があればいいんじゃない？
あるかどうかは知らないけど。

>>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だと組み込み型のメソッドを変更可能だからメソッド探索を真面目にしないといけないとかかな。

メソッド探索は速度に影響するかも知れんが、アクセサメソッドは大して影響ないだろ。
呼び出し自体のオーバーヘッドなんて無視できるレベル。
Pythonのメソッド呼び出しはいちいち属性から関数オブジェクトを引っ張ってくるから
速度に影響する！と言ってるレベルの負荷でしか無いと思われ。

ちょっと聞きたいんだが、この表現は正しいの？

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

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

PHPのマニュアルに書いてあるのか
なら、PHPの中ではそうなんでしょう
各言語ごとに独自の意味を持つ語って一杯あるよ

PHPでは無名じゃない普通の関数はクロージャじゃないの？

むしろ名前が付いてるか付いていないかはこの場合問題ではない

>> 323
> これは一般論としては正しくない。
いや正しいだろ、一般論としては。
"一般論としては正しいが、組み込み型の場合のみ当てはまらない" ということでしょ。

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

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

魅力的なPython: PsycoでPythonの実行速度をCと同等にする
http://www.ibm.com/developerworks/jp/linux/library/l-psyco/

これは？

>>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として推奨している。

>>331
> __len__ メソッドを実装したクラスに対して実行されるよりも
> 圧倒的にリストやタプルなどの組み込み型に対して使われる方が多い

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

>>332
コンテナ系のクラスを作ったとしても、アプリケーションでタプルやリストに比べてその
コンテナクラスを使う事の方が多くなるケースは稀じゃない？

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

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

> len()が関数であることがPythonで書かれたアプリケーションを遅くしている訳ではない、
> というのは同意してもらえる？

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

> phpやRubyがPythonより遅い

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

Rubyは遅い

>>334
おまえRubyなめんな
Rubyだけは桁違いに遅い

Ruby2.0でどうなるかだが、まだまだ先だしなー

>>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/

●●が２倍おいしくなりました(当社比)
みたいな

1.9.2使ってみたが、確かに早くなってるな。

>>334
言語自体の速度の違いは、Ruby 1.9 の登場でほとんどなくなったよ。

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

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

Pythonは来年には消えてるだろ

いやそれはあり得ないから。
少なくともLinux界では今Python抜くと酷い事になる鳥が結構あるぞ。

酷い事って、「やられたようだな」とか「四天王で最弱」とか言われるだけだろ

yumでうpでーとできなくなる

Linuxは来年には消えてるだろ

この前FreeBSDにPHPをインストールしようとしたら、インストールにPerlが必要なんだな。

>>344
ワラタｗｗｗｗｗｗｗｗｗ

依存関係が少ないLinuxって、やはりSlackwareになるのか。

FreeBSDはpython依存してなかったっけ？

何が？

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

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

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

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

Pythonistaはいいやつが多いけど、Python信者だけは別だな。(ｷﾘｯ

PHPの場合、組込みでテンプレートエンジン、セッション処理が備わってて、$_SERVERとか$_REQUESTが整備されてるもんな。
一つもクラスライブラリ使わずに、標準機能だけでMVC構造持ったウェブアプリが作れる。

>フレームワークつかえば、Symphonyよりも遅い。
Symfonyより遅いとかありえないだろw
phpで速く動くWebアプリを作るには、>>354の言うようにフレームワークを捨てるしかない。

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

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

少し古いが、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の方が倍速かったって。

webアプリの場合は言語の違いというより動作環境の違いが大きい。
pythonはmod_wsgiやfcgiなんかでメモリに全部読み込んで動作させるから速いに決まってる

皆仲良く全部のプログラミング言語覚えたら良いじゃん。
このスレも平和になるだろ

>>357
しかし、それはネイティブのPHPと同じ土俵にPythonが乗るってだけの話だぞ。

PHPはださい
VBと同じにおいがする

>>357
メソッド呼び出しにかかる時間みたいなマイクロベンチはアプリの速度に直結しないから
アプリの速度を議論したいけど、そもそもphpはWebアプリでしかほとんど使われてないから
Webアプリの話になってしまう。

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

定性的な話ばっかりだな

>>361
ふーん。
そうなんだ。

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

>>360
わかるよそのきもち

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

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

↑　試してるだけで成果物がクソな奴
















ふっ(笑）

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

webアプリでJavaとかC#の方が断然速いってｗｗｗ

>>367
サーバーコストより開発コストの方が断然高くつくんだよボウヤｗ

>>367
昔はそれが正解だったけど、今は共有レンタルサーバーだけじゃなくてGAEとかVPSとかあるから、
PHPじゃなくても非CGI動作が可能。

いや、VPSが共有レンタルサーバより安い事はないし。100円、200円レベルだとPHP以外は実質使い物にならないよ。海外なら無料っていうのもある。
まあ、HipHop for PHPみたいなのをPHPの周辺技術って事にしてしまえば、JavaやC#より速いわね。実績も十分だし。

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

言語のパフォーマンスの話と
安価なレンサバがどうたらとかいう趣味グラマ話と
開発コストがどうたらいうエンタープライズの話がごっちゃになっててわけわからん

Rubyをいじり始め、
phpの配列とハッシュの無差別さはよっかたなと思いつつ
はと、大した差ではないと思い至る。

>>371
Facebook以外本格的なサービスで使われているのを見たことが無いんだが、、、
Symfonyとか自分でHiphopで動かしてみたことある？苦行以外の何物でもないよ？
Facebookは、たぶんビューにしかphpを使ってないんじゃないかな。

FacebookはほとんどHipHopに移行してる。トラフィックベースで90%に達してる。
中小規模のサイトは普通のmod_php、大規模高アクセスサイトはHipHopって使い分ければ、他の言語の実行環境は付けいる隙ないな。

>>376
Hiphop使うくらいならPython使った方が楽に性能出せる。

>>371
> まあ、HipHop for PHPみたいなのをPHPの周辺技術って事にしてしまえば、
> JavaやC#より速いわね。実績も十分だし。

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

要はソースコードをPHPの文法で書いて、それをC++としてコンパイルして、そのバイナリをウェブアプリとして動かしてるってわけで。もはやPHPとは言えないかな。

いや、結局C++でphpの動的型の挙動を実装しているので、動的型のオーバーヘッドはしっかり残ってる。
Cythonで型指定した方が速い。

>>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#より速くなるなんて信じられなかった

>>380
ああやっぱりそうなのね
ありがとう

Facebook自身が倍速くなったとしか言ってないじゃん。
普通のWebアプリなら、phpからPythonにするだけで、Cythonとか使わなくても倍にはなるよ。

PHPカンファレンスで、Facebookの人が来てHipHopの解説してる。動画も見られるはず。
型は型推論してて、それなりに最適化されてるようだ。ただし、eval()とかはダメで、多少PHPのコーディングを制約されるようだ。

>>383
Webアプリのスループット全体で倍とかだと正直よくわかんないなあ
ある意味全体で倍は凄いと思うけど……

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

ちなみにPHPは5.4からIntとかをタイプヒンティング出来るようになる。
fuction f(Int $x, Int $y) { return $x + $y }

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

あ、ごめん、Cythonの話ね。
>>385
Psycoだと静的片付けにはならないから、100倍はムリだと思う。

>>384
eval もそうだけど、関数を動的に定義するのとか、autoloadとかもダメね。

>>388
書き方がわるかった
xs = range(1000)
result = 0
for i in xs: result += i
みたいに、intと推論可能なケースのつもりだった
すくなくとも数十倍は早くなったよ

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

Cythonは相互運用性としてはJVMや.NET言語に劣るんだよね
「C/C++のコードと」連携したいという前提があるなら、まあそれも仕方ないんだけど

>>390
インタプリタのコストを削減しているだけで、型に関しては普通にPythonのint型オブジェクトを
使ってると思うよ。
そうじゃないと桁あふれ時の動作が変わるし。

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

pythonやrubyを先にやったらPHPが簡単に感じたりする？

陳腐に感じるかもしれないね…

面白いライブラリ揃ってるけど、言語としてはガッカリするかも知れん

PHPバカにしてる奴は俺マイナー言語使っててカッコイイみたいな価値観の奴だから気にするな

>>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信者がどんなに頑張っても無理。

追加だけど、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がある今となってはどうも。

またコイツ、いや、まだコイツかよ。いい加減オナニーはやめろ
ブログで書け

どうせ大したこと言ってないんだから簡潔に言えよ
ウンコみたいな文章を読んでもらえると思うなよ

Djangoが早い方、っていうのは、何と比較して？
Pythonには軽いフレームワークも結構あるし、どちらかというと遅い方だと思うが。
mod_wsgiの話だったら、WSGIに対応しているフレームワーク全部早いし、
その中で、っていう話ならDjangoが早い方には絶対ならんと思うが。

信者って言葉使うやつのいうこと、まともに相手しないほうがいいよ。
薄っぺらい情報あつめて知ったかぶりするやつばっかりだからｗ

>>397
>もしDjangoがSymfonyと比べて数10パーセントしか速くないなら
Symfonyを *軽量化して* 、それでも *2倍* の差があったんだよ？

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

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

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

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

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

>>405
その知識のなさで、それだけのことを語れる君に日本の未来を感じたよ！
がんばれ！

PHPの人ってこういうのが多い

HTMLが出力されて実用に耐え得ればなんでもいい

フレームワークも別、アプリケーションサーバも別、こんなんでベンチマーク取る意味ないわ

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

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

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

>>409
つーか目的はWebページが表示されることなんだからそこだけ条件そろえればいいんじゃね
そして言語のみを取り上げてこの言語は遅いだのカスだの言わないことだな
この言語を使ってこういう実装した場合の優劣みたいな比較をすべき

Rails3 + ruby 1.9.2も比較してあげて…

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

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

日本語理解できないのか偏屈なのか

はいはいWebはPHPちゃんでいいよもう
それ以外は他の言語でやるからさ

Facebookが全面的に採用してるのにHipHopが不安定というのはあり得ない。

プログラミングの前に日本語を勉強すべき。

日本語が出来ないからプログラミングなんてやる羽目になったんだろ

俺も日本語よりプログラミング言語のが上手く書けるな
特に何かの手順を書き記そうとすると、自然とコードっぽい記述に…w

つーても、ウェブ以外じゃ、商業ベースでスクリプト言語の使い道はほとんどないから

テキストフィルタはAWKかPerlかRubyで書きたいな

>>418
hiphop-dev をウォッチしてる？
自分でhiphop動かしてみた？

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

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

PHPはクソだけど使えるから使うってのはPHPの作者を含めて共通認識だろ？
なんで今さらdisったり、それをかばったりするのん？

>>424
http://developers.facebook.com/blog/post/358
これを読む限りはマジでPHPっぽいぞ

クソだという事実を認めない人がいるから

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

Scalaのforループってすごく遅くないですか？
http://codepad.org/EQR8MH0B
何種類かの書き方を試して計測してみたのですが、
上から0.03s→0.22s→0.56s→0.83s
という具合にどんどん遅くなります

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

まぁJavaで書いてるんだからJavaより速くはならんだろそりゃ
カツカツ最高速でもJavaと同速度だ

フロントをPHPで、バックエンドをJavaやC++で書いてる部分はあるかもしれないが、そこにPythonが含まれてる予感はまったくしない。

>>432
FacebookはFriendFeedを買収したけど、FriendFeedが作ってたリアルタイムWebフレームワークの
TornadoをFacebookでも使ってるよ。
http://developers.facebook.com/blog/post/301

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

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

サーバーサイドで書ける言語をこれ以上増やしてもな
クライアントサイドで書ける言語の選択肢をもっと多くしてくれ

Java、JavaScript、C#（Silverlight）、Flash。これでも不足？

>>433
それはPythonで完結する場合だろ？PHPとPythonで有意な速度差があるとは思えない。それなら全部PHP、もしくは全部Pythonで書いた方がメンテしやすい。

>>429
この人はエキスパートパイソンという本を書いた人みたいだけど、ガチでパイソン信者だなあ。
ルビーも相当嫌いらしいｗｗ

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は勉強しないと読めない" とかもはやこじつけ。

>>438
言い方が過激だけど、内容は間違ってないだろ？
毎日その言語でプログラム書いている人にとってはRubyの方が書きやすいかもしれないけど、
普段その言語を使わないユーザーがたまに修正するにはPythonの方が理解が早い。
俺もC++のプロジェクトのビルドツールやテストツールなら、RubyよりもPythonを選ぶな。

興味はあるけどイマイチ始めようと思わない言語：関数型言語、ruby

「エキスパートＰｙｔｈｏｎプログラミング」の翻訳者のひとり？

これすごいなあ。信者がどんなふうに考えているか知ることができる。つうかもう怖いよ。

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
本人乙。もうバレバレなんだし、トリップつけたら？

このスレって文章力ない奴のオナニー長文とツイッターからのコピペで埋まっていくんだな死ね

アンチ的な主張も自分のブログとかツイッターで主張しろよｗ

>>438
2chのPython信者って痛いよなーと前から思ってたけど、その典型例みたいな奴だな

ポールはLispの宣伝ばかりしてるLisp信者だけど、それのどこが問題なのかな？
とりあえず自分の気に入らない2chのレスやコピペを逐一コピペすんな。目障りだから
誘導すれば興味あるやつは自分で読むだろ

訂正　2chのレスやツイッターのコピペを連投すんな

いや、このスレでやらかすぶんには全然かまわないと思うけどどうかね？

発言主がいないところで「Python信者はさー」ってなんの話だよ。レベル低すぎるわ

そもそも、「信者」などとレッテルを貼ることでしか、自分の主張を正当化できないのは、
痛すぎる。

スイッチ入っちゃったみたいだね

パイソン信者の人は自分の文体が独特なのに気づかないのかな？パイソン以外の言語には頭が回らないのかしら

本人乙。
>>446
>ポールはLispの宣伝ばかりしてるLisp信者だけど、それのどこが問題なのかな？
別に問題ないんじゃない？Python信者がPythonの宣伝しても何の問題もない。ここはそのためのスレだろ？
コピペくらい気にすることじゃない。

いやー、パイソンって本当にすばらしい言語ですね。
使ってる人もすばらしい人ばかりで、PHPやRubyとは大違いですね。
ぼくも今からパイソン勉強します。まずエキスパートPythonを読んでみます。

>>450
>そもそも、「信者」などとレッテルを貼ることでしか、自分の主張を正当化できないのは、
>痛すぎる。
笑うところ？どうみても信者のいってることのほうが痛いだろ。

>>455
自覚ないのかもしれないけどお前の方が

コピペ連投馬鹿が「コピペくらい気にすることじゃない」と取り繕うスレ

まあまあ
すぐ必死になるのが面白いんだからニヤニヤ弄ってればいいんだよ

>>442
こうやって晒されたのを見た感想としては、
「Rubyは楽しい」に通ずる何かを感じるな

ぐだぐだ言ってるヒマがあったら一行でもコードを書くべきだな
良い言語というのは言語自体の良し悪しでは無く、それで書かれたアプリによって決まるのだから

>>442
このひと Ruby と Rails がごっちゃになってるんだな

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

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

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

>>442
1つ目:
完全に個人の感想です。Rubyを煽っているように読めるのは、Rubyの人からの反応を見たかったからです。
PythonよりRubyの方がスラスラ読めたという感想とか、Rubyのコードをスラスラ読むためのカギなどあったら
教えてください。

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

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

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

>>463 は私です。コテハン記憶のチェックが外れてました。

本人ｷﾀ――(ﾟ∀ﾟ)――!!
このスレで匿名でやいやい言ってもあんまり意味がないし、
意味がないから無責任な発言を連発してるだけなので、あまり気にしなくてもいいのですが、
こんな風に槍玉にあげられたら一言言いたい気持ちも分かります。
個人的には正論だと思います。これからもがんばってください。

わざわざ、hoge(self, hogehoge)とselfを書く意味が分からんな。
内部動作的になんかあるとか、ちらっと見かけたが。

これほんとに本人なの？なりすましじゃない？

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

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

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

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

本人はPythonスレにたまに出没するから本人だと思うよ
それを狙った成りすましと言われればなにも言えないが

http://twitter.com/methane/status/27122796834
http://twitter.com/methane/status/27145580952

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

2chに書き込んで実名自慢ってかっこ悪いｗ

>>466
@classmethod とか
@staticmethod とかを使ったときに
ああ
あって良かったんだと認識出来た

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

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

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

せっかくだから記念に宣伝しとこう。
エキスパートなPython信者が書いた「エキスパートPythonプログラミング」絶賛発売中！
ttp://www.amazon.co.jp/exec/obidos/ASIN/4048686291/hatena-hamazou-22/
これを読めばあなたもPythonエキスパートになれる！

アンチ必死過ぎ…ｗ

>>473
LR違反です
通報しました

>>472
簡潔さ、というか、可読性といったほうがいいんじゃないかな。

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

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

ご本人（？）も認めているように、ツイートは「個人的な感覚」であって、
もともとが論理的な主張ではないのだから論理的な反論など無意味
（だからこそ、ここにまで転載するような内容ではないとも思うが……）
あるとしたら水掛け論だけ

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

>（だからこそ、ここにまで転載するような内容ではないとも思うが……）

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

>>429
これはどうみても信者だろ。ここまであからさまなのは中々ない。
これを信者じゃないというほうが信者だよ。
なぜそこまでPHPが嫌いなの？symfonyが遅い＝PHPが遅いと言っているけど、違うよね。symfony以外のフレームワークは試してみた？
もしPHPが本当に遅いなら、他のPHPフレームワークより遅いPythonフレームワークがあるのはなんで？

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

>>479
お前の知識が浅いのはよく分かった

>>479
おれ本人じゃないけど Python 好き PHP は嫌い
好き嫌いに理由なんてないぜ

俺はたいていの言語大丈夫だけどPythonだけダメだわ
括弧書きたい！！！

ツイッターでもブログでも、個人が自由に書けばいいじゃん。個人の主観で書けば。
それが他人の主観からみたら信者に見えたってだけでしょ。
個人の主観で書きたいように書くのがありなら、他人が主観で信者だと思うのもありだろう。
それとも信者と言われて何か困るの？

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

>>481
でもPHPとRubyが嫌いな理由はちゃんとあるんだろ。あれだけ書いてるんだし。

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

>>479>>483
何がしたいの？言語の話する気ないなら死ねよ

>>484
括弧ってブレースのことじゃないの

つかDRYを強調してるのは主にRailsじゃね？
上の方にも出てたけど、RubyとRailsごっちゃにしてね？
あとシンボルの意味がわかってなくて、なおかつ理解しようとしてない人のRubv批判なんかまったく信憑性なくね？

ちゃんと使ってから文句言えよ(ｷﾘｯ

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

>>486
>>482は大抵の言語大丈夫つってるから、多分ブレースでもないんじゃね
FORTRAN, COBOL, PASCAL, BASICとかは大丈夫なんだろうし

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

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

「Ruby 環境は憶えないといけないことが多いので嫌」ってだけのことで、
そんなもん「慣れた奴が気分よく使えればいいんじゃね」でおわる話だろ。
ギャアギャア噛み付くことじゃあない。

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

$ irb
irb(main):001:0> if "" then "t" else "f" end
(irb):1: warning: string literal in condition
=> "t"

> 空文字が偽になる言語
これってPythonのことじゃないの

>>490
じゃぁrequire_onceは遅くないってこと？

他言語はフレームワークを取り上げて批判してるのに、pythonは言語自体の良さを主張してフレームワークには触れてない
信者の意見なんて偏ってるもんだから仕方ないかもしれんが

>>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でプロファイリングしたら確認できると思います。

>>495
文盲のPHP信者は黙ってろよ。

>>493
Python の空文字は None だから false だ

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

Pythonはfilterの使い勝手の悪さがな…まあ、lambdaの仕様のせいなんだが
内包表記が読めるようになるまでは苦痛だった
内包表記に慣れるとmapも要らなくなるのは良いけどさ

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

>>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

とか書かないといけない

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

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

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

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

>>503
ダサいっていうか、この例だと単純に上の奴に比べて行数6倍になってるよね

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

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

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

＞・自由変数の参照にnonlocal文が必要
「更新」だね、ｽﾏｿ

>>504
LLというかスクリプト言語としては、確かに指摘されている点は面倒ですね。
その辺は、アプリケーションからスクリプトまで一つのLLで済ませたいかどうかだと思います。

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

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

>>506
そのコードは上の例と等価じゃないよ

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

>>463
>Rubyを煽っているように読めるのは、Rubyの人からの反応を見たかったからです。

わざとかーーー！

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

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

>>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よりは遅いものの、他言語勢は蹴散らしてますよね？

>>510
>カギはRubyを勉強することです。Symbolもわかってないのに「Rubyのコードが読めない」とかいいがかりすぐるｗｗｗｗｗ

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

カッコの省略が、脊髄反射的にRubyのコードに対し「読めない」感を持たせる原因じゃないかと俺は思う。
というか俺の場合そうだった。単純に、慣れるしかないと思うけど。

>>511
……だから注意したのに、全然よく読んでいないのね
Pythonの例もあるんだからまさか読めないわけでもあるまいに

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

わかりましたか？

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

>>515
遅延計算が（慣れていない人にとっては）むずかしいのは
別にPythonのせいではないと思うよ
Haskellが分かりにくいといわれるのも、結局その辺が理由なわけだから
（もちろんそれだけではないが）

もうどうでいいお

>>514
すみません、よく読まずに勘違いしてました。
確かに、nonlocalが無いとストレートに書けない、例ですね。

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

def f(n):
  while True:
    i = (yield n)
    n += i

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

>>516
遅延計算？

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

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

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

メソッド中→関数中

>>520
なるほど、「そこ」を難しいと思うのならそうかも
コルーチン的な動きをするわけだから

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

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

>>519 うまい！
yield式も可読性が悪いのであまり使われないけど、レアケースにおいては非常にコードを簡潔にできますね。
nonlocalと違って2.5以降で使えるのがうれしい。

>>523
シンボル知らないってことは、当然だがLispやSmalltalkも知らないんだろうね

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

> PythonよりJavaScriptでしょ

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

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

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

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

Rubyのシンボルなんてただのhashだろ

Lispを知ってたら、ああ、シンボルね、で終わりなんだよなぁ...

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

>>529
なるほど、僕の場合背景知識がC++やJavaだったのでPythonがとっつきやすかったのに対して、
SmalltalkやLispが背景知識の人にとってはRubyがとっつき易いという事でしょうか？

>>「シンボルも判らないで」と批判されるとやっぱりRubyは一見さんお断りな言語なんだなと感じます。
結局はこういう極論もちだすから信者って馬鹿にされるんだよｗ

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

rubyはきもいと感じ内でもない
儲が、と言う話しでもあるけど。

シンボルは別にそんなに難しい話じゃないよ
どの言語でも内部的には同じだと思うが、よく使う文字列をハッシュテーブルに
登録してやることで、文字列比較じゃなくてアドレスやIDみたいなもんで
比較できるようにするんだよ、そのほうがずっと高速で扱いやすいからな
これをinternという

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

>>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

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

>>533
はい、internはもちろん知ってますし、最適化のために使ったりもしています。
PHPも5.3からは関数名等が自動的にinternされるようになってずいぶん速くなりましたよね。

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

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

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

>>530
俺はJavaPHP流れだけど余裕でRuby選ぶよ

>>536
あぁ、やっぱり専用の構文になっているのは、internをコンパイル時に実行して高速化する以上の意味があるんだ。。

先ほどTwitterでもつぶやいたんですが、単純にPythonは公式チュートリアルがあって構文の使い方まで
説明しているのに対して、Rubyはあくまでもリファレンスであって構文の使い方、何が嬉しいのかが説明されて
いないんですよね。
RubyはWeb上に丁寧な公式チュートリアルってありますか？そっちを読めば他人の書いたRubyコードも
すらすら読めるようになるかもしれません。

Javaは正直あまりくわしくないんだが、確か1.5あたりでenumが追加されたんだよな
ああいうのは、本来シンボルがあればシンボル使えばいいような話だと思う

なんかな。本来比較対象でないものを必死に比較対象にしてる感がひしひしとするのよね。
Pythonのキーワード引数と、Rubyのシンボルって。
確かにRubyにはキーワード引数がなくて、シンボルをキーにしたハッシュを渡すことで代用するから、
似たような場面で出てくるという関連がないわけじゃないけどさ。

どこが違うと言われたら :foo のようなリテラルの記法があって、id になってるもの、としか
言いようがないけど。
ハッシュのキーにすると、文字列だと毎回ハッシュ値を計算するので性能が落ちるけど、
シンボルなら id だから速いとか。

> RubyはWeb上に丁寧な公式チュートリアルってありますか？そっちを読めば他人の書いたRubyコードも
> すらすら読めるようになるかもしれません。

ありません。
ていうかどれが公式でどれが非公式なのか線引きさえよくわかんないぐらい。

>>540
キーワード引数を例に挙げたのは、>>523 がシンボルに対してPython側の判りにくい構文の例として挙げたからで、
同じような機能だという主張はしていません。

結局 Ruby のチュートリアルが判りにくいっていう話で FA?

>>541
了解です。社内にはRuby書きが何人かいるので、お勧めの本を借りて斜め読みしてみます。
Pythonに比べて記号を多用するのは可読性の点でやはり好きではありませんが、入門書を読めば
Rubyもすらすら読めるようになるかもしれません。


あと、PHPについて >>507 とか >>397 とか、「言語には関係ない、ただのフレームワークの問題だ」
という意見の方は、>>511 に反論ありますか？

Rubyは本買えってことだよ。実際,Rubyの方が圧倒的に本が多い

糞本ばっかじゃねーか

なんで関係のないPerlが貶されないといかんのだ。
しかも、文法忘れたから読めないって、そりゃ、どんな言語でもそうだろうに。
プンスカ。

そんな私から見れば、Rubyの方が読みやすい。
こんなもん、知識量や偏りで左右もんだろうに、クソッタレ。

Pythonを叩くスレだからPerlは関係ありませんよね＾＾；

>なんで関係のないPerlが貶されないといかんのだ。

その原因を作ったのは Matz 本人だろ

るびまの固定コンテンツ「Ruby の歩き方」で紹介してるのは、るびまの過去の連載か。
ttp://jp.rubyist.net/magazine/?0002-FirstProgramming

これが一番公式っぽいチュートリアル、ってことになるのかなぁ。

>>547
何が「驚き最小限の原則」だよって話だな
Rubyで書かれたコードの美しさにいつも驚かされてるぞ

いろいろな言語使ってきたやつはPython派が多い気がする

>>551
当然皮肉だよな

Rubyはプログラムが好きというより、物作りが好きなやつが多い気がする

555

驚き最小の原則なんて、Rubyではだいぶ昔に放棄されてるぞ。

>>554
漏れはもの作り好きだけどPython派

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: と同じだから良いんだけど、
構文じゃなくてただのメソッドのクセに影響範囲が予想外に広いのがちょっと気持ち悪い。

驚き最小の原則とか聞いたことあるけど、メソッドが見た目上構文に影響を与えるのは予想内なのかな。
それとも「メソッドが」みたいな論理的な予想じゃなくて、見た目と動作の間の驚きを最小にしてるのかな？

考え方としてはPerlのTMTOWTDIが好きだな
プログラミング言語としては置いといて

Rubyがおかしいんじゃなくてオブジェクト指向がおかしい
メソッドがオブジェクトなら、メソッドがcallメソッドをもつのか? おかしいだろ

> Rubyだと関数を普通の変数として扱えないから、

だからそういう風にいちいちPythonに翻訳して考えていては、どんな概念でもまわりくどく
めんどくさくなると思うんですが。

> 驚き最小の原則

このへんで「驚き」を検索してみてくれ。
ttp://slashdot.jp/developers/03/03/14/0258247.shtml?topic=86

今時ゴルフとか

>>558
> Rubyだと関数を普通の変数として扱えないから、
これだと、Python は関数を値の入れものに使えると書かれてるように思える。

「少し気持ち悪い」は言い過ぎた。よく考えたらすごく特定要素のメソッドだし、別に問題ないや。

>>563
「関数は変数に代入されたオブジェクトじゃないから」といっても正確じゃないよなぁ。
実際、なんで Ruby は foo = bar で foo という変数に bar という関数を代入しなかったのか今でも不思議だ。
変数の仕組み自体（値ではなくてオブジェクトへの参照を格納するとか）はPythonに似てるのに。

まぁパイソン信者の人はハナっから穿った見かたしてんだから、まともな比較なんかできてるわけないよな

仕方ないから、俺様がするどいパイソン批判をしてやる












パイソンはパイソンという名前がダサいから嫌い
だから使わない
パイパイとか人前で発せれないレベル

Javaでクラスがオブジェクトじゃないみたいに、
メソッドはオブジェクトじゃない、という決定をしたから、なんだけど。
なんでそうしたかは知らない。Lisp-1じゃなくてLisp-2だね、みたいなことをどっかで
話してた記憶はある。

>>518
遅レスだけど
「nonlocalが現実世界で遭遇するのは本当に稀」ってことはないんじゃないかなー

ま、まがりなりにもOO言語であるPythonなんだし、nonlocalとか言わなくとも
classで書けば勿論かけるよ？
こういう単純な例でclassをいちいち書いてたら、classとか__init__とかselfとか
タイプする分、格段に長くなるだけで
でも、classを持ってるOO言語の多くがクロージャをも導入していること、
Python自身もクロージャを持ってるということを過小評価してはいけないと思うんだ

少なくともPythonでは束縛された自由変数への更新を行うような
クロージャを書きにくいってのは、ただの事実なんだから、素直に認めればいいのに

>>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ではより
普通のクロージャがある言語に近づくと思います。

>>568
要はPythonで書きにくいやりかたはPythonに慣れたユーザは最初から避ける、という
当たり前の結論だよね
俺もそうなんだろうと思うYO

自由変数を更新するクロージャってのはつまりイミュータブルなオブジェクトで、
Schemeあたりでそのように振舞う「もの」を書く場合は
そういう書き方になるんだけどね

だから、そんなものは現実にはないんだよ！みたいに言われると
えーっって感じなんだけど
Lispをご存知じゃないようなんで、仕方ないのかな

>>569
Lispっぽく書けないから避けてた面もあるでしょうが、そもそもLispっぽいのがPythonicじゃないから
避けてた面の方が大きいと思いますよ？
nonlocalができたからっていきなりlamdaが高機能になったりはしないだろうし、これからも
一時的なクロージャを高階関数に渡す書き方よりもイテレータを受け取ってループする書き方の方が
Pythonicであり続けるし。

nonlocalはpython3.0で導入されたけど、とりあえずPython3.2a3の標準ライブラリをgrepした限りは
symbol.py keyword.py pydoc_data/topics.py とテストからしかヒットせず、ライブラリ内では全く
利用されて無いようです。

>>558
Module#method_addedを使えばprivateみたいのはRubyレベルで実装できるし、
そんなにキモくない。

メソッドがデフォルトでオブジェクトにならないのは括弧の省略やself省略等、
構文上メソッドを特別扱いするためだと思われ。メソッドがファーストクラスオブジェクト
でないのは欠点かもしれないけど、括弧等の省略による表現力の高さを考えると十分許容できる。

>>561も言ってるけども、RubyにはRubyの考え方があるんだから、一度それを受け入れてから
キモいのかそうでないのか考えるべき。自分でPythonicとか言っちゃうぐらいなんだから、
Ruby Wayがあることも理解できるでしょ。

クロージャはOOじゃないからなあ
しかしOOを擁護しながらRubyを論破するのは無理だ
要領悪すぎる

>>571
>括弧等の省略による表現力の高さを考えると十分許容できる。

いや、これは明確に失敗だったと思うけどな。

>>572
何をもってOOというのかを考えるとキリがないけど、クロージャがOOでないと言うのは
言いすぎだと思うね。コードブロックを固めて持ち運べるようにするのがクロージャだからな。
そもそもRubyのクロージャはSmallTalk由来らしいし。

>>573
じゃあ君はrequireにもattr_accessorにもraiseにもpにもそしてprivateにも
括弧をつけたいのかい？
それらを予約語にすべきだというのなら、それはRubyの言語としての表現力を大きく
失なることになる。

>>571
>メソッドがファーストクラスオブジェクトでないのは欠点かもしれないけど、

いや、Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。
つまりオブジェクトとメソッドは明確に区別されているわけで、
それを引き継いだRubyがメソッドをオブジェクト扱いしないのは自然なのよ。

メソッドを関数として扱うのは、LISP系のオブジェクト指向拡張の流れを組むもの。
LISPはラムダ計算が基本だから、関数が(他のデータ)と同様にファーストクラスであるのは当然。
そして、そういった関数型言語の影響を強く受けたPythonが関数をファーストクラスとして扱えるのも自然なこと。

その片方(Python)しか知らないmethane君が、他方(Ruby)を見て、自分の知ってるのと違うから変だ！間違ってる！と
Twitterで喚き散らすのも、恥ずかしいけど中学生にありがちなことではないかと。

そんなこと言ったらどの言語も過去の流れを汲んでて素晴らしいってことになるじゃんｗ

問題にしてるのは違いがあるという事実だけだろ
そこから先、どちらが良いかは宗教戦争だから
全部知ってるから全部良いと言おうが、一つ知ってる素晴らしいものと違うから良くないと言うのは同じことだよ

>>574
Smalltalk由来ではなく、CLU由来らしいよ。

>>575
> Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。

どうしてるび厨はよく知りもしないでそういう嘘をつくかなぁ。
はっきりいって、Smalltalk流儀のOOPLでメソッドがオブジェクトじゃないのはRubyぐらいだろ。

| methodObj |
methodObj := Integer compiledMethodAt: #factorial.
methodObj valueWithReceiver: 10 arguments: #() "=> 3628800 "

>>579
るび厨というよりむしろ知ったかぶりな感じがする

>>575
ああそうだったのか。むしろ自然なのか。
ってかTって小文字なんだorz

>>577
宗教だからどちらが良いかなんて関係ないって考えるのは思考停止だと俺は思う。
まあ、ほとんど宗教だけどな。

さいきんついったでやってなかったか
MatzはSmalltalkほとんど知らんらしいぞ

メソッドがfirst-classでオブジェクトじゃないのは
当時のmatzの趣味だか不勉強だかのせいかと。
が、今となっては明らかに言語内DSLの作りやすさというメリットの方が大きい。

>>583
え、それはないでしょ。Smalltalkの話は置いておくとして、
もしメソッドがfirst-classオブジェクトだったら、今の形のrequireや
attr_accessorが実現できないじゃん。RubyがLispっぽいのはこういうところだし。

ブロックは今みたいな使い方がされるとは思ってなかったって、
どこかに書いてあったけど。

RubyがLispっぽいとしたらそれだけでマイナス。ソースはLisp

>>585
えーw
オマイにとってマイナスなだけで、多くのRubyistはRubyがLispのような
柔軟な言語であって欲しいと思ってるはずだ。

Lispがああなっちゃったのは、かっこのせいだ。かっこが少なくて、Lispに匹敵する
柔軟性を持つRubyこそ最強の言語。

と言ってみるテスト

>>579
これはメソッドをオブジェクトに変換しているように見える
オブジェクトではないものをオブジェクトに変換しているのでは？

不勉強なのでLispはifすら関数とかそういうレベルの知識しかありませんが、、、

>LISPはラムダ計算が基本だから、関数が(他のデータ)と同様にファーストクラスであるのは当然。
>そして、そういった関数型言語の影響を強く受けたPythonが関数をファーストクラスとして扱えるのも自然なこと。

Pythonが関数をファーストクラスとしているのは、単に変数と名前空間を統一した方がシンプルだからであって、
Lispに習っているわけではないと思いますよ。
Paul Graham がPythonはLispだと言って明確に否定されていたし、Lispは参考にしている言語の一つではあるけど、
「Lisp系言語だからこういう仕様なんだ」ってのは違うと思います。

JavaScript だって、Lispを真似てではなく、関数の名前空間を汚したくないからという理由で function foo() よりも
var foo = function() という書き方が好まれる場合が多いですよね。

> Lispはifすら関数
いやLispはごく普通の正格言語だからifを関数にはできないよ

仮にifが関数だったとしたら
(if expr then else)
って書いたら、expr, then, elseがまず評価されるってことね

Pythonの方がRubyよりLisp(Scheme)っぽさを感じる
RubyなんてSmalltalkとPerlのあいのこだろ
たまたまPerlがLispに影響を受けてるだけで

>>590
釣られないクマー

>>589
恥ずかしながら、 (xxx aaa bbb ccc) の形はすべて xxx という関数に aaa bbb ccc という値を渡す、
(if (X) (Y) (Z)) だと if は S式3つを受け取って、 (X) を評価した後に (Y) と (Z) のどちらかを評価すると
勘違いしてました。関数と式って別物なんですね。もう黙ります。

>>587
> オブジェクトではないものをオブジェクトに変換しているのでは？

ほんとるび厨は自分の無知を棚に上げて言いがかりだけはいっちょ前だね。
#compiledMethodAt: の定義みて、どこで変換しているか言ってみろよ。

Behavior >> compiledMethodAt: selector
　　^ self methodDict at: selector

>>586
テストって事は容赦なく叩いていいのか？
パーザーもろくにいじれない程度の柔軟性でよくLispに匹敵するとか臆面もなく言えるなと。

>>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に由来する括弧省略は「一見すると属性に見える、メソッド呼び出し」
という形で上手くマッチしたんだと思うよ。

ttp://togetter.com/li/54495
matzlispなんてのはジョークだと本人も認めてるしな

>>592
> 関数と式って別物なんですね。
気になってしまったので……、
関数と式は比較対象ですか？
Lispでは全てが式です。Pythonのように式と文に分かれていません。
ただ、関数呼び出しと同様に表記できる、特殊フォームがあるだけです。

>>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 "受信者オブジェクトヘメソッドオブジェクトを送信"

すまんが、正しい事を言ってるつもりなら、適切な例(コード)に書き直してから反論してくれ。

>>588
>Lispに習っているわけではないと思いますよ。

確かに、Lispという言葉の引用は不適切でした。関数型言語という言葉に置き換えてください。

>>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)と似ているか？とか
どちらが強い影響を受けたのか？という話に、大きな意味は無かったりする。議論は自由だろうけどね。

>>598
最低限、無名関数（Stではブロック。RbではProc）とメソッドの区別くらいはつけてから反論しようよ。
君、自分で気づいていないみたいだけど、言っていることめちゃくちゃだよ。
嘘だと思うならMatzに聞いてごらん。どこが違うかおしえてくれるはず。

>>601
結局、自分の口では説明できないし、Smalltalkでは書けてRubyでは書けないコードは示せないのね。
了解した。(説明が面倒なら、コード書いてくれるだけでいいのに....。)

>>601
判ってるなら自分で説明しろよケチ

Rubyで書くとこうだよ。バカる厨どもが。

meth_obj = Integer.instance_method(:fact)
meth_obj.bind(10).call #=> 3628800

で、もう一匹のアホがこれに絡めて言いがかりをつけた587、それの反証の593に繋がるんだよ。
偉ぶる前に、自分のレベルが２段階ほど至っていないことにいい加減気づけよ。

Rubyはなんで meth_obj.call(10) って素直に書けないの？

Matzに技量がないから。

ファーストクラスオブジェクトとしてのメソッド
http://yugui.jp/articles/741

>>605
メソッドにはレシーバが必要。
メソッド内でのselfはどうすんの？

>>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. アンカの付け方くらい学びなさいな。

痛い

自己レスで訂正。>>609内のアンカ>>575は間違い。正しくは>>579。スマン。

>>597
>>589 を受けてのレスです。(foo (x y)) の form で、もし遅延評価ならifも含めてすべて関数という扱いにすることが
できるけど、実際には関数は正格評価だから、foo が示すのは関数かもしれないし式かもしれないんだな、という
意味で「別物なんだな」と言いました。

>>607
Yuguiさんの考察、非常に参考になりました。

> でも、名前空間を一緒くたにすると「selfを省略可能」「引数の括弧を省略可能」というのは難しくなってしまう。
> Rubyとしては、高階関数を綺麗に書けることよりもこれらのほうが重要だろうと判断しての選択だ、
> とまつもとさんは言っていた。

確かに、Ruby方式には引数省略だけじゃなくて第一引数selfも自然に省略できるというメリットもありましたね。
Pythonだと第一引数を省略しようとすると、省略するかどうかを選ぶ構文の追加が必要になるので「タイプ数かわんねーし
構文規則が複雑になるだけ」と第一引数selfが残り続け、他言語ユーザーに「面倒そう」と思われる原因になってます。

今更だけど気になったので

>>588
>JavaScript だって、Lispを真似てではなく、関数の名前空間を汚したくないからという理由で function foo() よりも
>var foo = function() という書き方が好まれる場合が多いですよね。
JavaScriptには関数の名前空間と変数の名前空間に区別は無い。
function foo() {} と var foo = function() {} はどちらもfooという変数に関数が代入される。
違うのは代入が行われるタイミング（スコープに入った時・文の実行時）

あとJavaScriptの設計者はScheme大好きで、ブラウザ上にSchemeを実装するつもりで作った言語らしいから、
Lispを真似てこういう仕様になった可能性は十分あり得る

真似たというならLispというよりSchemeだな。
Scheme以外のLispはLisp 2が多い。

>>609
メソッドがオブジェクトな Smalltalk には出来て、そうでない Ruby には出来ない事の例でもいいんだよね？

Integer.instance_method(:even?).eql? Integer.instance_method(:even?) #=> false

(Integer compiledMethodAt: #even) == (Integer compiledMethodAt: #even) "=> true "

念のため、Smalltalk の #== は Ruby の #== ではなくて、#eql? と等価なメソッドです。

>>608
メソッドを関数と見なした場合、第一引数を self と見なすのが通常だから問題ないかと。

>>612
揚げ足取りだと自分でも分かってるけど……、
> foo が示すのは関数かもしれないし式かもしれないんだな、
lispでは関数は結局ラムダ式
普通の関数とifが別物なのはそうだよ。

言語によって、同じ言葉でも意味が異なるので、「Pythonでいう何々」とか言ったほうがいいよ。

>>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

なかなかいい感じにスレタイ的展開が続いているな

>>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もなんちゃっての欠陥品ですよね)

アンカーを間違えていました。>>620の最初の行にある>>609は誤りで、>>615が正しいレス先です。

(CompiledMethod superclass) == ByteArray

ByteArrayの方が抽象度が高いというのがおもしろいね

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

>>> def hello(): return "Hello"
...
>>> print hello()
Hello
>>> hello = lambda: "Goodbye"
>>> print hello()
Goodbye

>>594
うんやっぱりS式は最強だよね。嫌いだけど。

>>620
> 完璧に統合された実行環境を含まないOOPLは、
> すべからく「なんちゃってOOPLで欠陥言語」ということなのでしょうか？

なんでそう攻撃的になるの？　わけわからん。
いちおうマジレスしておくと、Smalltalk の GUI や IDEツール群、ライブラリ等は、じつのところ飾りだし、
その一部、あるいは全部が Ruby に揃っていないから欠陥品だとか言いがかりを付ける奴は
はっきり言って Smalltalk のド素人だからそんなのは無視していいよ。

多くの動的 OOPL では、メソッドはたいていオブジェクトで静的に関数としてもコールできる。
Smalltalk も同じ。ところが Ruby はメソッドいちいちオブジェクト化しないといけないし、
オブジェクト化してきてもその都度レシーバーを bind しないとそのままでは静的なコールもできない。

この事実を踏まえた上で、

>>575
> いや、Smalltalk流のオブジェクト指向では、メソッドはオブジェクトではない。
> つまりオブジェクトとメソッドは明確に区別されているわけで、
> それを引き継いだRubyがメソッドをオブジェクト扱いしないのは自然なのよ。

って、Rubyが現状のような仕様であることを「自然」と思うかどうかは本人の勝手かもしれないけど、
そうなった事情を説明するのに Smalltalk を巻き込むのはどうかやめて欲しい。

Objective-C の nil のクソ仕様も、ともすると Smalltalk のせいにされがちでホント参っている。

巻き込まれたくないなら「オブジェクト指向」なんてグループから抜けてしまえばいい
ただの手続き型なら、こんな下らないトラブルに巻き込まれずにすむ

じゃあ俺Objective-Ruby作るわ

>>620
>これは、Rubyがメソッド instance_method が呼ばれるたびに UnboundObject を新規生成しているのに対して、
>Smalltalkでは(毎回新規生成するのではなく)セレクタをキーとする辞書の要素への参照を返しているという、仕様の差異ですよね。
>だとすれば、「できる、できない」の話とはズレている気がしますよ。

これは、Smalltalkのメソッドエンティティがオブジェクトである一方で、Rubyのメソッドはそうではないという
証拠じゃないの？　どっちの話がズレているのだか。

>>623
さしもの Python にもこれは出来まい。ｗ

| 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 "

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

>>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 "

>>633
うん、それは出来ないね
func_code自体は書き換えられるけど、属性がreadonlyなので
ここでは別のcodeオブジェクトを生成して突っ込んでるだけ

> (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

>>622
> ByteArrayの方が抽象度が高いというのがおもしろいね

そう？　コンパイル済みメソッドはバイトコード列だからバイト配列でっていう継承関係は
ごく当たり前のことのような気がしていたのだけれども。他の言語の感覚では違うのかな。

>>636
カプセル化が当たり前の言語では、バイトコードは公開しない。
バイトコードを外から操作できたら、非公開メンバーも操作できるから。

「カプセル化が当たり前の言語」って例えば？

>>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

>>638
Rubyじゃね
あれカプセル化が強制されてるし

>>639
Lisp 系はソースコードがオブジェクトだった。
OOPL はバイトコードをオブジェクトにした。

でも結局 literalAt: や literals[] は
クロージャが自由変数を管理するのと同じテクニックだから
世界はやっぱり狭いと思う。

>>640
Rubyがカプセル化を強制してるってならSmalltalkも同じな希ガス
バイトコード列をいじれる言語はカプセル化が当然じゃないって
主張なんだから矛盾するじゃん。Javaとかのことを言っているのかな。

きっとものすごーく狭いOOPL界で満足できてる人なんだよ。

>>641
>でも結局 literalAt: や literals[] は
>クロージャが自由変数を管理するのと同じテクニックだから

まったく意味不明なんだが、何とか解読してみると、
SmalltalkのliteralAt:put:はLisp由来でOOPL的ではないし異端だ、とかいう話？

>>644
クロージャで同じことができるって意味だよ

my $bar = sub { $_[0] * $_[1] };
sub foo { $bar->(3, 4) }
$bar = sub { $_[0] + $_[1] };
print foo();

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

Perlはもうだめだな
はやくきえてほしい

iPhoneはがんばってるな

boostなんて出てきたし、Perlはいらない子だな

それ、あんまり意味ある指標だとは思わない。
PHP 76件
Perl 27件
Ruby 19件
Python 4件

http://www.pasonatech.co.jp/index.jsp
キーワードで検索

perl6は大幅変更なんだべ。

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

Rubyのsuperは引数なしだと現在の引数をそのまま渡すけど、これはsuperを呼び出す時は
多くの場合同じ引数をそのまま渡すケースが多いからそういう仕様になっているわけで、
理由がわかればすごく合理的な仕様ですよ。
「super」とあるだけで「同じ引数を渡している」ことが一発でわかるし、実際便利だし。
これはルールを増やすに値するだけの機能だし、そのルールだって別に難しくない。
それより「super(クラス名, self).メソッド名(引数1, 引数2, 引数3)」のほうがよっぽど・・・

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)」だろ。

>>439
>言い方が過激だけど、内容は間違ってないだろ？

間違ってるよ。最低限の勉強をしなけりゃ、Pythonでもコードを読むのは難しい。
この人がPythonをすぐ理解できたと言っているのは、Pythonでもほんと基礎的な部分だけでしょ。
ジェネレータや高階関数をPython学習しはじめの人がすぐに理解できるわけないよ。
Rubyのシンボルが理解できないというのは、単にシンボルという機能を持つ他の言語（Lispとか）を勉強したことがないだけ。
つまりバックグラウンドとなる知識がなかっただけだよね。それで他の言語を批判するのは間違い（というか勘違い？）。
新しい言語を学ぶときに、それを簡単に学べるかどうかは、持っているバックグラウンドの知識で大きく変わる。
なのに「Rubyは勉強しないと読めない」とか「Pythonはプログラマの共通言語として素晴らしい」と言っちゃてるんだから、批判されておかしくない。

ほかのPython使いの人はこの人に何も注意しないの？それとも本気でこの人のいうことが正しいと思ってるんだ、Pythonな人は。

>>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)　# インスタンスメソッドのはずなのに？

続き。
引数なしで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を要素とするタプル

ちょうど最近Pythonを勉強したから言うけど、Pythonだって勉強しないと簡単なプログラムすら読めない。
上で書いたのは、勉強した時に引っかかったところ。勉強なしでこれを理解するのは無理。
あとジェネレータとデコレータとメタクラスは勉強したけど理解できない。そのくせメジャーな機能っぽいから
これを理解できてないとオープンソースのコードが読めない。
Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった（未だにユニコードのエラーが解消できない）。
Pythonは勉強しなくても（あるいはちょっと勉強するだけで）すらすら読めるようになるというのは、ウソ。
ダイエットや英語教材のうさんくさい広告並みにウソ。

Pythonは何かとめんどくさい。道具としてはRubyの方が優秀

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文で使えるオブジェクトを作りたかったらイテレータを理解しないといけない(初心者にはムリ)。
繰り返しになるけど、僕は読むときの話をしていて、書くときの話をしていない。
さらに言えば、初心者はイテレータプロトコルを実装したオブジェクトを作らなくても、たいていの場合はリストを返せば事足りる。

>listやstrは関数かと思ったら実はtypeだったり。
list や str に限らず、全ての型は関数オブジェクトであって、呼び出したらその型のオブジェクトが返るようになっている。
全く特別ルールではない。

>listがあるのになぜかtupleがあるとか。しかも書き方がわかりにくいし。
>data = (1)　　# これは数字の1
>data = (1, )　# これは1を要素とするタプル

要素が1つ、あるいは0個の場合は確かに特殊だね。
でも、これも書くときの問題であって、読むときに引っかかる部分ではない。
書くときに引っかかる部分は、丁寧にチュートリアルで解説されている。

>あとジェネレータとデコレータとメタクラスは勉強したけど理解できない。そのくせメジャーな機能っぽいから
>これを理解できてないとオープンソースのコードが読めない。
メタクラスは知らなくても大抵困らない。
ジェネレータとデコレータって、こんなに丁寧にチュートリアル書いてあるのに理解できない？
デコレータなんて
@foo
def bar():
が
def bar():
bar = foo(bar)
ってなるだけだし。

>（未だにユニコードのエラーが解消できない）。
これは、なんとなく偶然に動くよりも明示的にエラーにしようっていう方針。
「動いてるけどどこかで文字化けしている」ってなる前に、例外だして問題の
あるところを指摘してくれてるんだよ？むしろ優しいじゃないか。

誰かが貼ってた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がその言語だ。
とか書かれている。

>>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()

>>658
例題に対しておまえの書いたsuper、1個引数たりねーじゃねーかwww
「省略できる」というルールさえおぼえれば、おまえが犯したようなミスをせずにすむってことだよwwwww

ほかの反論も、シンボルが理解出来ないレベルにしてはずいぶん小難しい話してるなwwww
pythonの時だけ都合よく頭が働くのかwwwwﾌﾟｹﾞﾗ

>>662
揚げ足取りしか反論出来ないのはは恥ずかしいよｗ

「Pythonならこうするんだ」って推測できる(ｷﾘｯ
全く特別ルールではない(ｷﾘｯ
こんなに丁寧にチュートリアル書いてあるのに理解できない？(ﾄﾞﾔｯ

どんだけ上から目線wwwww
液パイ如きがちょーしこいてんじゃねーwwww

言い方はひどいが指摘としてはもっともだね。

>>663
揚げ足取りっつーか、Pythonの文法じゃめんどくさい上にそういうミスを犯す可能性があることを信者自身が示してくれたんだろ？www ご苦労様ですwwww

>>662
悪い、普段は new style class かどうか確認するのが面倒で 親クラス名.__init__(self, arg1, arg2) って書いてるから、
super() の使い方覚えてなかった。

でも、使い方覚えてなくてミスってもエラーになるからわかるでしょ。
僕が問題にしているのは最初から読むときの推測のしやすさ。

>>667
大丈夫だ、問題ない


ﾆﾔﾆﾔ

>>661
メタクラスとかsendとか、殆ど出てこない機能はさすがに推測だけじゃ無理だよ。

チュートリアルを1度流し読みするだけで、普通のプログラム内で頻繁に出てくる程度の文法の
殆どは推測できるようになり、ライブラリのリファレンス以外は殆ど見ないで済むという主張しかしてない。

ていうかさ

「誰が書いても同じように書ける」的なことを掲げてるPythonが比較的読みやすいのなんておまえに言われなくてもみんなわかってるわwwww

楽しく書けるRubyや、歯ブラシのPHPは、読みやすさを売りにしてるわけじゃないんだから、Pythonの得意な土俵だけで比較しても不利だし、そんな偏った比較は意味ないだろwwww

それをﾄﾞﾔ顏で「読む時の推測のしやすさしか問題にしてない」ってｱﾎかwwwww

チュートリアル、チュートリアルって連呼してるが、普通の入門者は読むためよりも自分でプログラムを書くためにチュートリアルで勉強するもんだろwwwwwおまえの言ってること破綻しすぎwwww()笑www

>>658-659
デコレータは読んでも全然理解出来んかったな。
Pythonの中でもかなり感覚に反する機能だと思う。

あと
> 繰り返しになるけど、僕は読むときの話をしていて、書くときの話をしていない。

スクリプト言語は「書く」ことが重要な分野だと思うが。
そこらの大規模言語は読むことが最重要だろうけど
各自が「書く」ことこそスクリプト言語が生きるところだと思う。

まあ、それでも同じスクリプト言語って分類でも
Pythonは読みやすい、Rubyは書きやすいってのは思うけどね。

Lispから来たんだけど俺はPythonの方がいいな
Rubyはストレスがたまる
Perlの方がよっぽどマシ

Pythonは一度書いたコードを書き直していくと、だんだん綺麗になっていくのが好きだ。癒される。

>>671
デコレータは高階関数に慣れてないと難しい概念になるんじゃないかな？
高階関数を普通に作る/使うようになれば、単に糖衣構文だし。

引数を取るデコレータを作る場合、関数を返す関数を返す関数を作るので、
多分混乱するんだと思う。

bind1st = lambda arg: lambda f: lambda *args, **kw: f(arg, *args, **kw)

@bind1st(1)
def add(x, y): return x + y

PythonよりもJavaScriptの方が読みやすい・分かりやすいと思うんだけどなあ

>>673
その感覚すごくわかる。たしかに癒される。
Pythonに特有のことというわけじゃないんだけど、
Pythonの場合スタイルの縛りが厳しいせいか
比較的早く達成感的なサムシングが得られる気がする。

Python信者こわい

まぁpythonは日本じゃ今後も流行らなさそう

チュートリアルさえ読めば問題ないが通るなら
rubyのsuperとかも別に問題ないな

エキスパートPythonの訳者?のおかげで、なんかPythonのイメージが悪くなった
あと歯ブラシのPHPってなに?

>>680
使ってる身からしても、Rubyの
入門向けのオンライン資料が足りないってのは否定しないけどね
ただ例の人の言ってることはちょっと変な方向に行っちゃってるとは思う

まあ、ある意味バトルっぽくていいがw

Python好きな人ってMっけあるんじゃない？

いや色々だよ
ただ信者クラスになると妙に頭が固いというか、排他的な気はする

PHPとかきもいんだよ

ケーキPHPとか歯ブラシとか

なんかバカが　キャラ名に　すきやき　やきにく　歯ブラシ　とかつける感覚なんだろ？

ふざけてるっていうか　なんていうか

しねごみ

Pythonの日本語ドキュメントって2.5で止まってんだな
Rubyもドキュメントは全然整備されてないし
その点PHPは頑張ってるな

本ぐらい買え

あぁ、やっぱりドキュメントそうなんだ

翻訳遅くてすみません。2.6の翻訳中のものはこちらにあります。2.6出したときに比べると
大幅にスピードダウンしてますが、一応細々と続いてます。
http://pythonjp.sourceforge.jp/dev/
ライブラリリファレンスは殆ど終わってますが、チュートリアルの翻訳率はまだ低いです。
# といっても、チュートリアルはあまり2.5から変更なさそうですが。

日本語の書籍という観点で見るとRubyが圧倒的に多い感じだな
次点でPerl？ 僅差でPHP
Pythonはほとんどなかったが、最近ちょろちょろ出てるな

日本にRuby信者が多いわけだ

英語の書籍でもRubyの方が多い

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

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

Pythonはチュートリアルだけでもそこそこいけるからな

>>656
>Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった（未だにユニコードのエラーが解消できない）。

馬鹿には無理です

日本限定でも、RubyとPythonだったら、Pythonの方が将来性あるだろう。

PHPのドキュメントは圧倒的に優れてるな。日本語翻訳のスピード、質の高さが半端ない。MSとかと比べても全然優れてる。
それに公式サイトの作りが秀逸。上に説明があって、下に掲示板があって、掲示板まで読めば使いどころとか注意点まで全部分かる。

>>690
といっても、Rubyでもやっぱり
良書とされる書籍は原語が英語のことが多い
『初めてのRuby』とか日本語ネイティブのいい本もあるんだけどね

>>676
JavaScriptは環境が不自然
いくら便利な環境を作ったとしても、デフォルト・強制にしたらダメ

>>696
あれ、コテの人の発言と矛盾してるね

>>696
http://bugs.python.org/issue5911
これ、コテの人のunicode絡みのfeature requestで、rejectされてるわけだが

http://dsas.blog.klab.org/archives/51390187.html
こことかでも同種の問題が指摘されているね

さすがシンボルみたいな基本も知らないレベルで他の言語disれる
Python信者は一味違うね

信者よりストーカーのほうがきもいよ

methaneなんぞいちいちストークするかボケ
>>702に上げたPython 2.x系の問題は2chのPythonスレにも上がってたし
Pythonユーザなら知ってるだろ

Python信者はよくありがちな自画自賛タイプだが
Ruby信者はストーカータイプ（笑）

>>702
後者のBlogも僕だったりしますが、、、
compileは内部のコンパイラとのI/Fなので特殊な事例ですが、確かに

そもそも、Rubyは初心者にとって読みにくい気がするって、初心者視点で感想を言ってただけなんですが、
シンボル判らないと初心者以下ですか？

シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、Ruby、Lispの
シンボルは独特で、Java、JavaScript、PHP、C/C++その他メジャーな言語では出てきません。
それなのに
> シンボルは任意の文字列と一対一に対応するオブジェクトです。
だけで、Rubyにおいてシンボルがどういう役割を持っているのかが一切説明されていないのですが、
これで判れという方が厳しくありませんか？

おいおい、いつの間にかRuby信者にされちゃったよｗ
俺はRubyだったらPythonのほうがまだ詳しいぞ

compile()は確かに初心者が直接使うもんではないかもしれないが
compile()を内部的に用いているプログラムは初心者も普通に使う可能性が
高いわけで、間接的にエンコーディングに関するトラブルが出るのが
問題なんだろ？
methaneは自分でバグレポ出したぐらいなんだから、んなことは百も承知だろうがな

俺は>>656ではないが、>>696のような厨房の言い草には腹が立った
Pythonをちょっと知ってるぐらいで、一体何様のつもりだよ

http://www.google.co.jp/trends?q=python+programming,+ruby+programming,+perl+programming,+php+programming&ctab=0&geo=all&date=all&sort=0

>>708
PHPよりPythonのほうが多いのはびっくりした

Railsブームってやっぱすごかったんだな

>>707
うん、unicodeが難しい例としてcompileが相応しくないという指摘をしているだけ。
もうちょっと詳しく言うと、compile()の結果がutf-8で良いなら現行のAPIでもBlogに書いたような
修正をすれば問題なくて、Windows上でcp932使いたい場合に今のcompile()が問題になる。

bzrっていうバージョン管理ソフトもPythonで作られてるんだけど、sys.argvがunicodeじゃなくて
バイト列なんで、Windows環境でユニコードファイル名使うために GetCommandLineW() 使って
引数を取り直したりとにかくめんどくさい。
WindowsでのUnicodeとcp932の問題が面倒なのはPythonだけの問題じゃないけどね。

>>707
>俺は>>656ではないが、>>696のような厨房の言い草には腹が立った
>Pythonをちょっと知ってるぐらいで、一体何様のつもりだよ

Pythonスレじゃ挨拶代わりなんだぜ

>>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の人がろくに勉強もせずに文句ばかり言ってるだけにしか見えない。

>>706
>そもそも、Rubyは初心者にとって読みにくい気がするって、初心者視点で感想を言ってただけなんですが、
>シンボル判らないと初心者以下ですか？
初心者以下かどうかは知らないけど、シンボルわかってないなら間違いなく初心者。

>シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、Ruby、Lispの
>シンボルは独特で、Java、JavaScript、PHP、C/C++その他メジャーな言語では出てきません。
なにをもってメジャーな言語とするかわかんないけど、LispやSchemeはメジャーじゃないってことか。ふーん。
それ、「メジャーな言語では出てこない」じゃなくて「自分がしってる言語では出てこない」の間違いじゃない？
なんというか、JavaやC++にはクロージャが出てこないので・・・とか、mix-inはRuby以外の言語には見られないので・・・とか言いそう。
Pythonならジェネレータとかまさにそうだと思うけど。
自分が知らないなら勉強すればいいだけだと思うけどな。

>それなのに
>> シンボルは任意の文字列と一対一に対応するオブジェクトです。
>だけで、Rubyにおいてシンボルがどういう役割を持っているのかが一切説明されていないのですが、
>これで判れという方が厳しくありませんか？
別にRubyに限らないけど、シンボルは単に記号を表すだけ。数値処理や文字列処理と同じように記号処理ができるというそれだけのこと。
どういう説明が欲しいの？

>>659
>list や str に限らず、全ての型は関数オブジェクトであって、呼び出したらその型のオブジェクトが返るようになっている。
>全く特別ルールではない。

これって他のメジャーな言語でも見られるの？
型を呼び出すことができるという時点で、まったくもって推測できなかったんだけど。
これを「全く特別なルールではない」とか、君はほんとに信者だな。

>>660
>誰かが貼ってたURLだけど、 http://slashdot.jp/developers/article.pl?sid=03/03/14/0258247 で、Matz自身が
>>少なくともRubyの目指すポジションは「Rubyに十分に慣れた人が最高のパワーを発揮できる道具」です。
>...
>>Ruby のやり方に十分に慣れた人が持つ常識が一貫して通用するという意味です。
>
>って言ってるんだよね。

うん、そうだよ。
そして、それはきみの勉強不足とはまるで関係ないよね。
入門書を読んで勉強したけど分からなかった、という話なら仕方ないけど
入門書も読まずに文句をいってる人が引用する言葉じゃない。

よく見たら

>>706
>シンボルテーブルとか一般的な意味でのシンボルは判るし、internももちろん判りますが、

って書いてあるじゃない。internが分かっててシンボルが分からないという理屈が分からない。

これだからRuby厨って・・
Lisp使いだけど残念ながらメジャーとは言えないと思う
CやJavaから来た人ならシンボルを知らなくても当然でしょ

シンボルも知らないのか馬鹿！
メソッドチェーンも知らないのか馬鹿！

>>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のやりかたが特に初心者に理解しやすいとも思わんが

なにしろこの説明で既にメタクラスが出てしまってるぐらいだしな

アンダースコア2個で囲まれたメソッドってなんかキモいんだけど、どっかの慣例？

C

Java,Cやってる人は、Python派
PHP,Perlやってる人は、Ruby派
でFA？

元はCだと思うが（もっと古いのかも）
__FILE__みたいなのってPerlやRubyやPHPにもあるだろ

>>721が一体どんな言語を使ってるのか興味あるなｗ

c++がperlとして、javaにシンパシーを感じるのがPythonで
c#ならrubyって感じがする

>>659
>>（未だにユニコードのエラーが解消できない）。
>これは、なんとなく偶然に動くよりも明示的にエラーにしようっていう方針。
>「動いてるけどどこかで文字化けしている」ってなる前に、例外だして問題の
>あるところを指摘してくれてるんだよ？むしろ優しいじゃないか。

勘違いしてるね。問題にしてるのは、エラーが起きたことじゃなくてそれを解消できないこと。
問題があるときにエラーになるのは当然でしょ。それは別に結構なこと。
そうじゃなくてPythonのユニコードがらみのエラーは、少なくとも初心者には解決が難しく、
エラーメッセージもわかりにくい。

まあPythonな人はチュートリアルを読めばわかると言い張るんだろうけどｗ

>>718
>これだからRuby厨って・・
>Lisp使いだけど残念ながらメジャーとは言えないと思う
>CやJavaから来た人ならシンボルを知らなくても当然でしょ

これだからPython厨って・・
彼が非難されているのはシンボルを知らないことじゃなくて
入門書の一冊でも読めばわかることを、勉強もせずに「読んでもわからない」と
言い張っていること。
「Lisp使い」なんて見え見えの隠れ蓑やめたら？Pythonさん。
Lispがメジャーでないなら、日本でのPythonもまったくメジャーじゃないね。

あ、だから他の言語を必死にけなしてるのか。

Rubyには公式のチュートリアルがない、という批判ならまだ理解できるけど
Pythonな人の文句はそうじゃないからなあ。
自分が理解できないRubyが悪い、と言われても、勉強してください、としか言いようがない。

>>716
Rubyが判りにくい言語だと文句を言っているわけではないです。
あくまでもPythonに比べての相対的な感想でしかありません。

僕が挙げた例が全て妥当だとはいえないかもしれませんが、
Rubyだと開発者本人が、「十分にRubyに慣れた人のための言語」と言っているのに対して、
Pythonだと僕以外にも「十分にPythonに慣れていない人にも使いやすい」と感じているのは事実です。

>>721
特別な意味を持った名前は特別な命名規則を与える事で、
1. 初心者がそのメソッド名を見たときに「これは特別な意味を持ったメソッドなんだ」と瞬時に理解できる。
2. 初心者が普通のメソッドを作ろうとして、他の意味を期待されてしまう名前を使ってしまう心配が無い。
というメリットがあります。

>>Lispがメジャーでないなら、日本でのPythonもまったくメジャーじゃないね。
これはさすがに無茶苦茶いいすぎ

>>729
普遍的に、万人にとって使いやすいの？

pythonと相対的に他の言語をみて、分かりやすい使いやすい言語は？

C,Lisp,Perlをいじってた状況でPythonとRubyに触れてみたんだが
Pythonの方がRubyよりは楽だったんだけどな

>>726
Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
という事でしょうか？
非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね？

Pythonの問題は、Python2ではunicodeとstrに対する方針が（標準ライブラリでさえも）ライブラリごとに
まちまちになってしまっているために、ライブラリとの受け渡しでエラーが発生しやすいことだと思います。
（Python 3.2 でやっと標準ライブラリの統一が取れる予定です。）

この問題が多くの日本人を悩ませていることは十分承知しています。
エキスパートPythonプログラミングで1章だけ追加章を書き下ろしたのも、この問題の深刻さを理解しているからです。

>>731
一つでも例外があったら駄目みたいな言い方だけど、
一般的にはpythonの方が使いやすいだろ

>>729
後者で言ってることってRubyのシンボルにもそのまんま当てはまるんじゃないの？

わかりやすいことと、つかいやすいことは必ずしも一致しない

今回の場合の「使いやすい」は、書きやすいという意味で使ってるのか？
事実とか一般的にとか、何を根拠に言ってるんだ？

つまり少なくともRubyは分かりにくくはあるわけだね

>>734
何がどう使いやすいのさ

>>738
ライブラリが豊富で、標準ライブラリも豊富で
言語もくせがないところかな。

Python信者って煽りは案外的確だった。

>>733
>>726
>Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
>という事でしょうか？

そうじゃないよな
一般的な他の言語では(文字化けするのに)エラーにならないから
なんとなく動いてるからとりあえずこれでいいやって放置されるのが問題

つまり初心者(またはLatin-1しか知らない外国人やrubyist)は一般的な他の言語では
そこに問題があることすら気付かないし欠陥プログラムを量産してしまうのが迷惑

>>729
> Rubyが判りにくい言語だと文句を言っているわけではないです。
どう好意的にみてもそうは見えない。

> Pythonだと僕以外にも「十分にPythonに慣れていない人にも使いやすい」と感じているのは事実です。
それはPython信者とその仲間の話だよね。

>一般的な他の言語では(文字化けするのに)エラーにならないから
>なんとなく動いてるからとりあえずこれでいいやって放置されるのが問題
webアプリだとエラーになるより文字化けしてでも表示してくれたほうがいいよね

>>743
それはPHPだけで通じる話だw

>>742
世界的に見たらPythonプログラマの方がRubyプログラマより圧倒的に多い罠
日本だけだろ、PythonとRubyが拮抗するのは。

>>739
相対的に言うなら、perlのライブラリの方が充実してるんじゃない？

>>745
もちろん。
ライブラリの数でいったら、Perlにはどの言語もかなわないよ。
その点に関してはCPAN最強。
ってか、まあ、あとはC、というかこれは範疇違うから比べてもしょうがないし。
Perl > Python > PHP > Ruby
こんな感じじゃない？

Perlはずっと圏外な感じだったが、ここに来てようやく登場か……。

>>733
>Pythonでのユニコードエラーの解消が、一般的な他の言語でのエラーor文字化け解消と比べて難しい
>という事でしょうか？
そうです。ユニコード文字列とふつうのバイナリ文字列がごちゃまぜになりやすい仕様なので。
チュートリアル読んでも、初心者ではなかなか解決できない。どうせ信者は否定するでしょうけど。

>非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね？
Javaではこんな面倒なこと起きなかったのにPythonではしょっちゅう。

>>748
別に解決は難しくないよ。
わからなくなったら、ちゃんと全部unicodeにすりゃあいいの。
それだけ。

エラーが出なかったらバイナリでもいいけど、ねw

>>743
http://boost.cppll.jp/
ここはあきらめたらしい

>そうです。ユニコード文字列とふつうのバイナリ文字列がごちゃまぜになりやすい仕様なので。

まぜるな危険
と誰が見ても判りやすい場所に書いておくべきだね

>>非ASCII文字を使うなら適切にエンコード、デコードを行うというのは、UCSな言語では全て同じですよね？
>Javaではこんな面倒なこと起きなかったのにPythonではしょっちゅう。

馬鹿だからさ

Javaは長いこと文字コード大問題だったじゃんw

>>720
丁寧な説明はありがとうだけどそれを「特別ルールではない」と思えるのはエキスパートだけでしょ。
クラスや型もオブジェクトであることまではいいとしても、それらを関数のように呼び出せるのは
Pythonを知らない人から見てどうみても特殊。
Pythonのこういうところは擁護するくせに「superの見た目が関数と同じなのが嫌い」とかアホか。

ま、でも、Pythonも今のunicode仕様に行き着くまでに紆余曲折、というか、
ポカもしてるわけで。
Python 1.6とか今やなかったことになってるからなw

>>752
それはunicodeとsjisのマッピングの話であって、ユニコード文字列とバイナリ文字列が混じりやすいというPythonの問題とは別。
冷静に考えればすぐわかる。頭冷やせ。

>>755
頭冷やすとかじゃないだろw
「問題」だろ、それも大問題だろ？w

あとさ、老婆心ながら、忠告しとくと、
Pythonせめるなら文字コードよりDB系の方がいいよ？
今でこそ、DB-API2.0が認知されてきちんとライブラリ出揃ったからいいけれど、
ちょっと前までは結構悲惨だったからな。
Postgre使うか、MySQL使うか、まさに悩みどころだったわさ。

>>755
>ユニコード文字列とバイナリ文字列が混じりやすいというPythonの問題

そんな問題ねーよ
isinstance(hoge, str)
isinstance(hoge, unicode)
でちゃんと区別出来るし
勝手に混ぜられないからエラーが出るんだよ

ぐちゃぐちゃまざってんのはお前の頭だろ

>>753
あー、C++だとキャストで int() とか書けるし、ある型のインスタンス生成に型名＋()なのは違和感無かったし、
それが関数呼び出しなのはC++で「変数宣言してるつもりが関数宣言してた」みたいな文法よりもすっきり
してると思ったけど、確かにC++以外の人にとっては 型名() は推測しにくいのかな？

superは、C++でもJavaでも明示的に引数は指定するから、Rubyのコード読んでるときに引数が
渡ってることになかなか気づかなくてハマったんだけど、i = int(s) とか、 L = list(x) とか、
実際に読んでてハマった？
できればPython勉強する前のバックグラウンドとなる言語とか教えて。

>>751, 755
静的型付けのJavaに比べると、さすがに初心者にとってのエラーの解消しやすさは違うね。
コンパイルエラー＞実行時型エラー＞暗黙の文字化け
とすると、初心者はコンパイルエラーと実行時型エラーの間に大きな壁があるし、
非初心者はエラーと暗黙に化けるの間に大きな壁がある。

でも、逆にJavaだときっちりしすぎてて、System.getenv()がStringを返す（Unix環境ではバイト列を
格納できるのに、それを取得できない）とか、汎用性にはかけてしまう。

>>758
俺も先にCを使っていたからかもしれんが、int()とか、()をつければ関数コールとかは違和感ない。
ってか、むしろ、「くせのない」仕様と感じるが。
これをくせがある、と感じる奴いるわけ？w

いねえよばかが

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？

>>761
名前付き引数は本当に良い機能。
単に辞書・ハッシュを引数に渡すのに比べると、メソッドの宣言を見ただけで引き数がわかりやすいし、
受け取り側での名前のバリデーションが自動で実行される。

少なくともその C#4 の仕様みたいに、仮引数（パラメータ）の名前が、明示的指示なしに
勝手に API の一部になるのはクソだろ。

プログラマの従来の感覚では、仮引数の名前はローカル変数の名前と同じで、関数の
ローカルに閉じたものだったんだから。うっかり名前を変更できないわけだから。

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のほうが書きやすいのが常識だった

C#もやっとpythonなみになってきたな

Javaと違ってC#はかなり強力なので、.NET上のほかの言語があまり流行る感じがないな
MS謹製のF#もScalaほど注目されてないように見える

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

>>723
俺は逆。
Perlやってるから、.Rubyに必要性を感じない。Pythonの方がいい。
PHPの人はどっちにも興味ないと思う。

Rubyってアップルから捨てられたみたいだけど、この先勢いを
取り戻す事はく消えるだけですよね。

そう思いたいならそう思っていたほうが、精神の安定になると思いますよ。

Ruby-Cocoa（苦笑）

MacRubyの開発してるけど

ruby / python 両方覚えればいいと

Ruby使ってないけどMacRubyはかっこいいと思う

>>773
わしにはそんな時間もうないのじゃ

>>775
諸行無常だね…

木下誠　っていうクソマカ
ｖｓ
Ｐｅｒｌｅｒ

必要を感じたら学べばいいんじゃないか？
そして必要に応じて深く学ぶと

>>758
俺は>>753では無いが、型名()は何やってるのか推測しにくいぞ。

C++でもいくつかある書き方の1つでしかないし
C++での他の書き方やJavaに倣って new 型名() を使う形式も多い。JavaScriptとかPerlとか。
Delphiは 型名.Create() と、コンストラクタ名（大概のクラスでは Create という名称）を直接書く。

Pythonでハマッた点は…int()を関数だと思ってしまって意味が解らなくなったことならある。
まさかintが型名で、インスタンス生成の形式になってるとは思わなかった。
ドキュメント読めば解るがそれはRubyのsuperも同じ。
…でも引数の不一致はコードを追う過程で自然と判ると思うのだが？

でも一番ハマッたのはclass文の「新形式」かな。
新形式とは何か、旧形式とは何か、が
（少なくとも俺が読んだ当時のドキュメントには）書かれてなくて
自分が書いたclass文が旧形式だとは知らずに困った。
旧形式って言うぐらいだから、class文すら使わないような形式だと思ってたよ。

その勘違いの原因の1つに、objectをわざわざ継承しなければならないってところもあったかな。
JavaもDelphiも…そしてRubyもだが、基本的に「全ての基底となるクラス」があって
継承元を省略した場合には、そのクラスを継承したことになるってのが当たり前だと思ってたから。

ああ、そこオレもはまったよｗ

ほら、な？
Python批判するのは馬鹿ばっかりだろ？

Python信者もシンボルが理解できないくらい馬鹿だけどな

>>724
Rubyの場合はメソッドじゃなくて疑似変数だね。
CやPerlの語彙を借りてるだけで、アンダーバーを使いたいわけではない。

俺が理解できないことは万民にとってそれが分かり難いものだというだけのこと
俺が理解できることを理解できない奴は全員馬鹿

新形式クラスとか旧形式クラスとか、Pythonの統一が取れてない面だけど、
別に知らなくてもコード読めてた気がするんだけどなぁ。
本当に、他人のコードを読んで大体の動作をつかむ上でそこに引っかかる？

>>784
Rubyにも__send__みたいメソッドはあるよ
sendの再定義に備えて用意してある

あと、Python自体が統一が無いと認めてPython3で修正するような問題（Pythonicで無い部分）と、
Ruby1.9でも変わらず、Ruby2.0でもきっと変わらないRubyらしい部分を比較するのも、フェアじゃない気がする。

＞フェアじゃない気がする。

本日の「お前が言うな」ですね

フェアじゃない気がする。(ｷﾘｯ

>>786
いや、それならシンボルも別に知らなくても大体の動作はつかめるよね。。。

シンボルが引数なのは割とよく出るけど、新クラスと旧クラスの挙動の違いがコード読むときに
関係することはあんまり無いと思うんだけど、、、僕だけ？ごめんなさい。

>>696
>>Pythonは簡単っていうから勉強したのに、ちっとも簡単じゃなかった（未だにユニコードのエラーが解消できない）。
>
>馬鹿には無理です

なるほど、Pythonは馬鹿には無理ですか。
Pythonエキスパートにそう言われると仕方ありません。あきらめます。
馬鹿には無理なPythonをマスターしているエキスパートはほんとうに頭がいいですね。うらやましいです。

>>782
>ほら、な？
>Python批判するのは馬鹿ばっかりだろ？

はいそうですね。Pythonは馬鹿には無理なので、Pythonを批判するのはマスターえきなかった馬鹿どものしわざです。
さすがPythonエキスパートさん。Pythonは頭のいいスマートな人が使う、素晴らしい言語ですね。

とりあえず、みんなそれぞれいろんな点で引っかかるのは判ったから、個別の事例は忘れて。

RubyとPythonを比べると、似てる部分が多いけど、どちらかというとPythonの方が構文がシンプルで
記号もキーワードも少なくて覚えることが少ない。
Rubyは「Rubyに慣れた人にとっての使いやすさ」を目指していて、Pythonはもう少し万人向け。
ここまでは殆どの人は異論無いよね？

もちろん、Rubyにもスクリプト言語やDSLとして使うときのタイプ数の少なさなど、Pythonに勝っている
部分もあるのは十分承知している。

>>793
そんなあなたに「エキスパートPythonプログラミング」。
UnicodeErrorがなぜ発生するのかの説明、安全な操作と安全じゃない操作の分類、
unicode未対応ライブラリとの付き合い方、Python3でどうなるかまで解説しています。
これを読めばあなたもエキスパートの仲間入り。UnicodeErrorなんて怖くない。

>>795
つまりどちらかのエキスパートを目指すなら、RubyのほうがいいということでOKですか？

>>795
構文や言語仕様がシンプルかどうかの比較ってそんなに重要かな
PythonってSchemeに比べると随分複雑な言語だけど
Scheme興味ないんでしょ？

>>797
人それぞれ。多人数が参加するオープンソースの世界ではPythonの方が選ばれていることが多いし、
少数精鋭で一気に素晴らしいWebサービスを立ち上げる事例はRubyの方が多いと思う。

>>798
似てる言語だから比べてるんであって、全然違うシステムの言語と比べても意味が無い。
せめて、オブジェクト指向をサポートした手続き型言語の範囲に絞って。

JavaScripterな俺から見ればPythonですら複雑すぎる

> オブジェクト指向をサポートした手続き型言語
なんでそこに拘るんだか意味わかんねえ
CommonLispはオブジェクト指向をサポートしたマルチパラダイム言語だけど、
CommonLispならいいの？

言語仕様がシンプルがシンプルなのは、複雑なのよりずっと良い

>>795
この文章だけ読んでも、Rubyを下に見ている感が溢れでまくってるね
滲み出るとかのレベルじゃなく、溢れまくり
Ruby信者って怖いなあって思うことが多々あったけど、Python信者さんは格が違った 恐れ入る

>>802
俺もそう思うけど、そういう思想でLisp族をスルーするのは解せないね

Pythonクックブックにも、
Pythonは何でもできるけど、Lispも何でもできる。あの括弧だらけのコードに堪えられればの話だが
みたいな文章があったよ

>>801
構文だけでなく、バラダイムまで習得しないといけないから、構文のシンプルさが
学習コストの低減に繋がらない。
アセンブラ/C/C++/Java に加えて一つスクリプト言語やアプリケーション作成向けの
言語を覚えようと思ったら、手続き型＋オブジェクト指向の方が直ぐに覚えて高い生産性を
発揮できる。

自分ひとりなら趣味で選べても、例えばC++のプロジェクトのビルドやテスト用にスクリプトを
書くとして、自分以外にもいろんな人が読み書きする可能性があるのにCommonLispが
妥当な環境って少ないと思う。
逆に、なんでPythonやRubyじゃなくてLispに拘るの？

>>803
漏れはそんな風に感じなかった
藻前がそう思ったならそれは藻前のコンプレックスがそうさせているんだ

>>807
というかMatzでも普通に同意するんじゃないかな

> 逆に、なんでPythonやRubyじゃなくてLispに拘るの？
俺は特にこだわってないよ
要は、あなたは構文のシンプルさを重視しているようで、実は重視してないんでしょ？
生産性のほうが重要だからPythonを選ぶと自分でいっているわけだ

ならRubyを選びたがる人の気持ちもおのずと分かりそうなもんだけど、
そうでもないのが面白いね

> 学習コストの低減
云々も、結局そのユーザのバックグラウンド次第でしょ
情報科学の専門教育を受けた人間なら、たいていSchemeやらMLやらの
関数型言語ぐらい弄ってるだろうし

なぜ二者択一なのか分からん。一部を重視したら他全部は捨てることになるのかよ

>>809
生産性と同じくらい、習得のしやすさや、読みやすさ、毎日その言語を使うわけではない人にも
気軽に使える事を重視しているだけだよ。
自分が書いたコードは同僚にもメンテして欲しいし、同僚が書いたコードは俺もメンテしないと
いけないからね。

>>812
つまりさ、それはあなたの条件にとってPythonが最善だった（少なくともあなたは
そう判断した）ってだけの話じゃないの？

PythonがシンプルだからとかRubyは複雑だみたいな話に
そこだけ取り出して持っていったところで、
Pythonなんかよりずっとシンプルな言語いくらでもあるし
一般的な主張としては、大して意味無いように見えるのだけどね

だいたいあなた、習得しやすさ等を考慮して判断してるかのごとくに言ってるけど
Lispについては判断以前に何もしらないんでしょ？

>>812
個別のことを忘れようと書きながら、
>>806で
> アセンブラ/C/C++/Java に加えて一つスクリプト言語やアプリケーション作成
> 向けの言語を覚えようと思ったら、手続き型＋オブジェクト指向の方が直ぐに
> 覚えて高い生産性を発揮できる。
と十分個別のことを書いてるように思える。

>>813
そもそもPythonとRubyを比べたTwitterの書き込みに批判があったからそれについて
話してただけなのに、なんで他のパラダイムの言語まで含めた一般論をしないといけないの？

Lispがライブラリの数や質まで考慮に入れてPythonよりも生産性が高いとは思いにくいし、
そもそも興味が無い。

>>814
個別の事例ってのは、superとか名前付き引数とかselfとか、PythonとRubyの個々の構文の違い
という意味で言ってた。
PythonとRubyどころか手続き志向言語から話題が離れると全く専門外だから、これ以上僕に
向かって話題振らないでくれ。

Lisp使いでPythonも好きなんだけど流石にこれはちょっと引く
Python使いの全てがこんなのとは思って欲しくない

またLisp使いの人かよ

> これ以上僕に向かって話題振らないでくれ。
はいはい、じゃあねバイバイｗ

Lisp厨が一番痛い。スレタイ嫁

まあ色々まぜるとPythonが威張れないからね

しかしその人気のなさにも関わらず、LISP (現在では “Lisp”、もしくは“Arc”と書かれる)は
「マクロ」や「見下し」といった強力なプログラミングテクニックによって影響力ある言語であり続けている

>>821
そのページは、JavaとC#だけネタでも何でもないただの事実が書いてあって
それがそのままネタになってるのが面白かったな

>>786
読む上で引っかかることはあまりないけど、書く上で引っかかる。

というか盛んに読むことのみを見てRubyを批判するけど
プログラムってのは読むだけでは終わらないでしょ？
書く為に読むんじゃないか？読むだけのプログラミングって何？

Pythonが読むのに向いてるのは認めるよ。というか
自分も割とPythonを使うから、読みやすいのは百も承知。
他人のコードや、随分前の自分のコードも読めるのは良い点だ。
個人的なものなら、Rubyで書いたコードをPythonに移植することも多い。
後から見返すにはそのほうが楽な場合もあるからね。
（一部、文字列関連の処理はRubyのが少なくとも俺は読みやすいのでそこは除く）

ただ、書くなら俺はRubyのほうへ分があると考えている。
だから読む部分だけ見て批判するのはフェアではない。
いや、批判しても良いのだけれど、どうもその言い方に引っかかるものがある。
Rubyのコードを書いたことがあるのかな、と。
読んだだけで批判してやいないか、と思ってしまう。
いや、Pythonのコードもさほど書いていないのではないのか、と疑ってしまう。

もちろん読むことは大事だ。でもさ、読むのは最終的に書くためにするんだろ？
他人のコードただ読んでそれで終わりってプログラミングって無いんじゃね？
ただ読むだけでも、それは後に書くのに繋げるものじゃね？
なんか読みだけで見るのっておかしくね？

> いや、Pythonのコードもさほど書いていないのではないのか、と疑ってしまう。
書いてはいるんだろうけど
比べる相手がアセンブラにC, C++じゃあ、そりゃ天国みたいなもんだろうね
Pythonは

もう600レスほど使って無意味な会話続けてるけど、Pythonってこんなに貧しい言語じゃないよ。

結局、各言語のマスタークラスがいないわけね。ここには

タコツボ視野の自称マスターじゃ意味ない

>>823
書くために読んでるのは認めるけれど、書く量の数十倍のコードを読まない？
量じゃなくて時間で言っても、やっぱり書く時間より読んでる時間が長くない？

たぶん、この書きやすさと読みやすさのバランスがPythonとRubyの一番の違いだと思う。

両極端で言うと、ライブラリの不具合を直す数行のパッチを作るために何百行、何千行も
読むケースと、新規のWebサービスを短時間で立ち上げるために勝手知ったるフレーム
ワーク上でひたすら書くことに集中するケース。

僕の場合は前者はあるけど、後者は無いな。もちろん読み書き比率が100倍超えるようなのは
エッジケースだけど、平均しても数十倍はあると思う。

最近は、フレームワークしか使えない人
というのも居てなんだかな

特にRailsとRubyの区別が付いてない人が身近に多い。
キラーアプリみたいなもんだったからな。

コード読む量のが多いとかチームで仕事とかなら性的肩言語のほうがいいなあ
LLは書き散らしてこそ花だと思ってるわ