PHP est-il le pire langage de programmation ?

J'ai près de vingt ans d'expérience en programmation et j'ai développé dans divers langages de programmation. Dans de nombreux emplois que j'ai occupés et dans le travail que j'occupe actuellement, je suis très heureux d'avoir eu PHP comme langage de programmation principal. Dès la première fois que j'ai commencé à travailler avec PHP, j'ai entendu toutes sortes de plaintes à propos de PHP, mais en même temps j'ai aussi vu la puissance de PHP.

PHP est au moins un langage de programmation intéressant. Le langage et les programmes construits avec lui relèvent généralement de deux philosophies de conception. Ici, je ne parle pas des cycles de vie du développement logiciel comme Waterfall ou Agile, mais de l'idée de base de ce que devrait être un logiciel. Ces idées sont appelées « La bonne voie » et « Le pire est le mieux ».

PHP est un autre langage de programmation plutôt étrange. Quand les gens se plaignent que le langage est « nul », ils n’ont pas tort. Il y a effectivement beaucoup de points négatifs dans ce langage. À l’époque, la langue connaissait des problèmes encore plus terribles. Le billet de blog qui se moque de PHP, « PHP : une fractale de mauvaise conception », contient quelques arguments valables, même s'ils étaient obsolètes lors de sa publication il y a neuf ans.

Cependant, en même temps, les développeurs peuvent utiliser PHP pour créer des logiciels structurellement « corrects » et importer des philosophies d'autres langages considérés comme de bonnes pratiques. Des frameworks comme Laminas et Symfony utilisent les meilleures pratiques de la programmation orientée objet, permettant aux développeurs d'écrire du code structurellement correct à l'aide de ces frameworks.

Comment PHP fait-il cela ? C'est parce que PHP est le pire langage de programmation.

Logiciel de conception

En 1991, Richard P. Gabriel a publié un article « Lisp : Good News, Bad News, How to Win Big » (Lisp : Good News, Bad News, How to Win Big). L’argument de cet article est qu’une philosophie « le pire est le mieux » serait le meilleur choix en matière de conception et de longévité des logiciels. Il est arrivé à cette conclusion parce qu'il a reconnu l'émergence de deux écoles de programmation différentes, qu'il a appelées le « style MIT/Standford », ou « la manière correcte », et le « style New Jersey », ou « le pire est le mieux ».

Les deux philosophies ont des objectifs similaires mais diffèrent dans des domaines clés. Les deux styles se concentrent sur quatre domaines clés de la philosophie philosophique : la simplicité, l’exactitude, la cohérence et l’exhaustivité.

Le style MIT est décrit comme ceci :

• Simplicité : Le design doit être simple, quelle que soit sa mise en œuvre ou son interface, il doit être simple. En comparaison, il est plus important de garder l’interface simple.

• Correction : La conception doit être correcte dans tous les aspects observables. Ne présumez pas faire une conception incorrecte.

• Cohérence : Le design ne doit pas être incohérent. Pour garantir la cohérence, vous pouvez légèrement sacrifier la simplicité et l'exhaustivité. La cohérence et l'exactitude sont tout aussi importantes.

• Exhaustivité : La conception doit couvrir autant de situations importantes que possible. Toutes les situations attendues doivent être couvertes. L’exhaustivité doit avoir la priorité sur la simplicité.

Quant au style New Jersey, Gabriel a déclaré qu'il définit ses objectifs comme suit :

• Simplicité : Le design doit être simple, que ce soit sa mise en œuvre ou son interface, il doit être simple. En comparaison, il est plus important de garder la mise en œuvre simple. La simplicité est la plus importante, et aucune autre fonctionnalité n’est aussi importante que de rester simple.

• Correction : La conception doit être correcte dans tous les aspects observables. Mais l’exactitude peut être légèrement sacrifiée au profit de la simplicité.

• Cohérence : Le design ne doit pas être trop incohérent. Dans certains cas, la cohérence peut être sacrifiée au profit de la simplicité. Si l’introduction d’une situation inhabituelle dans la conception rend la mise en œuvre complexe ou incohérente, n’y pensez pas.

• Exhaustivité : La conception doit couvrir autant de situations importantes que possible. Toutes les situations attendues doivent être couvertes. L’intégrité peut céder la place à toute autre caractéristique. En fait, l’exhaustivité doit être sacrifiée dès que la simplicité de mise en œuvre est menacée. Si vous souhaitez garder les choses simples, vous pouvez sacrifier la cohérence au profit de l'exhaustivité, en particulier la cohérence de l'interface.

La clé de ce débat est d'utiliser LISP et C comme exemples de la raison pour laquelle « le pire est le mieux ». Pour Gabriel, programmeur LISP, LISP est un meilleur langage que le C, aussi rapide que le C, et Common LISP a mis de nombreuses années à être conçu, développé et standardisé. Les spécifications qui définissent le langage s'appuient sur le meilleur de tous les différents LISP, et les environnements de développement modernes sont les meilleurs pour les développeurs LISP.

LISP est la bonne voie

LISP représente la « bonne voie » du développement logiciel. LISP est facile à interagir avec lui et vous pouvez interagir avec lui de différentes manières. Vous souhaitez appeler LISP depuis Fortran ? Vous pouvez appeler LISP depuis Fortran et transmettre des données, et vice versa. Vous pouvez utiliser avec plaisir toutes les fonctionnalités « de luxe » modernes de LISP tout en travaillant avec du code existant.

LISP a une conception cohérente grâce à ses spécifications. Si vous regardez un langage moderne comme Python, les spécifications contribuent grandement à fournir plusieurs backends et compilateurs, et ils interprètent ou compilent tous le code de la même manière. Les outils étaient de premier ordre et LISP en 1991 offrait tout le confort dont nous bénéficions encore aujourd'hui, comme le débogage par étapes, l'inspection des données et des éditeurs sophistiqués.

En tant que langage, LISP est complet. Il comporte une couche de programmation orientée objet avancée, un héritage multiple, des objets de première classe, ainsi que des fonctions et des types. LISP semble être le langage de programmation que les développeurs ont en tête.

En 1991, un langage de programmation comme LISP était probablement dans la meilleure forme qu'il ait jamais été. Cette exactitude technique n'a pas été prouvée par une utilisation réelle. Les développeurs LISP sont en déclin. La réputation externe du LISP a été ternie par des années de presse négative et de mauvais positionnement. Les gens n’y voient plus un moyen de fournir des logiciels aux utilisateurs finaux.

En termes de développement, LISP représente souvent bon nombre des mêmes idéaux que Big Design Up Front (BDUF). Si vous avez déjà utilisé une méthode de conception telle que le modèle Waterfall, vous aurez découvert quelques problèmes. La « bonne manière » met fortement l'accent sur la cohérence, l'exactitude et la garantie que tous les problèmes imaginables sont pris en compte.

LISP en lui-même n'est pas une langue unique, mais une famille de langues. Bien que Common LISP soit conçu pour être un standard, la mise en œuvre de LISP elle-même existe en fonction des différentes tâches qui doivent être effectuées. Un article sur le site Web de Lockless Inc pointe cette « fragmentation » comme l’un des facteurs déterminants de l’échec éventuel du LISP. Bien que LISP adhère à la « bonne manière » de concevoir des logiciels, cette fragmentation compromet la maintenance et la portabilité du code.

C et Unix sont dans le mauvais sens

Dans le même temps, en raison de l'émergence d'Unix, le langage C est progressivement devenu la méthode privilégiée pour le développement de logiciels. C a été conçu pour Unix et Unix a été conçu en C. Ses développeurs avaient une position de conception différente de celle du LISP du MIT et de ses auteurs.

En 1972, C a été conçu pour être un langage simple. En 1991, cela avait un peu changé, mais les principes de base du langage C restaient inchangés. Certaines fonctionnalités ont été ajoutées pour répondre aux besoins des développeurs et d'Unix. Le langage étant simple, il est facile d’écrire des compilateurs et des programmes. Bien que le langage ne vous empêche pas d'effectuer une programmation complexe, C possède environ 50 à 80 % des fonctionnalités dont un programmeur a besoin par rapport à LISP.

Cependant, le langage C est très portable. Il peut également fonctionner sur du matériel moins gourmand en énergie que celui couramment utilisé dans les logiciels et les environnements LISP. Ce facteur permet de compiler et d'exécuter le logiciel sur un plus large éventail de machines. C et Unix sont faciles à utiliser, et Gabriel pense qu'Unix et C deviendront viraux.

Le langage C a évolué pendant que Dennis Ritchie concevait et construisait Unix. Étant donné que les Bell Labs n'étaient pas autorisés à entrer officiellement dans le domaine informatique, Unix pouvait également être facilement distribué à une variété d'utilisateurs. Ces utilisateurs aident à corriger Unix en fonction de leurs propres besoins. Dennis Ritchie a pu assembler ces correctifs selon les besoins sans avoir à réfléchir à ces besoins à l'avance.

Contrairement à LISP, le C est encore largement utilisé aujourd'hui. Bien que les langages interprétés de haut niveau tels que PHP, JavaScript et Python soient le premier choix de nombreux développeurs, bon nombre de ces langages de haut niveau sont développés en C. Même si des concurrents comme Rust commencent à émerger, la capacité de fonctionner sur de petits appareils à faible consommation reste un point fort du langage C. "PHP est le pire" de la bonne manière."

- Richard Gabriel Quelques années après cette révélation, Rasmus Lerdorf a commencé à travailler sur un interpréteur de page d'accueil/formulaire personnel, ce que nous appelons maintenant PHP. PHP/FI est né du besoin de Lerdorf de maintenir sa page d'accueil et d'interagir avec les formulaires et les bases de données. PHP/FI n'a même pas été conçu comme un véritable langage de programmation, mais comme une couche de scripts et de fonctions au-dessus du langage C.

PHP est très simple

La conception doit être simple, que ce soit sa mise en œuvre ou son interface.

PHP utilise le langage C sous le capot, et nous avons déjà dit que cette partie est la "pire". Cependant, cela présente également certains avantages, le plus important étant un langage sous-jacent plus simple qui facilite son extension. Même si Hack/HHVM adopte une approche plus C++, PHP lui-même reste un langage C.

Cela ne prend que quelques heures pour apprendre la structure interne de ce langage. Elizabeth Smith a donné une excellente conférence sur les extensions PHP qui a beaucoup abordé le fonctionnement interne de PHP. Le langage lui-même s'appuie sur d'autres langages de style C, qui sont non seulement faciles à lire, mais également convertibles en d'autres langages de style C.

La plupart des interfaces PHP, ou bibliothèques standard, sont très simples, car la plupart des fonctions principales ne sont que des wrappers de diverses bibliothèques du langage C et sont ensuite exposées presque inchangées. Bien que cela entraîne certaines incohérences dans l’interface, cela fournit un environnement familier aux développeurs issus du C ou du C++.

Le langage PHP est très axé sur le développement web. Il est souvent très simple d'extraire des concepts de HTTP et de trouver des concepts similaires dans le langage. Vous souhaitez connaître les informations d’en-tête d’une requête ? get_headers() vous satisfera. Obtenir des informations sur la requête est aussi simple que de lire les variables globales $_GET et $_POST.

PHP maintient une interface de développement simple et maintient la structure interne aussi simple que possible.

PHP a (presque) raison

Dans tous les aspects observables, la conception doit être correcte. Mais l’exactitude peut être légèrement sacrifiée au profit de la simplicité.

Ici, PHP a tendance à choisir « simple » plutôt que correct. Avant l'avènement de HHVM, l'apparence et les fonctionnalités du langage n'avaient pas été standardisées. L'interpréteur Zend est la spécification elle-même, et la façon dont le langage se comporte est toujours « correcte » (à l'exclusion des erreurs réelles). Si vous souhaitez remplacer le moteur PHP par autre chose, vous devez implémenter toutes les fonctionnalités du moteur existant.

Les paramètres de la fonction LAX et les types de retour pour de nombreuses fonctions principales facilitent le travail du système. Des fonctions comme strpos() peuvent renvoyer des entiers ou des valeurs booléennes, ce qui est légèrement plus facile à gérer que les méthodes strictement conçues pour renvoyer des entiers ou lever des exceptions.

En regardant le développement du langage PHP, presque toutes les nouvelles fonctionnalités sont basées sur ce dont les développeurs ont besoin, plutôt que sur l'idée sérieuse de "il faut le corriger parce que c'est faux". Se concentrer davantage sur ces erreurs de type et d’exception strictes est une façon plus correcte de faire les choses. Cependant, il existe également des éléments tels que des fonctions de flèches courtes, des propriétés et des énumérations que les développeurs souhaitent utiliser pour simplifier leur code.

PHP ne nécessite pas de cohérence

Le design ne doit pas être trop incohérent. Dans certains cas, la cohérence peut être sacrifiée au profit de la simplicité.

Je ne vais même pas prétendre que PHP est cohérent, mais il l'est suffisamment. Les gens peuvent se plaindre de l’ordre des arguments aiguille/botte de foin lorsqu’il s’agit de fonctions de tableau ou de chaîne. Cependant, en général, les fonctions de tableau sont cohérentes et les fonctions de chaîne le sont également. Il est beaucoup plus simple d'être cohérent avec la bibliothèque C sous-jacente qu'avec le langage.

PHP est également suffisamment cohérent dans d'autres aspects. Comme je l'ai mentionné avec strpos(), PHP a tendance à renvoyer FALSE de manière assez cohérente pour les fonctions qui rencontrent une erreur. Ce n’est pas nécessairement exact, mais c’est cohérent. Les noms de fonctions soulignés et non soulignés correspondent généralement à leurs bibliothèques sous-jacentes.

Le langage PHP sacrifie la cohérence au profit de la simplicité, mais même sans cette spécification, il s'efforce toujours d'être cohérent là où cela a du sens.

PHP est aussi complet qu'il doit l'être

La conception doit couvrir autant de situations importantes que possible.

PHP est complet lorsqu'il s'agit de la tâche de conception la plus exigeante : l'écriture d'applications Web. PHP n’a jamais été conçu pour être un langage pouvant être appliqué à tous les problèmes du monde de la programmation. Néanmoins, sa simplicité le rend utilisable au-delà du Web. L’objectif initial de PHP était de fournir les fonctions les plus élémentaires pour la programmation Web, et cette tendance se poursuit aujourd’hui.

Les modifications apportées au langage principal sont souvent motivées par les besoins des développeurs. L'ensemble de la communauté propose des modifications, puis la communauté vote pour décider si la nouvelle fonctionnalité est rejetée, modifiée ou acceptée. De nombreuses innovations linguistiques découlent de la nécessité de faire avancer les choses rapidement. Même lorsque nous absorbons des fonctionnalités d'autres langages, c'est parce que cela facilite notre développement, rarement parce que d'autres langages le font « plus correctement ».

Aujourd'hui, vous pouvez développer des applications Web avec PHP. Dans cinq ans, vous pourrez toujours développer des applications Web en PHP, avec seulement quelques nouvelles fonctionnalités. Cependant, l'intégrité de la langue elle-même est adaptée aux besoins d'aujourd'hui. Nous pouvons toujours modifier la langue ou y ajouter de nouvelles fonctionnalités si nécessaire dans le futur.

Est-ce que pire, c'est mieux ?

Gabriel admet que la philosophie « le pire est le mieux » fait référence aux designs qui semblent mauvais et qui ne devraient peut-être pas être considérés comme une meilleure option. Le seul problème est que lorsqu'il examine les deux philosophies, « le pire est le mieux » finit toujours par être l'option la plus flexible, comparée à la philosophie de conception du MIT/« la bonne voie », « avec de meilleures caractéristiques de survie ». Si nous regardons PHP, nous pouvons confirmer l’idée selon laquelle « le pire est le mieux ».

Au fil des années, Gabriel admet qu'il a hésité entre la meilleure voie. La communauté PHP se demande si nous devons faire les choses correctement ou continuer à faire les choses simplement. Nous avons des frameworks comme Laminas, qui construisent des bibliothèques de manière informatique classique, puis nous avons des frameworks comme Laravel, qui se concentrent sur l'expérience et la vitesse des développeurs. PHP lui-même est les deux.

La prochaine fois que vous entendrez quelqu'un critiquer PHP, laissez-le partir. La langue est vraiment mauvaise. Mais à bien des égards, la longévité et l'utilisation généralisée de PHP témoignent du fait que faire les choses de la « bonne manière » n'est pas toujours mieux que de la « pire ». Lorsque quelqu'un se plaint du framework que vous utilisez, comprenez que cela n'a pas d'importance à long terme. Choisissez une philosophie de conception qui, selon vous, fonctionne pour vous et acceptez le fait que pire pourrait en réalité être mieux.

Lien original : https://www.phparch.com/2021/09/education-station-php-is-the-worst/

Auteur original : Chris Tankersley

Présentation de l'auteur :

Chris Tankersley a de nombreux Rôles : mari, père, auteur, conférencier, animateur de podcast et développeur PHP. Chris a utilisé de nombreux frameworks et langages différents au cours de ses 12 années de carrière en programmation, mais il passe la majeure partie de sa journée à travailler avec PHP et Python. Il est l'auteur de Docker for Developers et travaille avec des entreprises et des développeurs pour intégrer des conteneurs dans leurs flux de travail.

Apprentissage recommandé : "Tutoriel vidéo PHP"