PHPは本当に悪いのですか？ 私は誘惑されることはありません-彼の欠点の多くを知っています。 私の個人的なリストには、最初に非常識な変数参照システムがあります。
a）オブジェクトのクローンを実質的に無用にし、
b）
<upd>ハックは公式ドキュメントのコメントに記載されています。 誤解したすべての人に謝罪します。 </ upd>
2番目の場所は、完全にクレイジーなエラーシステムです。 PHPには2.5種類のエラーがあり、バージョン7の時点で既に2.5の基本的な例外のクラスがありますが、Throwableインターフェイスの例外とは一切関係ありません。それ自体がエラーを引き起こします。 そして、それは__halt_compilerとexit関数をカウントしていません。
一般的に、すべてが悪いです。 しかし、PHPは、システム設計から個々の機能的な問題の解決まで、開発のすべてのレベルでの言語の誤用に対しても同様に有害です。 そして、それは私が意味することです...
ハイパーテキストプリプロセッサ
PHPはハイパーテキストプリプロセッサです。 ほとんどの場合（非常に特殊なものを除き、その意味は理解できません）、PHPは、コンソールコールであれHTTPリクエストであれ、テキスト環境で動作します。 そして、テキストの性質を持っているので、彼はそれで素晴らしい気分です。
PHPの主なデータ型は文字列です。 少なくとも、__ toIntや他のスカラーコンバーターへの言及がない場合、単一の変換マジックメソッド__toStringが存在することは、この考えを示唆します。 この問題を詳しく見ると、実際に辞書である配列はより論理的になります。 結局、整数がない場合、インデックスは存在できません。 しかし、文字列キーがあります。その特定のケースは、整数を含む文字列です（既存のキー変換はこの考えを強化します）。 予期しない結果を生成する比較は、テキスト表現にも依存します（ただし、安心する必要はありません）。
スカラー型と配列要素の型の型ヒントがないことは、関数が文字列、文字列とオブジェクトの配列を引数として受け取り、文字列を返すことを意味します。 バージョン5.4では、引数を関数にすることもできます。5.3よりも少し前の段階で、クロージャーが登場しました。クロージャーは文字列ではなく、オブジェクトと呼ばれます。 したがって、文字列データとそれらを処理するツールがあります-これはPHPのミニチュアであると言えます。 バージョン7では、スカラー型が表示されていましたが、「Javaのように」OOPのような言い訳のように見えます。 ところで、彼について。
通常のゲッターとセッターの代わりにPHPに存在する魔法のメソッド__getと__setは、一見すると、ある種のナンセンスに見えます。 しかし実際には、コードを記述する段階でオブジェクトの明確な構造を知らなくても、プロパティを動的に操作できる非常に強力なツールです。 どうしてこれが必要なのでしょうか？ オブジェクトを単独で考えると、これは無意味な山のように見え、定型文を書くことを強制します。 ただし、オブジェクトを外部ツール（拡張機能やAPIなど）のインターフェイスと見なす場合、そのようなソリューションは理にかなっています。 たとえば、__ get、__ set、および__callを使用して、ストアドプロシージャを呼び出して設定を変更することで実行される、非常に便利なオブジェクトデータベースマネージャーを作成できます。
同様に重要なのは、マジックメソッド__sleep、__ wakeup、および__set_stateを使用して、スクリプト呼び出し間でオブジェクトの状態を保存する機能です。 繰り返しになりますが、オブジェクト自体を物としての観点から見ると、カプセル化をほこりに分解するのは災害です。 ただし、オブジェクトがスクリプト外で動作する何かのインターフェイスである場合、これは上記の例からの同じデータベースへの永続的な接続と同じくらい論理的です。 PHPは死ぬために作成されました。つまり、アプリケーションではなくスクリプトを作成するために設計されました 。
ファルコンストライク
私はスカラー型のヒントと、オブジェクトのメンバーの可視性の制限、そしてほとんどの場合役に立たないデストラクタの両方が好きです-理論的にはこれは追加の機会を与えるからです。 しかし、馴染みのあるプログラミング言語の構築との類似性により、馴染みのある開発アプローチが選択され、PHPで機能しないため、PHPでの必然的な失望につながります。
PHPは、戦略よりも戦術においてはるかに強力です。 彼の作品の論理は、 「ヒットラン」と呼ばれる優れた部隊を扱うよく知られた方法に似ています（おそらくそれが彼が新人が好きな理由でしょうか？）。 機能性の面では、彼は拡張機能に大きく依存していますが、その拡張機能には膨大な量があります。 そのため、通常はすべての呼び出しですべてをロードします（ただし、疑わしいdlがあります ）。 後者は議論の余地のあるアイデアですが、PHPでは基本的に、機能自体ではなくインターフェイスが読み込まれるため、何らかの形で機能します。 ただし、これはリソースオーバーランの妨げにはならず、廃止された機能を除き、PHP 7は以前のバージョンと比較して大幅に速度が向上しました。 しかし、それはそうかもしれません-木星に許可されていることは雄牛に許可されていません。 そして、この場合フレームワークとCMSである雄牛は、同じロジックに従います。
WordPressを扱った人にとって、このCMSは明らかに最良の例ではありません。 それにもかかわらず、これは最も人気のあるCMSの1つであり、W3Techsによると、すべてのサイトの25％で動作します。 そして、これが世界中のほぼ4分の1のサイトで起こっていることです。 REST APIへのリクエスト（およびスタイルやスクリプトへのリクエストも含む）を含むすべての HTTPリクエストに対して、以下が発生します。
1）CMS自体のかなり大きなコアを読み込みます。念のため、PHPで記述された多くのツールが含まれています 。
2） PHPで記述された すべてのプラグインをロードします。多くのプラグインはかなりの機能を備えており、現時点で必要かどうかを判断することはまったくありません。
そして、これらすべては、疑わしい芸術的価値のあるHTMLページをレンダリングするためのものです。 それは、パンを買いに近くの店に行くために1時間染まる女性を思い起こさせます。 この25％のサイトに誰も来ないことを願うだけです。
世界中のサイトの何パーセントがPHPを使用しているのかわかりませんが、ほとんどのサイトでフレームワークも使用しています。 Doctrineを見たことがありますか？ いいえ、彼らは実際にDQL パーサーを作成しました 。 PHPで。 これはデコレーターは言うまでもありません。 ところで、これらの人たちはTwigを書いた。 また、PHPでも。 私は、これらが上品な専門家の力と時間に費やされた優れた製品だとは言いません。 私はただ理解していない、そしてここではPHP。 同じ成功を収めて、シェルでこれをすべて書くことができました。
私の議論と議論することができますが、テストによって判断すると、 Pallconがあります。 私の意見では、これは右への一歩に過ぎませんが、方向性は非常に明確です。 FastCGIを使用して、Cでアプリケーションサーバーを作成し、同じDBMSと同じようにPHPで動作させてみませんか？ 拡張機能をインストールするだけでなく、PHPバージョンをアップグレードできないペニーホスティングが以前の理由である可能性があり、それでも疑わしいです。
正直なところ、PHPがチューリング完全であることを後悔することがあります。
おわりに
合理的な疑問が生じるかもしれません-なぜ本格的なプログラミング言語としてPHPが率直に弱いのに、なぜPHPが必要なのでしょうか。 Cで書くこともできます。 またはJavaで。 はい、何でも。 私の意見では、PHPを使用すると、アプリケーション自体の機能に集中することができ、PHPでの開発が簡単で便利なハイパーテキストインターフェイスから分離できます。 結局のところ、データベースロジックは、DBMSおよびユーザーインターフェイスロジック（JS、Android SDKなど）を使用して開発するのに便利です。 それぞれのツールは、その場所で良いと他のすべての人に悪いです。
PHPには、PHPを使用したプログラミングを非常に不快にする多くの問題があります。 言語の移植は、最終製品を目標とする開発者が望んでいることではありません。 しかし、PHPは最初の1年間は埋葬されていませんが、これまでのところかなりいい感じです。 言語自体が改善され、新しい、より意味のあるツールが表示されます。 確かに、他の言語から軽率にコピーすることにより、国民のニーズにより多くのイノベーションが発生するほど、これらのまさに他の言語の存在下でのPHPの有用性についてより多くの疑問が生じます。 PHPには多くの潜在的な可能性があり、残念ながら実装されていないため、これは特に面倒です。