パスワードを忘れた？ アカウント作成
Close
6883 story

大規模Web開発に向いた言語は何か 219

ストーリー by koyhoge
所詮ツールは使い方次第 部門より

yukichi 曰く、 "「PHPはちょっと」という記事が Excite Japan CTO 井上氏のBlogに出ています。 発端は楽天の楽天事業カンパニー開発本部 開発推進部部長、安武弘晃氏の「CNET Japan - 「要は使い方次第」：楽天、PHPを語る」という記事です。"(後半に続く)

"ここで、安武氏は、社内にPHPを取り入れたことについて

システムというのは積み木のようなもの。問題が起こるとしたら組み合わせの問題だろう。これまで楽天では工夫してシステムを積み上げていったので、PHPの大規模開発も問題なく成り立っている。
開発期間が短くて済むため、数カ月単位で環境が変わってしまうインターネット業界に適している。PHPは早くて安くてできないことはほぼないと言ってよいだろう。
と語っており、それに対し、井上氏は
PHPではやろうと思えばスクリプト中でなんでも出来るため、他の人が引き継げなくなる恐れが大きい。また、1人～3人程度で開発している分には良いのだが、複数人数での開発は厳しい。へたをすると、ロジックとプレゼンテーションを切り分けるという大原則さえ簡単に破られる。（そんなこと気にしたことない人は、これを機会に考えてください。）小規模で十分シンプルなサービスなら適用できるというのが私の考えだ。
と語っています。 で、その代わりにJavaをあげ
基本的な機能は全て言語側でサポートしているため、APIとにらめっこしていると少ない行数で動くアプリケーションが出来上がる。また、C/C++のような自由度、不明度がない。Javaで書く分には個人差はあまり発生してこないと思う。イコール、メンテが楽、引継ぎが楽、ということになると思う。
とメンテナンス性をポイントに挙げています。
また、それに呼応して、別のある方(お名前確認できず)は、「大規模開発では PHP や Perl よりも Java、という話について」というblog記事で、
Perl も strict な構文を意識して、コーディング規則をしっかりと設ける、テストをコードにより自動化するといった作業を徹底することで、複数人数開発での一貫性は確保できると思います。より複雑かつ大規模な開発においてはフレームワークを適用することで設計やコーディングに縛りをつけて、整合性を保つ。この辺の話については、言語が何であろうと変わらないですね。ただ、そういった話題をするときに Perl、PHP、Ruby といった Lightweight Language を題材に扱われること自体が稀なために、「スクリプト言語は大規模開発には向かない」という先入観が世の中に浸透してしまっているような気がします。
と語っています。

実際に現場で採用される言語は言語性能よりも実績などのほうが重視されるきらいがありますが、みなさんは、どう思われますか?　みなさんが、現場で言語を採用するとしたら、どのような基準をとりますでしょうか?"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

大規模Web開発に向いた言語は何か More

  • 思いっきり素人がなんですが… (スコア:3, すばらしい洞察)

    by kamuy (1690) on 2003年11月14日 17時54分 (#434222) ホームページ 日記
    つか、タレコミ文にもしっかり書かれてはいる訳ですが、結局大規模開発に向いた「開発体制は?」と云うコトになるような気がします。
    しっかりとした分業体制や継続開発・後々のメンテが出来る体制さえ出来ているならば、使う言語は使い慣れたもので良いやとか、いざとなったら別の言語に乗り換えてしまえとか、そんな感じなのではないですかね?

    もちろん、そんな体制が簡単に築けるなら苦労はせん、というのが実情なのだろうというのは、分かりますが…

    #ホントに素人考えなんです。
    #業務でデスマーチなコトになっている皆さん、気に障ったらごめんなさい。
    --
    -+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-

    • Re:思いっきり素人がなんですが… (スコア:2, 興味深い)

      by Coo-Neruasobu (17846) on 2003年11月14日 18時55分 (#434283)
      > 結局大規模開発に向いた「開発体制は?」と云うコトになる

      野良猫コーダーなので大規模とかチームとか縁遠い言葉なのですが、人や開発体制ってそんなに安定しているとは思えず、崩れた時に言語や環境、フレームワークといったセーフティーがあるなら十分にポイントになると思います。
      そういう部分は Perl/PHP にアビリティが無いとは思わないのですが、国内では未成熟な部分だと思っとります。

      > 使う言語は使い慣れたもので良いやとか、いざとなったら別の言語に乗り換えてしまえとか、そんな感じなのではないですかね?

      については元記事のエッセンシャルサーチエンジンで
      ポータルなどは本当にたくさんのサービスがあるので、サービスごとに違うアーキテクチャを採用しようと思えば出来る。しかしそれをやってしまうと「統一してよ」と運用部門(Operation)が怒るのは目に見えている。

      また、サーバーを買うからには同じアーキテクチャでそろえた方が、余分な作業なしに使いまわしが出来たりして、足りない部分に簡単に振り分けられるので資源の有効活用が出来る。エキサイトのようにハードウェア投資にシビアな会社は、こっちはPHPで書いたので別のサーバーを買うなんてことはしない。

      出来るだけ同じアーキテクチャで統一し、どのプログラムがどのサーバーでも動くようにしておいた方が、冗長性があるというものだ。これはハードウェア購入だけでなく、ラックスペースに払う金額もセーブできる。

      とカウンターになる理由が語られています。
      エグゼクティブの視点だと思って読むと説得力は高いです。
      シェア
      親コメント
      • ＞出来るだけ同じアーキテクチャで統一し、どのプログラムがどの
        ＞サーバーでも動くようにしておいた方が、冗長性があるというも
        ＞のだ。これはハードウェア購入だけでなく、ラックスペースに払
        ＞う金額もセーブできる。

        これはよくわからんなー。
        Javaしか動かないハードウェアとか、PHPしか動かないハードウェアっていうのが
        あるわけじゃないよね。JavaでもPHPでも、たいがいのマシンで動くし。
        なんで使用言語を統一することがハードウェア購入金額の節約に結び付くの？
        ほんとうにわからないので教えてください。
        ＃運用コストが下がるのはよくわかるんだけど。
        シェア
        親コメント
    • > 結局大規模開発に向いた「開発体制は?」と云うコトに
      > なるような気がします。

      私もここがポイントなんだと思います。で一つ問題提起させていただきたい。

      大きな企業の場合は大抵信用を重んじるので、既に実績のあるもの、90年代に実績がある Perl, PHP を選択すると思います。そして猛烈な資金を投じて（リファクタリングもさせない、堅いプロセスで）使い捨てプログラムを書かせます。数ヶ月で状況変わるからそ、のたびにプログラムも一から書き直させればよいということなのでしょう。

      しかし「メンテナンス費用はかかる。寿命は数ヶ月。そんなものに投資していていいのか」と問いたい。大企業ならともかく、中小は100%ムリ。

      だから、中小にははシステムの資産と負債の違いを知って、資産にだけ投資していただきたい。で、その観点から技術基盤の選択をすると、PHP や Perl では綺麗なコードは書きづらいので（負債をせっせと作ってしまう）、永続的なメンテナンスがしやすい Python か Ruby を選択してほしい。そして、何十年にわたって使える資産、リファクタリングされたメンテナンスしやすいコードを書くのがよいでしょう。
      シェア
      親コメント

      • Re:思いっきり素人がなんですが… (スコア:2, 参考になる)

        by programmer (12835) on 2003年11月15日 0時46分 (#434512)
        PHPで綺麗なコードは書きにくいですか？
        Perlはたしかにいろんな書き方ができるし省略記法が多すぎるので
        綺麗なコードにはなりにくいですが、PHPはそんなことないのでは？
        どちらかというと、PHPの問題は（ほかのコメントにもありますが）
        HTMLとロジックとをごちゃごちゃにしてしまいがちという点でしょう。

        でもまあ、いちばん綺麗なコードが書けるのはRubyでしょうね。
        Javaも綺麗なコードが書けるし汚いコードになりにくいですが、
        RubyはJavaに負けず汚いコードになりにくいし、Javaよりはるかに
        簡潔に書けるのがうれしい。実行速度に言及されると弱いが。
        ＃Pythonはよくしらんのでパス。
        シェア
        親コメント

      • この提案の最も非現実的な点は，　何十年に渡ってメンテナンス出来る人材を確保・維持することが事実上不可能なことを無視していることです．

        シェア
        親コメント

  • デザイン屋の技術力 (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2003年11月14日 18時13分 (#434237)
    今のWebアプリケーション開発って記事もふれられているけど、
    プレゼンテーションとロジックの分業ってのは、絵を作る側
    にロジック側に依存した、その言語のタグを埋め込んで
    貰うわけだが、はたして今のプレゼンテーション側の作成者に
    それが出来ているの（技術力があるか）かが疑問。

    結局、紙芝居だけ貰って後はロジック開発者側が、
    HTMLにタグを埋め込んでいくと言うの未だに多いのでは
    無いでしょうか・・。
    （私の周りの環境だけか？)

    分業が完全に出来れば生産性もあがるとは思うが、
    それってデザイン屋が知っている言語と、
    ロジック屋が知っている言語とがマッチして
    居なければならないわけですが、貴方（皆さん）の所は
    どうですか？　旨くかみ合っていますか？

    • Re:デザイン屋の技術力 (スコア:1)

      by tomatsu (2545) on 2003年11月14日 18時48分 (#434275)
      知っているべき技術的概念に対して、あまりにも無知な職業技術者の割合が多すぎると思います。

      一般のGUIアプリケーションでも、ロジックとプレゼンテーションを分離して考えられない技術者が大勢います。というか、UIとロジックという分け方の概念が乏しくて、技術者同士ですら画面イメージのみで機能の説明をしてる事の方が圧倒的に多いのでは？

      どの職場に行っても、知識＆経験不足というより、目を向ける方向や努力の仕方などの根本的な思想が技術者に不向きな人ばかり。

      どうしてこうなってしまったんだろう。
      シェア
      親コメント
    • プレゼンテーション界隈の住人でも優秀な人なら即慣れてくれます。

      その辺の更新が遅い人に対しては、例えば Dreamweaver + Smarty プラグインのようなツールが代替えになってくれると思います。
      まぁ Smarty が大規模とかいう今回のストーリーに合っているかどうかはおいといて。

      ちょっと背伸びして手が届く現実という所で Movabletype/2ch-blog ライクなテンプレート型の HTML と CSS だと思っているのですがどうでしょう。
      シェア
      親コメント

  • 常識のウソ? (スコア:2, 興味深い)

    by Anonymous Coward on 2003年11月14日 18時55分 (#434281)

    自分では使わずに話を聞いただけですが、PHP5 [atmarkit.co.jp] はかなり普通のオブジェクト指向言語になりつつあるような印象を受けます。OOP が身についた人なら、Java で書いても PHP5 で書いても同じような構造になるのではないかと思いますが…。

    ところで「やろうと思えばスクリプト中でなんでも出来る」のは、PHP に限ったことではないですよね。Java だって同じことだと思います。他にも Perl を「何でも出来る便利さゆえ他の人が見ると全く分からないプログラムになる」、Javaを「C/C++のような自由度、不明度がない」「Javaで書く分には個人差はあまり発生してこないと思う」と評しているのが本当に正しいか、どの範囲でこれらの主張が成り立つかは、議論してみる価値があると思います。

    • Re:常識のウソ? (スコア:2, 参考になる)

      by Coo-Neruasobu (17846) on 2003年11月14日 19時10分 (#434292)
      アビリティで言えばそうかも知れませんが、Java の教育環境、マーケティング、上がってくるコーダーの質や属性が元記事の結論を引き出しているのではないでしょうか。
      コメントで突っ込まれている部分は元記事やトラバで議論を交わしている人たちも前提で分かっている事で、元記事はプログラマの視点ではなく技術統括責任者の視点なので そちらの角度から検討してみるとどうでしょう。
      PHP でも「出来るよ」とは言えますが最高の選択肢だ！とは言えず相互評価したらそこは Java に譲ると思います。その分 Java 側が払うべきコストも生じるのですが。。
      結局 NDO の naoya さんが言う
      Java の成功はマーケティングの産物だと、著名なエンジニアの誰かが言ったのを聞いたことがあります
      なのだと思いました。
      シェア
      親コメント

      • Re:常識のウソ? (スコア:2, 参考になる)

        by yukichi (12361) on 2003年11月14日 20時38分 (#434354) ホームページ
        このJavaの部分は、まつもとゆきひろさんの日記 [rubyist.net]の以下の箇所かと思います。

        Bjarne(引用者注:C++の作者)はこのAarhus出身なのだそうだ。「俺のホームタウンはどうだ、いいだろう」という感じだった。気さくな人だ。

        「C++のような世界的に重要な言語のデザイナーっていうのはどんな気分」と聞いたら、「うーん、単なる偶然。そういうものが必要と思って作っただけだから」とのこと。

        「Javaについてどう思う」という問いには「興味ない。書けと言われれば書くけど、技術的には面白いものはないから。あれはマーケティングの産物だよね」だそうだ。私以上に技術屋だ。ま、それはそうか。

        シェア
        親コメント

    • Re:常識のウソ? (スコア:1)

      by wwe (16718) on 2003年11月14日 19時40分 (#434314)
      結局のところ、プログラム言語論は宗教戦争になるわけで…
      最終的には、個々の技術と個々のその言語に対する信仰度によるんじゃないかなと…、少なくともプログラマーの観点からは…

      (参考: 普通のやつらの上を行け [dreamhost.com])


      微妙にPHP、JAVA両方でプログラムしてますがID
      シェア
      親コメント

      • Re:常識のウソ? (スコア:1)

        by deleted user (13014) on 2003年11月14日 22時33分 (#434427)
        スクリプト言語は今 Ruby Python Perl PHP の四つ巴が大戦争中。用途が全く同じで、共存の余地は無いと思います。

        ゆっくりとですが、一つのものに収斂してくるでしょう。（ここの競争に使い方次第も何も無い。使いづらいものが死ぬのみ）
        シェア
        親コメント

  • ふーん (スコア:2, 興味深い)

    by partial (18305) on 2003年11月15日 0時19分 (#434488)
    結局、言語程度でウロチョロして開発方法論まで辿りつけないから今の惨状があるんだよね。

  • 色々な可能性を探ってみる (スコア:2, 参考になる)

    by mera (2504) on 2003年11月15日 2時44分 (#434565) ホームページ 日記
    　言語の特性から考えて見る事と、開発体制の整えやすさから考えてみる事と、各言語のサポート体制から考えてみる事と、とりあえず３つの視点から考えてみます。

    　まず、言語の特性。これは技術者のスキルによって様々なので言語のスキルで大規模開発に向いているとか、向いてないとか考えるのはあまりあてはまらないような気もします。　PHP は DBコネクションプーリングが出来ないとかありますが、プロキシを使えば問題無いのでは？　という気がします。　将来的に改善されるかもしれません。　どの言語も将来的に出来なかった事が出来るようになるかもしれません。　今蓄積しているあなたが得意な言語のノウハウは大規模開発に向かない言語だと言われてたとしても決してムダになる事はないでしょう。　でも「今」を基準に考えると言語毎に多少差はあるのかもしれませんが、技術者のスキルで十分埋まる差だと思います。

    　次に開発体制の整えやすさ。今はどの言語も経験豊富な技術者を雇うのは難しいのではないでしょうか？　「Java技術者？ あぁ、すっげぇ奴知ってるよ。でもよその会社でバリバリやってて忙しいから多分つかまんないかもねぇ」　って知り合いを持ってる人は沢山いらっしゃるんじゃないでしょうか？　いい奴程そいつの会社が離さない(笑)　いい技術者であるほど収まるべきところに収まっている、そんな状態。　後はなかなか就職できない、もしくは派遣で食ってるけどすぐ追い出されて転々としてる人で溢れ返っている(汗)　そんなわけでどの言語に比較的スキルン高い技術者が沢山分布しているかが見極めのポイントかもしれません。　いくらスキルが高くても入院したらもう代わりの人がいないようじゃ話になりません。　大変です、本人も同じ事を感じてプレッシャーを感じています(笑)　そこそこのスキルがあって沢山の技術者がいればいる程、または確保しやすい程大規模開発に向いてるのかもしれません。　え？ VB6 が大規模開発に向いているって？　うがー、やめてくれー。

    　最後に言語のサポート体制。いくら開発をするといってもお客さんが首を縦に振ってくれなかったら開発できません。ゴーサインをもらう為にはお客さんが安心してくれる必要があります。　まずは企業のサポートが（内容はとりあえず問わない）ついててそれなりにブランドがあってお高いものであるとよさそうですね、実績も大事です。　えーと、Java。アプリケーションサーバがとっても高価です。.NET。天下のマイクロソフト様のフレームワークです、お客様は多分後光がさしてるように見える事でしょう。　PHP？あまり聞いた事ないなぁ。 Perl？ あぁ、よく色々なところにフリーでおちてるCGIのことだろ？ そんなもので大丈夫なのか？　と、お客様はかなり心配そうです。　自社開発でも社長が首を縦に振ってくれなかったらこれも結構大変そうです。　でもこれは自社の利益を守るためにどこの社長様も必死なので(長いので以下略・・・

    結局のところは、色々な言語を要所要所抑えておき、時と場合によって使い分ける器用さが技術者に必要なんじゃないかと思います。「この言語が優れている・・・」と議論しているのでは言語に振り回されているだけなのでは？　と思うのでした。さぁ、宗教戦争なんかもうやめてもっと柔軟な眼をもとう。　そして会社に利益をあげさせて貢献し、多いなる発言力を得てから自分の好きな言語で好きなものを作ってハッピーな生活を手に入れるんだ！！

    恐らく超少数派になるであろうとっても優れた技術者のたまごへ。PHP中毒者より

    ＃書いてるうちに電波っぽくなってしまったよ、すまそ。
  • オフトピですけど・・・

    ルールを無視したコードを書いたプログラマに対する罰則規定を明文化するってのはどうなんでしょう。システム開発において、コーディングに関するルールは社則扱いでも構わない気がするんですよね。ちゃんとしたルールであれば、それに従わないと後で会社に損害をもたらす可能性がある訳ですから。

    どうでしょう?

    • Re:ルールを無視したコード (スコア:2, 参考になる)

      by Anonymous Coward on 2003年11月14日 18時20分 (#434244)
      ルールを作って従わせるためのコストとルールを無視したコードによって生じる潜在的コストの両方を比較してみましたか?
      シェア
      親コメント

    • Re:ルールを無視したコード (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年11月14日 18時09分 (#434233)
      「社則を決定する連中はコードのことなんか全く分かっていないのでトンデモ規則が出来る」に1票。

      # 笑えないのでAC
      シェア
      親コメント
      • 「行番号は 1000 から 10 きざみで」とか?
        --
        -- 哀れな日本人専用(sorry Japanese only) --
        シェア
        親コメント
      • １関数１ファイルとか、C++で継承使うなだとか...
        それに、今はまっとうなルールでも状況が変化すれば糞になりうるんだし、ル
        ールでなくマナーをソースコードレビューでも繰り返して醸成するしかないん
        じゃね?
        シェア
        親コメント

        • Re:ルールを無視したコード (スコア:3, 参考になる)

          by SteppingWind (2654) on 2003年11月15日 0時30分 (#434494)

          実際に数100人規模のプロジェクトを経験してみると分かりますが，現場のプログラマで継承の概念を理解しているなんてのは数％もいれば多いぐらいです．その数％でさえ有効に継承が使えるかと言えば極めて怪しい．言語の機能としての継承は使えても，システム設計として継承が使えないという場合が非常に多いです．

          そのため極少数（数人程度）の共通技術チームのみが制限なしでコードを取り扱えるようにして，残りは制限をかけるという方式のほうが，まだましな物ができます．とは言っても，この方式が通用するのも１００人前後の質の高いメンバーが揃ったプロジェクトまでですけどね．それ以上の規模になると，常識では想像できないような腐れコードが機械的に量産されてきます．

          シェア
          親コメント

        • Re:ルールを無視したコード (スコア:1, 興味深い)

          by Anonymous Coward on 2003年11月14日 18時59分 (#434284)
          一. oopを使って部品の再利用性を高める設計を行う事
          一. 継承の概念は複雑度が上がり、引継に問題があるので使用しない事

          という感じのを実際に目にしました。
          その会社の人はまったく無視していましたが。
          これを守るとするとなにも書いてはいけない事になって、、、

          「、、、してはいけない」とか「、、、しなくてはいけない」
          ってコーディング規約はめちゃくちゃなのが多い。
          シェア
          親コメント
    • そういうのはテンションが下がるから(･A･)イクナイ！　とおもうですよ。
      --

      (I can't get no) satisfaction
      シェア
      親コメント

    • Re:ルールを無視したコード (スコア:1)

      by pyon (1702) on 2003年11月14日 18時28分 (#434258)

      ルールに則ったからと言って理解しやすいコードとは限らない。

      --
      -- pyon
      シェア
      親コメント
    • 罰則規定は、モチベーションが下りますから、
      止めたほうが良ろしいかと。
      詳しくはトム デマルコ [amazon.co.jp] の本をどうぞ。

      プログラマ同士でソースコードを交換して、
      お互いプレゼンしあう環境が欲しいですね。

      他人が見ると思うと、きれいに書く習慣が身につくと思います。

      きちんとデザインができていれば、
      実装は、それなりでも良いものになりますよ。
      シェア
      親コメント
    • プログラマの能力って正規分布していないからなんですよね。能力が平均以上の集団であれば、モチベーションを維持してクオリティをって議論が成り立つと思うのですけど、最初からモチベーションが底辺な人達も大勢いる訳で・・・
      シェア
      親コメント

  • javaが妥当かな？ (スコア:1, 参考になる)

    by Anonymous Coward on 2003年11月14日 18時28分 (#434259)
    結局フレームワークとして環境がそろっているのと、
    (腐っている部分も大量にあるが)技術者の確保の容易さを考えると
    Javaでしょうね。
    と、言いますかWebApplicationを書くと言う行為において言語は
    あまり問題にならないかと。javaが優位な点はフレームワークなり
    アプリケーションサーバーなりの環境が非常に有利になっている点です。
    元の話はWebテクノロジ(若干意味不明だが)で話が始まっているのに
    いつの間にか複数人で開発する言語はどれがいいかって話になっている。
    これはWebアプリに限らず一般的なプロジェクトではどの言語を選択するかって話になると思いますが。
    もっとも言語の選択よりプロセス管理のほうが非常に深刻な状態になつつあるんだが。
    #ROIってうるさくて…

  • 言語なんてどうでもいいから (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2003年11月14日 18時37分 (#434267)
    一つのexcite IDで複数の接続サービスを購入できるように してくださいませ。おながいします。
  • とか言いたいがなぁ。

    トランザクションモニタ配下のCOBOLだったら、勝手なことは出来ないし、フレームワークとしてもきっちりしてる。でも、結局いろんなことは「規約」を作って縛らないと縛り切れない。

    個人的にはCOBOLは好きなんだが、Javaマンセーな奴は聞く耳は持たんだろう。でも、COBOL+TPモニタでも、EJBでも、ドメインが同じならやってることに大差はない。それはPHPでも同じこと。

    まーそーいったわけで、言語がどーだこーだという問題ではないと思うんだけどな。業務がわかる技術者が生産性高く品質高く作れて、人を集めやすければそれでいいかと。

    まぁ言い古されたことだとは思うけどね。
    • ＞業務がわかる技術者が生産性高く品質高く作れて、人を集めやすければそれでいいかと
      御意。以前、大規模WebApplicationの構築で、Javaのコンサルという名目で参加したことありますが、請け負ったベンダーさんの方達はJava未経験のCOBOL屋さんばかりで、マジでCOBOLでCGI書いた方がいいんじゃないか？と思いましたよ。
      残念なことに、私が行ったときには、全て「これは決定です。変更できません」ばかりで、どうしようもない状態でしたけど。何のためのコンサルなんだか (-_-;;;
      シェア
      親コメント

    • 個人的な経験では，開発言語がどうこうという議論をやっているプロジェクトで成功したためしがないんですけどね．

      むしろ昔からオープン系システムやオープン系・メインフレーム連携システムを多く手がけている部隊の方が，業務分析，システム設計，実装アーキテクチャ設計あたりで効率を稼ぐ術を心得ているように思えます．

      シェア
      親コメント

  • はたしてそーなのか？ (スコア:1, 参考になる)

    by Anonymous Coward on 2003年11月15日 0時08分 (#434482)
    Java専門でやってる人はJavaが良いと思うだろうし、
    PHP専門でやってるとPHPの方が楽だと感じるだけでは？とも思うけど、
    他人が書いたソースが読めないってのは、
    読む側の能力と書く側の良識による部分が多いと思う。

    経験上PHPが保守に耐えないとは感じた事はない、
    むしろ、やっつけで書かれたJavaのソースの方が読みづらいと感じる。

    あと、APIを睨まないと書けないのって利点じゃない、
    この人勘違いしてるよ・・・。

    ついでに言えば、PHPもJavaも用途を間違うと使い勝手は悪い
    システムが作られてしまう、よくC/Sが時代遅れのように言われるが、
    用途によっては、C/Sのシステムも多くの点で優れている点も多い、
    言語も用途で使い分けできないと厳しいよね。
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー