アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
OOPが当たり前の前提で議論が進んでいて驚いた。現実は理想ほど甘くないと思っていたのだが。
去年、大手プロバイダのWeb案件に関わったことがあるのだが、
「これはPerl4のソースか?」
と見間違えるCGIのメンテを任されて愕然とした。聞けば開発されたのは3年前と言う。驚愕した。
先進的な(と言っても10年以上歴史があるが)OOPは広まらないものだなと、半ば諦めていたのだが、こっちの方が特殊例だったのかな。C++やJavaがCを置き換えるまでに行ってないので、OOPが嫌いなプログラマが多いのかとも考えていたが。
いや, 特殊例じゃないと思います.
みそもくそもひっくるめた, いわゆるプログラマで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)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
驚いた (スコア:0)
OOPが当たり前の前提で議論が進んでいて驚いた。
現実は理想ほど甘くないと思っていたのだが。
去年、大手プロバイダのWeb案件に関わったことがあるのだが、
「これはPerl4のソースか?」
と見間違えるCGIのメンテを任されて愕然とした。
聞けば開発されたのは3年前と言う。驚愕した。
先進的な(と言っても10年以上歴史があるが)OOPは広まらないものだな
と、半ば諦めていたのだが、こっちの方が特殊例だったのかな。
C++やJavaがCを置き換えるまでに行ってないので、OOPが嫌いなプログラマが
多いのかとも考えていたが。
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
Re: (スコア:0)
数人以上のチームで開発する場合限定です。(後で他の人間がコードを読んだり変更するのも勘定します)
A+D=P時代の人間ですが、トップダウンスタイルでもなんでも構わないのですが、良いとされるスタイルを奨励ないし強制する構造を持つ言語が良い言語と考えています。
しかしPerlはそうではない。
Re: (スコア:0)
Pascalサイコー
能率が悪くたって、プロセッサが早くなれば関係ないよね。
Re: (スコア:0)
ちょっと気の利いた人ならAdaサイコーと言って欲しいですね。
Re: (スコア:0)
俺も去年、大手プロバイダのWeb案件に関わってたけど、
工数たんなくてさ、既存の仕様の調査に時間を消耗して、
ベターーーーーとしたコード書いて動かしてきたよ。
OOP なモデルなんか考えてる時間なんかなかったよ。
いや、設計してる時間なんかの間違いか。