アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、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は適当に書いただけで動くとっつきやすさがこういう使われ方を招いているんだろうなぁ・・・# そろそろ「望ましくない」とされてる構文は潰した方がいいのではないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
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は適当に書いただけで動くとっつきやすさがこういう使われ方を招いているんだろうなぁ・・・
# そろそろ「望ましくない」とされてる構文は潰した方がいいのではないかと。