のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,645,298人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレPerl VS PHP

php覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

51 :

Servletはコンパイルが必要という時点で、もう手軽とはいえないでしょう。
場合によっては、つーか、たいがいは一本のサーブレットに対して、
クラスファイルが沢山できる事になるし、jarでパックすりゃ一つに
なるといっても、それだって一手間よけいにかかる事にかわりない
し。とかいいながら、サーブレット使ってるんだけどさ。
サーブレットからPerlやPHPのモードになると、それまで大リーグ
ボール養成ギブスでもつけてたんかみたいな開放感を感じるのは
おいらだけか?

53 :

その ギブスで 養成されたか知りたい

54 = :

>>53
Servlet を使おうとすると、それなりにオブジェクト指向設計・実装技法を
身に付ける必要があるから、アプリケーションの設計能力は若干高まるんじゃ
ないかな。
まあ Java プログラマー自称していても巨大な main() 作る人もいるから、
「常にそうなる」わけではないけど、少なくともそういう機会は与えられる
よね。

PHP だけしか使っていないと、なかなかそういうやり方が身につかない。
そういう設計・実装が必須ではないし、オブジェクト指向的に書く問題点も
あるし(全体の見通しが悪くなる、書きなれていない、適切なサンプルがない)、
具体的なメリットが痛感できるわけでもないから、これは仕方が無いと思う。
# マンモス本のコードを見れば痛感できるでしょう・・・。

もちろん、そういうオブジェクト指向的な書き方ができるようになることの
是非はまた別だね。書けるようになるまでに必要な労力や、メリットを考えると
あらゆる場合にお勧めするわけではない。
議論がずれてきたのでこの辺はまた別の機会にでも。

55 = 51 :

>>53
大リーグボール的魔球のようなプログラムが書けるようになったとは思わんさ(藁
開発にかかる労力としての比喩だよ。でもJavaって悪くない言語仕様だとは思う。

56 :

意外と素人が多いな、ここ。(もちろん全員ではないが)
適材適所はプロの現場、趣味を含めて当然だと思う。
とりあえず企業のサイト(コンテンツ)でPHPはちょっと痛いと思う。
JSPのアプリケーションサーバーだって安いんだからさぁ。
自分は自宅で趣味でやるからPHP使うけど。

57 = 56 :

つうかPerl VS PHPだったっけ。
個人的にはWebのアプリケーションとして使うなら
PerlよりPHPの方が生産性が高い(特に小規模なら)と思う。
たとえば、よーいドンで作ったら勝つのはPHPでしょう。
(同等のスキルの人間が作ったとして)

Perlは今後、コマンドラインから使うことにしよう(藁
それはそれで便利。覚えておいて損はないよね。

58 :

PHPってPerlより生産性高い?
PHP3はデバッガがなくて苦労したけれどな。
データベースにしてもDBI使えば変わらないし。
Perlのほうがライブラリが充実しているし、いろんなことが出来ると
思うんだけれどなー

59 :

ツール,参考書籍等においては当然Perlだけど、
それをふまえても生産性はPHPに軍配上がると思う。
PHPが枯れてくればさらに差は広がるであろう。

60 :

>>59
>それをふまえても生産性はPHPに軍配上がると思う。
なんで?
理由は?

61 :

>>58
デバッガについては Zend Debugger がある。有償になるけど。
VB のようなステップ実行とかブレークポイントの設定とか可能みたい。
ただまだ使った経験がないので、どこまでカタログスペック通りかは不明。

>>59-60
そういう議論は定量的な数字を示さない限り「そう思う」「いや思わない」
という水掛け論になりがち。もっとも数字を出しても、その数字をどう評価
するかという別の問題が出てくるので、これが決定的ではないが。

ちなみに会社でプログラミング初心者にやらせてみた感じでは、PHP の方が
受けがよかった。

PHP の場合、HTML 埋め込みになるため、まず素の HTML で書いてみて、
そこにだんだん PHP のコードを入れるという形で徐々に試すことが出来る。
その点がとっつきやすそうに見えるらしい。

Perl だとどうしても最初から Perl 「プログラム」から書くことになり、
その辺の心理的抵抗が大きい模様。

そういう事例もある、程度に読んでほしい。

62 = 61 :

ちなみに生産性は、言語仕様よりも
・再利用・メンテナンスを意識したコーディングをしているか
 (コーディングスタイル)
・きちんと設計できているか(特にビジネスロジック層と永続化データ層)
の影響を大きく受けると思うので、Perl だろうが PHP だろうが違いがあっても
誤差程度というのが自分の考え。

Perl は write-once な言語だと揶揄されることが多いが、PHP にも同じ傾向が
見られるような気がする。そうだとすると、どちらもそのままでは生産性は低い、
が正解では?。で、どうやったら生産性が高まるか?という話になるのでは
ないかと思う。

64 :

電動ナナシ氏はかなりもっともなことを言うなぁ。

生産性についてはどう捕らえるか、色々あるけど、
HTMLのデザインを先にデザイナーに作ってもらって、
それをそのまま流用できるのは大きな差だと思う。
もちろんPerlだってそうすると思うけど、PHPの方がそこが楽だと思う。
修正が入ったときでも、ソースを書いた本人以外が見ても
デザイン程度の変更だったら割と楽だと思うし。

これに関してはPerlとPHPというよりは、
スクリプト(もしくは言語)にHTMLを吐かせるタイプか、
HTMLにスクリプトを埋め込むタイプかという比較ですけどね。

65 = 64 :

あと、メンテナンスを考慮した云々の話しでコーディングしているか
って話しだと、Webの仕事だといわゆる「やっつけ」に近い形で
来ることが多いので(自分の経験に限り)、ちゃんと設計している
暇がないことが多い。
Perlなどの言語主体の作りをする場合は、どちらかと
言うと共通して使えるようなモジュールになってくることが多かった。

66 :

>65
っつーか、自分がそーゆーことになってます。
ホントは俺だって再利用したいんだよ。いろいろ。
でも、結構アクセスがあるんで、requireとかincludeにかかるコスト&
納期を考えると、だらだらとよだれ垂れ流し型のみっともないコードを
かかざるを得ない。んで、クライアントから「前つくったのと同じだから
半分の納期でできるでしょ?」とか言われちゃって・・・。

すまん、グチった。

67 = :

>>66
んまあ、それが現実だよねえ。自分も納期間際になって「あーゼロからやり直したい!」と
いう衝動によくかられる。

> クライアントから「前つくったのと同じだから
> 半分の納期でできるでしょ?」とか言われちゃって・
あーそれはよくあるねえ。再利用が完全な形で利用できるなら確かにクライアントの
言う通りだけど、実際には「作り直し」に近い事態になりがちなんだよね。
実際の統計データとして、
・企業が新規開発に投入するコスト
・新規開発にあたり企業が既存のシステムの解析・デバッグに要するコスト
がほぼイコールだっていう話もあるしね。再利用が完全なら前者のコストだけですむはず
なんだけど、実際にはレガシーコードが足を引っ張って倍以上のコストになるという
お話だった。

あと、PHP 使った小規模案件だと、発注者も要求仕様をきちんと詰めないで「こんな感じ」を
連発した非常によく分からない発注の仕方をするから、仕様が確定するのはいつも
納品時ということになりがち(いや仕様は最後まで確定しないで、とりあえず納品する
という方が正確か)。このために再利用性を高めるべく事前に設計をしようと思っても
できないことが多い。これがさらに状況を悪化させると思う。

もちろん、この曖昧な顧客の要望を仕様にまとめあげるのが技術者の能力の一つである
ことは間違いないんだけど、朝令暮改というのは本当に困る。

みんなはどうよ。
# 愚痴スレになってきたかな・・。

68 :

Perlでもヒアドキュメントを使えば、PHPライクに書けるぞなもし。

70 :

>>67
>朝令暮改というのは本当に困る。

同意。
顧客のニーズを察して汲み上げて・・
顧客本位の姿勢て大切だけど何かと大変ですね。
私は優柔不断な顧客をねじ伏せる力技・小技・裏技を日々駆使してますよ。

楽したいからじゃなくって、最後に顧客に満足してもらいたからこそ。マジで。

72 :

電動ナナシ氏って、所謂「判っている技術者」って感じですよね。
「わかってる」ってのは、技術云々もそうだけど、技術者に仕事を
出す側の論理とかクライアントの要求とかをちゃんと見てる、という
意味で・・・。
一番の疑問は、何故こんな優れた技術者が2chにこんなに頻繁に
書き込んでるのか?ってこと。こんな人をほっといていいのか?
>電動ナナシ氏の会社

73 = :

現実逃避だよ・・・。
# まだハマっています。X-(

会社にばれたらやばいだろうな・・・。

74 = :

>>1-

75 = :

>>1-ああああ

76 :

今回の仕事は某N○○系列の仕事だったんだが、向こうのSEがしっかりしているので、
珍しく仕様がカッチリ固まっていて良い感じ。
ドキュメントも先に書いているしね。
やっぱり大手は違うんすかね。

PerlでもPHPでもないんですけどね:)
これまた某N○○関係のアプリ。

77 :

私、仕事でJSP+Java。趣味でPHP使ってます。
Java系はクラス設計からしっかり作れるから、自分の知的財産として高く売りやすいですね。
通常画面周りをJSPで作って処理自体をクラスとかBean(use Bean)で作るので、
JSP部分をWebデザイナーに流せるのもチームな仕事向きですね

でも、PHPはWebプログラムで欲しい機能が一通り入ってるので好きです。
画像生成だけでなく、PDFやShockwaveFlashまでさっくり作れるのはうれしいですね。
デバッガ無いとか言われてますけど、
ほとんどの趣味Perlプログラマがデバッガ無しで作っている状況で、
エラーメッセージが画面に出るだけ幸せに感じてるのは私だけ?

Perlも一応使えるんですが、C言語から育った世代なので、Java PHPの方が忘れにくいですね。
複数言語使ってると混乱するもので(^^;

78 :

どうしてもPHPでなきゃいけない理由がない。
となると枯れてるとか、どこの鯖でもたいがい動くとか、
「ぺっぷ~?なんだねそりゃ」なんていわれて説明する手間も
いらないってわけでPerlにおちつくな。

79 = :

むしろ「この言語じゃないと」って必然性があるほうが珍しいだろうね。

80 = :

>>78
はう? 「ぺっぷ」って呼ぶの?
「ぴいえいちぴい」だと思ってた....。

81 = :

>>80
そっちが正解。
でも HTML を「はとまる」って読む人もいるご時世だからね。
世の中にそういう読み方をする人がいても不思議はないような・・。

82 :

「○○言語じゃなきゃいけない」とか言ってるのは一部の風潮であって
TPOではないでしょうか?

会員ページを作るとき、セッションにデータを格納できないPerlではさすがにきついです。
メールアドレスの整合性チェックはCやJavaだと面倒だけど、正規表現が使える言語だと1行だし。

結局自分の持ちネタが多い言語に落ち着くかな。

83 = 82 :

あぁ、TPOは私の個人的意見。
仕事では許してくれません。
コールドフュージョン使ってみたい

ところでPerlで画像ライブラリってあるんでしたっけ?

90 :

>>79
言語仕様や性能に言語選択の必然性がある場合は少ないが、
それを使う側の事情に言語選択の必然性がある場合は非常に多い。

94 = :

>このアクセス1って、俺のことだ。
俺の1は何処??

95 = :

>>93
これって書き込み数なんじゃないの?

>>90
「トンカチを持つと、問題がすべて釘に見える」ってやつだね。

96 = :

鬱だし脳

97 :

PHPだと、インタフェースデザインとプログラムが分離しにくいから嫌いだ。

98 :

Perlだと、インタフェースデザインとプログラムが分離しにくいから嫌いだ。

100 = :

>>97-98
どっちもやり方次第だと思うんだけど。


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について