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

【Perl,PHP】LLバトル ..

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
Wikipedia項目ﾘﾝｸ

日本以外では言わない。海外ではリソース消費が軽量という意味で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(" ", "&nbsp")

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の構文糖衣だし、なんか的はずれすぎてﾜﾛﾀ

次ページ