input type password und chrome

[1unitedpower]

Kontextwechsel sind für Menschen nicht so leicht zu erkennen, für Maschinen jedoch schon.

Das sehe ich genau umgekehrt. Eine Maschine bzw. ein Programm kann nur im Ausnahmefall erkennen, was mit den erzeugten Ausgabedaten noch passieren soll und wird; ein Mensch, insbesondere wenn er sich Programmierer nennt oder als solcher tätig wird, sollte das können, weil er den Überblick nicht nur über das aktuelle Script, sondern über die Zusammenhänge im Projekt hat.

Und inwiefern erleichtert es dem Programmierer die Arbeit, wenn er auch noch Lösungen zu Problemen entwickeln muss, die sich gar nicht stellen müssten?

Ein gutes Beispiel, wo PHP sich gebessert hat, ist die Datenbankschnittstelle, vergleiche die beiden Varianten:

mysql_query("select * from tablename where id = " . mysql_real_escape_string($id));

$db->prepare("select * from tablename where id = :id")->execute([":id" => $id]);

Im zweiten Fall, muss der Programmierer sich um den Kontextwechsel keine Gedanken machen, weil PDO ihn automatisch vornimmt. Das ist schon sehr viel besser, aber es erlaubt dem Programmierer leider immer noch die Query mit String-Konkatenation zusammenzubauen und dort einen Fehler zu machen.

Eine hilfsbereite Programmiersprache stellt deshalb Sicherheitsmechanismen zur Verfügung, die diese Fehlerklasse kategorisch ausschließen. Das vermeidet riesige Sicherheitslücken und spart dazu noch eine Menge Schreibarbeit. PHP und die meisten objektorientierten Sprachen zählen leider nicht dazu.

PHP will Handwerkszeug sein, nicht eine komplette, auf ein bestimmtes Produkt ausgelegte Fertigungsstraße.

Gutes Handwerkszeug sollte dem Programmier Arbeit abnehmen und nicht zusätzlich machen. Die Ausdrucksstärke einer Programmiersprache oder einer Schnittstelle zeichnet sich nicht dadurch aus, was man damit sagen kann, sondern was man nicht sagen muss ^[1].

Klar könnte man eine Scriptsprache auch so entwerfen, dass sie intern eine DOM-Struktur aufbaut, diese dann serialisiert und an den CLient liefert. Dann würde man sich aber die Flexibilität verscherzen, damit neben HTML auch mal Plaintext, CSS, generisches XML, JSON oder etwas ganz anderes zu erzeugen - etwa den binären Byte-Stream einer Bildressource.

String-Konkatenation ist doch völlig unflexibel und die Lösungen die man für eine Sprache wie HTML erarbeitet hat, kann man für CSS oder JSON doch erst recht nicht wiederverwenden. Das Zusammensetzen von Strings erfordert, dass der Programmierer strenge zeitliche Abfolgen in seinem Code einhält. Manuelle Kontextwechsel sorgen dafür, dass Lösungen nicht für verschiedene Einsatzgebiete wiederverwendet werden können. Der Programmierer muss sich jedes mal wieder um die selben nervigen Details des Zielformates scheren. Das ist der Produktivitätskiller und das Sicherheitsrisiko Nummer 1. Nur weil die selben primitiven Operationen immer wieder auftauchen, spricht das nicht für einen flexiblen Progammentwurf.

Wtf? Für eine Sprache, die im Web zu Hause ist.

Tja. Spezialisierung schränkt meistens die möglichen Anwendungsbereiche ein. Ich bin ehrlich gesagt froh, dass man diesen Weg in PHP nicht gegangen ist.

Ich redete nie von Spezialisierung... Obwohl ich finde, dass domänespezfische Sprachen hervorragend dazu geeignet sind robuste Lösungen für wiederkehrende Probleme zu basteln. PureScript hat beispielsweise eine eingebettete domänespezifische Sprache für HTML, das sieht dann so aus:

greet name = h1 $ text $ "Hello, " <> name <> "!"

Auch hier muss der Entwickler sich keine Gedanken darüber machen, ob die Variable name unter Umständen ein Sonderzeichen aus HTML enthält, weil die Funktion "text" einen Textknoten erzeugt.

Etwas bekannter dürfte JSX sein, eine Erweiterung von JavaScript um quasi-HTML-Syntax:

function greet (name) {
  return <h1>Hello, {name}!</h1>
}

Das ist weniger Schreibarbeit als in PHP und bietet eine echte Abstraktions-Schnittstelle.

---

1. In Anlehnung an "Readings in Artificial Intelligence and Databases". Dort fällt dieser Satz in Verbindung mit First-Order Logic. ↩︎