Ist php eine schlechte Programmierungs Sprache?
Viele Developer und andere Leute sagen zu mir das php eine schlechte Programmierungs Sprache ist stimmt das?
Das Ergebnis basiert auf 39 Abstimmungen
11 Antworten
PHP als "absolut schlecht" zu bezeichnen halte ich für übertrieben, da diese Sprache durchaus sinnvolle Einsatzzwecke hat.
Aber als "relativ schlecht", also im Verhältnis zu anderen Programmiersprachen, kann man PHP getrost bezeichnen.
Das hat m. p. M. n. die folgenden Hauptgründe, die so gehäuft in keiner anderen mir bekannten Mainstream-Sprache auftreten:
- PHP wurde für die serverseitige Programmierung entwickelt, bietet aber von Haus aus keine vernünftige und portable Möglichkeit der Synchronisation einzelner Prozesse. (Stichwort IPC: die SysV-Techniken gelten als überholt und führen schnell zu Deadlocks, PThreads bekommt man nur mit Zusatzmodul, welches nicht in der Standardinstallation enthalten ist, uvm.)
- Die Dokumentation auf php.net wirkt auf den ersten Blick übersichtlich, ist aber total kaputt. Es gibt kaum eine Funkion bzw. einen Aspekt, deren / dessen Seiteneffekte vollumfänglich in der Doku aufgelistet sind. Ohne die korrigierenden Kommentare darunter wäre man oft völlig aufgeschmissen. Aber selbst mit Kommentaren fehlen Teile der API-Docs schlichtweg, oder sind einfach nur falsch beschrieben, d. h. es gibt gravierende Abweichungen von dem, was beschrieben wird, und dem, was wirklich passiert. (Dazu muss man sich den Quelltext des Interpreters ansehen.)
- Die API ist total inkonsistent, sowohl im Bezug auf Parameterreihenfolge, Namensgebung von Funktionen, als auch dem Vorhandensein von Features aufeinander bezogener Funktionen.
- Anstatt Containertypen ordentlich für unterschiedliche Aufgaben anzubieten, hat man sich entschieden, eine Gottimplementierung namens "array" zu erschaffen, die intern eher weniger mit einem Array zu tun hat, als viel mehr einem Mischmasch aus Deque, Baum, Hashtable, und einigen weiteren herkömmlichen Containertypen. Diese Chimäre ist nicht nur vergleichsweise recht langsam, sondern frisst auch sehr viel unnötigen Speicher.
- Der Interpreter selbst ist in C geschrieben, und wenn man sich dessen Quelltext ansieht, fallen einem alle Code-Smells und Beispiele für schlechten Stil entgegen, vor denen selbst in Anfängertutorials gewarnt wird. Wie man einen sauberen Interpreter schreibt, kann man bei CPython sehen. Selbst ein uralter Perlinterpreter ist verglichen mit dem aktuellen PHP-Branch noch als "sauber" zu bezeichnen.
- Es fehlt eine "vernünftige" Unicode unterstützung. Die Betonung liegt auf "vernünftig" und schließt Workarounds mit den mb_XYZ() Funktionen aus, die noch nie eine wirkliche Alternative waren.
- Eine vernünftige Möglichkeit der Fehlerbehandlung fehlt völlig. Das ist einer der Gründe, warum gerade PHP-Entwickler so arge Probleme damit haben, da "Rückgabewert checken und evtl. Ausnahme werfen" eben meist viel zu viel Codebloat erzeugt und deshalb meistens gleich völlig weggelassen wird. (Das sieht man leider auch in fast allen Großprojekten!)
Es gibt noch mehr Punkte, und einige der oben genannten findet man tatsächlich auch bei anderen Sprachen, aaaaaaber niemals mehr als zwei davon gleichzeitig und in einer derart starken Ausprägung, wie bei PHP. (Und ich habe schon mit zich Programmiersprachen zu tun gehabt ...)
Es gibt allerdings auch einige wenige positive Punkte zu PHP:
- Neue Sprachversionen verfügen tatsächlich über einige wenige Sprachfeatures, die man von einer modernen Programmiersprache auch erwarten darf. (Auch wenn PHP hierbei erfahrungsgemäß immer ein paar Jährchen hinterher hinkt.)
- Seit PHP 7.x wurde die Geschwindigkeit des Interpreters massiv verbessert.
- PHP bringt seinen eigenen Webserver mit, den man mal eben für schnelles Testen anschmeißen kann, ohne sich einen ausgewachsenen Apache installieren zu müssen.
So, das wars. :)
Ich denke, dass ich meine Kritik ganz fundiert begründet habe, auch wenn ich mir Codebeispiele zu den einzelnen Punkten gespart habe.
Aber ein Software-Entwickler wird ohnehin sofort erkennen, was gemeint war.
Von daher muss ich sagen: Es gibt wirklich gute Gründe, PHP einzusetzen. Aber es gibt meistens noch mehr, die dagegen sprechen.
PHP ist nicht per se schlecht ... aber ganz offensichtlich schlechter (relativ gesehen!) als andere Sprachen.
Wenn man die Pro-Argumente "billig" und "überall verfügbar" weglässt, bleibt eigentlich nicht mehr viel, was FÜR diese Sprache spricht.
Aber dennoch sollte man PHP halbwegs nutzen können ... genauso wie viele weitere Sprachen. Denn nur so kann man die passendste wählen, und ist nicht auf die einzige angewiesen, die man kann. :)
Nein, das stimmt nicht, und das kann ich so nicht auf mir sitzen lassen.
Aber ich bin bereit mich umstimmen zu lassen! Beantworte mir also bitte jeweils eine Frage zu jedem meiner Punkte:
- Mit welchen IPC-Ansätzen synchronisierst du deine PHP-Prozesse portabel und sicher?
- Wenn die Dokumentation angeblich so gut ist, warum stehen dann zwei Drittel der wichtigen Infos zu Seiteneffekten i. d. R. in den Kommentaren?
- Du willst nicht ernsthaft behaupten, dass Funktionsnamen wie asort() und array_chunk() konsistent sind, oder?
- Wie funktioniert "array" denn ohne Performance- und Speicherkosten deiner Meinung nach intern, wenn nicht so, wie von mir beschrieben?
- Variablen-Recycling, Namen wie "d1" und "d2" für double-Variablen und hemmunslose Nutzung von void-Zeigern sind kein schlechter C-Stil im PHP-Interpreter?
- Es gibt nicht mindestens fünf (Server, Dateisystem, OS, DB, etc.) unterschiedliche Stellen am Sever, deren Kodierung man beachten muss, um vernünftig mit Unicode arbeiten zu können und ein großer Teil von PHP-Problemen dreht sich ohne Grund um Mojibake?
- Den Rückgabewert von fopen() zu prüfen und evtl. eine Ausnahme werfen ist für dich eine "saubere Fehlerbehandlung"?
Ehrlich gesagt kam von dir jetzt nicht viel wirklich fundierte Kritik, also beantworte mir diese Fragen doch mal in Stichpunkten.
Ach so, und ich entwickle auch heute noch seit 1997 fast durchgängig mit PHP, genau genommen seit Version 3 ... das war so 1996 oder 1997. Also tu bitte nicht so, als sitze das Problem vor dem Bildschrim.
Wenn du also fundierte Kritik hast und meine Fragen sinnvoll beantworten kannst, dann bitte.
Wenn nicht, dann kannst du dir jeden weiteren Kommentar sparen. Vielen Dank im Voraus! :)
Vielen Dank, ich habe eben selbst einen längeren Kommentar dazu abgegeben.
Beim Formulieren meiner Frage hatte ich leider keine Zeit für einzelne Codebeispiele und hab mir schon gedacht, dass einige Einsteiger mit der textuellen Repräsentation meiner Kritik nichts anfangen können.
Jetzt im Nachhinein denkeich mir, dass ich vielleicht doch besser Code-Beispiele dazu geschrieben hätte. In der jetzigen Form ist es für weniger erfahrene Entwickler vielleicht doch schwierig meiner recht trockenen Kritik zu folgen.
Naja, egal ... wünsche noch einen schönen Abend! :)
Vieles davon kann ich direkt unterschreiben, die Kommunikation mit Entwicklern ist auch gewöhnungsbedürftig - 'worksforme' ist kein Argument dafür, daß der Code ordentlich ist.
Wo ich mich nicht unbedingt anschließen möchte ist Sys-V IPC, letztlich ist shmem immernoch der grundlegende IPC-Mechanismus schlechthin, ob das nun anaon mmap()ed mem ist, das man mit der SYS-V-Semantik wrapped, oder es direkt nutzt, ist eigentlich wurst. Auch named pipes und socketpairs sind im Endeffekt nur shmem mit Kleister. (Und ja, es braucht natürlich einen geeigneten Synchronisierungsmechanismus, weiß ich ....)
Das Problem bei SysV ist, dass Ressourcen nicht mehr ordentlich frei gegeben werden können, wenn dir ein Prozess stirbt.
D. h., wenn du etwas "lockst" und es einem Angreifer gelingt, deinen PHP-Prozess zu beenden (was wirklich sehr leicht ist), dann warten alle folgenden Prozesse auf das lösen deines Locks ... was nie passieren wird.
Du bist ja hier einer der C-Entwickler auf dieser Plattform, der auch mit Systementwicklung zu tun hat, deshalb lege ich dir die (Plural!) SysV-Kapitel des Buches "The Linux Programming Interface" ans Herz. Das Buch ist vergleichsweise teuer, aber im wahrstten Wortsinn sein Gewicht in Gold wert. ;)
Ich bin übrigens "TeeTier" (falls dir der Nick etwas sagt) und bin hier seit etwas über einem Jahr - aus unterschiedlichen Gründen - nur noch mit wechselnden Kurzzeitaccounts unterwegs. :)
Schönen Abend noch! :)
Ah, deswegen, hatte mich schon gewundert, was mit Dir passiert ist - umgezogen?
Ja, da hast Du recht, das ist in der Tat ein mögliches Problem, insbesondere auch die Persistenz über Systemboots hinweg. Ich würde es da wie mit Init halten: Ein sauberer Prozess, der unsterblich die IPC-Resourcen managed und ggf. aufräumt (ein Supervisor sozusagen) - lästig, sicherlich, aber so haben wir das damals(tm) umschifft.
Insofern hast Du schon recht, ein Interface in PHP, daß dann z.B. auf mmap(), kqueues() usw. abbildet wäre dringend nötig - andererseits hat man bei PHP immer den Eindruck, so wirklich massive threading etc. ist nicht so ganz seins ;-).
Das hatte verschiedene Gründe, u. a. wegen Privatsphäre uvm. ... ist aber auch egal ... im Moment bin ich alle paar Wochen bis Monate mit neuen und recht anonymen Accounts hier unterwegs.
Hauptsache die Antworen haben eine gute Qualität, von welchem Account die letztendlich kommen ist ja Wurst.
Und noch mal zur IPC: Genau das, was du angesprochen hast, gibt es ja seit etwas über 10 Jahren bei Linux. Wenn dir der Prozess stirbt, der einen Lock hält, räumt ihn der Kernel für dich auf. Also ohne Neustart und ohne Watchdog.
Das ist nur ein kleines Beispiel, aber seit Kernel 2.2.x oder irgendwie so in dem Dreh (also schon eine halbe Ewigkeit) kann sich der Kernel um geteilte Ressourcen kümmern, falls alle beteiligten Nutzer gekillt werden. :)
Das hat man damals eingeführt, weil die Probleme mit SysV-IPC ja schon lange bekannt waren.
Ich empfehle dir nochmals "The Linux Programming Interface"! Wenn du noch keinen Weihnachtswunsch hast, dann solltest du mal drüber nachdenken. :)
Nu rabschließend, eine der Sachen, die SysV bequem ermöglichten: Message Passing als Uni/Multi/Broadcast zwischen multiplen Prozessen. Natürlich kann ich diese Pattern auch auf Namend Pipes abbilden, oder Unix domain sockets, aber eigentlich ist ein chunk shared mem dafür optimal.
Könnte ich auch mit mmap() machen, muß dann aber einiges drumherum basteln. Aber genau bei solchen Mustern brauche ich meist eine Instanz die überwacht, ob eine Nachricht von allen Empfängern konsumiert wurde.
Brauche ich nur einen shared cache oder so, dann tuts auch nen chunk mmap() mit MAP_SHARED und nen paar futexes oben drauf :-D.
Ich schaue mal nach dem Buch, danke für den Tip.
Kennst du noch 'The Linux Programmer's Guide' aus dem TLDP? Lang ists her ...
Bei Punkt 1 muss ich dir Recht geben, wäre auch tatsächlich neben Punkt 7 der einzige große Nachteil den ich an PHP sehe, im Vgl. zu moderneren Ansätzen über Python/Django oder JavaScript/Node.
Punkt 2 sehe ich nicht so - die Docs scheinen zwar etwas altbacken, aber sind aber m.M.n. vollständig, auch ohne Nutzerkommentare. Docs sind nicht dafür da, jeden Ausnahmefall aufzuarbeiten. Eben dafür sind die Nutzerkommentare da. Die Docs sollen die jeweiligen Klassen, Funktionen etc. neutral in Gänze darstellen, das tun sie meines Erachtens nach.
3 stimmt ebenfalls - das sehe ich jedoch weniger als Beweis dafür, dass PHP eine "schlechte Sprache" sei, allenfalls als nervtötend.
4 mag in der Theorie so sein, hat in der Praxis bei den allermeisten Anwendungen jedoch m.M.n. keine Nachteile. Und in den Fällen wo auf Datenstrukturen wie Maps und Co. zurück gegriffen werden muss, verwendet man eben nicht PHP - dafür ist die Sprache eben nicht gemacht, soll sie auch nicht. So wie je bei jeder Sprache gibt es anwendungsfallbezogen eben solche Nachteile, auch das würde ich PHP aber nicht als Nachteil per se anrechnen.
Zu 5 kann ich nichts sagen, da ich mir die Interpreterumsetzung noch nie angeschaut habe. Aber selbst wenn dem so sein mag - schlechter Codestil des Interpreters ist kein Problem mit der Sprache an sich. Wenn jemand nur gebrochen Deutsch spricht, bezeichnest du Deutsch ja auch nicht als schlechte Sprache (weit hergeholter Vergleich, aber du weißt, worauf ich hinaus will).
Zu 6 - ich hatte tatsächlich noch nie Probleme mit Unicode Support. Auch das könnte ggf. wieder anwendungsfallbezogen sein...
Und bei 7 muss ich dir wiederum Recht geben - da gewöhnt man sich jedoch denke ich dran und nutzt die limitierten Möglichkeiten, die man hat, eben aus. Aber vor allem durch das sehr beschränkte Error Handling kommt eben der häufig anzutreffende schlechte Codestil in PHP.
tldr; Deine Punkte sind m.M.n. bis auf 1 und ggf. 7 nicht zwingend dafür ausschlaggebend, dass PHP eine schlechte Sprache sei. Höchstens für gewisse Anwendungsfälle ungeeignet - so wie jede Sprache.
Zu 2 und 6 kann ich ein Beispiel angeben:
Die loadHTML-Methode der DOMDocument-Klasse arbeitet selbst dann mit einer ISO-8859-1-Kodierung, wenn man explizit angibt, dass man UTF-8 verwenden möchte. Die Dokumentation selbst gibt dazu keine Auskunft, dass das zweite Argument für den Konstruktor nicht zwingend Einfluss hat. In den Kommentaren erst findet man eine Warnung bezüglich dessen sowie Workarounds in den Artikeln der spezifischen Methoden. Eine Frage dazu hatten wir hier auf GF auch schon einmal.
Also gerade bei Modulen, die mehroder weniger zum PHP-Kern gehören und überall genutzt werden, sieht es mit der Dokumentation düster aus.
Prepared-Statements in Kombination mit Ausnahmen verursachen beim SQLite-Modul Fehler in dem Sinne, dass einige Prepared-Statements einfach nicht funktionieren.
Und die Doku zum OpenSSL-Modul enthält teilweise fast leere Seiten. Konstanten enthalten oft überhaupt gar keine Dokumentation, sodass man nur raten kann, was diese bedeuten.
Oder Parameter werden beschrieben, sind aber intern völlig funktionslos und haben keinerlei Auswirkungen auf die Funktion an sich. Auch das sieht man, wenn man sich den C-Quelltext des Interpreters ansieht.
Aber wie gesagt, PHP ist trotzdem NICHT per se schlecht!
Ich empfinde es nur als schlechtER, als andere Alternativen. :)
Interessant, nicht gewusst. In dem Fall muss ich mich in Punkt 6 geschlagen geben. :-)
Ich wollte eigentlich nein ankreuzen. Aber leider kann man es nicht rückgängig machen.
Ich wüßte nicht, warum PHP schlechter sein sollte als andere Sprachen, zumal PHP ja auch vollständig objektorientiert ist, was nicht für jede Sprache gilt.
Ist php eine schlechte Programmierungs Sprache?
Nein. Es gibt viele schlechte PHP Programmierer und schlechte PHP Programme. Aber das macht PHP nicht zur schlechten Programmiersprache.
Alex
PHP ist toll. Vor allem für z.B. Datenbankkommunikation zwischen App und Server. (Aber auch für Webanwendungen)
Sprachlich hat Lppll schon viel gesagt. Mich als Admin etlicher Server nervt vor allem, das die APIs nicht stabil sind. Gefühlt die Hälfte der für PHP 5 geschriebenen Scripte funktionieren unter PHP 7.2 nicht mehr ohne größere Anpassungen. Bei Standardsoftware ist das nicht so das Problem, die kann man Updaten, aber wenn man dann irgendwelche Individualsoftware hat, die laufen muss, wo aber Mittel oder Zeit fehlen, die upzudaten, bleibt einem nur übrig, irgendwo ein nicht mehr supportetes Alt-PHP in einer VM laufen zu lassen, mit allen vorhandenen Sicherheitslücken. Bis vor Kurzem lief hier noch eine PHP 3 VM :(
Das Argument ist aber mehr als wohlfeil. Mit PHP7 wurden einige Zöpfe korrigiert bzw. abgeschnitten, die gerade von der Gruppe der PHP-ist-mies-Sagern bemängelt wurden. Natürlich sind dann auch entsprechend Codeanpassungen alter PHP Scripte notwendig. Dies kann und darf dann kein Argument gegen PHP(7) sein. Und auch hier liegt der Fehler dann nicht originär bei PHP, sondern beim Entwickler.
Der Fehler sitzt vor dem PC und nicht im Code oder in der Sprache ;-)
Deine Kritik war ein interessanter Artikel - jedoch unbegründet oder auf mangelnde Erfahrung zurückzuführen.