アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の4つ。
- 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ではないコードを書く未熟者が現れる」は「規約を守れないアホの出現」の話になるわけで。そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。# 以上、1点目の解消案。
# 2点目はコーディング規約で、4点目は命名規約で解消可能。# 3点目は笑いどころと受け取りました;-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 以外の値を返す関数が存在するからです(きったねー!)。 よって、以下のように記述しなければならなりません。
信じるも何も、事実ですよ。# 私の古い知識だと「でした」が正しいか。## 現在どうなっているかは知らない。
>言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。私はCを使っていた頃から疑問を持っていたけれど、残念なことに多くの人についてはこの批判は正しいと思う。
そもそも、C言語には厳密な意味での真偽値なんてなかったんだよね.JavaとCで比較すると、その違いが良く分かる。
>そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。$isValid(正当かどうか)っていうように、変数側の命名基準がハッキリしてれば0か1か2かじゃなく"真か偽か"の二択だっていう事は判るだろうし、言語の問題というよりはどっちかというと読む側の"行間を読む"能力の問題じゃないの?
はい。そのとおりです。変数名の命名規則でほぼ判別できます。ただ、true か false のほうが確実ですよね?
一番怖いのは、変数名をだけを見て、読む側が0か1だろうと判別してしまうことです。書く側が未熟で、0か1ではないコードを書く可能性だってあります。その場合、原因に気づけず、多くの時間を費やすかもしれません。
これまでの経緯で分かると思いますが、Perlのbooleanの有無については、必ずこのような議論が発生してしまいます。私はこのようなこと自体が無駄だと思うので、あまりPerlを使わなくなったのです。
> C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。すみません、最初にCって書いちゃったので誤解を与えてしまったようです。正確にはC++ですね。
>単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも>そんなに問題にはなりません。
えっと、マクロで置き換えるってCでのコーディングのことですか?
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(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 ステップごとに内容のコメントを書いていく人やわざわざ難解な記述 (単項演算子を使うとかいうレベルではなく) にする人はいますので、そこは言語の責任ではないように思えます。
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分ココです。三項演算子だけじゃなくて、
read or die
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面食らうんですよ。。。年寄りには
if (read == FALSE) then die # 架空の言語
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗)
>私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だって>foo_2は「長い」んだもん。
と言えるのは、foo_1がすんなり読み下せるヒトの場合だと思うのです。慣れの問題だとは思うんですがperlの場合、こゆ『慣れ』を要する部分が他言語よりも多い気がするのと前の投稿で書いたように『慣れる前に放り出したくなる』のが私的にはボトルネックでした。
「read または die」と読むと分からなくなりますが、「read さもなくば die」と読むと分かるんじゃないですか?
>いずれにせよ、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は例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
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;}
これはこれで賛否ありそうですけど(^^;;
もう、この手のはFUD扱いしても良いんじゃないかな。
・TMTOWTDI (There's More Than One Way To Do It.) で書き方が多彩・暗号のような正規表現が頻出・$,@,%等の変数接頭辞
あたりが挙げられるけれど、別にそれは欠点ではないし(変数接頭辞はむしろ読みやすい)・純粋なオブジェクト指向ではないとか、殆ど言いがかり
・そもそもPerlの基礎知識が足りない・そのソースの書き方が汚い
という本質的な理由を、Perlのせいにしてるのが殆どじゃないの?
なんて指摘するとヒステリー起こす人がいるんだけど別にPerlに慣れてないのは恥ずかしい事じゃないわけで、使い込んでみたら意外と良い物だよ。
Perlはゴミ言語、そう思っていた時期が私にもありました。今ではガラクタ出力機だと思って愛用してます。
今ではガラクタ出力機だと思って愛用してます。
"ガラクタ出力機"ってのは本当にぴったりだなぁ。もちろん良い意味で。
あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
それなりに一通りの言語触ってきてそれぞれ向き不向きがあるのは分かるけど、とりあえずちょっとしたアイディアとかを試す時の楽さでいえばPerlが一番楽ちんだなぁ。言語のポリシーにもブレがなくていい。
アバウトにアバウトなプログラムが書けてアバウトに動かしても"きちんと"アバウトに動く、そんな感じ。もちろんキッチリとキッチリとしたコードを書いてキッチリと動かすこともできる。ラリーウォールの言語仕様に対するバランス感覚が天才的なんだと思う。ラクダ本を読むと特に。
# と、M1中だがあえてコメント
>あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
この時代、GUI が必要ならウェブシステムにしちゃえばいいんですよ。
最近は、グダグダなPerlもありかなと思うようになりました。
Perlって元々行儀の良い言語じゃなくて、生まれも育ちも悪い。それでも熱い魂は持っている、Punkな言語なんですよね。
おバカなプログラマであっても、只のノイズにしか見えないコードしか書けなくても、快く受け入れてくれる。教科書に書かれたようなコードより、勢いのある熱いコードが似合う。そんな言語だと思うようになりました。
# 変態技巧を凝らしたコードも好きですけど!
正規表現については言い掛かりだと思うけど、(正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい)「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。特に、ビジネスでは、
個人でちょこちょこやるにはこんな気軽な環境は無いけど、仕事なら相応のフレームワークを加えた方がいいんじゃないかと、
「そのソースの書き方が汚い」についても、フレームワーク導入で解決すべき事だと思うな。自分のスタイルでないソースは読み難くて汚く感じるもんだよ。で、それが「書き方が多彩」と言う「欠点」と言われるわけだから、
> 別にPerlに慣れてな
正規表現が無ければ、オートマトンで書けばいいじゃない。
> > 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、> うわっ、凄い上から目線!
そりゃ、ある言語が使える人は、使えない人よりも上でしょ?# どういう基準で上かはよく分からんが
「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「Rubyワカンネ」「知らなきゃ読めないよ」「Pythonイミフ」「覚えりゃ読めるよ」ってのと同じ話なんだけど、これらも上から目線ですかね
> 「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「知らなくても別に良いじゃん」って、何処が?
#1546737 [srad.jp]の以下の部分が「上から目線」だと言ってる事は読み取れるよね?
> ・そもそもPerlの基礎知識が足りない> ・そのソースの書き方が汚い>> という本質的な理由を、Perlのせいにしてるのが殆どじゃないの?>> なんて指摘するとヒステリー起こす人がいるんだけど> 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
Perlに難を示された場合に、『基礎知識が足りない』『書き方が汚い』と返すのが駄目駄目なの。
その前に挙げられていたのは枝葉の話だけど、それらは確かにPerlの特徴として存在するものであって、それぞれに、それが問題にならないようにする解も用意されてるよね?
それらを示して解決に導くのではなく、「そんなの問題ではない」と客観視の出来ない高慢な態度で、(相手が問題視してる部分に「俺は問題だと思わない」と返すのは論外でしょ)「お前の知識や書き方が至らないだけ」と切り捨ててしまって、挙句、『慣れてないのは恥ずかしい事じゃない』等と言う。
違う違う、Perlにはちゃんと解法が用意されてるから。なのに、それを教えられなかっただけでしょ?慣れてなくて上手く教えられないのは恥ずかしい事じゃないけどさ。
そりゃ「Perlは使えねぇな」と言う評価になりますよねぇ。本当は、その場その場で妥当な解決策を提示出来ない、その人に対する評価(このPerler使えねぇな)であるべきなんですけど、その人は「Perlはそーゆーもんだ」と言う態度なので、その周囲ではPerlの評価が下がってしまう。
ウォーターフォール開発の大好きな日本の職場環境では、Perl のような Quick Hack 言語は受け入れられにくいと思う技術的に優れているものが必ずしも普及する訳ではないのはよく解っているはず自分もテキスト処理をしたいときに個人的に Perl 使っているだけで、他の人に使ってもらおうとは思わない(メーカー系 IT 企業だけど Unix 的な文化からは程遠いから)
それを使ってもらえるようにするのがこの会の趣旨でもあるんでしょう。僕はPerlの使い手ではないですが。
いや, 特殊例じゃないと思います.
みそもくそもひっくるめた, いわゆるプログラマでOOを理解している人はおおよそ1割弱程度. さらに実際の業務システムなんかで実践できる人は, 理解している人の7~8割程度ってところってのが実感です. いや, OOどころか関数/サブルーチンでさえ, 出来合いの物を使うこと以外出来ないのが全体の7~8割強といったところか.
エンドプログラマは自前の関数を一切作らない, とかの無茶な前提を設けないと, Perlに限らずどんな言語であっても業務システム構築に使えるかどうかは評価できないと思います. 多くの場合, ある言語が使えるかどうかってのは評価者のレベルから見ていることが多いですけど, 他人に使わせるために評価するのであれば, どん底レベルから見ておかないと後で尻拭いが回ってきて泣きをみる可能性が高いです.
これが開発メンバーが数人から10人ぐらいの内製プロジェクトに限れば, メンバーの力量も分かるしコードレビューを行うなんてことも可能ですけど. Perlでシステム開発とかって話だと, このくらいの規模が限界じゃないかな.
Perlの場合、最初から大規模開発を目指していることはあまりなくて、1.優秀なプログラマが「こんなのあったら便利だよね」って片手間に作る2.使い勝手に難を感じたプログラマが「こんな機能も付け加えてみよう」と改修する3.厨房が「こっちにも使えんじゃねー?」と、forkさせる4.「あれ?うごかねーよ」と、その場で改修されて放置される5.PMが「そろそろ統一しようよ」と言い出してforkしまくったソースを結合する・・・・・・なんて感じで大規模化するので、メンバーの力量とかそれ以前の問題を抱えてるかも。
# Perlは適当に書いただけで動くとっつきやすさがこういう使われ方を招いているんだろうなぁ・・・# そろそろ「望ましくない」とされてる構文は潰した方がいいのではないかと。
まだC++のANSI標準が規定されるよりも前に、『先行技術開発/調査』ってコトで『オブジェクト指向』にかかわったことがあるんですが。
OOP以前に、OOA(オブジェクト指向分析)、OOD(オブジェクト指向設計)がちゃんと出来てないとオブジェクトオリエンテッドなプログラミングって難しいんだろうな、と感じてました。私はperlはPerl4で止まっていて、なにがしかちょっと書くならRubyなんですが、トータル1000ステップ以下のちょっとしたツールを書くのに、何も考えず(行き当たりばったりで^^;)コーディングしたらRubyで書いてもPerl4のようなソースになります(恥)
perlは、(良きにつけ悪しきにつけ)行き当たりばったりなコードが書きやすい言語ですから(汗)、投稿されているような現場に行き当たったんじゃないかと拝察いたします。
ps. ところで、ホントにオブジェクト指向じゃなきゃだめなんですかね?K&Rな時代の人間からすると、『別にOOじゃなくたって書けら(暴言)』とか思わないでもないんですけど(をゐ)
設計さえOOなら, あとはどんな言語でも工夫次第, と思います.
逆に設計は太古のフローチャートとレコード一覧. プログラムはOOPでなんてのは勘弁してほしいです.
# 私はそれで会社を辞めました
ちょっとお返事が遅くなったんで反応してくれるひとがいるかイマイチ不安ですが、せっかくなんで書いておこう(汗)
>設計さえOOなら, あとはどんな言語でも工夫次第, と思います.
設計はOOで、実装は“生のC(ダメぇ、赤ちゃんが出来ちゃうぅっ)”なんてどうやるんだろう?と思ったんですが。こんな感じの考え方であってますでしょうか?
継承どうしよう?とか、ガベコレとか実現難しそうだよなぁ、、、とか(汗)丸一日考えた割には練れてませんがorz
蛇足:もっと過激にObject Oriented Assembler なんてのもアリなんですかね?(^^;
昔、構造化アセンブラってのを考えていた時期があって、まぁ結局当時はスキルが未熟だったので、http://home.g04.itscom.net/alpha/archive/aspp.lzh [itscom.net]のようなフィルタ作って遊んでた程度なんですが。。。# 手前味噌ながら単純なプログラムの割りに案外役にたったんですよぉ(^^;
ここまでするなら素直にOOP言語使えよ、とは思いますが(苦笑)
メジャーな実装としてはGTKでも読めばいんじゃないかとおもいます。例外やRTTI(のようなもの)もあります
ここまでするなら(ry
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の4つ。
- 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ではないコードを書く未熟者が現れる」は
「規約を守れないアホの出現」の話になるわけで。
そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。
# 以上、1点目の解消案。
# 2点目はコーディング規約で、4点目は命名規約で解消可能。
# 3点目は笑いどころと受け取りました;-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 以外の値を返す関数が存在するからです(きったねー!)。 よって、以下のように記述しなければならなりません。
Re:Perlはもっと評価されていい (スコア:1)
信じるも何も、事実ですよ。
# 私の古い知識だと「でした」が正しいか。
## 現在どうなっているかは知らない。
Re:Perlはもっと評価されていい (スコア:1)
このような書き方をすべきでないことは、Cプログラマにとっては(WindowsAPIに限らず)常識ですよ。
IPAのコーディング作法ガイドにも「真の値と等しいかどうかを調べてはならない」と言うのがあります。
Re:Perlはもっと評価されていい (スコア:1)
>言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。
私はCを使っていた頃から疑問を持っていたけれど、
残念なことに多くの人についてはこの批判は正しいと思う。
そもそも、C言語には厳密な意味での真偽値なんてなかったんだよね.
JavaとCで比較すると、その違いが良く分かる。
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:Perlはもっと評価されていい (スコア:1)
> C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。
すみません、最初にCって書いちゃったので誤解を与えてしまったようです。
正確にはC++ですね。
>単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも
>そんなに問題にはなりません。
えっと、マクロで置き換えるってCでのコーディングのことですか?
Re: (スコア:0)
はまっている様にしか見えないのだが、私だけだろうか.....
Re: (スコア:0)
> はまっている様にしか見えないのだが、私だけだろうか.....
たぶんあなただけだと思います。
その証拠に、perlでのコードの書き方を例示した人が誰もいません。
Re:Perlはもっと評価されていい (スコア:1, 興味深い)
最近のPerlはそうでもない気がします。
Re:Perlはもっと評価されていい (スコア:2, すばらしい洞察)
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
#ビール片手に一ヶ月前に書いた自分のコードは(ry
Re:Perlはもっと評価されていい (スコア:2)
Syntax errorと中の小人さんがおっしゃっております。
もちろん私にも読めません。
spam嫌いなbeefeater
でも豚肉は好き
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:Perlはもっと評価されていい (スコア:1)
ご意見ありがとうございます
>三項演算子がマズイとすれば優先順位が見づらいことだろう。
自己分析まではしたことがなかったんですが、私が引っかかってるのは多分コ
コです。三項演算子だけじゃなくて、
なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。
解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面
食らうんですよ。。。年寄りには
のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗)
>私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だって
>foo_2は「長い」んだもん。
と言えるのは、foo_1がすんなり読み下せるヒトの場合だと思うのです。
慣れの問題だとは思うんですがperlの場合、こゆ『慣れ』を要する部分が他言
語よりも多い気がするのと前の投稿で書いたように『慣れる前に放り出したく
なる』のが私的にはボトルネックでした。
♪潔くカッコよく生きてゆこう
Re:Perlはもっと評価されていい (スコア:1)
「read または die」と読むと分からなくなりますが、
「read さもなくば die」と読むと分かるんじゃないですか?
1を聞いて0を知れ!
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:Perlはもっと評価されていい (スコア:1)
私は、条件を満たさなかった場合であることを明示するため、else節を入れる方が良いように思います。このような一行しかなければ明白ですけど、else節となるべき部分が長くなる場合には分かりにくくなると思います。
Re:Perlはもっと評価されていい (スコア:1)
>ifは例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
1.
『例外パターンを排除してから正常系の処理』でポリシー統一するというのも
方法のひとつですが
あたりが気にはなります。
# 気になるだけです。私が組んで、こう書く場合もけっこう多いです
2.
perlの話だと、後置ifは、このポリシーの時使いやすいですね
(read or dieの話とかいろいろ書きましたが、この記述は素直にいいなと思い
ます)
>変数に入れてすぐにreturnするなら、直接書く
3.
(業務での話なので、ややオフトピですが)残念なコトに
この記述でさえ混乱するメンバーとかいたりするんですよねorz
4.
例えば、コーディング規約で、単純に『(読解スキルの低いヤツもいるんだか
ら)三項演算子は使用不可』なんてすると以下のようなコードが出てきたりし
ます(^^;
これはこれで賛否ありそうですけど(^^;;
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
もう、この手のはFUD扱いしても良いんじゃないかな。
・TMTOWTDI (There's More Than One Way To Do It.) で書き方が多彩
・暗号のような正規表現が頻出
・$,@,%等の変数接頭辞
あたりが挙げられるけれど、別にそれは欠点ではないし(変数接頭辞はむしろ読みやすい)
・純粋なオブジェクト指向ではない
とか、殆ど言いがかり
・そもそもPerlの基礎知識が足りない
・そのソースの書き方が汚い
という本質的な理由を、Perlのせいにしてるのが殆どじゃないの?
なんて指摘するとヒステリー起こす人がいるんだけど
別にPerlに慣れてないのは恥ずかしい事じゃないわけで、使い込んでみたら意外と良い物だよ。
Perlはゴミ言語、そう思っていた時期が私にもありました。
今ではガラクタ出力機だと思って愛用してます。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
"ガラクタ出力機"ってのは本当にぴったりだなぁ。もちろん良い意味で。
あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
それなりに一通りの言語触ってきてそれぞれ向き不向きがあるのは分かるけど、とりあえずちょっとしたアイディアとかを試す時の楽さでいえばPerlが一番楽ちんだなぁ。言語のポリシーにもブレがなくていい。
アバウトにアバウトなプログラムが書けてアバウトに動かしても"きちんと"アバウトに動く、そんな感じ。もちろんキッチリとキッチリとしたコードを書いてキッチリと動かすこともできる。ラリーウォールの言語仕様に対するバランス感覚が天才的なんだと思う。ラクダ本を読むと特に。
# と、M1中だがあえてコメント
Re:Perlはもっと評価されていい (スコア:1)
>あとはtkとかGDとかイメージマジック使わずに簡単なGUIが作れてグラフ作図や図形描画ができれば最高のがらくたメーカーなんだがなぁ。マルチプラットホームだし。
この時代、GUI が必要ならウェブシステムにしちゃえばいいんですよ。
Re:Perlはもっと評価されていい (スコア:3, 興味深い)
最近は、グダグダなPerlもありかなと思うようになりました。
Perlって元々行儀の良い言語じゃなくて、生まれも育ちも悪い。
それでも熱い魂は持っている、Punkな言語なんですよね。
おバカなプログラマであっても、只のノイズにしか見えない
コードしか書けなくても、快く受け入れてくれる。
教科書に書かれたようなコードより、勢いのある熱いコードが似合う。
そんな言語だと思うようになりました。
# 変態技巧を凝らしたコードも好きですけど!
Re:Perlはもっと評価されていい (スコア:3, すばらしい洞察)
perl が批難されてるのは、
「使えない」からじゃなくって、
「難解」だからだ。
本当に perl を批難してる人は、perl が使えない等と言わない。
わからないのは、恥ずかしい事じゃないだと?
的外れも甚だしい。
たとえば、perl ベストプラクティスって本を読んでみればわかるが、
やってはいけない事、使ってはいけない方法が大量に書いてある。
そしてそれらは過去の互換性のために、未だに使用できる状態だとわかる。
再利用を意図されていない他人のコードを再利用する場合には、
最低でも、こんな本に書かれている事のすべてに精通している必要がある。
# もしくは、自力でそれら問題を看破する必要がある。
ほぼ並の人が解析できる量を、遙かに超えた自由度をもつ構文で、
必要とあらば使ってはいけないと言われる機能を自由に使う事ができ、
# 使ってはいけないと言われているんだから、当然、使い方など憶えてない。
同じ目的に複数の記法があり、書き手の好みによって自由に選択する事ができる言語を、
難しいと言わずしてなんて言えばいいんだ?
Perlが評価されない理由が理解出来た (スコア:0)
正規表現については言い掛かりだと思うけど、
(正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい)
「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。
特に、ビジネスでは、
個人でちょこちょこやるにはこんな気軽な環境は無いけど、
仕事なら相応のフレームワークを加えた方がいいんじゃないかと、
「そのソースの書き方が汚い」についても、
フレームワーク導入で解決すべき事だと思うな。
自分のスタイルでないソースは読み難くて汚く感じるもんだよ。
で、それが「書き方が多彩」と言う「欠点」と言われるわけだから、
> 別にPerlに慣れてな
Re:Perlが評価されない理由が理解出来た (スコア:1, 興味深い)
>(正規表現で処理したいからするのであって、嫌なら別の方法で処理すればいい)
これはそうとも言えないんだけども。
>「書き方が多彩」がある意味で欠点とされるのは仕方無いと思いますよ。
なんというか、perl擁護派は昔の非構造化BASIC擁護派と同じタイプの主張をしているんだよね。
手軽さ、機能の豊富さを誇り、欠点は「君が慣れてないから」で片付ける。
perlはあれもこれも出来る、(perlはXXが難しい、面倒くさいという意見に対して)それはperlに慣れていないだけ、俺には簡単
Re: (スコア:0)
正規表現が無ければ、オートマトンで書けばいいじゃない。
Re: (スコア:0)
> > 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
> うわっ、凄い上から目線!
そりゃ、ある言語が使える人は、使えない人よりも上でしょ?
# どういう基準で上かはよく分からんが
「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「Rubyワカンネ」「知らなきゃ読めないよ」
「Pythonイミフ」「覚えりゃ読めるよ」
ってのと同じ話なんだけど、これらも上から目線ですかね
Re:Perlが評価されない理由が理解出来た (スコア:2, すばらしい洞察)
> 「知らなくても別に良いじゃん」ってのがそんな反応するほど上から目線ですかねぇ
「知らなくても別に良いじゃん」って、何処が?
#1546737 [srad.jp]の以下の部分が「上から目線」だと言ってる事は読み取れるよね?
> ・そもそもPerlの基礎知識が足りない
> ・そのソースの書き方が汚い
>
> という本質的な理由を、Perlのせいにしてるのが殆どじゃないの?
>
> なんて指摘するとヒステリー起こす人がいるんだけど
> 別にPerlに慣れてないのは恥ずかしい事じゃないわけで、
Perlに難を示された場合に、
『基礎知識が足りない』『書き方が汚い』と返すのが駄目駄目なの。
その前に挙げられていたのは枝葉の話だけど、
それらは確かにPerlの特徴として存在するものであって、
それぞれに、それが問題にならないようにする解も用意されてるよね?
それらを示して解決に導くのではなく、
「そんなの問題ではない」と客観視の出来ない高慢な態度で、
(相手が問題視してる部分に「俺は問題だと思わない」と返すのは論外でしょ)
「お前の知識や書き方が至らないだけ」と切り捨ててしまって、
挙句、『慣れてないのは恥ずかしい事じゃない』等と言う。
違う違う、Perlにはちゃんと解法が用意されてるから。
なのに、それを教えられなかっただけでしょ?
慣れてなくて上手く教えられないのは恥ずかしい事じゃないけどさ。
そりゃ「Perlは使えねぇな」と言う評価になりますよねぇ。
本当は、その場その場で妥当な解決策を提示出来ない、
その人に対する評価(このPerler使えねぇな)であるべきなんですけど、
その人は「Perlはそーゆーもんだ」と言う態度なので、
その周囲ではPerlの評価が下がってしまう。
Re: (スコア:0)
> # どういう基準で上かはよく分からんが
分らないまま言い切る言語センスが凄い。
Re:Perlはもっと評価されていい (スコア:1, 興味深い)
ウォーターフォール開発の大好きな日本の職場環境では、Perl のような Quick Hack 言語は
受け入れられにくいと思う
技術的に優れているものが必ずしも普及する訳ではないのはよく解っているはず
自分もテキスト処理をしたいときに個人的に Perl 使っているだけで、他の人に
使ってもらおうとは思わない
(メーカー系 IT 企業だけど Unix 的な文化からは程遠いから)
Re:Perlはもっと評価されていい (スコア:2, すばらしい洞察)
それを使ってもらえるようにするのがこの会の趣旨でもあるんでしょう。僕はPerlの使い手ではないですが。
Re: (スコア:0)
Javaと違って今のperlは内部UTF8で処理されるから色々楽。
JavaだとUTF16の一部の文字の扱いが面倒で・・・
# でも新たに要求されるスキルは多いと思うが。
なのにビジネス用途だと尻込する人多いんだよね。
特にえらいさん。
Re:驚いた (スコア:2, 興味深い)
いや, 特殊例じゃないと思います.
みそもくそもひっくるめた, いわゆるプログラマでOOを理解している人はおおよそ1割弱程度. さらに実際の業務システムなんかで実践できる人は, 理解している人の7~8割程度ってところってのが実感です. いや, OOどころか関数/サブルーチンでさえ, 出来合いの物を使うこと以外出来ないのが全体の7~8割強といったところか.
エンドプログラマは自前の関数を一切作らない, とかの無茶な前提を設けないと, Perlに限らずどんな言語であっても業務システム構築に使えるかどうかは評価できないと思います. 多くの場合, ある言語が使えるかどうかってのは評価者のレベルから見ていることが多いですけど, 他人に使わせるために評価するのであれば, どん底レベルから見ておかないと後で尻拭いが回ってきて泣きをみる可能性が高いです.
これが開発メンバーが数人から10人ぐらいの内製プロジェクトに限れば, メンバーの力量も分かるしコードレビューを行うなんてことも可能ですけど. Perlでシステム開発とかって話だと, このくらいの規模が限界じゃないかな.
Re:驚いた (スコア:1, すばらしい洞察)
Perlの場合、最初から大規模開発を目指していることはあまりなくて、
1.優秀なプログラマが「こんなのあったら便利だよね」って片手間に作る
2.使い勝手に難を感じたプログラマが「こんな機能も付け加えてみよう」と改修する
3.厨房が「こっちにも使えんじゃねー?」と、forkさせる
4.「あれ?うごかねーよ」と、その場で改修されて放置される
5.PMが「そろそろ統一しようよ」と言い出してforkしまくったソースを結合する
・・・・・・
なんて感じで大規模化するので、メンバーの力量とかそれ以前の問題を抱えてるかも。
# Perlは適当に書いただけで動くとっつきやすさがこういう使われ方を招いているんだろうなぁ・・・
# そろそろ「望ましくない」とされてる構文は潰した方がいいのではないかと。
Re:驚いた (スコア:2, 興味深い)
まだC++のANSI標準が規定されるよりも前に、『先行技術開発/調査』ってコト
で『オブジェクト指向』にかかわったことがあるんですが。
OOP以前に、OOA(オブジェクト指向分析)、OOD(オブジェクト指向設計)がちゃ
んと出来てないとオブジェクトオリエンテッドなプログラミングって難しいん
だろうな、と感じてました。
私はperlはPerl4で止まっていて、なにがしかちょっと書くならRubyなんです
が、トータル1000ステップ以下のちょっとしたツールを書くのに、何も考えず
(行き当たりばったりで^^;)コーディングしたらRubyで書いてもPerl4のような
ソースになります(恥)
perlは、(良きにつけ悪しきにつけ)行き当たりばったりなコードが書きやすい
言語ですから(汗)、投稿されているような現場に行き当たったんじゃないかと
拝察いたします。
ps. ところで、ホントにオブジェクト指向じゃなきゃだめなんですかね?
K&Rな時代の人間からすると、『別にOOじゃなくたって書けら(暴言)』とか思
わないでもないんですけど(をゐ)
♪潔くカッコよく生きてゆこう
Re:驚いた (スコア:1)
設計さえOOなら, あとはどんな言語でも工夫次第, と思います.
逆に設計は太古のフローチャートとレコード一覧. プログラムはOOPでなんてのは勘弁してほしいです.
# 私はそれで会社を辞めました
Re:驚いた (スコア:1)
ちょっとお返事が遅くなったんで反応してくれるひとがいるかイマイチ不安で
すが、せっかくなんで書いておこう(汗)
>設計さえOOなら, あとはどんな言語でも工夫次第, と思います.
設計はOOで、実装は“生のC(ダメぇ、赤ちゃんが出来ちゃうぅっ)”なんてど
うやるんだろう?と思ったんですが。
こんな感じの考え方であってますでしょうか?
そのインスタンスへのハンドルとして管理
継承どうしよう?とか、ガベコレとか実現難しそうだよなぁ、、、とか(汗)
丸一日考えた割には練れてませんがorz
蛇足:
もっと過激にObject Oriented Assembler なんてのもアリなんですかね?(^^;
昔、構造化アセンブラってのを考えていた時期があって、まぁ結局当時はスキ
ルが未熟だったので、http://home.g04.itscom.net/alpha/archive/aspp.lzh [itscom.net]
のようなフィルタ作って遊んでた程度なんですが。。。
# 手前味噌ながら単純なプログラムの割りに案外役にたったんですよぉ(^^;
ここまでするなら素直にOOP言語使えよ、とは思いますが(苦笑)
♪潔くカッコよく生きてゆこう
Re:驚いた (スコア:1)
メジャーな実装としてはGTKでも読めばいんじゃないかとおもいます。
例外やRTTI(のようなもの)もあります
ここまでするなら(ry