Über die Zukunft einer Programmiersprache

Make PHP Great Again
2 Kommentare

Wie soll sich PHP als Sprache weiterentwickeln? Diese Frage wird momentan im Kontext der Planung für PHP 8.0 diskutiert. Andrew Carter macht in diesem Artikel einen Vorschlag, wie PHP wieder zu alter Größe geführt werden könnte.

Make PHP Great Again

„Make PHP Great Again“ – entschuldigen Sie bitte die reißerische Überschrift. Aber ich denke, das Thema dieses Beitrags verdient die Aufmerksamkeit eines jeden PHP-Entwicklers.

Eine ganze Weile schon herrscht zwischen PHP und der Entwickler-Community so etwas wie eine Hass-Liebe. Eine fast vollständige Einführung in das Thema „PHP hate“ findet sich im berühmten Blogpost PHP: a fractal of bad design.

In diesem Blogpost nimmt der Autor fast jeden Aspekt der PHP-Sprache aufs Korn und trägt eine recht überzeugende Argumentation vor, um PHP ins Archiv der Geschichte der Programmiersprachen zu verbannen. Der Artikel ist zwar nicht mehr ganz aktuell – er wurde 2012 veröffentlicht –, doch vieles von der geübten Kritik ist heute noch gültig.

Ich persönlich hasse und liebe gleichzeitig so ziemlich jede Programmiersprache, mit der ich mich bisher beschäftigt habe. Ich liebe C, weil ich dadurch Konzepte der Hardware-nahen Programmierung kennengelernt habe. Gleichzeitig hasse ich es, dass es zwei Stunden dauert, um zwei Strings zusammenzuführen.

Ich mag Python wegen der Machine Learning und Raspberry Pi Communities. Aber ich finde es furchtbar, dass es praktisch unmöglich ist, Typensicherheit und ein anständiges Objektorientiertes Design umzusetzen.

Ich liebe JavaScript und die asynchronen Programmiertechniken, die es gefördert hat. Aber ich hasse es, dass ich 9000 Abhängigkeiten in meinem node_modules-Verzeichnis brauche, um eine Hello-World-Anwendung auf Port 80 auszuliefern.

Und es gibt natürlich auch jede Menge Dinge, die ich an PHP liebe. Als ich jünger war und kein Geld für Server hatte, war das kostenlose PHP Hosting alles, was ich hatte. Es machte mir die objektorientierte Programmierung zugänglich, und ich mag den Package Manager und sein Ökosystem.

Trotz alledem hege ich eine leidenschaftliche Ablehnung gegenüber den PHP-Core-Funktionen:

  • Du willst ein Array mappen? array_map($callback, $input)
  • Du willst ein Array filtern? array_filter($input, $callback)
  • Du willst den Typ einer Ressource wissen? get_resource_type($resource)
  • Du willst den Typ einer Variablen wissen? gettype($variable)
  • Du willst prüfen, ob eine Variable ein String ist? is_string($variable)
  • Du willst prüfen, ob eine Variable gesetzt ist? isset($variable)

PHP hat alle Narben einer Sprache, die über einen langen Zeitraum gewachsen ist und ohne übergreifende Konzeptionierung von vielen verschiedenen Leuten erweitert wurde. Der Prozess, um Änderungen an der Sprache einzuführen, ist mittlerweile zwar deutlich strikter. Doch wir müssen viel mehr darüber sprechen, wie wir den verursachten Schaden beheben können.

Die Alternative wäre, diese schreienden Inkonsistenten als Teil der Sprache zu akzeptieren, bis sie stirbt. Die Argumente für oder gegen eine Behebung der Inkonsistenz-Probleme bleiben immer dieselben. Der einzige Unterschied ist, dass es in der Zukunft immer einfacher werden könnte, Brüche in der Rückwärtskompatibilität umzusetzen, da immer mehr Entwickler sich von PHP abgewandt und einer anderen Sprache zugewandt haben könnten.

Jedes Jahr investieren riesige Unternehmen wie Google oder Microsoft gewaltige Summen dafür, bessere Programmiersprachen zu entwickeln. Wenn PHP in der Zukunft mit Sprachen mithalten will, die aktuell auf dem Reißbrett entworfen und weiterentwickelt werden, muss es ab und zu seine Altlasten loswerden.

Theoretisch ist es sehr einfach, die PHP Core-Funktionen in Ordnung zu bringen. Im ersten Schritt werden Deprecations für Funktionen ausgesprochen, die ersetzt werden müssen. Dann muss sichergestellt werden, dass adäquate Ersetzungen implementiert und zur Nutzung empfohlen werden. Nach einer gewissen Zeit können die als „veraltet“ markierten Funktionen, die niemand mehr nutzt, entfernt werden.

Diskussionen über gute Ersetzungen gab es bereits. Der RFC zur Bereinigung der inkonsistenten Funktionsnamen brachte das Thema 2015 auf den Tisch, wurde aber niemals zu Ende geführt. Mein Lieblingsvorschlag dabei war die Einführung skalarer Objekte, mit denen der Weg für ein neues API bereitet würde, das sich am gesunden Menschenverstand statt an der C POSIX Library orientieren würde.

// Statt
$lowerCaseFruit = ['apples', 'oranges', 'grapes'];

$upperCaseFruit = array_map(function ($fruit) {
    return strtoupper($fruit);
}, $lowerCaseFruit);

// Könnten wir haben
$lowerCaseFruit = ['apples', 'oranges', 'grapes'];

$upperCaseFruit = $lowerCaseFruit->map(function ($fruit) {
    return $fruit->toUpper();
});

Tatsächlich ist der Prozess, die PHP Core-Funktionen zu vereinheitlichen, aber schwieriger. Der erste Schritt besteht in Wirklichkeit darin, die Gruppe der PHP Internals zu überzeugen, dass es sich lohnt, an dieser Stelle Arbeit zu investieren und einen Bruch mit der Abwärtskompatibilität zu riskieren. Der Weg, um Teil der Internals Community zu werden, ist ziemlich nebulös, und es braucht Zeit (und eine Portion Voodoo), um das nötige Karma und den Respekt zu erhalten, damit man selbst etwas bewirken kann.

Wenn nun aber die Community kollektiv die Trommel laut genug rührt, besteht zumindest die Chance, dass einige der Schlüsselfiguren der Gruppe ihre brillianten Köpfe zusammenstecken und sich dieser Aufgabe widmen.

Der Anlass für diesen Beitrag ist, dass momentan das Release von PHP 8 auf der Internals-Mailing-Liste diskutiert wird. Der aktuelle Vorschlag lautet, dass PHP 7.3, das kurz vor dem Feature Freeze steht, die letzte Version vor PHP 8 sein wird (abgesehen von einer Version 7.4, die nur Deprecations enthalten soll).

Ein derart wichtiges Feature wie die skalaren Objekte würde sicherlich nur in einer Major-Version umgesetzt werden. Allerdings gibt es bereits eine Liste wichtiger Features für PHP 8, ohne dass die Probleme mit den Core Functions dort erwähnt würden.

Wenn wir PHP wieder „großartig“ machen wollen, oder wenigstens „vor dem Jahr 2025 etwas besser“, dann ist wahrscheinlich jetzt eine gute Zeit, dafür zu trommeln!

Dieser Beitrag ist im englischen Original erschienen auf Andrew Carters Blog: Make PHP Great Again

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

2 Kommentare auf "Make PHP Great Again"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Irrelevant
Gast

Ich finde die Behauptung dass man mit Python nur wenig Ojektorientiert arbeiten könne ein Zeichen dass man sich selbst mit Python noch nicht hinreichend beschäftigt hat. Python ist sehr „tolerant“ was die Syntax angeht und auch was die Sicherheit bei Datentypen angeht, muss man sich schlicht ein klein wenig in defensivem programmieren üben.

X
- Gib Deinen Standort ein -
- or -