PHP 8 entwickelt sich in eine bedenkliche Richtung | Bergfest talk

Erfahrene PHP Entwickler sind nicht komplett zufrieden mit dem, wie sich PHP entwickelt und haben bedenken um die Zukunft von PHP

🔗 Links
***************************

🌐 Sonstiges
***************************
Weitere Themenvorschläge und/oder Kooperationen in die Kommentare.
#php8 #zukunft

🤑 Affiliate
***************************

* Hierbei handelt es sich um ein Affiliate-Link, es entstehen keine weiteren Kosten beim Einkauf eines Produkts über diesen Link, du unterstützt aber meinen Kanal direkt.

[VitalijMik]

Deine Meinung? Findest du wir brauchen weitere Möglichkeiten um wieder viel Code in eine Zeile zu legen? Oder wäre es sinnvoller andere Dinge wie etwa einen Compiler zu implementieren?

[GGGGGGGGGG]

Ja wir brauchen noch mehr Syntax-Sugar!!! :-p Ich finde neue Arrow-Funktion richtig super, weil sie bei kleinen Callback-Funktionen den Code viel übersichtlicher macht. Was hälst du eigentlich davon, wenn PHP Method-Overloading unterstützen würde, so wie Java oder Swift? Also $foo->bar("test") und $foo->bar(["test"]) wären dann möglich, ohne Methoden wie $foo->barByString() und $foo->barByArray(). Das ist etwas, was ich mir am meisten bei PHP gewünscht habe über die Jahre.

[systemtrader]

Hehe genau diese vielen Probleme hab ich auch gerade. Der weg rein zu finden ist ehrlich beschießen

[xDarkComedy]

Gutes Video! Meiner Meinung nach entwickelt sich PHP genau in die Richtung, die es sollte und die ich benötige. Es wird "erwachsener" und bietet mitunter auch einige Features, die anderen Sprachen fehlen. Mir persönlich fehlen noch Features wie Generics, Method overloading und Enums, dann wäre ich komplett wunschlos glücklich mit PHP. :-)

[darkempire]

Das es Arrow Function in PHP gibt wusste ich nicht ^^. Less is more würde ich sagen.

[janpatrickmoller]

Persönlich finde ich das die "Eintritts Barrikade" zur Sprache im direkten Vergleich zu früher, nicht viel höher ist als damals auch. Bevor man sich OOP zuwendet, programmiert man sowieso erst mal straight, Prozedural, runter. Im späteren verlauf merkt man von selbst, das man Sachen auslagern muss und gelangt an Erfahrung wie man Sachen auslagert. Irgendwann kommen dann Funktionen dazu und dann irgendwann OOP. Ich denke das ist der normale Lernweg, aus der Sicht von jemanden der sich die Sachen selbst beigebracht hat - und dieser ist nicht komplexer geworden durch die neuen Versionen und Funktionen.

Zum Thema Lehrer: Ein Lehrer gibt nur ein grobe Richtung. Gerade in der Programmierung gibt es bei manchen Sachen mehrere Lösungswege. Ich denke nicht das das Lehren von PHP schwieriger geworden ist. Ab einen bestimmten Punkt ist man dann auch soweit, das man Fachbücher liest die sich rein auf Struktur und Verhalten beziehen. Ähnliches Verhalten hat für mich in den Kontext eine Lehrperson, diese zeigt auf "Hey das ist die Richtung" aber die Umsetzung ist dabei jeden selbst überlassen. Grundlegendes wie z.b. Iteration und Rekursion können dabei auch gelehrt werden, ohne das wir direkte Codeschnipsel haben um den theoretischen Aspekt zu verstehen.

Bei Javascript kann ich auch nicht zustimmen. Persönlich, mag ich Javascript nicht. Es ist nicht meine Sprache. Aber aufgrund meiner Arbeit muss ich mich damit beschäftigen. Und bei Javascript ist das Hauptproblem das viele alten Browser neues Javascript einfach noch nicht richtig verstehen. Deswegen haben wir auch Compiler wie Babel, die das moderne Javascript in altes Javascript umwandeln, was alle Browser verstehen. Es geht dabei nicht darum das Entwickler oder neuer Entwickler den Code der transpiled wurde tadellos versteht.

Bei Sachen wie Switch/Match bin ich nicht deiner Meinung, beide haben andere Verhaltensweisen. Genau wie Arrow Funktionen. Ich denke die machen den eigentlichen Code leserlicher. Und wer da den Zusammenhang verstanden hat, wie welche Variablen in welchen Scope zur Verfügung stehen, der wird auch wissen wann eine Arrow, und wann eine normale Callback Funktion einzusetzen ist. Für den Rest gilt: am Ball bleiben. Das ist das Problem von zu vielen Entwicklern meiner Meinung nach und warum manche sagen: "Das wird unleserlich und gehört nicht zur Sprache". Oder auch gut: "mysql_ treiber sind weg" nach etlichen Jahren an deprecation Warnings

Noch eine Sache ist die Angabe bei den named arguments, ja, das ist schwerer zu verstehen, aber wenn man sich anguckt, das diese genau so auch festgelegt werden auch in den jeweiligen aufrufen, so finde ich das ganze nicht mehr "ungewohnt". Man muss hier ja auch differenzieren zwischen der Variable und den benannten Argument. Es währe doch viel "übler" wenn die named arguments nun auch Dollar Zeichen haben. Das eine ist ne Variable und das andere n benanntes Argument. Zwei völlig verschiedene Sachen

[danielgrana]

Ich kann die Angelegenheit aus Sicht eines Anfängers vielleicht betrachten, obwohl mir die Grundlagen relativ gut bekannt sind. Generell finde ich Veränderungen an einer Programmiersprache nicht verkehrt. Gerade wenn es einfacher, strukturierter wird. Aber gerade, wenn man die Basics nicht drauf hat und noch sehr viel nachdenken muss, sind solche permanenten Bewegungen oder Änderungen in der Syntax sehr hinderlich. Ein "blutiger"-Anfänger hat somit kauf bis keine Chance sich an eine Syntax zu gewöhnen, weil wenig später alles wieder ganz anders ist. Sowas ist übrigens auch demotivierend.

[mr.wasgehtsiedasan]

Glückwunsch zu 2000 Abonnenten. Ich sagte ja das du mehr als 1000 haben wirst bis zum ende des Jahres 😁👌

[gelbehexe]

Stimme dir voll zu, zu viele Varianten, um eine Aufgabe zu erfüllen sind nicht gut, denn darunter leidet die Lesbarkeit. Dieses Defizit muss dann in Teams durch Festlegen von Coding Style Guides kompensiert werden. Da lieber mehr Wert auf Leistungs-Features gelegt, das bringt uns alle weiter.

[alivesurvive]

Bin zwar Anfänger, aber kann eure Meinung schon gut nachvollziehen. Ich nutze aber allgemein eher einfache Funktionen, mit denen man eigentlich auch alles erreichen kann.
Am schlimmsten ist meiner Meinung nach diese prozedural/objektorientierte Regelung. Es gibt einfach zu viele offene Möglichkeiten. Beispiel: Man muss in einer Methode eine Variable nicht einmal deklarieren. Anfänger kommen da schnell durcheinander und am Ende entsteht ein kaotischer Code. :D Ist bei mir teilweise leider so, da ich objektorientiert erst seit Kurzem arbeite.

[SvenWagener]

Also dass der Code für Anfänger unleserlicher wird stimmt natürlich. Das Problem hat man definitiv bei JS. Das macht die Sprache ein wenig sperrig für Neueinsteiger. Allerdings ist das eigentlich kein Problem, wenn man die Sprache von Grund auf richtig lernt. Wenn man das Spiel spielen will, sollte man am besten eben auch das Tutorial machen und dann fügt sich das Bild mit der Zeit automatisch. Am Ende hat man mehr Möglichkeiten zum Ziel zu kommen als wenn man sich von vornherein einschränkt.

Das Problem der Leserlichkeit von Code besteht auch nicht unbedingt wegen dem Syntax-Sugar, sondern im schlechten Code ganz allgemein. Und dazu gehören unübersichtliche Klassen und Funktionen, uneindeutlige Namensgebung usw. Aber das Problem gab es bei PHP immer, weil PHP immer darauf angelegt war einfach zu sein um einen einfachen Einstieg zu bieten. Da holt man sich eben immer auch alle Anfänger mit ins Boot (und das ist auch gut so).

[hamwardegp]

Spannende Sichtweise 👍 BTW: Herzlichen Glückwunsch zur 2000er Marke

[typo-lexikon]

Danke für das Wort „Syntaxsugar“ 😂 Köstlich. Darf ich das übernehmen, oder hast Du da nen Copyright drauf 😅

[Darkray]

hallo vitalij, sehr interessante Ansichtsweise. Syntaktischer Zucker kann einem das Leben versüßen, aber wenn es überhand wie leider bei JS nimmt, wie du auch gesagt hast, dann macht man isch Sorgen über seine geliebte Sprache PHP^^

[aristor]

Sehr interessantes Video. Vielen Dank ^^

[ProgrammierenMario]

Meiner Meinung nach sollte man als Anfänger bei der altbewährten Syntax bleiben. Zumal davon auszugehen ist das diese auch am häufigsten angewendet wird. Als Lehrer, Vorbild oder Mentor hat man ohnehin die Verantwortung seinen Schüler davor zu bewahren das er durch die Anzahl der Möglichkeiten nicht erschlagen wird.

Ich halte es für sehr sinnvoll ab einem bestimmten Punkt ein Framework zu verwenden. Somit wird schon bis zu einem gewissen Grad der Wildwuchs verhindert der durch die Anzahl der vielen Varianten mit den nativen Möglichkeiten erst entstehen kann. Zudem nutzen alle dann das selbe Pattern bzw. alle einigen sich dann wie was womit umgesetzt wird.

[AmlorBluefog]

Hmmm… ich weiß, in welcher Richtung gedacht worden ist… habe mich aber gefragt, ob nicht gerade am Anfang ein Widerspruch da war. Die 3 Schreibweisen von z.B. if gab es schon immer… d.h. ein Anfänger weiß auch nicht unbedingt, warum er welche wann wie nutzen soll… und trotzdem haben wir alle PHP gelernt –  so weit ich mich erinnern kann, wurde das ja damals so umgesetzt, um halt mehrere Sprachen ähnlich zu sein und sowohl den Switch von C zu PHP als auch von Basic her zu ermöglichen (und lassen wir mal '?' bzw '??' eben raus, weil das streng genommen andere Sachen sind und nur indirekt was mit IF zu tun haben). Und wo ich gerade Switch erwähnt habe… Switch und Match sind IMHO zwei unterschiedliche Konstrukte und haben zwei verschiedene Anwendungen. Arrow Funktionen – gut, mag ich auch in anderen Sprachen nicht, kann aber nachvollziehen, warum einige sie Mögen… Lambda-Funktionen können aber vieles vereinfachen. Versteht sie ein Anfänger? Meine Azubis lernen sie erst im 3. Jahr und kommen dann meistens auch damit zurecht.

Sprachen entwickeln sich. Wir Programmieren nicht mehr, wie in den 80ern, 90ern oder zur Jahrtausendwende – das sich also PHP so entwickelt hat, hatte auf jeden Fall seine Vorteile. Bin ich mit allen Entscheidungen zufrieden? Nein. Fehlen mir Dinge (GENERICS ^^) ja (Maps, Trees, Vectors… halt das DS Paket… packt es endlich in die Core *g*)… die Entscheidungen bis 8.2 finde ich aber gut und sie bringen mir Vorteile… auch wenn ich bei neuen Azubis immer wieder mein Unterricht anpassen muss und es jedem Jahrgang anders erklären. Das ist aber ein Preis, den ich gerne 'zahle'.

Was die Umsetzung aber angeht… also das Beispiel mit dem # @ und so weiter… ja, da fände ich einen anderen Umgang auch… besser. Kommt bei mir aber nicht so sehr zum tragen, da ich die neuen Versionen immer so 1-3 Monate vor dem Release erst betrachte und mich dann freue, was umgesetzt worden ist.

Ich muss aber auch sagen… ich wechsle oft die Sprache und guck mir immer mal wieder eine andere an… vielleicht freue ich mich dann mehr über gewisse Änderungen, weil ich sie schon in anderen Sprachen entdeckt hatte und daher kenne.

Ach ja… und Coffee/Type Script ist ja nicht (nur) da, um JavaScript lesbarer zu machen… sondern um grundlegende Probleme von JS zu beheben/umgehen… aber – wenn der Erstentwickler von seiner Sprache sagt: 'Tragt sie bitte zu Grabe', dann sagt das ja schon alles ;) das ist bei PHP ja aber nicht der Fall… hingegen ein ausführbares Programm aus PHP zu compilieren… wäre ein Blick wert.

P.S. die Änderung von array() zu [] hatte mich auch erst verwundert… ich würde sie aber nicht missen wollen ;) . o O (damals, in den 'guten alten Zeiten')

[TotoMacFrame]

Spannendes Video, an sich bin ich da sehr bei dir, andererseits kann man auch sagen... nur weil es geht, muss man es nicht nutzen und kann (noch) bei der alten Syntax bleiben.
Nur an einer Stelle hast du dich glaube ich vertan (09:46). Hier geht es nicht darum, das Dollarzeichen bei Parametern weg zu lassen, hier geht es um die Named Arguments. Ich kann also gezielt einen von mehreren Parametern bei seinem Namen ansprechen, um ihm dann einen Wert zu geben. Das htmlspecialchars im Video ist ein wundervolles Beispiel, hier gebe ich nur den ersten und den vierten Parameter an, und lasse den zweiten und dritten weg. Ich gebe also nur zwei an, und "mappe" sie auf die 1 und auf die 4, was nur geht wenn ich irgendwie sagen kann, mein zweites Argument soll den vierten Parameter füllen. Dafür muss ich ihn beim Namen nennen. Das Dollarzeichen gehört da nicht hin, denn mit einem Dollar spreche ich das Argument ja erst innerhalb der Funktion an, wenn ich in dessen Scope bin.

[TeX]

"Neuer" Syntax machen es einfach nur, wie Du schon sagst, unleserlicher und anfälliger für Fehler, besonders wenn mehrere dran arbeiten. Man sollte drauf verzichten und die bekannten Basics nutzen.

[wordaslaw]

hmm und was für eine Version nimmt man jetzt? welche empfehlung?