Hallo, > > > 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? gar nicht - aber als guter[tm] Programmierer sollten einem derartige Routinegeschichten in Fleisch und Blut übergegangen sein, so dass man sie gar nicht mehr bewusst wahrnimmt, sondern einfach automatisch macht. Quasi aus dem Rückenmark, nicht mehr aus dem Großhirn. Ich vergleiche das mal mit einem guten Koch, der bei seiner Arbeit auch nicht mehr darüber nachdenkt, was da noch zum Abrunden oder Würzen in die Soße rein muss; er hat das im Gefühl. Oder der Blick in den Rückspiegel im Auto: Das ist ein solcher Automatismus - ich **weiß** doch, dass das Bild seitenverkehrt ist, also lese ich Schriftzüge auch schon von rechts nach links, ohne dass es mir überhaupt bewusst wird. Und wenn dann ein Feuerwehr- oder Rettungswagen hinter mir ist, dessen Front gleich in Spiegelschrift bemalt ist, dann passt's wieder nicht. > Ein gutes Beispiel, wo PHP sich gebessert hat, ist die Datenbankschnittstelle, vergleiche die beiden Varianten: > > ~~~php > mysql_query("select * from tablename where id = " . mysql_real_escape_string($id)); > > $db->prepare("select * from tablename where id = :id")->execute([":id" => $id]); > ~~~ Als Softwareentwickler und Programmierer der alten Schule ist mir die erste Variante eingängiger und leichter zu überblicken. Aber das ist natürlich eine Frage der Gewöhnung. > 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. Natürlich. Wenn man um die Hilfestellungen einen Bogen macht, nützen sie einem nichts. > > 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. Ja. Ich will aber weder zwanzig einzelne Werkzeuge im Kasten haben, noch ein hochkomplexes Multifunktionstool - ich möchte ein paar wenige, möglichst einfache Werkzeuge haben, deren korrekte Handhabung gern auch etwas Übung voraussetzen darf. Ich weiß, ich bin da ein bisschen archaisch, aber das aus Überzeugung. ;-) > String-Konkatenation ist doch völlig unflexibel Wenn letztendlich Text dabei herauskommen soll, ist sie IMO das flexibelste überhaupt. > Das Zusammensetzen von Strings erfordert, dass der Programmierer strenge zeitliche Abfolgen in seinem Code einhält. Natürlich. Das setze ich voraus. > > > 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... Doch, gewissermaßen schon. Du hast implizit verlangt oder gewünscht, dass eine Sprache (wie hatten PHP als Beispiel) die Besonderheiten des Kontexts selbst erkennen und berücksichtigen solle. Das **ist** eine Spezialisierung; sie prädestiniert die Sprache dann für diesen speziellen Einsatzfall, macht sie aber für andere Fälle umständlich, im Extremfall unbrauchbar. > ~~~purescript > greet name = h1 $ text $ "Hello, " <> name <> "!" > ~~~ Das sieht ja fast sp kryptisch aus wie Perl. ;-) > Etwas bekannter dürfte [JSX](http://buildwithreact.com/tutorial/jsx) sein, eine Erweiterung von JavaScript um quasi-HTML-Syntax: > > ~~~jsx > function greet (name) { > return <h1>Hello, {name}!</h1> > } > ~~~ Auch das sieht syntaktisch irgendwie kaputt aus, wenn man es nicht kennt. Ein String ohne eindeutuge Stringbegrenzer verursacht bei mir leichte Übelkeit. Und wenn ich eine geschweifte Klammer in der Ausgabe haben möchte, müsste ich die diese vermutlich wieder escapen. Genau, ein Kontextwechsel. ;-) So long,  Martin -- Bei der Umsetzung von guten Ideen hapert es meist viel mehr an der Wolle als an der Könne.

Hallo, > > > 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? gar nicht - aber als guter[tm] Programmierer sollten einem derartige Routinegeschichten in Fleisch und Blut übergegangen sein, so dass man sie gar nicht mehr bewusst wahrnimmt, sondern einfach automatisch macht. Quasi aus dem Rückenmark, nicht mehr aus dem Großhirn. Ich vergleiche das mal mit einem guten Koch, der bei seiner Arbeit auch nicht mehr darüber nachdenkt, was da noch zum Abrunden oder Würzen in die Soße rein muss; er hat das im Gefühl. Oder der Blick in den Rückspiegel im Auto: Das ist ein solcher Automatismus - ich **weiß** doch, dass das Bild seitenverkehrt ist, also lese ich Schriftzüge auch schon von rechts nach links, ohne dass es mir überhaupt bewusst wird. Und wenn dann ein Feuerwehr- oder Rettungswagen hinter mir ist, dessen Front gleich in Spiegelschrift bemalt ist, dann passt's wieder nicht. > Ein gutes Beispiel, wo PHP sich gebessert hat, ist die Datenbankschnittstelle, vergleiche die beiden Varianten: > > ~~~php > mysql_query("select * from tablename where id = " . mysql_real_escape_string($id)); > > $db->prepare("select * from tablename where id = :id")->execute([":id" => $id]); > ~~~ Als Softwareentwickler und Programmierer der alten Schule ist mir die erste Variante eingängiger und leichter zu überblicken. Aber das ist natürlich eine Frage der Gewöhnung. > 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. Natürlich. Wenn man um die Hilfestellungen einen Bogen macht, nützen sie einem nichts. > > 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. Ja. Ich will aber weder zwanzig einzelne Werkzeuge im Kasten haben, noch ein hochkomplexes Multifunktionstool - ich möchte ein paar wenige, möglichst einfache Werkzeuge haben, deren korrekte Handhabung gern auch etwas Übung voraussetzen darf. Ich weiß, ich bin da ein bisschen archaisch, aber das aus Überzeugung. ;-) > String-Konkatenation ist doch völlig unflexibel Wenn letztendlich Text dabei herauskommen soll, ist sie IMO das flexibelste überhaupt. > Das Zusammensetzen von Strings erfordert, dass der Programmierer strenge zeitliche Abfolgen in seinem Code einhält. Natürlich. Das setze ich voraus. > > > 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... Doch, gewissermaßen schon. Du hast implizit verlangt oder gewünscht, dass eine Sprache (wie hatten PHP als Beispiel) die Besonderheiten des Kontexts selbst erkennen und berücksichtigen solle. Das **ist** eine Spezialisierung; sie prädestiniert die Sprache dann für diesen speziellen Einsatzfall, macht sie aber für andere Fälle umständlich, im Extremfall unbrauchbar. > ~~~purescript > greet name = h1 $ text $ "Hello, " <> name <> "!" > ~~~ Das sieht ja fast sp kryptisch aus wie Perl. ;-) > Etwas bekannter dürfte [JSX](http://buildwithreact.com/tutorial/jsx) sein, eine Erweiterung von JavaScript um quasi-HTML-Syntax: > > ~~~jsx > function greet (name) { > return <h1>Hello, {name}!</h1> > } > ~~~ Auch das sieht syntaktisch irgendwie kaputt aus, wenn man es nicht kennt. So long,  Martin -- Bei der Umsetzung von guten Ideen hapert es meist viel mehr an der Wolle als an der Könne.