PHPが非推奨になった理由

2000年、私はPHPの大ファンでした。 4月にバージョン4.0が正式にリリースされた直後に使用を開始しました。 当時、彼に加えて、ウェブサイトを作成するための選択肢は4つしかありませんでした。



1)C-頻繁に変化するプロジェクトには複雑すぎる。 編集には多くの時間がかかり、無料のツールはほとんどなく、有料のものは予算に収まりませんでした。 冗長すぎる。 依存関係の管理には注意が必要でした。



2)JavaはCよりも優れていますが、冗長であり、長時間コンパイルされます。 依存関係の管理には注意が必要でした。



3)Perl-パッケージ管理システムなしでのみ、PHPとほぼ同じくらい良い。 CPANにはあらゆる場合に対応するモジュールのセットがありましたが、ダウンロードしてインストールする必要がありました。 依存関係の管理には注意が必要でした。



4)ASP-PHPとほぼ同じくらい、Microsoftのツールでしかなく、その使用は私を彼らの高価な世界に引き込むでしょう。



3つのポジションについて、「依存関係の管理は困難でした」と書きました。 私にとって、これはPHPの重要なポイントでした。 彼の哲学は「オールインワン」でした。 現在のようなパッケージ管理システムはありませんでした。 現在、RubyのBundlerやClojureのLeiningenのような便利なものがあります。 しかし、2000年ではありません。 Linuxパッケージ管理システムでさえ2000年以降改善されています。 また、オールインワンシステムは、PHPのパッケージ管理の問題を解決しました。 しかし、この利点は重要ではありません。



PHPには他の長所もあります。 Web用に最適化されていますが、今日ではユニークではありません。 Cを恐れている人のために、彼はCの機能のラッパーを提案しました。しかし、他の言語では、 今日でも簡単です



ジュリアの現在の問題は、ライブラリが比較的不足していることです。 しかし、この言語では、Cの既存のライブラリと対話するのは非常に簡単です。他の言語とは異なり、Cで1行も記述せずにCコードを呼び出すことができるため、Juliaのライブラリはすぐに追いつくと思います。 私の経験では、Juliaコードの150行からCコードの5,000行を使用することができました。




過去数年にわたって、私はさまざまな企業( Wine SpectatorTimeout )で彼らのシステムで働いてきました。 ほとんどはPHPとsymfonyフレームワークでした。 私は以前それらをすでに批判しました 。 最近、企業の仕事でPHPを使用する人は、以前PHPが好きだった理由を忘れてしまったようです。 2000年に彼がどのような利点を持っているかわかりますが、今日は? それは遅く、不器用で、システムが複雑になりすぎており、コンパイルされていない言語の本質がその上で大規模なプロジェクトを作成しようとしています。 100台のサーバーを必要とするプロジェクトでCMSを作成する場合、100台のサーバーのそれぞれにCMS全体を展開する必要があります。



今日、PHPの世界にはどのような革新が存在しますか?



言語に並行処理を行うためのツールがない場合、人々 はpthreadを追加します。 対照的に、 Clojureを見てください



Symfonyの洗練されたコードキャッシングシステム



注釈はコメントに追加されます-プログラムの実行を制御する命令。 これは悪い考えだと思う。 横断的な関心事をモデル化する必要がある場合、注釈のような粗雑なソリューションに頼るのではなく、エレガントにそれを行う言語を選択する必要があります。



問題のある開発の長い歴史のために行う必要がある変更と修正のリスト



腫れたメモリ管理



儀式プログラミングは不必要な命令の集まりであり、コンパイル段階でチェックするような利点はありません。 2000年、PHPを支持する議論の1つは、Javaに典型的な余分なコードがなかったということでした。 PHPを完全にJavaに変えたいですか?



複雑さのための複雑さへの愛



管理および構成する設定はありません。 これは、Ruby、Python、またはClojureとは異なり、PHPが苦しんでいたパッケージ管理システムの欠如に似ています。 しかし、PHPでは、状況を修正するための作業は行われていません。これは、ChefやSupervisorなどのシステム管理ツールの肩に引き継がれています。



豊富なモンキーパッチ (実行中のプログラムクラスのメソッドおよび属性値の置換)。 特性は、Rubyのモンキーパッチに似ていますが、特性の操作や追跡、デバッグはさらに困難です。



言語そのものを追い越す野望 。 Fabien Potansierが言ったように、PHPにはいくつかの素晴らしい特性があります。 それは奇妙です。 さびたフィアットに強力なフェラーリエンジンを挿入したかのようです。



利便性のために導入された無数の関数



そして、私は有名なエッセイ「 PHP:貧弱なデザインのフラクタル 」を思い出さずにはいられません。



PHPがクールなもの(ストリームとイテレーター)に出くわすと、PHPは言語に統合されるのではなく、言語に釘付けになります。 彼らは言語哲学の一部として感じられません。 代わりに、 ラムス・ラードルフは次のようなことを言っています。



プロパティ、抽象メソッド、コンピュータサイエンスの先生があなたに言ったこれらすべてのゴミを保護しました。 私はすべてのこのたわごとについて気にしません。




それに比べて、 松本幸弘はRubyを次のように説明しています。



私にとって、人生の意味の一部は喜びです。 プログラマーは、プログラミングの創造的な側面に集中できるようになると喜びます。 Rubyはプログラマーを幸せにするように設計されています。 速くて楽しい仕事をするなら、それは良いことですね。 あなたの人生は良くなっています。 コンピューターを使用して日常のタスクを解決したいので、プログラムを作成します。 Rubyを使用して、「print void hello world」という言葉でプログラムを開始しなければならないような言語の魔法のルールではなく、自分がやっていることに集中したいと思います。




PHP開発チームのリーダー間の深いビジョンの欠如は、特にPHPで優れたコードを記述する方法に関する初心者プログラマーへの指示欠如につながります。



2004年、Ruby On Railsが突然登場し、Javaの複雑さやPHPの混乱からすべての人を救うことを約束しました。 当時は大きな改善でした。 構造的でエレガントで、PHPでは利用できません。 しかし、今日では、 Railsでさえも廃止されています。 今日、RubyとPHPは並列処理では同等に機能しません。 それらは、コンピュータープロセッサに1つのコアがあり、時間が経つにつれてより高速になったときに開発されました。 しかし、未来はアムダル法則に従い、この方向では彼らは何も提供しません。 jRubyはRubyの未来であり 、今日検討する価値のある言語の1つです。 しかし、「これはPHPの未来です」と言えるような言語はありません。



「今日なぜ自分でPHPを選択するのか」という質問に、人々に答えてもらいたいのです。 2000年、彼に対する議論は説得力があったが、今日ではそのような理由はない。 世界は変わりました。そして今、より良い機会がたくさんあります。



All Articles