アカウント名:
パスワード:
第38回PHP勉強会発表 [hatena.ne.jp]の「PHPの全バージョンを揃えよう」を見てからというもの、少なくとも業務で使える物じゃないなー・・・と。フレームの元ちっくな聞き方になりますけど、好んで使う理由とかあるんでしょうか？
この手の事ってPHP限定な事ではないよね。他の言語でも言えること。でこんな心配していたらどの言語もさわれなくなる。
いや、PHP限定ってことはないよ。少なくとも「仕様」と「実装」が分かれている言語はそうじゃない。
ANSI CやANSI Common Lispのような標準仕様がある言語と、そうでない言語は明らかに違いがある。
PHPが問題なのは、実装以外に仕様を定めているものがないこと。しかもphp.ini等の設定によって挙動が変化するから、ポータブルなコードを書くことが非常に難しい（環境AからもってきたPHPスクリプトと環境BからもってきたPHPスクリプトを環境Cで問題なく動くとどうやって確信できるのか？）。
また、PHPは言語仕様の修正が無計画で場当たり的だという印象を受ける。Rubyほどラディカルに言語仕様をいじっているわけじゃないけど、逆に一見動いていそうに見えて問題が隠れているという体験がPHPでは少なくない。JavaとPHPを比較してみれば、PHPの方が後方互換性を大事にしていないことは明らかなことです。
しかもPHPは外部ライブラリのバージョンアップに追随する必要にも迫られている。PHPのコア言語とPHPで書かれたライブラリとC言語で書かれたモジュールが渾然一体となっているのがPHPの処理系であり、おいらの感覚からは「カオス」としか言いようがない。Hardened PHPのようなプロジェクトもあるけれど、おそらくPHPしかできないプログラマーにその必要を理解させることは無理で、それが理解できるくらいならPHP以外の選択肢も使えるようになると思う。
Webアプリの黎明期だとPerl CGIとJava SevletとPHPくらいしか選択肢がなかったからでは？フレームワークも無しにSevletを使うのは日本のプログラマー（笑)には荷が重すぎるし、Perl CGIも決して楽ではない。
それらに比べれば、PHPは小規模Webサイトを作る上で「とても便利なオモチャ」だったと思います。そのオモチャを「プログラミング言語」だと誤解して本格的に使おうとすると、酷いしっぺ返しを食らうということでしょう。
それも、あくまで「当時は」の話であり、今だとその後のツギハギ拡張のセンスのなさが際立つので、使いたくない言語の代表になってしまいました。
>今だとその後のツギハギ拡張のセンスのなさが際立つので、個人的にはPerlの方が継ぎ接ぎな感じがある。それとPerlっとあまり美しくない気がする。特によく使う機能としては関数での引数(@_)の扱い。他の言語みたいに関数名(引数)って受け取り方ができないから
さらにPerl CGIと書いていることからPerlのモジュール版ではないと解釈するけどCGIのオーバーベッドが気になる。後、レンタルサーバによってはCGIはcgi-bin内でないと駄目とか設定されているとトップページからシステムを持って行けないのが辛い。リダイレクトさせても良いけど美しくない。Java系はコストパフォーマンスが悪い。
そういえばオープンソース系のCMSの多くではPHPが利用されていますね。日本で人気があるXOOPSや海外で人気があるDrupal(ホワイトハウスのサイトもこれを利用)や他のCMSも
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
PHPこわい (スコア:0)
第38回PHP勉強会発表 [hatena.ne.jp]の「PHPの全バージョンを揃えよう」を見てからというもの、少なくとも業務で使える物じゃないなー・・・と。
フレームの元ちっくな聞き方になりますけど、好んで使う理由とかあるんでしょうか？
Re: (スコア:0)
この手の事ってPHP限定な事ではないよね。
他の言語でも言えること。
でこんな心配していたらどの言語もさわれなくなる。
Re:PHPこわい (スコア:2)
いや、PHP限定ってことはないよ。少なくとも「仕様」と「実装」が分かれている言語はそうじゃない。
ANSI CやANSI Common Lispのような標準仕様がある言語と、そうでない言語は明らかに違いがある。
PHPが問題なのは、実装以外に仕様を定めているものがないこと。しかもphp.ini等の設定によって挙動が変化するから、ポータブルなコードを書くことが非常に難しい（環境AからもってきたPHPスクリプトと環境BからもってきたPHPスクリプトを環境Cで問題なく動くとどうやって確信できるのか？）。
また、PHPは言語仕様の修正が無計画で場当たり的だという印象を受ける。Rubyほどラディカルに言語仕様をいじっているわけじゃないけど、逆に一見動いていそうに見えて問題が隠れているという体験がPHPでは少なくない。JavaとPHPを比較してみれば、PHPの方が後方互換性を大事にしていないことは明らかなことです。
しかもPHPは外部ライブラリのバージョンアップに追随する必要にも迫られている。PHPのコア言語とPHPで書かれたライブラリとC言語で書かれたモジュールが渾然一体となっているのがPHPの処理系であり、おいらの感覚からは「カオス」としか言いようがない。Hardened PHPのようなプロジェクトもあるけれど、おそらくPHPしかできないプログラマーにその必要を理解させることは無理で、それが理解できるくらいならPHP以外の選択肢も使えるようになると思う。
Re: (スコア:0)
Webアプリの黎明期だとPerl CGIとJava SevletとPHPくらいしか選択肢がなかったからでは？
フレームワークも無しにSevletを使うのは日本のプログラマー（笑)には荷が重すぎるし、
Perl CGIも決して楽ではない。
それらに比べれば、PHPは小規模Webサイトを作る上で「とても便利なオモチャ」だったと思います。
そのオモチャを「プログラミング言語」だと誤解して本格的に使おうとすると、酷いしっぺ返しを
食らうということでしょう。
それも、あくまで「当時は」の話であり、今だとその後のツギハギ拡張のセンスのなさが際立つので、
使いたくない言語の代表になってしまいました。
Re: (スコア:0)
>今だとその後のツギハギ拡張のセンスのなさが際立つので、
個人的にはPerlの方が継ぎ接ぎな感じがある。
それとPerlっとあまり美しくない気がする。
特によく使う機能としては関数での引数(@_)の扱い。他の言語みたいに関数名(引数)って受け取り方ができないから
さらにPerl CGIと書いていることからPerlのモジュール版ではないと解釈するけど
CGIのオーバーベッドが気になる。
後、レンタルサーバによってはCGIはcgi-bin内でないと駄目とか設定されていると
トップページからシステムを持って行けないのが辛い。リダイレクトさせても良いけど美しくない。
Java系はコストパフォーマンスが悪い。
そういえばオープンソース系のCMSの多くではPHPが利用されていますね。
日本で人気があるXOOPSや海外で人気があるDrupal(ホワイトハウスのサイトもこれを利用)や他のCMSも
Re: (スコア:0)
しかし、procやlambaの混沌っぷりを見ていると、結局Rubyもセンスが良いとはいえません。
洗脳された信者は気づかないのかもしれませんが・・・