今は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全部もう糞！
0064nobodyさん
2005/08/14(日) 03:24:27ID:???残念ながらそのせいでスキルが身に付かないんだよ。
面倒な部分が省ける以上に、知る必要がある部分も省いてるからね。
0065nobodyさん
2005/08/14(日) 03:26:42ID:???真似を否定する奴は学びを否定しているに等しい
0067nobodyさん
2005/08/14(日) 03:29:33ID:???abstractなんて半端なものが存在していたり
いちいちgetter/setter書かなければならなかったり
そういった醜さを何も考えずに真似したのがPHP
0068nobodyさん
2005/08/14(日) 03:30:19ID:???とても、J2EEと比べられるもんじゃないけどな。
0069nobodyさん
2005/08/14(日) 03:32:26ID:???0070nobodyさん
2005/08/14(日) 03:33:47ID:???どういう意味だ？
全部interfaceにしろと？
0072nobodyさん
2005/08/14(日) 03:37:16ID:???動的型つけでJavaのマネをしてツールのサポートも得られないとただのクソ言語。
0073nobodyさん
2005/08/14(日) 03:41:07ID:???0074nobodyさん
2005/08/14(日) 03:44:41ID:???Perlやっても旧世界の知識しか得られないが
Javaではモダンなプログラミング技術が学べるからな
Perl→PHPに移った奴がわざわざPerlに戻ろうと思うわきゃない
0075nobodyさん
2005/08/14(日) 03:48:17ID:???WevProg板は最近の話題追いかけていない人が多すぎるから困る。
0076nobodyさん
2005/08/14(日) 03:51:15ID:???>Perl→PHPに移った奴がわざわざPerlに戻ろうと思うわきゃない
また妄想か。
おれは、php→perl。メインはjavaだが。
phpの深みのなさを思い知ったよ。
0077nobodyさん
2005/08/14(日) 03:56:15ID:???ﾊﾅから目指してないんだから
0078nobodyさん
2005/08/14(日) 03:56:39ID:???CGI.pm使ってコードがりがり書くしか方法がないのに
小さなものならともかく、ある程度大きなものを作るとかありえん。
0080nobodyさん
2005/08/14(日) 04:04:42ID:???PHPは国産も含めて競争が激しくなってきているけど
Perlは聞かないよなあ・・・
0081nobodyさん
2005/08/14(日) 04:05:44ID:???0082nobodyさん
2005/08/14(日) 04:14:31ID:???cpanモジュールの組み合わせでやってるけど。
CGI::Application、Error...なんかで。
0084nobodyさん
2005/08/14(日) 04:33:09ID:???Perl←→PHPは
乗り換える程のアドバンテージはないと。
0085nobodyさん
2005/08/14(日) 04:54:51ID:???かなり狭い範囲だけど。
cgiではさばけない程のアクセスがあるサイトは、
専用鯖やVPSでやってるから、特に何でも使えるし。
0086nobodyさん
2005/08/14(日) 06:20:43ID:???掲示板を作るにしても
perlよりも簡単に早く書ける
オブジェクト指向強化で
クラスの使いまわしjavaとの連携も可能
大規模なものならperlよりもphpの方が制作日数が短くてすむ
perlはもともとWEB制作のために作られた言語ではない
WEB制作のために作られたPHPはWEB業界では最強の言語
0087nobodyさん
2005/08/14(日) 07:14:25ID:???掲示板を作るにしても
phpよりも簡単に早く書ける
オブジェクト指向強化で
クラスの使いまわしjavaとの連携も可能
大規模なものならphpよりもperlの方が制作日数が短くてすむ
perlはもともとWEB制作のために作られた言語ではないが、
今やネットワーク系の充実したモジュールも沢山ある。
最強の言語なんてものは存在しないが、なかなか良い言語である。
0088nobodyさん
2005/08/14(日) 07:39:56ID:???そんなにいいものなら別にホイホイ乗り換えるわけだが
実際はｸｾが強くて
少ない情報の渉猟を強いられ
簡単なことの実現にもいちいちライブラリ探しライブラリ探しなんじゃないのか？
0090nobodyさん
2005/08/14(日) 07:53:17ID:???もちろん、suexecでcgiとして動かしてる共用鯖のが多いけどね。
cgiとして実行するんなら、phpよりperlのが速いじゃない。
0091nobodyさん
2005/08/14(日) 07:58:19ID:???馬鹿は死んだ方ががいいね
0092nobodyさん
2005/08/14(日) 08:12:41ID:???でも提供している大手ホスティングあるけどね・・・。
となると、phpは自身のマニュアルに載ってることすら適当なのか。
そこまで使えない代物だとは思わなかったよ。
0093nobodyさん
2005/08/14(日) 08:29:37ID:???Python、Java、C/C++、Perl、Lisp （学習順は左から。PerlとLispはどちらが先でもよい）
残念ながらPerlが死ぬことはないよ
0094nobodyさん
2005/08/14(日) 08:36:00ID:???後先考えずに手っ取り早く作るにはPHPが一番なんだよ。
Javaみたいな厳格な型付けをする言語なんか使ってたら、ちゃんとした物を作らないといけないからめんどくせー。
0096nobodyさん
2005/08/14(日) 08:47:59ID:???単純なcgiなら実行ファイルの軽いperlが最強
phpの利点はDB接続とエラー表示
0098nobodyさん
2005/08/14(日) 11:25:31ID:???厳格な型とかが無いから余計なバグが潜んでいても発見が遅れる。
また、この間PHPのバージョンが上がって、間違った使い方をした場合は警告が出るようになったら、
出回ってる有名なアプリやらフレームワークが警告の嵐。
つまり、PHPみたいに厳格な型が無いお陰で、セキュリティ上重要なバグが潜む。
さらにはPHP使ってるプログラマの能力はこんなものなのかと露呈した結果となった。
0099nobodyさん
2005/08/14(日) 13:50:56ID:???そもそもバージョンがあがったときに旧バージョンと互換性をもたせるという考え方自体ないようだけど。
0100nobodyさん
2005/08/14(日) 14:03:46ID:???Javaの場合、J中間言語(JVML)で吸収させるようにして互換性を保ってる。
0101nobodyさん
2005/08/14(日) 14:05:29ID:???実行するときにバージョンを指定して動作させられればいいんだよ。
0102nobodyさん
2005/08/14(日) 14:09:40ID:ER9gajg+それにしても互換性がないのはものすごく不親切。
0103nobodyさん
2005/08/14(日) 15:45:20ID:???でも、言語仕様が固まってないのに下手に互換性つけられると、
後々、ごちゃごちゃとはしそう。
成熟するまで待つしかないんじゃない？
0104nobodyさん
2005/08/14(日) 15:47:45ID:???セキュリティーホールとかバグ修正とかと同時に仕様変更が行われるから、古いバージョンが並行で動けばいいって話でもない。
0105101
2005/08/14(日) 16:07:45ID:???それはそうだけど、普通はセキュリティとかバグ修正用のモジュール出して、
仕様は変えなくても穴を塞ぐ方法が用意されてしかるべき。
ただ、現状だとレン鯖とかでもセキュリティホールがあるにも関わらず、
PHPのバージョンは上がってない。
なぜか？と考えれば、バージョンアップに伴いユーザのプログラムが動かなくなる可能性あるから。
ならば、複数バージョンが平行して動くようにして、そっちへ順次移行させるように促し、
ある程度の以降が完了した時点で旧バージョンを動作させないようにするという事ができれば、
便利だと思うんだけどな・・・
0106nobodyさん
2005/08/14(日) 16:26:21ID:???0107nobodyさん
2005/08/14(日) 20:04:41ID:???>phpの利点はDB接続とエラー表示
どちらも利点なくない？
ネイティブ接続ってあまり使わないと思うし、
むしろ、DBIなりJDBCなり上位のインタフェースが優れてる他言語のが利点だと思う。
php5のpdoはよさそうだけど。
0109nobodyさん
2005/08/15(月) 06:32:00ID:???PHPはWEBアプリを手っ取り早く作れるって点では、やはり一番すぐれてる。
ただ、PHP自体、埋め込み型の言語なんだから、テンプレートなんて要らないし、
PHP4のうんこなOO機能でフレームワークとか意味ないし、PHP5は遅すぎて、もっと意味ない。
PHPはおとなしく簡単にWEBアプリを作るっていう本来の目的を守っているべきだと思う。
0110nobodyさん
2005/08/15(月) 07:06:36ID:???DB決め打ちで作るか、自前でDB用クラスを作るかでしょ。
Pear DBが組み込みだったらメリットあると思うし、
今の組み込み関数でもオブジェクト指向でクラス化されていれば、
多態で解決できたかもしれない。
0111nobodyさん
2005/08/15(月) 11:11:11ID:29YfjhoF0112nobodyさん
2005/08/15(月) 11:28:44ID:???運用中にDB自体が変更されるっていうのも、実際にはまずないだろうし。
0113nobodyさん
2005/08/15(月) 11:37:52ID:???＞運用中にDB自体が変更されるっていうのも、実際にはまずないだろうし。
そんなことは無い。
特にオープンソースを使った場合の開発は、度々こういった事が普通にある。
最初はPHP＋MySQLとかPostgreSQLなどを使ったシステムだったけど、
ユーザやアクセス数の増加や、システム拡張に伴い、Oracleなどに運用中に変更するという事は結構ある。
0114nobodyさん
2005/08/15(月) 11:48:09ID:???DB変更する前に、SQLやアルゴリズムを見直すのが先決。
PerlやPHPで動かす規模のサイトなら、grepで引っ掛けて手直ししていっても、いくらもかからないでしょ。
0115nobodyさん
2005/08/15(月) 12:02:30ID:???0116nobodyさん
2005/08/15(月) 12:11:20ID:???「Cの関数がスクリプトから使えりゃ良いや」
っていう安易な考えで作られてる感じだからなぁ。
DB周りのAPIは最初にもう少し考えてくれれば良かったのに。
>>113
というか、そういう可能性が考えられるなら
最初からPEAR使うか、自分で作って
標準SQLで対処するもんでないの？
0117nobodyさん
2005/08/15(月) 12:14:57ID:???フレームワーク要らない、テンプレート邪魔
っていえる規模のアプリならDB変更の保守も同様に大した事ない。
「手軽に作れる」と「作った後も保守性を高くする」
両方を同時に満たすのは難しい。
0118nobodyさん
2005/08/15(月) 12:29:27ID:???Perl は 定型処理や定時処理などを行うスクリプト言語として、この先生きのこると思うよ。
0119nobodyさん
2005/08/15(月) 12:44:11ID:???0120nobodyさん
2005/08/15(月) 12:54:48ID:???＞Perl は 定型処理や定時処理などを行うスクリプト言語として、この先生きのこると思うよ。
でも、この部分をPHPで書いてもいいんだよな・・・
Perlでなきゃというメリットは何も無い気がする。
0121nobodyさん
2005/08/15(月) 13:37:47ID:???PHPで全て同等のことが実現可能。
昔と違ってコマンドライン版もあるわけでPerlを使う必要は無い。
0122nobodyさん
2005/08/15(月) 16:05:12ID:???むしろ、Perl は 最近のLinuxや*BSDのディストリビューションだと
ほぼ標準でインストールされるが、
CLI 版のPHPは標準でインストールされないからデメリットだな。
0123nobodyさん
2005/08/15(月) 18:20:01ID:???perlは、amazonなどの大規模サイトでも使われてる実績もあるわけだし。
0125nobodyさん
2005/08/15(月) 20:07:26ID:???有名な大規模サイトで使われた→大丈夫
ってあまりにも短絡的な考え・・・
0127nobodyさん
2005/08/15(月) 20:16:50ID:???大規模サイトで使われたからイコールで大丈夫とは思わないが、
仕事としてPHPを提案する場合、有名サイトでの実績の有無で
ユーザがOKを出すかどうかが決まる。
0129nobodyさん
2005/08/15(月) 21:49:35ID:???お客さんが見るところで動的生成しなければならないところって少ないんだよね。
mixiやはてなのように、常に更新されて、毎回動的生成するようなサイトと比べるのは、
ちょっと違うと思う。
0131nobodyさん
2005/08/15(月) 21:59:29ID:???楽天やアマゾンでは、サイトにアクセスする人の殆どは見るだけの人だから、
商品一覧を固定にすることで、大幅に負荷を軽減できる
金額が決定した後の決済は、また別の決済システムだろうし
ミクシィって、会員が100万人もいるのに、みんなログインして
日記やコミュニティをリロードしまくってるのかと思うと、凄いシステムだと思う
セッションが重たいPHPでは無理だろうなぁ
0132nobodyさん
2005/08/15(月) 22:00:03ID:???0133nobodyさん
2005/08/15(月) 22:06:19ID:???商品一覧が固定って普通に考えておかしいと思え。
新たな商品が並んだ場合、
商品が売り切れた場合、
在庫数の表示、
次回納入日の表示、
動的に生成しないと意味が無い。
0134nobodyさん
2005/08/15(月) 22:06:42ID:???| ノ＼ ヽ | , -─-'- 、i
/ ●゛ ● | | _, '´ ／ ヽ、
| ∪ ( _●_) ミ j iニニ, "● ∪ ヽ、
彡､ |∪| |
/ ∩ノ ⊃ ヽ 〈｀'ｰ;＝=ヽ、〈ｰ- 、 !
( ＼ ／ ＿ノ | | ｀ｰ´ ヽi｀ヽ iﾉ
.＼ “ ／＿＿| | ! /
＼ ／＿＿＿ ／ r'´、ヽ
｀´ヽノ
0135nobodyさん
2005/08/15(月) 22:18:18ID:???amazonのおすすめ商品なんて、利用者がその場で商品の評価を下して、
動的にお勧め商品を絞り込んでいける。
いろんな意味ですごいから、勉強の為にも一度利用してみるといいよ。
0136nobodyさん
2005/08/15(月) 22:18:56ID:???で、楽天市場のどこに在庫数が書いてあるんだ？
あとの項目は商品メンテナンス時と売り切れ時に生成するだけでいい。
0138nobodyさん
2005/08/15(月) 22:21:18ID:???ディレクトリで商品切ってる
都度生成はしてない
0139nobodyさん
2005/08/15(月) 22:25:16ID:???お前の妄想だけで語ってないか？
0140nobodyさん
2005/08/15(月) 22:29:45ID:???楽天だって在庫が無くなりゃ買えないよーにせにゃならんのじゃないの？
期間限定販売とかもあるし、特価セールの時は金額だけ変えたいだろーし
売れ筋はPickUpしたいだろうし、商品ごとに税込み税別、送料込みやら追加送料だったり
イベントシーズン毎にギフト包装とか、その辺全部カートに入れてからしか対応されないの？
>>138
楽天はPHP+Smartyだってば。
ディレクトリ切ってるだけで固定なら2chも固定と言えるのだろうか？
ヒント：pathinfo
釣られすぎ？
0141nobodyさん
2005/08/15(月) 22:31:06ID:???アプリサーバ側の若干の速度の違いなんて
たいした違いにならないのではないか。
0142nobodyさん
2005/08/15(月) 22:31:09ID:???最近はよくmod_rewrite使うし。
0143nobodyさん
2005/08/15(月) 22:31:43ID:???0144nobodyさん
2005/08/15(月) 22:41:27ID:???動的に生成する必要がある情報がひとつもない
あれで都度生成ならかなり無駄
0146nobodyさん
2005/08/15(月) 22:46:15ID:???出店者が商品情報を自分の運営方法とタイミングで修正・変更できる必要があるだろ。
HTMLいじれないと出店できないんじゃモール側も商売にならん。
0148nobodyさん
2005/08/15(月) 22:47:40ID:???そうかい？
楽天、っていうかああいう商品情報って頻繁に変わるページは、
静的に生成するオーバーヘッドの方が負荷かかると思うけど。
0149nobodyさん
2005/08/15(月) 22:49:01ID:???買収だの吸収だのでツギハギだらけっぽい感じはするね。
パフォーマンスや効率は知らんけど>>140の上段に書いてあることは
出来るらしいよ。
0150nobodyさん
2005/08/15(月) 22:49:52ID:???商品を登録変更したら、システム側で自動生成するわけだが。
DBに書き込むだけなら、商品ページにアクセスがあるたびにDBアクセスが発生するが、
の時点で、アクセス時に呼び出されるHTMLを作成しておいておけば、
お客さんがアクセスしてもDBアクセスが最小限になり、負荷が軽減できる。
0152nobodyさん
2005/08/15(月) 22:51:15ID:???動的生成の方が、固定HTMLよりも早いというのか？
HTTPサーバのモジュールとして書いたんならともかく。
0153nobodyさん
2005/08/15(月) 22:52:45ID:???blogってのは、記事を書く毎に、スクリプトが静的ページを生成するのだよ。
だからDBアクセスが、メンテナンス時にしか発生せず、
読み手がアクセスしてきてもDBは動かなくてすむ。
0154nobodyさん
2005/08/15(月) 22:56:19ID:???静的ページを都度更新システムが生成するのは、動的ページと呼ばないって事なら、そうかもね。
そりゃhtmlファイルを生成した方が閲覧だけの負荷考えりゃ軽いのは当然だろうし。
ただ、期間限定の商品だとか、夜中だろうが在庫切れになったら買えなくしたりする必要はあるんじゃないの？
0155PHP大好きっ子
2005/08/15(月) 22:56:47ID:???0156nobodyさん
2005/08/15(月) 22:57:58ID:???そうじゃなくて、ページの更新頻度によるんだよ。
一度、静的に生成して情報の更新がしばらく行われないなら、
明らかに静的に生成する方が有利だろうけど。
楽天の様に、様々な店舗があって情報更新が激しいと、
静的に生成する処理の負荷の方がバカにならないんじゃないか、と。
楽天がどうだかは知らないけどね。
0157nobodyさん
2005/08/15(月) 22:58:44ID:???0158nobodyさん
2005/08/15(月) 22:59:15ID:8q2yV0LVblog全般がコメントやトラックバックがあった時も静的ファイルを書き換えてる作りなの？
その方式じゃないとblogとは呼べないの？
つか、CMSがhtmlファイルを動的に生成するサイトを静的なサイトとは定義しづらいと思うがなぁ。
0159nobodyさん
2005/08/15(月) 23:00:06ID:???システム設計の経験はおありでしょうか？
最後の商品が売れたタイミングで、在庫切れのページを作ればいい。
バッチ回しておいて、期限が切れたら公開停止にすればいい。
0162nobodyさん
2005/08/15(月) 23:02:10ID:???問い合わせのたびに connect したり、検索効率の悪いテーブル構造とかでもない限り、
SQLで問い合わせるオーバーヘッドが問題になることは少ないぞ。
今時のシステムならSQLキャッシュとかもあるし、下手に静的HTML生成して、
セッション管理やシステム連携で苦労するなら、全体を動的に構築した方がはるかにマシ。
■ このスレッドは過去ログ倉庫に格納されています