アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(ry
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外しかも知れませんがご容赦を。perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってきて改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。# (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照これのおかげで記述が省略されているところが多いと読み下すのにすごく大変です。# 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、# 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもあるらくだ本に何度も出てくるフレーズで“perl
私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だってfoo_2は「長い」んだもん。
長ったらしいから目で追うのがそもそも辛いし、 中間変数を使えば変数の取り違えのリスクが生じる。
三項演算子がマズイとすれば優先順位が見づらいことだろう。 だからコーディング規約として 「三項演算子なら各要素をかならず括弧でくくれ」とでもしておくのは有意義だろう。
が、三項演算子じたいを禁止すればコードが冗長になりすぎることが有る。 冗長すぎるコードはバグの元だ。
あと、三項演算子が見た目として目立たないから気づきにくくてマズイという指摘については、SQL
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分ココです。三項演算子だけじゃなくて、
read or die
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面食らうんですよ。。。年寄りには
if (read == FALSE) then die # 架空の言語
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗
「read または die」と読むと分からなくなりますが、「read さもなくば die」と読むと分かるんじゃないですか?
いいこと言うなぁ。なるほど、自然に読めば意味が通るじゃないか。
じゃ、俺も。
daed or alive
い、いきなり死んだぞ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:1, 興味深い)
最近のPerlはそうでもない気がします。
Re: (スコア:2, すばらしい洞察)
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(ry
Re: (スコア:1)
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外
しかも知れませんがご容赦を。
perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってき
て改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。
# (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照
これのおかげで記述が省略されているところが多いと読み下すのにすごく大変
です。
# 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、
# 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもある
らくだ本に何度も出てくるフレーズで“perl
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だってfoo_2は「長い」んだもん。
長ったらしいから目で追うのがそもそも辛いし、 中間変数を使えば変数の取り違えのリスクが生じる。
三項演算子がマズイとすれば優先順位が見づらいことだろう。 だからコーディング規約として 「三項演算子なら各要素をかならず括弧でくくれ」とでもしておくのは有意義だろう。
が、三項演算子じたいを禁止すればコードが冗長になりすぎることが有る。 冗長すぎるコードはバグの元だ。
あと、三項演算子が見た目として目立たないから気づきにくくてマズイという指摘については、
SQL
Re: (スコア:1)
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分コ
コです。三項演算子だけじゃなくて、
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。
解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面
食らうんですよ。。。年寄りには
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗
♪潔くカッコよく生きてゆこう
Re: (スコア:1)
「read または die」と読むと分からなくなりますが、
「read さもなくば die」と読むと分かるんじゃないですか?
1を聞いて0を知れ!
Re:Perlはもっと評価されていい (スコア:0)
いいこと言うなぁ。
なるほど、自然に読めば意味が通るじゃないか。
じゃ、俺も。
daed or alive
い、いきなり死んだぞ?