Ist PHP die schlechteste Programmiersprache?

Ich habe fast zwanzig Jahre Programmiererfahrung und habe in verschiedenen Programmiersprachen entwickelt. Bei vielen Jobs, die ich hatte und die ich jetzt mache, bin ich sehr froh, PHP als meine Kernprogrammiersprache gehabt zu haben. Als ich zum ersten Mal mit PHP zu arbeiten begann, hörte ich alle möglichen Beschwerden über PHP, aber gleichzeitig erkannte ich auch die Leistungsfähigkeit von PHP.

PHP ist zumindest eine interessante Programmiersprache. Die Sprache und die damit erstellten Programme lassen sich im Allgemeinen zwei Designphilosophien zuordnen. Hier spreche ich nicht von Softwareentwicklungs-Lebenszyklen wie Wasserfall oder Agile, sondern von der Grundidee dessen, was Software sein sollte. Diese Ideen heißen „Der richtige Weg“ und „Schlimmer ist besser“.

PHP ist eine weitere ziemlich seltsame Programmiersprache. Wenn sich Leute darüber beschweren, dass die Sprache „scheiße“ ist, liegen sie nicht falsch. Es gibt tatsächlich viele schlechte Dinge an dieser Sprache. Damals hatte die Sprache noch schlimmere Probleme. Der Blog-Beitrag, der sich über PHP lustig macht, „PHP: ein Fraktal schlechten Designs“, enthält einige berechtigte Punkte, auch wenn diese bei seiner Veröffentlichung vor neun Jahren veraltet waren.

Gleichzeitig können Entwickler jedoch PHP verwenden, um strukturell „korrekte“ Software zu erstellen und Philosophien aus anderen Sprachen zu importieren, die als bewährte Verfahren gelten. Frameworks wie Laminas und Symfony nutzen die Best Practices der objektorientierten Programmierung und ermöglichen es Entwicklern, mit diesen Frameworks strukturell korrekten Code zu schreiben.

Wie macht PHP das? Das liegt daran, dass PHP die schlechteste Programmiersprache ist.

Design-Software

Im Jahr 1991 veröffentlichte Richard P. Gabriel einen Artikel mit dem Titel „Lisp: Good News, Bad News, How to Win Big“ (Lisp: Gute Nachrichten, schlechte Nachrichten, wie man groß gewinnt). Das Argument dieses Artikels ist, dass eine „Schlechter ist besser“-Philosophie die bessere Wahl wäre, wenn es um Softwaredesign und Langlebigkeit geht. Er kam zu diesem Schluss, weil er die Entstehung zweier unterschiedlicher Programmierschulen erkannte, die er „MIT/Standford-Stil“ oder „Richtiger Weg“ und „New Jersey-Stil“ oder „Schlimmer ist besser“ nannte.

Die beiden Philosophien verfolgen ähnliche Ziele, unterscheiden sich jedoch in wesentlichen Bereichen. Beide Stile konzentrieren sich auf vier Schlüsselbereiche der philosophischen Philosophie: Einfachheit, Korrektheit, Konsistenz und Vollständigkeit.

MIT-Stil wird wie folgt beschrieben:

• Einfachheit: Das Design muss einfach sein, unabhängig von seiner Implementierung oder Schnittstelle, es muss einfach sein. Im Vergleich dazu ist es wichtiger, die Benutzeroberfläche einfach zu halten.

• Korrektheit: Das Design muss in allen beobachtbaren Aspekten korrekt sein. Versuchen Sie nicht, ein falsches Design zu erstellen.

• Konsistenz: Das Design darf nicht inkonsistent sein. Um Konsistenz zu gewährleisten, können Sie Einfachheit und Vollständigkeit etwas opfern. Konsistenz und Korrektheit sind gleichermaßen wichtig.

• Vollständigkeit: Das Design muss möglichst viele wichtige Situationen abdecken. Alle erwarteten Situationen müssen abgedeckt sein. Vollständigkeit sollte Vorrang vor Einfachheit haben.

Was den New-Jersey-Stil betrifft, so definiert Gabriel seine Ziele wie folgt:

• Einfachheit: Das Design muss einfach sein, egal ob seine Implementierung oder Schnittstelle, es muss einfach sein. Im Vergleich dazu ist es wichtiger, die Umsetzung einfach zu halten. Einfachheit ist das Wichtigste, und kein anderes Merkmal ist so wichtig wie die Einfachheit.

• Korrektheit: Das Design muss in allen beobachtbaren Aspekten korrekt sein. Aber der Einfachheit halber kann die Korrektheit etwas geopfert werden.

• Konsistenz: Das Design darf nicht zu inkonsistent sein. In manchen Fällen kann die Konsistenz zugunsten der Einfachheit geopfert werden. Wenn die Einführung einer ungewöhnlichen Situation in den Entwurf die Implementierung komplex oder inkonsistent machen würde, denken Sie nicht darüber nach.

• Vollständigkeit: Das Design muss möglichst viele wichtige Situationen abdecken. Alle erwarteten Situationen müssen abgedeckt sein. Integrität kann jedem anderen Merkmal weichen. Tatsächlich muss die Vollständigkeit geopfert werden, sobald die Einfachheit der Implementierung gefährdet ist. Wenn Sie die Dinge einfach halten möchten, können Sie die Konsistenz zugunsten der Vollständigkeit opfern;

Der Schlüssel zu dieser Debatte besteht darin, LISP und C als Beispiele dafür zu verwenden, warum „schlechter besser ist“. Für LISP-Programmierer Gabriel ist LISP eine bessere Sprache als C, genauso schnell wie C, und es hat viele Jahre gedauert, Common LISP zu entwerfen, zu entwickeln und zu standardisieren. Die Spezifikation, die die Sprache definiert, stützt sich auf das Beste aller verschiedenen LISPs, und moderne Entwicklungsumgebungen sind die besten für LISP-Entwickler.

LISP ist der richtige Weg

LISP repräsentiert den „richtigen Weg“ der Softwareentwicklung. Die Interaktion mit LISP ist einfach und Sie können auf verschiedene Arten damit interagieren. Möchten Sie LISP von Fortran aus anrufen? Sie können LISP von Fortran aus aufrufen und Daten übergeben und umgekehrt. Sie können problemlos alle modernen „Luxus“-Funktionen von LISP nutzen, während Sie mit Legacy-Code arbeiten.

LISP verfügt dank seiner Spezifikation über ein einheitliches Design. Wenn Sie sich moderne Sprachen wie Python ansehen, tragen Spezifikationen wesentlich dazu bei, mehrere Backends und Compiler bereitzustellen, und alle interpretieren oder kompilieren Code auf die gleiche Weise. Die Tools waren erstklassig und LISP verfügte 1991 über alle Annehmlichkeiten, die wir auch heute noch genießen, wie Step-Debugging, Dateninspektion und ausgefallene Editoren.

Als Sprache ist LISP vollständig. Es verfügt über eine erweiterte objektorientierte Programmierschicht, Mehrfachvererbung, erstklassige Objekte sowie Funktionen und Typen. LISP scheint die Programmiersprache zu sein, die Entwickler im Sinn haben.

Im Jahr 1991 war eine Programmiersprache wie LISP wahrscheinlich in der besten Form, die sie je hatte. Diese technische Korrektheit wurde nicht durch den tatsächlichen Gebrauch nachgewiesen. LISP-Entwickler sind rückläufig. Der externe Ruf von LISP wurde durch jahrelange negative Presse und falsche Positionierung beeinträchtigt. Man betrachtet es nicht mehr als eine Möglichkeit, Software an Endbenutzer zu liefern.

In Bezug auf die Entwicklung repräsentiert LISP oft viele der gleichen Ideale wie Big Design Up Front (BDUF). Wenn Sie jemals eine Entwurfsmethode wie das Wasserfallmodell verwendet haben, werden Sie einige Probleme entdeckt haben. Der „richtige Weg“ legt großen Wert auf Konsistenz, Korrektheit und darauf, dass alle erdenklichen Probleme berücksichtigt werden.

LISP selbst ist keine einzelne Sprache, sondern eine Sprachfamilie. Obwohl Common LISP als Standard konzipiert ist, basiert die Implementierung von LISP selbst auf den verschiedenen Aufgaben, die erledigt werden müssen. Ein Artikel auf der Website von Lockless Inc weist darauf hin, dass diese „Fragmentierung“ einer der entscheidenden Faktoren für das letztendliche Scheitern von LISP ist. Obwohl LISP dem „richtigen Weg“ des Softwaredesigns folgt, führt diese Fragmentierung dazu, dass die Wartung und Portabilität des Codes beeinträchtigt wird.

C und Unix sind der falsche Weg

Gleichzeitig wurde die C-Sprache aufgrund des Aufkommens von Unix allmählich zur bevorzugten Methode für die Softwareentwicklung. C wurde für Unix entwickelt, und Unix wurde in C entwickelt. Seine Entwickler hatten eine andere Design-Haltung als LISP des MIT und seine Autoren.

1972 wurde C als einfache Sprache konzipiert. Bis 1991 hatte sich etwas geändert, die Grundprinzipien der C-Sprache jedoch nicht. Einige Funktionen wurden hinzugefügt, um den Anforderungen von Entwicklern und Unix gerecht zu werden. Da die Sprache einfach ist, ist das Schreiben von Compilern und Programmen einfach. Während die Sprache Sie nicht daran hindert, komplexe Programmierungen durchzuführen, verfügt C im Vergleich zu LISP schätzungsweise über 50–80 % der Funktionen, die ein Programmierer benötigt.

Allerdings ist die C-Sprache sehr portabel. Es kann auch auf Hardware mit geringerem Stromverbrauch ausgeführt werden, als dies üblicherweise in LISP-Software und -Umgebungen verwendet wird. Dieser Faktor ermöglicht es, die Software auf einer größeren Anzahl von Maschinen zu kompilieren und auszuführen. C und Unix sind einfach zu verwenden und Gabriel glaubt, dass Unix und C viral gehen werden.

Die C-Sprache entwickelte sich, während Dennis Ritchie Unix entwarf und baute. Da Bell Labs offiziell nicht in den Computerbereich vordringen durfte, konnte Unix auch problemlos an eine Vielzahl von Benutzern verteilt werden. Diese Benutzer helfen dabei, Unix an ihre eigenen Bedürfnisse anzupassen. Dennis Ritchie war in der Lage, diese Patches nach Bedarf zusammenzustellen, ohne im Voraus über diese Bedürfnisse nachdenken zu müssen.

Im Gegensatz zu LISP wird C auch heute noch stark genutzt. Obwohl hochinterpretierte Sprachen wie PHP, JavaScript und Python für viele Entwickler die erste Wahl sind, werden viele dieser Hochsprachen in C entwickelt. Auch wenn Konkurrenten wie Rust auftauchen, bleibt die Fähigkeit, auf kleinen Geräten mit geringem Stromverbrauch zu laufen, eine Stärke der C-Sprache.

PHP ist das Schlimmste

Daher wird erstens „schlechter ist besser“-Software akzeptiert, zweitens werden die Benutzer weniger erwarten, drittens wird diese Software kontinuierlich verbessert, bis sie nahe an der „schlechter ist besser“-Software ist. der richtige Weg."

- Richard Gabriel

Einige Jahre nach dieser Offenbarung begann Rasmus Lerdorf mit der Arbeit an einem persönlichen Homepage-/Formularinterpreter, den wir heute als PHP kennen. PHP/FI entstand aus Lerdorfs Bedürfnis heraus, seine Homepage zu pflegen und mit Formularen und Datenbanken zu interagieren. PHP/FI wurde nicht einmal als eigentliche Programmiersprache konzipiert, sondern als eine Schicht aus Skripten und Funktionen auf der C-Sprache.

PHP ist sehr einfach

Das Design muss einfach sein, egal ob es sich um die Implementierung oder die Schnittstelle handelt.

PHP verwendet unter der Haube die Sprache C, und wir haben bereits gesagt, dass dieser Teil der „schlechteste“ ist. Allerdings bringt dies auch einige Vorteile mit sich, vor allem eine einfachere zugrunde liegende Sprache, die die Erweiterung erleichtert. Während Hack/HHVM eher einen C++-Ansatz verfolgt, ist PHP selbst immer noch eine C-Sprache.

Es dauert nur wenige Stunden, die interne Struktur dieser Sprache zu erlernen. Elizabeth Smith hielt einen großartigen Vortrag über PHP-Erweiterungen, der viel über das Innenleben von PHP abdeckte. Die Sprache selbst basiert auf anderen Sprachen im C-Stil und ist nicht nur leicht zu lesen, sondern auch in andere Sprachen im C-Stil konvertierbar.

Die meisten PHP-Schnittstellen oder Standardbibliotheken sind sehr einfach, da die meisten Kernfunktionen nur Wrapper verschiedener C-Sprachbibliotheken sind und dann nahezu unverändert verfügbar gemacht werden. Obwohl dies zu einigen Inkonsistenzen in der Schnittstelle führt, bietet es eine vertraute Umgebung für Entwickler, die mit C oder C++ beginnen.

PHP-Sprache konzentriert sich stark auf die Webentwicklung. Es ist oft sehr einfach, Konzepte aus HTTP zu extrahieren und ähnliche Konzepte in der Sprache zu finden. Möchten Sie die Header-Informationen einer Anfrage erfahren? get_headers() wird Sie zufriedenstellen. Das Abrufen von Anforderungsinformationen ist so einfach wie das Lesen der globalen Variablen $_GET und $_POST.

PHP pflegt eine einfache Entwickleroberfläche und hält die interne Struktur so einfach wie möglich.

PHP hat (fast) Recht

In allen beobachtbaren Aspekten muss das Design stimmen. Aber der Einfachheit halber kann die Korrektheit etwas geopfert werden.

Hier tendiert PHP dazu, „einfach“ statt korrekt zu wählen. Vor der Einführung von HHVM waren Aussehen und Funktionen der Sprache nicht standardisiert. Der Zend-Interpreter ist die Spezifikation selbst, und die Art und Weise, wie sich die Sprache verhält, ist immer „korrekt“ (mit Ausnahme tatsächlicher Fehler). Wenn Sie die PHP-Engine durch etwas anderes ersetzen möchten, müssen Sie alle Funktionen der vorhandenen Engine implementieren.

LAX-Funktionsparameter und Rückgabetypen für viele Kernfunktionen erleichtern die Arbeit des Systems. Funktionen wie strpos(), die eine Ganzzahl oder einen booleschen Wert zurückgeben können, sind etwas einfacher zu handhaben als Methoden, die ausschließlich darauf ausgelegt sind, Ganzzahlen zurückzugeben oder Ausnahmen auszulösen.

Wenn man sich die Entwicklung der PHP-Sprache ansieht, basieren fast alle neuen Funktionen auf den Bedürfnissen der Entwickler und nicht auf der ernsthaften Idee „Es muss repariert werden, weil es falsch ist“. Eine stärkere Konzentration auf diese strengen Typ- und Ausnahmefehler ist eine korrektere Vorgehensweise. Allerdings gibt es auch Dinge wie kurze Pfeilfunktionen, Eigenschaften und Aufzählungen, die Entwickler nutzen möchten, um ihren Code zu vereinfachen.

PHP erfordert keine Konsistenz

Das Design darf nicht zu inkonsistent sein. In manchen Fällen kann der Einfachheit halber auf Konsistenz verzichtet werden.

Ich werde nicht einmal behaupten, dass PHP konsistent ist, aber es ist konsistent genug. Es kann sein, dass sich die Leute über die Reihenfolge der Nadel-/Heuhaufen-Argumente beschweren, wenn es um Array- und String-Funktionen geht. Im Allgemeinen sind Array-Funktionen jedoch konsistent, und auch String-Funktionen sind konsistent. Es ist viel einfacher, mit der zugrunde liegenden C-Bibliothek konsistent zu sein als innerhalb der Sprache.

PHP ist auch in anderen Aspekten konsistent genug. Wie ich bei strpos() erwähnt habe, gibt PHP bei Funktionen, bei denen ein Fehler auftritt, ziemlich konsistent FALSE zurück. Das ist nicht unbedingt richtig, aber konsistent. Unterstrichene und nicht unterstrichene Funktionsnamen stimmen im Allgemeinen mit den zugrunde liegenden Bibliotheken überein.

Die PHP-Sprache opfert Konsistenz zugunsten der Einfachheit, aber auch ohne diese Spezifikation strebt sie immer noch danach, dort konsistent zu sein, wo es sinnvoll ist.

PHP ist so vollständig, wie es sein muss

Das Design muss möglichst viele wichtige Situationen abdecken.

PHP ist komplett, wenn es um die anspruchsvollste Designaufgabe geht: das Schreiben von Webanwendungen. PHP wurde nie als Sprache konzipiert, die auf alle Probleme in der Programmierwelt angewendet werden kann. Dennoch ist es aufgrund seiner Einfachheit auch über das Web hinaus nutzbar. Der ursprüngliche Zweck von PHP bestand darin, die grundlegendsten Funktionen für die Webprogrammierung bereitzustellen, und dieser Trend setzt sich bis heute fort.

Änderungen an der Kernsprache werden häufig durch Entwickleranforderungen bestimmt. Die gesamte Community schlägt Änderungen vor, und dann stimmt die Community ab, um zu entscheiden, ob die neue Funktion abgelehnt, geändert oder akzeptiert wird. Viele Innovationen in der Sprache resultierten aus der Notwendigkeit, Dinge schnell zu erledigen. Selbst wenn wir Funktionen aus anderen Sprachen übernehmen, liegt das daran, dass es unsere Entwicklung erleichtert, und selten daran, dass andere Sprachen es „richtiger“ machen.

Heute können Sie Webanwendungen mit PHP entwickeln. In fünf Jahren können Sie immer noch Webanwendungen in PHP entwickeln, allerdings mit einigen neuen Funktionen. Die Integrität der Sprache selbst genügt jedoch den heutigen Anforderungen. Wir können die Sprache jederzeit ändern oder bei Bedarf in Zukunft neue Funktionen hinzufügen.

Ist schlimmer besser?

Gabriel gibt zu, dass sich die „Schlechter ist besser“-Philosophie auf Designs bezieht, die schlecht aussehen und vielleicht nicht als bessere Option angesehen werden sollten. Das einzige Problem besteht darin, dass, wenn er beide Philosophien betrachtet, „schlechter ist besser“ letztendlich immer noch die flexiblere Option im Vergleich zur MIT-/„Right Way“-Designphilosophie ist, „mit besseren Überlebenseigenschaften“. Wenn wir uns PHP ansehen, können wir die Idee bestätigen, dass „schlechter besser ist“.

Im Laufe der Jahre gibt Gabriel zu, dass er schwankte, welcher Weg besser ist. Die PHP-Community hat darüber debattiert, ob wir die Dinge richtig machen oder einfach weitermachen sollten. Wir haben Frameworks wie Laminas, die Bibliotheken auf klassische Informatik-Art aufbauen, und dann haben wir Frameworks wie Laravel, die sich auf Entwicklererfahrung und Geschwindigkeit konzentrieren. PHP selbst ist beides.

Wenn Sie das nächste Mal hören, dass jemand PHP kritisiert, lassen Sie ihn einfach gehen. Die Sprache ist wirklich schlecht. Aber in vielerlei Hinsicht sind die Langlebigkeit und die weit verbreitete Verwendung von PHP ein Beweis dafür, dass es nicht immer besser ist, Dinge auf die „richtige“ Art und Weise zu tun, als auf die „schlechteste“ Art und Weise. Wenn sich jemand über das von Ihnen verwendete Framework beschwert, verstehen Sie, dass es auf lange Sicht keine Rolle spielt. Wählen Sie eine Designphilosophie, die Ihrer Meinung nach für Sie funktioniert, und akzeptieren Sie die Tatsache, dass das Schlimmste tatsächlich besser sein könnte.

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

Originalautor: Chris Tankersley

Vorstellung des Autors:

Chris Tankersley hat viele Rollen: Ehemann, Vater, Autor, Redner, Podcast-Moderator und PHP-Entwickler. Chris hat während seiner 12-jährigen Programmierkarriere viele verschiedene Frameworks und Sprachen verwendet, aber den größten Teil seines Tages verbringt er mit PHP und Python. Er ist Autor von Docker for Developers und arbeitet mit Unternehmen und Entwicklern zusammen, um Container in ihre Arbeitsabläufe zu integrieren.

Empfohlenes Lernen: „PHP-Video-Tutorial“