アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の４つ。
- true, false の boolean値を利用できない。 CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ？)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、 sub true() { return 1; } sub false() { return 0; } などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラになっていることが多く、可読性が低いものが多い。
- モジュール(クラス)を作る際、いちいち bless をする必要がある 一度覚えれば分かりにくくは無いが、他の言語に比べて余計なコーディングしている感は否めない。また、人によって、$this だったり、$self だったりマチマチなのもいただけない。
- public, protected, private などの指定ができない。 よって、モジュール(クラス)のどのメソッドでも呼び出せる。危険なだけではなく、どれがインターフェースなのか分かりにくく可読性が悪い。
上記が満たされるようになれば、また使いたい言語です。
今や、PerlでOOするのなら、ごしごし書きませんよ。MooseやMouseを使えば、blessなぞ、書く必要もないです。もちろん、boolean等の型指定も可能です。ここらへんのことが余りにも知られてなくて、JPAが啓発して行こうと考えているのでしょう。
MooseやMouseモジュールの存在を知らなかったので、ざっと見てみました。しかし、結論から言うと、まだ使う気になれないですね…。
MooseやMouseの記述方法が、モジュールではなくPerlの言語として正式に組み込まれるのであれば使う気がおこるのですが、今のところそうではなさそうなので…。
このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。少なくともアクセサは言語の中に組み込まれるべきだと思います。（使う使わないは別にして）
# MooseやMouseについて、教えていただきありがとうございました。勉強になりました。
このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。少なくともアクセサは言語の中に組み込まれるべきだと思います。
極論すれば、MooseやMouse等を完全にコアに入れたものが、Perl6なんです。「混乱」等ないと思いますが、あるとすれば非英語圏の人だけだと思います。Mooseのメインメンテナである、Dave Rolsky氏は（「Mason」という本の著者で有名ですが）は、Perl Foundationから資金を受けて、Mooseのドキュメントを沢山書いてくれました。これを読めば十分なんです。分からなければ、Daveに質問すればいいのです。現に、この私でさえ、相手にしてくれました。
CもJavaもやるけど、true/false無くても別に痛くない。人によってマチマチになる点はコーディング規約で縛ればいい。命名規約でも縛ればいい。
自由すぎて困るなら、自分で枠を作ってやればいい。# それがフレームワークの別の側面だと思う
booleanがなくても構わないというのは、すごいですね。そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
$is_valid = true;$is_valid = false;
$is_valid = 1;$is_valid = 0;
上記のコードでは、あきらかに前者の方が理解しやすいです。後者は1という数値が真を表しているのか分かりませんし、0と1だけではなく、ひょっとすると 2,3,4...という数値があるかもしれないという疑念にかられてしまいます。(実際に2以上の値がついたコードで嵌ったことがあります。)
> 人によってマチマチになる点はコーディング規約で縛ればいい。
コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、そういったことを開発前に打ち合わせること自体、時間の無駄だと思います。
確かに欲しい時ありますね。
とはいえ、Cでも、C99まで言語仕様にtrue/falseは無かったのですが、コード規約や共通で使用するマクロで定義されていたから、それほど問題は無かったです。これがakiho氏の考え方ではないでしょうか。
coffe_ataさん、代弁ありがとうございます。
pumipumiponさんは言語仕様にbooleanを入れるべきと言っているように見えたもので。『コード規約や共通で使用するマクロで定義』があれば済む話だと思うんですよね。それがいわゆる業界標準的なものになれば、尚良しでしょうか。
例えば「真は必ず"true"とし、共通ライブラリXに用意した真偽判定関数のisTrue()を使うこと」とか。
となると「0か1ではないコードを書く未熟者が現れる」は「規約を守れないアホの出現」の話になるわけで。そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。# 以上、１点目の解消案。
# ２点目はコーディング規約で、４点目は命名規約で解消可能。# ３点目は笑いどころと受け取りました;-D
君は信じるかい？それとも笑うかい？
http://www.onicos.com/staff/iz/amuse/wapi/wapi.html [onicos.com]
> BOOL foo(); と宣言された Windows API foo() について、>> if(foo() == TRUE)>> は誤りです。やってはならないスタイルです。 なぜかって？理由は、返り値が BOOL と定義された Windows API 関数の中には、 0, 1 以外の値を返す関数が存在するからです(きったねー！)。 よって、以下のように記述しなければならなりません。
よく意味は分からんのだけど、nullと0の意味を混同してない？nullはperlではundefと表現されるので、0とは全く別物。
しかしtrue/falseを1と0で表現するのって、シェルだと意味が逆転するのも初心者を嵌める罠になってるよなー。その影響なのか、関数単位でも0を正常終了、負数を異常終了にする実装も見かけたりするけど・・・
信じるも何も、事実ですよ。# 私の古い知識だと「でした」が正しいか。## 現在どうなっているかは知らない。
＞言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。私はCを使っていた頃から疑問を持っていたけれど、残念なことに多くの人についてはこの批判は正しいと思う。
そもそも、C言語には厳密な意味での真偽値なんてなかったんだよね．JavaとCで比較すると、その違いが良く分かる。
＞そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。$isValid(正当かどうか)っていうように、変数側の命名基準がハッキリしてれば0か1か2かじゃなく"真か偽か"の二択だっていう事は判るだろうし、言語の問題というよりはどっちかというと読む側の"行間を読む"能力の問題じゃないの？
はい。そのとおりです。変数名の命名規則でほぼ判別できます。ただ、true か false のほうが確実ですよね？
一番怖いのは、変数名をだけを見て、読む側が0か1だろうと判別してしまうことです。書く側が未熟で、0か1ではないコードを書く可能性だってあります。その場合、原因に気づけず、多くの時間を費やすかもしれません。
これまでの経緯で分かると思いますが、Perlのbooleanの有無については、必ずこのような議論が発生してしまいます。私はこのようなこと自体が無駄だと思うので、あまりPerlを使わなくなったのです。
＞booleanがなくても構わないというのは、すごいですね。こっちは分かるけど，
＞そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。こっちはどうかなあ．
C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。＃だからif(a = b)みたいな初歩的なエラーが発生したりする。
単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでもそんなに問題にはなりません。
＞ C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。すみません、最初にCって書いちゃったので誤解を与えてしまったようです。正確にはC++ですね。
＞単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも＞そんなに問題にはなりません。
えっと、マクロで置き換えるってCでのコーディングのことですか？
>>コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。>>真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、>>そういったことを開発前に打ち合わせること自体、時間>>の無駄だと思います。はちょっとびっくり。こういうルールは言語毎に一度決めておけば良い訳で長期的には大したコストでは無いと思うのだが？
確かにプロジェクト毎に使うライブラリが異なる場合なんかは若干の増補は必要になるかもしれないがデバッグでパニックとなりコスト爆発なんてことよりははるかにましなんじゃないだろうか？
大体真偽の扱いまで自由にしたのでは、booleanとかがあっても意味が無いのではないかな？
これで何でも解決というわけではないですけど、Perl::Critic [cpan.org]てのがあります。
ちなみに、フォーマッタはPerltidy [sourceforge.net]がよいですね。
本論からは外れるけど、
>程度の差はあれ「型にはめる」ことが重視される
その「程度」が度を過ぎる(ことがすごく多い)のもまた現場での典型的な問題のひとつですね。縛らないとマズイけど、縛りすぎて身動きが取れなくなるのもマズイ。
あと、「重視される」というのも曲者でして、型にはめることが過剰に大好きな(えてして偉い)かたがた「が」重視する、という痛いケースも多いです。
重要なのは「ほどほどに」であることなのですが、現場を離れてる人には加減というものが判らない模様。
> - public, protected, private などの指定ができない。use Attribute::Protectedhttp://search.cpan.org/dist/Attribute-Protected/ [cpan.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の４つ。
- true, false の boolean値を利用できない。
CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ？)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、
sub true() { return 1; }
sub false() { return 0; }
などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラになっていることが多く、可読性が低いものが多い。
- モジュール(クラス)を作る際、いちいち bless をする必要がある
一度覚えれば分かりにくくは無いが、他の言語に比べて余計なコーディングしている感は否めない。また、人によって、$this だったり、$self だったりマチマチなのもいただけない。
- public, protected, private などの指定ができない。
よって、モジュール(クラス)のどのメソッドでも呼び出せる。危険なだけではなく、どれがインターフェースなのか分かりにくく可読性が悪い。
上記が満たされるようになれば、また使いたい言語です。
Re:Perlはもっと評価されていい (スコア:4, 参考になる)
今や、PerlでOOするのなら、ごしごし書きませんよ。MooseやMouseを使えば、
blessなぞ、書く必要もないです。もちろん、boolean等の型指定も可能です。
ここらへんのことが余りにも知られてなくて、JPAが啓発して行こうと考えているのでしょう。
Re:Perlはもっと評価されていい (スコア:1)
MooseやMouseモジュールの存在を知らなかったので、ざっと見てみました。
しかし、結論から言うと、まだ使う気になれないですね…。
MooseやMouseの記述方法が、モジュールではなくPerlの言語として正式に組み込まれるのであれば使う気がおこるのですが、今のところそうではなさそうなので…。
このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。
少なくともアクセサは言語の中に組み込まれるべきだと思います。（使う使わないは別にして）
# MooseやMouseについて、教えていただきありがとうございました。勉強になりました。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
MooseやMouseの記述方法が、モジュールではなくPerlの言語として正式に組み込まれるのであれば使う気がおこるのですが、今のところそうではなさそうなので…。
このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。
少なくともアクセサは言語の中に組み込まれるべきだと思います。
極論すれば、MooseやMouse等を完全にコアに入れたものが、Perl6なんです。
「混乱」等ないと思いますが、あるとすれば非英語圏の人だけだと思います。
Mooseのメインメンテナである、Dave Rolsky氏は（「Mason」という本の著者で有名ですが）
は、Perl Foundationから資金を受けて、Mooseのドキュメントを沢山書いてくれました。
これを読めば十分なんです。分からなければ、Daveに質問すればいいのです。現に、
この私でさえ、相手にしてくれました。
Re:Perlはもっと評価されていい (スコア:2, すばらしい洞察)
CもJavaもやるけど、true/false無くても別に痛くない。
人によってマチマチになる点はコーディング規約で縛ればいい。
命名規約でも縛ればいい。
自由すぎて困るなら、自分で枠を作ってやればいい。
# それがフレームワークの別の側面だと思う
Re:Perlはもっと評価されていい (スコア:2, すばらしい洞察)
booleanがなくても構わないというのは、すごいですね。
そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
$is_valid = true;
$is_valid = false;
$is_valid = 1;
$is_valid = 0;
上記のコードでは、あきらかに前者の方が理解しやすいです。後者は1という数値が真を表しているのか分かりませんし、0と1だけではなく、ひょっとすると 2,3,4...という数値があるかもしれないという疑念にかられてしまいます。(実際に2以上の値がついたコードで嵌ったことがあります。)
> 人によってマチマチになる点はコーディング規約で縛ればいい。
コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、そういったことを開発前に打ち合わせること自体、時間の無駄だと思います。
Re:Perlはもっと評価されていい (スコア:1)
確かに欲しい時ありますね。
とはいえ、Cでも、C99まで言語仕様にtrue/falseは無かったのですが、
コード規約や共通で使用するマクロで定義されていたから、
それほど問題は無かったです。
これがakiho氏の考え方ではないでしょうか。
Re:Perlはもっと評価されていい (スコア:1)
coffe_ataさん、代弁ありがとうございます。
pumipumiponさんは言語仕様にbooleanを入れるべきと言っているように見えたもので。
『コード規約や共通で使用するマクロで定義』があれば済む話だと思うんですよね。
それがいわゆる業界標準的なものになれば、尚良しでしょうか。
例えば「真は必ず"true"とし、共通ライブラリXに用意した真偽判定関数のisTrue()を使うこと」とか。
となると「0か1ではないコードを書く未熟者が現れる」は
「規約を守れないアホの出現」の話になるわけで。
そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。
# 以上、１点目の解消案。
# ２点目はコーディング規約で、４点目は命名規約で解消可能。
# ３点目は笑いどころと受け取りました;-D
Re:Perlはもっと評価されていい (スコア:2, 参考になる)
君は信じるかい？それとも笑うかい？
http://www.onicos.com/staff/iz/amuse/wapi/wapi.html [onicos.com]
> BOOL foo(); と宣言された Windows API foo() について、
>
> if(foo() == TRUE)
>
> は誤りです。やってはならないスタイルです。 なぜかって？理由は、返り値が BOOL と定義された Windows API 関数の中には、 0, 1 以外の値を返す関数が存在するからです(きったねー！)。 よって、以下のように記述しなければならなりません。
0か1ではないコードを書く未熟者が現れる (スコア:0)
1 ⇒ true
0 ⇒ null
-1 ⇒ false
として扱ってました。
Re: (スコア:0)
よく意味は分からんのだけど、nullと0の意味を混同してない？
nullはperlではundefと表現されるので、0とは全く別物。
しかしtrue/falseを1と0で表現するのって、シェルだと意味が逆転するのも
初心者を嵌める罠になってるよなー。その影響なのか、関数単位でも
0を正常終了、負数を異常終了にする実装も見かけたりするけど・・・
Re:Perlはもっと評価されていい (スコア:1)
信じるも何も、事実ですよ。
# 私の古い知識だと「でした」が正しいか。
## 現在どうなっているかは知らない。
Cの話だけど (スコア:0)
昔は基本として仕込まれてたんです。
# 8 bitCPU 以下の環境とかでは、ヤバイの多かった。
if (hoge == true)
なんてコードの書き方の人をよくみかけるので、
今時は誰も教えてないのかって思ってます。
本当はこう書くんです!
if (!!hoge)
…とやったら、不評だった。
Re: (スコア:0)
>「規約を守れないアホの出現」の話になるわけで。
> そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。
あなたの方針では、「BOOLと定義しつつTRUE,FALSEつまり1,0以外の値を返す」未熟者のマイクロソフト社とその製品は排除か再教育となりますが、それは現実的ですか？
やはり言語レベルで決めるべきものはあるのですし、それはCに限った話ではありません。
Re:Perlはもっと評価されていい (スコア:1)
このような書き方をすべきでないことは、Cプログラマにとっては(WindowsAPIに限らず)常識ですよ。
IPAのコーディング作法ガイドにも「真の値と等しいかどうかを調べてはならない」と言うのがあります。
Re: (スコア:0)
Re:Perlはもっと評価されていい (スコア:1)
＞言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。
私はCを使っていた頃から疑問を持っていたけれど、
残念なことに多くの人についてはこの批判は正しいと思う。
そもそも、C言語には厳密な意味での真偽値なんてなかったんだよね．
JavaとCで比較すると、その違いが良く分かる。
Re: (スコア:0)
Re: (スコア:0)
＞そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
$isValid(正当かどうか)っていうように、変数側の命名基準がハッキリしてれば
0か1か2かじゃなく"真か偽か"の二択だっていう事は判るだろうし、言語の問題というよりはどっちかというと
読む側の"行間を読む"能力の問題じゃないの？
Re:Perlはもっと評価されていい (スコア:1)
はい。そのとおりです。
変数名の命名規則でほぼ判別できます。
ただ、true か false のほうが確実ですよね？
一番怖いのは、変数名をだけを見て、読む側が0か1だろうと判別してしまうことです。
書く側が未熟で、0か1ではないコードを書く可能性だってあります。その場合、原因に気づけず、多くの時間を費やすかもしれません。
これまでの経緯で分かると思いますが、Perlのbooleanの有無については、必ずこのような議論が発生してしまいます。
私はこのようなこと自体が無駄だと思うので、あまりPerlを使わなくなったのです。
Re:Perlはもっと評価されていい (スコア:1)
# そういう話ではない？
Re: (スコア:0)
つまり言語の問題です。
Re: (スコア:0)
＞booleanがなくても構わないというのは、すごいですね。
こっちは分かるけど，
＞そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
こっちはどうかなあ．
C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、
数値をif文の判定に流用したりできるんですよ。
＃だからif(a = b)みたいな初歩的なエラーが発生したりする。
単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも
そんなに問題にはなりません。
Re:Perlはもっと評価されていい (スコア:1)
＞ C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。
すみません、最初にCって書いちゃったので誤解を与えてしまったようです。
正確にはC++ですね。
＞単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも
＞そんなに問題にはなりません。
えっと、マクロで置き換えるってCでのコーディングのことですか？
Re: (スコア:0)
>>コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
>>真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、
>>そういったことを開発前に打ち合わせること自体、時間
>>の無駄だと思います。
はちょっとびっくり。
こういうルールは言語毎に一度決めておけば良い訳で
長期的には大したコストでは無いと思うのだが？
確かにプロジェクト毎に使うライブラリが異なる場合なんかは
若干の増補は必要になるかもしれないが
デバッグでパニックとなりコスト爆発なんてことよりは
はるかにましなんじゃないだろうか？
大体真偽の扱いまで自由にしたのでは、
booleanとかがあっても意味が無いのではないかな？
Re: (スコア:0)
> 長期的には大したコストでは無いと思うのだが？
何社も集まるプロジェクトではかなり大変だよ。
コーディング規約を決めること自体がけっこうな手間だし、こういう基本的なところでなじみのないルールを強制されるのは負担になるし、ミスによる意図的でない逸脱があるとトラブルの元。
場合によってはライブラリにラッパーをかませる必要もある。これがまた大変なんだ。
言語で決まっていてコンパイラが弾いてくれるのとは雲泥の差です。
Re: (スコア:0)
これで何でも解決というわけではないですけど、Perl::Critic [cpan.org]てのがあります。
ちなみに、フォーマッタはPerltidy [sourceforge.net]がよいですね。
Re: (スコア:0)
そんな大規模なものにPerlって適しているのかな...
なんか用途が違うような気がして...
本人が使いたくて使う分にはいいんだけどね。
Re: (スコア:0)
はまっている様にしか見えないのだが、私だけだろうか.....
Re: (スコア:0)
> はまっている様にしか見えないのだが、私だけだろうか.....
たぶんあなただけだと思います。
その証拠に、perlでのコードの書き方を例示した人が誰もいません。
Re: (スコア:0)
sub true { 1 }
sub false { 0 }
# なんだそりゃ
Re: (スコア:0)
何を証明しているのか理解できなっかったので、解説してもらえるとありがたい。
で、perlってフィーリングで書くから、同じ様な動作のコード書いても同じにならないのだけど。
いわゆるperlの書き方って人それぞれで、まあ動けば何でも良い感じだと思っていたのだけど、
スクリプト言語まで、そんなに型にはめないといけないのだろうか。
Re: (スコア:0)
> で、perlってフィーリングで書くから、同じ様な動作のコード書いても同じにならないのだけど。
をチームプログラミングにおけるPerlの欠点だと考えていて、氏は実例も挙げているんですけれども、
答えとしては、#1547315の
> > - public, protected, private などの指定ができない。
> use Attribute::Protected
> http://search.cpan.org/dist/Attribute-Protected/ [cpan.org]
ような具体的かつなるべく標準的な返答を望んでいます。
> いわゆるperlの書き方って人それぞれで、まあ動けば何でも良い感じだと思っていたのだけ
Re: (スコア:0)
本論からは外れるけど、
>程度の差はあれ「型にはめる」ことが重視される
その「程度」が度を過ぎる(ことがすごく多い)のもまた現場での典型的な問題のひとつですね。
縛らないとマズイけど、縛りすぎて身動きが取れなくなるのもマズイ。
あと、「重視される」というのも曲者でして、
型にはめることが過剰に大好きな(えてして偉い)かたがた「が」重視する、という痛いケースも多いです。
重要なのは「ほどほどに」であることなのですが、
現場を離れてる人には加減というものが判らない模様。
Re: (スコア:0)
> - public, protected, private などの指定ができない。
use Attribute::Protected
http://search.cpan.org/dist/Attribute-Protected/ [cpan.org]