PHP Zukunft: Großer Umbruch oder kleine Schritte?
PHP hat diverse Probleme, einige größer als die anderen, aber schon seit Jahren gibt es Diskussionen über dringend nötige Änderungen an der Sprache. Ein bekanntes Beispiel ist wohl die needle-haystack-Problematik oder das leidige Multi-Byte-Problem (Unterschied mbstrlen() zu strlen(), UTF-8 überall), oder String-Funktionen manchmal mit Unterstrich und manchmal zusammengeschrieben (str_replace(), strtolower()). Es gibt sicherlich noch zig andere große Probleme die man mal anfassen müßte um die Sprache „besser“ oder „runder“ zu machen, denn einige Dinge sind mit den Jahren gewachsen, werden aber nun wo man Verbesserungspotential sieht aus Rückwärtskompatibilitätsgründen nicht verändert.
Um also diese und andere größere Probleme zu beheben gibt es mehrere Möglichkeiten: einen großen Schritt oder mehrere kleine. Wir gehen davon aus dass wir hier über Änderungen reden die großen Einfluss auf bestehende Scripte nehmen werden, die Rückwärtskompatibilität kann in den meisten Fällen nicht gewährleistet werden. Im besten Fall funktionieren alte Scripte nicht mehr, im schlimmsten Fall entstehen Sicherheitslücken.
Würdet ihr einen großen Bruch bevorzugen, sprich die große Version 6 die alles besser macht und für die man > 50% der alten Scripte anpassen (oder zumindestens prüfen) muss? Natürlich gäbe es vorher noch Versionen in denen schonmal langsam die Features, die entfernt werden sollen, deprecated markiert sind.
Oder lieber in kleineren Schritten die Versionen 5.5, 5.6, 5.7 etc., wo dann mit der Zeit jeweils eines der angesprochenen Probleme gelöst wird, ähnlich 5.4 wo Dinge wie Register Globals, Magic Quotes, Safe Mode und weiteres endlich entfernt wurden, und auch das Verhalten einiger Funktionen geändert wurde?
Bevorzugt ihr solche Änderungen an euren Scripten lieber regelmäßig in kleinen Schritten oder einmal einen richtigen Rundumschlag? Wie würdet ihr die Vor- und Nachteile jeweils einschätzen?
Wenns nach mir ginge?
Dann bitte einen großen Knall. Meiner Meinung nach entstehen die größeren Probleme immer dann, wenn man auf Gedeih und Verderb für Abwärtskompatibilität sorgen will. Das sollte künftig einfach weniger Beachtung finden. Das hätte zur Folge, dass viele Scripte vielleicht nicht mehr funktionieren werden – doch der Vorteil ist, dass die Entwickler so auch gezwungen werden am Ball zu bleiben, was letztlich zwar vielleicht in weniger Programmen, dafür aber bessere Qualität enden könnte.
Kleinere Updates sollten zwar zwischendurch ebenso gemacht werden, das sollte sich dann aber eher rein auf Bugfixing und die Sicherheit betreffende Änderungen beschränken. Keine neuen Funktionen, die dann vielleicht doch nur halbherzig umgesetzt sind, weils schnell gehen muss. Dann lieber neue Features sammeln bis ein gewisses Ziel erreicht ist, und DANN einen Versionssprung vollziehen. Bei PHP hatt ich bisher eher das Gefühl, dass manchmal etwas „ungeplant“ zwischengeschoben wurde.
Von mir aus können wir auf Version 6 noch ein, zwei Jahre mehr warten als die Roadmap vielleicht vorgibt, dafür aber alle bekannten Schwächen ausmerzen und PHP „säubern“. Dann hat mans hinter sich und es gibt endlich einen klaren Schnitt, wo man sagen kann: Alles was bisher mit PHP geschrieben wurde, MUSS jetzt auf den Prüfstand gestellt und intensiv auf Fehlfunktionen gecheckt werden.
Patrick
24 Mai 12 at 09:07
Schön, dass Du das Thema ansprichst.
PHP hat schon lange das Problem mit der Rückwärtskompatibilität und nicht den Mut gehabt Schritte zu unternehmen, um die Sprache grundsätzlich zu verbessern. Daraus ist ein Mantra entstanden, welches jedes Mal beim Thema „Umbruch“ aufgesagt wird. Aber warum?
Es gibt gute Beispiele wie man Änderungen in dieser Größenordnung umsetzen kann. Ein gutes Beispiel ist ECMA Script 5 und 6. Man ist sich der Tatsache bewusst, dass Rückwärtskompatibilität nicht mehr gewährleistet werden kann und hat dafür Mechanismen etabliert wie den strict mode um „deprecated“ Eigenschaften nicht mehr zuzulassen.
Wenn PHP zukünftig mit anderen Script Sprachen mithalten will, muss die (schon lange kommen wollende) Version 6 massive Änderungen vorweisen und auf Rückwärtskompatibilität verzichten. Sonst kann die Sprache auf Grund der von Dir angesprochenen Problem irgendwann nicht mehr ernst genommen werden.
awenkhh
24 Mai 12 at 09:21
Ich bin auch dafür, lieber einen großen Sprung zu machen und auf diverse Kompatibilitätsmaßnahmen zu verzichten. Ansonsten wird man in 20 Jahren noch mit den ganzen Krücken zu leben haben.
Carsten
24 Mai 12 at 09:38
Wenn ich mir anschaue, wie die deutschen Hoster noch an PHP 5.2 festkleben, dann wäre mir ein „großer Knall“ auch lieber.
Ich sehe nur die Gefahr einer Spaltung der PHP-Community. Ein Teil der Entwickler wird den großen Schritt nicht mitmachen wollen, so dass es wahrscheinlich auf 2 parallel geführte PHP-Versionen hinauslaufen wird. Hier der Comic dazu: http://xkcd.com/927/
Gabriel
24 Mai 12 at 09:42
Großer Knall, definitiv ja, aber bitte mit Vorwarnzeit und einer stabilen Beta für Entwickler zum testen eigener Scripte.
Sascha Presnac
24 Mai 12 at 09:52
Sehe das so ähnlich, wie awenkhh: Grundsätzlich haben sich die Core-Entwickler das Problem selbst erschaffen, indem über Jahre auf Biegen und Brechen die Abwärtskompatibilität erzwingen wollten, so dass sich diese „Hässlichkeiten“ zu einem unüberschaubaren Berg angesammelt haben. Kleine BC-Breaks würden vermutlich kaum solche Wellen schlagen.
Zu „Was würdest ihr tun?“: Es gebe noch eine dritte Lösung 😉 Der große Knall samt Kompatibilitätslayer. PHP hat ja nun Namespaces, also liegt es schon Nahe, dass man auch die internen Funktionen und Klassen in solche verteilt („php\strings“ (use php\strings as str; echo str\sub()), „php\arrays“, …). Dort könnte man schön aufräumen, könnte aber parallel die alten Funktionen als Alias im globalen Namespace behalten und fleissig E_DEPRECATEDs werfen. Das ließe sich sogar im Userspace umsetzen (ebenso auch anders herum).
KingCrunch
24 Mai 12 at 09:53
@Sascha: Das hat bei 5.3 und 5.4 schon nicht funktioniert 😀 Es gibt schon lange sehr stabile Betas und es gibt auch immer die nötigen Quellen (allen voran das Wiki), um sich über Änderungen zu informieren. Das nützt bloß nichts, wenn das Groß der Entwickler neue Versionen erst beachten (was installieren und/oder nutzen noch nicht mal mit einschließt!), wenn eine „1“ hinter dem ersten Punkt steht.
KingCrunch
24 Mai 12 at 09:56
Ich würde auch den großen Bruch nehmen. Bis die ganzen Hoster auf z.B. Version 6 wechseln, dauert es dann sowieso ein zwei Jahre. Wer den Server selber aufsetzt kann ja entscheiden, ob er z.B. die 6er oder 5er nimmt, mit den entsprechenden Vorteilen und Nachteilen.
Kettil
24 Mai 12 at 10:33
Aus der Sicht eines Administrators wäre mir ein ähnliches vorgehen wie bei Python ganz recht. Sprich man setzt eine letzte PHP 5er Version an (evtl. mit erweitertem Support) und macht den großen Umbruch (brechen der Rückwärtskompatibilität) mit der 6er. Schön wäre es wenn die Distros das dann auch wie bei Python mit zwei Paketzweigen betreuen würden. So würde man auch ohne Extra Repos auskommen.
Sebastian Reimers
24 Mai 12 at 12:46
Ich finde, dass sich PHP nicht wirklich weiterentwickelt sondern immer dicker und fetter von Version zu Version wird, indem Sie versuchen aus anderen Programmiersprachen Sachen abzuschauen und reinzustopfen…
Das fängt bei Sachen wie array() = [] an und hört bei sinnlosen nicht einheitlich bezeichneten (siehe oben) Funktionen auf.
So manches habe ich noch nicht ganz verstanden und was mir immer im Kopf bleibt ist das eine Interview wo dieser PHP-Typ auf das HipHop-PHP von Facebook angesprochen wird (bzgl. Performance) und er nur drumrumredet aber rein garnichts dazu sagt wieso sie es nicht schaffen die Performance zu steigern.
Chris
24 Mai 12 at 13:07
Nur so, @Chris
> Ich finde, dass sich PHP nicht wirklich
> weiterentwickelt sondern immer dicker und
> fetter von Version zu Version wird, indem
> Sie versuchen aus anderen Programmiersprachen
> Sachen abzuschauen und reinzustopfen…
Wie sollte sich denn PHP weiter entwickeln, wenn nicht mit neuen Features? Das diese an Features anderer Sprache angelehnt wurden, klingt für mich sogar eher logisch, schließlich haben sie sich bereits bewährt 😉
> Das fängt bei Sachen wie array() = [] an
Da betrachte ich persönlich eher „array()“ (und das korrespondieren „list()“) als Fehler: Sieht aus, wie eine Funktion, ist aber keine und wenn man mal ein klein wenig schachtelt, wirds direkt unübersichtlich
> und hört bei sinnlosen nicht einheitlich
> bezeichneten (siehe oben) Funktionen auf.
Damit hats doch aber angefangen, nicht aufgehört 😕
KingCrunch
24 Mai 12 at 13:42
Hi,
ich würde eher einen ganz drastischen Schritt durchführen, da ich mittlerweile das vertrauen in die PHP Core Entwickler und das PHP Projekt verloren habe. Ich finde das Projekt sollte aufgesplittet werden. Der neue Teil sollte unter einer gemeinnützigen Organisation(die sich über Spenden finanziert) mit einer klaren Roadmap weiter entwickelt werden. Ähnlich wie die Mozilla Foundation. Somit könnten auch fest angestellt Entwickler an der neuen Version arbeiten, was den Fortschritt erheblich steigern würde.
Wieso würde ich diesen Schritt gehen:
– Es fehlt eine klare Roadmap für die Sprache PHP.
– Es gibt keinen der eine Vision von der Sprache PHP hat. Kurz gesagt ich finde es fehlt einfach eine Leader Persönlichkeit die das letzte Wort hat und die Entwicklung vorantreibt(Natürlich im Sinne der Community).
– Manchmal habe ich das Gefühl das die Core Entwickler komplett an den wünschen der PHP Community vorbei entwickeln. Das manifestiert sich ja schon allein darin, wer auf eine neues Feature voten kann und wer nicht. Denn der Großteil der Community bleibt hier außen vor.
– Ich finde dadurch das PHP eine Multiparadigmen- Programmiersprache ist wird die Entwicklung gebremst. Der Eine Teil der nur Prozedural programmiert kann nicht verstehen wie der OOP programmierend Teil ein Feature vorschlägt welches so gar nicht in das eigene Paradigma passt.
– Es gibt zu viele Interessengruppen die durch ständiges Gezerre und Gezedere die Enwicklung bremsen. Das mag auch daran liegen das es keine einheitliche Vision über die Zukunft von PHP gibt.
Wie ist eure Meinung dazu?
Christian Kaps
24 Mai 12 at 13:55
Mir wäre auch der große Bruch lieber. So ist man nicht genötigt, bei jeder neu erschienen Version ein paar kleine Änderungen zu machen, sondern kann sich dem großen Ganzen widmen. Ich finde, dieser Bruch ist wirklich dringend nötig!
Marcus Kober
24 Mai 12 at 13:57
Ich wäre ebenfalls für den großen Bruch in PHP6. Ob es dazu kommt, vermag ich nicht zu sagen aber ich fürchte eher nicht. Zu viel Software wäre wahrscheinlich nicht mehr kompatibel und wenn SiteBetreiber irgendwann zu einer großen Umstellung gezwungen wären, würden sich bestimmt nicht wenige es dreimal überlegen ob sie nochmal auf PHP setzen – ob man hier eine mögliche Abwanderung riskiert bezweifle ich irgendwie.
Auch kann man ja nicht eben mal so im vorbeigehen ein von den Grundfesten auf neues PHP zu entwickeln – man würde kaum drumherum kommen hier über einen gewissen Zeitraum hinweg PHP5 noch weiterzuentwickeln und gleichzeitig an PHP6 zu arbeiten. Ob man es sich überhaupt leisten kann hier zweigleisig zu fahren?
Schön wäre es aus meiner Sicht schon – Einsteiger werden ja heute immer noch in den Tutorials erstmal mit der prozeduralen Programmierung angefixt, wenn sie dann mal weiter sind, müssen sie in einigen Punkten beinah von vorne beginnen. Da spreche ich jetzt aus eigener Erfahrung – ich ertappe mich heute noch dabei, auf einmal die Pfade der OOP zu verlassen und irgendwelche Monster-Objekte zu erstellen, die eigentlich gar keine Objekte mehr sind, sondern einfach nur prozedurales Programmieren mit ‚class xyz {‚ ganz am Anfang ^^
Was sich da vor 12-13 Jahren bei mir eingebrannt hat, bin ich einfach heute noch nicht vollständig losgeworden.
Quetschi
24 Mai 12 at 15:32
Ich glaube ein großer Bruch wird aus zwei Gründen nicht funktonieren:
1) es wird keine Einigkeit zustande kommen wie genau denn das neue PHP aussehen soll (2nd System Syndrom)
2) jede menge Legacy Code wird einfach mit der letzten rückwärtskompatiblen Version weiterlaufen
Erinnert euch doch bitter nur einfach mal an Dinge wie „register_globals ist jetzt per default off“ …
Was ich statt dessen gerne erst einmal hätte wäre eine gründliche Bestandsaufnahme der bekannten Probleme, verbunden mit Kateogisierungen in Richtung „warum ist das überhaupt so“, „macht das heute noch Sinn“, „wie würden wir das machen wenn wir das Feature erst heute neu hinzufügen würden“ und vor allem „wieviel machen wir damit kaputt und wieviel Reparaturaufwand bringt das mit“. Oder auch evtl. nur einfach quantisiert in DefectClass/Severity/Impact/Effort/RiskToFix zu je 1-5 wie wir das im mySQL bug system gemacht haben …
hartmut
24 Mai 12 at 16:16
Der große Bruch wird nicht funktionieren. Der würde bedeuten, dass neue Skripte nicht auf alten Hosts funktionieren, und alte Skripte nicht auf neuen Hosts. Kann man niemandem zumuten, hat schon bei PHP 5.2/5.3 nicht so wirklich funktioniert. Wie das bei 5.3/5.4 funktioniert, wird man sehen.
Sven
25 Mai 12 at 00:29
Ich bin für den großen Bruch.
Ich vermute, dass dieser „global“ gesehen, keine großen Auswirkungen haben wird. Die Hoster nutzen zumeist die Pakete, die von der Distribution her angeboten wird (nehmen wir z.B. Debian was mit den Standardpaketen bei 5.3.3 noch rumgurkt) und was die Updatepolitik von Hostern angeht … naja ich glaub ihr habt da schon so eure eigenen Erfahrungen gemacht.
Zum Thema alte Skripte. Gerade für solche Fälle gibts Unittests und Entwicklungsserver. Es kann mir niemand sagen, dass er PHP-Entwickler ist und nicht in der Lage ist, sich selbst eine kleine virtuelle Maschine aufsetzen kann und dort seine Skripte mit der neuen PHP Version testen will / kann.
Bei jeder neuen Version einer Programmiersprache hat man zwei Möglichkeiten. Entweder ich steige um und teste dann aber auch meine Skripte oder ich behalte die „ältere“ PHP-Version bei und kann mir sicher sein, dass mein Skript läuft.
Bestes Beispiel hierfür findet man im Java-Bereich, wobei häufig eine bestimmte Java-Version vorausgesetzt wird, damit ein Programm läuft.
Alexander Jonser
25 Mai 12 at 06:31
Ich bin auch für einen großen Umbruch in einer neuen Major Version, aber bei gleichzeitigem Long-Term Support für eine PHP 5.x Version, so dass alle genügend Zeit haben, sich auf die neue Version einzustellen.
Es ist ja nucht nur so, dass „plötzlich“ alle Scripte angepasst werden müssen, sondern – was viel fataler ist im impact – alle Entwickler müssen PHP „neu“ lernen. Wenn man das Schritt für Schritt machen würde, hätte man mehrere kleine Änderungen und alle würden sich rasch anpassen. Nur dauert dies in den PHP Zyklen eeeeeewig 😉
Dennis Becker
25 Mai 12 at 09:11
Ein kurzes Statement zu dem Vergleich mit Java:
Warum gibt es denn so viel große Softwareprojekte in alten Java-Versionen? Niemand kann und will sich die Arbeit machen, die Software zu überarbeiten. Da bleiben dann natürlich auch alle Fehler und Sicherheitslücken auf Seiten von Java drin.
Ich bin auch gegen den großen Break, es Bedarf lediglich einer Roadmap, wann was geändert werden soll und dann kann das auch in Minor-Versionen geliefert werden. Damit die professionellen Projekte auf die neuen Dinge eingehen, braucht man nur die entsprechenden Warnungen auszugeben, in keinem Projekt mit entsprechendem Anspruch wird das geduldet.
Wenn man sich dann in einem ersten Schritt z.B. an die Vereinheitlichung der Namen macht, müssen die „Alten“ ja nicht zwingend sofort ungültig werden. Auch Java hat in seinen ältesten Bereichen Inkonsistenzen, aber da spricht man eher selten drüber.
Guido
25 Mai 12 at 13:47
Schnitt und neu…
wieso nicht gleich eine neue Programmiersprache. PHP_new! Eine Runde starke und Zukunftssichere Programmiersprache.
T-Rex
25 Mai 12 at 15:55
Ich bin mehr für viele kleine Schritte. Klar, Full-UTF8-Implementation muss auf einen Schlag kommen und wird (denk wie lang voraus gesagt) auch mit PHP6 kommen.
Mit den vielen kleinen Funktionen würde ich das wie folgt handhaben:
1. Minor-Version: Ersatzfunktion (besseres Naming, Vereinheitlichung der Parameterreihenfolge usw.)
2. Minor-Version: Alte Funktion als DEPRECATED markieren
3. Minor-Version: Alte Funktion fliegt raus.
Ich weiß, dass das ne Weile dauern wird, aber so hat man den Programmierern etwas Zeit gegeben (und auch noch ne ganze Version lang gewarnt!)
Simon Schick
25 Mai 12 at 17:03
Achso, gaaaanz wichtig dabei wäre auf jedenfall ein CLI Tool, welches den eigenen Quelltext untersucht und mir die stellen anzeigt, die „defekt“ sind / werden, damit ich nicht manuell wirklich jeden Aspekt der Software testen muss um zu sheen, was geht noch und was nicht.
Dennis Becker
29 Mai 12 at 15:23
Wie wäre es mit dem Python-Weg: 2.6, 2.7 für die „veraltete“ Software (die es zu genüge auch bei OSS gibt) und nebenbei die reine Lehre von 3.0, 3.1. So hat man genug Zeit für einen Umstieg… Und wer jetzt schon alles richtig machen will, darf es auch – mutet seinen Nutzern jedoch womöglich eine Mehrversionen-Pflege zu.
Robert Kolatzek
30 Mai 12 at 23:53
Ich wäre für einen großen Umbruch.
Das Argument bzgl. Legacy-Software kann ich nachvollziehen. Ich wäre für einen Schalter, welcher dem Interpreter die Version der Laufzeitumgebung vorgibt. Das Läuft ein Script in einem Kompatiblitätsmodus einer bestimmten PHP-Version. So könnte man Legacy-Projekte nach und nach modernisieren.
Das würde dann bedeuten, dass PHP an sich viel größer wird, denn es enthält dann alle unterstüzten Versionen, bzw. Versionen von Funktionen. Nicht notwendigerweise die komplette PHP-Version…
Ich sehe große Chancen vor allem in der Möglichkeit, seine Klassen mit mehr Typehinting zu härten und durch UTF8 Support und eine aufgeräumte Funktionslandschaft einheitlicher (=schneller) zu arbeiten. Von mir aus kann man mit dem Funktionssupport gleich ganz brechen 🙂
Ronald Kirschler
1 Jun 12 at 19:49
Abwärtskompatiboilität gibts ja nicht ohne Grund. Und ich bin auch der Meinung, das ist der Grund, warum Systeme wie Windows so beliebt sind. Und ganz ehrlich – ich wüßte nicht, wie ich für alle Anwendungen, die ich betreue einen Umstieg und die damit verbundenen Änderungen argumentieren soll. Mit „ist die Zukunft“ oder „ist jetzt einheitlicher für den Programmierer“? Da werden die Projekte dann wohl ewig auf PHP5 weiterlaufen.
„Rückwärtskompatibilität kann in den meisten Fällen nicht gewährleistet werden“ und deprecated-Markierungen scheinen mir auch ein Widerspruch zu sein. Bspw. eine umgestellte Argumentreihenfolge kann ja ein deprecated gar nicht abdecken. UTF-8 genauso wenig. Und alle Funktionen jetzt nochmal mit anderen Unterstrichen als Alias anlegen, scheint mir irgendwie auch nicht gerade die Traumvariante.
nk
3 Jun 12 at 20:35
Ich frage mich eher wozu einge für meine Augen sehr eigenartige Funktionen wie z.B. levenshtein (http://php.net/levenshtein) im Core sein müssen. Wieviel Promille der PHP Entwickler benötigen solche Funktionen? Kann man das nicht in ein Modul packen?
cYbercOsmOnauT
9 Jul 12 at 00:33