そうかな。java好きだけどな。
確かに自分だけが見て書くならphpでもperlでもいいかもしれないが
他人のphpのソースはひどいものはひどい。
その点javaでちゃんとオブジェクト思考で書いたたとえばstrutsは
見やすい。ちゃんとオブジェクト思考を理解している人が書けばまあ
案外はずれはない。
後さ、板違いかもしれないがhtmlのテーブルレイアウトで基地外みたいな
ソースを書くやつもいる。htmlでもここまできたなくかけるのかとちょっと
関心してしまった

PHPの特徴（Javaと比較して）

・アプリケーションスコープが存在しない
・マルチスレッドではなく、マルチプロセスで動作
・シリアライズはバグがあるため、使用に耐えない
・マルチプロセスのためシングルトンは本来の意味をなさない
・OOPはオーバーヘッドをまねく
・コネクションプーリングがない
・インタプリタ方式のため配備が容易である反面、実行が緩慢
・複雑なロジック構築には向かない
・スキルが高い技術者がいない（有能な技術者は他へ流れる）

>>453
日本語おｋ
比較対象が、>>446のような頭弱いやつが作ったサイトでは意味が無い

OOPはオーバーヘッドをまねくとかどの言語にも言えることを
PHPの特徴として挙げてるのが頭弱そうだなｗ

俺も昔Javaは遅いって偏見もってたけど自分で実装したら爆速だった。

OOPにするとリフレクションを使ったフレームワークがでてくるんだが、
これがとにかく重い。

だけど最近のJavaフレームワークはバイトコード書き換えライブラリで
リフレクションの重さを消してるから大きな差がでる。

>>455
OOPはオーバーヘッドをまねくとかどの言語にも言えない。
JavaはデフォルトがOOPなので「オーバーヘッド」とは言葉の意味として変。

他の言語で言えば、Objective-Cは早さを求める部分だけはC言語を使う。
OOPしたいときはObjective-C特有の記述を行う（処理が若干遅い）。
この言語ではオーバーヘッドだと言える。

PHPも同様。手続き型が早く、OOPするとオーバーヘッド。

phpは速度がいらない用途に使われることで
javaと住み分ければいい。

だからphpの命運はrubyしだいじゃないの？

データベースを使用しないサイトではPHP有利。

しかし、データベースを使用するサイトでは
同じデータのためにユーザー別にデータベースに取りに行く羽目に
なるから悲惨。シングルトンも中途半端で意味ないし。

ユーザー固有のデータをユーザー別に取りに行くのであればわかるが。。。

javaってタグ出力１行ずつなの？

>>462
質問の意味、不明

servletはリクエストごとにデフォルトで2000文字のレスポンスバッファ（メモリ）が
用意されてて、上から一行ずつレスポンスバッファにコピーされていく。
そしてバッファが満タンになるごとにブラウザへネットワーク出力される。
つまり2KB毎の出力。（大きく出来るが）

単純な実行速度の差（forループが速いとか）なら誰も気にしないんだけど、
キャッシュを作ったりするプログラマ側の工夫・テクニックが
phpには利用不可なところで大きな差がでるんだよ。

>>462
ついでにいうと、PHPの例を上げてもらうとJavaの場合を説明しやすい。
基本的にPHPよりもJavaの方が選択肢が多いと考えたほうがいい。

PHPに小技を使うプログラマを意図的に追い出して
初心者と上級者のコードの差をなくしたい目的があるなら
それでもいいかもしれんが、目的の為の結果ではなく
単なる設計上の失敗でこうなってるわけだ。

>>460にあるようにPHPであればリソースがムダになるのがデフォルトなのでパフォーマンスでは不利だろうね。

>>460の弱点を補うために共有リソースをJSON化し、JavaScriptで読む設計を見たとき、PHP大変だなと思った。

javaはWEBには向かない非効率過ぎだろう

>>469
たとえば？

>>469
で?

完全論破されたPHPユーザの末路だな。

これまでPHP使ってた程度の低い連中が
最近Rubyに流れ出したらしく、railsだかherokuの人が怒ってたな。

>>472
で?

リアルタイム通信対戦が作りたい（けど作れない）
phpゲームボーイが発狂してるのかな

PHPの特徴（Javaと比較して）

・アプリケーションスコープが存在しない
・マルチスレッドではなく、マルチプロセスで動作
・シリアライズはバグがあるため、使用に耐えない
・マルチプロセスのためシングルトンは本来の意味をなさない
・OOPはオーバーヘッドをまねく
・コネクションプーリングがない
・インタプリタ方式のため配備が容易である反面、実行が緩慢
・複雑なロジック構築には向かない
・高いスキルをもつ技術者がいない（有能な技術者は他へ流れる）

急に書き込みが止まったところをみると
PHP関連に金を貢いじゃったゲームボーイだったようだなｗ

「PHPの特徴（Javaと比較して）」

・リアルタイム通信対戦が作れない(´；ω；｀)
・糞本を発注して小遣い失ってしまう(´；ω；｀)
・ゲームボーイが発狂してしまう(´；ω；｀)
・セキュリティが弱く攻撃されてしまう
・プロセスでアクセスを裁く
→プロセスは遅い
→アプリケーションスコープが存在しない
→オブジェクトプールが作れない（IO負荷が大きい）
→リソースプールが作れない（コネクションetc）
・非同期リクエストが使えない
・インタプリタ方式のため配備が容易であると嘘をついてしまう
・名前空間が衝突しやすく、大規模システムや多人数開発に向かない
・スキルが高い技術者ほど苦労する言語仕様
・もともとOOPでないためオブジェクト指向の機能が弱い
・アダルトサイトやアダルト広告はphpで決まりだね☆

JAVAはミドルウェアやフレームワークがいろいろ絡みすぎ。
売切りのサイトならいいが、十年以上自分でメンテして行くサイトなら嫌すぎる。

その辺はPHPも十分ややこしくなって来とるけどな

更新が遅いってのは利点でもあるな。

PHPはフレームワーク乱立でJavaと同じ過ちに突っ込んで手遅れ。
AppサーバがApache2に統制されてるからサーバの設定だけは保守性高しかな。

>>475
facebookは違う。PHPコードからC++に変換している。
変換する意味はPHPの性能が低いから。たぶん、facebook開発者はこんなに流行するとは思ってなくて
苦肉の策でHipHopを作った。

>>481
>>484
サーバー管理者の立場から言うと、PHP自体のアップデートが多すぎて手間がかかる。
また乱立するPHPのモジュール。PHP4から5。またPHP5の数多くのバグフィックスなど。
もうね、ひどすぎる。
またメモリ食いが醜い。Javaみたいに1プロセスでドーンとメモリの幅を取るのはわかりやすいが、
PHPはそうじゃないのでアクセス増えてきたらとんでもないことになる。
追い打ちをかけてシリアライズにバグありで分散処理がいまだに信頼できず、
あっぷあっぷしている。といってもPHPの開発者はPHPしかできない人が多く、
分散の意味すらわかっていない。やっぱりPHPは小規模のサイトがぴったり。

PHP大変そうですね。小規模というか1人で開発＋サーバー1台だけ
で済むものぐらいでしょう。

>>485
あほくさ。それ管理になってないじゃんw
スケール決めずになんでもかんでも行き当たりばったりで突っ込んだら
なに使っても同じ目に遭うわw

>>487
確かにスケールはからずにPHP使ったのがすべての間違いでした。
分散処理がここまで難ありだとは思いもよりませんでした。
言語自体のバグはどうしようもありません。

>>90
分散処理云々を言語に頼るのがナンセンスw

>>489
他言語では分散処理を見越した機能がはじめからありますので・・・。
たとえばJava。

PHPもJavaにならって一部のみ後付けされたようですが、
バグがありますのでどうしようもありません。

>>489
たとえば、
JavaのEJBをPHPで実現できる方法を教えていただけませんでしょうか？

>>491
バカすぎるw
何の評価もせずにPHPでなんでもできると思ってたのかw

>>492
PHPを導入したのは私じゃありませんので。

PHPがJavaよりも機能や性能が劣るのは十分承知していますので
Javaでの作り直しを進めているところです。

ただいかんせん、PHPしかできない人ばかりで困っています。

使う人間の無能っぷりを言語に押し付けちゃあかんわw
僕がいれたんじゃないから知りませんとか管理にもなってないし。

楽な職場だなあ。

今日も釣れたな・・・。

ごめんね。今まで書いたことは作り話でした。

うわ、かっこわるw

これは恥ずかしい

さてと、

本日釣られた方>>492は実現できないとおっしゃっていますが、

やはりPHPではJavaのEJB相当の機能はないのでしょうか？

単純にロードバランサーとアプリケーションサーバーで分割するぐらいしか
できないんじゃないの？

分散オブジェクトで機能分散する規模では
遅かれ早かれ作り直すしかない。