- PHP steht für pupertierende Hauptschüler programmieren.
- -- Eine beliebte Erklärung, glaub man Google
Vor ein paar Tagen habe ich eine
schonungslose Abrechnung mit der Programmiersprache PHP gelesen. Sie ist lang, hervorragend argumentiert, und hinterlässt nicht den Funken einer Hoffnung, dass sich da noch was reparieren lässt. Außerdem ist sie auch noch recht gut geschrieben, so dass das Lesen auch Spaß macht.
Das Ökosystem PHP wird auf allen Ebenen zerlegt: in allen Facetten der Sprachdefinition genauso wie die Standardbibliothek, also die Funktionen, die mitgeliefert werden. Auch so ziemlich jedes "aber"-Argument wird genauso zerlegt. Ein kurze Kostprobe will ich mal übersetzen: das Argument "ein guter Programmierer kann in jeder Programmiersprache guten Code schreiben" wird meiner Meinung nach korrekt auseinandergenommen mit: "Ein guter Handwerker
kann einen Nagel entweder mit einem Stein oder einem Hammer einschlagen, aber wie viele Handwerker sieht man, die auf Nägel mit Steinen einschlagen? Ein Teil von dem, was einen guten Entwickler ausmacht, ist die Fähigkeit die richtigen Werkzeuge
auszuwählen."
Für mich ist mittlerweile klar: wenn ich das nächste Mal etwas für "das Netz" programmiere will, dann fällt eine Realisierung in PHP kategorisch aus. Die Frage ist nur: was sollte ich aber dann nehmen? Der Artikel empfiehlt Python und Ruby. Python und ich werden definitiv keine Freunde mehr, mir sind Programmiersprachen suspekt, bei denen ein falsch gesetztes Leerzeichen den Ablauf eines Programms verändert. Einen Kompilierfehler gerne, aber doch nicht den Ablauf ändern. Ruby habe ich mir noch nicht näher angeguckt, aber bin auch nicht motiviert, da wirklich tiefer einzusteigen.
Aber im Moment habe ich da eher eine andere Idee: C++ mit Qt. Da bin ich eh recht gut zu Fuß mit, das Programm kann recht gut in Threads aufteilen, so dass man Arbeit und Darstellung recht gut teilen kann. Die Kommunikation mit dem Webserver lässt sich via FastCGI oder SCGI erledigen, oder zu Not auch den Webserver selbst mit einkompilieren. Allerdings habe ich so gar kein Gefühl dafür, ob diese Idee, eine Qt Applikation ohne GUI aber mit Webschnittstelle, performant genug ist.
Ein ungetestetes SCGI-Interface habe ich fertig, genauso wie einen Webserver, wobei der Webserver definitiv nur ein Proof-Of-Concept ist, und unter Last vermutlich wohl noch böser einknicken wird als eine PHP Installation. Die Idee bei dieser Doppelimplementierung ist, die Schnittstellen so ähnlich zu halten, so dass die selbe Applikation mit entweder per Webserver oder per SCGI-Anbindung (oder wenn beides nicht gut genug "performt", dann eben FastCGI) laufen zu lassen. So hoffe ich, den Code zum einen recht gut test- und wartbar zu halten, zum anderen aber auch im Falle von Problemen noch Ausweichmöglichkeiten zu haben.
Im Netz habe ich schon das eine oder andere Projekt gefunden, bei dem Qt für ein Webframework eingesetzt wird. Allerdings ging es dabei zum Beispiel um eine Portierung von Django nach Qt, und da habe ich dann einen Riesenschwung an Code, den ich nicht brauchen kann, dafür fehlt dann aber auch genau das, was ich brauche, so dass ich wahrscheinlich besser damit fahren werde, doch alles selbst aufzusetzen.
Es bleibt im Allgemeinen nur noch die Frage, wie ich das ganze testen kann. Reicht "ab", also "Apache Bench", oder gibt es bessere Wege, das zu testen? :'(
Kommentare