アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(ry
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外しかも知れませんがご容赦を。perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってきて改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。# (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照これのおかげで記述が省略されているところが多いと読み下すのにすごく大変です。# 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、# 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもあるらくだ本に何度も出てくるフレーズで“perlらしさ”の原点なんだろうとは理解していますが。。。例えば(Cで記述しますが)
int foo_1(int x){ return (x ? x*foo_1(x-1) : 1);} int foo_2(int x){ if (x != 0){ int result; result = x * foo_2(x-1); return result; } else { return 1; } /* NOT REACHED */}
foo_1 とfoo_2は同じことをする関数(完全に等価かどうかは突っ込まんでください)ですが、私も若い頃はfoo_1のような書き方がカッコいいとイキガッテ(笑)たんですけど、業務で書くならfoo_2のように書きます。
で、偏見だと思う(思いたい)んですが、perl遣いのかたってfoo_1のような記述を好む傾向がある気がしています。。。
---- こういう人間がJPAの啓発対象なんだろうなぁ・・・(苦笑)
それは foo_1 に書くのは oneliner 的な書き方をする場合などで、仕事でコーディング規約を揃えてやろうっていう場合は foo_2 のように書ける人ばかりだったりしますね。 しかしそれはそういったコーディング規約を決めずに好き勝手に書いていい状態で野放しにした結果なんじゃないでしょうか。
どんな言語を使ったって 1 ステップごとに内容のコメントを書いていく人やわざわざ難解な記述 (単項演算子を使うとかいうレベルではなく) にする人はいますので、そこは言語の責任ではないように思えます。
私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だってfoo_2は「長い」んだもん。
長ったらしいから目で追うのがそもそも辛いし、 中間変数を使えば変数の取り違えのリスクが生じる。
三項演算子がマズイとすれば優先順位が見づらいことだろう。 だからコーディング規約として 「三項演算子なら各要素をかならず括弧でくくれ」とでもしておくのは有意義だろう。
が、三項演算子じたいを禁止すればコードが冗長になりすぎることが有る。 冗長すぎるコードはバグの元だ。
あと、三項演算子が見た目として目立たないから気づきにくくてマズイという指摘については、SQL
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分ココです。三項演算子だけじゃなくて、
read or die
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面食らうんですよ。。。年寄りには
if (read == FALSE) then die # 架空の言語
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗)
>私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だって>foo_2は「長い」んだもん。
と言えるのは、foo_1がすんなり読み下せるヒトの場合だと思うのです。慣れの問題だとは思うんですがperlの場合、こゆ『慣れ』を要する部分が他言語よりも多い気がするのと前の投稿で書いたように『慣れる前に放り出したくなる』のが私的にはボトルネックでした。
「read または die」と読むと分からなくなりますが、「read さもなくば die」と読むと分かるんじゃないですか?
R.O.D [sonymusic.co.jp]好きなんだけどな。好みの問題だからしょうがないか。
RODは私も少しだけ(TVで)見て結構好きになりました。
>年寄りには
何についてどう年を食ってるかにもよります。 C(の三項演算子)に慣れてると、三項演算子を使うほうが爺っぽくみえる。
Java坊やたちに read or die みたいな「論理演算子の左辺がBooleanではない(とは限らない)式」を見せると、いい獲物だと言わんばかりに騒ぎ出しますね。
#Javaしか知らない自称OOP屋なひとは、いっぽうでNullがオブジェクトではないことについて全く騒ぎ立てないから不思議だ:-O
いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについてのユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。「型のルールとしてはちとグダグダだが、実際にコーディングしてみると、こういう書き方をすると丁度旨い具合にコーディングコストが下がる(短くなる)」というのが経験的に見えてるからこうしてる、という。
ただ、たとえば0をtrue/falseどっちとみなすか?で派閥が有るのが厄介ですが(^^;
いいこと言うなぁ。なるほど、自然に読めば意味が通るじゃないか。
じゃ、俺も。
daed or alive
い、いきなり死んだぞ?
>いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについての>ユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。
別枝のブール値の話題にはクビを突っ込まなかったんですが、Cの場合、最終的にアセンブラコードに落ちる時のことを考えると、jz, jnz(8086ニモックの場合ね)になってくれるのが実効速度的にも利いてきますから、ゼロ/非ゼロを真偽に割り当てるのが妥当なんだと思います。(まさしく経験則)
で、偽=ゼロ、真=非ゼロで定義しておくとビット演算のand, orで破綻しないですから。実際、Cのif構文の条件判断は、偽=ゼロ、真=非ゼロですしね。
あと、if (hoge() == ture) と書いてハマるという話題があって、確かにその通りなんですが、真か偽を返すはずの関数が3とか5とかいう返り値を出すのはナニガシか『もっと大きな問題』を内在している可能性がけっこうあったりしますので、あえて
#define TURE 1#define FALSE 0
と定義して、if (hoge() == TURE) と書くように統一したこともあります。もちろん、関数単位の単体テストをキッチリやらせるのが大前提ですし、それでも1/0以外の値を返されると大ハマりするんですが、ソレでハマるケースっていうのは、アルゴリズムに致命的な欠陥がある、とか、そもそも仕様が変、だったりすることがあって、結果的にはそういう『もっと大きな問題』を早期に炙り出してくれることにつながった思ってます。
私は、条件を満たさなかった場合であることを明示するため、else節を入れる方が良いように思います。このような一行しかなければ明白ですけど、else節となるべき部分が長くなる場合には分かりにくくなると思います。
今回の例の場合、if文の後に処理がありません。わざわざ/* NOT REACHED */と置いていますが、elseを使わない書き方なら構造がそれを示しますから、lintや読者に対する説明が不要になります。
また、今回の例では違うと思いますが、もし真と偽が対等な正常ルートならelse節で書いたほうがわかりやすいでしょう。
あと、いまどきの流儀だと、かなり細かく積極的に関数にくくり出すことが望まれますので、else節が長くなる心配はないです。関数やファイル数が増えるのを嫌う人もいますので、その方法を取れない場合もあるでしょうが。
さらに余談ですが、一時期話題になった「OOコード養成ギブス [hatena.ne.jp]」(邦訳の出た「ThoughtWorksアンソロジー」の一節)では「else禁止」なんてのがあります。
>ifは例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
1.『例外パターンを排除してから正常系の処理』でポリシー統一するというのも方法のひとつですが
あたりが気にはなります。# 気になるだけです。私が組んで、こう書く場合もけっこう多いです
2.perlの話だと、後置ifは、このポリシーの時使いやすいですね(read or dieの話とかいろいろ書きましたが、この記述は素直にいいなと思います)
return if (例外条件);正常系の処理;
>変数に入れてすぐにreturnするなら、直接書く
3.(業務での話なので、ややオフトピですが)残念なコトに
return x * foo_2a(x - 1);
この記述でさえ混乱するメンバーとかいたりするんですよねorz
4.例えば、コーディング規約で、単純に『(読解スキルの低いヤツもいるんだから)三項演算子は使用不可』なんてすると以下のようなコードが出てきたりします(^^;
int foo_2b(int x){ int result = 1; if (x != 0) result = (x * foo_2b(x-1)); return result;}
これはこれで賛否ありそうですけど(^^;;
私は、業務なら100%こう記述します
int foo_3(int x){ int result; if (x == 0) return 1; result = x * foo_3(x-1); return result;}
#趣味の範疇でしょうが。。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:1, 興味深い)
最近のPerlはそうでもない気がします。
Re: (スコア:2, すばらしい洞察)
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(ry
Re:Perlはもっと評価されていい (スコア:1)
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外
しかも知れませんがご容赦を。
perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってき
て改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。
# (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照
これのおかげで記述が省略されているところが多いと読み下すのにすごく大変
です。
# 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、
# 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもある
らくだ本に何度も出てくるフレーズで“perlらしさ”の原点なんだろうとは理
解していますが。。。例えば(Cで記述しますが)
foo_1 とfoo_2は同じことをする関数(完全に等価かどうかは突っ込まんでくだ
さい)ですが、私も若い頃はfoo_1のような書き方がカッコいいとイキガッテ(笑)
たんですけど、業務で書くならfoo_2のように書きます。
で、偏見だと思う(思いたい)んですが、perl遣いのかたってfoo_1のような記
述を好む傾向がある気がしています。。。
---- こういう人間がJPAの啓発対象なんだろうなぁ・・・(苦笑)
♪潔くカッコよく生きてゆこう
Re:Perlはもっと評価されていい (スコア:1)
それは foo_1 に書くのは oneliner 的な書き方をする場合などで、仕事でコーディング規約を揃えてやろうっていう場合は foo_2 のように書ける人ばかりだったりしますね。
しかしそれはそういったコーディング規約を決めずに好き勝手に書いていい状態で野放しにした結果なんじゃないでしょうか。
どんな言語を使ったって 1 ステップごとに内容のコメントを書いていく人やわざわざ難解な記述 (単項演算子を使うとかいうレベルではなく) にする人はいますので、そこは言語の責任ではないように思えます。
Re: (スコア:0)
私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だってfoo_2は「長い」んだもん。
長ったらしいから目で追うのがそもそも辛いし、 中間変数を使えば変数の取り違えのリスクが生じる。
三項演算子がマズイとすれば優先順位が見づらいことだろう。 だからコーディング規約として 「三項演算子なら各要素をかならず括弧でくくれ」とでもしておくのは有意義だろう。
が、三項演算子じたいを禁止すればコードが冗長になりすぎることが有る。 冗長すぎるコードはバグの元だ。
あと、三項演算子が見た目として目立たないから気づきにくくてマズイという指摘については、
SQL
Re:Perlはもっと評価されていい (スコア:1)
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分コ
コです。三項演算子だけじゃなくて、
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。
解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面
食らうんですよ。。。年寄りには
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗)
>私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だって
>foo_2は「長い」んだもん。
と言えるのは、foo_1がすんなり読み下せるヒトの場合だと思うのです。
慣れの問題だとは思うんですがperlの場合、こゆ『慣れ』を要する部分が他言
語よりも多い気がするのと前の投稿で書いたように『慣れる前に放り出したく
なる』のが私的にはボトルネックでした。
♪潔くカッコよく生きてゆこう
Re:Perlはもっと評価されていい (スコア:1)
「read または die」と読むと分からなくなりますが、
「read さもなくば die」と読むと分かるんじゃないですか?
1を聞いて0を知れ!
Re: (スコア:0)
R.O.D [sonymusic.co.jp]好きなんだけどな。好みの問題だからしょうがないか。
Re: (スコア:0)
RODは私も少しだけ(TVで)見て結構好きになりました。
>年寄りには
何についてどう年を食ってるかにもよります。 C(の三項演算子)に慣れてると、三項演算子を使うほうが爺っぽくみえる。
Java坊やたちに read or die みたいな「論理演算子の左辺がBooleanではない(とは限らない)式」を見せると、いい獲物だと言わんばかりに騒ぎ出しますね。
#Javaしか知らない自称OOP屋なひとは、いっぽうでNullがオブジェクトではないことについて全く騒ぎ立てないから不思議だ:-O
いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについてのユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。
「型のルールとしてはちとグダグダだが、実際にコーディングしてみると、こういう書き方をすると丁度旨い具合にコーディングコストが下がる(短くなる)」
というのが経験的に見えてるからこうしてる、という。
ただ、たとえば0をtrue/falseどっちとみなすか?で派閥が有るのが厄介ですが(^^;
Re: (スコア:0)
いいこと言うなぁ。
なるほど、自然に読めば意味が通るじゃないか。
じゃ、俺も。
daed or alive
い、いきなり死んだぞ?
Re:Perlはもっと評価されていい (スコア:1)
> open || die
なんですけど、わざわざ、read or die なんて記述にしたのはR.O.Dを考慮したからに
決まってるじゃないですか! (決まってるのか??^^;)
読子さ~ん(*^^*)
♪潔くカッコよく生きてゆこう
Re:Perlはもっと評価されていい (スコア:1)
>いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについての
>ユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。
別枝のブール値の話題にはクビを突っ込まなかったんですが、Cの場合、
最終的にアセンブラコードに落ちる時のことを考えると、
jz, jnz(8086ニモックの場合ね)になってくれるのが実効速度的にも利いてき
ますから、ゼロ/非ゼロを真偽に割り当てるのが妥当なんだと思います。
(まさしく経験則)
吐くそうなんで、若いヒトにはピンと来ないかも
で、偽=ゼロ、真=非ゼロで定義しておくとビット演算のand, orで破綻しな
いですから。
実際、Cのif構文の条件判断は、偽=ゼロ、真=非ゼロですしね。
あと、if (hoge() == ture) と書いてハマるという話題があって、確かにその
通りなんですが、真か偽を返すはずの関数が3とか5とかいう返り値を出すのは
ナニガシか『もっと大きな問題』を内在している可能性がけっこうあったりし
ますので、あえて
と定義して、if (hoge() == TURE) と書くように統一したこともあります。
もちろん、関数単位の単体テストをキッチリやらせるのが大前提ですし、それ
でも1/0以外の値を返されると大ハマりするんですが、ソレでハマるケースっ
ていうのは、アルゴリズムに致命的な欠陥がある、とか、そもそも仕様が変、
だったりすることがあって、結果的にはそういう『もっと大きな問題』を早期
に炙り出してくれることにつながった思ってます。
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
・then節でreturnしていればelseは不要
・変数に入れてすぐにreturnするなら、直接書く
・ifは例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
int foo_2a(int x)
{
if (x == 0) {
return 1;
}
return x * foo_2a(x - 1);
}
Re:Perlはもっと評価されていい (スコア:1)
私は、条件を満たさなかった場合であることを明示するため、else節を入れる方が良いように思います。このような一行しかなければ明白ですけど、else節となるべき部分が長くなる場合には分かりにくくなると思います。
Re: (スコア:0)
今回の例の場合、if文の後に処理がありません。わざわざ/* NOT REACHED */と置いていますが、elseを使わない書き方なら構造がそれを示しますから、lintや読者に対する説明が不要になります。
また、今回の例では違うと思いますが、もし真と偽が対等な正常ルートならelse節で書いたほうがわかりやすいでしょう。
あと、いまどきの流儀だと、かなり細かく積極的に関数にくくり出すことが望まれますので、else節が長くなる心配はないです。関数やファイル数が増えるのを嫌う人もいますので、その方法を取れない場合もあるでしょうが。
さらに余談ですが、一時期話題になった「OOコード養成ギブス [hatena.ne.jp]」(邦訳の出た「ThoughtWorksアンソロジー」の一節)では「else禁止」なんてのがあります。
Re:Perlはもっと評価されていい (スコア:1)
>ifは例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
1.
『例外パターンを排除してから正常系の処理』でポリシー統一するというのも
方法のひとつですが
あたりが気にはなります。
# 気になるだけです。私が組んで、こう書く場合もけっこう多いです
2.
perlの話だと、後置ifは、このポリシーの時使いやすいですね
(read or dieの話とかいろいろ書きましたが、この記述は素直にいいなと思い
ます)
>変数に入れてすぐにreturnするなら、直接書く
3.
(業務での話なので、ややオフトピですが)残念なコトに
この記述でさえ混乱するメンバーとかいたりするんですよねorz
4.
例えば、コーディング規約で、単純に『(読解スキルの低いヤツもいるんだか
ら)三項演算子は使用不可』なんてすると以下のようなコードが出てきたりし
ます(^^;
これはこれで賛否ありそうですけど(^^;;
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
私は、業務なら100%こう記述します
int foo_3(int x)
{
int result;
if (x == 0)
return 1;
result = x * foo_3(x-1);
return result;
}
#趣味の範疇でしょうが。。。