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

1 ：デフォルトの名無しさん：2010/10/25(月) 03:23:51

もういらないよね

2 ：デフォルトの名無しさん：2010/10/25(月) 03:31:39

>1 乙

3 ：デフォルトの名無しさん：2010/10/25(月) 03:47:55

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

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

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

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

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

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

4 ：デフォルトの名無しさん：2010/10/25(月) 03:49:11

>>1
死ね

5 ：デフォルトの名無しさん：2010/10/25(月) 03:49:24

※前スレ
【Perl,PHP】LLバトルロワイヤル12【Ruby,Python】
http://hibari.2ch.net/test/read.cgi/tech/1284382120/
■過去スレ
【Perl,PHP】LLバトルロワイヤル11【Ruby,Python】
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/

6 ：デフォルトの名無しさん：2010/10/25(月) 04:24:36

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

7 ：デフォルトの名無しさん：2010/10/25(月) 04:28:13

Ruby最強

8 ：デフォルトの名無しさん：2010/10/25(月) 08:32:23

シンボルを理解できないPython信者

9 ：デフォルトの名無しさん：2010/10/25(月) 10:16:53

pythonスレ荒らしてたのはやっぱこいつらか

10 ：デフォルトの名無しさん：2010/10/25(月) 10:47:52

Rubyスレに誤爆進展じゃねえ

11 ：デフォルトの名無しさん：2010/10/25(月) 11:31:38

シンボルくらい理解してるがRubyは使いたくないな
PerlやPythonの方がマシ

12 ：デフォルトの名無しさん：2010/10/25(月) 12:27:33

相変わらずだなこのスレ

13 ：デフォルトの名無しさん：2010/10/25(月) 20:57:03

声が大きいだけのruby信者

14 ：デフォルトの名無しさん：2010/10/26(火) 03:17:53

PythonってRubyみたいなイテレータメソッド用意されてる？
forやwhileで回す文化？

15 ：デフォルトの名無しさん：2010/10/26(火) 03:44:21

forで回す文化だけど

16 ：デフォルトの名無しさん：2010/10/26(火) 07:31:43

for DragonよりかはWhile Dragonの方がかっこいいです

17 ：デフォルトの名無しさん：2010/10/26(火) 07:33:00

Rubyは内部イテレータ文化
Pythonには外部イテレータを簡単に作れるジェネレータがある

18 ：デフォルトの名無しさん：2010/10/26(火) 08:07:43

Pythonには内部イテレータも外部イテレータもあるよ
ジェネレータの方が簡単なのでみんな外部イテレータを使ってるだけ

19 ：デフォルトの名無しさん：2010/10/26(火) 09:26:47

ん？どゆこと？
簡単に作れるって、eachとかmapとかinjectとか、毎回自分で定義すんの？めんどくさ

20 ：デフォルトの名無しさん：2010/10/26(火) 09:32:17

今までに無いタイプの煽りだな
無知って言えばいいのかな

21 ：デフォルトの名無しさん：2010/10/26(火) 09:33:01

そういうことじゃなくて。

外部イテレータ文化なので外部イテレータと組み合わせて使うforを使うのだというか。

22 ：デフォルトの名無しさん：2010/10/26(火) 09:59:11

外部イテレータも理解できないRuby信者

vs

シンボルも理解できないPython信者

ﾌｧｲｯ!!

23 ：デフォルトの名無しさん：2010/10/26(火) 10:01:16

死ね

24 ：デフォルトの名無しさん：2010/10/26(火) 10:24:14

>>19
eachがPythonのforとほぼ同じ。

25 ：デフォルトの名無しさん：2010/10/26(火) 10:47:23

イテレータブロックの事を言ってるのならpythonにはないよ

26 ：デフォルトの名無しさん：2010/10/26(火) 11:01:01

Rubyのブロックは他の言語のlambda/クロージャに近いけど、中でnextとか使えるから
iteratorを意識した特殊仕様の不純物なんだよな
だが便利なのでRubyでは多用されている

一方Pythonのlambdaは非常に非力なので、多用されない
ループ的な処理を高階関数でやると関数呼び出しのオーバヘッドで遅くなるから、
というのも理由にされている（らしい）
それは実際その通りで、C++のように関数呼び出しをインライン消去できない言語では
そうならざるを得ないんだが、
Pythonはもともと糞遅い言語なのでそれは二次的な理由で、
lambdaの非力さと、Rubyのブロックつきメソッドのような
構文的サポートがないことにより、単にPythonで似たようなことをやろうとしても
不便なので誰もやらない、ということにつきると俺は思っている

27 ：デフォルトの名無しさん：2010/10/26(火) 11:17:33

Rubyのブロック付きメソッドで、
File.open(...) { |f| ... }
みたいなパターンの奴は、Pythonではwithブロックを使う
with open(..) as f: ...

ただしCPythonはリファレンスカウントなので、それを使うまでもない
ことが多い

28 ：デフォルトの名無しさん：2010/10/26(火) 13:21:45

>>19
e.each{|x| ... } → for x in e: ...
e.map{|x| ... } → [ ... for x in e] または map(xを引数にとる関数, e)
e.select{|x| ... } → [ x for x in e if ... ] または filter(xを引数にとる関数, e)
e.inject(init){|t,x| ... } → reduce(tとxを引数にとる関数, e, init)

Pythonあんまり使わんから解らんけど、reduceって内包表記じゃ書けないの？
まあresult=initしてfor x in e: result=...でいい気はするけど

29 ：デフォルトの名無しさん：2010/10/26(火) 13:48:44

>>28
内包表記って「リストを返す」もんだから、その時点でreduce()とは別物
まあおおざっぱに言ってmap()/filter()の相当物だわな
無理に書けばこんなコードになる

def make_accumulator(init, f):
_ = [ init ]
def thunk(x):
_[0] = f(_[0], x)
return _[0]
return thunk

def my_reduce(f, xs, init):
acc = make_accumulator(init, f)
return [acc(x) for x in xs][-1]

print my_reduce(lambda x, y: x + y, range(1, 11), 0)

30 ：デフォルトの名無しさん：2010/10/26(火) 14:00:00

>>26
lamdaが非力なのは意図的なので、lamdaが非力な言い訳だとお前が思うのは、お前の中だけの正解だな。

31 ：デフォルトの名無しさん：2010/10/26(火) 14:02:36

>>30
Pythonはlambdaが非力で実に鬱陶しいと思った記憶しかないがなあ
もともと式言語なら中に式しか書けなくとも問題はないが、
何でも文、文、文な手続き型ベッタリの言語だし

せっかくファーストクラスの関数を持ってるのに、この辺でかなり台無し

32 ：デフォルトの名無しさん：2010/10/26(火) 14:03:42

make_accumulatorが>>29のようになってしまうのもPythonの汚点
まあ馬鹿馬鹿しいからこんなコードを書く奴はいないが

33 ：デフォルトの名無しさん：2010/10/26(火) 14:10:01

Python標準のtimeitはかなり恥ずかしいから見てみるといいぞ
http://www.python.jp/doc/2.4/lib/module-timeit.html

timeit.Timer('for i in xrange(10): oct(i)', 'gc.enable()').timeit()

なんじゃこりゃｗ

34 ：デフォルトの名無しさん：2010/10/26(火) 14:17:52

>>33
何が恥ずかしいの？
独立した環境で式を実行するために式を文字列で渡しているだけだよね。
構文で独立した環境を作る機能をサポートしないといけない？

35 ：デフォルトの名無しさん：2010/10/26(火) 14:21:13

>>28
reduce は each と同じく、ただのループか、 reduce() 関数使うのがPythonicだな。

36 ：デフォルトの名無しさん：2010/10/26(火) 14:24:05

>>34
そりゃあんた、素直に式や関数などのオブジェクトを渡したい、というニーズのほうが
独立した環境で計測したい、というニーズよりもずっと多いだろうよ

初心者はREPL上で
def foo(): ....
timeit.Timer(foo).timeit(10000)
となぜ書けないかを疑問に思い、
次に
timeit.Timer('foo').timeit(10000)
と書いてなぜ動かないかを疑問に思うわけだ

37 ：デフォルトの名無しさん：2010/10/26(火) 14:25:15

ああ下は'foo()'のつもりな
まあどうでもいい話だが

38 ：デフォルトの名無しさん：2010/10/26(火) 14:28:14

>>35
reduce()はPythonicではないらしいぞ

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

39 ：デフォルトの名無しさん：2010/10/26(火) 14:29:53

timeit.Timer(foo).timeit(10000)
これは動くよ? 2.6からだけど

40 ：デフォルトの名無しさん：2010/10/26(火) 14:37:01

>>39
あー、そうなのか
そりゃすまんかった

41 ：デフォルトの名無しさん：2010/10/26(火) 14:44:28

>>38
（Lisp脳以外の普通の人間にとっては、）reduceはtirivialではなくて、
reduce の殆どのユースケースは sum, any, all でカバーでき、それ以外も
ループを使って書いた方が読みやすいから、 functools に追い出すよって話ね。

一応、モジュールに移動されたからそれを使うのが全てにおいてPythonicじゃない
というわけじゃない。（もしそうなら移動じゃなくて削除されるか、せめてdeprecatedになる）
殆どのユースケースではPythonicではないというだけだ。

42 ：デフォルトの名無しさん：2010/10/26(火) 14:54:00

> （Lisp脳以外の普通の人間にとっては、）reduceはtirivialではなくて、
別にLisper専用ってことはないだろ
関数型言語にfoldがあるのは当然として、
C++にはaccumulate、C#にはAggregate、Rubyにはinject、という具合に
それを備えた言語は多い

43 ：デフォルトの名無しさん：2010/10/26(火) 15:00:36

>>42
うん、Pythonだってreduceを無くすわけじゃない。あくまでも min max sum といった
ビルトイン関数群から降格されるだけ。
non trivial = 悪、では無いからね。

44 ：デフォルトの名無しさん：2010/10/26(火) 23:00:49

>>26
Pythonなら「lambda使わなくてもできるんだし、Pythonicじゃない」という理由もありそう。

そういや、lambdaを採用したのは失敗って作者がいってなかったけ？

45 ：デフォルトの名無しさん：2010/10/26(火) 23:05:00

Pythonユーザーすらまともに使わなくて、他の言語からの移行者の罠同然なlambdaを残しているPythonがPythonicなのかどうか

46 ：デフォルトの名無しさん：2010/10/26(火) 23:11:13

他の言語の奴が注文付けたんだろ。知ったこっちゃない

47 ：デフォルトの名無しさん：2010/10/26(火) 23:16:27

lambdaは複雑な使われ方してるから、失敗なんだろ。
単純な使い方しかしなけりゃ便利だし害もない。

顔をしかめて読んだり、行の真ん中読んだら初めの方を読み直したりしないと読めないコードはPythonでは嫌われる傾向にある。

48 ：デフォルトの名無しさん：2010/10/26(火) 23:19:54

C++0xでλを導入しようとしてるC++にあやまれ！

std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), [&total](int x) {
　total += x;
});
std::cout << total;

こんな小汚い構文だが、こんなものでも無いよりはマシとかC++の人は
思ってるんだぞ（たぶん）

49 ：デフォルトの名無しさん：2010/10/26(火) 23:30:55

そもそも、C++はCと違って関数内で関数を定義できないし、operator() を実装した
structを関数内で定義するとテンプレートから参照できなくてエラーになるから
簡単なコードを渡すためだけでも離れた場所にstructを定義しないといけなかった。
JavaもC++よりはましだけど、関数一つ渡すためにclassを定義しないといけなかった
からクロージャや関数型変数の導入が考えられている。

それに対して、Pythonの場合実装が1行の関数を作るのには def foo(): を
つけるだけで良くて、コード上のオーバーヘッドが圧倒的に少ない。
関数内で名前付き関数を作るのが十分に簡単お手軽だから、lambdaの出番は
本当にちょっとした式だけで良い。

50 ：デフォルトの名無しさん：2010/10/26(火) 23:39:22

必ずしもオブジェクト指向に拘らなくていいしね。LLなら当然か

51 ：デフォルトの名無しさん：2010/10/26(火) 23:51:13

>>49
勿論lambdaを捨ててしまっても、Pythonで「出来ること」に差は無いけど
「書きやすさ」には差がでるよね
俺はLLではそこは重視してるよ

たとえば>>29の例をgroovyで考える
groovyには内包表記は無いから「mapで無理やり貧者のreduceを作る」というお題と
読み替えると、以下のように書ける
>>29よりずっと簡潔だ

List.metaClass.foldLeft = {init, f ->
delegate.collect{init = f(init, it)}[-1]
}
println((1..10).foldLeft(0){ x, y -> x + y })

52 ：デフォルトの名無しさん：2010/10/27(水) 00:05:02

groovyで言われてもリアクションに困るよね

53 ：デフォルトの名無しさん：2010/10/27(水) 00:13:07

>>51
そもそもプログラム書いてて「mapで無理やり貧者のreduceを作る」必要は全く無いからな。
reduceを作るならlamdaもmapも使わずにループを使えば良い。
def my_reduce(func, xs, init):
    for x in xs:
        init = func(init, x)
    return init

>>29はあくまでも内包表記で無理やりreduceした例であって、lamdaの強さが書きやすさに
大きな影響を与える例ではない。

54 ：デフォルトの名無しさん：2010/10/27(水) 00:13:15

別にgroovyはどうでもよくて、
なぜPythonでは>>51のように書けないのか考えてみるといい

55 ：デフォルトの名無しさん：2010/10/27(水) 00:14:46

pythonはgroovyではないから

56 ：デフォルトの名無しさん：2010/10/27(水) 00:16:29

>>54
ループで十分だから。

57 ：デフォルトの名無しさん：2010/10/27(水) 00:19:21

Lisp プログラマのための Python 入門
http://www.unixuser.org/~euske/doc/python/python-lisp-j.html

技術野郎の復讐---Revenge of the Nerds---
http://www.shiro.dreamhost.com/scheme/trans/icad-j.html

「技術野郎の復讐---Revenge of the Nerds---」への反響
http://www.shiro.dreamhost.com/scheme/trans/icadmore-j.html

PythonとLispの関係について
http://www.shiro.dreamhost.com/scheme/trans/IsPythonLisp-j.html

58 ：デフォルトの名無しさん：2010/10/27(水) 00:19:45

>>53
そ、Pythonだとそう書くことになるんだよね

> >>29はあくまでも内包表記で無理やりreduceした例であって、
> lamdaの強さが書きやすさに大きな影響を与える例ではない。

Pythonで>>51のように書けないのは、lambdaが弱いからだよ
そして、higher order functionを使いたいケースというのは別にループに
限らない

59 ：デフォルトの名無しさん：2010/10/27(水) 00:22:55

そう書くことになると、何が問題なのか

60 ：デフォルトの名無しさん：2010/10/27(水) 00:24:38

>>59
単にhigher order functionを使った「抽象化」がしにくい／使いにくいってことさ
上の例は、確かに無用なくだらない例に過ぎないが

61 ：デフォルトの名無しさん：2010/10/27(水) 00:25:25

>Pythonで>>51のように書けないのは、lambdaが弱いからだよ
>>51のように書けなくても、>>53のように書けるから全く困ってないし、
Pythonの人達は >>51 よりも >>53 の方が読みやすいと思ってるんだよ。

>そして、higher order functionを使いたいケースというのは別にループに
>限らない
そして、Pythonは名前付き関数を簡単に定義できるから、lamdaが式しか
書けなくても higher order function を使いたいケースで特に困らない。

62 ：デフォルトの名無しさん：2010/10/27(水) 00:28:41

>>61
そのhigher order functionを使いたいケースで、確かにPythonでも
書けるし困らないかもしれないが、
「困らない」といいつつ、その記述力には上で見たとおりの差があるんだよ

実際、うまく書けないからループに逃げたんだろう？

63 ：デフォルトの名無しさん：2010/10/27(水) 00:30:53

物は言いようだなｗ

64 ：デフォルトの名無しさん：2010/10/27(水) 00:31:07

そもそも内包表記で無理に書く必要性を感じないが
def my_reduce(f, xs, init):
　def g(x, acc=[init]):
　　acc[0] = f(acc[0], x)
　　return acc[0]
　return [g(x) for x in xs][-1]
と書いてみるテスト。

65 ：デフォルトの名無しさん：2010/10/27(水) 00:32:37

逃げというならどこまでも逃げられるんじゃね。どっかで捕まえてくれないとさ

66 ：デフォルトの名無しさん：2010/10/27(水) 00:33:38

>>64
そう書くと>>29よりは大分短くなるね

67 ：デフォルトの名無しさん：2010/10/27(水) 00:35:29

「ほ～ら、早く捕まえてみなさいよぅ」
「こいつう、待て待て～～～～」
とかそういうアレか

68 ：デフォルトの名無しさん：2010/10/27(水) 00:35:34

>>62
信じられないかもしれないが、Pythonの人達は逃げてるのではなくて、
本当に心のそこから >>51 よりも >>53 の方がシンプルで読みやすいと
思っているんだ。

69 ：デフォルトの名無しさん：2010/10/27(水) 00:38:11

>>68
いやそれは分かる、俺だって>>53のほうが読みやすいと思う
が、問題はそうじゃない

ここではたまたまmap()だが、既存の抽象化された高階関数を「利用」する際の
利便性を問うていて、そういった際にlambdaの記述力が問題になるのに、
題意を無視してループで書いてしまうのは「逃げ」だ、と言ってるんだよ

70 ：デフォルトの名無しさん：2010/10/27(水) 00:38:40

上手い例を持って来いよ

71 ：デフォルトの名無しさん：2010/10/27(水) 00:46:54

おまいらこれの
ttp://www.amazon.co.jp/dp/4873114713/
pythonの章は読んだ？

72 ：デフォルトの名無しさん：2010/10/27(水) 00:48:06

>>69
lambdaの記述力については、Guideが意図的にあんまり持たないようにしてる。
けど、仮に
lambda x,y:
　statements...
みたいにかけたとしても、
def foo(x, y):
　statements...
と比べて特にメリットがあるとは思えない。

73 ：デフォルトの名無しさん：2010/10/27(水) 00:50:10

少ないケースだけど、lamdaの非力さを感じることはあるな。
例えば obj.onclick = lambda: self._onclick(3) とは書けるけど、
obj.onclick = lambda: raise TestException("Button3 is clicked") とはかけないから、
def _onclick():
raise TestException("Button3 is clicked")
obj.onclick = _onclick
と3行(2行でも書けるけど)に分けて書かないといけない。

この制約の利点を無理に上げるとすれば、、この程度の不自由さと引き換えに、
Lisp脳の人が書いたlamdaを乱用したコードが排除できてメンテしやすい。

74 ：デフォルトの名無しさん：2010/10/27(水) 00:54:06

>>72
ただの推測なんだが、Pythonの構文自体が理由で、「ブロックの後に
何かをつなげる」ことがやりにくいからってのは無いのかね
だから色んなものを式にしにくいんじゃねーかと俺は疑っていた

あのJavaですら匿名インナークラスの定義とインスタンス化が
「式」になっているわけだが

lambdaに関しては、文はさておいても
6文字もタイプさせるのをやめて、Scalaの_やgroovyのitのような
ワイルドカードを使えるようになるだけでも大分マシなように思う

75 ：デフォルトの名無しさん：2010/10/27(水) 00:57:47

なんだよマシって。そんなPython使わない

76 ：デフォルトの名無しさん：2010/10/27(水) 01:00:09

>>74
多分言ってる事は正しいんだけど、そもそもPythonの価値観がそんな
書きやすさは最初から無視しているんだと思うよ。
式をネストさせて複雑な式を作るよりも、シンプルな式で複数の文を作った方が
読みやすいと考えるのがPython的な考え方なんじゃないかな。

77 ：デフォルトの名無しさん：2010/10/27(水) 01:00:11

>>75
ワイルドカードは便利だぜ

py: [ x for x in xs if x > 0 ]
py: filter(lambda x: x > 0, xs)
scala: xs.filter(_ > 0)

同じ意味だが、上のは冗長で三回もxをタイプしなければならない
2番目はxが2回に減っているが、lambdaのせいで全体の長さはむしろ増えている

78 ：デフォルトの名無しさん：2010/10/27(水) 01:03:30

文字単位の長さとか気にしてんの？

79 ：デフォルトの名無しさん：2010/10/27(水) 01:04:19

>>79
気にするだろう！多い日も安心だし！

80 ：デフォルトの名無しさん：2010/10/27(水) 01:04:55

>>77
確かにそれは便利。
でも、Pythonだと

1) 新規に記号を割り当てる => 記号を割り当てるほどの事ではない。
2) _ に特殊暗黙ルールを割り当てる => 特殊暗黙ルールなんてイヤ！

って感じで、受け入れられないだろうな。

81 ：デフォルトの名無しさん：2010/10/27(水) 01:08:30

>>26
なんだよ、2chのくせに的確な分析じゃねーか
内容に98パーセント同意

Pythonのlambdaってほんとうに複数文をサポートできるように拡張できないのかなあ
>>73とかみると、Pythonが残念な子に見えて仕方ない。

>>74
いやそのとおりだと思うし、改善できないかと思って話してみたんだけど、
Pythonな人は「Pythonのやり方こそ正しい」としか言わないから
てんで話にならない。

82 ：デフォルトの名無しさん：2010/10/27(水) 01:10:47

>>81
そりゃ、言語設計者はポリシー持って言語仕様をコントロールしないといけないから、
受け入れられない要求に対しては「（Pythonでは）Pythonのやり方こそ正しい」としか
言わないだろうな。

83 ：デフォルトの名無しさん：2010/10/27(水) 01:11:23

Pythonを変更せずに他の言語を使ってくれることを祈る

84 ：デフォルトの名無しさん：2010/10/27(水) 01:14:50

おまいらこれの
ttp://www.amazon.co.jp/dp/4873114713/
pythonの章は読んだ？

85 ：デフォルトの名無しさん：2010/10/27(水) 01:17:02

式としてのループはあるけど、変数スコープが1周限りなのが、複雑になってる原因。
これでもっと単純になる。
def my_reduce(f, xs, init):
　a = [init]
　return [a.append(f(a[i], x)) or a[-1] for i,x in enumerate(xs)][-1]

86 ：デフォルトの名無しさん：2010/10/27(水) 01:24:32

>>82
「Pythonな人」を「言語設計者」と読み違えるおまえの頭に乾杯、いや完敗。

87 ：デフォルトの名無しさん：2010/10/27(水) 01:26:57

>>85
Pythonでもわかりにくいコードはいくらでも書けるという、わかりやすい例だな。

88 ：デフォルトの名無しさん：2010/10/27(水) 01:30:32

>>85
おーすげー！
上の方で煽ってたのは俺だが、その発想は俺にはなかった
が、xs.append(y) or xsとかなら、Pythonでは貧者のconsとしてたまに使うな
（consをそう書かなければならない時点で既にヤバいと思うが）

89 ：デフォルトの名無しさん：2010/10/27(水) 01:30:50

>>86
え？言語拡張の話を言語設計者の居ない所で提案してたの？
回答が何であっても生産性ゼロだよね。何がしたかったの？

90 ：デフォルトの名無しさん：2010/10/27(水) 01:35:51

○○厨・信者（○○は言語名）ってレッテル張りはあまり好きじゃないんだけど、
RubyとPythonの言い争いは一般人の同属嫌悪的な雰囲気なのに対して、
Lispの人が全く異物な概念を連れてきて、「Lispのように書けないRuby/PythonのXXは粗悪だ」
って言うのは、何か宗教じみたものを感じてしまう。

91 ：デフォルトの名無しさん：2010/10/27(水) 01:36:17

>>73
lambdaは関数だから基本的には値を返すべきものだとは思うが。
def raise_func(ex):
　raise ex
みたいな関数は、用意してくれててもいいよね。
クラスに使うこと考えたら
def raise_method(self, ex):
　raise ex
になるから、用意するってのも微妙なのかもしれんが。

92 ：デフォルトの名無しさん：2010/10/27(水) 01:40:30

>>90
そいつらはこっちで頑張って欲しいよね
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1286791669/

93 ：デフォルトの名無しさん：2010/10/27(水) 01:42:55

>>90
俺のことを言ってるんなら、別に俺はLispの人じゃないよ！
勘違いしないでね！
大体Lispの人だったらlambdaとかタイプすんのうぜーとか言わないよ
どこの自虐ギャグだそれ

94 ：デフォルトの名無しさん：2010/10/27(水) 01:43:47

はいはい、scalaやgroovyだよね！ｗ同じだボケ

95 ：デフォルトの名無しさん：2010/10/27(水) 01:47:01

えーん>>94がいぢめるぅ

96 ：デフォルトの名無しさん：2010/10/27(水) 01:49:45

>>88
> （consをそう書かなければならない時点で既にヤバいと思うが）
cdrをxs[1:]と表現すると、リストのコピーになってしまうのはもっとヤバい。

97 ：デフォルトの名無しさん：2010/10/27(水) 01:51:17

>>96
うむ。コピーでいいんなら、consもxs + [y]でいいんだけどいちいちコピーすんな
ボケぇ！

まあ
[x, [y, [z,....]]]
とか書いてもいいが禿げしくうざくて禿げそうだ
こんなんやってもmapとかfilterとか使えないし

98 ：デフォルトの名無しさん：2010/10/27(水) 01:51:50

思考停止

99 ：デフォルトの名無しさん：2010/10/27(水) 01:52:17

ああxs + [y]っていうか普通にあわせるんなら
[y] + xsね

100 ：デフォルトの名無しさん：2010/10/27(水) 02:11:03

Scalaって関数型っぽく書くと全然JVMの速度生かせないから、関数型っぽく書いて
「俺カッコイイ」ってのとJavaっぽく書いてJVMの効率上げるのとのバランスで悩む言語という
認識であってる？
Pythonの人がScalaやったら、「再起じゃなくてループでいいじゃん。可読性良くて効率良いし」
って言って、ただの書きやすいJavaにしかならなさそう。

101 ：デフォルトの名無しさん：2010/10/27(水) 02:19:02

>>100
俺はScalaの人では無いから知らんが、俺なら多分悩むだろうな
関数型っぽくどころか、ただのforループもScalaのは遅かった
もっとも性能が大事な部分はいっそJavaで書いてもいいし、JVMや.NETの言語は
Python + Cの100倍は容易に連携できるのだから、それで
問題はなさそうにも思える

あーあとJVM言語は末尾再帰は全部無意味だよ
Clojureは仕方が無いので末尾再帰を最適化してほしい場合は
recurで明示するようになっている

102 ：デフォルトの名無しさん：2010/10/27(水) 02:28:59

Scalaの人じゃんｗ

103 ：デフォルトの名無しさん：2010/10/27(水) 02:30:16

ちょ、ちょっとだけ使ったことがあるだけなんだから！
ス、スカラの人なんかじゃないんだもん！

104 ：デフォルトの名無しさん：2010/10/27(水) 02:33:56

Scalaのforって
C系言語のプリミティブなforとはまるで別物じゃなかったっけ

105 ：デフォルトの名無しさん：2010/10/27(水) 02:36:39

>>104
そうそう、だから遅い

つってもJavaだと
for (x: xs) {}
をxsが配列や何かの場合はプリミティブなforに展開するので、同じぐらい速いのだが

106 ：デフォルトの名無しさん：2010/10/27(水) 02:44:16

>>105
拡張forは単なる頻出処理のショートカット、
シンタックスシュガーだから
それはまたちょっと別の話じゃないのかなあ

107 ：デフォルトの名無しさん：2010/10/27(水) 02:47:27

>>106
うん一緒にしちゃあ可哀想なんだが、ScalaではJavaのfor並に速いループを
書きたければ、現状while()を使うしかなくて、Javaより酷いコードになるのがね

108 ：デフォルトの名無しさん：2010/10/27(水) 02:52:38

ループのオーバーヘッドまで気にするなら、LL使っちゃダメだと思う。

109 ：デフォルトの名無しさん：2010/10/27(水) 04:30:22

ScalaはLLかよ

110 ：デフォルトの名無しさん：2010/10/27(水) 07:48:46

>>109
少なくともJavaよりはLL

111 ：デフォルトの名無しさん：2010/10/27(水) 08:32:33

P言語よりはLLじゃない

112 ：デフォルトの名無しさん：2010/10/27(水) 09:04:07

RubyとScalaって似てると思うんだけど、そうでもない？
Pythonって後続で似てる言語ってあるのかな

113 ：デフォルトの名無しさん：2010/10/27(水) 09:06:50

Rubyはヘビー言語

114 ：デフォルトの名無しさん：2010/10/27(水) 09:48:17

Scala が Ruby に似てるって言うと Matz が喜ぶらしいお

115 ：デフォルトの名無しさん：2010/10/27(水) 09:59:59

>>89
>え？言語拡張の話を言語設計者の居ない所で提案してたの？
ええええーーー？なんで「提案」になるの？
たんに、こうできたらいいよね、とヨタ話してるだけじゃん。

>回答が何であっても生産性ゼロだよね。何がしたかったの？
知り合いとだべってるだけなんだけど、>>89にとっては生産性ゼロなんだろうね。
ああそうか、友達がいないから他人との他愛ない会話が「生産性ゼロ」なんて思うのだろう。
今日も話し相手を求めて2chにやってくるPython信者乙。前スレでは大活躍だったね。
現スレもよろしく！
あとおまえのtwitterでのつぶやきも生産性ゼロってことに気づこうぜ。

116 ：デフォルトの名無しさん：2010/10/27(水) 10:08:47

生産性ゼロの2chで暴れてる人って童貞

117 ：デフォルトの名無しさん：2010/10/27(水) 10:42:02

自分の意見が他の言語のポリシーに合わないからといってその言語ユーザーにレッテル張りし出す人って・・・

118 ：デフォルトの名無しさん：2010/10/27(水) 10:45:04

結局、lamdaで文をかけない事が書きやすさに影響を与えるケースって、
>>73 のように短い文1つの関数を一行で書きたいケースのみって事でFA？

119 ：デフォルトの名無しさん：2010/10/27(水) 10:56:07

>>118
例えばCやJavaのような言語でいちいちブロックに全部名前つけろと言われたら嫌だろう
というか俺は嫌だ

(1..10).each {
　これをする
　あれをする
}
みたいなのに、いちいち名前をひねりだしてつけたくない

Rubyのブロックつきメソッドのようなものの記述力は、高階関数を
CやJavaのブロックのように水や空気のように使える構造として
容易に書けるようにしているから多用されている
（高階関数のeachがforループと同じぐらいの感覚で書けるのが分かるだろう）

少なくともPythonのlambdaはそれを拒み、より抽象度の低い書きかたに
ユーザを導く

120 ：デフォルトの名無しさん：2010/10/27(水) 11:13:17

名前考えるのが面倒とか，おまえ開発者やめろよ(www

121 ：デフォルトの名無しさん：2010/10/27(水) 11:18:11

>>119
要約すると、名前つけたくないのね。
1つの文に複数の処理を詰め込まない。文を分けて名前を付ける。っていうのはPythonの
ポリシーだから、どうしても無名が良い人にはPythonは合わないかもね。

>（高階関数のeachがforループと同じぐらいの感覚で書けるのが分かるだろう）
逆に言えば、eachが使いにくくてもforループでも同じくらい楽に書けるよね。
lamdaのせいで書きにくくなっている例としては不適切。

122 ：デフォルトの名無しさん：2010/10/27(水) 11:21:48

> （高階関数のeachがforループと同じぐらいの感覚で書けるのが分かるだろう）
そのeachがforループと同じくらいの記述能力しかないなら、そうできることに意味はないんじゃないの？

array.each {
　statements...
}
が
for a in array:
　statements...
に比べて勝っている点ってどこにあるのよ？

確かにPythonは、lambdaで文を処理することを意図的に拒んでいる。
多少の記述力を犠牲に、読みにくいコードになることを避けようとしている。

なので、単純に、記述力の大小でいうとPythonの記述力が低いことは疑う余地がないし、そこで戦うつもりはないよ。
Python使いの主張は、こうだ。
そう記述できないことで、失ったものもあるが、それ以上のものを得ている。

123 ：デフォルトの名無しさん：2010/10/27(水) 11:25:55

名前をつけるまでもない関数を多用するだろうし、したい、というのが、Lisp発明以来の
関数型プログラミングの知見なわけで、それに真っ向から背を向けているのが
Pythonのポリシーであり、GvRがそれを是としている、ということだと私は理解しているが。

124 ：デフォルトの名無しさん：2010/10/27(水) 11:29:35

>>121
> 要約すると、名前つけたくないのね。
そう。というか、さっきも言ったが、

function loop_body(i) { print(i) }
for (i = 0; i < 10; ++i) loop_body

とか単にブロックを書くかわりに毎度毎度書かされたら嫌だろう
それと同じことだよ

>>122
高階関数にループしかできないと思ってるんなら、意味が無いようにしか
見えないかもな
高階関数は、ループ以外の色んなものを抽象化できる
Rubyでは、その抽象を組み込みループのようなものと
大差ない感覚で利用できるようになっている

125 ：デフォルトの名無しさん：2010/10/27(水) 12:06:30

>>124
Schemeもちょっとはかじった人間だから、高階関数だけで何でもできることだって知ってるよ。
けど、lambda式で文が書けないだけで高階関数はPythonでも使えるし、
Schemeでも複雑な関数だと入れ子にしないでletの中に書くことだってある。

lambda式の記述力の低さがすごく辛く感じられる場面って、どれくらいある？

126 ：125：2010/10/27(水) 12:09:58

高階関数だけで何でもできるって何だよ...
できなくもないかもしれんが「関数だけ」に訂正した方が無難ですね。スマソ
0のかわりにlambda f,z: z使うんですか？とか意地悪いわないでね。

127 ：デフォルトの名無しさん：2010/10/27(水) 12:38:53

>>125
うーむ……可能不可能の話ではなくて、要は快不快の話でしかないので、
平行線かもな

Schemeでは
(with-input-from-file foo (lambda () (....)))
とか書く
groovyなら
new File(foo).eachLine { ... }
とか書くだろう

Pythonにはこれに相当するものは一応あるが、それは高階関数じゃなくて
withステートメントだ
with open(foo) as f: ～

あれは、要はlambdaがまともなら本来不要な代物で、不便だから導入されたんだろう
（たぶんね）
だが、withは中途半端で、withのボディは決めうちで一回走るだけだ
つまり、新たな構文要素まで導入したのに、高階関数に柔軟性において
劣ってるんだよ

128 ：デフォルトの名無しさん：2010/10/27(水) 14:02:59

高階関数の方がメタで汎用的なのには同意。

Pythonは単に、高階関数が役に立つ場面の殆どを別のもっと具体的で効率の良い
構文に割り当ててるだけ。メリットは速度と可読性。

あと、 >>127、 eachLine {} よりも with の方が行単位アクセス以外にも使えて汎用的だろ。

129 ：デフォルトの名無しさん：2010/10/27(水) 14:08:10

>>128
あー。適当に書いたけど、eachLine {}は正確には対応してないね
new File(foo).withInputStream { f -> ... }
とでも読み替えて

130 ：デフォルトの名無しさん：2010/10/27(水) 14:17:48

> メリットは速度と可読性
これは全く同意できない

lambdaがそんなに嫌ならPythonのwithはRubyのブロックつきメソッドと
同等の機能を提供することも可能にできたはずで、可読性も劣らないだろうが
実際にはRAIIでしかない

それに、
new File(foo).withInputStream { f ->
　...
}
が可読性において劣るか？

速度が理由ってのはマジならお笑いだ
整数の足し算するにもいちいちオブジェクト作ったり消したりしてんのに
高階関数における関数呼び出しのオーバーヘッドなんて、それこそどうでもいいだろう

131 ：デフォルトの名無しさん：2010/10/27(水) 14:42:26

>>130
そのケースだと可読性に差は無いな。
無名関数を許すと可読性の悪いコードが生産されやすいという程度の問題。

それと、関数呼び出しのオーバーヘッドって、オブジェクトの生成＆破棄に比べて大きいよ？
C++とかインライン展開ができる言語だったり、スタックフレームの生成がすごく軽量な言語では
ともかく、Pythonではオブジェクト生成の方が軽い。

132 ：デフォルトの名無しさん：2010/10/27(水) 14:47:47

>>131
だから、整数の足し算ってオブジェクト作ったり消したりする
だけじゃなくて、メソッド呼び出しもするだろう
まさかループの中でやる仕事がオブジェクト作ったり消したりする「だけ」
なんてことはないよね？普通

それに遅くなるから便利であっても××の機能は提供しない云々は、
俺に言わせればプログラマを舐めきった余計なお世話
遅くてもいい場所で便利な××の機能を使うユーザの自由はあってしかるべきだし、
そもそも遅いのが気になるぐらいなら最初からPythonなんか使わないぞ

133 ：デフォルトの名無しさん：2010/10/27(水) 14:55:31

Rubyのeachとloopを比べてみた。
Pythonはeachに相当する機能が無かったからループだけやった。
http://paste.bradleygill.com/index.php?paste_id=58965

>>132
だから、ループ以外にPythonでは上手く書けない便利な例を出してって。
ループだとムダに遅くなるだけで、まったく便利じゃないんだから。

134 ：デフォルトの名無しさん：2010/10/27(水) 14:57:43

ちなみに俺は以前実行時間を計ったことはあるが、
Pythonでループをreduce()で書きなおしたところで、他の言語に比べれば
大した問題になるとは思えなかった
ただのループが十分過ぎるほど遅いからだ

これがScalaとかなら話は別で、関数呼び出しの差が大きな性能の違いとなって出てくる
だからC++のインライン化は本質的に重要だ

ま、PythonでもPsycoかませば別だが、まさかPsyco前提とも考えにくい

135 ：デフォルトの名無しさん：2010/10/27(水) 15:02:20

おっと>>133を見ていなかったｗ

> だから、ループ以外にPythonでは上手く書けない便利な例を出してって。
だから、不便なだけで、Pythonでも書けるよ？
当たり前だろう、Pythonには高階関数があるのだから

出来る出来ないではなく、
>>124
で書いたような気持ち悪さを許容するかどうかの問題でしかない

もっともPythonユーザも不便と感じたようだから、>>130のように
高階関数として書けるもののために、わざわざwithをひねりだした
だがwithではRAIIしかできないのだから、不十分だと言ってるんだよ

136 ：133：2010/10/27(水) 15:05:49

おっと、Ruby1.9.1 ならeachの方が若干速いな。
それでもPythonのループより5倍遅い。>>133のコードって何か余計なことしてる？

137 ：デフォルトの名無しさん：2010/10/27(水) 15:07:55

>>136
PythonとRubyの性能を比べても仕方が無いだろ
ここではPythonで高階関数を使うと致命的に速度が低下するかどうかを
問題にしているのだから、
Pythonでforとreduceの差を測れば十分

138 ：デフォルトの名無しさん：2010/10/27(水) 15:08:03

>>133
Ruby遅！

139 ：133：2010/10/27(水) 15:10:20

あ、ループ回数が違ったww

140 ：133：2010/10/27(水) 15:14:28

http://paste.bradleygill.com/index.php?paste_id=58968
Ruby 1.9 と Python 2.6 なら大して違わなかった。スマソ。

141 ：133：2010/10/27(水) 15:26:05

>>137
致命的に、なんて誰も言ってない。
ループの方が読みやすいと感じる人が多くて、ループの方が若干性能が良いなら、
ループだけで十分だよね、という話。PythonはRubyやPerlと違って書き方を幾つも
準備する言語じゃないから。

一応、reduceとloopの差を計測してみた。大体3倍だけど、今度はreduceがRubyのeachより
遅くなってる。Pythonの関数呼び出しが重いのか、Rubyのブロックが関数呼び出しより軽く
実行できる仕組みになってるのか、どっちだろ。
http://paste.bradleygill.com/index.php?paste_id=58969

142 ：デフォルトの名無しさん：2010/10/27(水) 15:35:02

> PythonはRubyやPerlと違って書き方を幾つも準備する言語じゃないから。

本来ならlambda一つで十分なもののために
異常に用途の限定された専用構文withを作ったわけだろう？
同様に、map()やfilter()はあるが、リスト内包も生み出した

むしろ逆だと思うけどな

143 ：デフォルトの名無しさん：2010/10/27(水) 15:39:45

最近のPythonはTOOWTDIではなくなってるという気はするね。

144 ：133：2010/10/27(水) 15:50:56

訂正する。「推奨される」書き方は一つしだけなのがPython。
書き方が一つしかない言語なんて汎用言語ではあり得ないだろ。。。

145 ：133：2010/10/27(水) 15:55:25

> うーむ……可能不可能の話ではなくて、要は快不快の話でしかないので、
> 平行線かもな

なんだ、結論に自分でも気づいてるんじゃないか。
Pythonは何でもlamdaで書いてしまうのが不快と考えて設計されている。
何でもlamdaで書きたい人はPythonに合わなくて当たり前。
劣っているとかそういう話じゃない。

146 ：デフォルトの名無しさん：2010/10/27(水) 17:07:12

>>141
lambda x,y: x+y
じゃなくて
operator.add
だったらどう？

147 ：133：2010/10/27(水) 17:20:38

>>146
もちろんC言語の関数だからPythonのスタックフレーム用意する必要なくて高速になるけど、
今話題にしているのは任意の関数を呼び出すことだから、 lambda で計測しないと意味無いよね？

148 ：デフォルトの名無しさん：2010/10/27(水) 17:58:04

Pythonのlambdaの最大の問題点はifが文なせいで分岐が書けないことじゃね？
関数型のそれや、名前付きなら書けるのに…

149 ：デフォルトの名無しさん：2010/10/27(水) 18:12:31

>>148
x if test else y
みたいな奴の話じゃなくて？

マジレスするとな、最大の問題点はタイプしにくいことだ
lamdaでこのスレを検索してみるといいぞ

150 ：デフォルトの名無しさん：2010/10/27(水) 18:17:02

>>149
2.5で3項演算付いたのか、知らんかったスマン
…ちょっと実装が遅い気もするけど、まあいいや

151 ：デフォルトの名無しさん：2010/10/27(水) 18:20:52

def loop():
    for i in xrange(1000):
        sum = reduce(lambda x,y: x+y, xrange(10000), 0)
loop()

def loop():
    def add(x, y):
        return x + y
    for i in xrange(1000):
        sum = reduce(add, xrange(10000), 0)
loop()

後者がちょっとだけ速い

152 ：デフォルトの名無しさん：2010/10/27(水) 18:31:39

>>150
こんなん後付で作るぐらいなら最初からifを式に汁！とか思うよな
だが

if True:
　operator.add
else:
　operator.sub
(1, 2)

とか書くのは無理目だから仕方が無いのだろう
Pythonが文だらけなのは、}やendや)))))))))を書かなくていい代わりの
負債なのだと思う

ところで予約語なのにPythonユーザによって名前を間違えられまくっている
ラムちゃんに対する賠償とか謝罪とかツッコミはないのか！！

153 ：133：2010/10/27(水) 19:10:36

はいはい、typoしてごめんなさい。
普段lambdaなんて使ってないから手が覚えてないのよ。
vimならコードハイライトしてくれるからそれでハマることはないんだけどね。

154 ：デフォルトの名無しさん：2010/10/27(水) 19:14:37

ジエンしてるんだから言っても無駄だよ。
書いてる内容に全く変化が無いだろ？自分の知識の範疇から抜けだした解説が出来ないからね。ｗ

155 ：デフォルトの名無しさん：2010/10/27(水) 19:14:44

>>153
> 普段lambdaなんて使ってないから手が覚えてないのよ。
実際、そうなんだろうなと俺は思っていたぞ

lambdaをそもそも使わない人には
lambdaつかえねーだりーと言っても通じるわけはないんだ
俺はstructがあまりに手に馴染んでいるから
abstractをよくabstructと書いてしまうんだが

156 ：デフォルトの名無しさん：2010/10/27(水) 19:19:52

labmdaはまだいいんだ
-er と -or の使い分けは死ねる

>>152
文だらけだけど
if (ch = "\n") ... ではまらなくなったり一行が短くなったりで
メリットは拾っていけば結構あるんじゃないか
式指向の言語は一行80文字に収まらなくて汚くなりがち

157 ：133：2010/10/27(水) 19:25:39

>>155
あと、vimだとlamまで入力したら C-p で補完してるな。
だから、lambdaって最後まで手で書くのって2ちゃんに書き込むときか、IPythonじゃない
インタラクティブシェルを使うときぐらい。

常に単語補完を使うと、typoで変数名間違えて悩むことが無い。

158 ：デフォルトの名無しさん：2010/10/27(水) 19:43:27

>>156
-er と -or の使い分けは死ねる
禿同！
マジ死ねる

> if (ch = "\n")
これはJavaやC#のように、ifのtest式は厳密にboolean値しか
認めないようにすればいいだけだと思う

まあ、Cでも、gccはwarning言うよね
if (p = strchr(s, '\n')) *p = 0;
みたいな正当な場合にも文句言ってくるので
()を余計につけたりする必要があってウザいけど

159 ：デフォルトの名無しさん：2010/10/27(水) 20:45:29

液パイのmeなんとかが混じってるな

160 ：デフォルトの名無しさん：2010/10/27(水) 21:23:15

>>77
その例の場合、わざわざプロシージャ使わなくても
x > 0
でいいんじゃないの？という意見もあったりなかったり

161 ：デフォルトの名無しさん：2010/10/27(水) 21:29:13

あ、
xs > 0
の間違い

162 ：デフォルトの名無しさん：2010/10/27(水) 22:26:42

俺はPython使いではないけど、Schemeをちょっと前にかじって
そんときにlambdaのスペル間違えまくったな確かにw
あれは打たないと覚えないと思うわ

163 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/10/27(水) 22:27:01

ねずみ野郎は死ねってw

164 ：デフォルトの名無しさん：2010/10/27(水) 22:31:45

>>150
それついたのも、Pythonの複雑な式やだやだ精神からだろうなぁ。
もともと複雑だから付けなかったけど、andとorで強引にやる方法があるので、付けることになったんだと思う。
根拠はない。ただの推測。

165 ：デフォルトの名無しさん：2010/10/27(水) 23:55:57

なんか普通の奴らの上を行けみたいな、
上いってるやつといってないやつの会話を見てるようだぞw

166 ：デフォルトの名無しさん：2010/10/28(木) 00:16:02

上見て暮らすな下見て暮らせ

167 ：デフォルトの名無しさん：2010/10/28(木) 01:05:44

上下逆転してるやつがいる

168 ：デフォルトの名無しさん：2010/10/28(木) 01:10:20

Pythonは普通の奴らのための言語だからな。

169 ：デフォルトの名無しさん：2010/10/28(木) 01:22:01

Lisperウゼーｗ

170 ：デフォルトの名無しさん：2010/10/28(木) 01:45:25

関係代名詞とか多様すれば、英語の文章って1文にまとめられたりするのかなぁ？
それがわかりやすいとは思えないけど、できたらすごいよね。

171 ：デフォルトの名無しさん：2010/10/28(木) 01:55:40

Python is a general-purpose high-level programming language whose design philosophy emphasizes code readability.
Python aims to combine "remarkable power with very clear syntax", and its standard library is large and comprehensive.
Its use of indentation for block delimiters is unusual among popular programming languages.

Python使いが文章を書いたなら
Python is a general-purpose high-level programming language.
Python is designed philosophy emphasizes code readability.
Python aims to combine "remarkable power with very clear syntax"
Python's standard library is large and comprehensive.
def use_of_indent():
　use of indentation for block delimiters
Python's use_of_indent() is unusual among popular programming languages.

やべーwwwちょーよみやすいwww

172 ：デフォルトの名無しさん：2010/10/28(木) 02:01:35

頭悪そう

173 ：デフォルトの名無しさん：2010/10/28(木) 02:33:00

>>171
英語の苦手な俺には下の方が読みやすい。
誰かの言ってた他言語ユーザーの読みやすさってこういうことなんだなｗｗ

174 ：デフォルトの名無しさん：2010/10/28(木) 03:24:48

上のならともかく、これを無理に1文にしようと思ったらどうなることか。

175 ：デフォルトの名無しさん：2010/10/28(木) 06:59:27

Pythonでlambdaに不自由を感じるのはしょっちゅうだけどなあ。
filenames = glob.glob('*.html')
def tmp(name):
　m = re.search(r'(¥w+)-(¥d+)', name)
　return m.group(1), int(m.group(2))
filenames.sort(key=tmp)
うーん今いち。いちいち関数定義を書かなきゃいけないし、テンポラリな関数がsort()より先に来ちゃうし。
できればテンポラリな関数よりメインの処理であるsort()が先に来てほしいよね。
filenames = Dir.glob('*.html')
filenames.sort_by! {|name| name =~ /(¥w+)-(¥d+)/ and [$1, $2.to_i] }
こっちのほうが自然に頭から読み下せる。
他の関数言語なら、いちいちテンポラリな関数を定義しなくて済むし、テンポラリな関数より
メインの処理となる関数名のほうが先に出てくるから、理解しやすい。
それに慣れるとPythonのやり方は不自由を感じる。
こうとか本当に書けないのかな。
filenames.sort(key=lambda name:
　m = re.search(r'(¥w+)-(¥d+)', name)
　return m.group(1), int(m.group(2))
) 
>>127
Pythonエキスパート(と書いて信者と読む)は何をいっても聞く耳持たないって。
前スレでわかっただろ？相手するだけ無駄。
> あれは、要はlambdaがまともなら本来不要な代物で、不便だから導入されたんだろう
同意。ほんとは要らないはずなんだよな、あんな機能。

176 ：デフォルトの名無しさん：2010/10/28(木) 07:50:20

つーかPythonのlambdaをこねくり回そうとしてるのPythonユーザーじゃないだろ
もう別の言語使えよ。使い分けも出来んのか

177 ：デフォルトの名無しさん：2010/10/28(木) 08:01:15

>>176
> Pythonのlambdaをこねくり回そうとしてるのPythonユーザーじゃないだろ

複数のLL同士を比較するスレで、Pythonの欠点について話してるんだから
むしろ非Pythonユーザも入って来るのが当たり前だろ
Pythonista同士でやるなら本スレでやればいい話

そして別の言語使え、はちと暴論すぎる。
「名前付けろ」ぐらいならまだ解らんでもないんだが。

178 ：デフォルトの名無しさん：2010/10/28(木) 08:11:44

ああ、Pythonのことを知らないんだね

179 ：デフォルトの名無しさん：2010/10/28(木) 08:11:53

>>175
一次関数の名前をtmpじゃなくてorderとかにすれば軽減される話ではあるけど、
確かにその例ではRubyの方が頭から読み下せて好ましいね。
Pythonの場合だと、関数内で定義された関数を一旦読み飛ばして、どう使われて
いるかを把握してから内部関数を読まないといけない。

でも、関数の引数の中で関数を定義するのは、 reverse=True みたいにオプショナルな
別の引数もとる場合は読みにくくならない？sortならkey自体がオプショナルだからkeyを
最後に持っていけるけど、高階関数が第一引数として必須な場合もあるんだしさ。

「こう書きたい」っていう話は判るけど、Pythonとしては推奨する書き方を1つにしたくて、
数行の処理が必要で、引数の中に直接書いた方が読みやすいってのはレアケースだから
名前付き関数を推奨してる。

180 ：デフォルトの名無しさん：2010/10/28(木) 08:12:54

結局、自分が信仰する言語のために良く知らない他宗教を攻撃してるだけ。アーメン

181 ：デフォルトの名無しさん：2010/10/28(木) 08:19:46

ああ、Pythonに慣れるとendendendが邪魔邪魔邪魔！

182 ：デフォルトの名無しさん：2010/10/28(木) 08:21:04

>>181
endの面倒さはselfの面倒さとほぼ等価なので、そこを叩き合っても無限ループだけどな。

183 ：デフォルトの名無しさん：2010/10/28(木) 08:23:17

lambdaの話はPythonの開発者がちゃんと議論したうえで、by design で with を導入したんだから、
ここで否定しているやつらはPythonの設計者の意図に聞く耳持たない奴だけだろ。
Python信者が他の言語のユーザーの意見に聞く耳持たないって言う前に、自分がPythonの設計意図に
聞く耳を持てよ。

184 ：デフォルトの名無しさん：2010/10/28(木) 08:28:05

>>175
filenames.sort(key=lambda name:
(lambda m:
(m.group(1), int(m.group(2))))(re.search(r'(\w+)-(\d+)', name)))

書けなくもない…が、ますます読めないなw
名前付きのほうがまだ読みやすそうだ
（ところでこのコード、マッチしないファイル名あったらどうすんだw）

>>179
引数の中に直接書くのが読みにくくて名前付き関数を推奨してるなら
lambda自体の存在理由が無くないか？
実際、使う場面が無いだろあれ。俺もdef以外でやることまず無いし。
正直（特に関数型出身者を）混乱させるだけの仕様だと思う。最初からdefしか無いなら迷わないし。

185 ：デフォルトの名無しさん：2010/10/28(木) 08:30:17

>>183
むしろ、設計者がlambdaを導入した意図を知りたいな。

>>181
そうだね、endが多くなると邪魔だね。
…で、それが邪魔だとlambdaはどう良くなるんだ

186 ：デフォルトの名無しさん：2010/10/28(木) 08:31:12

> lambdaの話はPythonの開発者がちゃんと議論したうえで、by design で with を導入したんだから、
> ここで否定しているやつらはPythonの設計者の意図に聞く耳持たない奴だけだろ。
> Python信者が他の言語のユーザーの意見に聞く耳持たないって言う前に、自分がPythonの設計意図に
> 聞く耳を持てよ。

聞く聞かないのレベルが全然違う話を混同すんなよw

187 ：デフォルトの名無しさん：2010/10/28(木) 08:32:00

>>183
lambdaの場合は単に「式の中に文を書けない」って制限のデメリットだけどな。
式と文をごっちゃにしてたら問題なかった。

188 ：デフォルトの名無しさん：2010/10/28(木) 08:33:26

>>184
さすがに、 x * 2 + 1 とか、超シンプルな式までいちいちdefでやらせるのは面倒すぎだろ。

189 ：デフォルトの名無しさん：2010/10/28(木) 08:43:58

>>188
seqfunc(lambda x: x*2+1, seq)

def f(x):
return x * 2 + 1
seqfunc(f, seq)

…俺なら後者選ぶなあ。
それほど面倒さは変わらないし、後でちょっとだけ変更したい時に
lambdaじゃ無理になって書き直すほうが面倒だ。

190 ：methane：2010/10/28(木) 08:44:25

Twitter上で反応の欲しかった個人的な感想を前スレで晒されて、しかも反対意見を
ちゃんと聴いてたのに聞く耳持たない奴認定されて、、、あんまりだ。

191 ：デフォルトの名無しさん：2010/10/28(木) 08:46:49

>>190
不特定多数に反応を求めた時点で、そんなことは普通に想定できる話。
想定が甘かったな。

192 ：methane：2010/10/28(木) 08:57:28

lambda は他のLLに比べてPythonの制限がきつい一つの例だと思う。
特にスクリプト言語としてPythonを見ている人にとっては >>175 みたいなちょっとした
ストレスの積み重ねがキツイだろうね。

193 ：デフォルトの名無しさん：2010/10/28(木) 09:08:28

やっぱ廃止で良いと思うよPythonのlambda

194 ：デフォルトの名無しさん：2010/10/28(木) 09:19:20

>>175
lambdaで書けるよ。それ。
読みにくくなるから書きたくないけど。

withはlambdaがないからじゃなくて、入る・出るの機能の抽象化としてできた。
lambdaがあると本来必要ないはずのものは多いけど、
例えばlambdaがあったらintいらないとは(効率の問題を無視したとしても)全く思わないなぁ。

195 ：デフォルトの名無しさん：2010/10/28(木) 10:17:17

>>179
>でも、関数の引数の中で関数を定義するのは、 reverse=True みたいにオプショナルな
>別の引数もとる場合は読みにくくならない？
ならねーよ。読みにくくなるような設計にしてるのがまずいとは思わないのか。

> sortならkey自体がオプショナルだからkeyを
>最後に持っていけるけど、高階関数が第一引数として必須な場合もあるんだしさ。
そんな設計にしてるのがまずいってだけだろ。
・クロージャを第1引数にもってこなくてすむRubyやGroovy
・関数が最初の引数になっても違和感のない関数型言語
いいかげんPython信者はほかの言語けなすまえにそれらを勉強しろや。

196 ：デフォルトの名無しさん：2010/10/28(木) 10:20:28

ていうか、どんな言語でもラムダ実装してりゃ、引数の順番くらいかえれるだろ。
f(x, y)
(lambda y, x: f(x, y))(y, x)

197 ：デフォルトの名無しさん：2010/10/28(木) 10:24:00

>>194
foo(..) {|bar|...}
with foo(..) as bar: ...

withとブロック付きメソッドは可読性において変わらないし
コンテキストマネージャとブロック付きメソッドを実装する場合、その実装の
手間も変わらないどころか、中身はほとんど同じものになるのだから
チャーチ数のような極論を持ち出すのはどうかと思うが

198 ：デフォルトの名無しさん：2010/10/28(木) 10:25:17

>>181
あれだな、旗色が悪くなると他の言語の別の欠点をとりだして話の流れを変えようとしているんだな。なるほど。信者らしい行動だ。
バトルすれだし、いいぞもっとやれ。

>>194
>lambdaで書けるよ。それ。
>読みにくくなるから書きたくないけど。
じゃあ意味ないじゃん。

> 例えばlambdaがあったらintいらない
まるで意味不明。

199 ：デフォルトの名無しさん：2010/10/28(木) 10:27:59

引数の順番はカリー化を多用する／デフォでカリー化されてる言語だと
わりと重要だわな
ま、>>196の言うとおりに、自分でどうとでも出来るけど

Rubyのブロック付きメソッド（groovyなどもパクっている）の場合は
ブロック／クロージャ引数が最後の場合に、それが特別扱いされる仕様だね

200 ：デフォルトの名無しさん：2010/10/28(木) 10:29:43

>>195
Pythonのlambdaを強力にしたらって仮定の話をしてるだけで誰もRubyを貶してないよ。

201 ：デフォルトの名無しさん：2010/10/28(木) 10:29:58

上に出てたreduceの実装だって、ラムダでできる。
my_reduce = lambda f, xs, init: (lambda a: [a.append(f(a[0], x)) or a.pop(0) for x in xs][-1])([init])

残念ながら、例外の発生は、別の例外を発しうる処理を利用する以外にはlambdaじゃできない。
けど、いわゆる普通の計算はlambdaで十分できるはず。

202 ：デフォルトの名無しさん：2010/10/28(木) 10:30:52

>>197
「with文は可読性が悪い」とか「実装のためがかかる」とはだれも言ってない。
たんに「関数言語ばりのlambdaがあればwith文はいらないはず」と言ってるだけ。
ほんと話をずらすのが好きだな。というか、相手のいいたいことがわからないだけか。
アスペ乙

203 ：デフォルトの名無しさん：2010/10/28(木) 10:32:35

>>202
ちょっと待てｗｗｗ
いきなりアスペ扱いか

> ほんと話をずらすのが好きだな
って俺を誰だと思ってるんだか知らないが、なぜそんなに喧嘩腰？

204 ：デフォルトの名無しさん：2010/10/28(木) 10:38:13

バトルロワイヤルというスレタイが見えないとでも？

205 ：デフォルトの名無しさん：2010/10/28(木) 10:41:09

>>197
そこまで分かってるなら、Pythonはあえてブロック付きメソッドを拒否してることにも気づいてるんだろ？

206 ：デフォルトの名無しさん：2010/10/28(木) 10:41:42

>>204
いやそうじゃなくてさ、どーも>>202は何か勘違いしてると思うんだよな

>>197は俺が今日始めてつけたレスだし、俺のレスの意図も読み違えてると
思うんだわ
>>202は少し冷静になったほうがいいよ

207 ：デフォルトの名無しさん：2010/10/28(木) 10:41:52

>>203
> 俺を誰だと思ってるんだか知らないが
そりゃしらねーよww

208 ：methane：2010/10/28(木) 10:42:05

>>202
「関数言語ばりのlambda」をブロックとして使いやすく実装したのがRubyで、その頻出する用途を
直接構文でカバーしたのがPythonというだけだよね？

元の話題は、「Pythonのlambdaは文が使えないから不便だ」というものなので、
「Pythonの○○はlambdaが強力だったらlambdaでできるよ」じゃなくて、
「lambdaが強力だったらできる○○が今のPythonじゃ面倒だよ」という指摘をしないと的外れだと思う。

>>73 とか >>175 の指摘の方が的を射ている。

209 ：デフォルトの名無しさん：2010/10/28(木) 10:43:21

>>202
つか、lambdaがあればブロックつきメソッドもいらないんじゃないの？

210 ：デフォルトの名無しさん：2010/10/28(木) 10:45:23

λ計算かチューリングマシンがあれば何でもできるよね

211 ：デフォルトの名無しさん：2010/10/28(木) 10:48:20

汎用的な処理と、それがあればxxはいらない、を追求すればそうなるよね。

212 ：デフォルトの名無しさん：2010/10/28(木) 10:57:13

Rubyの "lambda" はグローバルなメソッドで、ブロックやProcとの関係はなんというか魔境なんだけどw

あとブロックはそれ単体でリテラルみたいに使えないってのも設計として微妙なところ。

213 ：デフォルトの名無しさん：2010/10/28(木) 10:59:00

>>205
俺は中の人じゃないから分からんけど、要は「WAY」を増やしたくないんだろう、と
思っているよ

214 ：デフォルトの名無しさん：2010/10/28(木) 10:59:47

>>212
え？
f = {|x|
...
}
f(x)
みたいにできないの？

215 ：デフォルトの名無しさん：2010/10/28(木) 11:05:14

よく知らんが、その辺はRubyがLISP-2系統だとかいう話なんじゃなかったっけか

CLだと関数と普通の値を分けているので、関数と同じ名前の変数を
使えるかわりに、#'とかfuncallとか書く必要があるよね

216 ：methane：2010/10/28(木) 11:06:46

Pythonのlambdaが弱いのはインデントでブロックをあらわす構文との相性の悪さもあるから、
>>181 の指摘って無関係な煽りに見えて、実は結構関係するんだよな。
endあるいは } を省略した代償として、式に書き下せない処理は名前付き関数にしないといけない。

217 ：デフォルトの名無しさん：2010/10/28(木) 11:11:01

>>215
似てはいるけど、Lisp-1かLisp-2かというのは名前空間の話なのでちょっと違う。

>>214
できない。Proc.new {|x| ...} か lambda {|x| ...} を使う。今では推奨されてないという話になってるけど
proc {|x| ...} というのもあった。

218 ：デフォルトの名無しさん：2010/10/28(木) 11:13:32

で、end書く回数か、式に書き下せないけどブロック付きメソッド使いたい処理を書く回数かどっちが多いかって話になるんですね。

たぶん、Cでいうところのコンマ演算子がないことと、代入が文なこと(式と文が明確に分かれていて、式にできることが少ない)が、もっと大きな要因。

219 ：デフォルトの名無しさん：2010/10/28(木) 11:13:40

>>217
> 似てはいるけど、Lisp-1かLisp-2かというのは名前空間の話なのでちょっと違う。
なるほど、ありがとう

220 ：デフォルトの名無しさん：2010/10/28(木) 11:14:42

>>217
できないのかよ...
ブロック付きメソッド渡す場面で、そのProcかlambdaを渡すことはできるんだよね？

221 ：デフォルトの名無しさん：2010/10/28(木) 11:22:18

>>217 できる。

foo = lambda {
　...
}
f(x, &foo)

↑これが↓これとほぼ同じ。

f(x){
　...
}

222 ：デフォルトの名無しさん：2010/10/28(木) 11:40:58

あ、アンカー間違えた >>220 ね。

223 ：デフォルトの名無しさん：2010/10/28(木) 11:58:18

じゃあfooが関数を返す関数だった場合、
f(x, &(foo(n)))みたいになるわけか。

224 ：デフォルトの名無しさん：2010/10/28(木) 13:45:18

>>218
代入が文なのも勿論そうだけど
破壊的操作を行うメソッドの多くがNoneを返す仕様なので、
（式だが）式の中で使いやすいようにはできてないってのもあると思うな

>>201が書いている例
a.append(f(a[0], x)) or a.pop(0)
は、代入が式なら単に
a[0] = f(a[0], x)
でいいし、そもそもリストをアキュミュレータにする必要が無い
Pythonの代入には、自由変数にまつわる問題もあるので、より使いにくい

λが単体として問題というより、Pythonの言語仕様がさまざまに絡み合って、
Pythonにおけるλをより使いにくく、無理に書けばcrypticなコードに
なりがちにしているように見える

が、見ての通り、crypticになるのは、必ずしもλのせいではなくて、
要はPythonの言語仕様全般とのインピーダンスアンマッチ、につきると思う

225 ：デフォルトの名無しさん：2010/10/28(木) 13:46:07

>>223
そもそもRubyは「関数」を返すことが出来ない。
ブロック（＝Procクラスのインスタンス）を返すことは出来るから
まあ意味合いとして似たようなことはできるんだけど。

そもそもRubyには「関数」ってオブジェクトが無いんだわ。
・関数とは、メソッドの一種を便宜上そう呼ぶに過ぎない
・メソッドは必ずオブジェクトに所属する
　（いわゆる「関数」と呼ばれるものも例外でなく、「トップレベルでのself」（通称main）に所属する）
・関数が無い代わりに、無名の「手続きの塊」を扱うProcクラスがある
・ブロックやlambdaはProcクラスのインスタンスとして扱われる

ちなみにメソッドや関数の定義内で def を使っても「関数内関数」のようにならず
「メソッドを呼んだ際にメソッドを定義する」という動作になってしまうのも
defが「メソッドの定義」であり、所属先がその際のselfになってしまうから。
「関数内関数」とか「関数を値として使う」みたいなことをしたいときは、Procクラス(lambdaもこれ)を利用する。

226 ：デフォルトの名無しさん：2010/10/28(木) 18:18:05

846 ：デフォルトの名無しさん[sage] 投稿日：2009-02-08 10:45:59
島根の真実。

松江とかひどい状態なんだぞ。
どこでもRubyだもん。Ruby以外のことがしにくくてしょうがない。
Rubyにあらずんば人にあらずみたいな気がする。
Javaでやりますっつっても役人に全く受けない。予算が付かない。
Rubyの波に乗りなさいって言われてもなぁ。。。。
塩屋が邪魔くさくってしょうがない。

227 ：デフォルトの名無しさん：2010/10/28(木) 18:24:32

ラーメンまでRubyだよ

228 ：デフォルトの名無しさん：2010/10/28(木) 18:37:33

ruby大社とかruby灯台とかないだろ

229 ：デフォルトの名無しさん：2010/10/28(木) 20:30:44

出雲ruby空港ってのはいまいちだった
米子でもあわないだろうけど

230 ：デフォルトの名無しさん：2010/10/28(木) 20:59:07

おまえらWebProg板でやれよ。

231 ：デフォルトの名無しさん：2010/10/28(木) 21:02:12

全員死ねよごみが

232 ：デフォルトの名無しさん：2010/10/28(木) 21:30:31

IDやアンカーだけ書いて何か言ったつもりになっている行為が、いかに恥ずかしいことか。

とにかくそのIDの奴の言う事が気に入らないもんだから
何とかしてそのIDの奴のレス勢力を無力化、無効化してやりたいのだが、
かといってどこにツッコミ所があるのか具体的に指摘出来ないし
論破出来る知識も自信も自分には無い、
何より、ヘタにレスを書いてしまうと自分の無知を曝け出す結果となって
かえって自分が周囲の嘲笑の的となってしまうのが怖い。

そこで、とりあえず無言でレスアンカーだけを付けておく事で
「こいつイタイなｗ晒し上げｗ」と必死に周囲に印象付けようとする。

具体的指摘を伴わない無言レスアンカーなら
自分の勘違いだったところで自分はちっとも傷付かずに済むからな。

肝心のどう　“イタイ”　のかについては周囲の流れにお任せ。
きっと読んだ人それぞれが頭の中で勝手に考えてくれるさ！！

抽出廚、レスアンカー厨からは

　「ママ、ぼく悔しいよ！　こいつをやっつけてよ！」

という悲痛な叫びが聞こえてくる。

233 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/10/28(木) 21:45:14

自分の事いうのやめたほうがいよ

234 ：デフォルトの名無しさん：2010/10/28(木) 21:47:00

>>233
死ね

235 ：デフォルトの名無しさん：2010/10/28(木) 23:32:43

あらたなPython信者。といっても2004年か。

ttp://tabesugi.net/memo/2004/82.html#202238

> それからもうひとつは全然べつの話だが、Python がサイコーなのはオブジェ
> クト至高言語なことでも関数風味なことでもなく、「手続き言語として」サイ
> コーなのだ、ということに気づいた。今になってみると、Python がとりわけ
> 直観をサポートするようにできていたのは、インデントだけではないと思う。
> いい例がタプルである。これは、本来なら一度にひとつの値しか使えないとこ
> ろ (配列の要素とか、関数からの返り値とか、変数への代入) に複数の値をま
> とめて渡すことができるので、結果としていくつもの状態を別々に管理するよ
> うな状況で気をもまなくてすんでしまう。これによって制御構造が極端に単純
> でも、あまり気にならない。これにひきかえ、たとえばループを表すのに
> Ruby のイテレータがわかりやすいとは到底思えないし、Scheme の末尾再帰が
> わかりやすいとも思えない (複雑な状態遷移があるものを書くとウンザリする)。
> 彼らのアプローチは概念的に単純ではあるが、それによってループが直感的に
> 書けるかというとべつにそういうわけでもないのだ。

「オブジェクト*至高*言語」というのはSmalltalkやRubyを揶揄してるんだろうな。

236 ：デフォルトの名無しさん：2010/10/28(木) 23:33:25

代入が式じゃないからlambdaで代入できないっていうけど、
関数型言語としてみたら、代入ってできる必要なくね？

237 ：デフォルトの名無しさん：2010/10/28(木) 23:37:21

Python信者まじ怖ぇー

ttp://tabesugi.net/memo/2004/82.html#121731

> Computer Programming for Everybody というエッセイを見てはげしく同意する。
> すげー。Guido はこんなことを考えていたのか。やはり他のスクリプト言語作
> 者とは格が違う。そもそも Perl や Ruby というのは一部のオタクどもが楽を
> するためだけに存在している言語で、かれら教育のことなんか何も考えてない。
> しょせんかれらは狭い世界に閉じこもる運命にあるのだ。それにひきかえ
> Guido はもっとずっと遠くを見ている。エライ。この点で、Python は Scheme
> や Squeak と (理念的に) 肩をならべるものだと思う。しかし Scheme や
> Squeak はセンスがよくても、実用性という面で Python とは比較にならない
> くらい不便という重大な欠点がある。もっとも Python もいきなりこんなに便
> 利になったわけではないから、今後 Scheme やら Squeak やらが発展して便利
> になることもあるかもしれない…けど、実際にはそんなことはなさそうな気がす
> る。なぜなら彼らは「言語」のことしか考えてなさそうだから! ここがポイン
> トだな。つまり、教育のことだけを考えていたのでは言語は使ってもらえず、
> かといって実用性のことだけを考えていても教育には不向きということか。両
> 方をうまくバランスさせないとだめなのだ。そこまで言語開発者が考えている
> プログラミング言語は Python ぐらいじゃないかと思う。

238 ：デフォルトの名無しさん：2010/10/28(木) 23:39:14

> 「すべての人がプログラミングできるようにする (それもお遊びレベルではな
> い、日常的に使うソフトウエアを自分でいじれるようになる)」というのは、
> ぺるりん先生もまえに同じことを授業で話していたが、彼も Python が現時点
> ではいちばん理想に近いといっていた。Alice Project のこともあるし。やっ
> ぱそういう遠大なビジョンをもっている人はエライよな。なぜなら、そういっ
> た計画は将来、本当に重要なものになるだろうし (そうでなければ世の中は非
> 常に暗いものになる)、しかもそれを実現するのには数十年あるいは数百年と
> いうレベルの長い長い時間がかかりそうだからである。そして、そういう活動
> をしている人がほとんど米国にばっかりいるというのは (Guido のこの研究計
> 画書も DARPA にあてたものだ)、なんだか心配だ。
>
> ということで、これでますます選民思想が強化されました。 Ruby なんかと一
> 緒にされちゃ困るね。(なにがどう困るのだかは知らない)

選民思想だという自覚はあるだけ前スレの信者よりましか。
しかしこの人もRubyを目のかたきにしてるな。RubyのなにがそうPython信者を熱くさせるのか知りたい。

239 ：デフォルトの名無しさん：2010/10/28(木) 23:39:50

またコイツかよ。長文コピペすんなカス

240 ：デフォルトの名無しさん：2010/10/28(木) 23:46:02

コイツってツイッターや個人ブログのコピペばっかしてるけど、
ネット中のPythonの記事を探し回ってんのか？

241 ：デフォルトの名無しさん：2010/10/29(金) 00:07:59

Guidoってサヨっぽい考え方をする人だったりするのかな

242 ：デフォルトの名無しさん：2010/10/29(金) 00:12:57

ストールマンの悪口はそこまでだ

243 ：デフォルトの名無しさん：2010/10/29(金) 00:22:31

前ので本人引っ張り出せたから味占めたな

244 ：デフォルトの名無しさん：2010/10/29(金) 00:25:51

Ruby厨がPythonスレやコミュニティーをさんざん荒らしたから
PythonユーザーはRubyと聞いただけで嫌悪感を持つってのはあると思う
PythonスレにRuby最高とか楽しいとか日本人ならRuby使えとかやられまくったからな

245 ：デフォルトの名無しさん：2010/10/29(金) 00:28:28

>>244
今でもブログやツイッターは監視されてるようだしな

246 ：デフォルトの名無しさん：2010/10/29(金) 00:40:48

>>236
Pythonは参照透明性を重視した関数型言語ではないのだから
Pythonでコードを書く限り実質的に代入は必要だろ

仮にPythonでループの代わりに末尾再帰で書いても最適化はされないのだから、
糞遅い上にスタックオーバーフローになるだけ

247 ：デフォルトの名無しさん：2010/10/29(金) 01:01:50

>>244
昔 Java スレにも shige という奴が居てだな…

248 ：デフォルトの名無しさん：2010/10/29(金) 04:21:41

>>236
関数型言語のλでも、値の束縛は大概出来ると思うのだが？
多くはletとかでサポートしてるだろ

249 ：デフォルトの名無しさん：2010/10/29(金) 04:40:48

Erlangは実際、バインドだけで代入はないな。
バインドできるのは一回だけだし。

250 ：デフォルトの名無しさん：2010/10/29(金) 07:14:25

>>244
むしろそいつがどうの言うレスでRubyスレでも迷惑してたんだけど

最近だとC#マンセー Windowsでは使い物にならねー厨が一時期いくつかのスレに来なかった？
Rubyのスレにもきてたが

Windowsでは使い物にならね、は同意だが正論でも荒らされてはわな

251 ：デフォルトの名無しさん：2010/10/29(金) 07:15:40

Windowsでは使い物にならね、じゃなくてGUI作れねえ、だったかな？
どっちでもいいけど

252 ：デフォルトの名無しさん：2010/10/29(金) 07:27:51

上でlambdaとブロックの話が出ていたが、こういうのはlambdaでできないだろう、と示すのは別物なんだからフェアじゃないな。

Rubyのブロックはwithを作るようなもんなんだろう。
withのような簡単な制御構造や内部DSLを作りやすい。

この使い方がRails以降多用されている。空気のように～と上ででていたが実際そう。

だけど上であまり強調されていない理由は、その流れをRubyユーザーがあまりよく思っていないからじゃないか？
Rubyスレでも話題が出ると不満がでることが多々ある。

いきすぎた制御構造の拡張や、内部DSLってさ、
ようするに宣言っぽくかけてRubyらしく振舞わないRubyスクリプトなんだよね

ブロックのネストの度に省略されたselfがバンバン変化する
信じられるかい？
このブロックでメソッドを定義したらどうなるのだろう？
>>225のようにトップレベルに定義されるのだろうか？
別のクラスやモジュールに定義されていないか？

こんな疑問を持ちながら、selfを確かめながら、挙動をソースを見ながら(ドキュメントじゃないぞ)
使わないといけないんだよ、ブロックは。

253 ：デフォルトの名無しさん：2010/10/29(金) 07:33:25

>>252を見たらわかる人はすぐにわかるこいつはバカだ、と
「ブロックが悪いんじゃない、メタプログラミングをブロックを使って多用しているのが悪いんだ」と
実際そうだ。

だが、実際はブロックはすでにlambdaの範疇を超えてるんだよ。
メタプログラミングと切っては切れない。
だから単純に比較できない

> ようするに宣言っぽくかけてRubyらしく振舞わないRubyスクリプトなんだよね

これもおかしくて、ブロックとメタプログラミングの使用はRubyらしい。
だが、ブロックとメタプログラミングを使わずにRubyを書いているときとは全く違った使い方になる
それくらいの意味。

254 ：デフォルトの名無しさん：2010/10/29(金) 08:15:46

>>252
そんなに心配ならJavaScriptみたく保存しておきたい時点でのselfを代入しとけばいいんじゃね
まあ別物と比較するのはフェアじゃないな。

…で、lambdaどうすんだ

255 ：デフォルトの名無しさん：2010/10/29(金) 08:42:16

いらない

256 ：デフォルトの名無しさん：2010/10/29(金) 09:45:38

>>248
値の束縛はできるよ。けど、letなくても値の束縛は出来るよね。

257 ：デフォルトの名無しさん：2010/10/29(金) 10:22:52

>>248
letはlambdaの構文糖なので、lambdaがあればletは一応実現できる

ま、Pythonではiterative processは末尾再帰でなくループで書くべきだし
ランタイムも破壊的操作を前提としたものが多い

Pythonでお上品ぶろうとしたってまるで意味は無いが

258 ：デフォルトの名無しさん：2010/10/29(金) 22:22:11

Python的な見方では、lambdaの積極的な利用はむしろ下品。

259 ：デフォルトの名無しさん：2010/10/30(土) 01:38:55

ttp://www.uproda.net/down/uproda160078.png

260 ：デフォルトの名無しさん：2010/10/30(土) 09:47:52

Haskellだけ他の陣営からの見た目と一緒なのかw
…ところでこのスレ的にはPythonとPerlが入ってて欲しいのだが

>>257-258
別に上品とか下品とか関係なくね？
どっちかっつーと、中途半端で紛らわしい存在って感じ

261 ：デフォルトの名無しさん：2010/10/31(日) 08:51:09

素直にlambdaはPythonicじゃないと言おうぜ

262 ：デフォルトの名無しさん：2010/10/31(日) 09:03:41

Ruby って PHP 上がりがよく使ってるな。Rail 出る前は完全に死に体だったのに。
PHP(ﾌﾟとか人格からにじみ出てるけど Web プログラマ(笑)どうし仲良くしてろよって感じ。

263 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/10/31(日) 11:32:20

(笑）

264 ：デフォルトの名無しさん：2010/10/31(日) 15:47:56

急に話のレベルが下がったと思ったら

265 ：デフォルトの名無しさん：2010/10/31(日) 17:52:12

>>245
Ruby厨はネトウヨの集合体みたいになったわけだ

266 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/10/31(日) 20:41:54

まつもとひろゆきをボコボコにぶん殴ってる夢見た

気分爽快だった

267 ：デフォルトの名無しさん：2010/10/31(日) 21:11:22

誰かまつもとを葬ってくれないか

268 ：デフォルトの名無しさん：2010/10/31(日) 21:11:59

通報した

269 ：デフォルトの名無しさん：2010/10/31(日) 21:16:28

いいなぁ。俺もそんな夢を見てみたい。

270 ：デフォルトの名無しさん：2010/11/01(月) 03:36:14

考えが足らない人が真似ないために書きます
267の書き込みは刑事責任が問われる書き込みです。
この類の書き込みで逮捕された事件も少なくありません。
268が通報したので、IPアドレスを元に捜索が入ると思いますが
もし逮捕されない結果になったとしても犯罪を犯したという反省が必要です。

271 ：デフォルトの名無しさん：2010/11/01(月) 04:20:33

何罪で?
信者ｷﾒｪ

272 ：デフォルトの名無しさん：2010/11/01(月) 04:54:40

刑法で脅迫罪
いたずら、殺人依頼、脅迫
いずれの目的であっても脅迫罪として立件される

273 ：デフォルトの名無しさん：2010/11/01(月) 05:07:22

んな事で犯罪になるのか
んー、分からないでもないが、変なの

274 ：デフォルトの名無しさん：2010/11/01(月) 05:15:37

Matzはどうでもいいけど
みんなのアイドルLarryちゃんが悲しむから物騒な流れはやめて

>>258
Haskellも無名関数は謙抑的に用いるのが行儀いいらしいね
代わりにletやらwhere使えってことで
Pythonの態度も似たようなものか

275 ：デフォルトの名無しさん：2010/11/01(月) 05:17:35

掲示板に殺人依頼の書き込みがあることを本人が知った場合
殺人宣言と同程度の不安がありそうだから犯罪と判断されるのが正当でしょう。
当然、殺人宣言が発見された場合は、ほぼ確実に逮捕へ踏み込むのが現状だけどね。

276 ：デフォルトの名無しさん：2010/11/01(月) 05:20:19

全部私見じゃねぇかｗ

277 ：デフォルトの名無しさん：2010/11/01(月) 05:22:16

脅迫罪の話までは過去の事例だから
勘違いをされないように。

278 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/01(月) 07:23:58

ばかどもがわめてますね

279 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/01(月) 07:25:38

どうせ訴えない　訴えてもこわくねえよはげだから

280 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/01(月) 07:27:45

>>267

281 ：デフォルトの名無しさん：2010/11/01(月) 07:28:27

282 ：デフォルトの名無しさん：2010/11/01(月) 09:20:08

実際のところ、通報されたら面倒になるとは思うよ。

283 ：デフォルトの名無しさん：2010/11/01(月) 11:59:21

すでに通報されていると思うけど(wwwWw

284 ：デフォルトの名無しさん：2010/11/01(月) 12:36:44

まつもとは「Rubyが飽きられてきた」という現実は…死んでも見たくないんだろうな。ｗ

http://twitter.com/yukihiro_matz/statuses/29317109670

285 ：デフォルトの名無しさん：2010/11/01(月) 12:49:55

妄想乙

286 ：デフォルトの名無しさん：2010/11/01(月) 12:52:59

Railsの便乗人気が一区切り付いて安定期に入ったね

287 ：デフォルトの名無しさん：2010/11/01(月) 13:11:54

PerlやPythonは10年以上前に安定期に入ってるけどね。

288 ：デフォルトの名無しさん：2010/11/01(月) 13:15:14

安定期に入った時期を比較してなんの意味があるんだろう
というかPythonって火がついてた時期ってあるの？
火は付かないけど、地味に人気を保ち続けてるイメージが強い
ある意味、その浸透の仕方が好きでもあるんだが

289 ：デフォルトの名無しさん：2010/11/01(月) 13:17:30

googleが使ってるってことで火が付いただろ

290 ：デフォルトの名無しさん：2010/11/01(月) 13:36:16

>>289
でもそれってGoogleだけで完結しちゃってね？
多少の人気は出て使用人口は増えたかも知れないが
それだけで、Pythonを使う上での変革はあんまり無かった
Perl/CGIやRuby on Railsは、その言語に新しい使い方をもらしただよ

291 ：デフォルトの名無しさん：2010/11/01(月) 13:56:49

>>288
>安定期に入った時期を比較してなんの意味があるんだろう

Rubyみたいに些細なことでコア履いたりしないってことさ
鍛えられ方が違うんだよ

292 ：デフォルトの名無しさん：2010/11/01(月) 13:57:03

http://twitter.com/yukihiro_matz/statuses/29317109670

yukihiro_matz: 英語圏でRubyとPythonを比較する記事を見ることが少なくなってきた
のは、RubyとPythonでクラスタが分離してきたからか。逆に日本語でRubyとPythonを
比較する記事を見かけるのは国内でのPythonの地位が向上したからか。

　　　　　　　　　　　　　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　／⌒　　⌒＼　　 |　　 |
　　　／（ ●）　（●）＼　 !　　 !
　／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　　　 | 　／　＜こいつ最高にアホだお
　＼　　　｀ー'´ 　　／／
　　/　＿＿　　　　　　　/
　　(＿＿＿）　　　　　　/

293 ：デフォルトの名無しさん：2010/11/01(月) 14:09:21

必死だな

294 ：デフォルトの名無しさん：2010/11/01(月) 14:16:07

アホだよな
Rubyは相手にされていないってだけなのに
本人もPythonスレでRubyの宣伝していた時代を黒歴史だって認めてるのに
ただの口から出任せでなにも反省してないことが丸わかり

295 ：デフォルトの名無しさん：2010/11/01(月) 14:17:39

大丈夫、Ruby使いの中でもMatzがアホなのは周知の事実だから

296 ：デフォルトの名無しさん：2010/11/01(月) 14:30:35

　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　 ☆　ﾁﾝ　　〃　 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　ヽ　＿＿_＼（＼・∀・）　＜　Rubyホ(モ)ルモンラーメンまだ～
　　　　　　＼＿／⊂　⊂＿ )　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　／￣￣￣￣￣￣／|
　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　|　　宍道湖七珍　|／

297 ：デフォルトの名無しさん：2010/11/01(月) 14:42:15

もっと連投ガンバレ

298 ：デフォルトの名無しさん：2010/11/01(月) 14:55:25

PythonスレじゃなくてPythonのMLだったorz

299 ：デフォルトの名無しさん：2010/11/01(月) 15:04:25

>>297の期待に応えますだお

http://twitter.com/yukihiro_matz/statuses/29317109670

yukihiro_matz: 英語圏でRubyとPythonを比較する記事を見ることが少なくなってきた
のは、RubyとPythonでクラスタが分離してきたからか。逆に日本語でRubyとPythonを
比較する記事を見かけるのは国内でのPythonの地位が向上したからか。

　　　　　　　　　　　　　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　／⌒　　⌒＼　　 |　　 |
　　　／（ ●）　（●）＼　 !　　 !
　／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　　　 | 　／　＜こいつ最高にアホだお
　＼　　　｀ー'´ 　　／／
　　/　＿＿　　　　　　　/
　　(＿＿＿）　　　　　　/

300 ：デフォルトの名無しさん：2010/11/01(月) 15:21:03

　　　　　　　　　　　　　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　／⌒　　⌒＼　　 |　　 |
　　　／（ ●）　（●）＼　 !　　 !
　／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　　　 | 　／　＜こいつ最高にアホだお
　＼　　　｀ー'´ 　　／／
　　/　＿＿　　　　　　　/
　　(＿＿＿）　　　　　　/

301 ：デフォルトの名無しさん：2010/11/01(月) 15:50:00

クリスチャンなら謙虚をむねとすべきで、こんなふうに他力本願でちょっとバブったからって、
調子ぶっこいてみせる態度がいかに馬鹿っぽく見えるかとかわかりそうなものだけれどもね。

モルモン教徒がクリスチャンを名乗ることが詐称行為に当たる点は不問に付すとしても、だ。

302 ：デフォルトの名無しさん：2010/11/01(月) 15:52:17

（キリッ）

303 ：デフォルトの名無しさん：2010/11/01(月) 21:39:31

(ﾄﾞﾔｯ)

304 ：デフォルトの名無しさん：2010/11/01(月) 21:42:28

rubyを発端に流行ってるのが最近多い気がするけど、rails,sinatra,rspec,cukesとか、他のPがつく言語発端で流行ったのってなんかある？

305 ：デフォルトの名無しさん：2010/11/01(月) 22:17:32

ダンジョー

306 ：デフォルトの名無しさん：2010/11/02(火) 00:46:10

WSGI

307 ：デフォルトの名無しさん：2010/11/02(火) 01:03:05

pylons
plone
django

308 ：デフォルトの名無しさん：2010/11/03(水) 00:36:28

なぜRubyは許容可能なLISPなのか
ttp://d.hatena.ne.jp/masatoi/20101102/1288654204
Ruby vs Lisp, ファイト!

309 ：デフォルトの名無しさん：2010/11/03(水) 01:18:01

>>301
Pythonエキスパートさん、名前欄書き忘れてますよ。
それからPython信者がどんなにわめいたところで、
あなた自身の価値はあなたがバカにしているMatzよりずっと低いままですよ。

310 ：methane：2010/11/03(水) 04:00:47

>>309
俺はモルモン教を批判したことはないし、Matzは尊敬しているし、今までpypiに登録してる
パッケージのバージョンアップしてた。 >>301 とは別人だよ。

311 ：デフォルトの名無しさん：2010/11/03(水) 04:40:03

LL好きでMatz尊敬してない人とかそうそういないだろ
むしろ一身に尊敬を集めているがゆえに安心したバカが面白半分に
アンチを名乗ってるだけじゃなイカ？

312 ：デフォルトの名無しさん：2010/11/03(水) 05:05:46

Matzをリスペクトしてるけど痛い発言は恥ずかしいから止めて欲しいと思っている

313 ：デフォルトの名無しさん：2010/11/03(水) 05:48:53

Matzはなんだかんだ言ってこっち側の人間だしね
祭り上げられてることについて本人がどう思ってるか知らないけど
公的な発言力が増すことはRuby使い以外にとっても利点が大きい

314 ：デフォルトの名無しさん：2010/11/03(水) 08:28:39

>>312
そういう人多そう

315 ：デフォルトの名無しさん：2010/11/03(水) 08:59:42

s/Matz/Linus/
s/Matz/GvR/
s/Matz/Theo/

316 ：デフォルトの名無しさん：2010/11/03(水) 09:01:41

ArcがもうちょっとCLっぽい文法だったら良かったのに

317 ：デフォルトの名無しさん：2010/11/03(水) 09:28:03

他の言語をdisるのは偉大なる先人も通った道
たとえば

318 ：デフォルトの名無しさん：2010/11/03(水) 11:46:19

既存の言語に不満を感じなきゃ独自の言語を作ろうと思わないのはまあ当然
そして自分が作った言語の方が他の言語よりも親しみを感じるのも当然
他の言語をdisりたくなる理由は理解できる

319 ：デフォルトの名無しさん：2010/11/03(水) 12:03:02

自分が作った言語に親しみを感じるのは自由だし
優れていると思っているところを自慢するのも勝手だが
他の言語をdisるのは全くの筋違い

320 ：デフォルトの名無しさん：2010/11/03(水) 12:10:08

カーニハン先生がニヤニヤしてますよ

321 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/03(水) 12:34:43

かにチャーハンとかいうやついるよな

お前みたいなやつら

322 ：デフォルトの名無しさん：2010/11/03(水) 12:51:36

>>320
蟹飯はPascalをdisりまくってたな

323 ：デフォルトの名無しさん：2010/11/03(水) 19:33:07

>>319
その言葉、Python信者にそのままお返しします。

324 ：デフォルトの名無しさん：2010/11/04(木) 03:31:59

IDEを駆使したときの生産性の高さ、開発後の保守性を考えたらJavaの
ほうがLL言語より優れていますが？

325 ：デフォルトの名無しさん：2010/11/04(木) 04:59:10

>>324
マウスに手を持っていかなくても出来るの？

326 ：デフォルトの名無しさん：2010/11/04(木) 08:18:31

>>323
Python信者に何言っても無駄だって。
自分はtwitterでさんざんPHPやRubyをけなしておいて「あれは個人的な感想です」と言い張っておきながら、
他人のtwitterでのつぶやきに対しては「他の言語をdisるな」だもんね。話が通じる相手じゃない。

327 ：デフォルトの名無しさん：2010/11/04(木) 08:19:09

何この妄想厨

328 ：デフォルトの名無しさん：2010/11/04(木) 08:20:19

いつものツイッター監視厨だろ

329 ：デフォルトの名無しさん：2010/11/04(木) 08:26:51

つかさ、>>292のどこが「disる」になるんだ？これをdisってると感じるのはPython信者ぐらいだろ。
どうみても↓のほうがdisってるくせに、これは「感想」で済ましちゃうんだよね。

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なら不要。

330 ：デフォルトの名無しさん：2010/11/04(木) 08:29:04

やっぱりいつもの奴だったか。何回長文コピペすれば気が済むんだよ

331 ：デフォルトの名無しさん：2010/11/04(木) 08:29:37

ｷﾁｶﾞｲ警報

332 ：デフォルトの名無しさん：2010/11/04(木) 08:41:25

転載するだけしてあとは他の人に叩いてもらおうとか卑怯過ぎる

333 ：デフォルトの名無しさん：2010/11/04(木) 09:01:42

>>330-332
液パイ乙。擁護レスすんの速すぎるよお前w

334 ：デフォルトの名無しさん：2010/11/04(木) 09:04:41

だと良いですね(ﾜﾗ

335 ：332：2010/11/04(木) 09:15:11

>>333
いや、そんなツイート（を書く奴）を擁護する気はさらさら起こらないわ
経験者にとっても可読性が低い言語は叩いて構わないが
一見さんにとっての可読性を気にするなんてもうどうしようもない
（保守するのは一見か？勉強もせずいきなりコード読むのか？）
Haskellが一見にとってイミフだから叩くのと同じぐらいDQNな行為だ

と釣られてみる

336 ：デフォルトの名無しさん：2010/11/04(木) 10:31:04

わずか38秒で反応するやつ、2chにはりつきすぎだろ。ニートってこわい。

　326 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/11/04(木) 08:18:31
　>>323
　Python信者に何言っても無駄だって。
　自分はtwitterでさんざんPHPやRubyをけなしておいて「あれは個人的な感想です」と言い張っておきながら、
　他人のtwitterでのつぶやきに対しては「他の言語をdisるな」だもんね。話が通じる相手じゃない。

　327 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/11/04(木) 08:19:09
　何この妄想厨

　328 名前: デフォルトの名無しさん Mail: sage 投稿日: 2010/11/04(木) 08:20:19
　いつものツイッター監視厨だろ

337 ：デフォルトの名無しさん：2010/11/04(木) 10:31:49

methaneネタはもういい加減にしとけ
自分がblogに突撃するゲハ厨並に馬鹿な真似をやってるんなら
相手を馬鹿にはできないよ

338 ：デフォルトの名無しさん：2010/11/04(木) 10:38:27

即スレ食らって涙目のｱﾌｫが居ると聞いて

339 ：デフォルトの名無しさん：2010/11/04(木) 10:47:20

興味深い。
マルチしている>>292やここぞとばかりににdisってる>>294はまったくスルーしてるくせに
それへの批判はいちいち反応してるパイソンの人って、どんな精神構造してるのか知りたい。
あれかな、自分のツイートは何書いても「感想」で、他人のツイートは「dis」よばわり
していることの矛盾に自分でも気づいているから、妄想厨とでも言わなきゃ反論できなのかな。

>>337
本人乙

340 ：デフォルトの名無しさん：2010/11/04(木) 10:48:51

↑さっきからこの見苦しいのは何なの?

341 ：337：2010/11/04(木) 10:54:00

>>339
本人認定来たよｗ

>>292みたいなAAマルチ厨なんか相手にするわけないだろ
methaneネタは最初は面白かったがMatzみたいな大物じゃなくてどうでもいい奴だから
すぐ飽きる
シンボルも知らない厨房だったじゃないか
言ってることからして、コンピュータサイエンスを学んだこともないんだろ

またいつもの厨房か、と思われたくなければ、冷静になれよ、と言ってる

342 ：デフォルトの名無しさん：2010/11/04(木) 11:18:04

コミュニティの話はどうでもいいから言語の話をしようぜ

343 ：デフォルトの名無しさん：2010/11/04(木) 11:20:18

>>335
>>336

45秒www
はやすぎるwwww

344 ：methane：2010/11/04(木) 12:09:33

>>329,339
2chではよくあるけど、「Python信者」みたいなレッテル張りを始めたとたんにそれが
1つの人格のように感じてしまうのは良くないよ。
Python信者は沢山居て、俺と >>292 は別人なんだから、「Python信者はダブスタだ」みたいな
指摘は意味が無い。

>>335
別に一見さんに対する可読性が良いからPythonはRubyより良い言語だって主張する気は無いよ。
あくまでも、C++が99%の職場で他人も改造するようなバッチ処理を書くとか、そういう場面では
Pythonが一見さんにも読みやすくて良いんじゃないかと思ってつぶやいただけ。

一見さんに対する可読性に限らず、言語はいろんな側面を持っていて、どの側面が重要なのかは
場面によって異なる。
PHPのパフォーマンスの話だって、秒間数千リクエストのサイトをMVCフレームワークを使って
構築しようと思わなければ問題にならないし、mod_phpの利便性とかphpの良い点もちゃんとわかってる。

345 ：デフォルトの名無しさん：2010/11/04(木) 13:30:35

C#やってた俺はRubyが1番読み易かったな

346 ：デフォルトの名無しさん：2010/11/04(木) 17:40:00

C#は5年以上まともに触ってないんだが、最近のはかなり凄いよね
……と思ってC#のコード書いてみたけど、やっぱりちょっと面倒くさかったｗ

Pythonで
http://codepad.org/f7JQm3CK
これぐらいのコードが
C#だと
http://pastie.org/1271708
これぐらいになった

まあこれぐらいで型安全と速度が手に入ると思えば上出来なのかな
C#使いならもっと簡潔に書くんだろうし

347 ：デフォルトの名無しさん：2010/11/04(木) 18:07:58

>>343
ツイッター監視厨は他にやることないのかよ

348 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/04(木) 18:36:50

disってるとマイトガイになっちまいますよ？ｼｭｯｼｭ

349 ：デフォルトの名無しさん：2010/11/04(木) 19:12:54

よく知らんのだけど
C#ってがんがん改良・拡張されていくなぁ

一企業が作ってるのと
コミュニティが作ってるものの違いか

350 ：デフォルトの名無しさん：2010/11/04(木) 19:16:43

よく知らんなら発言すんな

351 ：デフォルトの名無しさん：2010/11/04(木) 19:27:49

>>328
python信者のツイッター発言がコピペされると怒るけど、matzのツイッターがマルチでコピペされることはスルーするのは変だなと思ったけど
328がmatzのツイッターを監視してマルチコピペしているのだと考えたら納得がいった。

352 ：デフォルトの名無しさん：2010/11/04(木) 19:29:58

>>351
お前はコピペについてどう思ってんの？

353 ：デフォルトの名無しさん：2010/11/04(木) 19:31:14

ツイッターのコピペとか情弱の極みだな。本人に直接言えばいいだろ。
頭悪すぎ。コピペ野郎とは会話も成立しない

354 ：デフォルトの名無しさん：2010/11/04(木) 19:32:07

よく知らんのだけどScalaいいね
def queens(size: Int) = {
def safe(x: Int, y: Int, x_ : Int, y_ : Int) =
x != x_ && y != y_ && (x - x_).abs != (y - y_).abs
def solve(y: Int): List[List[(Int, Int)]] = {
if(y == 0) List(List())
else for {
qs <- solve(y - 1)
x <- 1 to size if qs.forall{case (_x, _y) => safe(x, y, _x, _y)}
} yield (x,y) :: qs
}
solve(size)
}
for(x <- queens)
println(x)

355 ：デフォルトの名無しさん：2010/11/04(木) 19:32:31

よく知らんなら発言すんな

356 ：デフォルトの名無しさん：2010/11/04(木) 19:33:03

こうか
for(x <- queens(8))
println(x)

357 ：デフォルトの名無しさん：2010/11/04(木) 19:36:09

>>354
おー、さすがにC#よりは全然いいね
C#はJavaに比べればかなり頑張ってるけど、微妙なところでまだ不便さを感じたYO

358 ：デフォルトの名無しさん：2010/11/04(木) 19:36:14

ツイッター監視スレを別に立ててくれ。邪魔。

359 ：デフォルトの名無しさん：2010/11/04(木) 19:44:24

>>344
なにいい子ぶってんの？バトルスレなんだから、前スレ通りPython信者は言いたい放題言えばいいよ。

>別に一見さんに対する可読性が良いからPythonはRubyより良い言語だって主張する気は無いよ。
まさに>>323の通りだな。

360 ：デフォルトの名無しさん：2010/11/04(木) 19:46:20

>>359
プログラミング言語に関しては無知だから煽ることしかできないのか馬鹿が死ねよ

361 ：methane：2010/11/04(木) 19:55:21

>>359
良い子ぶるもなにも、前スレでもTwitterでも最初から限定された条件でのPythonのメリットを
言っているだけで、「だからRuby/PHPはクソ、Python万歳」なんて主張は一切してないよ。
そういう主張をしている痛いPython信者キャラとしてみている人がいるだけ。

362 ：デフォルトの名無しさん：2010/11/04(木) 20:11:26

日本人ならRubyと言いつつも、隣が気になってPythonも嗜み、実際にはPHPばかりいじってるのは知ってる。
でも本当に好きなのはPerlだよな。

363 ：デフォルトの名無しさん：2010/11/04(木) 20:20:43

lispだろ

364 ：デフォルトの名無しさん：2010/11/04(木) 20:58:52

>>361
痛いPython信者さんは、Python以外ではどんな言語が好きですか？

365 ：methane：2010/11/04(木) 21:25:24

>>364
C++は、ヘッダとソースを分けるのが面倒だったりビルドに時間がかかったりするけど、
プログラムしてて楽しい。
といっても言語が好きというわけじゃないな。C++を使う必要性があるようなパフォーマンスを
気にする課題が好き。アセンブラが必要になる場面とか燃える。

あとは、Erlang、Go、Valaなんかも気になってる。
基本的に構文よりも、ライブラリなどの実用性とCPUとメモリ両方の実行効率が言語を気に入る条件。

366 ：デフォルトの名無しさん：2010/11/04(木) 21:32:29

>>364
お前は何が大好きなの？

367 ：デフォルトの名無しさん：2010/11/04(木) 21:39:28

慣れないF#でも書いてみたけど、昔ちょっと使ったときより
型推論が強力になってる気がした（きのせいかも）
C#よりはいいかなあ
でも似た傾向のコードになる言語ばかりだと、つまらないですね

let queens size =
let safe x y pos = match pos with
| (x_, y_) -> x <> x_ && y <> y_ && abs(x - x_) <> abs(y - y_)
let rec solve y = seq {
if y = 0 then yield []
else
for qs in solve (y - 1) do
for x in 1..size do
if qs |> Seq.forall (safe x y) then yield (x, y)::qs }
solve size

368 ：デフォルトの名無しさん：2010/11/05(金) 00:39:52

>>346 は Rubyist

369 ：デフォルトの名無しさん：2010/11/05(金) 00:43:09

>>354
goでおながいしまs

370 ：デフォルトの名無しさん：2010/11/05(金) 01:10:15

>>329
その人は放っといてやって。

371 ：デフォルトの名無しさん：2010/11/05(金) 01:49:36

Pythonだとこんなんでいいの？
def queens(size):
    def safe(l, x0, y0):
        return all(x != x0 and y != y0 and abs(x - x0) != abs(y - y0) for x, y in l)
    def solve(y):
        if y == 0:
            return [[]]
        else:
            ls = [l + [(x, y)] for x in range(1,size+1) for l in solve(y-1) if safe(l, x, y)]
            return ls
    return solve(size)
for ans in queens(8):
    print ans

372 ：デフォルトの名無しさん：2010/11/05(金) 04:17:12

>>371
>>346

373 ：デフォルトの名無しさん：2010/11/05(金) 09:08:15

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
PerlはObjective-Cに抜かれたな。Pythonも時間の問題で、安泰なLLはPHPだけ。
Obj-Cと逆に下落を続けるVBはとうとうPythonを下回った。Perl/Rubyを下回るのも時間の問題。

374 ：デフォルトの名無しさん：2010/11/05(金) 23:27:17

pythonのブロック抜けて、インデント下げるのが
面倒なんだが、なんか良い方法あるの？

375 ：デフォルトの名無しさん：2010/11/05(金) 23:37:17

8 Queenを100回走らせたら実行時間は↓のような感じだった

C++ 0.08
C# 0.851
F# 1.602
Scala 1.663
Python 7.946

C++のコードはこれ
http://codepad.org/bO7Zg25g

汎用プリンタが無い言語は地味にだるいな、と思った

376 ：デフォルトの名無しさん：2010/11/05(金) 23:45:03

pythonはexe化したの？

377 ：デフォルトの名無しさん：2010/11/05(金) 23:51:32

>>376
exe化する意味は無いのでは

以前のコードは関数safeの条件式に少し無駄があったので
http://codepad.org/FsSMAc9V
のように書き換えた
psycoもかけてみたけど、このコードではほとんど差がないようだった

378 ：デフォルトの名無しさん：2010/11/05(金) 23:54:21

>>375が何を言いたいのか分からん。さっさと他のP言語の結果持って来いよ

379 ：デフォルトの名無しさん：2010/11/05(金) 23:55:08

興味がある人は自分で書いてくださいね

380 ：デフォルトの名無しさん：2010/11/05(金) 23:58:21

>>378
似たようなコードのなかでC#が速いのはコンパイラが
よく最適化されているということかと思った
ただ、F#やScalaとの差が高々倍程度なので、それならばF#やScalaを選ぶ人が
多いのではとも

C++は完全にべた書きなので速いのはあたりまえ
この品揃えの中でPythonが遅いのもあたりまえ

381 ：デフォルトの名無しさん：2010/11/06(土) 00:00:00

>>380
そんなことはお前の実験の100年前から分かってる

382 ：デフォルトの名無しさん：2010/11/06(土) 00:00:53

エキPyとかいう糞本の翻訳者の発言はエキストリームなバカの意見だから無視して下さい

383 ：デフォルトの名無しさん：2010/11/06(土) 00:03:10

どう糞なのか具体的に言えたらお前が言ってること信じるよ

384 ：デフォルトの名無しさん：2010/11/06(土) 00:05:57

翻訳者が問題発言の多い糞なんです

385 ：デフォルトの名無しさん：2010/11/06(土) 00:08:45

どう糞なのか具体的に言えたらお前が言ってること信じるよ

386 ：デフォルトの名無しさん：2010/11/06(土) 00:09:51

>>384
それはクソだぜなるほどな

387 ：デフォルトの名無しさん：2010/11/06(土) 00:16:13

イタタタタ(ww

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なら不要。

388 ：デフォルトの名無しさん：2010/11/06(土) 00:19:49

>>387
Pythonユーザー視点からの発言としては全く妥当だけど、何が問題なのかなあ
他のプログラマ兼ブロガー、エッセイストと比較して、どう糞なのかワカンネ
あと、原著者と内容、翻訳自体に問題はないの？本、読んだことあるの？

389 ：デフォルトの名無しさん：2010/11/06(土) 00:25:40

単純にさー、自分の直感や閑静と違うって話でしょ。

390 ：デフォルトの名無しさん：2010/11/06(土) 00:28:25

>>388
お前がそれを言うなよ(w

391 ：デフォルトの名無しさん：2010/11/06(土) 00:29:22

Scala F# Pythonはコード量あんま変わらんけど一見さんはどれが一番見やすいのよ

392 ：デフォルトの名無しさん：2010/11/06(土) 00:29:29

>>390
他のプログラマ兼ブロガー、エッセイストと比較して、どう糞なのかワカンネ
あと、原著者と内容、翻訳自体に問題はないの？本、読んだことあるの？

393 ：デフォルトの名無しさん：2010/11/06(土) 00:30:11

発言が全く妥当だと思えるPythonユーザーの視点は問題があるという証左になってるな

394 ：デフォルトの名無しさん：2010/11/06(土) 00:31:04

エキストリームバカは遠まきに見てるのが安全だよ

395 ：デフォルトの名無しさん：2010/11/06(土) 00:31:59

>>393
だからどう問題があるのか少しは具体的に言えないのかよ

396 ：デフォルトの名無しさん：2010/11/06(土) 00:36:11

>>391
これだけ短くて純粋な計算(?)だとやっぱり見慣れたC++かな。なんか安心する。

397 ：methane：2010/11/06(土) 00:48:02

私的 <- Twitter - 個人Blog - 会社Blog - 翻訳 -> 公的
Twitterでは思ったこと・感じたことを気軽につぶやきますが、翻訳文では個人の感想や
感情が入らないようにしっかり考えています。

398 ：デフォルトの名無しさん：2010/11/06(土) 00:59:28

勉強を兼ねてSqueak4.1で書いてみた。

| queens |
queens := [:size |
　　| safe solve |
　　safe := [:dp | dp x * dp y ~= 0 and: [dp x abs ~= dp y abs]].
　　solve := nil.
　　solve := [:y |
　　　　y = 0 ifTrue: [#(())] ifFalse: [
　　　　　　((solve value: y - 1) collect: [:qs | (1 to: size)
　　　　　　　　select: [:x | qs allSatisfy: [:pos | safe value: x@y - pos]]
　　　　　　　　thenCollect: [:x | {x@y}, qs]]) concatenation]].
　　solve value: size].

Transcript closeAllViews; open.
(queens value: 8) do: [:each | Transcript cr; show: each]

399 ：デフォルトの名無しさん：2010/11/06(土) 01:00:06

.って入れなきゃいけないのか？あり得ないほど見にくいな

400 ：デフォルトの名無しさん：2010/11/06(土) 01:03:02

Scheme
http://codepad.org/b6mrBkhu

Codepadで使えるみたいだったけど、srfi-1をどうやったらimportさせられるかが
わからなかった
safe?のありえなさでだいぶ割りを食っているｗ

401 ：methane：2010/11/06(土) 01:11:17

>>377を、リスト内包のネストをループに戻してみた。
http://codepad.org/XwQJSHNw
これで 2.2sec で、 >>377 とほとんど変わらない。

で、これを次のように cython にかけてみると 0.4sec になった。
cython --embed queen.py
gcc `python-config --cflags` `python-config --ldflags` queen.c
./a.out

402 ：methane：2010/11/06(土) 01:20:12

http://codepad.org/vD8lJsx0
整数を C の int にしたら 0.2sec
Pythonのリストやタプルを使うのを止めたら10倍くらい早くできると思うけど、もはや
Pythonの原型が無くなるなw

403 ：デフォルトの名無しさん：2010/11/06(土) 01:26:59

そんなこと言われなくてもわかってるよ、とみんなが思っているようなことを
いちいちコードに含めるのはナンセンスだよね。
一見さんには辛いかもしれないけど、そういう人たちのための補助的な情報は
コードにではなく書籍とかウェブとかに載せておけばいい。
コードには初心者にも上級者にも必要な本質だけが載っているべきだと僕は思うよ

404 ：デフォルトの名無しさん：2010/11/06(土) 01:28:28

まあ外部リンクに含めてくれるなら、誰かさんみたいに、ここに長文コピペするよりは大分マシかな

405 ：デフォルトの名無しさん：2010/11/06(土) 01:58:10

>>403のようなことを言うにはまだまだ環境に賢さが足りない。
本質だけを書いて申し分ない速度が得られるならそもそも言語ごとに速度の比較などしないのだ。

406 ：デフォルトの名無しさん：2010/11/06(土) 01:59:20

>>401
うちの環境(Python2.6)で、そのループ版と>>377を走らせてみたけど
ほとんど違いがないけど
両方8～9sといったところで、違いは誤差の範囲

もちろんCythonは速いだろうけど

407 ：デフォルトの名無しさん：2010/11/06(土) 02:00:48

配列とリストではデータ構造が違うから同じコードを比較してるとは言えない

408 ：デフォルトの名無しさん：2010/11/06(土) 02:05:40

Pythonのlistは配列ですけど

409 ：デフォルトの名無しさん：2010/11/06(土) 02:17:17

仕様さえ満たしていれば構造やロジックなんてなんでもいい。本質とは仕様をどう表現するかということ。
逆に言えば構造やロジックをどう書こうと、同じ仕様なら最適化後には同じになっていてほしい。

410 ：デフォルトの名無しさん：2010/11/06(土) 02:18:39

そんなバカな

411 ：デフォルトの名無しさん：2010/11/06(土) 02:22:53

環境がそこまで賢くなってなければ「コードには本質のみ」なんて言えないよなぁって言ってるだけ

412 ：デフォルトの名無しさん：2010/11/06(土) 02:27:13

よくわからない議論になっているな
>>403は、要するに出力部とかはいちいち書かんでいいい、という意味なのかと
思ったが

413 ：デフォルトの名無しさん：2010/11/06(土) 02:32:25

403の意図は知らんけど少なくともデータ構造とアルゴリズムは本質だと思うよ

414 ：デフォルトの名無しさん：2010/11/06(土) 02:35:17

まだ時代が早すぎたようだな

415 ：デフォルトの名無しさん：2010/11/06(土) 02:49:31

本質という言葉を濫用するからこうなるんだよ

書いたの俺だけどさ

416 ：デフォルトの名無しさん：2010/11/06(土) 04:07:35

いつからこのスレPythonスレになったの

417 ：デフォルトの名無しさん：2010/11/06(土) 04:10:50

痛信者さんが降臨してから

418 ：デフォルトの名無しさん：2010/11/06(土) 04:15:05

ネット監視厨が個人の使用感に激しく抗議したから

419 ：デフォルトの名無しさん：2010/11/06(土) 04:46:14

コピペバカが召還を続けてるから

420 ：デフォルトの名無しさん：2010/11/06(土) 07:56:33

エクストリームなクソ翻訳者は大人気だね
みんなバカぶりを見たくて仕方がないんだね

421 ：デフォルトの名無しさん：2010/11/06(土) 11:03:26

>>375
Pythonの書いたの俺だけど、
リストをくっつける処理で毎回コピーが発生するのが無駄だなと思いながら書いてた。
なんかうまいことジェネレータ書いたら、速くなるのかもしれん。

他の言語、そこらへんの処理どうやってるか読み取れなかったんだが、やっぱりコピーしてるの？
あるいは、LISPでいうところのconsみたいに、cdr部分をコピーせずにリストの連結してる？

422 ：デフォルトの名無しさん：2010/11/06(土) 11:15:36

>>401
リスト内包よりループの方が速いってこと？

423 ：デフォルトの名無しさん：2010/11/06(土) 11:48:03

>>422
>>406だが、うちでは>>377と>>401に有意な速度差はなかったよ
Python環境があるんなら、自分で試せばいい

424 ：デフォルトの名無しさん：2010/11/06(土) 11:50:41

OCaml
http://codepad.org/fjU4CJLb
ちょっとしんどかった

425 ：デフォルトの名無しさん：2010/11/06(土) 11:53:09

>>421
関数型のやつは基本的にconsだね
C#のやつのCons()はconsなんだけど、その後でToList()しているのでこれも無駄

426 ：デフォルトの名無しさん：2010/11/06(土) 12:42:24

>>420

427 ：デフォルトの名無しさん：2010/11/06(土) 12:46:56

>>382=>>420
ツッコまれたから読んだことない本を糞本よ呼ぶのはやめたんですねｗ良いことだと思います

428 ：デフォルトの名無しさん：2010/11/06(土) 13:00:39

>>424
tab をやめてスペースのみでインデントしたのは評価出きる

429 ：methane：2010/11/06(土) 14:25:20

>>422
ごめん、説明不足だった。
>>401みたいに書き換えたのは、>>377がそのままだとCythonでコンパイルできなかったから。
>>401と>>377はやってる処理は同じだし、実行時間も>>377とほぼ同じ。

>>377や>>401はC++のコードに比べてy座標をリストのインデックスではなく(x,y)のタプルで
管理しているし、しかも座標列をタプルで表してyが変わるたびにタプルの連結をしているから、
C++よりも処理は重いはず。
C++のコードを移植したら時間が 3/4 くらいには縮んだ。
http://codepad.org/ABj8FfkF

430 ：methane：2010/11/06(土) 14:34:36

>>429 のコードは判定部分で無駄なことしてた。
http://codepad.org/pkZ4sLPz
でも、このコードをCythonにかけてもなぜか >>401 のCythonより遅い。
このコードをベースにチューニングすれば>>402は超えられると思うけど。

Cythonは、平坦なPythonのコードがScala並には速くなる（しかも起動時間は速い）のが魅力。
JITコンパイルよりもAOTコンパイルの方が安定して性能が伸びて使いやすい。

431 ：デフォルトの名無しさん：2010/11/06(土) 18:15:23

RubyとかPerlにもCythonみたいなのあるの？

432 ：デフォルトの名無しさん：2010/11/06(土) 18:29:24

Cuby、Cerl

433 ：デフォルトの名無しさん：2010/11/06(土) 21:36:45

test

434 ：デフォルトの名無しさん：2010/11/07(日) 12:17:33

>>430
solveを回す回数を減らさない限り、軽くならないんじゃないかと思う。

435 ：methane：2010/11/07(日) 13:32:12

>>434
solve を回す回数はC++と同じだから、Cythonがちゃんと仕事してくれる（Pythonオブジェクトを回避して
Cで計算する）ようにしたらsolveを回す回数を減らさなくても軽くなるよ。
>>430 をベースに、Cython用に少し改造したら 0.05secになった。
http://codepad.org/aTEP7OpZ
元の2.2secから0.05secで44倍速くなってるから、>>375で言えばC++の2倍強の速度になる。
これはlistとかはPythonオブジェクトをそのまま使ってて、計算中にCのintで十分なところだけintに
してやった。
abs使うとPythonのabs使うために一旦Pythonの数値型に変換するところがCythonまだまだだ。

436 ：デフォルトの名無しさん：2010/11/07(日) 14:08:09

プロファイルとってみれば分かるが、一番のボトルネックは
枝狩りのためにテストしてるところ（そこがinnermost loopになってるので）

よって、>>430の改良がかなり効いてる（それだけで倍ぐらい速くなる）はずよ
もとのC++のコードは、そこで「無駄なこと」をしてるので、実は効率が悪い

まあ、Pythonでそこまでやる意味が俺にはわからないが…
素直に最初からC/C++で書いたほうがいいような状態だろう

ところでCythonってどんぐらい安定してるんだ？
>>401は0.13だとコンパイルできたが、0.12だとエラーになるのだが

437 ：436：2010/11/07(日) 14:35:28

ごめん、ちょっと勘違いだったみたいだ
そこの比較だけ変えても大した影響ないみたいだな

438 ：デフォルトの名無しさん：2010/11/07(日) 14:44:11

今のトレンドではもうC/C++は素直ではないんだろうな

空気読んでトレンドに従ってルールを守ることこそが「素直」で
それを無視したら統制がとれなくなって暴走すると思ってるから
そういう意味では、とても重要なことなんだ

439 ：methane：2010/11/07(日) 15:30:09

Cythonは普通は--embed使わないでPythonの拡張モジュールを書くのが目的だから、
たとえばPythonから使えるクラスをCで定義するのが面倒なときにCythonが便利というだけで、
上記のような計算の高速化はオマケだと思ってる。

ただ、PythonにはNumPyみたいに数値計算とか統計とかをするライブラリが充実しているので、
そういった目的でPythonを使っている人には、Pythonで作った計算関数を後から簡単に5倍10倍
高速に出来るのは魅力的だろうね。
上の例は計算目的が最初からはっきりしてたから最初からC++で書けば良いけど、
統計処理とかだとインタラクティブな環境で試行錯誤しながら関数を作り上げていけるPythonが
便利だろうから。

440 ：デフォルトの名無しさん：2010/11/07(日) 15:30:48

そういう処理って、LL上で軽量化しようとするのは不毛だと思うなぁ。

重い部分だけ別言語で書くってことが簡単にできる言語が、LLとしてはいいんじゃないの？

441 ：440：2010/11/07(日) 15:33:48

うげぇ、先に>>439見てりゃ書かなかったのに。。
確かに、C++で書くのさえ面倒な部分書くのにはいいかもね。

けど、CPythonで動かせないのがなんだかなぁ。
なんとか互換性保ったままできないのかなぁ

442 ：methane：2010/11/07(日) 15:53:58

>>441
CPythonで動かせるよ。CPythonの拡張モジュールを作るのがCythonの一番便利な使い方。
Cythonは、Cython用の（Pythonライクな）コードを、Pythonの拡張モジュール用のCコードに変換してくれる。

例えば >>435 では [].append を引数に渡しているけれど、実際に PyList_New でCPythonの
リストオブジェクトを作って、 PyObject_GetAttr で append 属性を取り出してっていう、CPythonの
拡張モジュールAPIを使ったコードに変換されている。
cdefで書いたsolve関数は高速だけど、Pythonから直接呼べない。
でもdefで書いたtest関数は普通にPythonから実行できるし、solveを呼びたかったらsolveをラップする
関数を def で定義したら良い。

443 ：デフォルトの名無しさん：2010/11/07(日) 16:07:43

どうでもいいけどCythonってなんて読むの？サイソン？

444 ：methane：2010/11/07(日) 16:11:51

http://video.google.com/videoplay?docid=8155731528590036456#
サイソンって発音してるね。
最近は発表を動画で公開する文化が定着していて、発音調べるときに動画検索ができて便利。

445 ：デフォルトの名無しさん：2010/11/07(日) 16:19:52

最初SQLを聞き取れなかったのを思い出した

446 ：デフォルトの名無しさん：2010/11/07(日) 16:36:59

>>435
さすがにもとのC++より速いってことはないみたいよ
ただ、ほとんど差は無い

両方gccの-O2でコンパイルして
うちでは
0.08sと0.11sぐらいです

447 ：デフォルトの名無しさん：2010/11/07(日) 16:41:53

CythonだとC/C++のヘッダを直接includeできないのが地味にめんどうくさい

Cのobjとリンクできる言語ならいくらでもあるし
ffiでCのコードよべる言語もいくらでもあるけど
ヘッダをとりこめないと、#includeの一行で済むことに手間をかけないといけない
C++の強みってけっきょくそこだと思う
その代償として言語仕様がカオスだけど

448 ：デフォルトの名無しさん：2010/11/07(日) 17:35:14

科学技術計算分野でC++のコンパイル手順が面倒という人であれば、
昔から CINT&ROOT が存在していた訳で、なんとなく無理矢理 Python へ結びつけようとする、
あるいは Python しか知らない素人の感想にしか聞こえないんだよな。
ここLL言語のバトルスレだよな？

449 ：デフォルトの名無しさん：2010/11/07(日) 17:44:24

他言語の話題は全くないな。Python以外はカスすぎてお話にならないってことか

450 ：デフォルトの名無しさん：2010/11/07(日) 17:45:11

>>448
いいえPythonスレです

451 ：デフォルトの名無しさん：2010/11/07(日) 17:58:59

>あるいは Python しか知らない素人の感想にしか聞こえないんだよな。

ウケタ

452 ：デフォルトの名無しさん：2010/11/07(日) 18:48:45

PythonやC#のリスト（配列）を使って関数型と同じアルゴリズムで書いてしまうと
>>421の指摘している理由によって効率がわるい
関数的なリストでは探索木が木として保持されるが
配列ではそれぞれの枝毎にルートからの配列を持つことになり無駄
この程度のサイズでは無視できる範疇だけれども

C++の方法は素直な深さ優先／バックトラッキングで
現在探索中の枝の状態しか持たないのでメモリ効率は最善
一方関数型の方法は、抽象度が高く並列化もしやすいはず

という感じですかね

俺もCythonまで持ち出して特定の言語でパフォーマンスチューニングを
延々やる意味がわからない
興味がある人は並列化を試すといいのでは

453 ：デフォルトの名無しさん：2010/11/07(日) 18:50:39

>>450
やっぱり、そうだっかw

CINTは(C++と比較すると)テンプレートの実装に難があるし、
STLはもちろんBoostも使えない。ただし、LL(軽量言語)として見れば、
95%のC/C++と互換性のあるインタプリタだし、
CINTでアルゴリズムを試行錯誤して、本番はC/C++でコンパイルするのは何ら支障は無い。

Boostみたいな最新の数値計算ライブラリは利用できないけど、代わりにROOTがある。

ありふれた単なるC/C++教育用の処理系ではなく、CERNでの導入/活用実績も十二分にある。
ちなみに、作者はRubyと同じく日本人だよ。(...と、餌を撒いておこうw)

数値計算分野に限定すれば、どうあがいてもPythonに勝ち目は無い。
もちろん「Pythonを使う事こそが目的」であるなら、スルー汁

454 ：デフォルトの名無しさん：2010/11/07(日) 18:51:54

数値計算でLLって…

455 ：デフォルトの名無しさん：2010/11/07(日) 19:00:02

ここ最近、ずっと性能、性能、性能....の話題ばかりだよね
というか、PHP/Rubyに対するPythonの絶対的優位性って、性能くらいしかないんだろ

Zopeは派手にコケちまったし、今さらWebプログラミングでPHP/Railsを超えるのは無理でそ
せいぜい、GNUの公式LLとして選ばれた事をネタにオナるのが、いいとこなんじゃないのかな

456 ：デフォルトの名無しさん：2010/11/07(日) 19:05:47

オナるネタもねえ低性能言語が下品な批判を続けてるってことか？

457 ：デフォルトの名無しさん：2010/11/07(日) 19:12:31

SciPy/NumPyって数値計算分野じゃかなりメジャーだと思うんだけど
むしろそのためだけにPython使ってる人が多いくらい

458 ：デフォルトの名無しさん：2010/11/07(日) 19:20:20

PHPやRubyみたいなWebプログラマはオナる余裕が無いからね

LLとしてPythonに手を出すくらいなら先にJavaScripyだし、Rubyなら最新の1.9とRails3で手一杯だろ
いまさら、派手コケしたPythonに関わるのは面倒なだけ
Pythonでやれることの大半は、Ruby/Perlで済む

Webの世界だと、PythonエキスパートによればGoogleに採用された事が自慢らしいから、
性能の話題と合わせて、それもこのPythonスレのオナネタにして夢を見てればいいんでないかい？

PHP/Railsプログラマは関わってられまへんw

459 ：デフォルトの名無しさん：2010/11/07(日) 19:31:30

JavaScripyってPython関係の言語？

460 ：デフォルトの名無しさん：2010/11/07(日) 19:31:42

ユーザーの数 / 自分の言語が良いと吠える信者の数 = 言語の良さ

これ豆

461 ：デフォルトの名無しさん：2010/11/07(日) 19:33:19

>>458
やっぱWebプログラマみたいな底辺ってお前みたいにオナオナ言ってる奴ばっかりなの？

462 ：デフォルトの名無しさん：2010/11/07(日) 19:40:02

そう。Webでつぶやいてる自称Pythonエキスパートと同じだよ。

463 ：デフォルトの名無しさん：2010/11/07(日) 19:45:43

Pythonプログラマとは違うってさっき言ったじゃんｗ

464 ：デフォルトの名無しさん：2010/11/07(日) 19:54:15

日常のWebプログラミングに追われてるから、自称エキスパと違って、つぶやく余裕も無いって事w
そこまで必死になる必要がないから
というか、Ruby1.9/Rails3/CSS/HTML5/JavaScript2.0...etc 勉強する事が山ほどあって、
つぶやく暇なんてありまへん

Pythonプログラマがうらやましいッスw

465 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 20:07:10

お前みたいな　やりたいことが山ほどある　小僧は死ね

知識をつけたい　とか　色々やりたい
日々勉強　などツイッタで自己紹介しとけよ

466 ：デフォルトの名無しさん：2010/11/07(日) 20:08:27

わろた
だけど、確かにやりたいことがあるなら２ch見てる場合じゃねーよな

俺はいろいろ諦めたけどw

467 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 20:09:01

だからしね

468 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 20:13:17

お前みたいなカスは
マック使ってんだろうな

>>というか、Ruby1.9/Rails3/CSS/HTML5/JavaScript2.0...etc 勉強する事が山ほどあって、
だいたいこんなキモいweb系やってるってことは
すべてがマックのターミナルから始まったでしょ

君のwが半角な時点でクソマカかLinuxインストール厨房を物語ってるよ

469 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 20:19:19

Python使ってるやつは

厨房が好きな飲み物　無糖ブラックコーヒーってわめくほどの痛さ

470 ：デフォルトの名無しさん：2010/11/07(日) 20:22:15

>>464が暇じゃなくて誰が暇なんだ

471 ：デフォルトの名無しさん：2010/11/07(日) 20:23:37

わたしです＾o＾

472 ：デフォルトの名無しさん：2010/11/07(日) 20:25:53

実際そうだろうなあ。Webプログラマなんて奴隷と同じだし
まあ、そういう可哀そうな話はマ板でやれよ
しかし、言語の話をしようにもPython以外は奴隷で議論に参加できないのか(´・ω・)ｶﾜｲｿｽ

473 ：デフォルトの名無しさん：2010/11/07(日) 20:27:41

まだスレの中盤だぞ
早漏乙

474 ：デフォルトの名無しさん：2010/11/07(日) 20:34:53

>>469
コテハン12級のくせに偉そうにするな！

475 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 21:23:30

だってPython使ってるやつ低レベルしかいねえよな

クロールがどうたらとかわめいてるバカみたいなかすばっかり

476 ：methane：2010/11/07(日) 21:27:57

>>453
Cythonネタ引っ張りすぎたな。反応があったからつい。

もちろん、分野や条件を限定すればPythonより良い言語はあるだろう。
WindowsでGUIアプリを作るならPythonよりもC#をオススメするし、
Webプログラミングに興味を持ってる初心者にはPHPをオススメする。

Pythonは汎用言語で、Webプログラミングも数値計算もGUIアプリもスクリプティングも
こなせる、しかもいくつかの分野では専用言語にも引けを取らないのが魅力。
すでにPythonでGUIプログラムを作れる人が、ちょっとWebアプリ作るとか、
ちょっと数値計算するとか、そのたびにいちいち専用言語を覚えなくても良い。

メジャーなLLの中ではPythonが一番広い分野で使われていると思う。

477 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/07(日) 21:37:24

「みんな使ってる」に弱い人種だろWEB系なんて

478 ：デフォルトの名無しさん：2010/11/07(日) 21:50:18

性能の話はするなって>>455が言ってるだろ

479 ：デフォルトの名無しさん：2010/11/07(日) 22:30:42

>>476
要するに、

　Pythonとは、何でもできるけど、何一つ結果を残せない器用貧乏な言語

ってことね。

>>476の応用分野は、すべてRubyでも(Perlでも)可能、あるいは得意分野だし。
あえて(Rubyと比較して)Pythonの優位性をとけば、ちょっと速くてWindows対応に優れていること
くらいじゃないのかな。あと構文が簡潔だから、中高生/文系学部の教育用言語には適しているね。
ただし、GUIであれば、Ruby/TkとRuby-GNOME2という拡張ライブラリの作者は日本人だから、
日本語のドキュメントは豊富でサポートも安心できるし、Webプログラミングであれば、
Rails vs. Zope で誰の目から見ても結果は明らか。また、

>メジャーなLLの中ではPythonが一番広い分野で使われていると思う。

とあるけど、推薦図書/必読図書スレ 57 によれば、世界的に見て Pythonユーザ数(34508タグ)と
Rails + Rubyユーザ数(20050 + 13617タグ)は、ほぼ同数。Python派の口癖は

　ruby が普及してるのは日本だけ、全世界的には python が圧倒的！

だったけど、これも否定された。結局、どれも主観あるいは無知からくる誤認な評価ばかりだよ。

480 ：デフォルトの名無しさん：2010/11/07(日) 22:38:29

要するに、

　物は言い様

ってことね。

481 ：デフォルトの名無しさん：2010/11/07(日) 22:40:32

そう。Webでつぶやいてる自称Pythonエキスパートと同じだよ。

482 ：デフォルトの名無しさん：2010/11/07(日) 22:42:51

>Pythonユーザ数(34508タグ)とRails + Rubyユーザ数(20050 + 13617タグ)は、ほぼ同数。

こりゃ詭弁だ。重複はねえのかよ

483 ：デフォルトの名無しさん：2010/11/07(日) 22:44:46

インデント吹いた
書式としては、確かに優秀かもなｗ

484 ：デフォルトの名無しさん：2010/11/07(日) 22:48:32

ところで、あえて自称Pythonエキスパートなmethane氏に質問したいのだけど、

　なぜZopeはRailsのようにWebの世界で成功を収めることに失敗したのか？

に答えて欲しい。前スレでも質問したけどスルーされちまったんだよな。エキスパートならZopeは知っているよね。

それほど(思わずツブヤいてしまうほど)Pythonが優れているのなら、Zopeは成功していたはずなんだけどなぁ....。
当時は(SoftwareDesigin誌だったかな？)では「次世代のWebフレームワーク」として派手に登場し、
世間で大いに騒がれていたように記憶している。でも現実には後発のRailsがリーダーシップを握ってしまった。
それとも自称Pythonエキスパートにとって、Web技術は無視すべき存在なのかな？

　もっと現実を見ようよ by ドラエモン(AA略

それともPythonコミュニティにとってZopeは禁句なのかな？まあ、暇なのはうらやましいけどねw

485 ：484：2010/11/07(日) 22:51:31

日本語が変だね。
>　なぜZopeはRailsのようにWebの世界で成功を収めることに失敗したのか？

以下のように訂正。

　なぜZopeはWebの世界で成功を収めることに失敗したのか？なぜRailsに負けたのか？

486 ：デフォルトの名無しさん：2010/11/07(日) 22:54:28

Rails vs. Zope　ってｗ
普通比べるならDjangoだろ、お前の頭は何年前でとまってるねんｗ

487 ：デフォルトの名無しさん：2010/11/07(日) 22:54:55

(思わずツブヤいてしまうほど)

おちおち呟いてられない世界かよｗ

488 ：デフォルトの名無しさん：2010/11/07(日) 22:55:01

横からだが、Zopeってhttpサーバは同梱なの？
rakeのような、スケルトンジェネレータその他多機能コマンドは同梱なのかな

もしそうじゃなければ、それらが決定的な差になった可能性はある
そこは、言語どうこうじゃなく、ユーザビリティの差だろう

489 ：デフォルトの名無しさん：2010/11/07(日) 22:56:50

google trend見てみろ、どれだけRailsのバブルが崩壊してるかわかるよｗ

490 ：デフォルトの名無しさん：2010/11/07(日) 22:58:30

>>488
覚えたての単語ならべて偉そうに言ってると恥じかくよ

491 ：デフォルトの名無しさん：2010/11/07(日) 22:58:38

エキスパートPythonさんを召還しないでください
同じPython使いからも煙たがられているエキスパート厨房なんです

492 ：デフォルトの名無しさん：2010/11/07(日) 23:01:28

なんとなく分かるのは、RubyにはRailsしかないってことと、Rubyユーザは英語が苦手だってことかな

493 ：デフォルトの名無しさん：2010/11/07(日) 23:02:03

>>490
そんなつもりは無かったんだけど
Zopeを知らないのは確かだからごめん

494 ：デフォルトの名無しさん：2010/11/07(日) 23:06:00

Rubyは基本性能悪すぎ

495 ：デフォルトの名無しさん：2010/11/07(日) 23:06:59

メジャーなプログラミング言語で英語が得意なユーザーが多いのってなにがあるん？

496 ：デフォルトの名無しさん：2010/11/07(日) 23:09:43

>>488が言いたいことはなんとなくわかるが、
>>490-492が指摘したいことはまったくわからない

497 ：methane：2010/11/07(日) 23:10:49

俺はWebからPythonに入ったんじゃないしZope触ったことが無いんだけど、とりあえずZopeの
解説を流し読みした個人の感想では、ZODBとかいうデータストア使っている時点で使いにくいと思った。

データストレージはメンテナンスに非常に気を使う部分で、メインのデータストレージはやっぱり
MySQLとか信頼できてメンテナンスのノウハウがあるものを使いたい。
多分、ZopeはLAMPという言葉が一般的になる以前の設計なんじゃないかな？

全く触ってない第三者としての感想なので話半分で。

498 ：デフォルトの名無しさん：2010/11/07(日) 23:11:55

>>496が指摘したいことはまったくわからない

499 ：デフォルトの名無しさん：2010/11/07(日) 23:13:28

>>442
cdefってあったら、CPythonじゃSyntaxErrorでるけど。
そこ消して何か別のものに差し替えるの？

>>447
拡張子を.py.cにして、
python foo.py
の代わりに、
gcc -E -P foo.py.c | python
で実行する。
コメントは#じゃなくて//で始める。

500 ：methane：2010/11/07(日) 23:15:30

>>499
いや、Cython queen.pyx したあとに、 gcc `python-config --cflags` queen.c -o queen してから、
Pythonで
>>> import queen
>>> queen.test()
ってしてみて。

501 ：デフォルトの名無しさん：2010/11/07(日) 23:15:54

>>498
むだに意地張ってるんじゃねえよ
>>496で指摘してるのは、>>496には>>490-492の意味がわからないっていうことだけだろうが
うまいこと書いたつもりで馬鹿書いてるよあんたｗ

502 ：デフォルトの名無しさん：2010/11/07(日) 23:19:26

>>452
そう思って、コピーの代わりにitertools.chainでつなげることも試してみたけど、
そんなに大きい配列じゃなかったらかなぁ。逆に効率が悪かった。
コピーには時間かかるけど、たどるのは楽なんじゃないかなぁ。

503 ：デフォルトの名無しさん：2010/11/07(日) 23:19:35

>>501が指摘したいことはさらにわからない

504 ：デフォルトの名無しさん：2010/11/07(日) 23:20:21

エキスパートPython信者キモイ(ww

505 ：デフォルトの名無しさん：2010/11/07(日) 23:20:25

>>501
同じレベルで>>496は馬鹿だと思うよ。ああ、コイツ日本語すら読めないんだなって。

506 ：デフォルトの名無しさん：2010/11/07(日) 23:21:27

餓鬼が二人いることだけはわかる

507 ：デフォルトの名無しさん：2010/11/07(日) 23:22:34

もう何でも分からない言うバカはつまみ出せ

508 ：デフォルトの名無しさん：2010/11/07(日) 23:24:46

>>479
Ruby/TkとRuby-GNOME2のドキュメントって、結局TkとGNOME2のドキュメントに当たらないといけなくなってどうせ英語じゃんってことはないの？

509 ：デフォルトの名無しさん：2010/11/07(日) 23:26:57

>>500
なるほど。そういう風にするのか。thx

510 ：デフォルトの名無しさん：2010/11/07(日) 23:28:31

GUIでRubyは絶対ないなｗ

511 ：デフォルトの名無しさん：2010/11/07(日) 23:31:22

RubyでRoRが当たったのってそれしか選択肢がなかったのが
少ない人材リソースながら選択と集中的効果を出したんじゃないの。
べつに言語が優秀だとかそういう話じゃないよ。

512 ：デフォルトの名無しさん：2010/11/07(日) 23:36:18

この場合の問題は、「RubyでRoRが当たった」わけではなく、
Java、Perl、Pythonその他も含めたWEBフレームワークとして
RoRが当たったってことなんだと思うんだけど

513 ：デフォルトの名無しさん：2010/11/07(日) 23:38:56

>>502
itertoolsでチェインしたら、ただのlinked listであるconsリストより
そりゃ効率は悪いんじゃないかな

consリストもあると嬉しいんだけど、なんで無いんだろうね
JavaやC#にはLinkedListもあるけど、これも全然役に立たないし

514 ：デフォルトの名無しさん：2010/11/07(日) 23:41:20

>>511
DSL的な拡張がし易かった、ってのがRoRが生まれた一因なんじゃないかな。
やり方次第でほとんど別の言語みたいな環境が作り出せる、ってのは
Rubyの長所でもあり、短所でもあると思う

515 ：デフォルトの名無しさん：2010/11/07(日) 23:43:19

>>492
英語が苦手な人が多いのはそうだと思うが
Railsしか無いってのは確実に誤りだと思うぞ
というかそもそもRubyの得意分野ってWebじゃなくてテキスト処理じゃね？
Perlもそういう勘違いされてるがあれも本来はテキスト処理言語だし

516 ：デフォルトの名無しさん：2010/11/07(日) 23:43:57

よくしらないけど、DSL記述能力の違いじゃないのかなー

Webではデータを右から左に流すような、似たような仕事を楽チンに書きたいという
需要がとても多いのではと推測するんだけど
そういうユースケースではDSLがとても有用なのでは

↓というわけで以下マクロの話

517 ：516：2010/11/07(日) 23:45:05

ありゃ、>>514を見てなかったｗ

518 ：デフォルトの名無しさん：2010/11/07(日) 23:45:09

>>511
選択と集中って素晴らしいじゃないですか。

教育用言語で、この素晴らしい考え方をどうやって教えるつもりですか？
それとも、教える気なんてないの？

519 ：デフォルトの名無しさん：2010/11/07(日) 23:46:49

それらは、RoRがRubyで書かれた理由にはなっても、
RoRが当たった理由にはならんだろう
このスレ住人の意識がそっちにはいかないだけなのか、
意図的にずらしてるのかよくわからない流れだ

520 ：デフォルトの名無しさん：2010/11/07(日) 23:47:12

>>518
何言ってんの？

521 ：デフォルトの名無しさん：2010/11/07(日) 23:47:29

選択と集中って、馬鹿の一つ覚えと同義だよねｗ

522 ：デフォルトの名無しさん：2010/11/07(日) 23:50:07

>>519
当たったのは、宣伝とかの話をのぞけば、
それが優れたデザインで開発が楽だと思われた、アピールできたからじゃないの
が、何もない土壌にそういうものは生まれないわけで、その土壌が
DSLだという話なのでは

523 ：デフォルトの名無しさん：2010/11/07(日) 23:53:44

>>520
教育用だとか、初心者がいちいち専用言語を覚える必要がないとか書いていたから
胡散臭いと思って聞いてみたんですが
やっぱり教育なんてどうでもいいんですよね

524 ：484：2010/11/07(日) 23:54:11

>>497
レスありがとう。

当時を振り返ると、LAMPというキーワードこそ存在していなかったけど、Linux/BSD上でPHPとRDBを動かす
いわゆる「WEB-DB連携」は、そこそこ普及していた。その一方で、過去に大いに期待を集めたOODBは
既に衰退しつつあった。そんな背景の中で、現実のRDBを選択せずOODBを実装したという、ありがちな
自己の技術力を過信するあまり「マクロ的な技術動向」を読めず敗退した例ということなんでしょうね。

もしもその時点でZopeデベロッパがストレージとしてRDBを選択していたら、時代は変わっていたのかもしれない。

525 ：デフォルトの名無しさん：2010/11/07(日) 23:55:48

>>523
教育用って、なんの教育？

526 ：デフォルトの名無しさん：2010/11/07(日) 23:57:52

PythonでもVBでも思うけど、教育用とか言うのは結構だけど
実務と一緒くたにするなよ。それはRubyやPerlで教育しても同じことだろ

527 ：デフォルトの名無しさん：2010/11/07(日) 23:59:53

実務というか、実例が必要。
"generalizing from no examples at all" にならないために。

528 ：デフォルトの名無しさん：2010/11/08(月) 00:01:11

アンチpythonのruby厨が発狂してるだけだな

529 ：デフォルトの名無しさん：2010/11/08(月) 00:02:34

ウェブプログラマーだったDHHが
自分の経験を元にRubyで書いたWebフレームワークがRoR
RoRの成功した理由はともかくとして、そもそもなぜDHHはRubyを選んだかというと

＞私は達人プログラマの2人とMartin Fowlerの大ファンなんですけど、それも関係していますね。
＞彼らから何度となくRubyの話を聞くんです。
（中略）
＞Rubyは、それはもう、ものすごくフィットしたんです。私の脳に完璧にフィットしました。
http://capsctrl.que.jp/kdmsnr/wiki/transl/?AnInterviewWithDHH

Pythonはよく知らなかったと語っている
……まあその、きっかけがあるのは大事という話になるｗ

530 ：デフォルトの名無しさん：2010/11/08(月) 00:06:13

教育用言語は必要だと思うが、現状では乱立し過ぎだな。
教育用言語を名乗る言語は数あれど
実際に多くのプログラマが学ぶ共通語ってのが無い。

531 ：デフォルトの名無しさん：2010/11/08(月) 00:09:56

結局Javaがそれに一番近いという現実がありそうな＞教育用

532 ：デフォルトの名無しさん：2010/11/08(月) 00:11:34

VBは出自がBASICというだけで、もはや教育用でもなんでもないような気が
Pythonも教育用に使われてるだけで、そのために設計された言語じゃないよ
ttp://www.rakunet.org/TSNET/TSpython/35/1067.html
教育用というとSqueakが一番に思い浮かぶ

533 ：デフォルトの名無しさん：2010/11/08(月) 00:11:35

教育用っていうと、processingとか？

534 ：デフォルトの名無しさん：2010/11/08(月) 00:14:02

教育用言語といったらschemeだろう。
黒板がもっとも普及してる実装なんだし。

535 ：デフォルトの名無しさん：2010/11/08(月) 00:16:16

あー、情報処理試験にも出て、現代の主流であるOOPが一通り出来て
メモリ管理とかはあまり気にせずに扱えて、Javaで書かれた書籍が結構あって
実務でも趣味でもそこそこのシェア、か。
なるほど、確かにJavaがその位置に居るのかも知れんな。

処理速度がイマイチで、色んな環境で使われるってのも昔のBASICを思い出すなw

536 ：デフォルトの名無しさん：2010/11/08(月) 00:16:41

>>508
Ruby/Tkについては、ググレば見つかるけど作者のWikiの他、ネットに日本語の情報が有るし、書籍も２冊あるから、
ほぼ英語は不要と言える。後、何か問題があっても、Ruby公式MLで質問すれば、過去に何度も作者自身が
的確かつ新設に対応してくれている。これの魅力は大きい。

Ruby-GNOME2は詳しく知らないが、公式ページには、一般的な３ペインのメーラや2chブラウザなら書けるくらいの
日本語情報は揃っている。また、作者が日本人だから日本語の公式MLもある。

もちろん本格的なアプリ開発であれば英語は必要になるけど、「最初の一歩」が日本語で済むっていうのは、
初心者はもちろん、熟練者にとっても魅力ではないかと思う。英語がペラペラな人でもない限り。
これらは、どちらもGUIプログラミングにおける「Pythonには無い、Rubyの魅力」だよ。

さあ、これに対して、「Rubyには無い、Pythonの魅力」を大いに語ってくれ。
Windows対応の良さとか、他にもあるはずだと思う。

537 ：デフォルトの名無しさん：2010/11/08(月) 00:18:52

>>534
ラムダ計算の授業では、黒板がカッコで大混乱に陥った記憶がある
Schemeも似たような理由で
あまり向いているとは思えないが……エディタの支援がないと

538 ：デフォルトの名無しさん：2010/11/08(月) 00:20:38

Lispとかは黒板に手書きする場合は
カッコを適当に省いてインデントで構造を表すのかと思ったけど
そうでもないのか

539 ：デフォルトの名無しさん：2010/11/08(月) 00:22:35

>>536
>>455、>>458、>>479

540 ：デフォルトの名無しさん：2010/11/08(月) 00:22:47

教育用言語ちゅーたらPascalだろ

541 ：デフォルトの名無しさん：2010/11/08(月) 00:23:56

Schemeといえば黒板、というネタをいいだしたのって、黒田さん？

542 ：デフォルトの名無しさん：2010/11/08(月) 00:23:57

フォートラン

543 ：デフォルトの名無しさん：2010/11/08(月) 00:26:17

>>536
逆に英語の情報が異常に充実してるっていうのはメリットになるかも >Python
英語さえ厭わなければ大抵の疑問はググると答えが見つかる
しかもコミュニティの気風として中途半端な答えだとすぐにツッコミが入るからS/N比が良い

544 ：デフォルトの名無しさん：2010/11/08(月) 00:27:49

>>539
その３つ、すべて漏れのカキコなんだけどw
しかも、どれも決定的な優位性じゃないし

他には無いの？ Pythonには XXX ができるけど、Ruby じゃできない！ってネタ

545 ：デフォルトの名無しさん：2010/11/08(月) 00:28:36

>>479ってStackOverflowのタグ数か
あれはその場限りのお遊びデータとして貼ったのに
そういうナイーブな使い方をされるとは正直思ってなかった

546 ：デフォルトの名無しさん：2010/11/08(月) 00:31:20

>>544
日本語が決定的な優位性と思ってる人には
pythonのとっつきやすさ、導入のしやすさは十分決定的なはずだけど

547 ：デフォルトの名無しさん：2010/11/08(月) 00:35:44

>>546
そのPythonのとっつきやすさってのはなにを基準に主張してるんだろ
ある程度のとっつきやすさや導入のしやすさは、このスレで対象に
している言語はみんな持ってるんじゃね？

まったくの素人が一番とっつきやすいのは、ブラウザに搭載されている
JavaScriptだったり、Windowsでシェルスクリプトを書けるVBScriptだったり
するわけで

548 ：デフォルトの名無しさん：2010/11/08(月) 00:41:54

JavaScriptやVBScriptがとっつきやすいと感じるのは素人じゃないよ

549 ：544：2010/11/08(月) 00:54:52

>>546
その「if 日本語が決定的 then Pythonはとっつきやすい」という論理展開について、具体的な例をあげてくれ。
第三者から見て(感覚的に)分かる例を。でないとコメントのしようがない。>>544では具体例を挙げているよね？

550 ：デフォルトの名無しさん：2010/11/08(月) 00:59:26

>>548
いや、一見してJavaScriptやVBScriptがとっつきやすいように感じてしまうのは、素人だったりする。
Rubyの動的な性質は良くも悪くも指摘される事だけど、これらはプロトタイプベースの言語だから、
Ruby以上に変態的に動的な性質がある。構文が単純だから入門用だと感じるのは、まだまだだな。

551 ：デフォルトの名無しさん：2010/11/08(月) 00:59:46

>>548
んなことはない
「開発環境」って言われて少しも引かない素人はいない、と思う
Windowsのメモ帳でできるよ、っていうのは決定的な導入のしやすさじゃないのかな
俺が知らないだけで、Pythonのインストールって、例えばActivePerlのインストールより
決定的に簡単なのか？

開発環境まで含めて考えると、少なくともWindowsでは、やっぱりJavaもしくはC#なんかが
Pythonより遙かにとっつきやすい気もしないでもないが

552 ：デフォルトの名無しさん：2010/11/08(月) 01:01:07

「最初の一歩」が日本語だから良いって
Pythonでも他の言語でも英語が分からなくて「最初の一歩」で苦労したなんてあんまりないな
だって日本語の入門資料なんてそこらへんにあるでしょ

>>550
日本語で書いてくれ

553 ：デフォルトの名無しさん：2010/11/08(月) 01:07:58

>>551
お前が前提としてるのがインストールすらできないアホなのか
VisualStudioもなんなく扱える奴なのか分からん

554 ：デフォルトの名無しさん：2010/11/08(月) 01:08:13

>>550
ちょ、ちょっとまって
JavaScriptはともかく
VBScriptがプロトタイプベース？

555 ：553：2010/11/08(月) 01:13:53

>>553
んだね。確かによく分からんな
一応、ソフトのインストール・アンインストール含めたWindowsの操作が一通りできる人間、が前提

>>546の「導入のしやすさ」の前提がよくわからんので書いた例として捉えてくれ

556 ：551：2010/11/08(月) 01:15:39

あれ？名前間違った。>>553ｽﾏｿ

557 ：デフォルトの名無しさん：2010/11/08(月) 01:18:43

Rubyの日本語に別段優位性はないってレスだろ言わせんな恥ずかしい

558 ：デフォルトの名無しさん：2010/11/08(月) 01:20:08

素人に「開発環境」って言ったらむしろワクワクすんじゃね？

559 ：デフォルトの名無しさん：2010/11/08(月) 01:21:46

eclipseのことですねわかります

560 ：デフォルトの名無しさん：2010/11/08(月) 01:34:49

>>552
まず一般論として、自分は英和辞典を前提にすれば技術英語を何とか読める程度の英語力しかないから、
新しい事(たとえば形式的仕様記述とか高階型推論とか)を勉強しようとする時、
まずはざっと日本語のサイトを軽く読み通し、(もしあれば)日本語の入門書を購入する。
そうして概念の全体像を何となく把握した上で、英語のサイトや論文/書籍に取りかかる。

それが苦にならない>>552とかは、英語に自信があるか、既にかなりのスキルがあるってことではないかと。

で、この文脈での話題はGUIプログラミングについてなんだけど、たとえば以下のリンクはRubyの場合。
しかも(>>536で書いたように)公式な日本語MLがある。

・Ruby/Tk Wiki(作者の個人ページで公式なものではない)
　　http://www.dumbo.ai.kyutech.ac.jp/nagai/RubyTk/
・Ruby-GNOME2公式ホームページ
　　http://ruby-gnome2.sourceforge.jp/ja/

これらを超える情報を提供してくれる日本語の解説サイトって、Pythonにはあるの？
また公式な(Binding開発のコアメンバが対応してくれる)MLって、Pythonにはあるの？

具体例が無ければ、>>552の主観的な「かんそうぶん」にしか読めないなよ。
それとも「俺の考えに誤りは無い」あるいは「俺の考えは言わなくても相手は理解できる」っていう
独善的なのがPythonコミュニティの特性なのかな？(なんかPython派ってそんな人ばかり....)

561 ：デフォルトの名無しさん：2010/11/08(月) 01:44:23

× 読めないなよ
○ 読めないなり

562 ：デフォルトの名無しさん：2010/11/08(月) 01:44:27

まずはざっと日本語のサイトを軽く読み通し、(もしあれば)日本語の入門書を購入する。
そうして概念の全体像を何となく把握した上で、英語のサイトや論文/書籍に取りかかる。

これは一般論なのか、これが苦になるのは一般論なのか
お前の個人的な感想だろ

563 ：デフォルトの名無しさん：2010/11/08(月) 01:48:37

>>560
http://www.shido.info/py/index.html
http://www.geocities.jp/m_hiroi/light/#python_tkinter

564 ：デフォルトの名無しさん：2010/11/08(月) 01:55:33

>>513
consよりは悪いと思うが、コピーはしなくなる。

565 ：デフォルトの名無しさん：2010/11/08(月) 01:56:35

>>562
うん、確かに上段は自分の感想だよ。でも、それは英語が苦手な人に共通な「一般論」だと思うんだけど。
逆に、未知の概念について、いきなり英語でも無問題な>>552が特殊なケースなのでは？と主張している。

　Do you undestand?

あと、結局はPythonのGUIライブラリについて、具体例(日本語の解説サイト等)は示してもらえないのね。
それって、結局は

　英語が不得意な人にとって、GUIプログラミングに関して(Pytonよりも)Rubyのほうがとっつきやすい、

って事を>>552,562が(間接的に)認めたことになるんだけど....。
間違いは誰にでもあるんだから、素直にそれを認めればいいのに。だからPython派ってのは.....アレなんだよ。

566 ：デフォルトの名無しさん：2010/11/08(月) 01:58:03

示したじゃん

567 ：デフォルトの名無しさん：2010/11/08(月) 01:59:18

>>563
上は、いわゆる恥pyの人のサイトか

http://www.shido.info/py/python1.html
Pythonが参照渡しだとか
Pythonの関数名が関数へのアドレスをあらわすだとか
面白いサイトだよな

568 ：デフォルトの名無しさん：2010/11/08(月) 01:59:21

RubyでGUI？冗談よしこさん

569 ：デフォルトの名無しさん：2010/11/08(月) 02:00:18

>>560のサイトは面白くも糞もないね。英語サイトを翻訳したのかよって感じだし

570 ：デフォルトの名無しさん：2010/11/08(月) 02:02:29

Do you understand とか失礼なこと言うやつは
いくら叩いても構わないと思うが
Ruby/Tk の人を叩くのはやめてあげてマジで

571 ：デフォルトの名無しさん：2010/11/08(月) 02:02:37

日本でRubyでGUIって実はツクールが最大勢力なんじゃね？
とか思ってるんだが偏見だろうか

572 ：デフォルトの名無しさん：2010/11/08(月) 02:04:19

>>570
Do you understand何て言ってない。Do you undestand?だ

573 ：デフォルトの名無しさん：2010/11/08(月) 02:06:25

>>563
その程度のページでいいのなら、Ruby/Tkにもありますよ。
・Ruby/Tkチュートリアル
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Ruby%2FTk+%A5%C1%A5%E5%A1%BC%A5%C8%A5%EA%A5%A2%A5%EB
・逆引き Ruby/Tk
　　http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=%B5%D5%B0%FA%A4%ADRuby%2FTk
・Ruby/Tk サンプルプログラム集
　　http://www.mnet.ne.jp/~tnomura/tksample.html

574 ：デフォルトの名無しさん：2010/11/08(月) 02:06:52

>>567
rubyを酷評してるから根に持ってるのかｗ

575 ：デフォルトの名無しさん：2010/11/08(月) 02:08:11

>>574
いや、恥pyの人は主にPythonユーザに評判が悪いと思っていたのだが...
Pythonについて書いてること大嘘だし
Rubyの人は知りもしないんじゃないの？

576 ：デフォルトの名無しさん：2010/11/08(月) 02:08:26

>>510
あるよ
http://hibari.2ch.net/test/read.cgi/tech/1269609576/

577 ：デフォルトの名無しさん：2010/11/08(月) 02:11:09

>>572
つまんないとこにケチをつけるなあと自分でも思わない？
失礼な表現だってことに違いはないのに

578 ：デフォルトの名無しさん：2010/11/08(月) 02:12:52

>>573
それがRubyにあってPythonにないものなの？それで、よしRubyを使おう、と思うの？
Pythonを使う理由は、あるいはRubyを使わない理由はそこだとRubyの人は思ってるの？

579 ：デフォルトの名無しさん：2010/11/08(月) 02:13:06

Python厨は、揚げ足取りしかできねえのかよw
GUIならTkinterよりもWindowsサポートを攻撃したほうが効果的だぜ
Ruby厨じゃ反論できねえから

580 ：578：2010/11/08(月) 02:14:10

ありゃ日本語が変になった。まあいいや
つまりRubyの人が重要視してることが、本当に重要なのかと言うこと

581 ：デフォルトの名無しさん：2010/11/08(月) 02:14:57

>>579
はい。Pythonの優位性はWindowsサポートです。Python大勝利。Ruby厨発狂死亡ｗｗｗ

582 ：デフォルトの名無しさん：2010/11/08(月) 02:17:13

読んだことない本を糞本呼ばわりするRuby厨よりはマシ

583 ：デフォルトの名無しさん：2010/11/08(月) 02:23:32

>>560
http://ruby-gnome2.sourceforge.jp/ja/hiki.cgi?GLib::Object
これのどこが日本語だって？

584 ：デフォルトの名無しさん：2010/11/08(月) 02:26:55

どっちの日本語サイトが充実してるかどうかなんてみみっちいドングリの
背比べなんかどうでもいいだろ

585 ：デフォルトの名無しさん：2010/11/08(月) 02:28:21

奥ゆかしいんだか何だか知らないが、Perl, PHP, Rubyの人ここでコード書かないな
せっかく今Rubyの人いるみたいだから
なんか書いてよ

586 ：デフォルトの名無しさん：2010/11/08(月) 02:30:13

アンチPythonのエキスパートであって、Perl, PHP, Rubyのエキスパートではないんだろう

587 ：デフォルトの名無しさん：2010/11/08(月) 02:32:33

バインディング作ってくれてる人は偉大だけど。
出来のいいバインディングならバインディングのドキュメントより元ライブラリのドキュメントの方が役に立つことになる。
なので、それが日本語でもあんまり役に立たない。

UbuntuのRubyバインディングQtみたいに、なぜか落ちる(もう直った？落ちて使えなくて使うのやめた)とかだと、MLが日本語だと原因探りやすいが。

588 ：573：2010/11/08(月) 02:34:07

>>578,580
いや、大差は無いと考えていますよ。もしTkinterのサイト紹介が無くても、Rubyが決定的に優位とまでは言えないと。
ただ、作者が日本人で直接会話できるのは(英語が不得手な人には)魅力かな？という程度で、
しかもRuby/Tkは作者のWikiで(整理されていないけど)かなりの情報が提供されてるから、(Tkについては)やや有利かな。
いずれにせよGUIアプリ開発者の熱意があれば、(英語の問題を含めて)とっつきやすさにRubyとPythonで差は無いと見てる。

589 ：デフォルトの名無しさん：2010/11/08(月) 02:36:18

>>586
別にエキスパートしかコード書いちゃいけないわけじゃないでしょｗ
上の流れとか、その辺の言語も誰か書くだろうと思ってたのに誰もかかないまま
例の人が一人で頑張りだしたから何だかなあと思っていた

590 ：デフォルトの名無しさん：2010/11/08(月) 02:36:56

余所でGUI作りたいって言ったら十中八九C#を勧められると思うよ

591 ：methane：2010/11/08(月) 02:42:43

ruby-gnome2のプロジェクトページのぞいてみたんだけど、この開発者の日本人凄い。
殆どこの一人と、ちょくちょく外国人が一人の二人がメインコミッタか。
この規模で、企業のバックアップとかじゃなくて、完全ボランティアなんだよね？本当に尊敬する。

ただ、チュートリアルだけならPyGTKも個人サイトで解説しているところがいくつかある。
チュートリアルの先も、日本語リファレンスが無い代わりにアプリなら山ほどあるから参考にしたい
GUIがきっと見つかる。
リファレンスに判りにくい部分があっても、IPythonでインタラクティブに動作を確認しながら開発できる。
あと、PyGTKだけで5人以上メインコミッタがいるほうが、トラックナンバー1よりなんとなく安心できる。
採用アプリが多い分、地雷を先に誰かが踏んでくれている確率が多い気がする。
だから、本当に英語アレルギーで無い限り、やっぱりPythonの方が良いんじゃないかなぁ。

592 ：デフォルトの名無しさん：2010/11/08(月) 02:48:46

はっきり言おう
GTKは糞
もう一度言う
GTKは糞

593 ：methane：2010/11/08(月) 02:48:47

もちろん、RubyでGUIアプリが悪いといっているわけじゃなくて、あくまでもPythonかRubyで
GTKアプリを作り始めたい人にどっちを勧めるかという話ね。

完全に興味本位なんだけど、Ruby-gnomeって、Ruby 1.8系だとスレッドはどう実装されてるの？
Rubyのスレッドとgtkのスレッドを完全に分離してるのかな？

594 ：methane：2010/11/08(月) 02:53:30

>>592
Windowsでは最新版が不安定だったりするし、僕は知らないけどMacでもなんか不具合あるらしいね。
Windowsを含むクロスプラットフォームでGUIやるならPython＋Qtかwx がオススメだけど、
Windowsを無視して良いんだったら、Linux版はruby-gtk、Mac版はRubyCocoaで2種類のGUIを作ったら
良いんじゃない？

595 ：デフォルトの名無しさん：2010/11/08(月) 02:58:10

>>594
なるほど
Ruby のひとが Windows 無視する原因はその辺にあるんだな

596 ：デフォルトの名無しさん：2010/11/08(月) 03:00:13

単にwrapしてるだけだから記述言語は関係無くないか？
GUI作る上で必要なのはpythonやrubyの知識じゃなくて、GTKなりQtなりの知識なんだから

597 ：デフォルトの名無しさん：2010/11/08(月) 03:03:23

windowsは、シェル周りが使いにくいんだよな

598 ：methane：2010/11/08(月) 03:09:49

http://ruby-gnome2.sourceforge.jp/hiki.cgi?tips_threads
Ruby 1.8 だと、GTKのメインスレッドをRubyのスレッドに割り当てて、それ以外のGTKスレッドから
Rubyが呼ばれないように注意してプログラムしないとセグフォになるのか。
やっぱり、汎用言語はネイティブスレッドをサポートしないとGUIフレームワークやブロックする
API周りの実装が面倒だよね。Ruby1.9への移行が早く終わると良いな。
（Python3はやっと来年から本格化しそう）

599 ：デフォルトの名無しさん：2010/11/08(月) 03:35:10

2.5くらいの頃しかわからないけど
ZopeはSmalltalkみたく環境込みのOOでめちゃ楽しかったな。
管理画面でポトペタしてサイト構築できたから土方にも配慮してたし
なんで流行らんかったんだろ。
遅いしバグも多かったけど。

600 ：デフォルトの名無しさん：2010/11/08(月) 04:26:02

>>599
土方には難しすぎて理解不能だったからだろ
Railsはちょうど土方のレベルに合ってたから流行った

601 ：デフォルトの名無しさん：2010/11/08(月) 04:41:02

>>598
まさに、それが理由でRuby1.9に移行した。
やっぱネイティブスレッドはいい

602 ：デフォルトの名無しさん：2010/11/08(月) 09:54:43

みんな夜遅くまで起きてるんだな～
ちゃんとセックスしてるか？

603 ：デフォルトの名無しさん：2010/11/08(月) 11:23:42

良い物が流行るとは限らんとよ

604 ：デフォルトの名無しさん：2010/11/08(月) 12:17:05

セックスに流行る/流行らないはないけどな

605 ：デフォルトの名無しさん：2010/11/08(月) 12:59:35

RubyやPythonでGUIアプリ作るならいっそWebアプリにしちゃったほうが楽そうな気がする。

606 ：デフォルトの名無しさん：2010/11/08(月) 13:10:29

Pythonにとって、いちいちJavaScriptを覚えることは耐え難い苦痛なのだ・・・
でもSQLは認めざるをえないのだ・・・

607 ：デフォルトの名無しさん：2010/11/08(月) 13:34:27

WPFとかJavaFXとかみたいに宣言的にGUIを構築できるようなものはないの
JavaFXってこんなんなんでしょ
LLでGUIならこんな感じであるべきだと思う

var window = Frame {
title:"JavaFX!"
width:200
height:120
content:BorderPanel {
top:Label {
text:bind textData.value
font:new Font("Serif", "BOLD", 18)
}
center:TextField {
value:bind textData.input
font:new Font("Serif", "PLAIN", 12)
}
bottom:Button {
text:"OK"
action:operation(){
textData.value = "You typed \"{textData.input}\" !";
}
}
}
};

608 ：デフォルトの名無しさん：2010/11/08(月) 14:14:50

LL言語のGUIってなんでひどいものしかないんだろうな
Javaとかに差をつけられる分野なのに、逆に負けてる

609 ：デフォルトの名無しさん：2010/11/08(月) 14:45:02

>>608
GUIは需要がないから。
買い被るやつはたくさんいるけど。

610 ：デフォルトの名無しさん：2010/11/08(月) 14:49:50

使えねーのを需要のせいにするなよ

611 ：デフォルトの名無しさん：2010/11/08(月) 14:50:42

たしかに、理屈屋のオナニー言語にGUIは必要ないな。

612 ：デフォルトの名無しさん：2010/11/08(月) 15:10:23

>>607
S式で書けそうだな。拒否反応のでないS式というべきか。

613 ：デフォルトの名無しさん：2010/11/08(月) 15:20:49

>>611
その通り
GUIの数少ないモチベーションのひとつは、そうやって罵倒されることへの恐怖だ

614 ：デフォルトの名無しさん：2010/11/08(月) 15:24:43

(笑)

615 ：デフォルトの名無しさん：2010/11/08(月) 15:30:20

>>606
http://pyjs.org/

616 ：デフォルトの名無しさん：2010/11/08(月) 16:19:39

今ちょっとgroovyのswing builderというので遊んでみたけど、こんな感じだった
http://pastie.org/1280934

楽なのかどうなのかよくわからんｗ
paintComponentオーバーライドして自前描画とかは
さすがに宣言的にはできないようだ

617 ：デフォルトの名無しさん：2010/11/08(月) 17:48:20

>>608
まぁ、LLでGUIはこれからなんでしょ。
最近はJavaのよく出来たGUIアプリも見られるけど、初期の頃は酷かったし。

618 ：デフォルトの名無しさん：2010/11/08(月) 19:19:46

http://hirata-create.lar.jp/

619 ：デフォルトの名無しさん：2010/11/08(月) 19:27:22

ttp://coreblog.org/ats/python-got-the-best-langage-place-at-linux-world-readers-choice-2010

Rubyとか世界的に見たら三流言語だから！

620 ：デフォルトの名無しさん：2010/11/08(月) 19:28:08

>>617
これからって・・・
10年以上前に整備しておくべきものだろ

621 ：PHPくのいち(yumilcy：2010/11/08(月) 19:31:12

私をなめないほうがいいわよ

女忍者なの(○｀ε´○)／

622 ：デフォルトの名無しさん：2010/11/08(月) 19:47:03

>>620
自分がやるわけじゃないからって、簡単に考えすぎ

623 ：デフォルトの名無しさん：2010/11/08(月) 19:51:51

Javaは出来てんのに簡単に考えすぎはねぇよｗ

624 ：デフォルトの名無しさん：2010/11/08(月) 20:18:18

どこから手をつけていいかわからないんじゃないかな
具体的な需要がないことには、優先順位もなにもないし

625 ：デフォルトの名無しさん：2010/11/08(月) 20:48:59

JavaのGUIアプリって普及してるか？まだAIRの方が見かけると思うが。
特定業務アプリとか、そういう話だろうか。

626 ：デフォルトの名無しさん：2010/11/08(月) 21:08:46

JavaMEの携帯アプリとかAndroidとかBD-Jとかじゃないの
普及しまくってると思うけど

627 ：デフォルトの名無しさん：2010/11/08(月) 21:55:58

scalaはswingをラップしたscala用のguiライブラリが標準であるみたいだな
出来は知らんけど。

628 ：デフォルトの名無しさん：2010/11/08(月) 21:57:40

>>625
俺が自分用につくってるGUIアプリは全部Javaだ。なんつうか、Javaは
ネットワークとGUI関係は他の言語より設計がよい。

629 ：デフォルトの名無しさん：2010/11/08(月) 22:02:51

いちばんメジャーなのはEclipseなんだろうけど
2chビューワのV2Cとか、かなり出来がいいよね

>>627
http://stackoverflow.com/questions/1570175/scala-and-swing-gui-applications
これか
Scalaならもう少しdeclarativeにかけたほうがかっこいいのに、と
思った
DSL記述力は高いはずなんだから

630 ：デフォルトの名無しさん：2010/11/08(月) 22:08:27

比較的新しいGUIはどれも良いと思うよ
そうでなければ新しく作る意味が無い
CのGTKも、C++のQtも、javaのSWINGも
Objective-CのCocoaは使ったこと無いから言及は避ける

631 ：デフォルトの名無しさん：2010/11/08(月) 23:05:29

遅ればせながら、>>607のJavaFX宣言をRuby/Tkで書いてみた。(Windowサイズの明示的指定は分からんかったケド)
Ruby/Tkなら、>>607の言う「LLでGUIならこんな感じであるべき」姿は、既に実現できているよ。(10年以上前に!!)
Javaのような静的言語では、JavaFXのような別の新言語を憶える必要があるけど、Rubyならそんなのは無用。
また、標準で提供されていないウィジェットも、Ruby/Tkで記述してクラス定義すればいいから無問題。
これらは、少なくとも2001年には実装されていた。(Ruby/Tk解説書である「256倍本界道編」の出版が2002年12月)

require 'tk'
text_data = Struct.new(:text, :input).new(TkVariable.new, TkVariable.new)
TkRoot.new(:title => 'Ruby/Tk!') { |window|
　　TkLabel.new(window,
　　　　:textvariable => text_data.text,
　　　　:font => TkFont.new([:serif, 18, [:bold]])
　　).pack
　　TkEntry.new(window,
　　　　:textvariable => text_data.input,
　　　　:font => TkFont.new([:serif, 12, [:normal]])
　　).pack
　　TkButton.new(window,
　　　　:text => 'OK',
　　　　:command => proc {
　　　　　　text_data.text.value = "You typed #{text_data.input.value} !"
　　　　}
　　).pack
}
Tk.mainloop

632 ：デフォルトの名無しさん：2010/11/08(月) 23:20:18

>>631
わざわざ有難う！

Rubyのブロックをうまく利用することで階層構造通りにわかりやすく書けていて
とても好ましいと思うけど
JavaFXのような後発のものに比べると、windowやpackを何度も書いてるあたり
やはりverboseな印象をうけるなあ

S式でもXMLでもYAMLでもJSONでもいいが、木構造を記述するときに
それぞれのノードにいちいちペアレントの名前を書きたくは無いでしょう

633 ：デフォルトの名無しさん：2010/11/09(火) 06:43:18

えっ

634 ：デフォルトの名無しさん：2010/11/09(火) 15:59:56

>>631
Rubyistとして言わせてもらおう。これはいけてない。
windowや.packが何度もでてきてるし、フォントの指定部分はわかりにくい。
これをJavaFXと同じだというのは、JavaFXに対して失礼。
これは素直にJavaFXの勝ちだと認めるべき。

635 ：デフォルトの名無しさん：2010/11/09(火) 16:29:46

この手のものはDSLで、それっぽく書けるようにできるんじゃないの？
Rubyの得意分野っぽい気もするけど。

636 ：デフォルトの名無しさん：2010/11/09(火) 16:32:42

>>635
そう思うよ
>>616のgroovyの例は言語内DSLだし
もっと頑張れるはず

637 ：デフォルトの名無しさん：2010/11/09(火) 19:57:05

>>631のなにがださいって、windowや.packが重複してることもあるけど、
クラス名がTk::ButtonじゃなくてTkButtonなんだよな。なんでTkモジュールを作ってないんだろう。
自分ならこう書きたい。

require 'tk'
text_data = Tk::Variable.struct(:text, :input)
Tk::Root.new :title=>'Ruby/Tk!', :pack=>true do |w|
　w.label(text_data.text).font(:kind=>:serif, :size=>18, :weight=>:bold)
　w.entry(text_data.input).font(:kind=>:serif, :size=>18, :weight=>:normal)
　w.button('OK').onclikc { text_data.text.value = "You typed #{text_data.input.value}!" }
end

短くはなったけど、JavaFxのほうが見やすいかもな。

638 ：631：2010/11/09(火) 20:06:42

>>632
window とpackについて指摘がありますが、まずwindowについては、指摘の通りです(= verboseという意見に賛成)。
wigetの配置というのは上下の階層構造が基本なのだから、親wigetの指定は(必須ではなく)オプション属性であれば
良かったのに...と思う。ただし、これは「些細な」問題ではないかな？ちょっとコーディングが面倒になるだけ。

次にpackについて。これはwigetの配置を指定するメソッドです。
だから、Ruby/Tkの場合、pack, pack, pack と3回呪文を唱えれば、あら不思議、wigetは縦に並んで配置される。
もちろんpackのオプション属性を使えば、上/左下/右下といった配置も可能。なんてCoolなんだ!!って思いませんか？
(>>607の)JavaFXは、各wigetで個々にtop, bottom, centerを選んで指定する必要があるから(些細だけど)verbose。

それよりも、10年前に設計されたRuby/Tkが「ほとんどJavaFXと同じスタイルでGUIをコード化できる」って事がスゴイ。
Ruby/Tkが時代を先取りしていたと言うべきなのか、JavaFXが10年遅れてようやくRuby/Tkに追いついたというべきなのか....。
しかも、記述言語はRubyだけです。Javaのように、GUIに特化した専用言語、いわゆる「外部DSL」を憶える必要はありません。

>>634
Rubyistを自称するのでしたら、「論よりコード」の言葉のように、>>644自身が適切なコードを示して下さい。
他の人のRuby/Tkコーディングスタイルには興味が有りますから、私は大歓迎しますよ。

639 ：631：2010/11/09(火) 20:11:41

送信の前に、リロードするんだった....orz

>>637
「こう書きたい(or こうあるべき)」ではなく、実際に動くコードで示してくれると嬉しかったりします。
（>>631のコードは、コピペすれば動きますよ。）

640 ：デフォルトの名無しさん：2010/11/09(火) 21:10:34

>>638,639
ダサイといったのは君の書き方じゃなくて、TkのAPIというかライブラリ設計がダサイってこと。
今のライブラリのままじゃ、君じゃなくたってダサイ書き方しかできない。
だから、>>637みたいに書けたらいいよねというわけ。
「実際に動くコード」といわれても、それはTkの別ライブラリを開発しろってことだから、さすがに無理。
それに631のだささを説明するのに、動くコードである必要はないし、それが10年前のコードかどうかなんて、君以外はだれも興味ない。

JavaFXはFlashの対抗馬なんだから、GUI関連に関してRubyより洗練されていてもおかしくない。
他言語の優れたところは素直に認めるべき。
なにがなんでもRubyのほうがいいという人間になりたいなら、まずは「エキスパートRuby」という本を書け。話はそれからだ。

641 ：631：2010/11/09(火) 21:27:14

>>640
了解しました。

ただし、最後の一行を除きます。なにがなんでも....なんて気はありません。
>>608-624あたりの「今のLLには、JavaFXのような洗練されたGUIキットが無い」という流れを眺めていて、
Ruby/Tkなら(些細、あるいは「いくらか」冗長であっても)ほぼ同じスタイル書けるのになぁ....と感じてカキコしただけです。

642 ：デフォルトの名無しさん：2010/11/09(火) 21:31:47

初期化ブロック内だと、親windowは省略できる
過去との互換でTkButtonも使えるけど現在ではTk::ButtonになっててTkButtonはTk::Buttonの別名になってる
DSLっぽく(Tclっぽく)、メソッドで属性を指定すると
require 'tk'
text_data = Struct.new(:text, :input).new(TkVariable.new, TkVariable.new)
Tk::Root.new do
title 'Ruby/Tk!'
Tk::Label.new do
textvariable text_data.text
font :family => :serif, :size => 18, :weight => :bold
pack
end
Tk::Entry.new do
textvariable text_data.input
font :family => :serif, :size => 12, :weight => :normal
pack
end
Tk::Button.new do
text 'OK'
command proc{text_data.text.value = "You typed #{text_data.input.value} !"}
pack
end
end
Tk.mainloop
でも、表示上の階層構造しか表してなくて、後で個々のウィジットインスタンスを得られない
必要なら、それぞれのインスタンスを自分で保存しておく必要があるのがださい

GUIは統合環境やGUIビルダーのある言語で書いたほうがいい
LL限定でやるのなら自分の使い慣れた言語でやればいい
Rubyのことしか知らんけどそう思う

643 ：デフォルトの名無しさん：2010/11/09(火) 21:38:20

WPF....いや、何でも無いですすいません

644 ：632：2010/11/09(火) 21:47:31

>>638
ああなるほど、packに関しては、それがTkのレイアウトマネージャの
仕様なわけですね

> だから、Ruby/Tkの場合、pack, pack, pack と3回呪文を唱えれば、
> あら不思議、wigetは縦に並んで配置される。
> もちろんpackのオプション属性を使えば、上/左下/右下といった配置も可能。
> なんてCoolなんだ!!って思いませんか？

これは同意しません
ttp://pastie.org/1284195
これはJavaFXではなくてgroovyのSwingBuilderですが、見ての通り
boxLayout(axis: BoxLayout.Y_AXIS)を一度指定すれば、以降は縦配列になります
同様にflowLayout()で、HTMLのフローレイアウト同様の横配列を
指定したことになります
これはJava/Swingのレイアウトマネージャの設計によるものですが、
少なくとも毎回packのようなものを呼ぶ必要はありませんよ

645 ：デフォルトの名無しさん：2010/11/09(火) 21:49:00

>>643
>>607でJavaFXと一緒に名前が挙がってるけど、スルーされているなｗ
どっちかというとWPFのほうがメジャーなのではと思うが
そうでもないのだろうか

646 ：631：2010/11/09(火) 22:22:38

>>644
>これはJavaFXではなくて

え、JavaFXではできないんですか？たまたま>>607のコードでは使われなかったけど、
ポリシーベースのwidget自動配置機能はJavaFXにもある、ってのが事実だと推測したのですけど。

あと、Ruby/Tkのpack仕様が「古くさい」というか、ユニークである事は認めます(<-- 今更かよ)。

647 ：デフォルトの名無しさん：2010/11/09(火) 22:27:42

>>646
JavaFXについてはほぼ全く知らないので、答えようがありません
単にGroovyは知っているので、Groovyで書いただけですよ
(もっとも、Groovy標準で利用できるSwingBuilderは昨日初めて試したのですが）

648 ：631：2010/11/09(火) 22:35:19

>>647
あ、そうだったんですか。てっきり>>607と>>632が同一人物だと早とちりしてレスしてしまい、大変失礼しました。

649 ：デフォルトの名無しさん：2010/11/09(火) 23:03:51

>>645
私の周りでJavaFXやってる人はあまり...

まぁLLにGUI求めても仕方ないような気がしますけどね

650 ：methane：2010/11/09(火) 23:33:26

PyQtやPyGTKでも、ある程度の規模になるとUIデザイナーで設計したUI定義を読み込むのが一般的で、
LLらしさは無いな。
C++のQtが宣言型UI定義言語に対応してそれがPyQtでも使えるけど、思いっきりJSONだから、
いっそPythonの辞書をそのまま定義にしろって思う。

SwingはLinuxだとデフォルトのフォントがダメダメ（デスクトップ環境のフォントを調べずに、
fonts.propertiesとかなんとかいうJavaのファイルだけ見やがる）だったり、
クロスプラットフォームGUIツールキットとしてはQt以下だと思ってたけど、最近はそんなこと
無いのかな。

651 ：デフォルトの名無しさん：2010/11/09(火) 23:44:50

唯一の正しいデフォルト
Pythonらしいな

652 ：デフォルトの名無しさん：2010/11/10(水) 06:11:00

自分はTkを使ったことないし、gladeでお手軽デザインしかしてないから何ですが、

例えば TkRoot.[] を定義して、>>631を
window = TkRoot[title: 'Ruby/Tk!', pack: [
　　[TkLabel,
　　　　textvariable: text_data.text,
　　　　font: [:serif, 18, [:bold]]
　　],
　　[TkEntry,
　　　　textvariable: text_data.input,
　　　　font: [:serif, 12, [:normal]]
　　],
　　[TkButton,
　　　　text: 'OK',
　　　　command: proc {
　　　　　　text_data.text.value = "You typed #{text_data.input.value} !"
　　　　}
　　]
]]
みたいに書けるようにするのは、どうなんでしょ？
Ruby1.9用だけど、結構すっきりするような

653 ：デフォルトの名無しさん：2010/11/10(水) 07:01:00

javascript にそういう gui/fw あるね

654 ：デフォルトの名無しさん：2010/11/10(水) 11:47:13

>>642
> でも、表示上の階層構造しか表してなくて、後で個々のウィジットインスタンスを
> 得られない
> 必要なら、それぞれのインスタンスを自分で保存しておく必要があるのがださい

最近の（というか、HTMLのようなマークアップ言語の影響を受けたもの）は
それこそwidgetにIDつけられるようになってるみたいだね
それないと確かに不便だろう

655 ：デフォルトの名無しさん：2010/11/10(水) 15:39:36

>>652
悪くないんじゃね？実装も簡単そうだし。

656 ：631：2010/11/10(水) 18:38:17

>>652
ウィジェットの階層構造をメソッドの列で表現するのではなく、データ構造で表現するということですね。
とても良い発想だと思います。自分はまだRuby1.9へ移行していないので、Ruby1.8で実装してみました。
ただし、Ruby1.8は連想リストが使えないので、代わりにモジュール関数を使っています。
これは実際に動くコードです。モジュールMTKを実装したmodern_tk.rbは、114stepほどの規模でした。

require 'modern_tk'
text_data = Struct.new(:output, :input).new(MTK.variable, MTK.variable)
MTK.mainloop(
　　MTK.root(
　　　　:title => 'Ruby/Tk!',
　　　　:vpack => [
　　　　　　MTK.label(
　　　　　　　　:textvariable => text_data.output,
　　　　　　　　:font => [:serif, 18, [:bold]]
　　　　　　), MTK.entry(
　　　　　　　　:textvariable => text_data.input,
　　　　　　　　:font => [:serif, 12, [:normal]]
　　　　　　), MTK.button(
　　　　　　　　:text => 'OK',
　　　　　　　　:command => proc {
　　　　　　　　　　text_data.output.value =
　　　　　　　　　　　　"You typed #{text_data.input.value} !"
　　　　　　　　}
　　　　　　)
　　　　]
　　)
)

657 ：631：2010/11/10(水) 18:56:27

>>642,654
モジュールMTKは、任意のウィジェットにID属性を指定できます。
以下のコードでは、Small/Largeボタンを押すと入力テキストのサイズが変化します。

require 'modern_tk'
text_data = Struct.new(:output, :input).new(MTK.variable, MTK.variable)

MTK.mainloop(
　　MTK.root(
　　　　:title => 'Ruby/Tk!',
　　　　:vpack => [
　　　　　　MTK.label(:id => :LABEL, :textvariable => text_data.output),
　　　　　　MTK.entry(:textvariable => text_data.input, :font => [:serif, 18, [:bold]]),
　　　　　　MTK.frame(
　　　　　　　　:hpack => [
　　　　　　　　　　MTK.button(:text => 'Small', :command => proc { MTK[:LABEL].font.size = 14 }),
　　　　　　　　　　MTK.button(:text => 'Large', :command => proc { MTK[:LABEL].font.size = 18 }),
　　　　　　　　　　MTK.button(
　　　　　　　　　　　　:text => 'OK',
　　　　　　　　　　　　:command => proc { text_data.output.value = "You typed #{text_data.input.value} !" }
　　　　　　　　　　)
　　　　　　　　]
　　　　　　)
　　　　]
　　)
)

658 ：デフォルトの名無しさん：2010/11/10(水) 20:35:07

>>608
Qt使えたら十分だと思うが。
JavaにはQtすらひどいと言えるほどに素晴らしいライブラリがあるの？

659 ：デフォルトの名無しさん：2010/11/10(水) 21:40:56

SwingはUIやなんかの実装はかなりアレだが
プログラミングのインターフェースとしては出来が良いと思うよ

660 ：デフォルトの名無しさん：2010/11/11(木) 00:06:09

vb >>>> 越えられない壁 >>>>> pygtk,ruby/tk,tcl/tk

661 ：デフォルトの名無しさん：2010/11/11(木) 00:35:47

>>660
まあそれは一理ある。
できればこれも追加して。
InterfaceBuilder＞＞＞＞越えられない壁＞＞＞＞VB

662 ：652：2010/11/11(木) 06:29:24

>>656-657
ごめん、何かイマイチな感じがしてしまう。
Ruby的じゃないというか、オブジェクト指向的じゃないというか。。。
単純に>>652をRuby1.8でも通る書き方に変えるだけの方がマシだと思う。

663 ：デフォルトの名無しさん：2010/11/11(木) 10:59:39

Expression Blendとか使うのが1番Light weightな気がするけどな。

664 ：デフォルトの名無しさん：2010/11/11(木) 11:13:57

世紀の問題児WPFさんで話題をかっさらうのはやめろ

665 ：デフォルトの名無しさん：2010/11/11(木) 14:53:51

これからもRuby出番ねーから
自分のパソコンでRuby使ってオナニーしてろ

666 ：デフォルトの名無しさん：2010/11/11(木) 15:24:23

脳内設定必死だなw

667 ：デフォルトの名無しさん：2010/11/11(木) 15:24:52

海外は LL = サンダル言語って割り切ってる連中が多いね。
OO とか求めないから PHP で十分的な。おまいら 3 年も経てば昔のﾌﾞﾋﾞ厨扱いかもな。

668 ：デフォルトの名無しさん：2010/11/11(木) 15:39:14

Rubyで作られたWindowsのGUIデスクトップアプリを紹介してください。

669 ：デフォルトの名無しさん：2010/11/11(木) 16:04:20

PHP みたいなイカれた言語で十分とか、VB厨以下の脳味噌だな >>667

670 ：デフォルトの名無しさん：2010/11/11(木) 17:45:54

ぶっちゃけ海外に限らず、日本でも多数派はそんなもんなんじゃね。

671 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/11(木) 18:14:30

PerlerにボコられるかすRubyist
顔面ぶたれて鼻折られて　腹も殴られて
嘔吐吐きつづけるPHPユーザー

672 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/11(木) 18:49:26

PerlのIRCのカスどもはテレパシーしてる電波野郎どもだからIRCの役割がうまく機能してない

673 ：631：2010/11/11(木) 18:53:07

>>662
>単純に>>652をRuby1.8でも通る書き方に変えるだけの方がマシだと思う。

やっぱりそうですか。カッコが大杉てインデント深すぎかも？とは感じていたのですが....。
というわけで、できる限り>>652に忠実かつRuby1.8でも通る書き方へと再実装(114 -> 226 step)してみました。
ただしTkRootにメソッド'[]'を追加するのはデータ構造の一貫性に欠けると考えて他と記法を統一し、
更にpack属性は省略可能(デフォルトは縦に配置する)といった変更を加えています。これならいかがでしょうか？

require 'modern_tk2'
text_data = Struct.new(:output, :input).new(MTK2.variable, MTK2.variable)
MTK2.mainloop [TkRoot, :title, 'Ruby/Tk!',
　　[TkLabel,
　　　　:textvariable, text_data.output,
　　　　:font, [:serif, 18, [:bold]]
　　],
　　[TkEntry,
　　　　:textvariable, text_data.input,
　　　　:font, [:serif, 12, [:normal]]
　　],
　　[TkButton,
　　　　:text, 'OK',
　　　　:command, proc {
　　　　　　text_data.output.value =
　　　　　　　　"You typed #{text_data.input.value} !"
　　　　}
　　]
]

674 ：631：2010/11/11(木) 18:56:59

>>657に相当したID指定とpacking指定に関するサンプルコードです。

MTK2.mainloop [TkRoot, :title, 'Ruby/Tk!',
　　[TkLabel, :id, :LABEL,
　　　　:textvariable, text_data.output,
　　　　:font, [:serif, 18, [:bold]]
　　],
　　[TkEntry,
　　　　:textvariable, text_data.input,
　　　　:font, [:serif, 12, [:normal]]
　　],
　　[TkFrame, :pack, :h,
　　　　[TkButton,
　　　　　　:text, 'Small',
　　　　　　:command, proc { MTK2[:LABEL].font.size = 14 }
　　　　],
　　　　[TkButton,
　　　　　　:text, 'Large',
　　　　　　:command, proc { MTK2[:LABEL].font.size = 18 }
　　　　],
　　　　[TkButton,
　　　　　　:text, 'OK',
　　　　　　:command, proc {
　　　　　　　　text_data.output.value =
　　　　　　　　　　"You typed #{text_data.input.value} !"
　　　　　　}
　　　　]
　　]
]

675 ：デフォルトの名無しさん：2010/11/11(木) 20:01:35

Perl忍者をこのスレでひきとってください

676 ：デフォルトの名無しさん：2010/11/11(木) 20:33:32

お琴割りします

677 ：デフォルトの名無しさん：2010/11/11(木) 20:49:01

↓でいいだろ

Perl忍者のPerlレベルを向上させるスレ
http://hibari.2ch.net/test/read.cgi/tech/1288431178/

Perl忍者です　Perlプログラマになりたいです
http://hibari.2ch.net/test/read.cgi/tech/1284704280/

678 ：デフォルトの名無しさん：2010/11/12(金) 03:18:18

プログラミング言語マニアみたいな人がいたらお聞きしたいのですが
Pythonの並に一貫して書きやすさや冗長性をなくすことよりも読みやすさを重視していてかつ
ドキュメントが少なく、コミュニティが活発でないマイナー言語はありませんでしょうか？

Pythonと他のLLやその他言語が比較されることがありますが、
いつも話を聞くのは、誰にとっても同じように書け、またあとから読みやすいからよいということのようです。

例えばRubyが使いづらいのはメタプログラミング以上に、ドキュメントが少ない、
Windowsでのサポートが少ないなどと言われることもありますが
それは単にPythonのコミュニティが大きくが人的なリソースを潤沢に持っているからなのではないか？と

つまり、Pythonからコミュニティやドキュメントなどを省いたような言語でも使いやすいはずと考えました。

動作はWindowsかLinuxで動くもので

679 ：デフォルトの名無しさん：2010/11/12(金) 03:20:28

> つまり、Pythonからコミュニティやドキュメントなどを省いたような言語でも使いやすいはずと考えました。

つまり、誰にとっても同じように書け、またあとから読みやすいから、ということであれば
Pythonからコミュニティやドキュメントなどを省いたような言語であれば使いやすいはずと考えました。

支離滅裂ですいませｎ

680 ：652：2010/11/12(金) 06:33:55

>>673-674
頭の中にあったのは、GTKのように全てのウィジェットの基底クラスWidgetと全てのコンテナの基底クラスContainerがある場合で、
ざっくり雰囲気だけ書くと、
def Widget.[](args = {})
　return self.new(args)
end
def Container.[](args = {})
　container = super
　args[:pack].each{|type, params| type[params]} # 子ウィジェット生成
　return container
end
みたいなメソッドを定義して、全てのウィジェットでWidget[def]のようにしてデータ構造からインスタンス生成できると
美しいかなと考えていました。（>>652では>>631との対比が分かりやすいように、TkRootで書きましたが）
ただ、同じ様な事がTkに適用できるかは分からないです。
それと、モンキーパッチしなくていいメリットもあるので、>>673-674もアリだと思います。

681 ：デフォルトの名無しさん：2010/11/12(金) 10:52:14

>>678
日本語勉強してからまた来なさい

682 ：デフォルトの名無しさん：2010/11/12(金) 11:21:19

言ってることはわかるよ、俺はそういう言語あるのか知らんけど

683 ：デフォルトの名無しさん：2010/11/12(金) 11:58:19

synapticパッケージマネージャなり,
comp.langの（何だっけ）を眺めて自分で探せ

684 ：デフォルトの名無しさん：2010/11/12(金) 12:27:47

遂にC#を越えたな
http://www.google.co.jp/trends?q=ruby+programming,+python+programming,+C%23+programming&ctab=0&geo=all&date=all&sort=0

685 ：デフォルトの名無しさん：2010/11/12(金) 14:17:37

>>684
まだ上には上が
Google トレンド: Java programming, ruby programming, python programming, C# programming
http://www.google.co.jp/trends?q=Java+programming%2C+ruby+programming%2C+python+programming%2C+C%23+programming&ctab=0&geo=all&date=all&sort=0

しかしC#下がってきてるのウケル

686 ：デフォルトの名無しさん：2010/11/12(金) 14:18:49

>>684
phpぶっちぎってるんだが、こっちの方がすごくないか
Google トレンド: php programming, ruby programming, python programming, C# programming
http://www.google.co.jp/trends?q=php+programming%2C+ruby+programming%2C+python+programming%2C+C%23+programming&ctab=0&geo=all&date=all&sort=0

687 ：デフォルトの名無しさん：2010/11/12(金) 14:29:01

>>686
phpはプログラミング言語ではなくて進化しすぎたテンプレートエンジンなので、「programming」と
and すると落ちるよね。

688 ：デフォルトの名無しさん：2010/11/12(金) 16:09:31

マジレスすると検索時に programming 一々足さなくね？
公式探すなら language 使わね？
始めたかったら tutorial 使わね？
詰んだら issue 使わね？

あとこれマジ便利じゃね？
http://www.google.com/insights/search/#cat=31&q=perl%2Cruby%2Cpython%2Cphp&cmpt=q

689 ：デフォルトの名無しさん：2010/11/12(金) 16:38:10

>>688
Rubyは宝石が、Pythonは蛇が、Javaはコーヒーが検索に引っかかる。
Programmingを足して検索する確率が言語間である程度均一なら、Programmingを
足して検索した結果の方が意味がある。

690 ：デフォルトの名無しさん：2010/11/12(金) 16:39:26

>>688
リンク見る前に返信してしまった。それマジ便利だね。

691 ：デフォルトの名無しさん：2010/11/12(金) 17:00:28

>>688
お前はラッパーかｗ

692 ：デフォルトの名無しさん：2010/11/12(金) 17:03:23

Googleと産んでくれた親にマジ感謝すれば完璧

693 ：デフォルトの名無しさん：2010/11/12(金) 19:03:34

Pythonを高速化しよう! - gumi Engineer’s Diary
http://d.hatena.ne.jp/gumilab/20101109/1289310291

694 ：デフォルトの名無しさん：2010/11/12(金) 21:16:44

こんなのが何かの指標になるとは思わない。
現実のシェアと明らかに違う。

http://www.google.co.jp/trends?q=internet+explorer%2C+ie%2C+firefox%2C+opera%2C+chrome%2C+safari&ctab=0&geo=all&date=all&sort=0
http://www.google.co.jp/trends?q=windows%2C+mac&ctab=0&geo=all&date=all&sort=0

695 ：デフォルトの名無しさん：2010/11/12(金) 21:26:22

俺らが何か文書を書くとき、または何かを検索するとき
そのコトバを使用してるのかというのがシンプルな回答だな

無論使ってない

Pythonにしかないライブラリを使う探す説明するときに「Python」といちいち断るかというと微妙
Rubyの話を書くときに「[Ruby] [プログラミング]」と完全にタグ付けするかも微妙

696 ：デフォルトの名無しさん：2010/11/12(金) 21:47:30

要約: (∩ ﾟдﾟ)ｱｰｱｰきこえなーい

697 ：デフォルトの名無しさん：2010/11/13(土) 14:46:20

>>688
クエリーの対象となったページをカテゴリわけしてるのだろうか？
はてなブックマークのカテゴリわけのすごいやつなのか、ググルさんクロール対象にも機械学習で分類できそうだな

これおもしろいな

>>694
あまり変わらないなｗ
http://www.google.com/insights/search/#cat=303&q=windows%2Clinux%2Cmac&cmpt=q
Linux右肩下がりでわろた

698 ：デフォルトの名無しさん：2010/11/13(土) 15:24:52

http://www.google.com/insights/search/#cat=303&q=ubuntu%2Clinux&cmpt=q
ubuntuとかdistroの名前で検索に変ってるだけじゃね？

699 ：デフォルトの名無しさん：2010/11/13(土) 17:40:18

OSならWindowsは90%、Macは4-5%程度のシェア。ブラウザはIEが60%、Firefoxが20-25%程度、その他は5%前後。これが実際のシェア。

700 ：デフォルトの名無しさん：2010/11/13(土) 20:53:45

>>688
> 公式探すなら language 使わね？
languageには自然言語が入るため制度が悪くなる

701 ：デフォルトの名無しさん：2010/11/13(土) 22:59:10

pythonを勉強したいと思っています。

最終的には、 Google App Engine　というのに乗せて動かしてみたいのですが

何か解説サイトとかってありますか？

702 ：デフォルトの名無しさん：2010/11/14(日) 01:07:29

>>701
Pythonと決めているなら
Pythonスレで訊くべきだ

703 ：デフォルトの名無しさん：2010/11/14(日) 01:08:56

>>702
了解です。
ちょっとPythonを触ってみましたが非常に気持ち悪い文法ですね。

704 ：デフォルトの名無しさん：2010/11/14(日) 01:26:55

それが言いたかっただけのRuby厨ｗ

705 ：デフォルトの名無しさん：2010/11/14(日) 01:33:54

いや俺は .Net　たーだから。

それにしても、Pythoは酷い文法だ。
だから日本で流行らないだよな。

706 ：デフォルトの名無しさん：2010/11/14(日) 01:36:21

具体的に言わないのは、とりあえず批判しとけば勝ちだと思ってるかrあ

707 ：デフォルトの名無しさん：2010/11/14(日) 02:28:28

まぁPythonが気持ち悪いのは同意

708 ：デフォルトの名無しさん：2010/11/14(日) 02:41:04

Rubyとかに>>693みたいな無いの？

709 ：methane：2010/11/14(日) 02:50:51

他の言語から来たなら、第一引数のselfの背景とか分からないし、気持ち悪いと思うのも仕方ないだろうな。
最初はとりあえず慣れて、次にどうしてそうなってるのか調べるのがいいと思うよ。
言語設計者の方針とかを理解せずに○○キモイって批判してもその言語の信者に叩かれるだけだし、
方針を理解した上でどうしても受け付けられないならムリに好きになる必要ない。

710 ：デフォルトの名無しさん：2010/11/14(日) 02:52:30

なんでインデントなんだろうなあ。

711 ：デフォルトの名無しさん：2010/11/14(日) 03:05:33

ＥｃｌｉｐｓｅでPythonの開発環境は何とか作ったけど
Google App Engineに作成したプログラムをEclipse上から
行うにはどうしたらよいのかな？
全く分からん。

712 ：デフォルトの名無しさん：2010/11/14(日) 03:05:41

どうせインデントするから。

713 ：デフォルトの名無しさん：2010/11/14(日) 03:06:05

逆に考えるんだ「閉じカッコがいらない分得した」と考えるんだ

714 ：methane：2010/11/14(日) 03:14:33

>>711
http://www.gesource.jp/weblog/?p=1704
pydevとGAEで検索したら他にも結構ヒットするよ。頑張れ。

715 ：デフォルトの名無しさん：2010/11/14(日) 03:23:38

検索したらヒットすることを質問する奴は、その前の段階までどうやってたどり着いたんだ？
一人エスパーで進んできたのか？天才じゃね

716 ：デフォルトの名無しさん：2010/11/14(日) 03:28:31

>>710
漏れも最初はそう思ってたけど
なれるとそんなに気にならない

self もそう

C++ よりも C が好きっていう人に python は合う

っていうかインデント批判するひとは python 使ったこと無いんだと思うことにしている

717 ：デフォルトの名無しさん：2010/11/14(日) 03:56:04

合わない言語は合わないが
慣れればどうにかはなる

718 ：デフォルトの名無しさん：2010/11/14(日) 04:00:08

>>714
サンクス。
そのサイトみたいにPythonのノウハウとかを公開したサイトが増えれば
もっと人気が出ると思うな。

取り敢えず練習用にPythonで作成したWEBサイトをGAEに載せてみる。
完成する頃には一通り出来る様になるだろうと期待して。

719 ：デフォルトの名無しさん：2010/11/14(日) 04:05:57

>>709
>言語設計者の方針とかを理解せずに○○キモイって批判してもその言語の信者に叩かれるだけだし、

まさに「お前がいうな」だな。そういうつっこみを期待してのボケだろうけど。

720 ：デフォルトの名無しさん：2010/11/14(日) 04:15:37

Google AppEngineについて思うこと
ttp://togetter.com/li/66450

721 ：methane：2010/11/14(日) 05:33:09

>>719
少なくともこのスレで晒されたTwitterの書き込みではRubyやPHPに対してキモイと言った覚えはないけど？

まぁ昔 php の == がキモイとかは言ってたから、 >>709 が自戒を兼ねているのは認める。

722 ：デフォルトの名無しさん：2010/11/14(日) 06:33:00

>>705
あなたの国では流行ってるですか？

723 ：デフォルトの名無しさん：2010/11/14(日) 09:26:37

インデント批判はLispの括弧批判みたいなもんで、
使っている人には気にならなくて、外から見たときに付け入られる見に見えた弱点のようなもの。

724 ：デフォルトの名無しさん：2010/11/14(日) 11:22:46

>>721
キモイという言葉を使わなければ設計者の方針とかを理解せずに批判しても良いのか。ふーん。

725 ：デフォルトの名無しさん：2010/11/14(日) 11:53:41

Pythonで Helloworld　プロジェクトを作成し
実行したところ Console には

http://localhost:8080

と表示されるのですがブラウザ上には何も表示されません。

また、直接ブラウザに http://localhost:8080　と入力し
実行すると　selef.response.out.write('hoge')
とPythonのスクリプトが実行されている様です。

どうすればDebug実行時にブラウザがEclipse上で
自動で起動する様になりますか？

726 ：デフォルトの名無しさん：2010/11/14(日) 11:58:14

>>725 マルチ

727 ：デフォルトの名無しさん：2010/11/14(日) 12:06:09

ここはpython質問スレじゃないって

728 ：デフォルトの名無しさん：2010/11/14(日) 12:07:42

Rubyとかに>>693みたいな無いの？

729 ：デフォルトの名無しさん：2010/11/14(日) 12:13:44

http://wiki.cython.org/DebuggingTechniques
悲惨すぎる

デバッグに難があるような物は、業務では採用されないんじゃないか
土方はIDEのソースレベルデバッガに慣れているからな

730 ：デフォルトの名無しさん：2010/11/14(日) 12:25:48

はい
デバッグに難があるような最適化をしてはいけません

731 ：デフォルトの名無しさん：2010/11/14(日) 12:42:04

>>726
だって誰も教えてくれないんだもん

732 ：デフォルトの名無しさん：2010/11/14(日) 12:49:47

最近Pythonでリスト処理したくて内包表記勉強したんだけど、
日本語公式のリファレンスの説明が分かりにくすぎる。
というかやる気ないだろｗｗ
英語なら資料揃ってるの？

Pythonなら公式リファレンスが整備されていて
初心者でも自習に困らないというのは
必ずしも真じゃないんだなと思った。

733 ：デフォルトの名無しさん：2010/11/14(日) 12:53:16

そうかなあ。
内包表記がpythonのコードを滅茶苦茶にし得る数少ない要素の一つだというのは分かるけど。

734 ：デフォルトの名無しさん：2010/11/14(日) 13:09:17

俺はなかなかいいと思ったよ。
うまく言えないけどPythonの字面にあってる。
そうじゃなくてリファレンスの説明じゃ初心者には分からんと言ってるの。

735 ：デフォルトの名無しさん：2010/11/14(日) 13:22:02

すまんリファレンスじゃなくてチュートリアルな。
リファレンスも分かりづらいけど。

736 ：デフォルトの名無しさん：2010/11/14(日) 13:24:28

英語読めないんだったら本買え

737 ：デフォルトの名無しさん：2010/11/14(日) 13:29:07

別に内包表記くらいググればすぐ分かったよ。

Python厨がドキュメントが充実してるから
初心者でも分かりやすいとかよく書いてるけど
全然そんなことなかったので不満を述べただけ。

738 ：デフォルトの名無しさん：2010/11/14(日) 13:32:24

ドキュメントの充実さでPHPに敵うLLは存在しない。

739 ：デフォルトの名無しさん：2010/11/14(日) 13:34:20

>>737
ググれば分かったってことは非公式ドキュメントが充実してたんですね＾＾

740 ：デフォルトの名無しさん：2010/11/14(日) 13:39:15

そう、ググればいくらでも出てくる。
別にPython自体が分かりにくいとか主張しているわけではないよ。
ただ公式が余りにやる気なさすぎて吹いたわ。

741 ：デフォルトの名無しさん：2010/11/14(日) 13:42:51

公式分かりにくいかなあ。これ以上でもこれ以下でもない気がするけど

742 ：デフォルトの名無しさん：2010/11/14(日) 14:04:57

リストの内包表記 (list comprehension) は、リストの生成を map() や filter() や lambda の使用に頼らずに行うための簡潔な方法を提供しています。
結果として得られるリストの定義は、しばしば上記の構文を使ってリストを生成するよりも明快になります。
各々のリストの内包表記は、式、続いて for 節、そしてその後ろに続くゼロ個かそれ以上の for 節または if 節からなります。
式をタプルで評価したいなら、丸括弧で囲わなければなりません。

743 ：デフォルトの名無しさん：2010/11/14(日) 14:06:58

List comprehensions provide a concise way to create lists without resorting to use of map(), filter() and/or lambda.
The resulting list definition tends often to be clearer than lists built using those constructs.
Each list comprehension consists of an expression followed by a for clause, then zero or more for or if clauses.
The result will be a list resulting from evaluating the expression in the context of the for and if clauses which follow it.
If the expression would evaluate to a tuple, it must be parenthesized.

こっちが原文。
最初の2行はおしゃべり、最後の一行は些細な補足
本質的な説明は事実上2行だけで、その後の行(The result will be～)が
和訳では完全に抜けているな

744 ：デフォルトの名無しさん：2010/11/14(日) 14:08:31

これ、サンプルコード見ても何やってるか分からない男の人って

745 ：デフォルトの名無しさん：2010/11/14(日) 14:09:31

ベタ貼りサンプルコードだけで何かを説明した気になるのは
よくある手抜き解説本にはありがちなことだね

746 ：デフォルトの名無しさん：2010/11/14(日) 14:10:48

ちなみにreferenceのほうを見れば、シンタックスは分かるようになっている
が、セマンティックスの説明は同じぐらい短い、つまり無いに等しい

747 ：デフォルトの名無しさん：2010/11/14(日) 14:34:10

初心者には分かりにくいと言っているのに何故読み手の理解力を叩くかなあ。
別に今は理解出来ているわけだし。

どういう順で評価されるのかとか、
途中評価された変数を評価に使えるのかが分からなかった。

lst=[[1,2],[3,4]]
[x for y in lst for x in y]
[x for x in y for y in lst]

が出来るのかとか、どちらが正しいのかとかね。
まあ後々振り返ると最初の式以外は素直にコンテキスト通りに考えれば良かったんだけどね。
そのあたりも初心者には自明では無いのよ。

748 ：デフォルトの名無しさん：2010/11/14(日) 14:53:15

>>747
Python信者にとっては、Pythonに関するあらゆる批判も愚痴も、許してはならない存在なのです。
なぜなら、それがPython信者だからです。
今回の件も、数あるうちのひとつに過ぎません。

749 ：デフォルトの名無しさん：2010/11/14(日) 14:55:55

>>747
http://www.python.jp/doc/2.5/ref/lists.html

750 ：デフォルトの名無しさん：2010/11/14(日) 15:03:29

チュートリアルは仕様書じゃないからね
自明な情報のために仕様書を読む初心者がいるなら感心するけど
自分でコードを書いて試すなりネットで調べるなりネットで質問するなり本買うなりすればいいんじゃないかな

>>727みたいに初めから具体的な指摘をするなら良いけど
やる気なさすぎて吹いた、とか言われても叩くしかないよね

751 ：デフォルトの名無しさん：2010/11/14(日) 15:06:12

俺がやる気無いと言っているのはチュートリアルの方で、
リファレンスについては「分かりにくい」だけだよ。
最初呼び間違ったから混乱したようならすまんな。

752 ：デフォルトの名無しさん：2010/11/14(日) 15:08:20

>>751
別に混乱してない。チュートリアルはレファレンスじゃない。

753 ：デフォルトの名無しさん：2010/11/14(日) 15:10:04

>>749
それはtutorialよりややマシだけど詳細で十分な
あるいは分かりやすい説明とはいえないよな

たとえばシンタックス的にlist_for の "for"の次の要素は
単にexpression_listとなっているから
for (lambda x: x) in xs ～
for 1 in xs ～
のようなものが「シンタックス的には」有効であることが見て取れるが、
実際には、セマンティックス上は、assign可能な名前のリストでなければならない
そしてそんなことはどこにも書いていない

754 ：732：2010/11/14(日) 15:21:03

>>750 煽り入ってたのは認める。
別にホントにPythonに不満あるなら本スレ行くなり使うの止めたりするよ。

>>751 チュートリアルだけじゃ理解出来ないのなら何のためのチュートリアル？

755 ：デフォルトの名無しさん：2010/11/14(日) 15:22:22

完璧ではないが、それが不十分だとは思わないけど
for (lambda x: x) in xs ～やfor 1 in xs ～が不可だって説明しないことは不十分ってことになるのか？

756 ：デフォルトの名無しさん：2010/11/14(日) 15:25:03

>>755
少なくともこんなレベルで標準化とかは無理

757 ：デフォルトの名無しさん：2010/11/14(日) 15:26:26

ああ、Rubyの標準化のことね

758 ：デフォルトの名無しさん：2010/11/14(日) 15:31:06

>>754
リスト内包のサンプルコード見れば雰囲気つかめると思うけどなあ
というかチュートリアルの時点で理解できないなんてのはよくあること
#include <stdio.h> 何かを考えてみればわかる

リスト内包は必須の機能じゃないし、誰もが理解できるまで説明してたら
叙述のバランスが悪いって逆に文句ついちゃうよ

759 ：デフォルトの名無しさん：2010/11/14(日) 15:31:25

list_for ::= "for" target_list "in" old_expression_list [list_iter]
になってるな。

760 ：デフォルトの名無しさん：2010/11/14(日) 15:36:13

>>759
ああ、原文の、少なくとも2.7の奴だとそうなってるみたいだな
じゃあ、シンタックスを変えたのか、例によって和訳のバグか？

761 ：デフォルトの名無しさん：2010/11/14(日) 15:41:39

>>755
不十分だろう
for x, y in xs
とかでタプルのアンパックとかもやるわけだし

そういう類の説明を一切無しで済ませるのなら、statementのほうのforだのifだのを
使った～のコードと等価であるぐらいは説明すべきじゃないのか

762 ：732：2010/11/14(日) 15:42:30

＞新たに作成されるリストの各要素は、
＞各々の for や if 節を左から右の順にネストしたブロックとみなして実行し、
＞ネストの最内ブロックに到達する度に式を評価した値となります。

少なくともこのぐらいはチュートリアルにも書いておいてくれてもいいんじゃないの？
上の文がそんなに冗長とは思えないのだが。
むしろ必須に思う。

763 ：デフォルトの名無しさん：2010/11/14(日) 15:45:32

>>759
ありがとう。俺は2.5使ってるからサ

764 ：methane：2010/11/14(日) 18:59:49

ネストした内包表記に関してチュートリアルが追加されたのが2.6からなんだけど、
http://pythonjp.sourceforge.jp/dev/tutorial/datastructures.html#id7
これを読んでも判りにくかった？それとも2.5のほうのチュートリアル読んでた？

2.6はチュートリアルとライブラリリファレンスがもうそろそろ完了しそうだから、
そしたらそこだけでも公開するつもり。

765 ：methane：2010/11/14(日) 19:14:44

>>724
批判をするのも自由。その批判を批判するのも自由。

Twitterに書いたただの感想を2chにコピペで晒すのは著作権法違反だし、
しかも書いた内容ではなく人格攻撃するのは行き過ぎると名誉毀損になるけどね。

766 ：methane：2010/11/14(日) 19:22:51

>>763
>>764の続きだけど、一応2.6のドキュメントにも2.5から変更された部分や追加された部分には
注意書きがあるから、2.6のドキュメントを読んだほうがいいかもしれない。

>>764に書いたURLは翻訳中で、翻訳状況は http://sourceforge.jp/projects/pythonjp/wiki/StatusTable26
で見れます。ただし、翻訳状況が完了になってから上記URLの更新まではタイムラグがあります。

>>743 に指摘していただいた抜けの部分も修正しておきます。

767 ：デフォルトの名無しさん：2010/11/14(日) 19:24:19

>>764
ここで出てるのって、ネストじゃなくて複数のforがある場合じゃないの？
あと、やっぱり内包表記の説明は「例見りゃ分かるだろ」って感じだなぁ。

768 ：デフォルトの名無しさん：2010/11/14(日) 19:35:36

>>767
[[row[i] for row in mat] for i in [0, 1, 2]]
どう見てもネストだと思うが……

つまり、「例見ても分かってない」わけだなｗ

769 ：デフォルトの名無しさん：2010/11/14(日) 19:42:24

内包表記は……たぶん元ネタにあたる、
集合論での内包表記を分かっていれば
感覚的に扱いやすいのかなあ

770 ：768：2010/11/14(日) 19:45:11

ああごめんごめん、勘違いした

>>767の「ここ」は、上の議論という意味で、
>>732が疑問に思っていたことはforが連続するケースの評価順だから
ネストのケースの説明はとくに解決策にはならないって意味か

俺が日本語を分かってなかっただけのようだｗ

771 ：デフォルトの名無しさん：2010/11/14(日) 19:45:53

>>768
なんかいわゆるPerlの汚さに通じそうな暗号文だなとか言ったら全然違うって言われるんだろうな
理屈がわかれば読める、わからなきゃ読めないって共通項は感じるんだが

772 ：デフォルトの名無しさん：2010/11/14(日) 19:52:43

>>771
pythonのfor文だけ知ってたら分かる
for(i=0;i<10;i++)みたいなのしか知らないと分からない

773 ：デフォルトの名無しさん：2010/11/14(日) 19:59:55

>>772
ActionScript的な for ～ in ... は知っていても、
>>768ではさらにその左に何かあるように見えるが、
これはPythonのfor文の基本なの？

774 ：デフォルトの名無しさん：2010/11/14(日) 20:01:29

[ f(x) for x in xs ]
みたいなのは、
result = []
for x in xs:
result.append(f(x))
と書かずに済ますための便法だと思えばいい
ループの中でリストにpushする式を先頭に書くだけで、後は同じように読める

>>768はネストしてるからちょっと複雑だけど同じ原理
ループで書けばこうなる
xs = []
for i in [0, 1, 2]:
ys = []
for row in mat:
ys.append(row[i])
xs.append(ys)

775 ：デフォルトの名無しさん：2010/11/14(日) 20:21:40

Lispだと
(loop for i from 1 to 10 if (evenp i) collect (* i i))
とか書くんだが、Paul Grahamはloopマクロ嫌いらしいな

776 ：デフォルトの名無しさん：2010/11/14(日) 20:23:20

>>773
>リストの内包表記を怖がらずにネストするためには、右から左へ読んでください。

777 ：デフォルトの名無しさん：2010/11/14(日) 20:31:19

Haskellのリスト内包

Prelude> [(x,y) | x <- [1,2,3], y <- [4,5,6]]
[(1,4),(1,5),(1,6),(2,4),(2,5),(2,6),(3,4),(3,5),(3,6)]

これと同じことをPythonのリスト内包でやるとどんな感じ？

778 ：デフォルトの名無しさん：2010/11/14(日) 20:34:39

>>777
自信ないけど

print [(x,y) for x in [1,2,3] for y in [4,5,6]]
[(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)]

779 ：デフォルトの名無しさん：2010/11/14(日) 20:39:12

>>778
サンクス
Pythonでも右側の方が頻繁に値が変わるのは一緒なのね

780 ：デフォルトの名無しさん：2010/11/14(日) 21:21:07

内包は右から左、ネストは左から右。良かった良かった

print [[(i, x, y) for x in [1,2] for y in [3,4]] for i in [0,1]]
[[(0, 1, 3), (0, 1, 4), (0, 2, 3), (0, 2, 4)], [(1, 1, 3), (1, 1, 4), (1, 2, 3), (1, 2, 4)]]

781 ：デフォルトの名無しさん：2010/11/14(日) 21:37:10

pythonスレでやれば？

782 ：デフォルトの名無しさん：2010/11/14(日) 21:43:12

公式ファレンスやチュートリアルで完璧に理解できるわけがない。
実際にインタプリタ起動して試行錯誤してみて、自分の理解と実際の動作が同じか確認しないと。

783 ：デフォルトの名無しさん：2010/11/14(日) 21:43:22

>>> def product(*lists):
... return [()] if not lists else \
... sum(map(lambda x: map(lambda xs: (x,) + xs, product(*lists[1:])),
... lists[0]), [])
...
>>> product([1,2,3],"AB","xy")
[(1, 'A', 'x'), (1, 'A', 'y'), (1, 'B', 'x'), (1, 'B', 'y'), (2, 'A', 'x'), (2, 'A', 'y'), (2, 'B', 'x'), (2, 'B', 'y'), (3, 'A', 'x'), (3, 'A', 'y'), (3, 'B', 'x'), (3, 'B', 'y')]

こう書くと無駄に暗号的な上に、いかにも効率が悪い

784 ：デフォルトの名無しさん：2010/11/14(日) 21:43:43

まあ各言語の表記の特色はこのスレでやってもらうのは結構楽しいぞ
Perlならたぶんmapなんだろうが、あんまり簡潔に書ける気がしない
確かに強力なリスト表記だとは思う
ってか処理混ざってるからリスト表記、っていうのには正直抵抗はあるけどな

785 ：デフォルトの名無しさん：2010/11/14(日) 21:49:58

map + filter + productって感じなんだが
多重ループで使われるのが独立変数とは限らないので、常にproductというわけでもない
リスト内包を使わず多重ループを書く場合、
Schemeのappend-map、ScalaのflatMap、.NETのSelectManyあたりで
ネストする読みにくいコードになる

Pythonにはこれらのものが無いので、上のコードでは
sum(map(f, xs), [])でflatmap(f, xs)の代用とした

786 ：デフォルトの名無しさん：2010/11/14(日) 21:56:48

>>785
そこまでいくとあんまり楽しくなくなるが、よければ
そのPyton用語っぽいproductについて軽ーくkwsk

787 ：デフォルトの名無しさん：2010/11/14(日) 21:59:16

いやPythonにはproductという関数はないよ
意味は数学のデカルト積で、欲しいのは>>777のような結果

788 ：デフォルトの名無しさん：2010/11/14(日) 22:03:37

剰積っていう意味のproductか、了解。英語弱いわ

789 ：デフォルトの名無しさん：2010/11/14(日) 22:05:21

>>771
Python使いで、単純な内包表記ならすぐ理解できるが、>>768はぱっと見じゃ分からんかった。
内包表記はPythonの文法の中でも特に、黒魔術化しやすい。
とくに中に副作用を伴う命令入れたときはカオスになりやすい。

790 ：デフォルトの名無しさん：2010/11/14(日) 22:13:10

>>787
2.6からはあるよ。
itertools.product(*iterables[, repeat])
ttp://docs.python.org/library/itertools.html#itertools.product
コード例もそこに載ってて、
def product(*args, **kwds):
    # product('ABCD', 'xy') --> Ax Ay Bx By Cx Cy Dx Dy
    # product(range(2), repeat=3) --> 000 001 010 011 100 101 110 111
    pools = map(tuple, args) * kwds.get('repeat', 1)
    result = [[]]
    for pool in pools:
        result = [x+[y] for x in result for y in pool]
    for prod in result:
        yield tuple(prod)

product([1,2,3],"AB","xy")
が、>>783と全く同じ結果を返す。

791 ：デフォルトの名無しさん：2010/11/14(日) 22:14:47

>>790
おー、知らんかった、サンクス
C#で書くとこう、やっぱりなんかキメぇ

var xs = from x in new []{ 1, 2, 3 }
from y in new []{ 4, 5, 6 }
select new { x, y };
var ys = new []{ 1, 2, 3 }.SelectMany(x =>
new []{ 4, 5, 6 }.Select(y =>
new { x, y }));

792 ：デフォルトの名無しさん：2010/11/14(日) 22:35:55

>>765
>批判をするのも自由。その批判を批判するのも自由。
でもPythonをキモいと言うやつは批判するとか何様なのこの人。

793 ：デフォルトの名無しさん：2010/11/14(日) 23:11:55

scala

for版
for {
　x <- 1 to 3
　y <- 4 to 6
} yield (x, y)

flatMap版
(1 to 3).flatMap(x => (4 to 6).map(y => (x, y)))

794 ：デフォルトの名無しさん：2010/11/14(日) 23:18:24

Eclipse GAEでPythonのデバッグ実行ってどうやってますか？
Debug実行をしてもブラウザが起動しないのですが。

795 ：デフォルトの名無しさん：2010/11/14(日) 23:19:58

さすがにPythonに関する質問はPythonスレで汁！

796 ：デフォルトの名無しさん：2010/11/14(日) 23:27:20

PythoでWEBアプリを作成する場合、

self.response.out.write('Hello, webapp World!')

この selef.response.out.write('<html></html>')
という風にHTMLコードを直接埋め込んで行く必要があるのでしょうか？

797 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/14(日) 23:41:57

苦笑

798 ：デフォルトの名無しさん：2010/11/14(日) 23:57:10

>>796
GAEスレで氏ね
Google AppEngine 3アプ目
http://hibari.2ch.net/test/read.cgi/php/1267057923/
Google App Engine 3アプ目
http://hibari.2ch.net/test/read.cgi/php/1267094290/

799 ：methane：2010/11/15(月) 00:08:46

>>789
チュートリアルでも気をつけろって書いてあるし、実際に内包表記でforを複数回使うのは
>>778 ぐらいシンプルな場合だけで、複雑になりそうだったら素直にループ使う方が良いね。

>>792
批判を批判するのも自由と言ってるんだから、「でも、」って繋げるのおかしくない？
そもそも >>709 は批判じゃなくてアドバイス程度のつもりで言ってたんだけど、そんなに気に障った？
それとも単に俺を叩きたくて叩きたくてしょうが無いの？

800 ：デフォルトの名無しさん：2010/11/15(月) 01:42:44

pythonの内包表記が使われ過ぎてる本（レビュー曰く）

集合知プログラミング: Toby Segaran, 當山仁健, 鴨澤眞夫: 本
http://www.amazon.co.jp/dp/4873113644

801 ：デフォルトの名無しさん：2010/11/15(月) 01:47:14

そのうち、Guidoが「内包表記なんて入れるべきじゃなかった。ループで書けばいいやん」とか言い出して内包表記はPythonicじゃなくなるに500スパム

802 ：デフォルトの名無しさん：2010/11/15(月) 06:41:59

>>801
ありそうだし笑える

803 ：デフォルトの名無しさん：2010/11/15(月) 09:39:57

どうでもいいけどこのスレのC#のコードがどれも見にくい。
そりゃLLと比較してくれるなんて光栄だけどさ

804 ：デフォルトの名無しさん：2010/11/15(月) 18:21:06

お前、LL使ってる奴らのC#コードだろ
察しろと

805 ：デフォルトの名無しさん：2010/11/15(月) 19:09:33

>>765
twitterの規約をよく読まずに了承したのか？
拘束力があるのは原典である英語版だけらしいから、最初の Basic Terms の部分だけでも自分で翻訳してみると良い。
不特定多数に読まれることを考慮した上で書けって感じのことが規約に書かれてるぞ。

読む人を制限したけりゃアカウント設定で制限しなさいとも書かれてるみたいだな。
そんなワケで、公開されてる以上2chで取り扱うことは何ら問題ない。
コピペの是非は日本でなくカリフォルニア州の判断次第だしな。

806 ：デフォルトの名無しさん：2010/11/15(月) 19:18:35

法がどうよりいちいちコピペ持ってこられるのは目障りなんだが。
そりゃツイッターは発言力がある人間がやってるってのが大きいんだろうし
コミュニケーションツールといより、有名人とそれを監視する取り巻きみたいな構図になってるが
言いたいことがあって、本人に言えば済む話はそうしてくれるかな
最近ニュー速のソースがツイッターとかよくあるけど、
いくら有名人だからっていちいちニュースにすることかよって思ってた

807 ：デフォルトの名無しさん：2010/11/15(月) 19:20:30

本人が名乗り挙げて来ちゃうんだから仕方ないんじゃね
匿名掲示板なんだから匿名で参加してりゃいいのになw

808 ：デフォルトの名無しさん：2010/11/15(月) 20:53:35

つぶやき vs 便所の落書き

809 ：デフォルトの名無しさん：2010/11/15(月) 23:20:00

Cygwin使っている人いますか？その20
http://hibari.2ch.net/test/read.cgi/unix/1268282846/272-273

272 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:42:30 ID: Be:
マウントオプションとは別に、CRLFをLFに変換するツールはないでしょうか？

美乳セーラー女子高生とSEX顔射フィニッシュ

というコマンドやnkfでも一応可能なのですが
専用のツールはなかったかと思いまして

273 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:43:21 ID: Be:
>>272
コピペミスった、、、、、
見なかったことにしてください

コマンドは、

cat crlf.txt | tr -d '\r' > lf.txt

です。

810 ：デフォルトの名無しさん：2010/11/15(月) 23:26:22

>>805
公開性と著作権を混同するな。

811 ：デフォルトの名無しさん：2010/11/16(火) 00:22:48

著作権違反は申告しないと罪にならないよ。
正確には、警察に著作権者が申告して、裁判で違反者が有罪になるまでは罪じゃないはず。
法律的にはだけど。

812 ：methane：2010/11/16(火) 00:34:03

>>810
>>805の言うとおり、英語の規約読んだら、Twitterの外部のサイトで公開されることを認めろっていう
部分があった。実際Togetterみたいなサービスあるし、俺の方が間違い。

コテハン使ってると>>709みたいな普通の書き込みにもイチイチ突っ込む人がいるけど、
コテハン使わないと痛いPython信者的発言（アンチPythonの自演かもしれないけど）にイチイチ
俺だろうって認定してくるヤツいるし、、、まぁ仕方ないか。

813 ：methane：2010/11/16(火) 02:02:45

>>812
勝手に人を語るなよ

814 ：デフォルトの名無しさん：2010/11/16(火) 03:27:49

だれかとおもったらGAEのスレでもめてるひとか

815 ：デフォルトの名無しさん：2010/11/16(火) 10:25:25

まだ表示してる奴がいることに大変驚きを禁じえない
2chでコテハンやるということ自体明確な証なのに

816 ：デフォルトの名無しさん：2010/11/16(火) 12:49:09

>>815
何の証か気になる。

817 ：methane：2010/11/16(火) 23:49:52

>>743 に指摘してもらった件を修正して、ちょっと訳注足してみたりした。
http://pythonjp.sourceforge.jp/dev/tutorial/datastructures.html#id6
>>732, >>743 ありがとう。

818 ：デフォルトの名無しさん：2010/11/16(火) 23:55:37

(self
(self
(self
(self
(self

ばーーーーーーーーーーーーーーーーーーーーーーーーーーか

819 ：デフォルトの名無しさん：2010/11/17(水) 01:31:50

end
end
end
って見づらいよねー

820 ：デフォルトの名無しさん：2010/11/17(水) 01:43:38

Rubyが糞文法のPythonに敗北した理由は、処理系が不安定すぎるから。

821 ：デフォルトの名無しさん：2010/11/17(水) 02:26:36

Perl基準で見るとどっちも勝ち組

822 ：デフォルトの名無しさん：2010/11/17(水) 05:54:44

>>818-819
お前ら小学生かw

823 ：methane：2010/11/17(水) 11:15:38

Pythonが糞文法のPHPに敗北した理由は、処理系が不安定すぎるから。

824 ：methane：2010/11/17(水) 11:17:01

>>812
建設的な話をするなら他のPythonスレの方がまだマシと思うのですが、
何故アンチの隔離スレにこられたのですか？

825 ：デフォルトの名無しさん：2010/11/17(水) 11:46:42

Rubyは好きだけど、rubyが酷すぎる

826 ：デフォルトの名無しさん：2010/11/17(水) 11:56:11

おまえがJRubyやIronRubyを使うことを誰も禁止はしないと思うのだが

ライブラリという問題があるか

827 ：デフォルトの名無しさん：2010/11/17(水) 12:13:58

ここってアンチの隔離スレだったのか
まあ、いろんな言語のアンチが仲良く集ってるという意味じゃ間違ってないかも

828 ：デフォルトの名無しさん：2010/11/17(水) 12:20:33

>>827
違う
自分の利用してるスレに書かれたレスが、
返事をするに値するものかどうかをこのスレの最新レスを見て判断する

たいてい同じような言語の同じようなレスが書いてあるから、それはスルーする

829 ：デフォルトの名無しさん：2010/11/17(水) 12:49:40

マルチ見つけるために質問スレ横断しておくのと似たようなもんか

830 ：デフォルトの名無しさん：2010/11/17(水) 15:08:33

それは目的が逆転してるぞ
マルチがマナー違反とされるのは
類似の話題のスレなら住人もある程度被るワケで
そこで全く同じレスを見つけて不快になるからであって
マルチを見つけるために似たようなスレを巡るのではない

831 ：デフォルトの名無しさん：2010/11/17(水) 15:16:44

マルチを指摘して悦にはいりたいんだよ。
言わせんな恥ずかしい

832 ：デフォルトの名無しさん：2010/11/17(水) 15:19:40

>>830
お前この板のマルチポストの問題何もわかってないんだな

833 ：デフォルトの名無しさん：2010/11/17(水) 15:24:47

ここの質問系のマルチポストレスの問題って9割くらいは
「第三者によって勝手にマルチポストにされてる＆マルチするなと元スレで封じ込め食らってる」
だと思うの
というかみんな経験くらいあるもんだと思ってた

834 ：デフォルトの名無しさん：2010/11/17(水) 15:34:58

この板はID出ないからなあ
出たらいいのに

835 ：デフォルトの名無しさん：2010/11/17(水) 15:36:20

http://groups.google.com/group/play-framework/browse_thread/thread/cf029b08e0807793

Scala + Play! Framework で、RailsライクなScailsを作るそうですよ。

836 ：デフォルトの名無しさん：2010/11/17(水) 15:36:22

>>823
PHPよく落ちるよ
Apacheが再起動してくれてるだけ

837 ：デフォルトの名無しさん：2010/11/17(水) 15:37:43

まぁLL最強はPythonってことでこのスレ終了

838 ：デフォルトの名無しさん：2010/11/17(水) 15:38:24

>>833
Rubyで2回ほど経験がある
あれ同じ人だよね
質問するのはスレを初めて利用する人だけだからバレないとでも思ってたんだろうか

>>835
名前だけは超かっこいい

839 ：デフォルトの名無しさん：2010/11/17(水) 15:39:18

>>835
Python で Pails 作ろうとした漏れがいます

840 ：デフォルトの名無しさん：2010/11/17(水) 16:30:03

>>838
かっこいいね

841 ：デフォルトの名無しさん：2010/11/17(水) 16:49:22

rubyが好きなんだけど、環境がいまいち整理されていなくて
いつ見ても発展途上な感じがする

perlの方が環境が整理されてて、業務で使えそうな気がする

ということでせっかくrubyを始めたけどperlに変更（笑）

842 ：デフォルトの名無しさん：2010/11/17(水) 17:52:41

なにをー、rubyは純日本製で書籍もいっぱい出てるんだぞー！

843 ：デフォルトの名無しさん：2010/11/17(水) 18:41:35

海外でもお前らみたいなことやってる

Issues - martinemde/learn-ruby-the-hard-way - GitHub
https://github.com/martinemde/learn-ruby-the-hard-way/issues/1

Shedding Bikes: Programming Culture And Philosophy
http://sheddingbikes.com/posts/1285754959.html

Zedがまたやっている:「自分の本を書け」 - karasuyamatenguの日記
http://d.hatena.ne.jp/karasuyamatengu/20101107/1289082916

844 ：デフォルトの名無しさん：2010/11/17(水) 19:32:52

ZedのPython入門は前一度見た限りではよさげだったな
堅実なアプローチで

ところでこのスレと>>843の共通点はどのあたりに

845 ：デフォルトの名無しさん：2010/11/17(水) 21:01:56

rubyの本はたくさんあって趣味や教育、ちょっとした用途に使えるのはよくわかる

なぜ標準の環境を提供しようとしないのかわからない

846 ：デフォルトの名無しさん：2010/11/17(水) 21:42:50

rubyは所詮趣味でしか使えない

847 ：デフォルトの名無しさん：2010/11/17(水) 22:36:44

規格化したらりんごから抹殺された

848 ：デフォルトの名無しさん：2010/11/17(水) 22:46:04

標準の環境って言うのがWindowsバイナリのことなら自分も禿同

849 ：デフォルトの名無しさん：2010/11/17(水) 22:48:35

すみません
RubyをWindowsにインストールして勉強したいのですが
Windows用のRubyのパッケージがいっぱいあって
どれをダウンロードしたら良いのか分かりません
それぞれ特徴とかメリットとかデメリットとか
速度の違いとかあるのでしょうか？

850 ：デフォルトの名無しさん：2010/11/17(水) 23:10:40

そういえばrubyがjisだかisoだかの規格になる話はどうなったの

851 ：デフォルトの名無しさん：2010/11/17(水) 23:31:08

>>844
ZedはRubyのmongrelつくってるくらいだけどをRubyをdisって炎上した経緯がありましてですね

852 ：デフォルトの名無しさん：2010/11/17(水) 23:33:43

>>851
Zedのrubyの代表作mongrel＝Webサーバー
Ruby標準のWebサーバーが遅いので、Railsの開発時に代わりに使ったりする

今でこそいろいろRailsで使えるWebサーバーがあったけど、
ちょっと前は本番でも使われてた。cookpadは今でも使ってるかもな。

853 ：デフォルトの名無しさん：2010/11/17(水) 23:51:27

>>851
それは知ってるけど、このスレとはいまだに共通点が（略

854 ：デフォルトの名無しさん：2010/11/18(木) 00:00:40

入門自然言語処理を禁書にすべき10の理由 | TRIVIAL TECHNOLOGIES on CLOUD
http://coreblog.org/ats/ten-reasons-why-analyzing-text-with-the-nltp-should-be-a-prohibited-book

855 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 00:28:40

ルビーって文法がきもすぎてきもすぎてうんこ漏れそうですぅ

856 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 00:29:53

ﾌﾟﾘｯﾌﾟﾘｯﾌﾟﾘｯ！！ｼｭｯｼｭ！ﾌﾟﾊｰｰｰｰ！（ー＿ー；）

857 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 00:32:03

class Lion < Animal # 継承
def initialize # オーバーライド
@word = "がおー"
end
end

animal = Animal.new # インスタンス生成
monkey = Monkey.new
lion = Lion.new

animal.speak(2) # 多態性の例
monkey.speak
lion.speak(3)

$ ruby animal.rb
ほげほげ
うっきー
がおーがおーがおー

858 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 00:36:45

長年のノウハウ＋CPANがあるのに
RUBYつかうのですか

ふっ(笑）

859 ：デフォルトの名無しさん：2010/11/18(木) 02:17:16

>>854
自然言語処理は素人なんだが
『言語処理のための機械学習入門』はすばらしかった

860 ：デフォルトの名無しさん：2010/11/18(木) 03:37:40

もうperlがないと生きていけない体になってしもうた

861 ：デフォルトの名無しさん：2010/11/18(木) 03:56:08

オールドPerl使いは黙ってろ

862 ：デフォルトの名無しさん：2010/11/18(木) 04:32:48

今時perlとかって、恥ずかしくないの？

863 ：デフォルトの名無しさん：2010/11/18(木) 05:00:23

うむ、こんな時間に

> 862 名前：デフォルトの名無しさん [sage]： 2010/11/18(木) 04:32:48

それも、sageで、こんなこと

> 今時perlとかって、恥ずかしくないの？

書き込みにくるよりは、ましだとおもうよ？

864 ：デフォルトの名無しさん：2010/11/18(木) 06:50:46

むしろTIMTOWTDIからイディオムで縛るシンプルな書き方へと移っていった
Perlの生き様には恥ずかしいどころか畏敬の念さえ覚える
ネストしたデータ構造がもう少し簡単に扱えれば今でもPerlでいいぐらいだ

865 ：デフォルトの名無しさん：2010/11/18(木) 07:05:46

Perlの、参照なのか即値なのか、リストなのかスカラなのかを
いちいち気にしながらアクセスする仕様は
複雑なデータ構造を扱うにはやや面倒いね
しかも違う方式で扱った時にもちゃんと意味があったりして
一見まともな値が返ってくるのが困り者
アクセスの仕方を間違えてても区別がつきづらい

866 ：デフォルトの名無しさん：2010/11/18(木) 07:15:26

Perlの、スカラコンテキストと配列コンテキスト、あれが許せない。
なんなのあれ。あれのせいでどんだけプログラムがわかりづらくなっていることか。

867 ：デフォルトの名無しさん：2010/11/18(木) 07:25:27

Perlの話をするときはモダンPerlなのかそれ以前なのか書き込みにメタ情報をつけてくれ頼む

868 ：デフォルトの名無しさん：2010/11/18(木) 07:33:42

モダンだとその辺は大丈夫なの？
最近のPerl事情詳しくないのでkwsk

869 ：デフォルトの名無しさん：2010/11/18(木) 08:46:17

スカラコンテキストとリストコンテキストの違いで混乱するのは同意。
あまり取り上げられないので、初心者の壁になってるように思う。

870 ：デフォルトの名無しさん：2010/11/18(木) 09:21:48

いやなものをいやいや使う神経って理解出来ないわ

871 ：デフォルトの名無しさん：2010/11/18(木) 10:07:20

>>870
レス番付けないと、誰へのレスか分からんぞ。

872 ：デフォルトの名無しさん：2010/11/18(木) 11:17:36

関数がwantarrayを使ってて返値の受け取り方を使い分ける必要がある事って滅多にないから、気にすることないと思うけど。
リストリファレンスを受け取ってるつもりで、実はリストそのものが返ってきていたってミスはあるけど、型指定出来ないスクリプト言語ならどれだってありがちなミスでしょう。

873 ：デフォルトの名無しさん：2010/11/18(木) 12:38:00

基本的な部分で、評価コンテキストを意識する必要があるわけで。

# 配列はスカラコンテキストで評価されると要素数を、
# リストコンテキストで評価されると内容を返す
# printの引数はリストコンテキストで評価される
my @array = (1, 2, 3);
print @array, "\n"; # (1, 2, 3) (内容)
print scalar @array, "\n"; # 3 (要素数)
print 0 + @array, "\n"; # 3 (要素数)

# コンテキストで正規表現のマッチング動作が変わる
$str =~ m/(\w+)/g; # 1つマッチしたところで止まる
my @m = $str =~ m/(\w+)/g; # $strを全部舐める

874 ：デフォルトの名無しさん：2010/11/18(木) 12:53:27

>>873
># 配列はスカラコンテキストで評価されると要素数を返す
これってほんとクソ仕様だよな。count(@array)で要素数を返す、とかにしてほしかった。

875 ：デフォルトの名無しさん：2010/11/18(木) 14:04:59

C/C++では、配列や関数をポインタに変換するコンテキストや
lvalueのコンテキストなどを意識する必要がある

一方Javaは、配列や関数を参照するにはNullableな変数を経由する必要がある
(staticメソッドは除く)

876 ：デフォルトの名無しさん：2010/11/18(木) 14:22:35

何がET

877 ：デフォルトの名無しさん：2010/11/18(木) 15:04:11

Perlはごくふつうの名前付き仮引数がなくて、関数の引数をいちいち手動で
アンパックしないといけない時点で俺は嫌だな
Perlの人は、いちいちshiftとか書くの面倒くさくないんだろうか？

878 ：デフォルトの名無しさん：2010/11/18(木) 15:04:45

古くからのPerlコードは、単に古くさい駄目さを感じる。
モダンPerlのコードは、袋小路に入った駄目さを感じる。

879 ：デフォルトの名無しさん：2010/11/18(木) 15:27:23

>>877
それに加えて引数のデフォルト値が指定できないとか、いまどきそんなスクリプト言語はPerlとJSくらいじゃね？

880 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 16:47:02

ニートはモダン気にしなくてもいいですよ

ニートなので

ふっ(笑）

881 ：デフォルトの名無しさん：2010/11/18(木) 21:40:29

スクリプト言語を複数操れる才能がある人ってどのくらいいるの？

882 ：デフォルトの名無しさん：2010/11/18(木) 21:44:03

3人に1人くらい

883 ：デフォルトの名無しさん：2010/11/18(木) 21:55:41

>>879
JavaやC#にもない理由は、言われて
みれば至極ごもっとも、C++にある
ほうが間違いだと思えるんだけど。

オーバーライドやオーバーロードで
混乱する原因だぞ。

884 ：デフォルトの名無しさん：2010/11/18(木) 21:58:26

>>883
C#にデフォルト引数あるぞ

885 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 22:00:16

今後の予定

Perl忍者というコテハンの戦闘力上昇をさせる

まずそのための段階

１、発言回数を増やし　知名度をあげる
２、ブログの更新回数を増やし固定ユーザーを獲得

１についてですが

一人だと書き込み(発言）が大変なのでPerlのちからを借りるわけでもなく
トリップ共有ということで　複数人でいろいろなスレにかきこみます
それで色々なスレに書き込むことで知名度があがります

２、これはネトゲなど２chネタなどまとめサイトをかいて　２ch意外のやつらからもユーザーを獲得するこころみです

↓
とりあえずネームバリュー向上のために最善をつくす

知名度をあげてアフェリの成功率をあげる

そして２ch専用ギルドを作る
２chを統一する　全てのネトゲプレイ代行＋荒らし＋釣り＋アプリ作成＋オフ会準備などを請け負う最強の団体へと進化する

886 ：デフォルトの名無しさん：2010/11/18(木) 22:06:02

擁護る。Perl使いのはしくれとして。

>>873
＞# コンテキストで正規表現のマッチング動作が変わる
でも、その挙動が影響するのはレア。
# これは、ハマるときにはハマるんで、
# さすがに擁護しづらいな。orz

>>874
＞。count(@array)で要素数を返す、とかにしてほしかった。
つ　scalar(@array)

>>877
＞Perlはごくふつうの名前付き仮引数がなくて、関数の引数をいちいち手動で
＞アンパックしないといけない
つ　ハッシュ
効率を気にするなら、そのリファレンス。

887 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/18(木) 22:12:51

文法でわめきあってる時点でだから相当低ベル

888 ：883：2010/11/18(木) 22:13:46

>>884
うそん、そうだっけか…orz
しばらく使ってないから混ぜてしもうた。

オーバーライドなんかどーすんの？
できなくなるんだっけ？

889 ：デフォルトの名無しさん：2010/11/18(木) 22:19:38

>>8７７
> アンパック

sub test
{
my %args = (
'a' => 0,
'b' => 0,
@_);
printf "a: %s, ", $args{'a'};
printf "b: %s\n", $args{'b'};
}

test('a'=>11, 'b'=>12); #=> a: 11, b: 12

こんな感じだっけ。
まあたしかに、書き方が違うだけといえばそれだけって・・・ちょっと苦しいか

890 ：デフォルトの名無しさん：2010/11/18(木) 22:24:16

>>888
型で判断されるからデフォルト値は関係ない

891 ：デフォルトの名無しさん：2010/11/18(木) 22:54:18

>>886
え？なんでハッシュで普通の名前付き仮引数の代わりだと言えるのか分からない
それでキーワード引数っぽいことができるのは分かるけれども

function add(x, y) { return x + y }
add(1, 2)

のようなごく普通のポジショナルな引数が欲しい一般的なケースにおいて、

add('lhs'=>1, 'rhs'=>2)
とか呼ばなければいけないとしたら面倒なだけだろう

892 ：デフォルトの名無しさん：2010/11/18(木) 22:57:58

Rubyちゃんがおびえています

893 ：デフォルトの名無しさん：2010/11/18(木) 23:08:58

ああ「名前つき仮引数」とかいう言い方が悪かったのか、ごめん
ただのごく普通の仮引数リストのことだと思って欲しい

勿論可変長引数やキーワード引数もあったほうが便利だけど、
どちらかといえばそれらが使われるのはレアなのに
Perlはそれらに適した方法「しか」用意していないように見える
それがなんかおかしいし、不便だと思う

894 ：デフォルトの名無しさん：2010/11/18(木) 23:20:51

>>893
> ごく普通の仮引数リスト
こんな感じ？まあ、面倒なのは確かかもだけど

sub test
{
my ($a, $b) = @_;
$a |= 0; $b |= 0;

printf "a: %s, ", $a;
printf "b: %s\n", $b;
}

test(); #=> a: 0, b: 0
test(1); #=> a: 1, b: 0
test(11, 12); #=> a: 11, b: 12

895 ：デフォルトの名無しさん：2010/11/18(木) 23:46:58

Python/Rubyも可変長引数やキーワード引数を扱いたければ
リストや辞書/ハッシュで受けて内部で展開してるわけだし
特にPerlが遅れをとってるってことはなさそうな気が

sub test { みたいにシグネチャの情報量が少ないのが
他の言語を使ってる人から見て違和感あるだけじゃないだろうか

896 ：デフォルトの名無しさん：2010/11/18(木) 23:53:26

いや
def f(n) {
と
sub f { my $n = shift;
じゃ冗長さも読みやすさも全然違うでしょ

なにが遅れを取ってないんだか分からない

897 ：デフォルトの名無しさん：2010/11/18(木) 23:56:16

読みやすさでは後れを取ってるけど、読みにくさでは後れを取ってない

898 ：デフォルトの名無しさん：2010/11/19(金) 00:04:50

>>896
そこはほらLisperが括弧を気にしないのと一緒だよ
もっと言えば日本人が漢字をすらすら読めるのと一緒

自分でも言ってて辛くなってきた

899 ：デフォルトの名無しさん：2010/11/19(金) 00:06:34

Perlなんて誰が今から好き好んで勉強するのか

900 ：デフォルトの名無しさん：2010/11/19(金) 00:17:02

>>886
＞＞。count(@array)で要素数を返す、とかにしてほしかった。
＞つ　scalar(@array)

俺はその人ではないが、その人に同感なので書いとく
問題はそこじゃなくて
「スカラコンテキストでリストを書くとエラー」にして欲しかったんだよ。
要素数は関数で得るようにして、ね。foreachあるから要素数は本当に要素数が必要な時にしか要らないんだしさ。
そうすりゃ、間違えたときに判りやすいだろ？
単純なリストだけ使ってるならあんまり問題にならんが
リストへのリファレンスやハッシュ、
そこに数値や文字列などの単純なスカラも入り組んだ
複雑なデータ構造になってくると結構混乱するんだよ。

901 ：デフォルトの名無しさん：2010/11/19(金) 00:19:17

PerlにPython,Lisp
あとLLでは無いがCは覚えておいたほうがいい

902 ：デフォルトの名無しさん：2010/11/19(金) 00:20:09

LispはLLなのか

903 ：デフォルトの名無しさん：2010/11/19(金) 00:41:34

LispはLispである。

904 ：デフォルトの名無しさん：2010/11/19(金) 00:44:51

Lisp自体をLLに分類するのはやや苦しいな
でも高度なリスト操作に高階関数にイテレータにGC…と今のLLの基準になるような機能を
真っ先に実現しちゃってた、LLへの功労者の1つではあると思う
未だにプログラミング言語そのものの研究ではしばしば使われる言語だしな

905 ：デフォルトの名無しさん：2010/11/19(金) 00:45:35

scheme手習いって本読んでみたいけど、書けるようになってもライブラリとかが不安

906 ：デフォルトの名無しさん：2010/11/19(金) 00:45:42

>>899
Perl6は面白そうｗ
なんていうかプログラマが好みそうな言語

907 ：デフォルトの名無しさん：2010/11/19(金) 00:47:59

>>905
Clojureでおｋ

908 ：デフォルトの名無しさん：2010/11/19(金) 00:51:55

>>3に書いてあることだけ読むと、LispはLLと言ってもよいように思えるが
「簡単なことを簡単に書ける」という意味でプログラマの負担が「軽い」言語じゃ
ないような気がする

すぐに食えるインスタントラーメンみたいなのが豊富にないかわりに
メタ解みたいなのが用意されているというか

909 ：デフォルトの名無しさん：2010/11/19(金) 01:21:56

>>908
まあねえ、全てを括弧でくくる仕様のお陰で優先順位とかは気にしなくて良いけど
お陰でプログラマが自らパーザを書いてるような状態だしw
あと計算式が素直に書けない（四則演算すらも+関数、-関数などを呼ぶように書くため）のもマイナスだろうね

910 ：デフォルトの名無しさん：2010/11/19(金) 01:27:49

計算式は
(+ 1 2 3)
とか
(mapcar #'+ '(1 2 3) '(4 5 6))
とか書ける利点もあるので、まあそんなに…

どっちかっつーと
a[i] = x
を
(setf (aref a i) x)
とか書くのがめんどうくさい

911 ：デフォルトの名無しさん：2010/11/19(金) 01:33:45

そうか、代入も関数（的な記法のマクロだっけか）だもんな

912 ：デフォルトの名無しさん：2010/11/19(金) 01:45:40

ifのtrue-statementの所が複文になった時
いちいちprognが必要なのが地味にめんどい

この辺はS式の記法的な限界なのかなあ？
C系言語みたいに、区切りとしてシンボルにelseとかを置くようにすれば
真/偽両側に複文が許されて嬉しい気がするんだが、
シンボルに重大な意味を持たせるのはLisp的にはご法度なんだろうか？

(if cond
　　something
else
　　other)

913 ：デフォルトの名無しさん：2010/11/19(金) 01:51:25

Perlは、LL界のFortranだな。

Perl6とFortran 2008って、どっちが普及するかな？

914 ：デフォルトの名無しさん：2010/11/19(金) 01:53:06

>>912
改行とインデントつけてそれっぽくしてるけど、
(if cond something else other)
これってLispで受け入れられる構文なのか？本当によくわからんなLispってのは

915 ：デフォルトの名無しさん：2010/11/19(金) 01:54:41

そこらへんはマクロでいくらでも思い通りにできるが
普及しなかったとこを見ると今のifとcondで十分だったのかな

916 ：デフォルトの名無しさん：2010/11/19(金) 01:55:46

>>912
cond, when, unlessではだめなの？

>>913
Perl6はほとんど知らないのだけど、なんで$とか@が生き残ってるのかわからない
あれ要らないと思うんだけど……

917 ：デフォルトの名無しさん：2010/11/19(金) 02:00:05

>>914
関数呼び出しは(関数名引数引数...)で、比較演算も全て関数なので…
実現したとしたら、実際にはこんな感じになるのかな

(if (< x 10)
　　(foo)
　　(bar x)
'else
　　(foo)
　　(bar (+ x 1)))

う～ん、なんかLispっぽく無い気もするが、アリっちゃアリかも知れない
でもLisp系の(if)のtrue部って、長く書くこと少なくね？
自分が無意識的にそうしちゃってるのかも知れないが

918 ：デフォルトの名無しさん：2010/11/19(金) 02:06:28

Perl5の引数は確かに機能的に劣ってると思うけど（だから、Perl6で強化されてる）、どっちみちタイプヒンティング出来ないんだったら、引数を連想配列で渡すやり方でそれほど不便は感じないな。

919 ：デフォルトの名無しさん：2010/11/19(金) 02:09:24

>>917
どうしてもcondで書きたくない理由があるの？
progn要るようなものはcondで書くのが普通だと思うけど

920 ：デフォルトの名無しさん：2010/11/19(金) 02:32:19

>>918
俺は困ってないから知らねえよ、>>912に聞いてくれw

921 ：920：2010/11/19(金) 02:33:06

レス番号ミス、>>919宛ね

922 ：デフォルトの名無しさん：2010/11/19(金) 05:03:10

>>886
>＞。count(@array)で要素数を返す、とかにしてほしかった。
>つ　scalar(@array)
もとの文章をちゃんと読め。
もともとは、>>873
># 配列はスカラコンテキストで評価されると要素数を返す
という仕様がわかりづらいから、>>874
> count(@array)で要素数を返す、とかにしてほしかった。
という流れなのに、
そこで「要素数を知りたいならscalar(@array)」と言い出すのは、何の解決にもなっていない。

配列をスカラコンテキストで評価したら要素数が返るという仕様がクソだ、という話に、scalar() を持ち出すのがいかにばかげてるか、わかる？

923 ：デフォルトの名無しさん：2010/11/19(金) 07:33:34

その程度の単純な例をPerl使いが苦にするとは思えないんだが
もうちょっとバグに繋がるような例を持ってきて叩くべきじゃないか

また左辺がコンテキストを提供すれば右辺でわざわざ
countだのlengthだの使わずに済んで簡潔に書けるのは利点のようにも思える

924 ：デフォルトの名無しさん：2010/11/19(金) 09:51:43

>>900

925 ：デフォルトの名無しさん：2010/11/19(金) 09:59:57

レスアンカーだけ書いて何か言ったつもりになっている奴っているよな。

とにかく俺の言う事が気に入らないもんだから
何とかして俺のレスを無効化してやりたいのだが、
かといってどこにツッコミ所があるのか具体的に指摘出来ないし
俺と正対して論破出来る知識も自信も無い、
何より自分の無知を曝け出す結果となって
かえって自分が周囲の嘲笑の的となってしまうのが怖い。

そこで、とりあえず無言でレスアンカーだけを付けておく事で
「こいつイタイなｗ晒し上げｗ」と必死に周囲に印象付けようとする。
具体的指摘を伴わない無言レスアンカーなら
自分の勘違いだったところで自分はちっとも傷付かずに済むからな。

肝心のどう“イタイ”のかについては周囲にお任せ。
きっと読んだ人それぞれが頭の中で勝手に考えてくれるさ！！

俺には、無言レスアンカーからは
「ママ、こいつをやっつけてよ！」という悲痛な叫びが聞こえてくるね。

926 ：デフォルトの名無しさん：2010/11/19(金) 11:57:27

rubyやpythonがperlやphpより文法的に整理されてたり優れてるのは分かるけど
webでもデスクトップでも仕事じゃろくに使われてないし求人もないよね
何に使うの？趣味？

927 ：デフォルトの名無しさん：2010/11/19(金) 12:13:54

後発の言語にパクられてない仕様は、クソ仕様。
Perlのコンテキストがいい例。

928 ：デフォルトの名無しさん：2010/11/19(金) 13:09:56

> webでもデスクトップでも仕事じゃろくに使われてないし求人もないよね
> 何に使うの？趣味？

まずは自分の脳内妄想に基づいて物事を考えるのをやめましょうw

929 ：デフォルトの名無しさん：2010/11/19(金) 13:17:09

>>925
いや、気に入らないんじゃない、読めって意味で書いただけだ。

…あとな。全然痛い奴じゃ無かったのに、そのレスで痛い奴になっちゃってるぞ、悪いけど。

930 ：デフォルトの名無しさん：2010/11/19(金) 13:53:38

>>925ってコピペでしょ

931 ：デフォルトの名無しさん：2010/11/19(金) 14:47:20

コピペだね
漏れは>>923だけどこのレスまで書き込んでないよ >>929

>>900に触れるなら複雑なデータ構造の扱いで混乱しやすい原因は
Perlのスカラと非スカラを区別する変数モデルが
複雑なデータ構造を気軽に扱うのに向いていないことに加え
リファレンス/デリファレンスの理解しやすい文法がないからだろう
コンテキストそのものが悪かっていうと疑問だ

みたいに適当なことをを具体例も挙げずに言うのは失礼だから今まで黙ってた

932 ：デフォルトの名無しさん：2010/11/19(金) 20:39:08

>>931
変数をダンプすればすぐわかるので、
あんまり問題にならない。

933 ：デフォルトの名無しさん：2010/11/19(金) 22:56:02

スカラ変数にリテラルもリファレンスも代入出来るのが問題だと思う。
リテラル変数とリファレンス変数に分けて、シジルも別にすれば良かった。
そうすれば、関数の戻り値の間違って受け取るとコンパイルエラーになるから、そういうミスはなくなる。
この辺はPerl6で解消されてるけど。

934 ：デフォルトの名無しさん：2010/11/19(金) 23:02:43

Perl6なんか、やる馬鹿いないよ。

935 ：デフォルトの名無しさん：2010/11/19(金) 23:25:00

スカラとリストとハッシュを区別してるのは問題ない。というか、そっちの方が良い。
文字列を格納するつもりで用意した変数に配列を代入するというのはあってはならない事だから。
ただ、スカラがリテラルもリファレンスも格納出来るのが問題。

936 ：デフォルトの名無しさん：2010/11/19(金) 23:32:53

Perlに関してのみの話じゃないけど歴史的経緯を無視しても仕方無い話じゃね？
Perlが一時代を築いたのも、その当時として価値があったからこそだし
翻ってpythonやrubyに次代を牽引する力があるか

937 ：デフォルトの名無しさん：2010/11/19(金) 23:34:02

> 文字列を格納するつもりで用意した変数に配列を代入するというのは
> あってはならない事だから。
動的型でそういう発想って俺にはちょっと分からない
入れ子のリストで木を表現するのとか、ごく普通でない？

Perlはそういうことをするのにリファレンスを使わなければならない
そしてリファレンスを使って結局一緒くたにするのなら、
区別する意味が無いように俺には見える

938 ：デフォルトの名無しさん：2010/11/19(金) 23:41:05

いまや産業遺産となってるPerlの文法にケチ付けるなんて、どうかしてるとしか思えない。

939 ：デフォルトの名無しさん：2010/11/20(土) 00:18:43

Perl5よりも新しいと言われ、Python3よりも古いと言われる
ダブルバインド

940 ：デフォルトの名無しさん：2010/11/20(土) 00:38:30

開発体制がいまいちなものは使いたくない

941 ：デフォルトの名無しさん：2010/11/20(土) 01:49:47

>>937
意図してそうするのと、意図せずにそうしちゃうのは全然違う。

942 ：912：2010/11/20(土) 01:52:27

>>919
arcのエッセイでポールグレアムさんが指摘していたと思うけれど、
condは括弧が多くて見づらくね？
あまり積極的に使いたくない

まあLispは日曜日にいじる程度なので、
もっと慣れれば違うのかもしれないが……
Lisperの人にとっては別に気にならない？

943 ：デフォルトの名無しさん：2010/11/20(土) 02:13:19

>>941
よくわからないな
リファレンスと生配列があるお陰で
$a->[0]と$a[0]を使い分ける必要があったり、リテラルも2種類あったり、
LLなのに無駄に複雑で面倒なだけにしか見えないけど

木といわずとも、単なるリストのリストや2次元配列程度で
すでにリファレンスは必要だし、その時点で生配列の存在意義が疑わしいし

配列とハッシュ「だけ」型の区別がついたところで、正直何が有難いんだかも
よくわからないし

Javaですらクラスは全部参照型なのでずっと単純だよね

944 ：デフォルトの名無しさん：2010/11/20(土) 02:19:12

Perlの文法は古典芸能

945 ：デフォルトの名無しさん：2010/11/20(土) 02:29:53

つか、Perlのライバルはawk, sedで、文法がどうとか議論する時代じゃない。

946 ：デフォルトの名無しさん：2010/11/20(土) 02:34:36

まあそうだね。
この分野に関しては、使えるか使えないか、だけが問題な気がする
んで、Perl5は実際Lispよりは結構広く使えるんだぜと

947 ：デフォルトの名無しさん：2010/11/20(土) 02:57:14

>>943
> 文字列を格納するつもりで用意した変数に配列を代入するというのは
> あってはならない事だから。
へのレスであって、別にリファレンスと生配列の話はしてない。

948 ：デフォルトの名無しさん：2010/11/20(土) 03:16:30

>>927
>後発の言語にパクられてない仕様は、クソ仕様。
>Perlのコンテキストがいい例。
超同意。あと@varと$var[]と$var{}とか。evalがtry-catchのかわりとか。packageがclass代わりだとか。

949 ：デフォルトの名無しさん：2010/11/20(土) 08:31:37

そろそろ真の大ボスPowerShellたんについて話そうぜ

950 ：デフォルトの名無しさん：2010/11/20(土) 08:49:53

MSってなんなの？
何がしたいの？

951 ：デフォルトの名無しさん：2010/11/20(土) 10:55:28

>>949
windowsでしか動かないって時点で却下。
windowsしか使わない人にはいいと思う。

952 ：デフォルトの名無しさん：2010/11/20(土) 12:21:05

>>949
シジルが必要な時点で俺の中ではLLのカテゴリに入らないなぁ

PowerShellはインタラクティブにぽちぽちやってみて
定型作業に落とし込めたらスクリプト化する
っていう使い方がしっくりくる

emacsキーバインドをサポートしてbash程度のヒストリサーチがあれば・・・

953 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 12:30:54

awkとかsedとかいってるばかは
マイトガイの影響うけたウソガキ

954 ：デフォルトの名無しさん：2010/11/20(土) 13:37:05

ここでPerlのコードを拝んだことがほとんど無いから
Perl使いはこのスレを見てないのかと思っていたが、結構いるんだなｗ

PowerShellはまともに使ったこと無いな
ngenしても起動が遅すぎてシェルとして常用する気にならんし
.NETのREPLが欲しいだけならF#やIronなんとかでよくね？と思ってしまう

955 ：デフォルトの名無しさん：2010/11/20(土) 14:34:51

>>942
Lispの場合「括弧の多さ」はそもそも言語そのものが根本的に抱えてるもので
condに限ったことじゃなく根本的なとこ、括弧が多くなるのはどんな書き方しても変わらない
ぶっちゃけLisperやってる時点で括弧の量には耐性ついてるだろ

>>954
シェルレベルでオブジェクトを扱えるのは凄いとは思うんだよな
ただちょっとそれが便利になる環境がまだ揃ってないと思う

956 ：Perl忍者：2010/11/20(土) 14:46:01

Perl最強だぜ！

957 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 15:43:42

strftimeのstrfってなに？
なんの略？

意味教えてください

958 ：Perl忍者：2010/11/20(土) 15:45:08

やっぱりイイわ

959 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 15:46:20

そんな影武者やりたいなら
トリップ教えるからSkype着てください

960 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 15:48:33

strfっ手どういう意味か教えてください

961 ：Perl忍者 ◇M5ZWRnXOj6：2010/11/20(土) 15:53:48

やっぱりイイわ

962 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 15:58:00

string formatの略でいいんですか？
strpは
string parserの略ですか？
おしえてうだわい

963 ：Perl忍者 ◇M5ZWRnXOj6：2010/11/20(土) 18:20:55

早く教えろって言ってんだろカス共

964 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/20(土) 19:01:07

短期は損気

965 ：デフォルトの名無しさん：2010/11/20(土) 22:02:24

>>954
F#なんかのREPLだと，普通のシェルでやってるような
cdとかlsとか面倒じゃね？
ipythonがIronPythonでも使えるならいいけど

SSDに変えてから起動の遅さは気にならなくなったな

>>955
>ただちょっとそれが便利になる環境がまだ揃ってないと思う
確かにそんなかんじ
使う方にもパラダイムシフトが要求されるし

966 ：デフォルトの名無しさん：2010/11/20(土) 23:04:37

>>965
シェルでやるようなことはそれこそシェルでやるので…

まあ両方出来るのがいいのだ、ということかもしらんけど
ipython, eshell, tclshとかも使わないから
自分の中にその手のニーズが無いだけかも

シェルもzshとかじゃなくてbashだし
bashも補完が全然無いと寂しいから使ってるだけで、機能的にはこんなに要らないって
感じ

967 ：デフォルトの名無しさん：2010/11/20(土) 23:43:02

>>966
なるほど
確かにPowerShellをシェルとして使って便利だなぁって思うのは
レジストリやActiveDirectoryなんかをいじる時なので
あまり一般向けじゃないかも

968 ：デフォルトの名無しさん：2010/11/21(日) 00:46:24

シェルでできることとスクリプト言語でできることがダブってるときどうする？
スクリプトですべてやった方が綺麗な気がするが

969 ：デフォルトの名無しさん：2010/11/21(日) 01:17:49

>>965
詳しくないんだけど
シェルとちがって外部コマンドをパイプラインで接続したりリダイレクトすると
どうもいちいちString[]に変換してテキストとしてリスト処理するようなので、
ストリームを流れるデータがバイナリの場合や、テキストであっても
エンコーディングがPowerShellの想定外の場合にはあっさりデータが壊れるので
とても困ると思った

外部コマンド | 外部コマンド
とか
外部コマンド > ファイル
みたいな場合には、完全に無駄で余計なお世話でしかない処理だし……

なんか上手い方法はあるのかな、この辺もあってシェルの代用に使う気に
なれなかった

>>968
昔はシェルスクリプトで書けることはなるべくシェルスクリプトで書いていた
今はシェルスクリプトを書く機会は大分減ったな
もっぱらコマンドインタプリタとしての利用が大半

970 ：デフォルトの名無しさん：2010/11/21(日) 01:40:02

>>969
確かに文字コードははまりどころだね
テキストファイルなら Out-File で文字コードを指定してあげることで回避できるけど
バイナリはどうするんだろうねぇ？

971 ：デフォルトの名無しさん：2010/11/21(日) 01:41:40

ttp://gihyo.jp/news/report/01/ploneconf2010/0001?page=3
> 弱点を認める
> PythonはPHPよりマイナーな言語であることや，Ploneで開発を行うためのラーニングカーブ（学習曲線）が急であるとことが指摘されました。開発側もこれらの課題を認識しているようです。

はい、PythonはPHPよりマイナー発言、きました。
きっとPython信者がディスってくれると思います。

972 ：デフォルトの名無しさん：2010/11/21(日) 02:05:20

>>971
Web開発って意味では真実なんじゃない？＞マイナー言語

973 ：デフォルトの名無しさん：2010/11/21(日) 03:40:27

http://www.slideshare.net/esteele/eric-steele-world-plone-day-2010-plone-4-overview

974 ：デフォルトの名無しさん：2010/11/21(日) 06:52:56

メジャーであることでしかプライドを保てないPHPerを慮っているんだよw

975 ：デフォルトの名無しさん：2010/11/21(日) 11:40:06

>>974
PHPよりマイナーであることがPython信者のプライドを傷つけてるんですねわかります

976 ：デフォルトの名無しさん：2010/11/21(日) 12:01:48

（Web開発において）PythonはPHPよりマイナーというだけの話だね

というかむしろこれはPloneの連中は自分たちがイマイチ盛り上がらないのを
PythonのせいにしてやがるとかいってPython本スレでやればいいネタ

977 ：デフォルトの名無しさん：2010/11/21(日) 16:24:34

しかし、スクリプト言語の使い道って、ほとんどがウェブ開発だろ。

978 ：デフォルトの名無しさん：2010/11/21(日) 16:35:47

そうなん？

979 ：デフォルトの名無しさん：2010/11/21(日) 16:37:42

シェルスクリプトを書いてた人以外は。

980 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/21(日) 16:58:41

PHPってダウンロードしたりファイル加工したりテキスト処理したりできんの？
LWPみたいなもんで何かどっかのページだからテキスト取得して編集したり

画像などバイナリあつかえんの？

使ったことないから教えて

981 ：デフォルトの名無しさん：2010/11/21(日) 17:07:25

>>980
出来る

982 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/21(日) 17:10:30

できるっていってガチガチでめんどくせえことやんだろゲハ

983 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/21(日) 17:12:04

PHPerは勧誘しようと必死なんだよ

984 ：デフォルトの名無しさん：2010/11/21(日) 17:25:46

いやぶっちゃけPerlよりはかなり簡単
ファイルというかHTTPレスポンスの取得は、（設定で可能にすれば）fopen一発だし
きちんとやりたいならcurl関数も組み込みっぽく使える（コンパイルもしくは拡張の設定次第）
画像処理なら組み込みのGDでもいいし、ImageMagickのPECLもあるし

というか、別にPHPだからってバイナリの扱いが特別とかそう言うことはない
お優しいことに、マニュアルに「バイナリセーフ」ってわざわざ書いてくれてる関数がたくさんある

Perlでごにょごにょやるよりは、よっぽどやりやすいのは間違いない、と思う

985 ：デフォルトの名無しさん：2010/11/21(日) 17:27:43

前から思ってたんだけど「Perl忍者」ってことは、Perlが表社会では
受け入れられない日陰者ってことを表してるんですよね？

986 ：デフォルトの名無しさん：2010/11/21(日) 17:57:38

Perlでこんな事やってるサイトを紹介してください
http://hirata-create.lar.jp/

987 ：デフォルトの名無しさん：2010/11/21(日) 17:58:58

>>977
まー、環境依存だけど。
$ file /bin/* /usr/bin/* | grep script | wc -l
555

ちなみに。
$ file /bin/* /usr/bin/* | grep perl | wc -l
121
$ file /bin/* /usr/bin/* | grep ruby | wc -l
0
$ file /bin/* /usr/bin/* | grep php | wc -l
0
$ file /bin/* /usr/bin/* | grep python | wc -l
81

988 ：デフォルトの名無しさん：2010/11/21(日) 18:04:11

さてはきさま
るびぃをいんすこすらしてないな

989 ：デフォルトの名無しさん：2010/11/21(日) 18:05:41

かんきょういぞんですねわかります

990 ：デフォルトの名無しさん：2010/11/21(日) 18:14:14

CGIに一番適した言語は？
同じ組織でスクリプト言語は統一するべき？適材適所でいい？

991 ：デフォルトの名無しさん：2010/11/21(日) 18:27:25

今日日CGIで適した、とかナンセンス
その括りで敢えていうならもうCでいいんじゃね？

992 ：デフォルトの名無しさん：2010/11/21(日) 19:29:58

>>986
こっ、これはオーパーツじゃ！

993 ：デフォルトの名無しさん：2010/11/21(日) 19:41:33

Q.RubyでCGIが作りたいのですが
A.PHPがお勧めですよ。