PHPは最悪のプログラミング言語ですか?-見出し-php.cn

PHPは最悪のプログラミング言語ですか?

私には 20 年近くのプログラミング経験があり、さまざまなプログラミング言語で開発してきました。私がこれまでに携わってきた多くの仕事と、現在行っている仕事において、PHP をコアプログラミング言語として採用できることに非常に興奮しています。初めて PHP を使い始めたときから、PHP についてあらゆる種類の不満を聞きましたが、同時に PHP の威力も実感しました。

PHP は少なくとも興味深いプログラミング言語です。言語とそれを使用して構築されたプログラムは、通常、2 つの設計哲学に分類されます。ここで私が話しているのは、ウォーターフォールやアジャイルのようなソフトウェア開発ライフサイクルの話ではなく、ソフトウェアとはどうあるべきかという基本的な考え方です。これらの考え方は「正しい方法」と「悪いほど良い」と呼ばれます。

PHP もかなり奇妙なプログラミング言語です。人々がその言語が「ひどい」と不平を言うとき、それは間違いではありません。この言語には確かに悪いところがたくさんあります。昔、この言語にはもっとひどい問題がありました。 PHP を嘲笑するブログ投稿「PHP: 悪いデザインのフラクタル」には、たとえ 9 年前に公開された時点では時代遅れだったとしても、いくつかの有効な点があります。

ただし同時に、開発者は PHP を使用して構造的に「正しい」ソフトウェアを作成し、グッドプラクティスと考えられる他の言語から哲学をインポートすることもできます。 Laminas や Symfony などのフレームワークはオブジェクト指向プログラミングのベストプラクティスを使用しており、開発者はこれらのフレームワークを使用して構造的に正しいコードを作成できます。

PHP はどのようにこれを行うのでしょうか?これは、PHP が最悪のプログラミング言語であるためです。

設計ソフトウェア

1991 年に、Richard P. Gabriel は「Lisp: 良いニュース、悪いニュース、そして大きく勝つ方法」という記事を発表しました。》（Lisp:良いニュース、悪いニュース、大きく勝つ方法）。この記事の主張は、ソフトウェアの設計と寿命に関しては、「悪いほど良い」という哲学がより良い選択であるということです。彼がこの結論に達したのは、2 つの異なるプログラミング流派の出現を認識したためであり、それらを「MIT/スタンフォードスタイル」つまり「正しい方法」、および「ニュージャージースタイル」つまり「悪いほうが良い」と名付けました。

2 つの哲学は同様の目標を持っていますが、重要な領域で異なります。どちらのスタイルも、哲学の 4 つの主要な領域、つまり単純さ、正確さ、一貫性、完全性に焦点を当てています。

MIT スタイルは次のように説明されます:

シンプルさ: 実装やインターフェイスに関係なく、設計はシンプルでなければなりません。それに比べて、インターフェイスをシンプルに保つことがより重要です。
正確性: 設計は、目に見えるすべての側面において正確である必要があります。間違った設計を行うと決めつけないでください。
一貫性: 設計に一貫性がなくてはなりません。一貫性を確保するには、単純さと完全性を多少犠牲にすることができます。一貫性と正確性も同様に重要です。
完全性: 設計はできるだけ多くの重要な状況をカバーする必要があります。予想されるすべての状況をカバーする必要があります。シンプルさよりも完全性を優先する必要があります。

ニュージャージースタイルについて、ガブリエル氏はその目標を次のように定義していると述べています。

シンプルさ: 実装に関係なく、デザインはシンプルでなければなりません。どちらのインターフェースもシンプルでなければなりません。それに比べて、実装をシンプルに保つことがより重要です。シンプルであることが最も重要であり、シンプルであることほど重要な機能はありません。
正確性: 設計は、目に見えるすべての側面において正確である必要があります。ただし、簡潔にするために正確性が若干犠牲になる場合があります。
一貫性: 設計に一貫性がありすぎてはなりません。場合によっては、簡素化のために一貫性が犠牲になることがあります。設計に異常な状況を導入すると、実装が複雑になったり一貫性がなくなったりする場合は、考慮しないでください。
完全性: 設計はできるだけ多くの重要な状況をカバーする必要があります。予想されるすべての状況をカバーする必要があります。誠実さは他の特性に取って代わられる可能性があります。実際、実装の単純さが脅かされると、完全性を犠牲にする必要があります。物事をシンプルに保ちたい場合は、完全性を保つために一貫性、特にインターフェイスの一貫性を犠牲にすることができます。

この議論の鍵は、「悪いほど良い」理由の例として LISP と C を使用することです。 LISP プログラマーのガブリエルにとって、LISP は C よりも優れた言語であり、C と同じくらい高速であり、Common LISP は設計、開発、標準化に何年もかかりました。言語を定義する仕様は、さまざまな LISP の最良の部分を活用しており、最新の開発環境は LISP 開発者にとって最適です。

LISP は正しい方法です

LISP はソフトウェア開発の「正しい方法」を表します。 LISP は操作が簡単で、さまざまな方法で操作できます。 Fortran から LISP を呼び出したいですか? Fortran から LISP を呼び出してデータを渡すことも、その逆も可能です。レガシーコードを操作する場合、LISP の最新の「高級」機能をすべて快適に使用できます。

LISP は、その仕様により一貫した設計を備えています。 Python のような最新の言語を見ると、仕様は複数のバックエンドとコンパイラーを提供する上で大いに役立ち、それらはすべて同じ方法でコードを解釈またはコンパイルします。ツールは一流で、1991 年の LISP には、ステップデバッグ、データ検査、機能的なエディターなど、今日でも享受している快適な機能がすべて備わっていました。

LISP は言語としては完成しています。高度なオブジェクト指向プログラミング層、多重継承、ファーストクラスのオブジェクト、関数と型を特徴としています。 LISP は開発者が念頭に置いているプログラミング言語のようです。

1991 年、LISP のようなプログラミング言語はおそらくこれまでで最高の状態にありました。この技術的な正しさは実際の使用によって証明されていません。 LISP 開発者は減少しています。 LISP の対外的評判は、長年にわたる否定的な報道や誤った位置付けによって妨げられてきました。人々はもはや、ソフトウェアをエンドユーザーに配信する方法とは考えていません。

開発の観点から見ると、LISP は Big Design Up Front (BDUF) と同じ理想の多くを表していることがよくあります。ウォーターフォールモデルのような設計手法を使用したことがある場合は、いくつかの問題を発見したことがあるでしょう。「正しい方法」では、一貫性、正確さ、考えられるすべての問題が確実に考慮されることが重視されます。

LISP 自体は単一の言語ではなく、言語ファミリーです。 Common LISP は標準となるように設計されていますが、LISP 自体の実装は、実行する必要があるさまざまなタスクに基づいて存在します。 Lockless Inc の Web サイトの記事では、この「断片化」が LISP の最終的な失敗の決定要因の 1 つであると指摘しています。 LISP はソフトウェア設計の「正しい方法」に準拠していますが、この断片化によりコードのメンテナンスと移植性が損なわれます。

C と Unix は間違った方法です

同時に、Unix の出現により、C 言語が徐々に優先される方法になりました。ソフトウェア開発の。 C は Unix 用に設計されており、Unix は C で設計されています。その開発者は、MIT の LISP やその作者とは異なる設計スタンスを持っていました。

1972 年、C はシンプルな言語になるように設計されました。 1991 年までに、C 言語は少し変わりましたが、C 言語の基本原則は変わりませんでした。開発者と Unix のニーズを満たすためにいくつかの機能が追加されました。言語がシンプルなので、コンパイラやプログラムを書くのも簡単です。この言語によって複雑なプログラミングが妨げられることはありませんが、C には、LISP と比較してプログラマーが必要とする機能の 50 ～ 80% しか備わっていないと推定されています。

ただし、C 言語は移植性が高くなります。また、LISP ソフトウェアや環境で一般的に使用されているものよりも低電力のハードウェアでも実行できます。この要素により、より広範囲のマシン上でソフトウェアをコンパイルして実行できるようになります。 C と Unix は使いやすく、ガブリエルは Unix と C が普及すると考えています。

C 言語は、デニスリッチーが Unix を設計および構築している間に進化しました。ベル研究所はコンピュータ分野に正式に参入することを許可されていなかったため、Unix もさまざまなユーザーに簡単に配布できました。これらのユーザーは、自分のニーズに合わせて Unix にパッチを適用するのに役立ちます。デニス・リッチーは、事前にニーズについて考えることなく、必要に応じてこれらのパッチをまとめることができました。

LISP とは異なり、C は現在でも広く使用されています。 PHP、JavaScript、Python などの高級インタープリター言語は多くの開発者にとって最初の選択肢ですが、これらの高級言語の多くは C で開発されています。 Rust のような競合他社が出現し始めても、小型で低電力のデバイス上で実行できる機能は依然として C の強みです。

PHP は最悪です

したがって、「悪いほうが良い」ソフトウェアが第一に受け入れられ、第二にユーザーが受け入れられます。第三に、ソフトウェアは「正しい方法」に近づくまで継続的に改善されます。

- Richard Gabrie

この啓示から数年後、Rasmus Lerdorf は、現在 PHP として知られる個人のホームページ/フォームインタプリタの開発に取り組み始めました。 PHP/FI は、Lerdorf のホームページを維持し、フォームやデータベースと対話する必要性から生まれました。 PHP/FI は実際のプログラミング言語として設計されたわけではなく、C 言語上のスクリプトと関数の層として設計されました。

PHP は非常にシンプルです

実装でもインターフェースでも、設計はシンプルでなければなりません。

PHP は下部で C 言語を使用しますが、この部分が「最悪」であると以前に述べました。ただし、これにはいくつかの利点もあります。最も重要なのは、基礎となる言語がよりシンプルになり、拡張が容易になることです。 Hack/HHVM はより C のアプローチを採用していますが、PHP 自体は依然として C 言語です。

この言語の内部構造を学ぶのに数時間しかかかりません。 Elizabeth Smith は、PHP の内部動作について多くのことをカバーした、PHP 拡張機能に関する素晴らしい講演を行いました。言語自体は他の C スタイル言語を利用しているため、読みやすいだけでなく、他の C スタイル言語に変換できます。

PHP のインターフェイス、つまり標準ライブラリのほとんどは非常に単純です。コア関数のほとんどがさまざまな C 言語ライブラリのラッパーにすぎず、ほとんど変更せずに公開されるためです。これにより、インターフェースに多少の不整合が生じますが、C または C++ を使用する開発者にとっては使い慣れた環境が提供されます。

PHP 言語は Web 開発に重点を置いています。多くの場合、HTTP から概念を抽出し、言語内で同様の概念を見つけるのは非常に簡単です。リクエストのヘッダー情報を知りたいですか? get_headers() はあなたを満足させます。リクエスト情報の取得は、$_GET および $_POST グローバル変数を読み取るだけで簡単です。

PHP はシンプルな開発者インターフェイスを維持し、その内部構造を可能な限りシンプルに保ちます。

PHP は (ほぼ) 正しいです

設計は、目に見えるすべての側面において正しくなければなりません。ただし、簡潔にするために正確性が若干犠牲になる場合があります。

ここで、PHP は正確さよりも「単純さ」を選択する傾向があります。 HHVM が登場するまで、言語の外観と機能は標準化されていませんでした。 Zend インタプリタ自体が仕様であり、言語の動作は常に「正しい」です (実際のエラーを除く)。 PHP エンジンを別のものに置き換える場合は、既存のエンジンのすべての機能を実装する必要があります。

LAX 関数パラメータと多くのコア関数の戻り値の型により、システムの作業が容易になります。 strpos() のような関数は整数またはブール値を返すことができ、厳密に整数を返したり例外をスローするように設計されたメソッドよりも処理が若干簡単です。

PHP 言語の開発を見てみると、ほとんどすべての新機能は、「間違っているから修正しなければならない」という深刻な考えではなく、開発者が必要とするものに基づいています。これらの厳密な型エラーと例外エラーにさらに焦点を当てるのが、より正しい方法です。ただし、短い矢印関数、プロパティ、列挙など、開発者がコードを簡素化するために使用したいものもあります。

PHP には一貫性は必要ありません

設計に一貫性がありすぎてはなりません。場合によっては、簡略化のために一貫性が犠牲になることがあります。

PHP に一貫性があるなどと言うつもりはありませんが、十分に一貫性があります。配列関数と文字列関数に関して、needle/haystack の引数の順序について不満を言う人もいるかもしれません。ただし、一般に、配列関数には一貫性があり、文字列関数にも一貫性があります。言語内で一貫性を保つよりも、基礎となる C ライブラリと一貫性を保つ方がはるかに簡単です。

PHP は他の面でも十分な一貫性を持っています。 strpos() で述べたように、PHP はエラーが発生した関数に対してかなり一貫して FALSE を返す傾向があります。これは必ずしも正しいわけではありませんが、一貫しています。通常、アンダースコア付きの関数名とアンダースコアなしの関数名は、その基になるライブラリと一致します。

PHP 言語は、簡素化のために一貫性を犠牲にしていますが、この仕様がなくても、意味のあるところでは一貫性を保つよう努めます。

PHP の完全性は要件を満たしています

設計では、できるだけ多くの重要な状況をカバーする必要があります。

PHP は、Web アプリケーションの作成という最も要求の厳しい設計タスクに必要なときにいつでも完成します。 PHP は、プログラミングの世界のあらゆる問題に適用できる言語として設計されたわけではありません。それでも、そのシンプルさにより、Web 以外でも使用できます。 PHP の本来の目的は、Web プログラミングの最も基本的な機能を提供することであり、この傾向は現在も続いています。

コア言語の変更は、多くの場合、開発者のニーズによって行われます。コミュニティ全体が変更を提案し、コミュニティの投票で新機能が拒否されるか、変更されるか、または受け入れられるかを決定します。この言語における多くの革新は、物事を迅速に完了する必要性から生まれました。他の言語から機能を吸収する場合でも、それは開発が容易になるためであり、他の言語がそれを「より正確に」行うためであることはほとんどありません。

現在、PHP を使用して Web アプリケーションを開発できるようになりました。今から 5 年後、いくつかの新機能が追加されるだけで、依然として PHP で Web アプリケーションを開発できます。ただし、言語自体の完全性は今日のニーズに十分対応します。将来必要に応じていつでも言語を変更したり、新しい機能を追加したりできます。

悪いほうが良いのでしょうか?

ガブリエルは、「悪いほうが良い」という哲学は、見た目が悪く、おそらくより良い選択肢と考えるべきではないデザインを指すことを認めています。唯一の問題は、彼が両方の哲学を考慮した場合、「より良い生存特性を備えた」MIT の「正しい方法」設計哲学と比較して、「悪いほど良い」が最終的には依然としてより柔軟な選択肢であるということです。 PHP を見てみると、「悪いほど良い」という考えが確認できます。

ガブリエルは長年にわたり、どちらの方法が良いか迷ってきたことを認めています。 PHP コミュニティでは、物事を正しく行うべきか、単純に物事を続けるべきかについて議論してきました。古典的なコンピューターサイエンスの方法でライブラリを構築する Laminas のようなフレームワークと、開発者のエクスペリエンスと速度に重点を置いた Laravel のようなフレームワークがあります。 PHP 自体は両方です。

次に誰かが PHP を批判しているのを聞いたら、放っておいてください。言語は本当に悪いです。しかし、多くの点で、PHP の長寿と広く使用されているということは、物事を「正しい方法」で行うことが常に「最悪の」方法よりも優れているわけではないという事実を証明しています。あなたが使用しているフレームワークについて誰かが文句を言ったとしても、それは長期的には問題ではないことを理解してください。自分にとって効果的だと思われる設計哲学を選択し、悪いほうが実際には良いかもしれないという事実を受け入れてください。

元のリンク: https://www.phparch.com/2021/09/education-station-php-is-the-worst/

原著者: Chris Tankersley

著者について:

Chris Tankersley は、夫、父親、著者、講演者、ポッドキャストのホスト、PHP 開発者など、さまざまな役割を担っています。 Chris は 12 年間のプログラミングキャリアの中で、さまざまなフレームワークや言語を使用してきましたが、1 日のほとんどを PHP と Python の作業に費やしています。彼は Docker for Developers の著者であり、企業や開発者と協力してコンテナをワークフローに統合しています。

推奨学習: 「PHP ビデオチュートリアル」