今はPHPの時代Perlがこの先生きのこるのは無理3
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/05/24(火) 14:32:01ID:6a7n1dhFこれからはPHPの時代Perlはもう終わりバイバイ2(dat落ち)
hhttp://pc8.2ch.net/test/read.cgi/php/1046194468/
Perlはもう時代遅れPHPの時代
http://pc2.2ch.net/php/kako/1036/10369/1036915437.html
PHP最高！！！！
Perl、Ruby、 Python全部もう糞！
0709nobodyさん
2005/09/05(月) 04:36:30ID:???0710nobodyさん
2005/09/05(月) 07:19:33ID:???0712nobodyさん
2005/09/05(月) 13:35:05ID:???じゃ、XMLが不満なら
GNU makeでも記述してな。
Antのほうが安全性が高いがな。
Eclipse Ant Editorを使えばbuild.xmlの記述なんて面倒くさくも無く非常に簡単だが。
XMLにする理由はOSへの依存度を減らすことと
構文エラーに気づきやすくするためだ。
それでもAntに不満があるならMavenを使えばいい。
数多くの主種のゴールが用意されており、それを実行するだけでデプロイ、Jar生成、テスト、テストレポート生成、
プロジェクトサイト構築、ドキュメント生成、ダウンロードなどを一括できる。
ライブラリ依存関係も自動で解消し、
CPANやPEARのようにすでに登録されているモノで足りないモノがあればJJarが起動し自動でダウンロードされる。
0714nobodyさん
2005/09/05(月) 15:48:43ID:???0715nobodyさん
2005/09/05(月) 17:07:56ID:???my関数とか？
0716nobodyさん
NGNGXMLにもあるし、Java, C++はもちろん、C#, Perlにもある。
PHP5が発表されるとき、名前空間がサポートされるはずだったが
なぜか不採用になってしまったらしい。とても残念だ。名前空間があれば、PEARも
もっと優れた使い勝手の良いライブラリになっていただろうに。
Java, Perlではpackage, C++, C#ではnamespace
というキーワードを使って指定している。
PHP5もnamespaceというキーワードを使って名前空間を実現できるはずだった。
C++やC#のnamespace, Java, Perlのpackageのように。
これがなきゃパッケージ名は異なるがクラス名は同じ、ということを実現できない。
また、Facadeパターンも実現しづらい。なぜなら、パッケージプライベートを実現できないから。
Javaでは、クラス宣言の頭にpublicとつけると、そのクラスはパッケージ外部からもアクセスできるようになる。
だが、publicをつけないと、同じパッケージ内にあるクラスからしかアクセスできなくなる。
これを応用して、Facadeパターンを実現することができる。
同じパッケージ内でFacadeに相当するクラスのみをpublicにして、他のクラスはすべてパッケージプライベートにする。
ある機能を集めたが、クラス間の依存関係を減らすために意図的にFacadeを経由してしか、
他のクラスにアクセスできないようにすることができる。Facadeとはデパートの入り口のインフォメーションカウンター
のようなものであり、そこでデパート内のこの店(パッケージプライベートになっているクラス)はどこにあるのか、
と行き先を聞くことができる。デパートに入ると、かならずFacadeを通る仕掛けだ。
また、Javaではパッケージ名にドメイン名を含めることが推奨されている。
なぜなら、誰かが作ったクラス + パッケージが同じ名前で重複することを避けるため。
例: package net.2ch.www.php.test.example;
というように。
日曜プログラマに不要といっても、大規模開発では重宝するよ。
0717nobodyさん
2005/09/05(月) 20:52:16ID:???というか、プログラミング言語以外の世界にもある。
名前がついていれば、名前空間は存在する。
>>716 は名前空間を切る事によって得られる利点の説明、だよね。
0718nobodyさん
2005/09/05(月) 21:49:24ID:???別にどっちがいいとか悪いとかどうでも良くなってきた。
0719nobodyさん
2005/09/06(火) 02:47:26ID:???データベースアクセス部分やいろいろな処理が必要になると、サーブレットに書かないといけないよね。
そのとき、コンパイル・デプロイでタイムラグがある。
特に、Hibernateとか最近のフレームワークなんか使ってるとコンテキスト起動に時間がかかる。
そのタイムラグが気にならないといってるのは、Javaに慣れてそのタイムラグをあきらめてるヤツ。
JSPも書き直して実行するときには時間がかかる。
画面遷移のコントロールやら入力データの処理、表示データの取得なんかは、スクリプト系で試行錯誤をやりやすく気軽に書けるようにしたい。
0720nobodyさん
2005/09/06(火) 03:26:17ID:???0722nobodyさん
2005/09/06(火) 09:30:09ID:???なんでそんなにシステムの書き換えが発生するんだ？
安定してない者をリリースしてるだけなんじゃないのか？
っていうか、そんなにとめられないシステムなら、普通は二重化して
片方ずつ入れ替えて、見ため上とまって居ないようにして入れ替え
られるようにすると思うけど。
0725nobodyさん
2005/09/06(火) 18:06:32ID:???気になるならないって、再起動しても10秒くらいから、遅いマシンで30秒くらいだしな。
それを待てないとしたら、イライラしすぎだと思う。
0726nobodyさん
2005/09/06(火) 19:04:09ID:???待たずに試せる快適さをしらないだけかと。
試行錯誤で起動に30秒もかかれば、10回試すだけで待ち時間5分だよ。
Javaの人は、その待ち時間に飼いならされてるから不満もでないんだろうけど。
0727nobodyさん
2005/09/06(火) 19:27:11ID:???0728nobodyさん
2005/09/06(火) 19:31:53ID:???JAVAとPHPの実行速度が、仮に3倍だとして(本当はもっと差があるが)、
一回5秒の処理を1000回動かしたら、10000秒の差が出る。
だいたい2.7時間の差。
仮にこれが1日の動作だとして、一年動かしたら、どれだけ差が出る？
約1000時間だよ。
これが業務システムだとして、それだけ業務に時間が余計に掛かることになる。
時給1500円だとしても、年間150万円を捨てることになる。
作るのに多少時間が掛かっても、長く動かせばそれだけ損失が出る。
0730nobodyさん
2005/09/06(火) 19:37:51ID:???>>619
この記事を鵜呑みにして、>>728の言う業務がWebのシステムだとすると、
38倍変わるから、2億8141万円を捨てることになるね
PHPってヤバいんじゃないのｗ
0731nobodyさん
2005/09/06(火) 19:39:18ID:???年間コスト１００万円くらいは変わるのかな？
0732nobodyさん
2005/09/06(火) 19:48:07ID:???0733nobodyさん
2005/09/06(火) 19:50:56ID:???単価が安いPHPが最強なことに変わりがないんだよｗ
0734nobodyさん
2005/09/06(火) 19:53:34ID:???0735nobodyさん
2005/09/06(火) 19:58:13ID:???コンパイル時間が待てないとか、
いきあたりばったりの開発してないか。
私だったら頭の中で黄色信号が点灯するけど。
0736nobodyさん
2005/09/06(火) 20:33:28ID:???実際の開発したことある？
開発初期とか新しいライブラリ試すときとか最後の微調整とか、試行錯誤を繰り返すことはたくさんある。
そのとき再起動で30秒とか、考えることの妨げになる。
たんなるコーダーだったら、考えることもなく言われたとおりにやればいいんだろうけど。
つうか、Javaばっかり使ってて、プログラム書き換えて即実行っていう良さ知らないんだろうね。
0737nobodyさん
2005/09/06(火) 22:13:41ID:???その設定でEclipseを使えば、コードを書いてすぐ実行ってこともできる。
それよりも、PHPは文法が甘いせいで、どこにバグがあるのかがわかりにくくて、結局時間を浪費してしまう。
0738nobodyさん
2005/09/06(火) 22:22:43ID:???デバッグが大変になってくる。
use strictと-wつけるとヤバイ。
0739nobodyさん
2005/09/06(火) 22:24:32ID:???それ以外は単体テストするから何度も再起動なんてことめったにない
0740nobodyさん
2005/09/06(火) 22:49:38ID:???WEBアプリの場合、HTMLを微調整しながら開発しつづけることになるケースが多いんだから。
0742nobodyさん
2005/09/06(火) 22:56:41ID:???開発中は他の作業が山ほどあるから、そんなに気にならないし、
最後の調整に再起動を何十回ってやってたら、こりゃ変だって感じない？
Perl使ってPHPも稀に使うけど、よく分からん。
C/C++などでビルドに5分待ちとかに慣れているからかもしれんが。
0743nobodyさん
2005/09/07(水) 00:05:58ID:???printくらいどんな言語でもできるだろ。
Javaならブレークポイントを設定したり、ステップ実行したりできる。
これだとどこで変数の値がおかしくなったかが手に取るようにわかるから、とっても楽。
printなんかではできないような快適な開発が出来るから、いっぺんやってみ。
PHPでもZend Studio(有料)ならできるから。
0745nobodyさん
2005/09/07(水) 01:24:59ID:???0747nobodyさん
2005/09/07(水) 02:02:30ID:???スタックトレースが出てくるし、例外の種類も出てくるし、それでもわからなければ変換後のソースを見れば済む話。
それに、ロジック部分はServletやBeansで書くわけだし。
普段Java等のコンパイル型言語を使っているか、PHP等のスクリプト言語を使っているかで、デバッグの概念そのものが違うみたいだね。
0748nobodyさん
2005/09/07(水) 02:28:29ID:???0749nobodyさん
2005/09/07(水) 02:32:48ID:???クラス構成の変更には対応してないんじゃないの？
それに結局コンテキスト再読込みしてるだけだから、クラス修正するたびに再読込みが発生するのはうっとおしい
0750nobodyさん
2005/09/07(水) 03:12:31ID:???何がうっとおしい？
サーバのコンテキスト関連のログでも追いかけていなければ、見た目には何も起こってないように見えるはずだが。
0751nobodyさん
2005/09/07(水) 03:59:38ID:???そうするとrequire()が面倒なんだよ。
相対パスになっているからさ。
結局いまのところわかっているある程度までの解決策は
ini_get(),ini_set()をつかう方法かな。
それから、__FILE__, getdir()も組み合わせる方法、
どれも統一感がない。
Javaのimport宣言のようにはいかないのがちとつらい。
この方法を使っても、結局、namespace名は異なるがクラス名は
同じってことは実現できない。
結局、PEARみたいに、>>720みたいな
ネーミングに頼るしかないっていう結果になりそうだ。
0752nobodyさん
2005/09/07(水) 04:04:32ID:???いやいや、そもそも
Tomcatで<Context>タグに
reloadable属性をtrueにすればTomcatを再起動する必要は無いよ。
本番ではお勧めしないときもあるかな。
ホットデプロイという奴だよ。
>>740
printデバッグはねえ。
ロガー使ったほうがいいけどね。
PHPで開発しているけど、PEAR::Logは大変ありがたくつかってもらってますぜ。
java.util.loggingやJakarta Log4jほどの機能は期待できないけれども。
0753nobodyさん
2005/09/07(水) 04:07:11ID:???リモートでバッグもしらないのかい？
それから今上で説明したロガークラス。
ログレベルを変更すれば変数の中身などのデバッグ情報を
出力させるってことも簡単にできる。
>>748もいっているように、Eclipse用に作られたTomcat Sysdeoプラグインを
使えばかなり簡単にデバッグできる。
0754nobodyさん
2005/09/07(水) 04:08:13ID:???> >>737
> クラス構成の変更には対応してないんじゃないの？
> それに結局コンテキスト再読込みしてるだけだから、クラス修正するたびに再読込みが発生するのはうっとおしい
それも上で説明したとおり、
<Context>タグのｒｅｌｏａｄａｂｌｅ属性をtrueに変更すれば済むことだよ。
0756nobodyさん
2005/09/07(水) 04:13:58ID:???Tomcatのreloadableではコンテキストの再起動が発生してる。
で、重めのフレームワーク使うと、フレームワークの初期化もそのときに行われて時間がかかる。
0758nobodyさん
2005/09/07(水) 04:21:50ID:???単価が安いのは、PHPがトランザクション系のシステムじゃなく、
単純なシステムにしか使われないからなんだけど。
0759nobodyさん
2005/09/07(水) 04:39:09ID:???で、エラい人が批判しだすと、いっせいに「あれは面倒」って意見が変わる。
EJBとか。
0761nobodyさん
2005/09/07(水) 04:42:27ID:???っていうか、EJBは面倒、Servletは面倒じゃないというだけだと思うが。
えらいえらくないなんてのはお前の妄想。
0762nobodyさん
2005/09/07(水) 04:45:06ID:???アプリやフレームワークの動作が重いのと、コンテキストのリロード速度とはあまり関係ないと思うが。
イニシャル時にDBから設定をごそっと持ってくるような実装にしてたら重いかもしれないが、
それはどの言語でも同じだし。
0763nobodyさん
2005/09/07(水) 04:47:06ID:???0764nobodyさん
2005/09/07(水) 04:48:57ID:???print書いたり消したりなんて面倒なことしてるんです。
いまどきPHPでもLoggingは当たり前です。
0765nobodyさん
2005/09/07(水) 04:49:35ID:???PHPにはO/Rマップという選択肢が単にないだけだろ
0768nobodyさん
2005/09/07(水) 04:57:43ID:???単に存在するだけなら、選択肢があるといううちには入らないぞ
DB_DataObjectは重くて使い物にならんという話なら聞いたことあるが
そもそも重いのは、JAVA云々ではなくて、O/Rマッピングというものが重いんだろ
0769nobodyさん
2005/09/07(水) 04:57:48ID:???Hibernateの起動速度は、マジしゃれならんよ
内部で動的にクラス生成しているのが重くなってる一因だと推測。
PHPの場合はリクエストのたびに初期化になるから比較的軽いけど、パフォーマンスは悪くなる。
Javaの場合は起動時が重いだけでリクエスト時には影響ないから、運用では問題ないけど。
0770nobodyさん
2005/09/07(水) 05:02:07ID:???0771nobodyさん
2005/09/07(水) 05:03:04ID:???PHPのクラスライブラリなんか、バージョンアップで動かなくなってあたりまえ。
0772nobodyさん
2005/09/07(水) 05:03:33ID:???使われてますが。
＞DB_DataObjectは重くて使い物にならんという話なら聞いたことあるが
別に使い物にならないような重さじゃないですよｗ
小規模なら素で十分だし、鯖がいじれる環境ならAPC使えば十分実用的
＞そもそも重いのは、JAVA云々ではなくて、O/Rマッピングというものが重いんだろ
そんなこと誰でも知ってますがｗ
0773nobodyさん
2005/09/07(水) 05:04:08ID:???PHP＝開発者が楽をするために、利用者が不便を強いられる
優良な製品を作るのにどちらが適しているかは一目瞭然だな
0774nobodyさん
2005/09/07(水) 05:05:00ID:???↑
小規模ならわざわざマップしなくてもいいだろ
0775nobodyさん
2005/09/07(水) 05:05:25ID:???0777nobodyさん
2005/09/07(水) 05:09:38ID:???それ単にお前のレベル（もしくは働き先のレベル）が低いだけじゃん。
普通ならどっちの言語でも関係なくまともなもん作れるけど。
0778nobodyさん
2005/09/07(水) 05:10:41ID:???いや、小規模でもORマッピングしたほうが楽。
パフォーマンスが気にならないなら、テーブルのjoinをほとんど書かなくてよくなる。
パフォーマンスが気になるところだけ、まじめにjoin書けばいい。
0779nobodyさん
2005/09/07(水) 05:11:20ID:???実装云々じゃなく、PHPは決定的に動作が遅いんだって
同じレベルの技術者が、同じものを作ると、JAVAの方が
より安定したものを作れる
0780nobodyさん
2005/09/07(水) 05:12:21ID:???パフォーマンスが悪いというのが議題なのに、パフォーマンスが気にならないなら
っていう提案は、なんか無意味なような気がするが
0782nobodyさん
2005/09/07(水) 05:14:29ID:???じゃあ、JAVAやってる会社は何処も皆優秀で、
PHPやってる会社は、例外なくレベルが低いんだなぁ
良くわかったよ
0783nobodyさん
2005/09/07(水) 05:15:01ID:???起動が遅いっていうのが問題なだけだよ。
で、Hibernateとか、内部的にそれを使ってるJBossとか使うと、コンテキスト再ロードがシャレにならなくなるってこと。
EJB3の実装として広く使われるだろうから、結構問題。
ほかのコンテナでも似たようなものだろうし。
0785nobodyさん
2005/09/07(水) 05:17:52ID:???相当アクセスが凄まじいか、トランザクション系なシステムでもない限り
利用者に不便を強いられるような遅さなんてないよ。
WEBアプリみたいに単純なもんなら尚更。
0786nobodyさん
2005/09/07(水) 05:18:45ID:???0788nobodyさん
2005/09/07(水) 09:33:03ID:???速度遅いなら鯖増やしたらいいじゃん
開発・運用コストより
鯖にかけるコストの方が安いんだから
0789nobodyさん
2005/09/07(水) 11:01:13ID:???0790nobodyさん
2005/09/07(水) 11:02:28ID:???１リクエストあたりの処理速度が上がるわけじゃないんだが。
むしろ振り分けコストがかかって、ちょっと遅くなるし。
0791nobodyさん
2005/09/07(水) 11:17:56ID:???そんなにねーだろ
重要度で言えば
DB周り＞＞＞＞＞＞アプリサーバ
くらい。DBとアプリサーバの間が速くなってもあんま意味ねーーー
0793nobodyさん
2005/09/07(水) 12:37:52ID:???Javaではバージョンアップで動かないという事態は滅多に無い。
あってもすぐに修正できるからいい。
PHPとか他の言語はひどいもんだけど。
M$系のAPIを使っているとたいていそういう痛い目に遭う。
0794nobodyさん
2005/09/07(水) 12:51:24ID:???そんなにないよ。
あってもすぐ修正できるレベル。
0795nobodyさん
2005/09/07(水) 12:58:06ID:???それでも「そんなにない」と言っていいのか？
0796nobodyさん
2005/09/07(水) 13:18:01ID:???0797nobodyさん
2005/09/07(水) 13:42:51ID:???そんなこと言ったら、PHPの実行速度のことも、Javaのコンパイル時間のことも、全部気にしなければ大丈夫ってことにならない？
そうなるとこのスレの面白味がなくなってしまうから、気にすると言ってくれ。
0798nobodyさん
2005/09/07(水) 14:41:02ID:AHRt86UB0799nobodyさん
2005/09/07(水) 14:51:55ID:???0800nobodyさん
2005/09/07(水) 15:55:54ID:???0801nobodyさん
2005/09/07(水) 16:10:54ID:AxGFCskAこんなん見っけた
やってみる気あったらケータイでお気に入り登録しとくといいよ
0802nobodyさん
2005/09/07(水) 16:24:46ID:???0803nobodyさん
2005/09/07(水) 16:50:16ID:???起動遅いよね。ほんと。
なぜあれを無視して Javaの方が速いとか言っていられるのか不明。
開発してるうちに、自分達は気にならなくなってるのかも知れないけど。
0804nobodyさん
2005/09/07(水) 16:54:39ID:???> >>721
> そうするとrequire()が面倒なんだよ。
> 相対パスになっているからさ。
> 結局いまのところわかっているある程度までの解決策は
> ini_get(),ini_set()をつかう方法かな。
> それから、__FILE__, getdir()も組み合わせる方法、
> どれも統一感がない。
統一感が無いというのなら、自分でどれかに統一すれば良いだけ。
私は ini_set() してます。
0805nobodyさん
2005/09/07(水) 17:08:29ID:???Perl使い…変態
PHP使い…ﾌﾞｻ専
Java使い…童貞
0806nobodyさん
2005/09/07(水) 17:29:00ID:L++YBOi90808nobodyさん
2005/09/07(水) 18:17:56ID:???マイナーバージョンアップで動かなくなるのは、開発方法が悪いケースと、
PHP自体にバグが含まれている場合があります。
バグの場合はすぐに修正されます。開発方法の悪さに関しては言うまでもありません。
0809nobodyさん
2005/09/07(水) 20:55:20ID:???だれも早いなんていってないだろ。
遅いが気にならないって話だろ。
開発している人垣にならないのであれば、何の問題もない。
絶えられないほど気になるのであれば、ほかのものを使えばいいだけ。
とりあえず書いて、動くか試してみて、変更を繰り返すような開発方法には
向かないかもしれないが、通常は、設計書どおりにロジックを起こす作業がメイン
なので、そのロジックの動作を単体テストした後に結合するので、
あんまり再起動を頻繁にやることってないけどね。
■ このスレッドは過去ログ倉庫に格納されています