09/06/05 10:48:30
最強のＬＬ＝軽量プログラム言語は、どれよ？
エントリーは、
Perl、PHP、Python、Ruby、JavaScript・・・
さあ、死ぬまで語りやがれ！！！
■LLとは？
軽量プログラミング言語（Lightweight Language,LL）とは、取り回しに優れ、
コードの作成や修正が容易と見なされるプログラミング言語のことを指す。
ここでいう「軽さ」はプログラマの負担の軽重を指し、
実行速度に優れているという意味ではない。
現在の水準では
・インタプリタ
・動的型
・正規表現
・関数オブジェクト
などを利用できるものがLLと呼ばれることが多い。（Wikipediaより）
■過去スレ
【Perl,PHP】LLバトルロワイヤル5【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】LLバトルロワイヤル4【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】LLバトルロワイヤル２【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/06/05 10:53:08
乙＞１
とりあえず 見ちゃったんで
3:デフォルトの名無しさん
09/06/05 15:15:39
レンタルサーバーを借りたので、
これから、Webアプリを作ってみようと思っているのですが、
今なら、Perl、PHP、Ruby、Pythonのどの言語が良いでしょうか？
上記4つの言語しか使えないサーバーです。
チャットルームにも掲示板にもなるようなのを
作りたいと思っています。
4:デフォルトの名無しさん
09/06/05 17:54:52
>>3
スレ違い
さらには板違いの可能性もある
5:デフォルトの名無しさん
09/06/05 18:13:55
>>3
Perl
理由は答えられない。
6:デフォルトの名無しさん
09/06/05 18:37:13
LLTV Coming Soon!!
7:デフォルトの名無しさん
09/06/05 20:18:45
共用なら開発は自重した方がいいよ。
そういうのが主目的じゃないんだからレンタルサーバー借りたからWebアプリを
作ろうっていう発想になるのはどうかと思う。
8:3
09/06/05 22:42:40
>>4
個別具体的な事例についての優劣は、議論しないという事ですか……。
申し訳ありません。
>>5
4つの言語の中で一番経験がある筈なのが Perl なんですが……。
(ただし、Web アプリではありません)
>>6
もうすぐ LL のイベントですか。
そういえば、毎年夏にあるんでしたっけ。
今年のは、テレビ番組を意識した気軽に楽しめるようなイベントを構想してるとか……。
まだ、一度も行った事がないので、行ってみたいですね。
>>7
当初 Web アプリを自作するつもりがなかったため、
何も考えず共用のを借りました。
総合的に考え直そうと思います。
さっき WebProg という板を見つけたので、
プログラムについてはそちらで相談しようと思います。
サーバーいついては、レンタルサーバーの板のほうで、
相談しようと思います。
板違いで申し訳ありません。
9:デフォルトの名無しさん
09/06/05 23:42:38
LLTV! LLTV!
10:デフォルトの名無しさん
09/06/05 23:56:26
今年の公式サイトが作られていますね。
Lightweight Language カンファレンス 2009
URLﾘﾝｸ(ll.jus.or.jp)
11:デフォルトの名無しさん
09/06/07 12:40:51
>>7
別にいいじゃん。Webアプリなんて、日曜大工とか夏休みの工作みたいなもんなんだし。
12:デフォルトの名無しさん
09/06/07 13:01:36
誰かまとめてくれ
Perl-------
PHP.------
Python----
Ruby------
JavaScript-
VB--------
13:デフォルトの名無しさん
09/06/07 13:23:20
Perl------- Larry Wall
PHP.------ The PHP Group (, Zend Technologies ?)
Python---- Python Software Foundation
Ruby------ Yukihiro Matsumoto
JavaScript- ???
VB-------- ???
とりあえず。
VBはまあMSだろうけど、JavaScriptは、それぞれの実装について
いろいろあるんだろうか。
14:デフォルトの名無しさん
09/06/07 15:32:09
Rubyが一番。 時点はPHP
15:デフォルトの名無しさん
09/06/07 15:37:44
確かにRubyは一番遅い
16:デフォルトの名無しさん
09/06/07 16:28:18
>>15
Perl------- 5
PHP.------ 2
Python---- 4
Ruby------ 1
JavaScript- 未知数
VB-------- 3
こうでつか？そんな気もする。
17:デフォルトの名無しさん
09/06/07 17:39:08
PHPは確変したからPythonよか軽いと思う
18:デフォルトの名無しさん
09/06/07 22:08:34
ここでは、mod_perl とか mod_php の類はどういう扱いになるんですかね。
19:デフォルトの名無しさん
09/06/07 22:26:46
>>16
キモイ奴が多い数でおけ？
20:デフォルトの名無しさん
09/06/07 22:30:57
LLって和製英語なの？
21:デフォルトの名無しさん
09/06/08 05:56:56
URLﾘﾝｸ(ja.wikipedia.org)
日本以外では言わない。海外ではリソース消費が軽量という意味でC言語などを指すのでむしろ逆。
日本でもごく一部でしか言わないし、「スクリプト言語」がポピュラーな呼称。
22:デフォルトの名無しさん
09/06/08 06:02:25
Lightweight Languages（複数形）という語は英語圏にも無くはないが
動作の軽い言語のことみたいで「プログラマの負担が軽い」という意味で使われるのは基本的に日本だけ
…もっとも俺もWikipediaかじった程度の知識だから実態は知らんが
23:デフォルトの名無しさん
09/06/08 07:29:24
「過去ログ嫁」
24:デフォルトの名無しさん
09/06/08 07:31:23
>>20-22
またこのネタかｗ 何回目だ？
>>20
「サラリーマン」や「ガソリンスタンド」的な意味での和製英語ではない。
なにしろ言い出しっぺはアメリカ人らしいし。（ソースは2chとWikipedia）
ただ、新語ではあるので用語として定着しておらず、また>>1の意味で利用
されている範囲もそれほど広くないんじゃないかな～という程度のもの。
25:デフォルトの名無しさん
09/06/08 07:32:00
LL和製ネタ、デジャブ・・・
26:デフォルトの名無しさん
09/06/08 08:07:33
まぁ、些末な事柄が繰り返し話題になるとか、
常識のはずのことが繰り返し尋ねられるとかは困るけど、
この場合、スレ的に根幹を成す物事で、その割には常識までは行ってない物事だから、
ある程度繰り返されるのも仕方ないかな、とは思う。
27:デフォルトの名無しさん
09/06/08 09:08:27
この流れは テンプレ化 しとこうぜ
Q. LLって和製英語なの？
A. >>28
28:デフォルトの名無しさん
09/06/08 09:39:26
和製英語ではありません
29:デフォルトの名無しさん
09/06/08 10:54:42
こうして歴史捏造が始まった。
30:デフォルトの名無しさん
09/06/08 13:13:50
じゃ、事実って奴を示せばいいわけだな？
ll-duscuss
URLﾘﾝｸ(lists.csail.mit.edu)
それとも、このアーカイブが全部捏造なのかなw
31:デフォルトの名無しさん
09/06/08 13:49:19
>>30
それMITの日本人学生が作ってるのモロバレじゃん。
32:デフォルトの名無しさん
09/06/08 21:27:43
>>31
Gregory T. Sullivan
URLﾘﾝｸ(people.csail.mit.edu)
いかつい日本人学生もいたもんだな
33:デフォルトの名無しさん
09/06/08 22:21:00
>>31
>それMITの日本人学生が作ってるのモロバレじゃん。
ねつ造してんのはおまえじゃんかwwwww
34:デフォルトの名無しさん
09/06/09 12:11:00
めんどくさいよな。スクリプト言語でいいじゃん
35:デフォルトの名無しさん
09/06/09 13:17:51
流行語にしてお金稼ぎたいんです！＞＜
36:デフォルトの名無しさん
09/06/09 14:52:17
>>32
実はひいばあさんの一人が...
37:デフォルトの名無しさん
09/06/10 01:19:16
スクリプト＝開発補助のイメージを払拭したい人達ががんばってるけど叶わずみたいな状況
38:デフォルトの名無しさん
09/06/13 04:03:39
LLはスイーツみたいなもんか
39:デフォルトの名無しさん
09/06/13 11:20:38
趣味でもJavaやC++しか使わないような奴等ばっかなの？
STLやコンテナやら面倒なだけじゃん
40:デフォルトの名無しさん
09/06/13 17:43:31
別に面倒じゃないけどな
IDEで作って右クリックで実行するだけだから結局同じだし
インタプリタインストールしないとならないLLの方が面倒じゃない？
41:デフォルトの名無しさん
09/06/13 19:04:59
>>39-40関連じゃないが、
最近、Ruby仕事してるんだが、
昔、DelphiでIDEでサクサク補完しながら作ってたころより生産性があがったように見えん。
どっかのひがやすをblogじゃないが、
> 「コードが多くても、実際の作業としては ctrl+spaceとctrl+1 を押すのが大半だから、生産効率に差はないんですよ。」
とか言われて、Ruby長年使っててRuby脳になってるはずなのに微妙に納得しかかってる。
もっとサクサク補完しながらかけるLLってねーの？
Ruby好きなんだけど、くだらんスペルミスとかで平気でとまる。ガバレッジテスト秋田・・・
42:41
09/06/13 19:07:47
LLだけじゃなくて、開発環境とかでもいいっす。
今時、言語の優越に開発環境引いて考える時代でもなかろう。
俺は、前はxyzzyでRuby書いてたけど、最近はNetBeans。でもどっちも補完はダメダメだね…
aptanaは重すぎワロタ
RubyとIDEでの補完の相性の悪さは、しゃーないことはわかっているんだけどさ
43:デフォルトの名無しさん
09/06/13 19:44:13
JavaからRubyへって本が酷かったな
どんだけJavaの生産性が酷いかしか説明してない本ｗ
44:デフォルトの名無しさん
09/06/13 22:39:35
ctrl+space とかで補完って、
LLでも普通にctrl+spaceで補完だが…
今更テキストエディタって、20～30行までの捨てスクリプトでもないかぎり
そんなことしない。
LLでもIDEがないと結局プロジェクトとしてのソース管理が困難になるのだし。
45:デフォルトの名無しさん
09/06/13 22:42:05
Rubyはダメでしょ。
統合環境使うなら、統合環境での利用に最適なシンタックス
を搭載しているpythonがベストと思うが。
46:デフォルトの名無しさん
09/06/13 23:16:52
開発環境まで言い出せば、VSでC#。これで決まり。
47:デフォルトの名無しさん
09/06/13 23:29:54
まあ、WindowsでRuby初心者ってのが最近多いみたいだが
そういう人は素直にC#勉強すればいいと思わないでもない
48:デフォルトの名無しさん
09/06/13 23:51:58
なんでもやりたいんだったら
LLから入るより普通にJavaでもやった方がいいと思う
49:デフォルトの名無しさん
09/06/13 23:54:03
素直にとか普通にとか
50:デフォルトの名無しさん
09/06/14 00:01:27
C#はクライアントのアプリはまだしも
Linux系サーバーになるとどうにもならなくなる。
また、CG開発系スクリプトでも全く威力を発揮しない。
C#はとても良い言語ではあるものの、
あくまでもC++のハイなレベル版に過ぎない。
Javaも意外なほど応用範囲がせまいな。
VMというもの自体が制約になるためだが。
51:デフォルトの名無しさん
09/06/14 01:39:21
そこで、parrotなのですよ。奥さん
いや、よー知らんけれど
52:デフォルトの名無しさん
09/06/14 02:11:05
>>50
だから何？
向き不向きならどんなものにもある。
53:デフォルトの名無しさん
09/06/14 06:40:07
>>52
だから、「何でもやりたい」ならjavaは別段向いてないのではということ。
(というか非常に向いていない）
個人がやるなら、クライアントアプリか、WEBアプリ、
あるいは、Excelやファイル処理などの簡易なマッチング処理・置換の類、
が最もありがちなのではないかと思われるが、
それら全てにjavaは凄まじく向いていない。
個人が1人でやる場合にjavaが向いているのは、iアプリぐらいかw
54:デフォルトの名無しさん
09/06/14 08:39:49
WebにJavaが向いてないとかすげー理論だな
55:デフォルトの名無しさん
09/06/14 09:08:47
サーブレットとクライアントとあると思うが。
サーブレットの場合はJavaの利点がよく見えないし、クライアントは
Flashに押され気味だし。
56:デフォルトの名無しさん
09/06/14 09:13:30
は…はぁ…
そうですね…
次の方どうぞ
57:デフォルトの名無しさん
09/06/14 10:09:12
＞サーブレットの場合はJavaの利点がよく見えないし
だったらPerlやPHPだと利点ありまくりなのか？
なんでもやりたいとか言うならPythonやC++くらいでたいていの事はできると思う。
とは言え職業プログラマならJavaやC++くらいできんと話にならん気がするが。
58:デフォルトの名無しさん
09/06/14 10:34:10
>>53
せっかくなので、あなたがオススメする
・クライアントアプリ
・WEBアプリ
・Excelやファイル処理
それぞれのオススメ言語おしえてくださいな
59:デフォルトの名無しさん
09/06/14 11:02:27
>>58
PHP
クライアント: ×、 Web: ○、Excelやファイル処理: ×
Perl
クライアント: ×、 Web: ○、 Excelやファイル処理: ○
Ruby, Python
クライアント: ○、 Web: ○、 Excelやファイル処理: ○
PerlやPHPでGUIのクライアントアプリ作る人ってあんまりいないね。
Ruby、Python は汎用言語だから全部こなせるけど、GUIのbinding が
より整備されているのは Python だったりする。
他にも OpenOffice.org ではマクロがPythonで書けたりする。
60:デフォルトの名無しさん
09/06/14 12:12:51
何でRubyとPython一緒にするかな
Pythonはガチだけど、RubyはGUIクライアントだと×か△ぐらいじゃねえか？
61:デフォルトの名無しさん
09/06/14 12:17:12
いやだから、GUIクライアントを簡単に作りたかったらC#でもJavaでも使えって。
中身のコードに関しても、JavaはともかくC#ならかなりコーディングの負荷は軽いぞ。
Windows限定では困るGUIクライアントを本当に作りたいの？
GUIってだけでスレチな気がすごくする。
62:デフォルトの名無しさん
09/06/14 12:42:56
GUIが必要になる状況って考えてみると、作ったツールを
プログラムやPCに疎い人間に使わせるときくらいだよなぁ。
自分で使うツールで必要になることって滅多にない。
63:デフォルトの名無しさん
09/06/14 12:45:09
PHPだとWinBinderとかあるけどな
適当なIDEが無いんでデバッグがしずらくて1週間で投げたけど
64:デフォルトの名無しさん
09/06/14 14:02:28
DropBoxのクライアントやBitTorrentのクライアントはPythonでできた
GUIプログラムだよ。
GUIプログラムって、よほどそのツールキットに精通していない限り
APIリファレンス見て、「こう設定したら期待する動作になるのかな?」
って試しながらプログラム書くことが多くて、その時は IPython という
強力なインタラクティブシェルを使って試しながらプログラムが書ける
Pythonは強い。
65:デフォルトの名無しさん
09/06/14 14:07:21
>>64
TortoiseHgもどうやらPythonですな。
UNICODEまわりがまだメタクソだけど、かなりよい感じ
66:デフォルトの名無しさん
09/06/14 14:14:43
>>65
Unicodeまわりがメタクソなのはhgの仕様だからなぁ。
ファイル名はバイト列ってフザケてるのかと。
bzrはコマンドライン引数でファイル名を渡す部分でWindowsでは
ファイル名をUnicodeにできなかったけど、次のbzr1.16では
コマンドライン引数をGetCommandLineW()を使って処理するように
なるからそれに対応するtortoisebzrもそれを使う方向に進んでる。
67:デフォルトの名無しさん
09/06/14 14:23:47
素人が前スレとここまで読んで判定すると、Pythonの圧勝です
68:デフォルトの名無しさん
09/06/14 18:19:11
ちょっと見たけど｛｝がない分いいかも、と思ったが
行末に：付いたり付かなかったり意味不
69:デフォルトの名無しさん
09/06/14 19:20:30
>>68
行末に : が付くのは、新しいブロックが始まる前(=インデントが増える
直前)で統一されていると思うけど?
70:デフォルトの名無しさん
09/06/14 23:24:24
なんで文法がVBで、出来ることがC++っつう理想言語が出来ないんだろうね？
if i=0 then j=0 else j=1;
これくらい共通にしろっての
インデントも｛｝も==も:も、なんで無駄なものを付けたがるんだ？
71:デフォルトの名無しさん
09/06/14 23:27:43
Webは技術よりもコンテンツだからな。んだからWebスクリプトプログラマーなんてアニメーター
同様カス扱い。
72:デフォルトの名無しさん
09/06/14 23:28:41
英語とドイツ語でこれはペンですくらい共通にしろって言ってるようなもんだぞ
73:デフォルトの名無しさん
09/06/14 23:56:09
>>70
文法がVBはやだなあ
Sub Hoge
End Sub
For i=0 to 10
Next
If a = 0 Then
b = 1
Else
a = 0
End If
どの辺がどう無駄のない文法なのかkwsk
74:デフォルトの名無しさん
09/06/15 00:47:01
BASICから覚えてきたはずなんだが、今見ると区切りが無くて見づらいな
75:デフォルトの名無しさん
09/06/15 02:36:59
C#でいいんじゃない。
76:デフォルトの名無しさん
09/06/15 03:45:31
一口にBASICっつーても色々方言があるけどな
77:デフォルトの名無しさん
09/06/15 03:57:05
10 CONSOLE,,,1
20 CLS 3
30 X=INT(RND(1)*7+1)
40 Y=INT(RND(1)*7+1)
50 Z=INT(RND(1)*7+1)
60 LOCATE 10,10:COLOR X:PRINT X
70 LOCATE 15,10:COLOR Y:PRINT Y
80 LOCATE 20,10:COLOR Z:PRINT Z
90 IF INKEY$=" " THEN GOTO 100 ELSE 30
100 IF X=Y AND Y=Z THEN PRINT "OOATARI!!":END
110 IF X=Y OR Y=Z OR Z=X THEN PRINT "ATARI!":END
…いや、ネットに転がってたからｗ 懐かしい。
そのうち、25 とか 105 とか の行番号で処理を差し込んだりするんだよなこれ。
78:デフォルトの名無しさん
09/06/15 04:15:16
N88あたりか、それ？
懐かしさと同時に、読みにくさも思い出すなｗ
今のBASICの規格だとIF～END IFやDO～LOOPはサポートすることになってるし
WHILE～WENDはその後のほとんどのBASICがサポートするようになったし、VBもEnd Ifを持ってるのもあって
今のBASICならGOTOで書いたりはしないだろうけど
79:デフォルトの名無しさん
09/06/15 06:34:21
>>69
Pascal(Delphi)の then とか do だと思えば納得ですな。
しかし、Rubyとか慣れてると、なんでいらないところにいるのん？と思わんこともある
80:デフォルトの名無しさん
09/06/15 06:36:09
>>73
Rubyっぽくしたら落ち着くのでは？
sub hoge
end
i.times(10)
next
if a == 0
b = 1
else
a = 0
end
81:デフォルトの名無しさん
09/06/15 06:38:33
ぼくがJavaのひとに「ガツン」と申し上げられて思ったこと - 梅雨ですな - ずっと君のターン
URLﾘﾝｸ(d.hatena.ne.jp)
Google App EngineのGreetingモデル定義 の Pythonコード
from google.appengine.ext import db
class Greeting(db.Model):
author = db.UserProperty()
content = db.StringProperty(multiline=True)
date = db.DateTimeProperty(auto_now_add=True)
一方Javaは…
package guestbook;
import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Greeting {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
82:デフォルトの名無しさん
09/06/15 06:39:22
@Persistent
private User author;
@Persistent
private String content;
@Persistent
private Date date;
public Greeting(User author, String content, Date date) {
this.author = author;
this.content = content;
this.date = date;
}
public Long getId() {
return id;
}
public User getAuthor() {
return author;
}
83:デフォルトの名無しさん
09/06/15 06:40:06
public String getContent() {
return content;
}
public Date getDate() {
return date;
}
public void setAuthor(User author) {
this.author = author;
}
public void setContent(String content) {
this.content = content;
}
public void setDate(Date date) {
this.date = date;
}
}
Python圧倒的すぎワロタ
※インデント崩れたスマソ・・・
84:デフォルトの名無しさん
09/06/15 06:53:15
言語思想が違うから一概にどーこーと言うのはないが、
Pythonは実用主義な言語だからそういうモノだと思うしかないな。
Javaのコードも実際は補完がバリバリ効くから、コードを打つのは苦痛では
ないだろうけど、コードの可読性でPythonに勝てる言語はそうそうないワケで。
85:デフォルトの名無しさん
09/06/15 07:25:28
>79
あのコロンのお陰で、エディタの補助にありつけたりするから要らないとは言えないなぁ
86:デフォルトの名無しさん
09/06/15 21:35:49
LLの場合、メソッドの引数の型がわからないから
未知のライブラリはコメント頼りになる。
静的型付けだと、引数の型からなんとなく仕様が想像できる場合がある。
87:デフォルトの名無しさん
09/06/16 00:17:40
補完が強力なエディタはどれ？やっぱEclipse？
88:デフォルトの名無しさん
09/06/16 00:18:20
あぁごめ、>>87はPythonでの話
89:デフォルトの名無しさん
09/06/16 01:04:11
>86
たまに変数名で分かるライブラリもあるけどな
90:デフォルトの名無しさん
09/06/17 02:02:49
>>84
Javaのコード補完の効き方と、
Pythonのコードの補完の効き方はかなり近いっしょ。
自分で定義したクラスやメソッドなどのコメントまで
補完時に見れるという点まで含めて。
91:デフォルトの名無しさん
09/06/20 09:58:10
Python は、ブロックが分かりにくいな。
インデントでやっているが、
ブロックの尻を明示する句や記号が無いから、
尻切れトンボみたいで気持ち悪い。
92:デフォルトの名無しさん
09/06/20 11:20:28
さんざん既出だが、スクリプトの始めの方に
end=1
と書いておいて、あとはブロックの終わりとか
目印代わりに「end」と書けばいい。
93:デフォルトの名無しさん
09/06/20 15:37:40
俺も気持ち悪いと思ってたが
しばらくLispやってたら帰って来たら慣れてた
94:デフォルトの名無しさん
09/06/20 15:50:42
# ここからブロック１
# ここまでブロック１
これで解決
95:デフォルトの名無しさん
09/06/20 16:08:44
>>92, 94
文法じゃないから、抜けててもチェックできないし、
書く人毎に違ってたら嫌じゃん。
96:デフォルトの名無しさん
09/06/20 16:43:04
>書く人毎に違ってたら嫌じゃん。
コード規約完全否定か
97:デフォルトの名無しさん
09/06/20 19:27:46
>>96
組織とかグループごとに独自のコード規約があって、
ブロックの書き方がそれぞれ毎に違ってたら意味無いじゃん。
98:デフォルトの名無しさん
09/06/20 20:15:10
Pythonの規約って標準化されたものないのか？
Javaは殆ど規約一本化されてるし
PHPもフレームワーク毎に規約あるぞ
仮になくてもせめて社内で統一くらいしろよ
99:デフォルトの名無しさん
09/06/20 20:16:38
PEP 8
100:デフォルトの名無しさん
09/06/20 21:02:32
Pythonはインデントを強制するのが規約
101:デフォルトの名無しさん
09/06/20 21:12:53
インデント強制は規約と言うより言語仕様。
公式規約はPEP8がある。
乱立はしていない。
Javaとかになれてる人には色々最初は気持ち悪いかもしれないけど、
使っているうちにそれがすごく合理的だと理解して慣れていくよ。
102:デフォルトの名無しさん
09/06/20 21:50:49
他人のコードを読むのが一番ラクな言語はPythonだと思うが。
103:デフォルトの名無しさん
09/06/20 21:58:52
Pythonはエスペラント語のようなもんで
いくら読みやすくてもみんな知らないから読めない
104:デフォルトの名無しさん
09/06/20 22:12:42
これほど共感できない例えも珍しい
105:デフォルトの名無しさん
09/06/20 22:17:10
Pythonは実行できる擬似コードと言われるくらいで、
Pythonを知らない人にも読みやすいコードが多いよ。
106:デフォルトの名無しさん
09/06/20 23:03:38
Pythonが読みやすいってのは
RubyがJavaより生産効率いいってくらい基準があいまいな話だと思う
107:デフォルトの名無しさん
09/06/20 23:42:35
とりあえず漏れの場合はRubyやJavaと比較するならば、Pythonの方が読みやすい。
つか個人的にRubyはJavaを意識する前にPythonよりも生産性を上げてから言うべきだろうに。
108:デフォルトの名無しさん
09/06/20 23:55:40
Pythonはまだ仕様が固まってないから、6.0くらいまでは様子見すべき。
109:デフォルトの名無しさん
09/06/21 00:16:03
PerlやRubyは、同じ処理をするのにいろんな書き方があるけど、
Pythonはそれを極力避けているから、多少冗長になっても
誰が見てもわかりやすいコードになるのがウリじゃなかったっけ？
110:デフォルトの名無しさん
09/06/21 05:38:48
紛らわしければpassを使えばよいのに(python-mode派)。
111:デフォルトの名無しさん
09/06/21 06:52:21
pythonって、どうやってコピペすんの？インデント崩れるんだけど
112:デフォルトの名無しさん
09/06/21 06:53:36
>>111
replace(" ", " ")
113:112
09/06/21 06:54:19
あわわ
replace(" ", " ")
114:デフォルトの名無しさん
09/06/21 07:05:01
＞Pythonはまだ仕様が固まってないから、6.0くらいまでは様子見すべき
それを言い出したらRubyなんて100.0くらいまで使えない希ガス。
115:デフォルトの名無しさん
09/06/21 13:49:43
>>99 >>101
PEP 8 ってこれで全部？
URLﾘﾝｸ(oldriver.org)
ざっと見たところ、ブロックの終わりを示す語句(記号)についての記述がないようだけど……
116:デフォルトの名無しさん
09/06/21 13:55:07
>>115
つまり、 end = 1 とかは使わないで普通にインデント解除するのが
標準コーディング規約
117:デフォルトの名無しさん
09/06/21 14:02:18
>>41
コード書くときの自動補完は、言語が静的型付かどうかに大きく使い勝手が
左右される。RubyやPythonみたいな動的言語だと、変数名が任意の
オブジェクトへのラベルに過ぎないので、適切なメンバを
候補として提示することが本質的に不可能。
WindowsでもLinuxでも、クライアントもサーバもってことなら、
Mono 2.4 + MonoDevelop 2の出来がびっくりするくらいいいので、
(多言語・多プラットフォーム・REPL等。 ただし、GTK#で日本語は地雷)
1回さわってみるのをおすすめ。
商用サーバでもLinux + Mono + ASP.NETって増えてきてるしね。
118:デフォルトの名無しさん
09/06/21 14:10:15
インデントを戻すタイミングについて、エディタに知らせる方法が問題なのかな？
pass でいいんじゃなかった？
119:デフォルトの名無しさん
09/06/21 14:19:13
>>106
読みやすさに明確な基準は持たせにくいからね。
でも、複数の言語を知っている人はやっぱりPythonは読みやすいと感じるよ。
dankogai も、
--
私ははっきり言って Python の哲学は好きになれない。でも Python のコードは好き。
「動く pseudocode 」としてのチャンピオンは、今や Python だ。Python はもっと知られ、
もっと使われて良い。 Pythonistas のみならず、 Perl Mongers のためにも、 Rubyists
のためにも。
--
とか言ってる。
120:デフォルトの名無しさん
09/06/21 14:59:04
pythonのコードが読みやすいことは認めるが
dankogaiを引き合いに出すのはやめてくれ
まるで「東スポにそう書いてあった」といわんばかりだ
121:デフォルトの名無しさん
09/06/21 17:13:48
この件は、誰を引き合いに出しても信頼性は変わらない
122:デフォルトの名無しさん
09/06/21 17:48:17
まぁそういうことだね。
「それ」にある程度重きを置く場合、Rubyは使えない。到底。
123:デフォルトの名無しさん
09/06/21 18:20:14
フランス人がフランス語は美しいって言ってるレベルの話だろこれ
フランス語がわかる奴じゃないと意味解らんから無駄って話
124:デフォルトの名無しさん
09/06/21 18:52:05
そういう話だということにすると救われるんですね。
125:デフォルトの名無しさん
09/06/21 19:16:31
この手の話は20年前からまったく進歩がない
126:デフォルトの名無しさん
09/06/21 19:23:10
インデントの規則が決まってるからPythonは見やすいってのなら
コード規約に従って書いた他の言語だって同じように見やすいんじゃないかと思うが
127:デフォルトの名無しさん
09/06/21 20:05:06
>>126
インデントだけじゃないよ。
予約語が少ない、特殊変数が無い、ビルトイン関数・変数が少ない、
式を複雑に組み合わせないで文に分けている、etcetc...
128:デフォルトの名無しさん
09/06/21 20:09:56
で、結局、 Python は、ブロックの終りを示す語句・記号が無くて、
気持ち悪いことに変わりないと。
文法にないどころか、標準のコーディング規約にすら無いから、
end = 1 とか、コメントとか、結局、独自の工夫をするしかなから、
統一的にはできないと。
標準に従うなら、むしろ、ブロックを閉じちゃいけないから、
ブロックを閉じないと気持ち悪く感じる人は、
選択肢に入れられないと。
129:デフォルトの名無しさん
09/06/21 20:13:59
↑
ヴァカ？
130:デフォルトの名無しさん
09/06/21 20:20:24
ブロックはちゃんとアンインデントで閉じるだろ、閉じる記号が文字としては無いってだけで
131:デフォルトの名無しさん
09/06/21 20:23:12
Python は,ブロックを閉じる記号がないから
気持ち悪いことには変わりない。
132:デフォルトの名無しさん
09/06/21 20:23:40
所詮慣れの問題なのにこんだけ熱く語れるってのはなんだかなあ
おれがPythonで気持ち悪いのは、インデントよりもむしろ文字列リテラルの方だったりする。
u'ユニコード文字列'
とか
"""コメント
コメント
コメント"""
ってなんだよ
133:デフォルトの名無しさん
09/06/21 20:24:31
だって、気持ち悪いんだもん。
しょうがないじゃん。
134:デフォルトの名無しさん
09/06/21 20:26:53
"""
文字列
"""
はRubyにもあったような…
まぁ、確かに範囲コメントはちょっと欲しいかも
135:デフォルトの名無しさん
09/06/21 20:27:21
ユニコード辺りはああいうモンと諦めている。
"""のｌ機能は便利だと思うけど。
ドキュメンテーション文字列もほどよいいい加減さがあって好きだが。
136:デフォルトの名無しさん
09/06/21 20:30:56
Pythonのu'文字列'は歴史がそうさせるので仕方ないだろう。
r'文字列'は随分とコードが読みやすくなるのでいいと思う。
137:デフォルトの名無しさん
09/06/21 20:31:09
気持ち悪い気持ち悪い言ってる人はこちらのスレで存分にどうぞ。
Pythonに見られるインデントによる制御構造の是非
ｽﾚﾘﾝｸ(tech板)l50
てか、数学の記法とか、普通の箇条書きとか、インデントを戻すことで
リストの終了を示してるけど、そういうものが全て気持ち悪いんだろうか？
138:デフォルトの名無しさん
09/06/21 20:47:34
箇条書きの場合は、ネストを深くする毎に頭の記号を変えるとか、
番号の後ろに番号を加えるとかするから、違うん感じがする？
数学のは、どういう事か分からないけど、
関数型言語(ML系、Haskell)とか、Prolog のは、気持ち悪いな。
LISP は、括弧だから（・∀・）イイ！
139:デフォルトの名無しさん
09/06/21 20:51:05
>>138 書き間違ったので修正します。
箇条書きの場合は、ネストを深くする毎に頭の記号を変えるとか、
番号の後ろに番号を加えるとかするから、違う感じがする。
数学のは、どういう事か分からないけど、
関数型言語(ML系、Haskell)とか、Prolog のは、気持ち悪いな。
LISP は、括弧だから（・∀・）イイ！
ブロックの閉じる記号がないから気持ち悪いという文脈で
LISP が出てくるのが、理解できなかった。
LISP は、全部きっちり括弧で括るから、 Python とは全然違うのに。
140:デフォルトの名無しさん
09/06/21 21:16:26
end があっても、 Pascal は気持ち悪くて、 Ruby はいいんで、
ブロックだけの問題じゃない気がしてきた。
141:デフォルトの名無しさん
09/06/21 21:35:42
歴史だから仕方ないっていいわけになってないけど
142:デフォルトの名無しさん
09/06/21 22:19:43
>139
しかし閉じ記号をブロックの中身に書いちゃうのは、それはそれで…
143:デフォルトの名無しさん
09/06/21 23:28:04
Cかschemeが最強だと信じている。LLは複雑怪奇すぎ
144:デフォルトの名無しさん
09/06/21 23:37:10
一時期Scheme勉強して、Pythonに戻ったら
map の前と後ろのどっちに ( つけるか毎回迷って困ったｗ
145:デフォルトの名無しさん
09/06/22 03:06:16
そういえばSchemeのmapとかCommon Lispのmapcarって、
何で関数引数が前なんだろう？
Rubyのブロック構文に慣れた身としては、
でかいlambdaを渡す時には非常に読みづらくなる気がするんだが・・・・・
146:デフォルトの名無しさん
09/06/22 03:42:58
>>145
map は引数として任意の数のリストを取れるので、
必須の引数である関数は必然的に一番最初になります。
あとまあ、その結果として apply と相性がいいとか部分適用しやすいとか。
でかい lamabda を直接書くと読みづらいのは確かだけど、
逆に読みづらくなるほどでかいなら適当にくくりだすかなあ。
さもなければ dolist 使うか。
147:デフォルトの名無しさん
09/06/22 04:50:16
あーなるほど感謝。やっぱりそれなりの理由と作法があるのか
148:デフォルトの名無しさん
09/06/22 07:51:45
Rubyのあの構文は、引数として渡す関数はたかだか1個、という前提に
最適化したものだからね。
149:デフォルトの名無しさん
09/06/22 20:44:07
まあ、Pythonしか使わない人（もしくはRubyしか使わない人）にはそれが見やすいのかも知れないけど、仕事上いろんな言語を使う必要がある場合、PythonやRubyは特殊で非常に見づらい。
150:デフォルトの名無しさん
09/06/22 20:54:32
色んなって…色んな、がどんな言語かによるだろうに
151:デフォルトの名無しさん
09/06/22 21:02:07
map(lambda x,y:x+y,[1,2,3],[4,5,6])
PyhtonのmapはRubyとは違ってLispのと同じような感じだが
152:デフォルトの名無しさん
09/06/22 21:09:07
C/C++ Java C# Perl PHP JavaScriptなどメジャーな言語。
153:デフォルトの名無しさん
09/06/22 21:36:37
要はC系言語のことを指してるワケね。
個人的にはC系の記法は数ある言語の中でも読みにくい部類に入ると思ってるんだが…
154:デフォルトの名無しさん
09/06/22 21:45:27
日本語は漢字があって読みにくい
英語は簡便でよみやすい
って言うようなもんだ
日本人に取っては難しい日本語の方が読みやすい
C系PGはC系言語が読みやすい
155:デフォルトの名無しさん
09/06/22 21:46:05
Basicだけは何をどうやっても読みにくい
156:デフォルトの名無しさん
09/06/22 21:46:09
Perl挙げてるあたり、自分の慣れてない言語が読めないってゴネてるだけだろ
157:デフォルトの名無しさん
09/06/22 22:04:23
読めないって話しじゃなくて
Pythonは特に読みやすい言語ではないって話な
158:デフォルトの名無しさん
09/06/22 22:10:34
メジャーな言語が読みやすくて、PythonとRubyはそれらと比較して非常に読みづらいとか
んなこと唐突に根拠もなく言われても
159:デフォルトの名無しさん
09/06/22 22:48:33
だから、Pythonだけ使ってる人にはいいんだろうけど、世の中やC+Java+Per+PHPを使ってる割合の方が遙かに多いわけ。
ハングルは世界一読みやすいって言われても、世界中の人はハングルなんて読めないの。
160:デフォルトの名無しさん
09/06/22 23:05:19
PythonやRubyしか使わないって人のほうが珍しいだろうし、
読みやすいってのはいろんな言語を使ってきた人たちが
比較して言ってるんでしょ？
161:デフォルトの名無しさん
09/06/22 23:12:57
メジャーな言語は読みやすい
メジャーでない言語は非常に読みづらい
なぜならユーザが少ないから
みたいな論理展開する人がプログラム書いてるのか・・・
162:デフォルトの名無しさん
09/06/22 23:16:50
読み辛いというか仕様やその言語特有の作法がよく分からない。探すのも面倒。
重箱の隅をつつくルールを覚える暇で、主要言語でやりたいことを模索する方が良さそう
163:デフォルトの名無しさん
09/06/22 23:17:46
ちょっと粘着気味でしんどいな
もうちょっと楽しい切り口でよろしく
164:デフォルトの名無しさん
09/06/23 00:49:24
既出すぎる話題ばかりだしな
165:デフォルトの名無しさん
09/06/23 01:09:11
Pythonは他のメジャーな言語に比べて、より少ないルールで高い生産性を
実現できている言語だけどな。
166:デフォルトの名無しさん
09/06/23 01:15:19
しかし根底にある概念が理解しにくい
手続き型って、かなりな部分の人間の思考過程に、
素直に馴染みやすい形態なのかもよ。その方向で
発展出来ないのかな
そう言う意味でもRubyはいいとこどりなんじゃね？
167:デフォルトの名無しさん
09/06/23 01:24:05
「可読性」なるものの定量的な比較基準が欲しい所だが、
果たして存在するのかすら分からん
記号含有率・・・・はある面で悪くないが、じゃあCOBOLは読みやすいのかって話になる
168:デフォルトの名無しさん
09/06/23 01:24:05
どのみち高級言語なんだしな
末尾再帰とかできて喜んでる人間ってなんなんだろう
それって、正直読みやすいのかな
169:デフォルトの名無しさん
09/06/23 01:29:24
>>166
Python は高級な手続き指向言語じゃん。
Ruby に比べたら圧倒的に記号や特殊ルールが少ない分、
Pythonを知らない人でも推測しながら読むことが可能。
170:デフォルトの名無しさん
09/06/23 01:38:42
Rubyがいいとこどりなんて言う人はもっといろんな言語を勉強するべき
全然いいとこどりでないぞ、むしろいろんな面で中途半端
171:デフォルトの名無しさん
09/06/23 01:49:04
そんな抽象的なレスじゃ何も言えんよ・・・・・・
なるほど中途半端だ
172:デフォルトの名無しさん
09/06/23 01:58:08
何も言えないなら「何も言えない」で終わっておかないとね。
後ろに捨て台詞付け足したら、それはもうしっかり言っちゃってることになる。
173:デフォルトの名無しさん
09/06/23 02:46:03
Pythonはエスペラント語
志は高いがシェアは低い
174:デフォルトの名無しさん
09/06/23 03:05:15
シェアが低いってww
日本で流行ってないだけだろ。
世界中では至る所で使われてるぞ。
175:デフォルトの名無しさん
09/06/23 04:07:40
と日記には書いておこう。
176:デフォルトの名無しさん
09/06/23 06:30:21
>>173
Ruby使っている人が自殺しそうな発言だな。
あれこそユーザー数は少ないしシェアはPythonと比べるのが可哀想なノリだが。
つかPython粘着ウゼェ。
アンチ専用スレあるんだからそっちで餌まいとけよ。
177:デフォルトの名無しさん
09/06/23 07:11:49
日本っつーか、日本のWindowsでは、ってところじゃないかな。
MacやLinuxの大手ディストリなんかではPythonが最初から入ってたりして
「あんまり知らなくても、いつの間にか身近なところで使われてる」言語になってるんだよね。
178:デフォルトの名無しさん
09/06/23 07:27:27
とりあえず日本のWindows環境でもRubyとPython比較するならば、
Pythonの方が恵まれた環境にあると感じるが。
Rubyのあのやる気の無さはなぁ。
とりあえずPythonがシェア低いなんて、モノを知らないにも限度がある発言だろうに。
179:デフォルトの名無しさん
09/06/23 09:50:30
>>177
使われてないなんて誰も言ってない
シェアが低いだけ
180:デフォルトの名無しさん
09/06/23 09:52:20
>>179
自分のまわりが世界なんですね、わかります。
181:デフォルトの名無しさん
09/06/23 11:29:45
シェアという単語の定義から始めないといけないのか
182:デフォルトの名無しさん
09/06/23 16:11:51
とりあえずpythonは3が普及したらがんばる。
183:デフォルトの名無しさん
09/06/23 23:02:43
自分のまわりが世界な人はLinux環境でならRubyはいい言語だと思うよ。
どうせ仕事じゃないんだろうし。
しかし、C/C++って読みやすいか？
つか、***pとか(p++)やらint (*p)()とか組み合わさったら、キツいノリがある言語だと感じるが。
パーな#defineされていると殺意を覚えるし。
Pythonの関数ポインタもかなりアレなノリがあるので微妙だが。
184:デフォルトの名無しさん
09/06/23 23:31:40
>>183
そんな程度で殺意わくようでは、
perlとかまともに読めない、書けない人かね？
185:デフォルトの名無しさん
09/06/23 23:50:02
perlは別に最初から読みやすい言語でもないだろ。
個人が使い捨て殴り書きするには最適な言語だから、そこにケチつけるのはおかしいし。
C/C++は運が悪いと延々とメンテされる可能性が高いからアレなんだろ。
186:デフォルトの名無しさん
09/06/24 00:03:25
誰もPerlが読みやすい言語だなんて言ってないだろうに
Pythonは特に読みやすい言語じゃないというのが肝であって
他の言語で特別読みやすい言語があるって話じゃない
187:デフォルトの名無しさん
09/06/24 00:10:34
＞Pythonは特に読みやすい言語じゃないというのが肝であって
さすがに、Pythonは特に読みやすい言語だし、コレが読みにくいと言うのは
プログラムをヤめた方がいい。
188:デフォルトの名無しさん
09/06/24 00:11:06
>>183
その辺をある程度改良しようとしたらDになるんだろう
型変換はcast式、プリプロセッサは排除
189:デフォルトの名無しさん
09/06/24 00:54:41
実際仕事でやってると言語なんて「これメンテして」で選択肢ないからなあ。
いっそそんな言語知らないとでもシラをきり通せた方がいいな。
190:デフォルトの名無しさん
09/06/24 02:18:40
C言語は、読みやすさを犠牲にして、書く量を減らした設計だろうから仕方ない気がする。
ただ、C言語が普及したせいで、C言語っぽい文法を採用する言語が多くなったから、
C言語っぽい文法の方が読みやすいと思われる事が多いかも知れない。
BASIC が読みにくいと言うのは、理解が出来ないな。
それで、 Python のソースは読めるのか？
Ruby は、「Perl の次」以上でも以下でもないと思う。
Ruby と Python では、明らかに Python の方がメジャーだな。
OS のインストーラのアナコンダ（だったっけ）が Python で書かれてるとか。
Python は、Google がよく使ってるんだっけ。
Perl は Yahoo がよく使ってるんだっけ。他にも、 はてな とか mixi とかいろんな所が Perl を使っていると聞く。
PHP は、ネット上の至る所で .php を見かける。
しかし、 Ruby を良く使っている所ってあまり聞かないな。
Twitter が使ってて話題になってたけど Scala に変えたんだっけ。
自分は、Python よりは Perl, PHP, Ruby が好きだな。
Python のは、読む気がしない。
Python のを読むくらいなら LISP の括弧を追っている方が、
いや、アセンブリ言語でレジスタの使われ方を追っている方が
よっぽどましだ。
191:デフォルトの名無しさん
09/06/24 02:26:50
>>190
馬鹿じゃねーの？
氏ねよ！！！！
長文ウザイ
192:デフォルトの名無しさん
09/06/24 02:44:08
2chで長文ウザイ言う人って、単に頭が悪い人なんだよね。
100個の1行レスは読むけど、1個の10行レスは嫌いな人種。要は根拠や例示を読めない人。
>>190なんて、>>191を書いて送信ボタン押してスレをリロードするより早く読めるのにね。
193:デフォルトの名無しさん
09/06/24 06:37:08
190,192はいつもの粘着だと思うが。
194:デフォルトの名無しさん
09/06/24 11:27:49
BASICっつーても方言によるが…
とりあえず規格は文法そのものは読みやすいが
命令によって微妙に書き方が違うのと
大きなコード書くと引数が多くなりがちなせいで慣れるほど限界を感じると思う
設計からしてプログラミング初心者向けだから仕方ないけど
195:デフォルトの名無しさん
09/06/24 14:01:28
>>187
いやだからね
いくら読みやすくても、その文法が特殊だとみんな馴染めないわけよ
だからC言語派生やBASIC派生の方が流行るわけでさ
英語は読みづらいから、もっと簡単な言語つくったので
みんな読めるはず、って言われても無理なのと同じ
196:デフォルトの名無しさん
09/06/24 14:50:14
後発のプログラミング言語はいろんなところから構文や機能をぱくってるから
自然言語で例えるのは微妙
日本語分かっててもハングル全く分からんけど
java分かってればpython5割ぐらいはだいたいこんな感じだろってわかるべ
ちがうパラダイムの言語じゃなければ
プログラミング言語でもっと簡単な言語を作った、みんな読めるはず
たぶん本当にみんな読めるんじゃないか？
197:デフォルトの名無しさん
09/06/24 14:59:51
今は読める読めないでなく読みやすい読みにくいの話じゃないのか？
198:デフォルトの名無しさん
09/06/24 15:12:33
みんなって誰だ。
コッチ・ミンナさん(AA略)か？
199:デフォルトの名無しさん
09/06/24 16:06:39
>>195
>いやだからね
>いくら読みやすくても、その文法が特殊だとみんな馴染めないわけよ
HaskellやML系の文法ならまだしも、Python の文法になじめないとしたら、
さすがにそれは文法が特殊だからではなくておまえの頭が悪いだけ。
いくらなんでも、Pythonの文法が理解できないというのはおかしい。
200:デフォルトの名無しさん
09/06/24 16:07:53
これがpy脳か…
201:デフォルトの名無しさん
09/06/24 16:24:33
>>187
書き手しだい。
Pythonに限らずインデントが深くて波打ってるようなコードとかあるだろ？
そういうのは例えPythonでも読み辛いもんだよ。
202:デフォルトの名無しさん
09/06/24 16:31:47
>>201
今はそういう話じゃない。
195が、いくら読みやすくてもPythonの文法は特殊だから読みにくいという主張に対しての反論。
書き手次第とかは今は関係ない。
203:デフォルトの名無しさん
09/06/24 16:44:56
特殊って言い方は変だと思うな。
プログラミング言語全体で「特殊」なんてのはあんまり無いと思う。
単に書き方の派閥があるだけで、その中に特殊なんてのは存在しないんじゃないかな。
つーかLLスレ的にはC風の書き方のほうがむしろ異端じゃなかろうか。
204:デフォルトの名無しさん
09/06/24 17:12:33
主観の問題なので、実際にリサーチしてみないと判断は無理。
自分を中心にして、相対的に語ったところで意味はないだろう。
205:デフォルトの名無しさん
09/06/24 17:14:29
C風の書式のLL：
・Perl
・PHP
・Ruby
・JavaScript
・(Python)
C風でない書式のLL：
・(Python)
206:デフォルトの名無しさん
09/06/24 17:41:32
>>202
読みにくいじゃなくて、他の言語に比べて特別読みやすいわけじゃない、だろ。
読みやすいか読みにくいかは、その言語に精通しているかどうかが大きな肝で、
Pythonが特別読みやすい言語仕様になっているから読みやすいわけじゃない。
インデントが綺麗かどうか程度の差でしかないから、
コーティング規約に従って書かれたJavaやPHPと、
可読性は殆ど変わらん。
207:デフォルトの名無しさん
09/06/24 17:43:36
RubyのどこがC風なんだ
class SuperClass
end
class MyClass < SuperClass
attr_reader :x
def initialize(x)
@x = x
end
end
def func1
MyClass.new 'Hello'
end
func1
puts func1
208:デフォルトの名無しさん
09/06/24 17:54:10
>>206
>読みにくいじゃなくて、他の言語に比べて特別読みやすいわけじゃない、だろ。
まず>>195を読もうぜ。
おまえの意見なんか問題にしてない。
209:デフォルトの名無しさん
09/06/24 18:44:25
>>207
キーワードがちょっと違うだけじゃん
210:デフォルトの名無しさん
09/06/24 18:45:45
じゃあpythonも十分C風ってことで
211:デフォルトの名無しさん
09/06/24 19:05:35
>>207
キーワードはAlgol風味だが、
メソッドとかの命名はC系の影響を受けてると思う
to_sとか、アンダーバー記法でギリギリ意味が取れる程度に短くする
212:デフォルトの名無しさん
09/06/24 19:42:56
pythonは制御構造を作るのに end も { } も; も必要ない。
余計なものが少なくてシンプルに見えるんだがなー。
213:デフォルトの名無しさん
09/06/24 19:56:39
だから見分けづらいんでしょ
214:デフォルトの名無しさん
09/06/24 19:59:28
慣れかもしれんがdelphi触ってたときは
begin endの嵐でうへぇって感じだった
俺的にはシンプルのがいいわ
見分けづらいとも感じない
215:デフォルトの名無しさん
09/06/24 20:58:01
俺はCやPerlの記号ごちゃごちゃ出す感じが嫌いなんだよなぁ
Rubyも書き方次第で記号ごちゃごちゃになるけど
216:デフォルトの名無しさん
09/06/24 21:27:27
PerlはOne-linerが流行るような、出来るだけ縮めてしまえっていう文化だよね。
Rubyもその流れを汲んでいる。
217:デフォルトの名無しさん
09/06/24 21:49:25
漏れの周りのPython知らなかった人もPythonの制御構造の仕組みは
解りやすいとコメントしていたな。
見分けづらい、と言う人は極少数だと思われ。
218:デフォルトの名無しさん
09/06/24 21:54:31
会社とかのコーディング規約で「ifやforのブロックはインデントして見やすく」とか
している組織だとPythonのコードは読みやすく感じるだろうな。
それにPythonだとswitchやcase文がないところからしても、「覚えやすく、見やすく、シンプルに」って
哲学みたいなのがあるんだろ。
219:デフォルトの名無しさん
09/06/24 22:11:11
pythonの制御構造に関していえば、別段、特殊でもないし、
括弧が、インデントが、begin-endがなんて、本質的な分かりにくさじゃないだろ
～です、～ゴザル、～ニャとか、そのぐらいどうでもいい違いだよ
メモリ上でオブジェクトがどうなっているかとか、どうやってソートするのかとか、
スコープや数値、配列、文字列の扱いやライブラリの利用なんかの方が遥かに謎
220:デフォルトの名無しさん
09/06/24 22:13:13
>>218
ifやforでインデントしない奴のソースなんか100人中98人までは読みたくねーよ
規約の遙か以前の問題で、またPythonのインデント強制とも次元が違いすぎる
switch～caseなんかもifの構文糖衣だし、なんか的はずれすぎてﾜﾛﾀ
221:デフォルトの名無しさん
09/06/24 22:35:46
＞switch～caseなんかもifの構文糖衣だし、なんか的はずれすぎてﾜﾛﾀ
ぶっちゃけ違う。
同じと思っているならソレは>>220のレベルが極限まで低い証拠。
そういう低レベルがPythonをどーこー言うのは的外れ。
222:デフォルトの名無しさん
09/06/24 22:44:36
>>221
どう違うのを書かないと、>>221のレベル（笑）もわからんな
例えば、ifで代替できないシンプルなswitch文をあげてみるとか、
コンパイラ方面での話をしてみるとか
223:デフォルトの名無しさん
09/06/24 22:52:18
ifでswitchの振り分け真似ると、orだらけになったりするコトも
後で指導するが、明らかにアレは見づらい
224:デフォルトの名無しさん
09/06/24 22:55:11
ifとswitchは似ている様で違うだろ。
Pythonはswitchなくてもほとんど困らないが、その理由が解らない>>220は
ちょっと頭が可哀想な人なんだと思う。
225:デフォルトの名無しさん
09/06/24 23:11:59
>>220が攻撃される理由が分からん。
pythonのは、OOだ！OOを使え！ルーク！って教えでしょ。
Perlは、ライブラリだ！ライブラリを使え！ルーク！って教えだし。
しかし、switchはifのシンタックスシュガーじゃないのか？
ifで代替できない場面が分からない。
見易さだけなら、ただのシンタックスシュガーだし。
226:デフォルトの名無しさん
09/06/24 23:20:20
Python教こえーな
異教徒排除が徹底しすぎ
敵がJavaだけのRuby信者より質悪いわ
227:デフォルトの名無しさん
09/06/24 23:28:07
ということにしたいのですね？
228:デフォルトの名無しさん
09/06/24 23:34:51
一応考えてみたが、switchには、if～else単独にはないラベルへのgotoも複合されている
C#みたいなものもある、とかいう点なのかな？
この場合は、switchってif～else+gotoの糖衣構文じゃん、とか言ってみたらどんな反応が
来るんだろう。やっぱり同じ反応な気もするが。
あとはコンパイラの最適化でなにかあるのかな～くらいしか思いつかないが、「違う」理由を、
純粋に勉強のためにせっかくだから誰か教えてくれないもんだろうか。気になる。
229:デフォルトの名無しさん
09/06/25 00:38:08
正露丸糖衣A
230:デフォルトの名無しさん
09/06/25 00:38:58
xがOまたはPまたはQのときは処理aと処理b
xがRまたはSのときは処理bのみ
それ以外のときは処理cを行なうってコードとか？
231:デフォルトの名無しさん
09/06/25 00:49:16
C言語だと switch と if が違うというのはわかるが、LL だとどうなんだろ？
C言語は、コンパイラやコードによっては、テーブルを引いてジャンプするコードに変換される場合があるらしいが。
232:デフォルトの名無しさん
09/06/25 00:54:14
>>230
switch( str )
{
233:デフォルトの名無しさん
09/06/25 00:59:53
Enter押してしまった・・・ orz
>>230
switch( str )
{
case 'O':
case 'P':
case 'Q':
function_a();
case 'R':
case 'S':
function_b();
break;
}
こういうのはifよりswitchのほうが楽だね
234:デフォルトの名無しさん
09/06/25 01:10:30
if s in 'OPQ': function_a()
elif s in 'RS': function_b()
235:デフォルトの名無しさん
09/06/25 01:12:21
あ、function_aの後は下へ流れるのか
236:デフォルトの名無しさん
09/06/25 01:22:22
Python には暗黙のルール、見た目から意味が推測できない記号が
少ないから、メタクラスとか駆使した一部分のコードをのぞき、Pythonに
それほど精通しなくても大体のコードは読める。
その反対は(非モダンな)Perlで、初心者どころか中級者になっても
他人のコードが読めなかったり、下手すると昔の自分の書いたコードが
読めないなんてことが起こる。
237:233
09/06/25 01:27:14
>それ以外のときは処理cを行なうってコードとか？
・・・ (´･ω･`)
switch( str )
{
case 'O':
case 'P':
case 'Q':
function_a();
case 'R':
case 'S':
function_b();
break;
default:
function_c();
break;
}
もうねまふ。。。
238:デフォルトの名無しさん
09/06/25 02:11:59
>>233
if str in "OPQ":
func_a()
if str in "OPQRS":
func_b()
239:デフォルトの名無しさん
09/06/25 02:18:15
>>237
if str in 'OPQ':
func_a()
if str in 'OPQRS':
func_b()
else:
func_c()
240:デフォルトの名無しさん
09/06/25 02:24:05
str の内容が 'RS' とかだったらどうするんだろ？
241:デフォルトの名無しさん
09/06/25 02:29:00
リスト使えばええがな
242:デフォルトの名無しさん
09/06/25 02:33:08
Pythonのinって何が起きてるんだ？
何となく分かるようで分からん。文字単位でのマッチング？
243:デフォルトの名無しさん
09/06/25 02:34:36
文字列は文字のリスト
244:デフォルトの名無しさん
09/06/25 03:13:57
URLﾘﾝｸ(www.python.jp)
245:デフォルトの名無しさん
09/06/25 03:19:45
俺的には K&Rが読みやすいから、GNUだなんだの見るよりは
インデントが統一されてるなら、読みやすくはあるんだろうなー
とは思う。 最終的には慣れだろうけど…
今は括弧がないとなんか読みにくい感じ。
do endもなんかなれないんだよなー
246:デフォルトの名無しさん
09/06/25 03:27:35
なんか場末のスナック的なスレだな
247:デフォルトの名無しさん
09/06/25 03:33:54
スナックに行った事が無いからワカンネ。
248:デフォルトの名無しさん
09/06/25 03:45:55
GNUスタイルとかは先頭ブレースの一行分長くなる点が好きでない
行数は可読性に直結すると思う
（だからといって、無理やり圧縮するのが良いとも思わないが）
その点、インデントベースは末尾のブレースやendも削れるのが素晴らしい
でも何となく好きになれないというワガママｗ どうも宙ぶらりん感がある
あとはS式みたいに、末尾に畳んじゃう記法だが・・・・編集がしずらいような
エディタの支援があればイケるか？
249:デフォルトの名無しさん
09/06/25 03:51:54
○ しづらい
250:デフォルトの名無しさん
09/06/25 03:56:25
S式は対括弧表示できるエディタ無いと苦しいね
まあ、Windows標準のメモ帳で開発しる！
なんてことが無い限り大丈夫だとは思うが
251:デフォルトの名無しさん
09/06/25 04:42:53
S式は文字数でインデントするからプロポーショナルだと崩れて読みづらい。
アメリカだとプロポーショナルでコーディングしてる人も結構いる印章だけど、彼らはどうしてるの？
252:デフォルトの名無しさん
09/06/25 08:03:14
>>240
具体的に >>233 で str の内容がRSの例を出してくれ。
とりあえず、
s = str[0]
if s in "OPQ":
func_a()
if s in "OPQRS":
func_b()
Python は他にも、 10 <= a && a < 20 を 10 <= a < 20 と書けたりするし、
if, elif の後に書ける条件式が強力だから switch 文が要らない。
253:230
09/06/25 09:11:22
えーと…OPQRSが文字として扱われるとは思なかった（・ω・）
それぞれ何らかの値と結び付けられてる定数のつもりだったんだけど…
254:デフォルトの名無しさん
09/06/25 09:26:55
>>253
if s in (O,P,Q):
func_a()
if s in (O,P,Q,R,S):
func_b()
else:
func_c()
Pythonにswitchが無いのは、散々議論された上で必要ないと判断されたから。
255:デフォルトの名無しさん
09/06/25 11:40:07
RubyやRoRって、生産性が高いって言うけど、それは膨大な規約を丸暗記した上での話だよな。俺的には分かりづらいったらありゃしないよ。
256:デフォルトの名無しさん
09/06/25 12:00:59
人の作った物だと丸暗記になるが、作った本人は丸暗記だと思ってないだろう
257:デフォルトの名無しさん
09/06/25 12:03:59
>>255
それは、他のでも変わらん
258:デフォルトの名無しさん
09/06/25 12:49:55
caseと三項演算子があればむしろif関係いらなくない？
259:デフォルトの名無しさん
09/06/25 16:44:58
ぶっちゃけswitchの方が意味解りやすいな
260:デフォルトの名無しさん
09/06/25 18:49:20
RubyやRoRは、どうだこれだと直感的で分かりやすいだろうっていう教条的な態度が我慢ならない。設定より規約って、大量に規約を覚えれば設定が省けるに過ぎない。
261:デフォルトの名無しさん
09/06/25 19:48:21
Strutsはわかりにくいうえに傲慢な態度だからな。しかも制約が多いくせに手間は省けない。
それよりは100万倍まし。
262:デフォルトの名無しさん
09/06/25 19:51:05
Javaだとmavenの思想が好きだ。
とりあえず何も書かなくても動く。
動きを変えたいところだけ、書く。
263:デフォルトの名無しさん
09/06/25 21:22:07
>>262
それならまさにRailsの思想じゃないかと
264:デフォルトの名無しさん
09/06/26 00:35:17
Ruby on Railsを使った事ない奴は、一度使ってから批評しような、とちょっと思った
中身をいじる必要も機会も、Java APIやJavaのframe workと同様に無いわけだしなｗ
もちろん、上書きは自由だし可能だしなあ
265:デフォルトの名無しさん
09/06/26 00:40:22
だから、結局、どんなフレームワークだって、最初に使うときは、
覚えなきゃならない事が沢山あるって事に違いはない。
フレームワークどころか、多機能な道具は、皆、
使った事が無ければ覚える事が多いってだけだ。
あとは、その道具の体系化の仕方が、
使おうとする個人に合っているかどうかというだけの事だ。
極めて、普遍的で当たり前の事であって、
わざわざ、キーボードを打つ手間を掛ける価値のない事だ。
266:デフォルトの名無しさん
09/06/26 00:49:47
>>265は、
> 使おうとする個人に合っているかどうかというだけ
が、普遍的で当たり前でキーボードを打つ手間を掛ける（、ましてやサーバ準備して
実行環境を整えるなんて！）価値のない事と言い切るが、それは本当にそうなのか。
足りていれば問題ないが、足りなくなったときにそれでは足るまい（←自己撞着）
まあ何でもいいが、それなりに使って評価してる人間がいるときに使わない人間の
評価なんて糞だと思うな。
267:デフォルトの名無しさん
09/06/26 01:07:49
>>261
そんな君にはWicketが向いている
268:デフォルトの名無しさん
09/06/26 03:10:55
>>265
Railsはあまたあるフレームワークの中でも暗黙の了解が半端なく多い。少ないコードで組めるっていうのは、それに頼ってるだけ。
269:デフォルトの名無しさん
09/06/26 03:20:55
まあ、言語自体が覚えること多過ぎな言語とか
標準ライブラリも拡張ライブラリも全部予約語扱いで予約語一覧だけで何ページにも渡る言語とか
そーゆーのもあるけどな
270:デフォルトの名無しさん
09/06/26 03:25:30
そんなことより、Erlanの話しようぜ
271:デフォルトの名無しさん
09/06/26 04:18:25
もしかして：Erlang
272:デフォルトの名無しさん
09/06/26 11:52:06
Erlang の話をする位なら Scala の話をしようぜ
273:デフォルトの名無しさん
09/06/26 11:55:42
今更ながら Python は良い言語かもしれないと思えて来た。
上の方のレスで、気持ち悪いと書いてしまってすまんかった。
274:デフォルトの名無しさん
09/06/26 12:33:21
>>272
ちょっと触ってみてるけど、
現時点では良いやら悪いやら分からん言語、という感想
狙いは合ってると思う
次に注目される言語が何かは分からんが、たぶんマルチパラダイムだろうし、
静的型付けの利点を残したまま記述量を減らすなら型推論は妥当
C#とかもその方向ではある
ただXMLリテラルは個人的に疑問。XMLは言語レベルで密結合させるほど絶対的なものか？
あと、背反しがちなオブジェクト指向と関数型を調和させようとして
言語が複雑奇怪になりかけてる（？）のも気になる。まあ仕方ない感はあるけど
275:デフォルトの名無しさん
09/06/26 14:42:21
>>274
>あと、背反しがちなオブジェクト指向と関数型を調和させようとして
そうなの？なぜ背反になるのかだれか教えて。
276:デフォルトの名無しさん
09/06/26 14:43:32
>>274
難解な表現はやめてもうちょっと簡単にいって。
じゃないとこのスレでは立ち入り禁止します。
277:デフォルトの名無しさん
09/06/26 15:09:12
おいおい、なんのためのスレだよ
278:デフォルトの名無しさん
09/06/26 15:36:40
Pythonにブロックスコープ無いけど、これは利点なの？欠点なの？
Rubyにも無いみたい。
279:デフォルトの名無しさん
09/06/26 15:44:14
グローバル変数さえ判り易ければいいと思うが、どうなんだろ
スコープ無しはプログラミングしたことないわ
280:デフォルトの名無しさん
09/06/26 16:11:37
ブロックスコープに頼って長々とメソッド書くんじゃない、ってことじゃないかな。
Ruby のブロック（は他の言語のブロックと違うけど）には、ブロックローカルが
あるけどね。
281:デフォルトの名無しさん
09/06/26 16:15:32
>>275
自分は >>274 じゃないが、
関数型だと変数は一度設定したら、書き換えない物であるのに対して、
オブジェクト指向だと、変数はドンドン書き換える物だから、
相容れないという事では？
282:デフォルトの名無しさん
09/06/26 16:32:36
>>280
ブロックスコープもそうだが
ローカル関数 (メソッドではない) に頼ってもメソッドは長くなる。
そういう書き方が嫌なのはOOへの拘りが強いせいでもあるんじゃないか。
283:デフォルトの名無しさん
09/06/26 17:04:21
でも拘るならスコープを狭い範囲に留めてさせてほしいなぁ。
その関数(やらメソッド)でしか使わない処理を、その関数(ry と同じ層に
おくのはなんかイヤらしい感じ。
284:デフォルトの名無しさん
09/06/26 17:06:08
JavaScriptにもブロックスコープがないのは盲点。
285:デフォルトの名無しさん
09/06/26 17:10:14
ブロックスコープの意味が未だに判らない。
for や while の中だけで有効な変数を作りたいってこと?
>>283 の言ってる、関数でしか使わない変数って、Pythonでも関数の中の
ローカル変数になるよね?
286:デフォルトの名無しさん
09/06/26 17:18:37
for や while の中、じゃなくて、
ブロックはブロックなんだけど。
for や while じゃない、ただ単にブロックだけのブロックも
あるわけで。
287:デフォルトの名無しさん
09/06/26 17:38:16
>>286
Pythonには無いよね>ブロックだけのスコープ
まぁ、関数より小さいスコープ作るよりも、関数自体を
小さくする方が良いんじゃないかな。
288:デフォルトの名無しさん
09/06/26 18:19:01
>>281
>関数型だと変数は一度設定したら、書き換えない物であるのに対して、
そんなことはない。関数型言語のうちで、そういうのもあるけど、たいがいのはそこまで厳しくない。
Lisp, Scheme, OCaml, ...
Haskellみたいなほうが少数派じゃね？
289:デフォルトの名無しさん
09/06/26 18:40:51
>>287
サブクラスを作るよりも、クラスの階層構造を小さくする方が良い
って思ったことはないのか？
290:デフォルトの名無しさん
09/06/26 18:43:01
>>278
>Pythonにブロックスコープ無いけど、これは利点なの？欠点なの？
>Rubyにも無いみたい。
一般的に、インタプリタではないと思う。これがあるのはコンパイル型言語の特徴じゃないかな。
もしインタプリタでブロックスコープを実現しようとすると、ブロックに入るたびに
新しい変数テーブルを用意し、ブロックから抜けるとそれを破棄しないといけない。
さすがにこれは、インタプリタでは性能がでない。
コンパイル型であればこれはコンパイル時に行なわれるから、実行時のペナルティはなしですむ。
インタプリタではあきらめろっつーことだな。ブロックスコープは、あったほうがうれしいけど、なくてもそうは困らない機能だから。
291:デフォルトの名無しさん
09/06/26 19:34:01
the requested operation has failed とエラーが出てapacheとphpの連携が取れない
システムファイルを変更すね前はapacheの起動はうまくいったのに、何をやっても
上のエラーが出てくる、誰か助けて～～～～～～～～!
292:デフォルトの名無しさん
09/06/26 19:43:07
>>285
変数だけじゃなくて、関数内関数も定義したいってこと。
293:デフォルトの名無しさん
09/06/26 19:50:39
>>291
まずはログファイルを探して読んでみよう
294:デフォルトの名無しさん
09/06/26 21:20:59
やっぱりブロックスコープがどうのこうの言ってるのが意味わからん。
たとえば、Perlではほぼできてる、ってこと？
#!/usr/bin/perl
my $a = 'a';
my $sub = sub(){ print "page\n"; };
{
my $a = 'b';
my $sub = sub(){ print "hoge\n"; };
print $a . "\n";
$sub->();
}
print $a . "\n";
$sub->();
295:デフォルトの名無しさん
09/06/26 22:31:08
本題からはずれるけど Perl で $a は使わないほうがいいよ
296:デフォルトの名無しさん
09/06/26 22:36:05
そう言えば、C++で昔 forのルール変わったよね。
for (int i = 0; ～) の i のスコープがfor文内になった。
297:デフォルトの名無しさん
09/06/26 22:41:04
>295
確か一部の組み込み関数とかで $a と $b を使うんだっけ？
298:デフォルトの名無しさん
09/06/26 23:00:52
>>292
少なくとも Python なら関数内関数作れるよ。
decorator なんて関数の中の関数の中で関数を作ったりする。
299:デフォルトの名無しさん
09/06/26 23:04:47
perlのブロックは変数の共有にも使えたりする。
今はさすがにオブジェクト指向で書くけどね。
set(12);
print get();
exit;
{
my $common;
sub set{
my ($value) = @_;
$common = $value;
}
sub get{
return $common;
}
}
300:デフォルトの名無しさん
09/06/26 23:08:33
関数内関数がやりたいだけならブロックにスコープ必要ないんでは
for文とかforeach文のブロックにスコープがあるのはいいような気がしないでもないけど
ブロックにスコープがあることの必要性がよく分からぬ
301:デフォルトの名無しさん
09/06/26 23:35:44
my $fizzbuzz;
{
my @a = qw(FizzBuzz - - Fizz - Buzz Fizz - - Fizz Buzz - Fizz - -);
$fizzbuzz = sub {……};
}
今はさすがにオブジェクト指向で書くけどねｗ
302:デフォルトの名無しさん
09/06/27 00:02:18
>>288
余り詳しくないけど……。
Lisp, Scheme は、一般的に広い意味で関数型言語と言われているけど、
本当の関数型言語（純粋関数型言語）ではないと聞いたと思う。
OCaml は、 ML の方言にオブジェクト指向機能を追加した言語で、
純粋な関数型言語ではなさそう。
303:デフォルトの名無しさん
09/06/27 00:05:06
流石にFizzBuzz問題にOOPは使わないなｗ
やろうと思えば、ジェネレータ使ったりするかも知れないがｗ
304:デフォルトの名無しさん
09/06/27 00:13:22
>302
OOPでも状態を変更するとは限らないから、やはり
OOPと関数型が相いれないとは言えないよ
例えばフィールドへの代入もコンストラクタでしか行わないとかいくらでもやりようはある
305:デフォルトの名無しさん
09/06/27 00:21:01
>>302
そんなことこのスレの住人のほとんどが知ってることだと思うけど
何が言いたいの？
306:デフォルトの名無しさん
09/06/27 00:24:09
>>304
静的な関数型言語だと
OOPは関数型によくある型システムの利点の一部を削り取ってしまう
307:デフォルトの名無しさん
09/06/27 00:31:50
>>305
そんなに突っかからなくてもいいじゃないか。
うゎーん（泣）
308:デフォルトの名無しさん
09/06/27 00:44:21
ブロックスコープは当然有効な機能だわ。その点、Perlは実にいい。
309:デフォルトの名無しさん
09/06/27 01:51:20
>>300
必要か否かでいってたら、たいていの便利なものは無くてもなんとかなるになっちゃうよ。
可読性を損なわないなら便利なものは使いたいな。
310:デフォルトの名無しさん
09/06/28 20:59:42
誰か、HSPの存在価値を教えてくれ。
あれもLL？DSLではあるみたいだが（どっちかというと、ゲーム特化(BASIC風)）
311:デフォルトの名無しさん
09/06/28 21:01:08
HSPはエントリーされていないのですれ違いデス。
312:デフォルトの名無しさん
09/06/28 21:10:38
価値はそれこそ個人の価値観の問題だろう
DSLだという見解には同意する
小規模なゲーム・グラフィカルなアプリの作成に特化している
ここで話題に上るような、いわゆるLLではないと思う
313:デフォルトの名無しさん
09/06/28 23:44:47
>>309
>必要か否かでいってたら、たいていの便利なものは無くてもなんとかなるになっちゃうよ。
うん、そうだよ。それでいいじゃん。
ブロックスコープは、あれば便利だけど、なくてすごく困るほどのものでもない。
すくなくともインタプリタにはペナルティが大きそうだから向かないと思う。
>可読性を損なわないなら便利なものは使いたいな。
便利でもペナルティが大きければ導入されない。
便利さのかげでなにも犠牲にならないのならいいけど、犠牲になるものがあるなら
あとはトレードオフでしょ。
314:デフォルトの名無しさん
09/06/29 01:25:09
ちゃんと計算されてる？ ペナルティとか
315:デフォルトの名無しさん
09/06/29 05:45:18
>>313
だから>>309が言ってるのは、必要か否かなんていう切り口で語ったら
ブロックスコープだろうがそれ以外のものだろうが、
大概のものは同じ結論しか出てこない、だから「ブロックスコープを」決め打ちで語りたきゃ
もっと踏み込んだ切り口を何か出さないと、ってことでは。
316:デフォルトの名無しさん
09/06/29 12:40:32
すみませんが教えてください。
下記のコードの3行目と5行目が何をしているのかわかりません。
特に3行目。。。
なぜrefで判定する必要があるのかもわからないので
詳しい方教えて下さい。
if(exists $form_data{$name} ) {
if(ref $form_data{$name} ) {
push @{ $form_data{$name} } , $value;
} else {
$form_data{$name} = [$form_data{$name} } , $value ];
}
else {
$form_data{$name} = $value;
}
317:デフォルトの名無しさん
09/06/29 13:03:49
>>313
＞便利でもペナルティが大きければ導入されない。
ところが、Perlにはあって、それでああいう
パフォーマンスがでているのだが。
ペナルティとかおおげさにいうほどのことは
ないんでは。
318:デフォルトの名無しさん
09/06/29 13:06:05
>>316
つ 配列のリファレンス、デリファレンス
319:デフォルトの名無しさん
09/06/29 13:28:44
>>317
Perlはmyやlocalで変数宣言をしているじゃないか。
Rubyとかだとそれがないから、ブロックスコープを実現しようとすると、
ブロックごとにチェックをいれないといけない。
じゃあ変数宣言のないRubyがウンコなんじゃないかということなら、否定はしない。
320:デフォルトの名無しさん
09/06/29 14:01:58
HSPは米国国防省の省内統制システムへの採用が内定してるらしいし
Rubyと同じパターンで「欧米で評価」→「日本で再評価」みたいな予感はする。
321:デフォルトの名無しさん
09/06/29 19:08:34
>>319
そもそも、変数宣言がなかったら、
ブロックスコープはどのように
表現すればいいの？
322:デフォルトの名無しさん
09/06/29 19:30:37
>>321
ブロックスコープは、無名関数をその場で1回だけ呼ぶのと同じ
323:デフォルトの名無しさん
09/06/29 20:52:50
変数宣言させることで、汚いコードを書けないように制約を受けるわけで、それは凄く楽だわ。PHPとかJavaScriptとか関数ベースのスコープの言語と比べると、そう思う。
324:デフォルトの名無しさん
09/06/29 21:19:11
>>321
必要に応じて変数名の前か後ろにスコープを記述すればいいんじゃない？
325:デフォルトの名無しさん
09/06/29 21:40:22
>>324
よくわからんので擬似コードでも書いてみればいいじゃない
326:デフォルトの名無しさん
09/06/29 21:48:02
>>316
まず、$form_data{$name} に配列のリファレンスを入れたいようだ、っていうのはわかるよね。
んで、その配列に$valueを追加する、っていう処理だとおもう。
そのさい、配列のリファレンスならデリファレンスする必要があるし、ただの配列なら単純にリスト
で追加してからリファレンスとして格納。
んで、５行目のこれ
> $form_data{$name} = [$form_data{$name} } , $value ];
typoってないか？
そして上記前提を覆す８行目
$form_data{$name} = $value;
このカオス。$valueは何者よｗ
結論から言うと、このコードは読めなくていいよ。 おれは読めないｗｗｗ
おれが勘違いしてるのかな。そうだといいな。
327:326
09/06/29 21:53:40
うん。やっぱり勘違いしてた。
最初に値（単純にスカラー期待）が与えられたときは、普通にスカラー。
もいちど飛んできたときは、配列のリファレンスとして格納。それだけだね。
どうせなら最初から配列のリファレンスにするよね、っていう固定観念があった。
328:デフォルトの名無しさん
09/06/29 22:43:18
>>325
擬似っつーかPowerShellだけど
> $hoge = 100
> & { $hoge = 111; "global: $global:hoge local: $hoge" }
global: 100 local: 111
みたいな感じ
まあブロックの中にまたブロックを～みたいな話になると別の方法になるけども
329:デフォルトの名無しさん
09/06/30 01:41:54
>>325
どうでもいいけどその言い回しおもしろいな
330:デフォルトの名無しさん
09/06/30 05:17:51
Rubyは、変数への代入で宣言も一緒にされるようなもんだっけ…
グローバルというかブロックの外に変数があるとそれを使い、ないとブロック内でのローカルになる。
たまにハマるんだよなー。
↓こういうの
10.times do |x|
i = x
end
puts i
unko.rb:4: undefined local variable or method `i' for main:Object (NameError)
331:デフォルトの名無しさん
09/06/30 06:37:41
>330
その場合、timesより前に i = nil でも i = 0 でも良いから代入が要るんよね
何回かやると慣れるがｗ
332:デフォルトの名無しさん
09/07/01 17:08:23
>>331
宣言だけじゃ駄目なんだっけ?
333:デフォルトの名無しさん
09/07/01 18:31:14
Rubyに変数宣言文は無いよ
最初の代入が宣言の代わりになるから、スコープ入る前に何か値を入れればスコープがそこに決まる
334:デフォルトの名無しさん
09/07/01 18:34:03
代入が無ければメソッド呼び出しと区別できない
というか宣言に相当するような構文が無い。代入が宣言を兼ねるというか
335:デフォルトの名無しさん
09/07/01 18:36:47
同じ変数名で局所化することはできるの？ブロックの外でiを使って、ブロックに入って、別のiを使うっていう。
336:デフォルトの名無しさん
09/07/01 18:40:14
不安に思ったら関数のはじめあたりで初期化してやればいいだけ
337:デフォルトの名無しさん
09/07/01 19:57:20
>335
変数名被るほど長いメソッドにせず、素直にprivateメソッド作る
338:デフォルトの名無しさん
09/07/01 20:21:02
>>337
また後付け前提ですか
339:デフォルトの名無しさん
09/07/01 20:54:23
>338
「それぐらいしか無い」とでも解釈すれば良いじゃない
具体的な挙動は相手にお任せするのがOOP流さね
340:デフォルトの名無しさん
09/07/01 21:27:21
>>339
二行目が全く>>337etcとつながらないな
意味不明
341:デフォルトの名無しさん
09/07/01 22:09:06
>340
ん？二行目はすぐ上の行としか繋がってないよ？
同じ文章でも各自で解釈は違いうる、ってポリモーフィズムっぽいよなあ、と
342:デフォルトの名無しさん
09/07/01 22:15:53
ブロックスコープの話とＯＯＰの話がどう結びつくのよ
343:デフォルトの名無しさん
09/07/01 22:16:58
どこともつながってないだろw
344:デフォルトの名無しさん
09/07/01 23:03:27
>>337
privateメソッドにしてそのメソッドから外に出したら、(そのオブジェクトの)他のメソッドからも呼べちゃうんじゃない？
345:ぼくのかんがえたさいきょうの
09/07/02 01:14:18
動くUMLだと思えば
そんなもんだろ
346:デフォルトの名無しさん
09/07/03 12:25:29
>>335
最新過ぎて第三者ライブラリの対応が追いついてないRuby1.9からはデフォルトでできる
一般的に使われてるRuby1.8ではそもそもできない
s = '無くしたら地球がヤバいデータ'
[1, 2, 3].each do |s|
s*10 # 適当
end
puts "#{s} は超重要だ！"
# Ruby1.8.7
3 は超重要だ！
# Ruby1.9.1
無くしたら地球がヤバいデータ は超重要だ！
Ruby1.8 のせいで地球がヤバい
347:デフォルトの名無しさん
09/07/03 12:47:36
うは。便利だけど 1.8 との互換性を考えると恐ろしい。
348:デフォルトの名無しさん
09/07/03 13:09:04
単なる変数じゃなくて、ブロックの引数であることに注意。
349:デフォルトの名無しさん
09/07/03 13:38:28
これでRuby使わない決心がついた。ありがとう。
350:デフォルトの名無しさん
09/07/03 13:40:21
似たようなのはPythonでもあるね。
x = "hoge"
y = [x for x in range(10)]
print(x)
Python 2.x なら xは9で、 3.xなら"hoge"のまま。
内包表記の中だけの名前になってる。
351:デフォルトの名無しさん
09/07/03 13:46:30
for や while を使う人がいないって言ったら Ruby 嫌がった人もいたし、人それぞれだな
352:デフォルトの名無しさん
09/07/03 13:59:02
>>346
Rubyって変数のスコープないの？
大昔に作られたLispですら変数のスコープがあるのに…
だめだめじゃん
353:デフォルトの名無しさん
09/07/03 14:12:01
は？
354:デフォルトの名無しさん
09/07/03 14:25:43
>>352
>>346を煽るのに「スコープがない」と言ってしまうような人はこのスレに来ちゃだめでちゅよ
355:デフォルトの名無しさん
09/07/03 14:29:31
>>354
> ブロックの外でiを使って、ブロックに入って、別のiを使うっていう。
スコープだろうが
356:デフォルトの名無しさん
09/07/03 15:05:25
Rubyは local や my といった予約語を使わずに、文脈上でスコープを定義する
ブロック内に変数が出現したとき、その時点で可視かどうかで
可視 → その変数を使う（つまり、書き換える）
不可視→ 新規変数（ブロックローカル）として定義する
という動作になってる
>>346では [1, 2, 3].each のブロック内での s は可視なので、変数を単に再利用する
これを最初から不可能にすることもできなくはなかったんだが、そうすると
out = 外部データ'
someblock do |s|
puts out #=> undefined
end
というように、ブロック外の変数にアクセスする方法がなくなってしまう
357:デフォルトの名無しさん
09/07/03 15:23:21
メソッドの引数も、ブロックの引数も、ライブラリの名前とかも宣言するのに
変数を宣言しない理由がよくわからない
358:デフォルトの名無しさん
09/07/03 15:25:31
R++ が出来たら Ruby を認めてやるよ。
359:デフォルトの名無しさん
09/07/03 15:27:44
>>357
変数は使う場所多いからいちいち宣言するのめんどいじゃん？ というような趣旨のことをどっかで聞いた覚えがある
360:デフォルトの名無しさん
09/07/03 15:30:50
変数宣言なんか導入されたら現状のRubyの利点である
「ローカル変数かインスタンスメソッドかよくわからないがとにかく返り値を返す何かであるhoge」
というのができなくなるじゃないかー
361:デフォルトの名無しさん
09/07/03 15:35:22
それ、やってるのお前だけだから。
362:デフォルトの名無しさん
09/07/03 17:31:50
>357
ライブラリ名の宣言というのがよく分からんが
メソッドやブロックの引数はRubyの場合、代入だろ？
モジュールやクラスの定義は
Module、Classのインスタンスを作成し定数に代入
さらに最後の式の結果を返す文
メソッド定義だけは少し毛色が違う気がするね
あれはProcのインスタンス作成とかしないだろうし
363:デフォルトの名無しさん
09/07/03 18:47:03
>>352
変数のスコープが無い って、言ってることがよくわからんな。
ローカル変数もインスタンス変数もクラス変数もスコープはちゃんとあるし。
ブロックがスコープを作らないってならPythonもJavascriptも一緒だし。
364:デフォルトの名無しさん
09/07/03 18:53:39
JavaScript1.7だったかからはブロックごとのスコープを持つletというのが出てきてvarの影が薄くなってる
365:デフォルトの名無しさん
09/07/03 18:54:27
Rubyの通常のブロックはスコープ作るよ
ブロック開始時の文脈でブロック内の変数の新規性をチェックしてるに過ぎない
366:デフォルトの名無しさん
09/07/03 19:03:09
うん、
class C
def initialize
hoge = 'hoge'
@block = lambda{puts hoge}
end
def run
hoge = 'MODIFIED!'
@block.call
end
end
C.new.run
は、call で実行された環境ではなく block が定義された文脈を考慮して
'hoge'
を表示する
367:デフォルトの名無しさん
09/07/03 19:05:44
本スレにもクロージャのスコープが理解できなくて延々文句垂れてた奴がいたな
そんな特殊なものでもないしちょっと調べれば分かるのに、Rubyばっかり話題になる意味がよく分からん
368:デフォルトの名無しさん
09/07/03 19:12:55
それは別の話じゃね
369:デフォルトの名無しさん
09/07/03 22:11:48
>>365
単純に、initializeとdefとは違うスコープになってて
呼び出し先が違うだけって事じゃないの？
370:デフォルトの名無しさん
09/07/05 04:29:55
>>349
遅すぎだろ。ｊｋｗ
371:デフォルトの名無しさん
09/07/06 00:08:20
なー、シンプルにそれぞれの最も優れてる実例を出してくれないか？
結局大事なのは使えるかだろ？
372:デフォルトの名無しさん
09/07/06 00:37:19
URLﾘﾝｸ(www.google.com)
373:デフォルトの名無しさん
09/07/06 21:34:43
えっ
374:デフォルトの名無しさん
09/07/06 21:35:26
何これこわい
375:デフォルトの名無しさん
09/07/07 01:33:20
>>372 の脳内
（検索しろ！と言う。俺かっこいいべ！昔はmanだったけど今はGoogleだべ。）
376:デフォルトの名無しさん
09/07/07 07:30:19
URLﾘﾝｸ(www.youtube.com)
377:デフォルトの名無しさん
09/07/07 08:50:13
URLﾘﾝｸ(d.hatena.ne.jp)
googleに使われてるよ
378:デフォルトの名無しさん
09/07/07 09:02:34
>>377
で？
379:デフォルトの名無しさん
09/07/07 09:04:06
>>378
Pythonが一番
380:デフォルトの名無しさん
09/07/07 09:30:20
Pythonはいいけど信者はうざい。この点rubyを凌駕している。
381:デフォルトの名無しさん
09/07/07 09:32:12
信者「ではない」よ
たぶんね
382:デフォルトの名無しさん
09/07/07 09:44:18
信者は「他称」だからなｗ
383:デフォルトの名無しさん
09/07/07 09:48:50
傍目にウザい時点で他人が装ってる可能性が大
>>380みたいに単純な人はいいオモチャ
384:デフォルトの名無しさん
09/07/07 10:48:48
信者はうざい。はここの書き込みに言ったのではない。
385:デフォルトの名無しさん
09/07/07 12:51:34
>>380
ルビ厨のほうがひどいだろ。ｊｋ
386:デフォルトの名無しさん
09/07/07 13:15:51
どの言語信者も最近はわりと皆おとなしいだろ
弾やmatzも
387:デフォルトの名無しさん
09/07/07 13:21:28
>>384
>>379がageてるのに気づいて後出しじゃんけんですね。わかります。
388:デフォルトの名無しさん
09/07/07 14:05:45
お前に何がわかるっていうんだ!!
389:デフォルトの名無しさん
09/07/07 14:16:03
JavaってLLじゃね？
390:デフォルトの名無しさん
09/07/07 15:31:14
>>1にエントリーされていないのでスレ違いとなります
391:デフォルトの名無しさん
09/07/07 17:06:57
>>390
ダメです。
392:デフォルトの名無しさん
09/07/07 18:00:16
久し振りにラクダ本を開いた。
テキトーなページを開いたら「配列の配列」について書かれていて
for $i ループ内には
$AoA[$i] = @array; # 間違い
$AoA[$i] = [ @array ]; # 正しい
と書かれていた。
…俺は読むのをやめた。
393:デフォルトの名無しさん
09/07/07 18:46:27
>>392
それのどこに嫌要素が？
超わかりやすいだろ。
394:デフォルトの名無しさん
09/07/07 18:54:26
>>392
何が問題なん？
395:デフォルトの名無しさん
09/07/07 19:29:05
で、№1は誰なんだよ
396:デフォルトの名無しさん
09/07/07 19:33:28
お前に決まってるだろ
397:デフォルトの名無しさん
09/07/07 19:36:38
じゃあ独断と偏見でPythonって事で
398:デフォルトの名無しさん
09/07/07 20:00:10
もう俺JavaScriptでいいや
399:デフォルトの名無しさん
09/07/07 23:04:16
Python最強ですよねー
400:デフォルトの名無しさん
09/07/07 23:09:03
>>392は、以前にPerlを触ったときにはスカラーの概念やリファレンスまでは
たどり着けなかったんだと。
まあどの言語でも、一つずつ覚えてちょっとずつ進歩していけばいいと思うよ。
401:デフォルトの名無しさん
09/07/08 03:33:31
俺には393や394の感覚がわからん。400もな。
392の例はあからさまに直感的じゃないと思うよ。
402:デフォルトの名無しさん
09/07/08 03:44:53
$AoA[$i] = $@array;
403:デフォルトの名無しさん
09/07/08 04:41:20
配列のリファレンスも分からないようなPerl素人がいきなりラクダ本なんて読もうと思うのが間違い。
もっと初心者向けび本にしとけ。
というか、リファレンスとかポインタとか理解出来ない人間は職業プログラマーの素養がないので、PHPで日曜プログラマーでよい。
404:デフォルトの名無しさん
09/07/08 05:00:29
～が理解できないとかPerl上級者とかそういう話はしてないよ
405:デフォルトの名無しさん
09/07/08 05:04:00
リファレンスが解るかどうかと、392が直感的かとは別問題でしょ…
俺だってCやJavaやPythonやRubyでリファレンスなら扱えるさ
Perlのは同じ記述がコンテキストで意味変わり過ぎてちと無理だわ
406:デフォルトの名無しさん
09/07/08 05:05:55
$AoA[$i] = [ @array ]; # usually best
$AoA[$i] = \@array; # perilous; just how my() was that array?
@{ $AoA[$i] } = @array; # way too tricky for most programmers
perldscから引用
直感的ではないなどと主観で言われても、
ああ、そうですかとしか言いようが無いけどね。
407:デフォルトの名無しさん
09/07/08 05:15:50
>>402
それ、エラー出ないか？
ちなみに同じページに
$AoA[$i] = \@array;
もほぼ間違い、と書かれていた。
@arrayがループ内でmyされたものなら問題は起きないが
ループより外にスコープがあるものだった場合
\@arrayは毎回同じ配列へのリファレンスを取得してしまうから、だそうだ。
408:デフォルトの名無しさん
09/07/08 06:20:36
言語毎にまとめてみた。
上はコピーされてリファレンスが渡され、下は直接リファレンスが渡される。
Perl
$AoA[$i] = [ @array ];
$AoA[$i] = \@array;
PHP
$AoA[$i] = $array;
$AoA[$i] = &$array;
Ruby
AoA[i] = array.dup
AoA[i] = array
Python
AoA[i] = list(array)
AoA[i] = array
409:デフォルトの名無しさん
09/07/08 06:29:28
Perlの場合リファレンスとかがわかりにくいというより
コンテキストが問題を分かりにくくしてると思う
410:デフォルトの名無しさん
09/07/08 07:52:09
今回の例に限って言えば、配列（およびハッシュ）の要素にはスカラー値のみ格納できる、
っていう言語仕様を知ってるかどうかだけのことなんだろうけどな
411:デフォルトの名無しさん
09/07/08 07:56:55
配列の配列とかが直感的に思った通りに出来る言語が勝ちだな。
412:デフォルトの名無しさん
09/07/08 08:06:57
>>411
直感は個人によって違うわけだから、そんなに直感的にやりたいなら自分で言語作ればいいんじゃないかと
つプログラミング言語を作る 前橋 和弥 (著)
URLﾘﾝｸ(www.amazon.co.jp)
413:デフォルトの名無しさん
09/07/08 10:08:45
@hoge = (1, 2, (3, 4, 5), (6, 7, (8, 9)), 10);
414:デフォルトの名無しさん
09/07/08 10:48:19
いつ見ても、Perlの文法は糞過ぎる。
なんで未だにこれを擁護出来る人が居るのか不思議でならない。
415:デフォルトの名無しさん
09/07/08 10:54:06
糞であるが故のバッドノウハウ症候群。
そして今更捨てられることができない認知的不協和。
416:デフォルトの名無しさん
09/07/08 11:42:12
無名関数を積極的に使いたい人は
クラス・メソッドの関係にこだわらないperlの方がむしろ癖がなくて良い
417:デフォルトの名無しさん
09/07/08 11:49:27
>416
まともな関数型言語触った事無い奴が、そんな寝ぼけた事言ってるんだろうな。
418:デフォルトの名無しさん
09/07/08 11:51:04
無名関数を積極的に使うならJSが割と最適解かも
419:デフォルトの名無しさん
09/07/08 11:52:21
416 は Perl しか使っていない
420:デフォルトの名無しさん
09/07/08 12:07:54
使いまわしの出来るクラスの一つや二つ作れるようになってから（ｒｙ
421:デフォルトの名無しさん
09/07/08 12:30:21
>>418 合意
422:デフォルトの名無しさん
09/07/08 12:31:36
>>408
Javaに慣れてしまった俺としては、Rubyが一番素直に見える。
次はPython、でPHPの順かな。
Perlはやっぱり複雑怪奇だ。
配列をオブジェクトとして扱えた方が、array.lengthみたいな書き方が出来て便利だと思う。
>>418
確かに。
最初のうちは無名関数の使いどころがよくわからなかったけど、
JavaScriptを使っているうちになんとなく身についた。
423:デフォルトの名無しさん
09/07/08 12:38:37
無名関数を関数型言語で覚えた奴は、純粋な関数処理を書く。
JavaScriptで覚えた奴は、副作用大前提のプロシージャっぽいのを書く。
424:デフォルトの名無しさん
09/07/08 12:56:06
>>414
いつ見ても、Rubyの文法は糞過ぎる。
なんで未だにこれを擁護出来る人が居るのか不思議でならない。
と、何にでも適用可能だな。ｗ
425:デフォルトの名無しさん
09/07/08 13:02:03
>>423
副作用大前提のおかげで、ジェネレータが発明されたんだぜ
426:デフォルトの名無しさん
09/07/08 13:08:20
LISPだって副作用バリバリだろ。
427:デフォルトの名無しさん
09/07/08 13:13:00
perlだけはレベルが違う
428:デフォルトの名無しさん
09/07/08 13:26:55
>>422
Java はどのへん？
C# は？
429:デフォルトの名無しさん
09/07/08 14:53:48
ラクダ本って言うのは、Perlに詳しい人が読む本。初心者が無理して読む本じゃない。
430:デフォルトの名無しさん
09/07/08 15:05:58
Javaは数値以外は基本的に参照、だからコピーのときに明示
C#は知らん
431:デフォルトの名無しさん
09/07/08 15:06:15
ダウト。ラクダ本は多言語上級者がPerl入門のために読むもの。
432:430
09/07/08 15:15:26
盛大にコンテキスト（文脈）を読み間違えたぜ…
433:デフォルトの名無しさん
09/07/08 15:59:44
結局コードも示さずに複雑怪奇やら、糞やら、呪詛を吐くしかできないのか。
だめだこりゃ。
434:デフォルトの名無しさん
09/07/08 16:01:49
>>433
そりゃほとんどの人間の悪口は脳内の言語イメージに対して言っているものだから仕方ない
そういう馬鹿がよりつかなくてよかったと思うしか
435:デフォルトの名無しさん
09/07/08 19:10:09
package MyObj;
sub new {
my ($class) = @_;
my $self = { 'items' => [] };
bless $self, $class;
}
sub set {
my ($self, $newitem) = @_;
push @{ $self->{'items'} }, $newitem;
}
sub take {
my ($self) = @_;
pop @{ $self->{'items'} };
}
1;
いまPerl初心者の俺のコードが簡単に言うとこんな感じになってるんだが
Perl使い的にはどう書くんだ？
436:デフォルトの名無しさん
09/07/08 19:55:55
Perlスレで聞けばいいのに。
モダンに書くとしたら。
package MyObj;
use Moose;
has 'items' => (
is => 'rw',
isa => 'ArrayRef',
default => sub { [] }
);
sub set {
my ($self, $newitem) = @_;
push @{ $self->items }, $newitem;
}
sub take {
my ($self) = @_;
return pop @{ $self->items };
}
1;
これだけ単純なら、use Mooseじゃなくてuse Mouseでも。
437:デフォルトの名無しさん
09/07/08 21:22:20
モダン（笑）
ハイソ（笑）
ハイカラ（笑）
438:デフォルトの名無しさん
09/07/08 21:47:52
ニーソ馬鹿にすんな
439:デフォルトの名無しさん
09/07/08 23:30:45
perlerの連中も、意識的にモダンに書かないと、非モダンな出来上がりになる事は
認めてるらしい。
440:デフォルトの名無しさん
09/07/08 23:56:12
perlの文を見ると吐き気がする。C++の仕様の方がカワイイぐらいだ
いい加減に間違った進化だったって、さっさと淘汰されないかな
441:デフォルトの名無しさん
09/07/09 00:04:30
Perl系の言語って、Perlそのもの以外になんかあるんだっけ？
442:436
09/07/09 00:34:14
>>439
まあ、モダンでなければ非モダンだわな。>>435そのままだし。
>>436でもAny::Mooseぐらい使えとか、no Mooseしとけとか突っ込まれそうな気がする。
>>441
直系はPHPとRuby。既に別物。
443:デフォルトの名無しさん
09/07/09 00:40:49
>441
JPerlとIronPerlがあるよ
444:デフォルトの名無しさん
09/07/09 00:47:37
PHPってPerl系なのか
445:デフォルトの名無しさん
09/07/09 00:55:53
PHPは元を辿ればPerlの派生だけど、
ポリシーの無い付け足しをしまくりでワケワカメ状態。
446:デフォルトの名無しさん
09/07/09 04:27:04
モノポリー
447:デフォルトの名無しさん
09/07/09 04:39:45
のんぽり
448:デフォルトの名無しさん
09/07/09 08:50:51
>>440
Rubyの文を見ると吐き気がする。Pythonの仕様の方がカワイイぐらいだ
いい加減に間違った進化だったって、さっさと淘汰されないかな