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?
@@yannickw_ der Compiler ist ja bereits eingebaut und es ist ja nicht nur eine Theorie, Hack von Facebook hat es ja auch bereits eingebaut. Die Scripte werden schneller ausgeführt, allerdings hast du dann weitere Problematiken, denn dann musst du deinen Code speziell aufbauen damit du nur Teile kompilierst. In C#/Java gibt es durchaus Programme wo man dann mehrere Stunden eine Applikation kompilliert ;) Will sagen, es bringt nicht nur Vorteile mit sich. Aber eben Optionen.
@@yannickw_ Aber wo ist denn das wirklich relevant? Das Problem bei PHP ist doch eher, dass jeder Request ein eigener Prozess ist. Und die Kommunikation mit der DB und externen Quellen schlägt sich viel eher nieder. Wenn man halt wirklich auf Biegen und Brechen Performance auf Applikationsebene braucht, warum nimmt man dann nicht z. B. Go? Unglaublich performant, niedriger Speicherverbrauch, Nebenläufigkeit, ... Auf der einen Seite möchtet ihr nicht, dass PHP featureseitig weiterentwickelt werden soll, auf der anderen soll es aber alle möglichen Bereiche abdecken. Warum Offline-Applikationen? Dafür ist es halt nicht gemacht.
@Karl Koslowski naja offline applikationen möchte man machen weil man andere Programmiersprachen nicht so toll findet. Es gab ja in der Vergangenheit beriets mehrere Projekte, zum Beispiel PHP GTK, damit konnte man schon mit PHP, GTK ansteuern und fenster Befehle ausführen so wie python es auch aktuell macht. Problem bei PHP ist dass der code nicht kompelliert wird und man kann somit nicht eine Datei einfach weitergeben und niemand hat dann den Zugriff auf deinen Code. Ich kann mir schon vorstellen, einige Tools mit PHP umzustezen die Offline oder zumindest mit einer SQLIte DB Laufen
@@VitalijMik Aber vielleicht sollte man lieber eine Sprache nehmen, die dafür geeginet ist, und nicht auf Krampf PHP, nur weil man das irgendwie auch machen könnte.
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.
Ich weiß nicht, mein Code war auch ohne den Arrow Functions sehr übersichtlich, einfach Early return und du hast oft nur zwei zeiler im Code. Wegen Methode overloading, das wäre tatsächlich ein interessantes neues Feature, das würde übrigens in PHP schon zu PHP 5 Zeiten vorgeschlagen und es wurde dann auch abgelehnt. In PHP ist es nicht einfach umzustezen weil du dynamische Typen hast. Swift konnte das einfach umsetzen weil die keine "altlasten" hat oder zuminstens nicht so viele wie PHP. Also klar bei einfachen beispielen wie bei dir mit string vs array ist es vielleicht noch einfach. Aber was ist mit Person[] vs User[] beides arrays nur mit verschiedenen objekten drin und man möchte eventuell da anders vorgehen. Da ist es schwierig für PHP performant zu unterscheiden welche Methode aufgerufen wird. Auch das lesen des Codes wird schwieriger, du musst ja wissen welchen Typ deine variable gerade hat damit du weiß welche Methode gerade aufgerufen wird. Durch das Method overloading kannst du nicht mal eben vi anschmeißen auf dem Live Server und dir den code anschauen, musst dann debuggen. TL;DR Prinzipiell ein nettes feature, kann zu problemen führen, wird vermutlich nie in PHP kommen auf grund von schwacher typisierung und altlasten diesbezüglich
@@VitalijMik Hi Vitalij, vielen dank für deine Antwort. Dann muss ich mich wohl von diesen Traum verabschieden :). Zwecks der Arrow-Funktion, vielleicht liegt es daran, dass ich seit meinen Anfängen auch stets mit JavaScript (dann auch TypeScript) zu tun habe. Aber diesen Code finde einfach praktischer und auch leserlicher: $oneAdded = array_map(($i) => $i+1, [1,2,3]); als diesen hier: $oneAdded = array_map(function($i) { return $i+1; }, [1,2,3]); Aber wie gesagt, ich bin diese Syntax gewöhnt. In Swift und einigen anderen Sprachen gibt es auch diese Abkürzungen für Closures und sehen noch ulkiger aus. Viele Grüße!
@@GGGGGGGGGG96 das Problem was an der Arrow funktion war, dass die Funktion anders ist als die normalen funktionen. In Javascript ist es nicht so. In PHP Hast du variablen nur im Function scope und du musst die von außen via use oder global hineinziehen. In JS hattest du immer alle variablen die draußen waren auch drinn gehabt deshalb gibt es this und that. Die Arrow Function wurde in PHP inkosistent umgesetzt, wir haben schon genug inkonsistente features in PHP (haystack needle problem zb) und jetzt haben wir ein weiteres. Wieso kann man in arrow function einfach so variablen von außen benutzen? sowas hat es nie in PHP gegeben.
@@VitalijMik Die (Fat-)Arrow Funktion funktioniert mMn identisch wie in JS: - kein Scope / identisch zu "static function" (spart Speicher / erspart umständliches importieren via "use()"), - das letzte Statement wird zurückgegeben (auch ohne explizit return angeben zu müssen) kleiner Unterschied: in JS brauch es kein "fn" und bei nur einem Argument auch keine Klammern. Ich verwende diese Ausdrucksform häufig für kurze, knackige Callbacks, z.B. Formatter, Renderer, Transformer, Mapper usw. - aber nicht generell für alle Lambdas. Nur wenn es die Lesbarkeit für mich und den Reviewer erhöht - nicht aus Faulheit oder Platzmangel ;) . In passenden Fällen (und nur dort sollte man den Shortsyntax einsetzen) ist plötzlich so viel weniger "Rauschen" da und Schreiben/Lesen macht einfach mehr Spaß. Ich finde auch die Deklaration von Settern/Gettern in C# oder TypeScript viel eleganter ausgedrückt und wartbarer als die meist wertlosen aber "sicherheitshalber schon mal generierten" PHP/Java Setter/Getter getABC(), setABC() - speziell in Entity- und DTO Klassen.
Hey. Kannst du mal ein Video machen in dem du zeigst, wie man vorgeht wenn man sein php quellcode von bspw v7 auf v8 updatet? Habe nichts von dir dazu finden können
Danke für deine schnelle Rückmeldung! Ich hab auf dem PC noch ein altes script auf php 5 mit der template engine smarty gefunden, wollte das mal aktualisieren. geht das auch mit dem programm?
Nichts gegen PHP, aber bei mir hat es mit 5.7 aufgehört... In Zeiten von NodeJS, Django, Rust und Go, bin ich nicht mehr mit PHP in Berührung gekommen. Hat es noch Vorteile in irgendeiner Form?
Naja die Vorteile liegen halt darin dass noch viele andere APplikationen damit umgesetzt wurden und einem die Sprache viel mehr liegt. Direkte vorteile kann ich nicht nennen weil ich nicht mit Python/DJango, Rust/Go, NodeJS wirklich gearbeitet habe. Das einzige was ich als Vorteil gegenüber NodeJS ansehen würde ist der Packagemanager von PHP und das Arbeiten mit Interfaces ohne extrene Sprach KOnstrukte wie Typescript zu nutzen. Und natürlich weil PHP nicht asynchron ist, was die entwicklung etwas einfacher macht.
@@VitalijMik Viele andere Applikationen? Für mich hatte PHP immer nur einen Anwendungsfall und zwar Webseiten dynamisch mit Inhalt zu füllen, was es ja auch sehr gut macht, sieht man ja daran wie weit Wordpress und Laravel verbreitet sind (und natürlich rein PHP^^). Ich persönlich würde nicht auf die Idee kommen mit PHP irgendetwas anderes umzusetzen. Habe in einem anderen Kommentar von dir gelesen: PHP nutzen um Webseiten zu crawlen. Ich würde niemals auf diese Idee kommen, dies geht doch easy mit Python und Beautiful Soup und mit Selenium kann ich alles mögliche noch automatisieren in Webanwendungen. Da starte ich doch Lokal keinen Server der mir PHP interpretiert. Naja NodeJS hat ja auch nen Packetmanager obwohl da ja die Meinungen auseinander gehen und nicht alles in JavaScript / NodeJS ist asynchron. TypeScript ist auch nur "syntactic sugar", das was überbleibt ist auch nur unschönes JavaScript xD Ich wollte PHP auch gar nicht schlecht reden, immerhin ist das die erste Programmiersprache die ich gelernt habe^^
@KDominic_ naja neben Laravel und Wordpress gibt es zum Beispiel Shopware, damit wurden auch sehr viele Shops umgesetzt, gerade jetzt zu Corona Zeiten wurde es noch mehr gefragt. Selbst große Unternehmen suchen weiterhin PHP Entwickler weil man nicht einfach so einen Code der vor jahren entwickelt wurde nicht einfach wegschmeißen kann, solange das Geld Produziert. Banken und Möbelgeschäfte hatten selbst vor paar Jahren noch Basic/Smalltalk applikationen und die Entwickler der Sprachen konnten auch den Gehalt bestimmen wie sie wollten. Weil es kaum jemanden gab der sich das noch antun wollte. Will sagen nur weil etwas nicht Modern ist und keine Vorteile gegenüber anderen SPrachen hat, heißt es ja nicht dass es nicht gebraucht wird. Klar könnte man bestimmt das alles was ich mit PHP umsetze auch mit NodeJS, Python usw umsetzen. Allerdings wenn ich nur eine Webseite entwickle und ab und zu paar kleinere Tools, finde ich, macht es für mich gar kein Sinn alles was ich bisher gelernt habe und Beruflich mache dann einfach wegzuwerfen. Ich will auch nicht NodeJS/Python/Rust unw. haten. Sicherlich haben die ihre Anwendungsgebiete und sicherlich haben die viele tolle tools. Aber ich könnte auch genauso gut sagen. Dann kann ich gleich C# benutzen, hat eine Saubere Syntax, kann desktop Applikationen und ASP.Net auch noch Webseiten. Hat ein Mysql Client der Prepared Statements unterstützt und hat sogar ein Compiler. Ich finde man sollte nicht Sprachen nach Vorteilen/Nachteilen abwägen sondern nach dem was man mag und was einem spaß macht. Ich habe immer noch Spaß an PHP und NodeJS habe ich zu Anfangszeiten probiert und nach kurzer Zeit aufgegeben. Teilweise kommt man da aber nicht drumherum wegen less/webpack usw, da benutze ich es dann. Ich weiß dass NodeJS ein Packetmanager hat, vielleicht sogar 2-3 das letzte Mal als ich es mir angesehen habe war Yarn das non plus ultra und NPM war schlecht. Python nutze in Blender oder Gimp weil es dort unterstützt ist. Wäre dort PHP würde ich es dann lieber PHP nutzen.
@@VitalijMik Ich wollte PHP oder sonst einer Sprache auch nicht die daseins Berechtigung absprechen. Ich persönlich hatte halt in den letzten Jahren keine Berührungspunkte mehr zu PHP. Ich kann es auch vollkommen nachvollziehen, das man am liebsten für alles ein und die selbe Sprache nutz, die einem besonders liegt / gefällt. Finde es Großartig, dass du Spaß an PHP hast und ich stimme dir voll zu das keiner unnötigt Applikationen neuentwickeln wird, wenn die alten mehr als gut funktionieren und Geld bringen. Jedoch widerspreche ich der Ansicht, der Ansicht, dass man eine Sprache nicht nach Vorteilen/Nachteilen abwägen sollte. Data Science oder Machine Learning würde ich fast immer mit Python machen, da es hier die großen Frameworks gibt. Große Spiele würde ich mit C++ / C# wegen Unity oder Unreal verwenden. Treiber / Hardware nahe Sachen like Microkontroller (auch wenn es hier mitlerweile MicroPython oder JavaScript for Microcontrollers gibt) / Embeded System immer mit C / C++ aufgrund der performence / Speicher Vorteile nutzen. Nicht umsonst gibt es soviele unterschiedliche Sprachen. Ich finde es ja an sich interessant das viele Sprachen ihre Anwendungsgebiete verlassen, wie JavaScript mit NativeJS für Mobileapps oder mit Electron für Desktopapps. Ähnliches gilt für C# für Desktop (wohl noch mehr Windows) aber auch Webapps und mit Xamarin für Mobnileapps. Ich bin da ganz offen und nehme dann die, womit sich meine Idee am leichtesten umsetzen lässt und wenn ich dann halt 5 verschiedene nutze xD
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.
Die Wahlfreiheit Ist meiner Meinung nach kein Nachteil. Jede Option hat seine Berechtigung - und sei es Abwärtskompatibilität. Wann was verwendet werden sollte ist auch gut dokumentiert und man gewöhnt sich schnell dran. Ich finde, PHP hat noch eine vergleichsweise flache Lernkurve. Junge Sprachen wirken natürlich cleaner - aber auch diese Sprachen werden sich verändern ... Früher jemanden die Zeigerarithmetik in C beizubringen war auch eine gewisse Herausforderung. Generics: In PHP gibt es vermutlich bis jetzt keine Generics (wie stark typisierte Sprachen), da nicht dringend notwendig. Durch die schwache Typisierung bzw. Uniontypes ist diese Art der Funktions-Signatur seit PHP4 lauffähig umsetzbar (seit PHP8 strikter) - was fehlt, ist dass der Interpreter zur Laufzeit nicht prüfen kann, ob der Rückgabetyp zum Übergabeparametertyp passt. PHPStorm unterstützt mittlerweile Generics via PHPDoc Block
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
Im Großen und Ganzen hast du ja Recht, letztendlich ist ja gut dass sich die Sprache weiter entwickelt ich habe im Video ein Blog Artikel wiedergeben. Ich habe vor einigen Wochen als PHP8 Rauskam ein Stream gemacht, da habe ich die neuen Features gefeiert und ich habe auch ein Artikel zu PHP8 im PHP Magazin geschrieben, da habe ich auch noch mal gesagt dass ich mich über Neuerungen freue. Dennoch kann ich den Artikel nachvollziehen. Also Thema Lehrer. Leider funktioniert das nicht immer mit einfach Richtung vorgeben. Du musst schon ein sehr guter Lehrer sein und musst gute "Schüler" haben die deine Richtung sofort auch nachvollziehen können. In Programmiersprachen hat man das Schwierigkeiten, der Beste Programmierer kann auch nicht unbedingt der beste Lehrer sein und der beste Lehrer kann nicht der Beste Programmierer sein. Ich merke ja selbst dass ich einige im Discord Chat "an die Hand" nehmen muss und einiges nach erklären damit es verstanden wird. Switch und Match haben andere Verhaltensweisen, ja, aber es gibt durchaus sehr viele "typische" fälle wo man aktuell ein Switch case nutzt bei dem man einfach ein match einsetzen könnte und es würde an dem Verhalten des Codes bzw des Ergebnisses sich nichts ändern. Zum Thema Scopes, da geht es darum, wenn man zb "Funktionen" durchgehen würde, dann geht man auf normale Funktionen ein, dann lambda und dann muss man arrow Funktionen erklären und dann kommen schon die ersten Ausnahmen. Es gibt scopes, du hast Variablen außerhalb von Funktionen und Innerhalb ABER arrow Funktionen sind zwar auch Funktionen die funktionieren aber anders. Und Funktionen lernt man ja in der Regel vor dem OOP. Ich meine klar kann man das letztendlich erklären. Die Kernaussage des Artikels war (ich habe es vielleicht nicht richtig wiedergeben) PHP ist schon gut wie es ist, wir brauchen nicht wirklich noch mehr Code-Sugar, investiert doch lieber die Zeit in Features die es vorher nicht gab. Zum Beispiel Attribute die KEINE Kommentare sind, oder Generics oder einen Compiler oder FFI. Der aktuelle Match, den haben wir bisher mit preg_match oder if statements abgefangen. Es gibt "primitive" Schreibweisen die den Match komplett ersetzen könnten. Oder Nullsafe Operator, was ist daran so schlimm ein is_null zu schreiben? War die Zeit es wirklich wert in das Feature zu investieren? Oder Attribute im Konsturktor definieren. Wen du am Anfang OOP beschreibst, sagst du ja sowas wie "Eine Klasse hat eine Struktur, erst werden Eigenschaften definiert, dann kommen Methoden" und jetzt muss man diese Aussage erweitern mit "Es kann aber auch sein dass die Methoden erst über den Konstruktor definiert werden, deshalb müsst ihr erst nach __construct schauen". Es ist nur ein Satz aber der muss auch erst Mal richtig verstanden werden. Es ist einfacher wenn du Richtung strukturieren kannst mit so wenigen Ausnahmen wie es nur geht. Die Argumentation soll jetzt ja nicht die Sprache und neue Features irgendwie schlecht reden war nie die Absicht. Nur vielleicht sollte man sich nicht nur auf Code-Sugar konzentrieren.
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. :-)
oh ja DAS sind tatsächlich meiner Meinung nach die wichtigeren Features die noch fehlen. Method Overloading wäre ja total genial, und genereics da könnte man yield wunderbar typecasten so dass man aus einem Generator auch ein typ kriegen würde und nicht nur ein generator interface. Enums wären auch sehr gut vielleicht noch sogar STRUCT also Datenstrukturen
@@VitalijMik Definitiv! Gerade weil ich auch ein Framework erstelle wären solche Sachen , insbesondere Method overloading, sehr hilfreich. Hoffentlich kommen diese Features noch in künftigen Versionen, dann bräuchte sich PHP erst Recht nicht vor anderen Sprachen zu verstecken.
@@xDarkComedy naja ich weiß ja nicht wann es zu letzt probiert wurde;) Vielleicht nimmst du dir die Zeit und erstellst ein RFC? 2008 wurde das ja alles per Mail geregelt, die Zeiten waren anders :D
Da der Switch ein Grundkonstrukt der Sprache ist, wird es als Legacy-Code für immer Teil des Compilers bleiben. Wenn Du das raus nimmst, bricht alles zusammen!
@@rckd5903 match kann schon den switch ersetzen weil ja viel mehr kann, wegen dem strikten typecheck kann es aber schon zu unterschiedlichen Ergebnisse führen. Es kommt mit dem match halt ein weiterer Part in einem Anfänger Kurs dazu wo man dann den unterschied erklären muss. Wo sich dann der Anfänger komisch vorkommen könnte so nach dem Motto "Aber wieso verwende ich dann überhaupt switch wenn ich match nehmen kann?"
@@VitalijMik Nein, match kann bspw. nur einzeilige Ausdrücke und ist deutlich strikter (strikter Vergleich, UnhandledMatchError-Exception). switch und match sind nicht interchangeable.
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')
Hi Ja mir ist klar dass die Sprache sich weiter entwickeln muss. und weil ich weiß dass ich bis zur Rente mit PHP Arbeiten werde (finde die sprache toll) finde ich halt einige Dinge nicht so schön. Das mit Switch und match war zum Beispiel damals nicht so nach außen kommuniziert. Es gab damals beim Release die schöne php 8.0 Page wo es einfach gegenüber gestellt wurde mit "new" und "old". Das Video hier ist ja auch schon etwas älter. Ich treffe halt heute immer noch code mit alter array schweibweise, alte Properties ohne typehints usw und ich weiß ganz genau. Das ist ein alter Code. Und ehrlich gesagt finde ich neue schreibweisen für Dinge die wir bereits schon immer haben, nicht wirklich hilfreich für die Sprache. Ich wünschte halt dass die Zeit in neue Features invistiert worden wäre statt in andere Schreibweisen :D (Generics zb) Wir sind hier aber nicht bei wünsch dir was sondern isso :D
@@VitalijMik ich weiß, was du meinst. Die Kommunikation könnte wirklich ein wenig besser sein und auch wenn PHP mit einer der besseren Dokumentationen hat - in dem einen oder anderen Fall ist sie dann doch auch mal verwirrend und/oder unzureichend. Was das 'über Code im alten Stil geschrieben' - Ja, das passiert mir auch immer wieder. Ich weiß nicht, ob es ein allgemeines Problem vom Internet ist, welches nichts vergisst… und man daher viel zu oft über Leichen stolpert… oder ob das mit an der Community liegt, wo viele noch immer ohne Nachzudenken einfach Copy'n'Pasten… ich bin letztens auch über ein Beispiel gestolpert, wo jemand 5 Klassen in das Projekt eingebaut hat… und später die Klasse zwar instanziiert, dann aber nie verwendet hat (So weit ich mich erinnern kann, war das was mit PayPal Bezahlung). Aber ehrlich gesagt, hat ja nicht nur PHP das Problem… wenn ich sehe, wie viel zum Teil mit JS gemacht wird, was man aber besser direkt mit CSS umsetzen könnte… und das ist nur ein Beispiel. Bei Python gibt es auch immer wieder Verwirrung in dieser Richtung. Vielleicht echt ein universell(er)es Problem?
@@AmlorBluefog vielleicht mal anders. Ich habe PHP Projekte, die aus PHP 5.4 5.5 Zeiten entwickelt wurden. Als die neue Array schreibweise rauskam, bin ich den kompletten Code durchgegangen und alle Array stellen ersetzt. Später als wir return types in den Klassen Eigenschaften bekommen haben, bin ich wieder durch den kompletten Code durchgegangen und alles ersetzt. Das war sehr viel Aufwand. Ich kenne Projekte die das nicht gemacht haben und dann sitzt man im Team und überlegt, wie soll man da vorgehen. soll man alles durchgehen und verbessern? Soll man alten Code so lassen wie es ist? Soll man alten Code erst dann verändern wenn man gerade an der Stelle arbeitet? Will man einen Mix haben? Will man jedes Mal wenn was neues dazu, wieder alles umstellen? Ich bin gerade bei PHP 8.1 und stelle gerade meine eigenschaften auf constructor properties um mit readonly. das Problem ist. wenn ich es nicht mache, dann bleibt der alte code bestehen und man behandelt es dann wie Legacy Code und gibt sich nicht die Mühe wenn man an der Stelle arbeitet. jede Neue änderung die rein Syntaktisch ist, bringt aufwand mit sich vor allem in größeren Projekten. Dazu bringt es Verwirrung mit sich da man das gleiche auf mehrere Art und Weisen erreichen kann. Und das gefällt mir halt nicht. Natürlich ist es bestimmt auch ein generelles Problem in allen Programmiersprachen. Dennoch wollte ich sagen dass es mir nicht gefällt und ich finde, man sollte die Zeit besser in andere Features investieren als in neuen Syntax Sugar. Nur als Beispiel. Es gibt zb die Funktion spl_autoload von PHP, stell dir vor das würde PSR-4 unterstützen. Stell dir vor wir könnten Klassen autoloaden über C Code statt über PHP. Oder schau dir die readonly Klassen von PHP 8.2 an. Der komplette Release wurde jetzt auf mitte Dezember verschoben weil eine neue Syntax eingeführt wurde, weil jemand sich dachte, ich habe keine Lust vor allen meinen eigenschaften readonly zu schreiben. Enum war zum Beispiel ein Feature was ich total toll fand, davon halt bitte mehr :D Das ist meiner Meinung nach Fortschritt und nicht eine andere Schreibweise für etwas, was wir eh schon davor konnten. Es spielt keine Rolle ob ich nun "Servus","Moin" oder "Hallo" sage :D
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.
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.
Ja das stimmt, allerdings ist das mit dem Framework auch eine Sache. Ich habe bereits sehr viele Frameworks erlebt die zu dem aktuellen Zeitpunkt etwas tolles angeboten und dann durch eine Feature änderungen alles komplett umgestellt wurden. Und bei Frameworks ist es auch oft so dass man am Anfang denkt, die würden gute Standards umsetzen und nach einiger Zeit stellen die fest, man muss doch alles umstellen. Also wir hatten in der Vergangenheit oft die Frage ob Service Locator wirklich so ein gutes Pattern ist. Wurde später verworfen. Aktuell fragen sich viele ob DataMapper oder Active Record oder Repository design pattern besser ist. Das Framework bietet einfach alle möglichkeiten an und jeder kann dann entscheiden was mehr Sinn macht. Es ist halt nie direkt von anfang an klar was man nutzen sollte, schließlich ist die Informatik an sich erst ein sehr junges Berufsfeld und wir alle lernen eh gerade dazu :D Damals im Mittelalter als die Medizin gerade ausgebaut wurde, hat man sich auch gefragt mit welcher Bibel der Aderlass am erfolgreichsten ist :D
@@VitalijMik Klar ist nicht alles immer Tutti. Ich sehe auch das in vielen Firmen immer noch PHP 5 im Einsatz ist, da ist an neuen Features eh noch nicht zu denken. ;-) Solche Fragen sind aber auch meistens echt Luxus-Probleme. Entscheidend ist doch ob ein Framework einem dabei hilft ein Projekt schneller umzusetzen anstatt das man immer alles mit nativen Mitteln neu erfinden muss. Der Faktor Zeit sitzt halt neben dem Projekt Manager ständig im Nacken :-D
@@ProgrammierenMario WIe schnell man ein Projekt umsetzt ist halt auch relativ. Ich kann dir mit Laravel sehr schnell eine APplikation/Prototypen zusammenkleistern ohne Tests und an eine Build pipeline zu tun so dass Time To Market relativ kurz ist. Dann aber wenn das Projekt doch wächst und man ständig irgendwelche Fehler hat, kann man danach das Projekt verwerfen und neu und in besser schreiben. Ist halt auch die Frage. Ist die GEschwindigkeit wichtiger oder nachhaltigkeit. Auf der Anderen Seite, wenn man eh weiß dass man ein Online Shop eröffnen will nur um Corona Masken zu verkaufen da ist die Nachhaltigkeit egal, hauptsache man ist schnell online solange alles noch ein Thema ist.
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).
Naja, PHP ist in erster Linie eine Programmiersprache, die produktiv verwendet wird und marktfähig bleiben muss. Da ist es erst Mal egal, ob das dann gut für Einsteiger ist. Vor allem aber heißt "neue Features benutzen KÖNNEN" ja nicht, dass man es nutzen MUSS. Die Schreibweise der neuen Annotations finde ich aber tatsächlich auch ziemlich bescheuert... Das machen andere Sprachen wie TypeScript, Java, C# usw. viel besser.
Okay früher hatten wir array_push um einen weiteren Wert zum Array hinzuzufügen. Es wurde eine neue Schreibweise mit [] eingebaut, dann wurde eine neue Schreibweise für arrays gebaut mit $array = []; Was ist daraus passiert, ein array ist ein array geblieben, du hattest aber drei Schreibweisen, diese Tatsache bringt dich jetzt zu dem Punkt wo man innerhalb eines Teams eventuelle Streitigkeiten hat. Du hast mehrere Möglichkeiten. 1) Jeder der neu dazu zum Projekt kommt, darf nicht die neue Schreibweise verwenden, damit es überall gleich bleibt und du deinen Codestandard einhalten kannst 2) Du sagst dass Legacy code so bleiben soll wie es ist und neue Schreibweise in neuen Projekten eingebaut wird und somit hast du eine Mischform 3) Du überarbeitest alle deine Projekte auch alte Projekte in bringst den Code auf den gleichen Stand Die Sprache war auch vorher Marktfähig vor den Arrays und man konnte es vor den Arrays auch produktiv verwenden. Hingegen sind viele PHP Entwickler zu Go gewechselt weil du dort Asychnron und schneller den Code ausführen kannst. Das war eigentlich die Kernaussage des Videos, dass es durchaus einige Features gibt die nicht unbedingt hätten sein müssen weil wir da keine Probleme hatten. Ein Match hatten wir die ganzen Jahren über auch, Eigenschaften in einer Klasse definieren, das macht PHP Storm mit einer Tastenkombination. 3 Unterschiedliche Implementierungen der Annotations war eine Zeitverschwendung. Ich bin leidenschaftlicher PHP Entwickler und ich finde es ist die beste Sprache, dennoch sind einige Features eigentlich useless und die Zeit hätte in andere Features investiert werden können. Generics, Enums, Asynchrone Verarbeitung, Optimierte Arrays(richtige Arrays statt Hashmaps) diese Features würden die Sprache Marktfähig machen.
@@VitalijMik Ich verstehe deinen Standpunkt sehr gut. Ich glaube allerdings, dass das Hinzufügen von syntaktischem Zucker nicht das eigentliche Problem an PHP ist. Meiner Meinung nach ist das Grundproblem, dass sowohl die Sprache PHP als auch die Standard Library und mitgelieferte First-Party Extensions schon in sich, aber noch viel mehr untereinander ein einziges Durcheinander sind. Das fängt bei Parameter Reihenfolgen und unterschiedlichen Benamungsprinzipien (z. B. "strlen" vs "str_cmp") an hört bei Sprachkonstrukten auf, von denen manche expressions innerhalb der Klammern erlauben, während andere nur skalare Werte, Konstanten und Variablen beinhalten dürfen (z. B. empty() vs isset()). Dieses Durcheinander ist zwar historisch gewachsen, würde aber nie aufgeräumt und selbst neue Sprachfeatures oder stdlib erweiterungen werden oft ähnlich inkonsistent umgesetzt. Da ist leider Annotations in Kommentarschreibweise nur die Spitze des Eisbergs. Ich finde aber trotzdem, dass kürzere Schreibweisen für gewohnte Konstrukte die Produktivität sehr steigern können. 70% der Zeit verbringen Programmierer/-innen nicht mit dem Schreiben von neuem Code, sondern mit dem Lesen und Verstehen von bestehendem Code. In diesem Sinne sollte es Ziel eines jeden Programmierers und einer jeden Programmiersprache sein, den sogenannten "Signal to Noise Ratio" so gut wie möglich zu bekommen. Wenn ich also in einem Model nur Standard-Getter und -Setter verwende - wieso sollte ich dann hunderte Zeilen Code schreiben und vor allem lesen sollen, die komplett unaussagekräftig sind? Wieso sollte ich bei Funktionen, die nur eine einzige Anweisung enthalten, zwei bis drei Zeilen Boilerplate Code lesen und verstehen müssen, wenn ich alles kompakt mit einer Arrow-Function ausdrücken kann? Wieso sollte ich ein Annotation-Framework nutzen, wenn die Sprache selbst Mittel zur Verfügung stellt, die das Problem auf Parser-Ebene viel schneller und effizienter und vor allem mit besserer IDE-Integration lösen kann? Fortschritt ist nicht per se schlecht. Es ist in meinen Augen unsere Aufgabe als Mentoren, der neuen Generation an Programmieren diese Sprachfeatures sinnvoll in verständliche Häppchen zu verpacken, sodass sie eben nicht zu Verwirrung führen, sondern das Repertoire an Tools zum Lösen von Problemen zu bereichern. PHP sollte lediglich den Mut haben, alte Schreibweisen sukzessive als Deprecated zu markieren und Stück für Stück zu entfernen. Nikita Popov ist in dieser Hinsicht sehr progressiv - oft ist es die PHP-Community, die ihn in den RFCs überstimmt und dafür sorgt, dass veraltete Features und Schreibweisen noch über Versionen hinweg bestehen bleiben.
@@VitalijMik haha ich bin genauso enttäuscht wie du, dass wir jetzt static typing für Class members haben, aber immer noch keine Generics, Tupels, Enums oder zumindest ganz rudimentären Support für Array vom Typ X. Die einzige Aussage aus deinem Video, die ich selbst so nicht unterschreiben kann ist, dass die Features die wir bekommen sind "useless" sind. Aber das ist sicher Geschmackssache ^^. Ein Lichtblick: Enums zumindest sollen in PHP 8.1 endlich kommen 👍
@@VitalijMik Das Refactoring macht PHPStorm auch mit einem Klick. Du klingst für mich wie jemand, der gerne in seiner gewohnten Komfortzone bleiben will. Ich habe die Erfahrung gemacht, dass gerade junge Entwickler, die neu ins Team kommen, frustriert sind, wenn sie plötzlich wieder mit alten Konstrukten hantieren müssen...
if(){}else{} so habe ich es gelernt, so habe ich es verstanden und alles andere nervt mich persönlich. Einerseits ist es ja toll, wenn sich etwas weiterentwickelt und auch die Sicherheit verbessert wird, aber es ist schon sehr anstrengend ggf. mit jeder neuen PHP Version seine ganzen Programme anzupassen. Ich mache das nur aus Hobby, glaube die richtigen Entwickler bekommen ab und zu mehr graue Haare.
@@maiks.3684 Es bleibt aber immer noch so dass man immer mehr und mehr Möglichkeiten bekommt das gleiche Problem zu lösen und dann gibt es den alten und neuen Weg. Ist halt so. Kann man nicht ändern:D
Danke fürs Zuschauen, aber ich hoffe aus dem Video ist nicht herausgekommen dass ich PHP8 nicht mag. Das Video ist eine Übersetzung eines Russischen Blog Artikels und entspricht nur teilweise meiner Meinung
@@VitalijMik Da zeigt sich nur etwas Zwiegestaltenheit, dem ich mich voll und ganz anschließe - also zumindest dem Author des Blogs, da ich als Neuling beim lernen von PHP auf solche (wie im Video genannten Probleme) Probleme gegenüber stehe...
Das sind alles veritable Kritikpunkte, aber sie sind nicht php-spezifisch, sondern finden sich in eigentlich jeder Programmiersprache, die sich weiterentwickelt.
Joa das stimmt. Aber weil man ja mit der Sprache noch weitere Jahrzehnte verbringt darf man sich ja beschweren. Entwickler aus anderen Sprachen machen das ja auch. Man muss ja nicht hinter allem stehen was eingebaut wurde
Ich persönlich finde die short form von IF Statements nicht gut, bevorzuge lieber die normale Schreibweise. Leider kann ich nicht so ganz meine Meinung abgeben, da ich mit Laravel angefangen hatte. Ich weiß also nicht, wie sich Anfänger fühlen. Es ist eh allgemein schwierig sowas beizubringen.
Und ja beibringen ist echt schwer. Ich kriege hin und wieder Mails und Rückfragen wo ich dann im Nachhinein denke. Ich habe doch die Frage beantwortet. Noch einfacher kann man das nicht erklären
@@VitalijMik Ganz genau. Ich persönlich fand am schlimmsten SQL. Die Sache mit den ForeignKeys war echt schwer zu begreifen. Bzw, es gab einfach niemand, der es gut erklärt hat. Oder anders ausgerückt, der eine lernt schneller oder langsamer. Komplexe Datenbank Systeme, fand ich persönlich am schwersten zu verstehen, gerade ManyToMany ;)
Ich habe halt das Problem dass teilweise einige Grundinformationen fehlen. Also was ist HTTP. Dass da xampp auf deinem PC Installiert ist und dass es eigentlich ein Server ist. Ich bekam sehr oft die Frage wie man JavaScript variablen an PHP übergibt. Und wenn ich dann sage, "Eine weitere Anfrage an den Server schicken" dann gibt es viele verwirrte Fragen zurück. Ich glaube da gibts keine Prinzipielle lösung/antwort. Ich müsste mal mit einem SPrechen der Lehramt studiert hat, vielleicht wird ja sowas im Studium beigebracht.
@@VitalijMik Es gab eine Frau, welche sie intensiv damit beschäftigt hat, wie man Gehirngerecht lernt. Leider ist sie 2011 verstorben, aber es gibt noch viele Vorträge von ihr auf TH-cam. Einfach mal nach Vera Birkenbihl suchen. Die war echt mega. Sowas fehlt in Programmiersprachen. Jap, an deinem Beispiel wird es kompliziert. Der Schüler muss dann erstmal JSON verstehen, um einen API Request an PHP zu senden. Für Anfänger ist das alles zu viel.
Es entwickelt sich dahin das alle alten Scripte nicht gehen und man eine riesen Firma sein muß um alles am laufen zu halten. Die ganzen alten Scripte z.B. wie eines das fast wie Y*utube ist usw. gehen nicht mehr ! Je mehr Code man schreibt desto schwieriger wird es das am laufen zu halten, also am besten alles einfach machen.
Ich finde auch, man sollte drauf achten, dass der Code (gerade für Anfänger) lesbar und / oder logischer wird bzw. bleibt. Aber auch daran wurde teilweise ja gearbeitet. Ich sehe mich selber noch als Anfänger und finde die Funktion str_contains genial. Finde ich logisch und leichter lesbar als zum Beispiel strpos. Wie das mit strpos geht, muss ich jedes mal nachlesen. str_contains finde ich selbst erklärend. Und damit es nicht so viele Möglichkeiten gibt, sollten alte Varianten meiner Meinung auch gerne schneller mal rausfliegen.
Ich finde eher, man muss mit einer Sprache Probleme effizient lösen können. Und PHP einfach zu halten, nur damit Anfänger damit besser klar kommen, ist der falsche Ansatz. Du musst doch viele Dinge im Leben lernen, die anfangs schwierig sind. Wenn Du Autofahren willst, wäre es natürlich am Anfang einfach, nur ein Gaspedal und sonst nichts zu haben. Aber letzten Endes ist man doch froh, dass man auch Bremsen, ein Lenkrad, Klimaanlage etc. hat, oder?
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^^
ich weiß halt manchmal nicht ob es wirklich versüßt wird oder nicht;) wirst du in Zukunft Match benutzen? oder Eigenschaften einer Klasse direkt über Constructor definieren?
@@vonBlankenburgLP fetch('example.com/movies.json') .then(response => response.json()) //was soll diese Zeile? nimm response und überschreibe es mit dem ergebnis aus response.json? .then(data => console.log(data)); vielleicht ist es alles eine Gewohnheitssache, aber es ist schon krass dass eine kleine Zeichenabfolge eigentlich ein Funktionsaufruf mit sich bringt.
@@VitalijMik Das ist eine synchrone Niederschrift eines asynchronen Methodenaufrufs. Da die Methode fetch nicht blockierend arbeitet, musst Du ihr einen Funktionshandler übergeben. Dies könnte eine eigene Funktion sein, die da heißt function handleFetch(response) { return response.json(); }. Die Kurzschreibweise davon als Lambda ist eben response => response.json(). Diese Methode gibt offensichtlich wieder einen asynchronen Task zurück, der dann in die Konsole schreibt. Ich löse das in Javascript mittlerweile über asynchrone Funktionen, die viel besser lesbar sind: async function fetchAndLog(url) { const fetchResult = await fetch(url); const json = await fetchResult.json(); console.log(json); } Oder als Harakiri-Version: const fetchAndLog = async url => (console.log(await (await fetch(url)).json())); //Test fetchAndLog('jsonplaceholder.typicode.com/todos/1')
@@vonBlankenburgLP das muss man mir nicht erklären, es geht ja nur darum dass es so stark verkürzt wurde dass es in eine Zeile passt. Man hat das Gefühl dass die Entwickler es gerne kurz alles in einer Zeile haben, schön nach dem Regex Prinzip. Schau dir den Pipeline Operator an. ist so ein anderer Beispiel.
Zu dem Punkt wegen des Herausziehen des Compilers zum Erzeugen ausführbarer Binaries und Desktop-Applikationen in PHP: Das hat eigentlich recht wenig miteinander zu tun. 1) Desktop-Applikationen mit PHP sind bereits jetzt möglich - siehe PHP-GTK. Muss aber deswegen nicht compiliert werden. Native Desktop-Apps sind generell ein eigenes Thema, nicht nur in PHP, weil halt jede Plattform eigene APIs für die UI-Programmierung bereitstellt. GTK funktioniert zwar so gut wie überall, ist aber auch nur unter Linux u. *BSD so wirklich "native", nicht aber z.B. unter Windows oder macOS. 2) Eine PHP-Applikation zu compilieren und dann Binär zu deployen hört sich erstmal sehr attraktiv an, auch für Web-Apps. Ich denke aber nicht, dass jemand damit unbedingt native Binaries/Executables (z.B. ELF-Binary unter Linux oder EXE unter Windows) erzeugen möchte. Eine Alternative ist ein Intermediate Bytecode-Format, wie etwa bei Java, .NET oder auch WebAssembly, das dann von einem Interpreter oder einer Virtual Machine (z.B. Java's JVM, .NET's CLR) ausgeführt wird. Und (fast) genau so etwas ist der PHP OPcache. Der Unterschied zu anderen Sprachen ist nur, dass man nicht vorher compilieren muss und dann das Erzeugnis des Compilers deployed, sondern der Compiler läuft automatisch bei der ersten Ausführung des PHP-Codes. Das kann man durchaus als Vorteil von PHP sehen. Wenn du gerne einen "Compiler" hättest, um schon vor der Ausführung deiner PHP-Scripts Type Safety zu garantieren oder Syntaxfehler zu finden usw., dann verwende ein statisches Code-Analyse-Tool wie z.B. Psalm - psalm.dev
Mir ist das alles natürlich klar. Ich kenne sowohl PHP-GTK und ich weiß was ein Compiler ist und was Psalm ist usw. Und BTW PHP-GTK ist eine PHP5 Applikation dessen Entwicklung eingestellt wurde, es gibt zwar alternativen aber da sieht es für mich einfach nur so aus dass einige PHP Entwickler einfach nur gerne eine Native Applikation mit der Syntax von PHP Schreiben. Psalm hat auch seine Schwächen, dieser kann zwar Typesierung usw prüfen bei einem Compiler hast du auch noch den Linker der auch überprüfen kann ob alles notwendige richtig verlinkt wurde. ich wollte nur grob sagen dass es andere interessantere Features gibt auf die man sich eher Konzentrieren sollen. Ich fand es schade dass erst jetzt in PHP 8.1 Enums und Generics kommen und wo bleiben eigentlich getter und setter? Kern meiner Aussage war ja, ein match brauchen wir nicht weil wir schon vor PHP 8 mit einem preg_match alles prüfen konnten, jetzt ist es hübscher. Oder Properties direkt über construktor definieren, du hast PHP Storm, ALT+ Enter und schon ist alles generiert, eine extra Syntax dafür ist nice to have aber nicht essentiell. Compiler war halt nur ein Beispiel, ich wollte mich da auch nicht zu sehr aufhängen.
@@VitalijMik Ok, dann habe ich es für die Community nochmal erklärt ;) Ja, der Haupt-Fokus von PHP lag immer und liegt auch heute noch auf Web-Apps. Und da ist PHP nun seit über 20 Jahren eine der am weitesten verbreiteten Technologien überhaupt, das muss man erstmal schaffen ;) Alles andere waren halt immer nur kleinere Projekte, die sich nie wirklich durchsetzen konnten, weil ganz einfach zu wenig Interesse seitens der PHP Community bestand. Für z.B. Desktop-Apps gibt es ja auch reichlich "geeignetere" Tools. Ich habe die Kernaussage in deinem Video natürlich auch verstanden. Das ist natürlich schon eine interessante Perspektive. Ich habe mich das selbst auch schon öfter gefragt, wieviel mehr PHP-Anfänger heute lernen müssen, als ich früher :) Aber es ist nunmal so, dass sich Programmiersprachen weiterentwickeln und neue Syntax-Konstrukte durchaus sinnvoll sind - man hat es halt nur vor 15 oder 20 Jahren nicht besser gewusst. Das gilt bei weitem nicht nur für PHP, du hast ja schon JavaScript im Video erwähnt, aber auch z.B. bei Java oder in den letzten Jahren vorallem bei C++ hat sich da sehr viel getan. Ich persönlich möchte auf viele (in diesen Sprachen) relativ neue Features, wie etwa Lambdas/Arrow-Functions, heute nicht mehr verzichten! Und ja, Enums, Generics, sowie auch die mittlerweile existierenden Namespaces und Type Hints hätte ich eigentlich schon gerne in PHP 5.0 gehabt :D Mein Vorschlag: Wer heute PHP lernen möchte, sollte sich eher auf die "modernere" Art, PHP Code zu schreiben, fokusieren. Viele "alte" Konstrukte gelten heute als überholt, weil man es heute einfach besser weiß. Mir fallen da gerade nur ein paar JavaScript Bsp. ein: Irreführender Scope von mit "var" deklarierten Variablen (Stichwort: Hoisting). Oder die Frage, worauf referenziert "this" in dem Kontext gerade? :) Klar, es gibt natürlich sehr viele über die Jahre gewachsene Code-Basen, die noch "alten" PHP Code enthalten und deswegen kann man das ja auch nicht von heute auf morgen aus der Sprache PHP entfernen. Wenn man mit so einer alten Codebase zu tun hat, kommt man eh nicht drum herum, den Code zumindest lesen zu lernen. Man sollte aber IMHO neuen Code immer versuchen im modernen Stil zu schreiben... und vielleicht dabei auch mal ein Stück alten Code refactoren ;)
@@rstangl ich arbeite aktuell viel mit Shopware 6 und da merke ich gerade dass Programmierung immer unwichtiger wird. Vieles ist bereits Programmiert, alles was du als Entwickler machen musst, ist die Konfiguration richtig anzupassen und eventuell hier oder da ein paar Klassen Dekorieren/Überschreiben. Vielleicht wird das die Moderne Programmierung sein, man nimmt das was da ist und COnfiguriert es so wie es der Kunde haben will. Veilleicht eine hübsche Verpackung im Form von Templates drauf und schon ist alles schön :D
Die fortschreitende Entwicklung unter Aspekt „aus der Sicht eines Lehrers“ zu betrachten, halte ich eher für akademischer Natur. Wie bei anderen Programmiersprachen liegt PHP inzwischen in vielen verschiedenen Versionen vor. Jedes Jahr erscheinen neue Versionen, die Verbesserungen und Funktionserweiterungen mitbringen - ca. alle drei Jahre gibt es ein neues Major-Release. In der Regel unterstützen Webhoster aktuell nur noch PHP-Versionen ab 7.xx. Viele Hoster haben in letzter Zeit die Unterstützung für PHP 5.6 abgeschaltet bzw. haben es entsprechend angekündigt. Für Versionen >int
Die neue Syntax-Notation wird man spätestens dann nutzen wenn das Team beschließt dieses in die Coding Standards aufzunehmen. Hier wird es eh in der Umstellung dann ein Mix von beiden Varianten geben. Man kann nicht von einem Tag auf den anderen komplette Projekte umschreiben. So wird man dann zwei Stellen im Code haben und man muss wissen. Okay das ist alte Schreibweise, und das ist die neue Schreibweise. Die Junior Developer haben heut zu Tage eh gefühlt schwieriger als wir es damals vor 15 Jahren hatten. Die müssen heute wissen was ein Docker Container ist was CSS Preprozessoren/CSS Frameworks sind, was Typescript ist dazu natürlich sich mit Frameworks beschäftigen und dann auch noch verschiedene Nuancen sowohl von PHP als auch JS kennen. Wenn man nach und nach mit der Sprache wächst ist es überschaubar, fängt man aber da neu an, kann es durchaus passieren dass man da nicht zu Recht kommt. Wenn sich niemand mehr Gedanken über neue Entwickler macht, haben wir bald keine.
@@VitalijMik Von Brian Goetz (Oracle) stammt die Aussage: „Languages must evolve, or they risk becoming irrelevant“. Das gilt sicherlich auch für PHP. Insofern ist die Bereitstellung neuer Features in Sachen Performance und Funktionalität mit jeder neunen PHP-Version doch eher ein normaler Umstand. Als Entwickler ist man es ohnehin gewohnt, ständig Neues lernen zu müssen. Ganz ehrlich? Deine Argumente „aus der Sicht des Lehrers“ kann ich nicht nachvollziehen. Denke daran: Wir sprechen vom IT-Umfeld! Allein 0 und 1 haben bisher nichts an Beständigkeit verloren … bis diese Entitäten durch QBITS ersetzt werden.
@@o.lewandowski7872 ich spreche nicht bei Features wo es um was neues geht. Oder Performance sondern um Features die das selbe tun was vorher schon ging nur anders..
Ich muss echt an meiner Kommunikation arbeiten, ich habe in keinem einzigen Satz gesagt dass ich dagegen bin dass PHP sich weiter entwickelt. Ich sagte dass man Statt den Syntax Sugar doch sich lieber auf die Weiterentwicklung der Sprache konzentrieren muss. Beispiel 1 : Short array Variante. Seit dem wir die haben gibt es in fast jedem Projekt ein Mix zwischen kurzer und langer schreibweise. Performance Gewinn = 0 dafür muss man erklären, damals haben wir das so gemacht jetzt ist es so. Beispiel 2: Haufen Alias Funktionen die je nach dem Ob der Entwickler aus einer anderen Programmiersprache kommt dann auch anders die dinge schreibt, zum Beispiel join() vs implode() wieder hat nichts mit performance zu tun sondern einfach nur syntax sugar. Oder list() vs [$a,$b,$c]. die() vs exit. sizeof vs count Das sind Beispiele aus echten Langlebigen Projekten jezt PHP 8. Constructor Property Promotion, du wirst noch in Zukunft Klassen finden die entweder schön wie im Lehrbuch erst Properties haben dann Methoden oder eben mal gibt es eine Klasse die gar keine Properties definiert hat sondern erst über den Constructor. Du wirst Klassen sehen die davon ableiten die dann gar keine Properties haben und im Code wird sich darauf bezogen werden. Das ist ein Code Sugar der Verwirrend ist. Nullsafe Operator. Im Clean Code Buch von Robert Martin wird auch gesagt, nutzt lieber nicht Null oder Statuscode, nutzt exceptions. Wir haben jetzt schon voller code wo es manchmal gemix wird mit dem null coalesting operator und mal mit isset. jetzt werden wir weiterhin code haben wo manchmal auf null geprüft wird und manchmal die short variante genommen wird. Syntax Sugar bringt Inkonsistenz im Code. Neue Fatures die vorher nicht da waren und jetzt wir brauchen begrüße ich NATÜRLICH. Ich freue mich riesig über Enums, Bessere Fehlermeldungen, Safe String Vergleich usw. Aber einige Features die nichts zur Performance beitragen sondern einfach nur eine andere Schreibweise ist, empfinde ich als verwirrend für Anfänger und eventuell wird es uns auf den Kopf fallen. Die erwähnten Features haben ja auch Entwicklungszeit gekostet und es ist ja nicht so als ob wir unendlich Code PHP Developer haben. Hätte man den gesagt "Aber ENUMs sind wichtiger" hätten wir enums schon in php 8 gehabt, RFC war ja schon da.
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.
Oder halt Tools. Zum Beispiel als damals die neue Syntax für PHP Arrays eingeführt wurde, mussten wir uns hinsetzen und kompletten Code überarbeiten und alle Arrays durch die neue Syntax ersetzen und davor war das gleiche mit array_push. Ich meine es war jetzt nicht soo ein großer Aufwand, man musste aber eben die Zeit aufbringen. Mittlerweile gibt es aber immer mehr und mehr Tools die einem dabei unterstützen.
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.
Dankeschön, ja nur weil es geht muss man es nicht nutzen. Ich komme aber aus der Zeit in PHP wo immer wieder neue Dinge dazu gekommen sind, die vorhandene Projekte schlechter gemacht haben. Neue Features heißt immer wieder, entweder nutzt man die überall oder gar nicht. Ein Mix davon macht den kompletten code unschön. Wir hatten zum Beispiel die neue schreibweise für arrays. In einem Projekt wurde es nicht festgelegt und man konnte beides nutzen. Dann hattest du Klassen gehabt die "veraltet" waren, die niemand vorher angefasst hat und dann hattest du neue klassen wo arrays in moderner form geschrieben waren. Der Code war inkonsistent. Dann hatten wir ein Projekt wo wir alle arrays umgeschrieben haben um eine gleiche Basis zu bekommen. Das war halt sehr viel Arbeit in den Projekten alles rauszusuchen und zu fixen. Seit PHP 8 sitzen wir zb auch noch an den named parameters und entfernen die ganzen nullern bei den argumenten. Du hast halt die Wahl, lasse ich mein Code so wie es ist und arbeite ab jetzt mit neuen features oder ich stelle alles um. Das erste führt dazu dass Entwickler den Code dann stiefmütterlich behandeln weil es ja "alter code ist". Der Alte Code läuft aber noch und braucht halt auch aufmerksamkeit. Oder du stellst alles um was sehr viel Aufwand bringt, aber keinen wirklich mehrwert außer eventuell lesbarkeit. Ich merke halt in den neuen Projekten jetzt auch, einige Entwickler nutzen immer noch ganz normal properties und setzen diese über konsturktor, einige entwickler nutzen das neue feature, das wiederum führt immer wieder zu diskussionen innerhalb des teams. Einige Entwickler wollen sich nicht umstellen, einige wollen nur den neuesten Code nutzen. Andere Schreibweisen für Dinge, die die Sprache eh schon konnte führt immer wieder zu Problemen die ausdiskutiert werden müssen oder man nacharbeiten muss. Aber so ist es halt. Da ich halt täglich damit arbeite, wollte ich in dem Video einfach meinen Frust rauslassen ;) Neue Dinge sind nicht immer per se total geil.
@@VitalijMik Oh ja, ich weiß genau was du meinst, das hab ich aktuell auch ein bisschen. Bei uns im Team ist inzwischen die Devise, wir gehen nicht los und stellen alles im, wie du schon sagst, viel zu viel Aufwand. Aber: in jeder Datei, die wir eh anfassen - Bugfixes, neue Feature etc - schauen wir uns die ganze Datei an und ziehen alle gerade, was wir entdecken. Tabs to spaces, Klammern auf neuen Zeilen, Leerzeichen hinterm if, alles sowas, und eben auch Typisierung, Default-Parameter und so weiter. Über die Zeit wird dann der ganze Code nach und nach neuer, und durchläuft quasi eine langsame Mutation. Das einzige, was wir wirklich auf einmal im ganzen Projekt geändert haben, waren Arrays. Da haben wir ein bisschen Zeit in ein Cleveres Regex investiert, und dann mit Search and Replace alle auf einmal geändert. Gründliches review, und Deckel drauf 😄 Mit den Tests machen wir es zum Beispiel ähnlich. Losgehen und für alles einen Test schreiben wo einer fehlt ist absolut nicht machbar. Aber alles was wir anfassen wird überprüft, ob es einen Test hat. Hat es keinen, werden welche geschrieben. Das sind mal eine Handvoll pro Branch, das ist machbar. So haben wir unsere Coverage von unter 3 (!) inzwischen auf über 50 Prozent gesteigert. Aber dafür braucht es eben ein Team, was willens ist sich auf neue Sachen einzulassen. Wir diskutieren sowas immer in der Retro und kommen gemeinsam zu einer Entscheidung, das hilft. Dann wird jeder gehört und niemand übergangen, und alle haben die Chance ihre Motivation und ihre Bedenken zu äußern.
"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.
Wobei man unterscheiden muss. Ich sagte neue Syntax für dinge einbauen die kein Problem sind. In 8.1 kommt zum Beispiel die neue Syntax für ein Enum, das ist zum Beispiel richtig geil und so etwas begrüße ich sehr.
@@VitalijMik ich glaube das liegt aber an unserem Zeitgeist. Getreu dem Motto: es ist möglich also machen wir das so. Sehe ich in vielen Lebensbereichen, dass Dinge verkompliziert werden. Aber wie du schon sagtest es wurde dir ja nichts (fast nichts) genommen, sondern nur zusätzlich Möglichkeiten gegeben.
@@8zeti711 naja schau mal. Ein Entwickler hat jetzt mehrere Stunden am match case gearbeitet. Es hätte auch an generics arbeiten können. Dann wurde jetzt mehr Code in PHP src eingebaut über lange Zeit muss es auch gepflegt werden. Dann gibt es ein weiteres Feature um das selbe Problem zu lösen, das heißt in größeren Projekten wird man entweder darauf verzichten oder ein misch zulassen. Beim Mischen sieht der code nicht einheitlich aus. Wir haben zb immer noch alte Projekte mit Array vs [] und solche dinge erlauben wieder zu blog Beiträgen wieso PHP schlecht ist. Bei Features wie fibers sag ich nichts die waren super. Auch readonoly usw ich stehe halt nicht hinter jeder Neuerung weil ich damit weitere 10 mindestens noch arbeiten muss:D
Das sagst du halt nur weil du ein reiner Anwender bist und nicht dinge erklären musst. Immer wieder kommen hier kommentare weil die Entwickler viel zu kurzsichtig sind und nur auf ihre eigene Situation das beziehen. Natürlich weiß ich dass constructor proeperies im di context abused werden. Ich muss aber jedes mal erklären dass man das entweder so oder auch anders beschreibt. Es gibt nicht nur PHP anwender.
Außerdem ich habe das wieder gegeben was im Blog stand das habe ich im Video gesagt. Ich bin nicht der Autor des Blogs. Ich habe nur den Text wiedergegeben weil ich es interessant fand
stimmt, wobei ich nie Probleme mit PHP an sich hatte wegen der Performance. Meistens hatte ich eher Probleme mit falschen DB index, oder zu viele API Requests über HTTP oder Filestorage also immer wenn man auf externe Systeme zugegriffen hat, musste PHP auf antwort warten und deshalb war alles langsamer
@@I_am_Raziel ich weiß, auch 8 ist super, enums sind geil. Aber es ist schon komisch zu sehen dass in einem Constructor Eigenscahften gesetzt sind, die nicht vorher definiert sind in der KLasse. Dass die Magisch da einfach drinne sind. sind wir echt schon soweit gekommen dass wir einfach die privaten eigenscahften nicht mehr definieren wollen? :D
@@I_am_Raziel oder der nullsafe operator, der wird in einigenn Projekten zu Fehler führen. Früher musste man jeden if statement ausschreiben, dadurch konnte man deutlich sehen in der code coverage, welcher part von tests abgedeckt ist. Jetzt werden alle if statements weggekürzt und man weiß nicht mehr ob der code mit den tests abgedeckt ist. Ich bin nicht gegen PHP oder so aber GERADE weil ich jeden Tag damit arbeite, darf ich ja auf einige dinge aufmerksam machen.
Der Zucker hat in JavaScript einen ganz anderen Hintergrund, bezüglich der Tatsache, das der Browser den Code verarbeitet und bei großen und vielen Scripten, dann doch viel Gewicht eingespart wird. Macht jetzt in PHP nicht so viel Sinn - aber : Für JavaScript - Entwickler ist die neue Syntax natürlich ganz nett. Man darf ja auch nicht vergessen, das PHP serverseitig einen ernstzunehmenden Konkurrenten mit JavaScript hat. Also ich finde es nett, muss aber nicht sein - dennoch werde ich es nutzen, da ich es in JavaScript gewohnt bin 😜. Ach und nen Compiler zur Realisierung für Desktopanwendungen - ein Traum 😍 - frag mal die ganzen Desktop - Offline / Online - Anwendungen. Ich meine ich habe in JavaScript die Möglichkeit meine App als „Desktop - Anwendung“ bereitzustellen. Allerdings ist das ein Thema was PHP schon längst hätte angehen können. Aber vielleicht kommt es ja als nächstes großes Ding.
Wobei man JavaScript mit PHP nicht einfach vergleichen kann. Auch wenn NodeJS mindestens das kann was auch PHP kann und noch viel mehr, ist die Arbeitsweise und Herangehensweise doch komplett anders. Stichwort Callback hell, ein PHP Entwickler kennt das zb nicht. Oder "Metasprachen" wie Typescript. Also man muss es kennen und verstehen, einfach so zu sagen "Ich steig mal um auf NodeJS" ist ja nicht. :D
@@VitalijMik absolut 😌. Die Möglichkeiten welche mit Node.js geschaffen wurden, haben ja tatsächlich auch erstmal nichts mit der Sprache JavaScript im Browser zu tuen, aber es wurde übernommen. Ich meine spätestens wenn wir bei 6G sind, brauche ich mir doch echt keine Gedanken mehr machen, bzgl dynamisch auf dem Server oder statisch, oder komplett dynamisch beim Clienten. Ich meine das muss ich eigentlich noch nichtmal mit 4G. Im Großen und Ganzen kann ich den ganzen Content mit JS importieren und sämtliches funktionelles für den Clienten auch. Dann bleibt für PHP nur noch das reine Backend - Datenbanken, Files, Sockets usw... Was die Performance für den DOM - Contentload angeht, sehe ich da keine Unterschiede mehr, außer mein PHP - Backend ist komplett mit Generatoren aufgebaut, dann ja.
@@svenskanda wobei man auch dazu sagen muss, mit ein paar Tricks könnte man mit PHP die gleichen Ergebnisse erzielen wie mit NodeJS ;) Spoiler sitze da gerade an ein paar Experimenten ;)
@@VitalijMik ich freue mich und werde das mal von dir Verfolgen - denn tief in meinen Herzen liebe ich PHP und wäre schon traurig nur noch mit JS zu arbeiten. Nicht nach all der Zeit und nicht nach all den Kopfschmerzen, die mir massige Anreihungen von Generatoren gebracht haben. Ich meine yield war schon ein Traum und jetzt freue ich mich auf den JIT.
Vielen Dank, falls jemand das Sieht, schaut unbedingt auf dem Kanal von Maximilian vorbei, ihr werdet nach seinen Videos sicherlich lachen, das verspreche ich euch :D
@@VitalijMik Naja in PHP sind Funktionen ja keine Variablen wie in den meisten anderen Sprachen. Im Screenshot sieht man ja auch, dass die Funktionen nur als String übergeben werden und nicht als Objekt selbst.
Eine Funktion ist eine Funktion, ein Objekt ist ein Objekt. In PHP kannst du anonyme Funktionen als variablen abspeichern und diese weitergeben. Das nennt sich in jeder Sprache lambda. Auch arrow finctions gibt es in PHP in den neuesten Versionen. Dass eine Funktion als objects daherkommt ist eigentlich eine sonderheit von Javascript.
Ich finde PHP einfach schrecklich. Habe einige Zeit in einer Firma damit gearbeitet und es fühlt sich alles so unelegant und willkürlich an. So eine schlechte Erfahrung mit einer Programmiersprache habe ich bisher neben PHP nur mit R gemacht.
Es ist halt alles Ansichtssache. Kann sein dass du alten PHP Code vor dir hattest. Ich arbeite seit über 10 Jahren damit und finde die Sprache toll. Ich habe drei Jahre intensiv c++ genutzt und wegen PHP auch viel mit js und typescript zu tun. Im Vergleich zu diesen Sprachen ist PHP doch viel verständlicher. Was genau hat dich denn gestört?
@@VitalijMik Mich stört vor allem, wie man Components definiert im Vergelich zu z.B. React. Wie man die Datentypen definiert, die ein Component als Input kriegen soll. Einfach nicht schön gemacht in PHP. Führt meiner Meinung nach zu unsauberem Arbeiten. Oder wie man Components z.B. in Flutter erstellt, ist viel sauberer.
Verstehe ich nicht. Du erstellt in PHP einfach eine Klasse. Genauso wie es in c# oder java der Fall ist. Danach kannst du die Klasse als typehint definieren. PHP basiert auf C und daher kommt viel aus der c syntax famlie.
@@VitalijMik Aber Klasse und Html Template sind nicht so eng miteinander vorwoben. Vielleicht habe ich mit einem unmodernen Framework gearbeitet. Und mit Sicherheit kenne ich mich weniger aus als du in dem Gebiet.
@@SEOTADEO will sagen in PHP wird eine Klasse genauso wie die componente in react und fluttr. Die Syntax ist nur anders aber es ist 1 zu 1 das gleiche. Ich vermute echt dass du auf der Arbeit irgendwie ganz komisch Erweiterung in den code einbauen musstest und das kommt oft vor , dass in den Firmen dinge gebaut werden die über Jahre gewachsen sind. Man muss da wirklich genauer hinschauen ob es wirklich was mit PHP zu tun hat oder der vorhandenene code der bereits was komsiches hat
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?
Ein compiler währe schon nice, weil die scripte in der Theorie dann schneller ausgeführt werden können.
@@yannickw_ der Compiler ist ja bereits eingebaut und es ist ja nicht nur eine Theorie, Hack von Facebook hat es ja auch bereits eingebaut. Die Scripte werden schneller ausgeführt, allerdings hast du dann weitere Problematiken, denn dann musst du deinen Code speziell aufbauen damit du nur Teile kompilierst. In C#/Java gibt es durchaus Programme wo man dann mehrere Stunden eine Applikation kompilliert ;) Will sagen, es bringt nicht nur Vorteile mit sich. Aber eben Optionen.
@@yannickw_ Aber wo ist denn das wirklich relevant? Das Problem bei PHP ist doch eher, dass jeder Request ein eigener Prozess ist. Und die Kommunikation mit der DB und externen Quellen schlägt sich viel eher nieder. Wenn man halt wirklich auf Biegen und Brechen Performance auf Applikationsebene braucht, warum nimmt man dann nicht z. B. Go? Unglaublich performant, niedriger Speicherverbrauch, Nebenläufigkeit, ...
Auf der einen Seite möchtet ihr nicht, dass PHP featureseitig weiterentwickelt werden soll, auf der anderen soll es aber alle möglichen Bereiche abdecken. Warum Offline-Applikationen? Dafür ist es halt nicht gemacht.
@Karl Koslowski naja offline applikationen möchte man machen weil man andere Programmiersprachen nicht so toll findet. Es gab ja in der Vergangenheit beriets mehrere Projekte, zum Beispiel PHP GTK, damit konnte man schon mit PHP, GTK ansteuern und fenster Befehle ausführen so wie python es auch aktuell macht. Problem bei PHP ist dass der code nicht kompelliert wird und man kann somit nicht eine Datei einfach weitergeben und niemand hat dann den Zugriff auf deinen Code. Ich kann mir schon vorstellen, einige Tools mit PHP umzustezen die Offline oder zumindest mit einer SQLIte DB Laufen
@@VitalijMik Aber vielleicht sollte man lieber eine Sprache nehmen, die dafür geeginet ist, und nicht auf Krampf PHP, nur weil man das irgendwie auch machen könnte.
hmm und was für eine Version nimmt man jetzt? welche empfehlung?
Neuste? 8.2
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.
Ich weiß nicht, mein Code war auch ohne den Arrow Functions sehr übersichtlich, einfach Early return und du hast oft nur zwei zeiler im Code.
Wegen Methode overloading, das wäre tatsächlich ein interessantes neues Feature, das würde übrigens in PHP schon zu PHP 5 Zeiten vorgeschlagen und es wurde dann auch abgelehnt. In PHP ist es nicht einfach umzustezen weil du dynamische Typen hast. Swift konnte das einfach umsetzen weil die keine "altlasten" hat oder zuminstens nicht so viele wie PHP. Also klar bei einfachen beispielen wie bei dir mit string vs array ist es vielleicht noch einfach. Aber was ist mit Person[] vs User[] beides arrays nur mit verschiedenen objekten drin und man möchte eventuell da anders vorgehen. Da ist es schwierig für PHP performant zu unterscheiden welche Methode aufgerufen wird.
Auch das lesen des Codes wird schwieriger, du musst ja wissen welchen Typ deine variable gerade hat damit du weiß welche Methode gerade aufgerufen wird. Durch das Method overloading kannst du nicht mal eben vi anschmeißen auf dem Live Server und dir den code anschauen, musst dann debuggen.
TL;DR
Prinzipiell ein nettes feature, kann zu problemen führen, wird vermutlich nie in PHP kommen auf grund von schwacher typisierung und altlasten diesbezüglich
@@VitalijMik Hi Vitalij, vielen dank für deine Antwort. Dann muss ich mich wohl von diesen Traum verabschieden :). Zwecks der Arrow-Funktion, vielleicht liegt es daran, dass ich seit meinen Anfängen auch stets mit JavaScript (dann auch TypeScript) zu tun habe.
Aber diesen Code finde einfach praktischer und auch leserlicher:
$oneAdded = array_map(($i) => $i+1, [1,2,3]);
als diesen hier:
$oneAdded = array_map(function($i) {
return $i+1;
}, [1,2,3]);
Aber wie gesagt, ich bin diese Syntax gewöhnt. In Swift und einigen anderen Sprachen gibt es auch diese Abkürzungen für Closures und sehen noch ulkiger aus. Viele Grüße!
@@GGGGGGGGGG96 das Problem was an der Arrow funktion war, dass die Funktion anders ist als die normalen funktionen. In Javascript ist es nicht so.
In PHP Hast du variablen nur im Function scope und du musst die von außen via use oder global hineinziehen. In JS hattest du immer alle variablen die draußen waren auch drinn gehabt deshalb gibt es this und that.
Die Arrow Function wurde in PHP inkosistent umgesetzt, wir haben schon genug inkonsistente features in PHP (haystack needle problem zb) und jetzt haben wir ein weiteres.
Wieso kann man in arrow function einfach so variablen von außen benutzen? sowas hat es nie in PHP gegeben.
@@VitalijMik Die (Fat-)Arrow Funktion funktioniert mMn identisch wie in JS:
- kein Scope / identisch zu "static function" (spart Speicher / erspart umständliches importieren via "use()"),
- das letzte Statement wird zurückgegeben (auch ohne explizit return angeben zu müssen)
kleiner Unterschied: in JS brauch es kein "fn" und bei nur einem Argument auch keine Klammern.
Ich verwende diese Ausdrucksform häufig für kurze, knackige Callbacks, z.B. Formatter, Renderer, Transformer, Mapper usw. - aber nicht generell für alle Lambdas. Nur wenn es die Lesbarkeit für mich und den Reviewer erhöht - nicht aus Faulheit oder Platzmangel ;) . In passenden Fällen (und nur dort sollte man den Shortsyntax einsetzen) ist plötzlich so viel weniger "Rauschen" da und Schreiben/Lesen macht einfach mehr Spaß.
Ich finde auch die Deklaration von Settern/Gettern in C# oder TypeScript viel eleganter ausgedrückt und wartbarer als die meist wertlosen aber "sicherheitshalber schon mal generierten" PHP/Java Setter/Getter getABC(), setABC() - speziell in Entity- und DTO Klassen.
Hallo Vitalij, kurze Frage 😀 wenn du eine PDF in PHP 8 entwickelst, welche Library nutzt du?
Ich habs in PHP 8 noch gar nichts besonderes genutzt außer externe Tools wie WKHTML2PDF
Hey. Kannst du mal ein Video machen in dem du zeigst, wie man vorgeht wenn man sein php quellcode von bspw v7 auf v8 updatet? Habe nichts von dir dazu finden können
Klar es gibt das Tool rector PHP. Das ändert dein code ab. Aber prinzipiell wenn dein code mit PHP 7 geht, wird es auch mit 8 gehen
Danke für deine schnelle Rückmeldung!
Ich hab auf dem PC noch ein altes script auf php 5 mit der template engine smarty gefunden, wollte das mal aktualisieren. geht das auch mit dem programm?
@@zilvestro1 ja. Du kannst damit von 5 auf 7 und dann auf 8 updaten
Glückwunsch zu 2000 Abonnenten. Ich sagte ja das du mehr als 1000 haben wirst bis zum ende des Jahres 😁👌
Dankeschön, ist ja schon fast das Ende des Jahres :P
Danke für das Wort „Syntaxsugar“ 😂 Köstlich. Darf ich das übernehmen, oder hast Du da nen Copyright drauf 😅
Steht unter WTF Public licence;)
Nichts gegen PHP, aber bei mir hat es mit 5.7 aufgehört... In Zeiten von NodeJS, Django, Rust und Go, bin ich nicht mehr mit PHP in Berührung gekommen. Hat es noch Vorteile in irgendeiner Form?
Naja die Vorteile liegen halt darin dass noch viele andere APplikationen damit umgesetzt wurden und einem die Sprache viel mehr liegt. Direkte vorteile kann ich nicht nennen weil ich nicht mit Python/DJango, Rust/Go, NodeJS wirklich gearbeitet habe. Das einzige was ich als Vorteil gegenüber NodeJS ansehen würde ist der Packagemanager von PHP und das Arbeiten mit Interfaces ohne extrene Sprach KOnstrukte wie Typescript zu nutzen. Und natürlich weil PHP nicht asynchron ist, was die entwicklung etwas einfacher macht.
@@VitalijMik Viele andere Applikationen? Für mich hatte PHP immer nur einen Anwendungsfall und zwar Webseiten dynamisch mit Inhalt zu füllen, was es ja auch sehr gut macht, sieht man ja daran wie weit Wordpress und Laravel verbreitet sind (und natürlich rein PHP^^). Ich persönlich würde nicht auf die Idee kommen mit PHP irgendetwas anderes umzusetzen. Habe in einem anderen Kommentar von dir gelesen: PHP nutzen um Webseiten zu crawlen. Ich würde niemals auf diese Idee kommen, dies geht doch easy mit Python und Beautiful Soup und mit Selenium kann ich alles mögliche noch automatisieren in Webanwendungen. Da starte ich doch Lokal keinen Server der mir PHP interpretiert. Naja NodeJS hat ja auch nen Packetmanager obwohl da ja die Meinungen auseinander gehen und nicht alles in JavaScript / NodeJS ist asynchron. TypeScript ist auch nur "syntactic sugar", das was überbleibt ist auch nur unschönes JavaScript xD Ich wollte PHP auch gar nicht schlecht reden, immerhin ist das die erste Programmiersprache die ich gelernt habe^^
@KDominic_ naja neben Laravel und Wordpress gibt es zum Beispiel Shopware, damit wurden auch sehr viele Shops umgesetzt, gerade jetzt zu Corona Zeiten wurde es noch mehr gefragt.
Selbst große Unternehmen suchen weiterhin PHP Entwickler weil man nicht einfach so einen Code der vor jahren entwickelt wurde nicht einfach wegschmeißen kann, solange das Geld Produziert. Banken und Möbelgeschäfte hatten selbst vor paar Jahren noch Basic/Smalltalk applikationen und die Entwickler der Sprachen konnten auch den Gehalt bestimmen wie sie wollten. Weil es kaum jemanden gab der sich das noch antun wollte.
Will sagen nur weil etwas nicht Modern ist und keine Vorteile gegenüber anderen SPrachen hat, heißt es ja nicht dass es nicht gebraucht wird.
Klar könnte man bestimmt das alles was ich mit PHP umsetze auch mit NodeJS, Python usw umsetzen. Allerdings wenn ich nur eine Webseite entwickle und ab und zu paar kleinere Tools, finde ich, macht es für mich gar kein Sinn alles was ich bisher gelernt habe und Beruflich mache dann einfach wegzuwerfen.
Ich will auch nicht NodeJS/Python/Rust unw. haten. Sicherlich haben die ihre Anwendungsgebiete und sicherlich haben die viele tolle tools. Aber ich könnte auch genauso gut sagen. Dann kann ich gleich C# benutzen, hat eine Saubere Syntax, kann desktop Applikationen und ASP.Net auch noch Webseiten. Hat ein Mysql Client der Prepared Statements unterstützt und hat sogar ein Compiler.
Ich finde man sollte nicht Sprachen nach Vorteilen/Nachteilen abwägen sondern nach dem was man mag und was einem spaß macht. Ich habe immer noch Spaß an PHP und NodeJS habe ich zu Anfangszeiten probiert und nach kurzer Zeit aufgegeben. Teilweise kommt man da aber nicht drumherum wegen less/webpack usw, da benutze ich es dann. Ich weiß dass NodeJS ein Packetmanager hat, vielleicht sogar 2-3 das letzte Mal als ich es mir angesehen habe war Yarn das non plus ultra und NPM war schlecht.
Python nutze in Blender oder Gimp weil es dort unterstützt ist. Wäre dort PHP würde ich es dann lieber PHP nutzen.
@@VitalijMik Ich wollte PHP oder sonst einer Sprache auch nicht die daseins Berechtigung absprechen. Ich persönlich hatte halt in den letzten Jahren keine Berührungspunkte mehr zu PHP.
Ich kann es auch vollkommen nachvollziehen, das man am liebsten für alles ein und die selbe Sprache nutz, die einem besonders liegt / gefällt.
Finde es Großartig, dass du Spaß an PHP hast und ich stimme dir voll zu das keiner unnötigt Applikationen neuentwickeln wird, wenn die alten mehr als gut funktionieren und Geld bringen.
Jedoch widerspreche ich der Ansicht, der Ansicht, dass man eine Sprache nicht nach Vorteilen/Nachteilen abwägen sollte. Data Science oder Machine Learning würde ich fast immer mit Python machen, da es hier die großen Frameworks gibt. Große Spiele würde ich mit C++ / C# wegen Unity oder Unreal verwenden. Treiber / Hardware nahe Sachen like Microkontroller (auch wenn es hier mitlerweile MicroPython oder JavaScript for Microcontrollers gibt) / Embeded System immer mit C / C++ aufgrund der performence / Speicher Vorteile nutzen. Nicht umsonst gibt es soviele unterschiedliche Sprachen.
Ich finde es ja an sich interessant das viele Sprachen ihre Anwendungsgebiete verlassen, wie JavaScript mit NativeJS für Mobileapps oder mit Electron für Desktopapps. Ähnliches gilt für C# für Desktop (wohl noch mehr Windows) aber auch Webapps und mit Xamarin für Mobnileapps. Ich bin da ganz offen und nehme dann die, womit sich meine Idee am leichtesten umsetzen lässt und wenn ich dann halt 5 verschiedene nutze xD
@@Num1989 das weiß ich alles, ich erstelle aber nun mal webseiten, und da nutze halt php ;)
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.
Meinst du, du wirst irgendwelche Features aus der neuen Version verwenden?
@AliveSurvive: Mal Hand auf's Herz: Das wird Dir doch anfangs in jeder Sprache so gehen.
@@VitalijMik Momentan sieht es noch nicht so aus. Aber ich bin auf jeden Fall offen für Neues. :)
Die Wahlfreiheit Ist meiner Meinung nach kein Nachteil. Jede Option hat seine Berechtigung - und sei es Abwärtskompatibilität. Wann was verwendet werden sollte ist auch gut dokumentiert und man gewöhnt sich schnell dran. Ich finde, PHP hat noch eine vergleichsweise flache Lernkurve. Junge Sprachen wirken natürlich cleaner - aber auch diese Sprachen werden sich verändern ... Früher jemanden die Zeigerarithmetik in C beizubringen war auch eine gewisse Herausforderung.
Generics: In PHP gibt es vermutlich bis jetzt keine Generics (wie stark typisierte Sprachen), da nicht dringend notwendig. Durch die schwache Typisierung bzw. Uniontypes ist diese Art der Funktions-Signatur seit PHP4 lauffähig umsetzbar (seit PHP8 strikter) - was fehlt, ist dass der Interpreter zur Laufzeit nicht prüfen kann, ob der Rückgabetyp zum Übergabeparametertyp passt. PHPStorm unterstützt mittlerweile Generics via PHPDoc Block
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
Im Großen und Ganzen hast du ja Recht, letztendlich ist ja gut dass sich die Sprache weiter entwickelt ich habe im Video ein Blog Artikel wiedergeben. Ich habe vor einigen Wochen als PHP8 Rauskam ein Stream gemacht, da habe ich die neuen Features gefeiert und ich habe auch ein Artikel zu PHP8 im PHP Magazin geschrieben, da habe ich auch noch mal gesagt dass ich mich über Neuerungen freue.
Dennoch kann ich den Artikel nachvollziehen. Also Thema Lehrer. Leider funktioniert das nicht immer mit einfach Richtung vorgeben. Du musst schon ein sehr guter Lehrer sein und musst gute "Schüler" haben die deine Richtung sofort auch nachvollziehen können. In Programmiersprachen hat man das Schwierigkeiten, der Beste Programmierer kann auch nicht unbedingt der beste Lehrer sein und der beste Lehrer kann nicht der Beste Programmierer sein. Ich merke ja selbst dass ich einige im Discord Chat "an die Hand" nehmen muss und einiges nach erklären damit es verstanden wird.
Switch und Match haben andere Verhaltensweisen, ja, aber es gibt durchaus sehr viele "typische" fälle wo man aktuell ein Switch case nutzt bei dem man einfach ein match einsetzen könnte und es würde an dem Verhalten des Codes bzw des Ergebnisses sich nichts ändern. Zum Thema Scopes, da geht es darum, wenn man zb "Funktionen" durchgehen würde, dann geht man auf normale Funktionen ein, dann lambda und dann muss man arrow Funktionen erklären und dann kommen schon die ersten Ausnahmen. Es gibt scopes, du hast Variablen außerhalb von Funktionen und Innerhalb ABER arrow Funktionen sind zwar auch Funktionen die funktionieren aber anders. Und Funktionen lernt man ja in der Regel vor dem OOP. Ich meine klar kann man das letztendlich erklären.
Die Kernaussage des Artikels war (ich habe es vielleicht nicht richtig wiedergeben) PHP ist schon gut wie es ist, wir brauchen nicht wirklich noch mehr Code-Sugar, investiert doch lieber die Zeit in Features die es vorher nicht gab. Zum Beispiel Attribute die KEINE Kommentare sind, oder Generics oder einen Compiler oder FFI.
Der aktuelle Match, den haben wir bisher mit preg_match oder if statements abgefangen. Es gibt "primitive" Schreibweisen die den Match komplett ersetzen könnten. Oder Nullsafe Operator, was ist daran so schlimm ein is_null zu schreiben? War die Zeit es wirklich wert in das Feature zu investieren? Oder Attribute im Konsturktor definieren. Wen du am Anfang OOP beschreibst, sagst du ja sowas wie "Eine Klasse hat eine Struktur, erst werden Eigenschaften definiert, dann kommen Methoden" und jetzt muss man diese Aussage erweitern mit "Es kann aber auch sein dass die Methoden erst über den Konstruktor definiert werden, deshalb müsst ihr erst nach __construct schauen". Es ist nur ein Satz aber der muss auch erst Mal richtig verstanden werden.
Es ist einfacher wenn du Richtung strukturieren kannst mit so wenigen Ausnahmen wie es nur geht.
Die Argumentation soll jetzt ja nicht die Sprache und neue Features irgendwie schlecht reden war nie die Absicht. Nur vielleicht sollte man sich nicht nur auf Code-Sugar konzentrieren.
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. :-)
oh ja DAS sind tatsächlich meiner Meinung nach die wichtigeren Features die noch fehlen. Method Overloading wäre ja total genial, und genereics da könnte man yield wunderbar typecasten so dass man aus einem Generator auch ein typ kriegen würde und nicht nur ein generator interface. Enums wären auch sehr gut vielleicht noch sogar STRUCT also Datenstrukturen
@@VitalijMik Definitiv! Gerade weil ich auch ein Framework erstelle wären solche Sachen , insbesondere Method overloading, sehr hilfreich. Hoffentlich kommen diese Features noch in künftigen Versionen, dann bräuchte sich PHP erst Recht nicht vor anderen Sprachen zu verstecken.
marc.info/?l=php-internals&m=121397217528280&w=2 seit 2008 wurde es angefragt und immer wieder abgelehnt;)
@@VitalijMik "It makes code less readable" - Meiner Meinung nach genau das Gegenteil. Schade, dass es immer wieder abgelehnt wurde.
@@xDarkComedy naja ich weiß ja nicht wann es zu letzt probiert wurde;) Vielleicht nimmst du dir die Zeit und erstellst ein RFC? 2008 wurde das ja alles per Mail geregelt, die Zeiten waren anders :D
Spannende Sichtweise 👍 BTW: Herzlichen Glückwunsch zur 2000er Marke
Dankeschön. Laut Socialblade sollte es nächstes Jahr um die gleiche Zeit 10k Werden ;) Bin mal gespannt
Sehr interessantes Video. Vielen Dank ^^
vielen dank fürs Zuschauen ;)
Ich finde neue Versionen schön und gut, aber man sollte sich wie zb. bei switch und match entscheiden welches benutzt und welches entfernt wird.
ja switch case kann man aber nicht entfernen, da würden ja alle applikationen zusammen brechen. Es ist ja überall verbaut
Da der Switch ein Grundkonstrukt der Sprache ist, wird es als Legacy-Code für immer Teil des Compilers bleiben. Wenn Du das raus nimmst, bricht alles zusammen!
switch und match ersetzen sich aber nicht gegenseitig.
@@rckd5903 match kann schon den switch ersetzen weil ja viel mehr kann, wegen dem strikten typecheck kann es aber schon zu unterschiedlichen Ergebnisse führen.
Es kommt mit dem match halt ein weiterer Part in einem Anfänger Kurs dazu wo man dann den unterschied erklären muss.
Wo sich dann der Anfänger komisch vorkommen könnte so nach dem Motto "Aber wieso verwende ich dann überhaupt switch wenn ich match nehmen kann?"
@@VitalijMik Nein, match kann bspw. nur einzeilige Ausdrücke und ist deutlich strikter (strikter Vergleich, UnhandledMatchError-Exception).
switch und match sind nicht interchangeable.
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')
Hi Ja mir ist klar dass die Sprache sich weiter entwickeln muss. und weil ich weiß dass ich bis zur Rente mit PHP Arbeiten werde (finde die sprache toll) finde ich halt einige Dinge nicht so schön.
Das mit Switch und match war zum Beispiel damals nicht so nach außen kommuniziert. Es gab damals beim Release die schöne php 8.0 Page wo es einfach gegenüber gestellt wurde mit "new" und "old". Das Video hier ist ja auch schon etwas älter.
Ich treffe halt heute immer noch code mit alter array schweibweise, alte Properties ohne typehints usw und ich weiß ganz genau. Das ist ein alter Code. Und ehrlich gesagt finde ich neue schreibweisen für Dinge die wir bereits schon immer haben, nicht wirklich hilfreich für die Sprache.
Ich wünschte halt dass die Zeit in neue Features invistiert worden wäre statt in andere Schreibweisen :D (Generics zb)
Wir sind hier aber nicht bei wünsch dir was sondern isso :D
@@VitalijMik ich weiß, was du meinst. Die Kommunikation könnte wirklich ein wenig besser sein und auch wenn PHP mit einer der besseren Dokumentationen hat - in dem einen oder anderen Fall ist sie dann doch auch mal verwirrend und/oder unzureichend.
Was das 'über Code im alten Stil geschrieben' - Ja, das passiert mir auch immer wieder. Ich weiß nicht, ob es ein allgemeines Problem vom Internet ist, welches nichts vergisst… und man daher viel zu oft über Leichen stolpert… oder ob das mit an der Community liegt, wo viele noch immer ohne Nachzudenken einfach Copy'n'Pasten… ich bin letztens auch über ein Beispiel gestolpert, wo jemand 5 Klassen in das Projekt eingebaut hat… und später die Klasse zwar instanziiert, dann aber nie verwendet hat (So weit ich mich erinnern kann, war das was mit PayPal Bezahlung).
Aber ehrlich gesagt, hat ja nicht nur PHP das Problem… wenn ich sehe, wie viel zum Teil mit JS gemacht wird, was man aber besser direkt mit CSS umsetzen könnte… und das ist nur ein Beispiel. Bei Python gibt es auch immer wieder Verwirrung in dieser Richtung. Vielleicht echt ein universell(er)es Problem?
@@AmlorBluefog vielleicht mal anders.
Ich habe PHP Projekte, die aus PHP 5.4 5.5 Zeiten entwickelt wurden.
Als die neue Array schreibweise rauskam, bin ich den kompletten Code durchgegangen und alle Array stellen ersetzt.
Später als wir return types in den Klassen Eigenschaften bekommen haben, bin ich wieder durch den kompletten Code durchgegangen und alles ersetzt.
Das war sehr viel Aufwand. Ich kenne Projekte die das nicht gemacht haben und dann sitzt man im Team und überlegt, wie soll man da vorgehen.
soll man alles durchgehen und verbessern? Soll man alten Code so lassen wie es ist?
Soll man alten Code erst dann verändern wenn man gerade an der Stelle arbeitet?
Will man einen Mix haben?
Will man jedes Mal wenn was neues dazu, wieder alles umstellen?
Ich bin gerade bei PHP 8.1 und stelle gerade meine eigenschaften auf constructor properties um mit readonly.
das Problem ist. wenn ich es nicht mache, dann bleibt der alte code bestehen und man behandelt es dann wie Legacy Code und gibt sich nicht die Mühe wenn man an der Stelle arbeitet.
jede Neue änderung die rein Syntaktisch ist, bringt aufwand mit sich vor allem in größeren Projekten. Dazu bringt es Verwirrung mit sich da man das gleiche auf mehrere Art und Weisen erreichen kann.
Und das gefällt mir halt nicht. Natürlich ist es bestimmt auch ein generelles Problem in allen Programmiersprachen. Dennoch wollte ich sagen dass es mir nicht gefällt und ich finde, man sollte die Zeit besser in andere Features investieren als in neuen Syntax Sugar.
Nur als Beispiel. Es gibt zb die Funktion spl_autoload von PHP, stell dir vor das würde PSR-4 unterstützen. Stell dir vor wir könnten Klassen autoloaden über C Code statt über PHP.
Oder schau dir die readonly Klassen von PHP 8.2 an. Der komplette Release wurde jetzt auf mitte Dezember verschoben weil eine neue Syntax eingeführt wurde, weil jemand sich dachte, ich habe keine Lust vor allen meinen eigenschaften readonly zu schreiben.
Enum war zum Beispiel ein Feature was ich total toll fand, davon halt bitte mehr :D Das ist meiner Meinung nach Fortschritt und nicht eine andere Schreibweise für etwas, was wir eh schon davor konnten. Es spielt keine Rolle ob ich nun "Servus","Moin" oder "Hallo" sage :D
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.
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.
Ja das stimmt, allerdings ist das mit dem Framework auch eine Sache. Ich habe bereits sehr viele Frameworks erlebt die zu dem aktuellen Zeitpunkt etwas tolles angeboten und dann durch eine Feature änderungen alles komplett umgestellt wurden. Und bei Frameworks ist es auch oft so dass man am Anfang denkt, die würden gute Standards umsetzen und nach einiger Zeit stellen die fest, man muss doch alles umstellen.
Also wir hatten in der Vergangenheit oft die Frage ob Service Locator wirklich so ein gutes Pattern ist. Wurde später verworfen. Aktuell fragen sich viele ob DataMapper oder Active Record oder Repository design pattern besser ist. Das Framework bietet einfach alle möglichkeiten an und jeder kann dann entscheiden was mehr Sinn macht.
Es ist halt nie direkt von anfang an klar was man nutzen sollte, schließlich ist die Informatik an sich erst ein sehr junges Berufsfeld und wir alle lernen eh gerade dazu :D Damals im Mittelalter als die Medizin gerade ausgebaut wurde, hat man sich auch gefragt mit welcher Bibel der Aderlass am erfolgreichsten ist :D
@@VitalijMik Klar ist nicht alles immer Tutti. Ich sehe auch das in vielen Firmen immer noch PHP 5 im Einsatz ist, da ist an neuen Features eh noch nicht zu denken. ;-)
Solche Fragen sind aber auch meistens echt Luxus-Probleme. Entscheidend ist doch ob ein Framework einem dabei hilft ein Projekt schneller umzusetzen anstatt das man immer alles mit nativen Mitteln neu erfinden muss. Der Faktor Zeit sitzt halt neben dem Projekt Manager ständig im Nacken :-D
@@ProgrammierenMario WIe schnell man ein Projekt umsetzt ist halt auch relativ. Ich kann dir mit Laravel sehr schnell eine APplikation/Prototypen zusammenkleistern ohne Tests und an eine Build pipeline zu tun so dass Time To Market relativ kurz ist. Dann aber wenn das Projekt doch wächst und man ständig irgendwelche Fehler hat, kann man danach das Projekt verwerfen und neu und in besser schreiben. Ist halt auch die Frage. Ist die GEschwindigkeit wichtiger oder nachhaltigkeit.
Auf der Anderen Seite, wenn man eh weiß dass man ein Online Shop eröffnen will nur um Corona Masken zu verkaufen da ist die Nachhaltigkeit egal, hauptsache man ist schnell online solange alles noch ein Thema ist.
@@VitalijMik Ja, Willkommen im Alltag ;-)
Flickschusterrei ist essentieller Bestandteil unseres Berufes. Wer dafür eine Lösung hat...Instant Kauf :-D
@@ProgrammierenMario es gibt 3 Dinge die unendlich sind:
1) Dummheit der Menschen
2) Das Universum
3) Legacy Code Projekte :D
Hehe genau diese vielen Probleme hab ich auch gerade. Der weg rein zu finden ist ehrlich beschießen
mit der Zeit wird es besser. Es ist nur am Anfang noch schwierig
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).
Das es Arrow Function in PHP gibt wusste ich nicht ^^. Less is more würde ich sagen.
Es gibt auch nicht so viele Fälle wo man die wirklich braucht. Vielleicht kennt ja jemand ein, würde mich total interessieren :D
Naja, PHP ist in erster Linie eine Programmiersprache, die produktiv verwendet wird und marktfähig bleiben muss. Da ist es erst Mal egal, ob das dann gut für Einsteiger ist. Vor allem aber heißt "neue Features benutzen KÖNNEN" ja nicht, dass man es nutzen MUSS.
Die Schreibweise der neuen Annotations finde ich aber tatsächlich auch ziemlich bescheuert... Das machen andere Sprachen wie TypeScript, Java, C# usw. viel besser.
Okay früher hatten wir array_push um einen weiteren Wert zum Array hinzuzufügen. Es wurde eine neue Schreibweise mit [] eingebaut, dann wurde eine neue Schreibweise für arrays gebaut mit $array = [];
Was ist daraus passiert, ein array ist ein array geblieben, du hattest aber drei Schreibweisen, diese Tatsache bringt dich jetzt zu dem Punkt wo man innerhalb eines Teams eventuelle Streitigkeiten hat. Du hast mehrere Möglichkeiten.
1) Jeder der neu dazu zum Projekt kommt, darf nicht die neue Schreibweise verwenden, damit es überall gleich bleibt und du deinen Codestandard einhalten kannst
2) Du sagst dass Legacy code so bleiben soll wie es ist und neue Schreibweise in neuen Projekten eingebaut wird und somit hast du eine Mischform
3) Du überarbeitest alle deine Projekte auch alte Projekte in bringst den Code auf den gleichen Stand
Die Sprache war auch vorher Marktfähig vor den Arrays und man konnte es vor den Arrays auch produktiv verwenden. Hingegen sind viele PHP Entwickler zu Go gewechselt weil du dort Asychnron und schneller den Code ausführen kannst.
Das war eigentlich die Kernaussage des Videos, dass es durchaus einige Features gibt die nicht unbedingt hätten sein müssen weil wir da keine Probleme hatten.
Ein Match hatten wir die ganzen Jahren über auch, Eigenschaften in einer Klasse definieren, das macht PHP Storm mit einer Tastenkombination. 3 Unterschiedliche Implementierungen der Annotations war eine Zeitverschwendung.
Ich bin leidenschaftlicher PHP Entwickler und ich finde es ist die beste Sprache, dennoch sind einige Features eigentlich useless und die Zeit hätte in andere Features investiert werden können. Generics, Enums, Asynchrone Verarbeitung, Optimierte Arrays(richtige Arrays statt Hashmaps) diese Features würden die Sprache Marktfähig machen.
@@VitalijMik Ich verstehe deinen Standpunkt sehr gut. Ich glaube allerdings, dass das Hinzufügen von syntaktischem Zucker nicht das eigentliche Problem an PHP ist. Meiner Meinung nach ist das Grundproblem, dass sowohl die Sprache PHP als auch die Standard Library und mitgelieferte First-Party Extensions schon in sich, aber noch viel mehr untereinander ein einziges Durcheinander sind. Das fängt bei Parameter Reihenfolgen und unterschiedlichen Benamungsprinzipien (z. B. "strlen" vs "str_cmp") an hört bei Sprachkonstrukten auf, von denen manche expressions innerhalb der Klammern erlauben, während andere nur skalare Werte, Konstanten und Variablen beinhalten dürfen (z. B. empty() vs isset()). Dieses Durcheinander ist zwar historisch gewachsen, würde aber nie aufgeräumt und selbst neue Sprachfeatures oder stdlib erweiterungen werden oft ähnlich inkonsistent umgesetzt. Da ist leider Annotations in Kommentarschreibweise nur die Spitze des Eisbergs.
Ich finde aber trotzdem, dass kürzere Schreibweisen für gewohnte Konstrukte die Produktivität sehr steigern können. 70% der Zeit verbringen Programmierer/-innen nicht mit dem Schreiben von neuem Code, sondern mit dem Lesen und Verstehen von bestehendem Code. In diesem Sinne sollte es Ziel eines jeden Programmierers und einer jeden Programmiersprache sein, den sogenannten "Signal to Noise Ratio" so gut wie möglich zu bekommen. Wenn ich also in einem Model nur Standard-Getter und -Setter verwende - wieso sollte ich dann hunderte Zeilen Code schreiben und vor allem lesen sollen, die komplett unaussagekräftig sind? Wieso sollte ich bei Funktionen, die nur eine einzige Anweisung enthalten, zwei bis drei Zeilen Boilerplate Code lesen und verstehen müssen, wenn ich alles kompakt mit einer Arrow-Function ausdrücken kann? Wieso sollte ich ein Annotation-Framework nutzen, wenn die Sprache selbst Mittel zur Verfügung stellt, die das Problem auf Parser-Ebene viel schneller und effizienter und vor allem mit besserer IDE-Integration lösen kann?
Fortschritt ist nicht per se schlecht.
Es ist in meinen Augen unsere Aufgabe als Mentoren, der neuen Generation an Programmieren diese Sprachfeatures sinnvoll in verständliche Häppchen zu verpacken, sodass sie eben nicht zu Verwirrung führen, sondern das Repertoire an Tools zum Lösen von Problemen zu bereichern.
PHP sollte lediglich den Mut haben, alte Schreibweisen sukzessive als Deprecated zu markieren und Stück für Stück zu entfernen. Nikita Popov ist in dieser Hinsicht sehr progressiv - oft ist es die PHP-Community, die ihn in den RFCs überstimmt und dafür sorgt, dass veraltete Features und Schreibweisen noch über Versionen hinweg bestehen bleiben.
@@arminmatthes ich habe nie gesagt dass ich fortschritt per se schlecht ist, ich finde nur man könnte sich um andere Features mehr kümmern :D
@@VitalijMik haha ich bin genauso enttäuscht wie du, dass wir jetzt static typing für Class members haben, aber immer noch keine Generics, Tupels, Enums oder zumindest ganz rudimentären Support für Array vom Typ X. Die einzige Aussage aus deinem Video, die ich selbst so nicht unterschreiben kann ist, dass die Features die wir bekommen sind "useless" sind. Aber das ist sicher Geschmackssache ^^.
Ein Lichtblick: Enums zumindest sollen in PHP 8.1 endlich kommen 👍
@@VitalijMik Das Refactoring macht PHPStorm auch mit einem Klick. Du klingst für mich wie jemand, der gerne in seiner gewohnten Komfortzone bleiben will. Ich habe die Erfahrung gemacht, dass gerade junge Entwickler, die neu ins Team kommen, frustriert sind, wenn sie plötzlich wieder mit alten Konstrukten hantieren müssen...
if(){}else{} so habe ich es gelernt, so habe ich es verstanden und alles andere nervt mich persönlich.
Einerseits ist es ja toll, wenn sich etwas weiterentwickelt und auch die Sicherheit verbessert wird, aber es ist schon sehr anstrengend ggf. mit jeder neuen PHP Version seine ganzen Programme anzupassen. Ich mache das nur aus Hobby, glaube die richtigen Entwickler bekommen ab und zu mehr graue Haare.
Mittlerweile gibt es tools wie rectorphp die übernehmen vieles automatisch. Das nutzen wir dann
@@VitalijMik danke, das klingt ja toll mit dem Rector
@@maiks.3684 Es bleibt aber immer noch so dass man immer mehr und mehr Möglichkeiten bekommt das gleiche Problem zu lösen und dann gibt es den alten und neuen Weg. Ist halt so. Kann man nicht ändern:D
@@VitalijMik Solange der alte Weg bleibt, ist es auch kein Problem. :)
Danke für die Info´s!
Danke fürs Zuschauen, aber ich hoffe aus dem Video ist nicht herausgekommen dass ich PHP8 nicht mag. Das Video ist eine Übersetzung eines Russischen Blog Artikels und entspricht nur teilweise meiner Meinung
@@VitalijMik Da zeigt sich nur etwas Zwiegestaltenheit, dem ich mich voll und ganz anschließe - also zumindest dem Author des Blogs, da ich als Neuling beim lernen von PHP auf solche (wie im Video genannten Probleme) Probleme gegenüber stehe...
Das sind alles veritable Kritikpunkte, aber sie sind nicht php-spezifisch, sondern finden sich in eigentlich jeder Programmiersprache, die sich weiterentwickelt.
Joa das stimmt. Aber weil man ja mit der Sprache noch weitere Jahrzehnte verbringt darf man sich ja beschweren. Entwickler aus anderen Sprachen machen das ja auch. Man muss ja nicht hinter allem stehen was eingebaut wurde
Ich persönlich finde die short form von IF Statements nicht gut, bevorzuge lieber die normale Schreibweise. Leider kann ich nicht so ganz meine Meinung abgeben, da ich mit Laravel angefangen hatte. Ich weiß also nicht, wie sich Anfänger fühlen. Es ist eh allgemein schwierig sowas beizubringen.
Ich vermeide die Form auch oft. Aber hin und wieder kann man die gut nutzen. Zb eine div Klasse active zu setzen oder selected option zu setzen
Und ja beibringen ist echt schwer. Ich kriege hin und wieder Mails und Rückfragen wo ich dann im Nachhinein denke. Ich habe doch die Frage beantwortet. Noch einfacher kann man das nicht erklären
@@VitalijMik Ganz genau. Ich persönlich fand am schlimmsten SQL. Die Sache mit den ForeignKeys war echt schwer zu begreifen. Bzw, es gab einfach niemand, der es gut erklärt hat. Oder anders ausgerückt, der eine lernt schneller oder langsamer. Komplexe Datenbank Systeme, fand ich persönlich am schwersten zu verstehen, gerade ManyToMany ;)
Ich habe halt das Problem dass teilweise einige Grundinformationen fehlen. Also was ist HTTP. Dass da xampp auf deinem PC Installiert ist und dass es eigentlich ein Server ist. Ich bekam sehr oft die Frage wie man JavaScript variablen an PHP übergibt. Und wenn ich dann sage, "Eine weitere Anfrage an den Server schicken" dann gibt es viele verwirrte Fragen zurück. Ich glaube da gibts keine Prinzipielle lösung/antwort. Ich müsste mal mit einem SPrechen der Lehramt studiert hat, vielleicht wird ja sowas im Studium beigebracht.
@@VitalijMik Es gab eine Frau, welche sie intensiv damit beschäftigt hat, wie man Gehirngerecht lernt. Leider ist sie 2011 verstorben, aber es gibt noch viele Vorträge von ihr auf TH-cam. Einfach mal nach Vera Birkenbihl suchen. Die war echt mega. Sowas fehlt in Programmiersprachen.
Jap, an deinem Beispiel wird es kompliziert. Der Schüler muss dann erstmal JSON verstehen, um einen API Request an PHP zu senden. Für Anfänger ist das alles zu viel.
Es entwickelt sich dahin das alle alten Scripte nicht gehen und man eine riesen Firma sein muß um alles am laufen zu halten. Die ganzen alten Scripte z.B. wie eines das fast wie Y*utube ist usw. gehen nicht mehr ! Je mehr Code man schreibt desto schwieriger wird es das am laufen zu halten, also am besten alles einfach machen.
joa wir versuchen ja immer alles einfach zu machen, aber die Anforderungen steigen ja und dann wird alles komplexer :D
Ich finde auch, man sollte drauf achten, dass der Code (gerade für Anfänger) lesbar und / oder logischer wird bzw. bleibt. Aber auch daran wurde teilweise ja gearbeitet. Ich sehe mich selber noch als Anfänger und finde die Funktion str_contains genial. Finde ich logisch und leichter lesbar als zum Beispiel strpos. Wie das mit strpos geht, muss ich jedes mal nachlesen. str_contains finde ich selbst erklärend. Und damit es nicht so viele Möglichkeiten gibt, sollten alte Varianten meiner Meinung auch gerne schneller mal rausfliegen.
Stimmt, an die Funktionen habe ich erst Mal nicht gedacht weil ich mich bisher an den Klassen aufgehangt habe :D aber ja macht Sinn.
Ich finde eher, man muss mit einer Sprache Probleme effizient lösen können. Und PHP einfach zu halten, nur damit Anfänger damit besser klar kommen, ist der falsche Ansatz. Du musst doch viele Dinge im Leben lernen, die anfangs schwierig sind. Wenn Du Autofahren willst, wäre es natürlich am Anfang einfach, nur ein Gaspedal und sonst nichts zu haben. Aber letzten Endes ist man doch froh, dass man auch Bremsen, ein Lenkrad, Klimaanlage etc. hat, oder?
@@karlkoslowski5439 oder ein Ipad, eine KI, eine Automatische Steuerung, Anbindung an das Internet :D
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^^
ich weiß halt manchmal nicht ob es wirklich versüßt wird oder nicht;) wirst du in Zukunft Match benutzen? oder Eigenschaften einer Klasse direkt über Constructor definieren?
Ich weiß gar nicht, was ihr habt. Ich finde Javascript extrem gut leserlich.
@@vonBlankenburgLP
fetch('example.com/movies.json')
.then(response => response.json())
//was soll diese Zeile? nimm response und überschreibe es mit dem ergebnis aus response.json?
.then(data => console.log(data));
vielleicht ist es alles eine Gewohnheitssache, aber es ist schon krass dass eine kleine Zeichenabfolge eigentlich ein Funktionsaufruf mit sich bringt.
@@VitalijMik Das ist eine synchrone Niederschrift eines asynchronen Methodenaufrufs. Da die Methode fetch nicht blockierend arbeitet, musst Du ihr einen Funktionshandler übergeben. Dies könnte eine eigene Funktion sein, die da heißt function handleFetch(response) { return response.json(); }. Die Kurzschreibweise davon als Lambda ist eben response => response.json(). Diese Methode gibt offensichtlich wieder einen asynchronen Task zurück, der dann in die Konsole schreibt.
Ich löse das in Javascript mittlerweile über asynchrone Funktionen, die viel besser lesbar sind:
async function fetchAndLog(url) {
const fetchResult = await fetch(url);
const json = await fetchResult.json();
console.log(json);
}
Oder als Harakiri-Version:
const fetchAndLog = async url => (console.log(await (await fetch(url)).json()));
//Test
fetchAndLog('jsonplaceholder.typicode.com/todos/1')
@@vonBlankenburgLP das muss man mir nicht erklären, es geht ja nur darum dass es so stark verkürzt wurde dass es in eine Zeile passt. Man hat das Gefühl dass die Entwickler es gerne kurz alles in einer Zeile haben, schön nach dem Regex Prinzip.
Schau dir den Pipeline Operator an. ist so ein anderer Beispiel.
Zu dem Punkt wegen des Herausziehen des Compilers zum Erzeugen ausführbarer Binaries und Desktop-Applikationen in PHP: Das hat eigentlich recht wenig miteinander zu tun.
1) Desktop-Applikationen mit PHP sind bereits jetzt möglich - siehe PHP-GTK. Muss aber deswegen nicht compiliert werden. Native Desktop-Apps sind generell ein eigenes Thema, nicht nur in PHP, weil halt jede Plattform eigene APIs für die UI-Programmierung bereitstellt. GTK funktioniert zwar so gut wie überall, ist aber auch nur unter Linux u. *BSD so wirklich "native", nicht aber z.B. unter Windows oder macOS.
2) Eine PHP-Applikation zu compilieren und dann Binär zu deployen hört sich erstmal sehr attraktiv an, auch für Web-Apps. Ich denke aber nicht, dass jemand damit unbedingt native Binaries/Executables (z.B. ELF-Binary unter Linux oder EXE unter Windows) erzeugen möchte. Eine Alternative ist ein Intermediate Bytecode-Format, wie etwa bei Java, .NET oder auch WebAssembly, das dann von einem Interpreter oder einer Virtual Machine (z.B. Java's JVM, .NET's CLR) ausgeführt wird.
Und (fast) genau so etwas ist der PHP OPcache.
Der Unterschied zu anderen Sprachen ist nur, dass man nicht vorher compilieren muss und dann das Erzeugnis des Compilers deployed, sondern der Compiler läuft automatisch bei der ersten Ausführung des PHP-Codes. Das kann man durchaus als Vorteil von PHP sehen.
Wenn du gerne einen "Compiler" hättest, um schon vor der Ausführung deiner PHP-Scripts Type Safety zu garantieren oder Syntaxfehler zu finden usw., dann verwende ein statisches Code-Analyse-Tool wie z.B. Psalm - psalm.dev
Mir ist das alles natürlich klar. Ich kenne sowohl PHP-GTK und ich weiß was ein Compiler ist und was Psalm ist usw.
Und BTW PHP-GTK ist eine PHP5 Applikation dessen Entwicklung eingestellt wurde, es gibt zwar alternativen aber da sieht es für mich einfach nur so aus dass einige PHP Entwickler einfach nur gerne eine Native Applikation mit der Syntax von PHP Schreiben.
Psalm hat auch seine Schwächen, dieser kann zwar Typesierung usw prüfen bei einem Compiler hast du auch noch den Linker der auch überprüfen kann ob alles notwendige richtig verlinkt wurde.
ich wollte nur grob sagen dass es andere interessantere Features gibt auf die man sich eher Konzentrieren sollen. Ich fand es schade dass erst jetzt in PHP 8.1 Enums und Generics kommen und wo bleiben eigentlich getter und setter?
Kern meiner Aussage war ja, ein match brauchen wir nicht weil wir schon vor PHP 8 mit einem preg_match alles prüfen konnten, jetzt ist es hübscher. Oder Properties direkt über construktor definieren, du hast PHP Storm, ALT+ Enter und schon ist alles generiert, eine extra Syntax dafür ist nice to have aber nicht essentiell.
Compiler war halt nur ein Beispiel, ich wollte mich da auch nicht zu sehr aufhängen.
@@VitalijMik Ok, dann habe ich es für die Community nochmal erklärt ;)
Ja, der Haupt-Fokus von PHP lag immer und liegt auch heute noch auf Web-Apps. Und da ist PHP nun seit über 20 Jahren eine der am weitesten verbreiteten Technologien überhaupt, das muss man erstmal schaffen ;) Alles andere waren halt immer nur kleinere Projekte, die sich nie wirklich durchsetzen konnten, weil ganz einfach zu wenig Interesse seitens der PHP Community bestand. Für z.B. Desktop-Apps gibt es ja auch reichlich "geeignetere" Tools.
Ich habe die Kernaussage in deinem Video natürlich auch verstanden. Das ist natürlich schon eine interessante Perspektive. Ich habe mich das selbst auch schon öfter gefragt, wieviel mehr PHP-Anfänger heute lernen müssen, als ich früher :) Aber es ist nunmal so, dass sich Programmiersprachen weiterentwickeln und neue Syntax-Konstrukte durchaus sinnvoll sind - man hat es halt nur vor 15 oder 20 Jahren nicht besser gewusst.
Das gilt bei weitem nicht nur für PHP, du hast ja schon JavaScript im Video erwähnt, aber auch z.B. bei Java oder in den letzten Jahren vorallem bei C++ hat sich da sehr viel getan. Ich persönlich möchte auf viele (in diesen Sprachen) relativ neue Features, wie etwa Lambdas/Arrow-Functions, heute nicht mehr verzichten!
Und ja, Enums, Generics, sowie auch die mittlerweile existierenden Namespaces und Type Hints hätte ich eigentlich schon gerne in PHP 5.0 gehabt :D
Mein Vorschlag: Wer heute PHP lernen möchte, sollte sich eher auf die "modernere" Art, PHP Code zu schreiben, fokusieren.
Viele "alte" Konstrukte gelten heute als überholt, weil man es heute einfach besser weiß. Mir fallen da gerade nur ein paar JavaScript Bsp. ein: Irreführender Scope von mit "var" deklarierten Variablen (Stichwort: Hoisting). Oder die Frage, worauf referenziert "this" in dem Kontext gerade? :)
Klar, es gibt natürlich sehr viele über die Jahre gewachsene Code-Basen, die noch "alten" PHP Code enthalten und deswegen kann man das ja auch nicht von heute auf morgen aus der Sprache PHP entfernen. Wenn man mit so einer alten Codebase zu tun hat, kommt man eh nicht drum herum, den Code zumindest lesen zu lernen. Man sollte aber IMHO neuen Code immer versuchen im modernen Stil zu schreiben... und vielleicht dabei auch mal ein Stück alten Code refactoren ;)
@@rstangl ich arbeite aktuell viel mit Shopware 6 und da merke ich gerade dass Programmierung immer unwichtiger wird. Vieles ist bereits Programmiert, alles was du als Entwickler machen musst, ist die Konfiguration richtig anzupassen und eventuell hier oder da ein paar Klassen Dekorieren/Überschreiben.
Vielleicht wird das die Moderne Programmierung sein, man nimmt das was da ist und COnfiguriert es so wie es der Kunde haben will. Veilleicht eine hübsche Verpackung im Form von Templates drauf und schon ist alles schön :D
Die fortschreitende Entwicklung unter Aspekt „aus der Sicht eines Lehrers“ zu betrachten, halte ich eher für akademischer Natur.
Wie bei anderen Programmiersprachen liegt PHP inzwischen in vielen verschiedenen Versionen vor. Jedes Jahr erscheinen neue Versionen, die Verbesserungen und Funktionserweiterungen mitbringen - ca. alle drei Jahre gibt es ein neues Major-Release. In der Regel unterstützen Webhoster aktuell nur noch PHP-Versionen ab 7.xx. Viele Hoster haben in letzter Zeit die Unterstützung für PHP 5.6 abgeschaltet bzw. haben es entsprechend angekündigt. Für Versionen >int
Die neue Syntax-Notation wird man spätestens dann nutzen wenn das Team beschließt dieses in die Coding Standards aufzunehmen. Hier wird es eh in der Umstellung dann ein Mix von beiden Varianten geben. Man kann nicht von einem Tag auf den anderen komplette Projekte umschreiben. So wird man dann zwei Stellen im Code haben und man muss wissen. Okay das ist alte Schreibweise, und das ist die neue Schreibweise.
Die Junior Developer haben heut zu Tage eh gefühlt schwieriger als wir es damals vor 15 Jahren hatten. Die müssen heute wissen was ein Docker Container ist was CSS Preprozessoren/CSS Frameworks sind, was Typescript ist dazu natürlich sich mit Frameworks beschäftigen und dann auch noch verschiedene Nuancen sowohl von PHP als auch JS kennen.
Wenn man nach und nach mit der Sprache wächst ist es überschaubar, fängt man aber da neu an, kann es durchaus passieren dass man da nicht zu Recht kommt.
Wenn sich niemand mehr Gedanken über neue Entwickler macht, haben wir bald keine.
@@VitalijMik Von Brian Goetz (Oracle) stammt die Aussage: „Languages must evolve, or they risk becoming irrelevant“. Das gilt sicherlich auch für PHP.
Insofern ist die Bereitstellung neuer Features in Sachen Performance und Funktionalität mit jeder neunen PHP-Version doch eher ein normaler Umstand. Als Entwickler ist man es ohnehin gewohnt, ständig Neues lernen zu müssen.
Ganz ehrlich? Deine Argumente „aus der Sicht des Lehrers“ kann ich nicht nachvollziehen. Denke daran: Wir sprechen vom IT-Umfeld! Allein 0 und 1 haben bisher nichts an Beständigkeit verloren … bis diese Entitäten durch QBITS ersetzt werden.
@@o.lewandowski7872 ich spreche nicht bei Features wo es um was neues geht. Oder Performance sondern um Features die das selbe tun was vorher schon ging nur anders..
Ich muss echt an meiner Kommunikation arbeiten, ich habe in keinem einzigen Satz gesagt dass ich dagegen bin dass PHP sich weiter entwickelt. Ich sagte dass man Statt den Syntax Sugar doch sich lieber auf die Weiterentwicklung der Sprache konzentrieren muss.
Beispiel 1 : Short array Variante. Seit dem wir die haben gibt es in fast jedem Projekt ein Mix zwischen kurzer und langer schreibweise. Performance Gewinn = 0 dafür muss man erklären, damals haben wir das so gemacht jetzt ist es so.
Beispiel 2: Haufen Alias Funktionen die je nach dem Ob der Entwickler aus einer anderen Programmiersprache kommt dann auch anders die dinge schreibt, zum Beispiel join() vs implode() wieder hat nichts mit performance zu tun sondern einfach nur syntax sugar. Oder list() vs [$a,$b,$c]. die() vs exit. sizeof vs count
Das sind Beispiele aus echten Langlebigen Projekten
jezt PHP 8. Constructor Property Promotion, du wirst noch in Zukunft Klassen finden die entweder schön wie im Lehrbuch erst Properties haben dann Methoden oder eben mal gibt es eine Klasse die gar keine Properties definiert hat sondern erst über den Constructor. Du wirst Klassen sehen die davon ableiten die dann gar keine Properties haben und im Code wird sich darauf bezogen werden. Das ist ein Code Sugar der Verwirrend ist.
Nullsafe Operator. Im Clean Code Buch von Robert Martin wird auch gesagt, nutzt lieber nicht Null oder Statuscode, nutzt exceptions. Wir haben jetzt schon voller code wo es manchmal gemix wird mit dem null coalesting operator und mal mit isset. jetzt werden wir weiterhin code haben wo manchmal auf null geprüft wird und manchmal die short variante genommen wird.
Syntax Sugar bringt Inkonsistenz im Code.
Neue Fatures die vorher nicht da waren und jetzt wir brauchen begrüße ich NATÜRLICH. Ich freue mich riesig über Enums, Bessere Fehlermeldungen, Safe String Vergleich usw. Aber einige Features die nichts zur Performance beitragen sondern einfach nur eine andere Schreibweise ist, empfinde ich als verwirrend für Anfänger und eventuell wird es uns auf den Kopf fallen.
Die erwähnten Features haben ja auch Entwicklungszeit gekostet und es ist ja nicht so als ob wir unendlich Code PHP Developer haben. Hätte man den gesagt "Aber ENUMs sind wichtiger" hätten wir enums schon in php 8 gehabt, RFC war ja schon da.
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.
Oder halt Tools. Zum Beispiel als damals die neue Syntax für PHP Arrays eingeführt wurde, mussten wir uns hinsetzen und kompletten Code überarbeiten und alle Arrays durch die neue Syntax ersetzen und davor war das gleiche mit array_push. Ich meine es war jetzt nicht soo ein großer Aufwand, man musste aber eben die Zeit aufbringen. Mittlerweile gibt es aber immer mehr und mehr Tools die einem dabei unterstützen.
Die Auswahl macht es vielleicht schwerer für Anfänger, aber wesentlich leichter für Framework Entickler.
Das stimmt. Dass man Eigenschaften direkt im Constructor definieren kann, Symfony Entwickler werden es lieben:D
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.
Dankeschön, ja nur weil es geht muss man es nicht nutzen. Ich komme aber aus der Zeit in PHP wo immer wieder neue Dinge dazu gekommen sind, die vorhandene Projekte schlechter gemacht haben. Neue Features heißt immer wieder, entweder nutzt man die überall oder gar nicht. Ein Mix davon macht den kompletten code unschön.
Wir hatten zum Beispiel die neue schreibweise für arrays. In einem Projekt wurde es nicht festgelegt und man konnte beides nutzen. Dann hattest du Klassen gehabt die "veraltet" waren, die niemand vorher angefasst hat und dann hattest du neue klassen wo arrays in moderner form geschrieben waren. Der Code war inkonsistent.
Dann hatten wir ein Projekt wo wir alle arrays umgeschrieben haben um eine gleiche Basis zu bekommen. Das war halt sehr viel Arbeit in den Projekten alles rauszusuchen und zu fixen. Seit PHP 8 sitzen wir zb auch noch an den named parameters und entfernen die ganzen nullern bei den argumenten.
Du hast halt die Wahl, lasse ich mein Code so wie es ist und arbeite ab jetzt mit neuen features oder ich stelle alles um. Das erste führt dazu dass Entwickler den Code dann stiefmütterlich behandeln weil es ja "alter code ist". Der Alte Code läuft aber noch und braucht halt auch aufmerksamkeit.
Oder du stellst alles um was sehr viel Aufwand bringt, aber keinen wirklich mehrwert außer eventuell lesbarkeit.
Ich merke halt in den neuen Projekten jetzt auch, einige Entwickler nutzen immer noch ganz normal properties und setzen diese über konsturktor, einige entwickler nutzen das neue feature, das wiederum führt immer wieder zu diskussionen innerhalb des teams. Einige Entwickler wollen sich nicht umstellen, einige wollen nur den neuesten Code nutzen.
Andere Schreibweisen für Dinge, die die Sprache eh schon konnte führt immer wieder zu Problemen die ausdiskutiert werden müssen oder man nacharbeiten muss.
Aber so ist es halt. Da ich halt täglich damit arbeite, wollte ich in dem Video einfach meinen Frust rauslassen ;) Neue Dinge sind nicht immer per se total geil.
@@VitalijMik Oh ja, ich weiß genau was du meinst, das hab ich aktuell auch ein bisschen. Bei uns im Team ist inzwischen die Devise, wir gehen nicht los und stellen alles im, wie du schon sagst, viel zu viel Aufwand. Aber: in jeder Datei, die wir eh anfassen - Bugfixes, neue Feature etc - schauen wir uns die ganze Datei an und ziehen alle gerade, was wir entdecken. Tabs to spaces, Klammern auf neuen Zeilen, Leerzeichen hinterm if, alles sowas, und eben auch Typisierung, Default-Parameter und so weiter. Über die Zeit wird dann der ganze Code nach und nach neuer, und durchläuft quasi eine langsame Mutation. Das einzige, was wir wirklich auf einmal im ganzen Projekt geändert haben, waren Arrays. Da haben wir ein bisschen Zeit in ein Cleveres Regex investiert, und dann mit Search and Replace alle auf einmal geändert. Gründliches review, und Deckel drauf 😄
Mit den Tests machen wir es zum Beispiel ähnlich. Losgehen und für alles einen Test schreiben wo einer fehlt ist absolut nicht machbar. Aber alles was wir anfassen wird überprüft, ob es einen Test hat. Hat es keinen, werden welche geschrieben. Das sind mal eine Handvoll pro Branch, das ist machbar. So haben wir unsere Coverage von unter 3 (!) inzwischen auf über 50 Prozent gesteigert.
Aber dafür braucht es eben ein Team, was willens ist sich auf neue Sachen einzulassen. Wir diskutieren sowas immer in der Retro und kommen gemeinsam zu einer Entscheidung, das hilft. Dann wird jeder gehört und niemand übergangen, und alle haben die Chance ihre Motivation und ihre Bedenken zu äußern.
"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.
Wobei man unterscheiden muss. Ich sagte neue Syntax für dinge einbauen die kein Problem sind. In 8.1 kommt zum Beispiel die neue Syntax für ein Enum, das ist zum Beispiel richtig geil und so etwas begrüße ich sehr.
Ich habe noch die 5er Version von PHP auf meinen Server
no risk no fun? :D jeferlich sach ich da janz jeferlich :D
@@VitalijMik was bedeutet das ?
Finde PHP 8 ehrlich gesagt das beste PHP was es bisher gab.. Meine Meinung...
ich habe auch nicht das Gegenteil behauptet ;) ich finde nur nicht jedes Feature von PHP 8 super
@@VitalijMik ich glaube das liegt aber an unserem Zeitgeist. Getreu dem Motto: es ist möglich also machen wir das so. Sehe ich in vielen Lebensbereichen, dass Dinge verkompliziert werden. Aber wie du schon sagtest es wurde dir ja nichts (fast nichts) genommen, sondern nur zusätzlich Möglichkeiten gegeben.
@@8zeti711 naja schau mal. Ein Entwickler hat jetzt mehrere Stunden am match case gearbeitet. Es hätte auch an generics arbeiten können. Dann wurde jetzt mehr Code in PHP src eingebaut über lange Zeit muss es auch gepflegt werden. Dann gibt es ein weiteres Feature um das selbe Problem zu lösen, das heißt in größeren Projekten wird man entweder darauf verzichten oder ein misch zulassen. Beim Mischen sieht der code nicht einheitlich aus. Wir haben zb immer noch alte Projekte mit Array vs [] und solche dinge erlauben wieder zu blog Beiträgen wieso PHP schlecht ist. Bei Features wie fibers sag ich nichts die waren super. Auch readonoly usw ich stehe halt nicht hinter jeder Neuerung weil ich damit weitere 10 mindestens noch arbeiten muss:D
bedenklich ist eher der Unsinn hier...
grad sowas wie constructor property promotion sind doch sowas von nice
Das sagst du halt nur weil du ein reiner Anwender bist und nicht dinge erklären musst. Immer wieder kommen hier kommentare weil die Entwickler viel zu kurzsichtig sind und nur auf ihre eigene Situation das beziehen. Natürlich weiß ich dass constructor proeperies im di context abused werden. Ich muss aber jedes mal erklären dass man das entweder so oder auch anders beschreibt. Es gibt nicht nur PHP anwender.
Außerdem ich habe das wieder gegeben was im Blog stand das habe ich im Video gesagt. Ich bin nicht der Autor des Blogs. Ich habe nur den Text wiedergegeben weil ich es interessant fand
PHP 8.1 die performance ist godlike.
stimmt, wobei ich nie Probleme mit PHP an sich hatte wegen der Performance. Meistens hatte ich eher Probleme mit falschen DB index, oder zu viele API Requests über HTTP oder Filestorage also immer wenn man auf externe Systeme zugegriffen hat, musste PHP auf antwort warten und deshalb war alles langsamer
@@VitalijMik vielleicht ein Grund um generell alle Daten zu ziehen und dann diese in Php zu filtern 😅
oder so wenig daten zu laden wie möglich und das schnell und oft um resourcen wieder frei zu geben für weitere PHP Requests :D
Bloß nicht noch mehr "Sugar".
Vielleicht geht es nicht anders :D
@@VitalijMik Aber es gibt auch jede Menge interessante Neuerungen über die Versionen hinweg. Ab v7.0 wurde PHP mit jedem Release besser und besser.
@@I_am_Raziel ich weiß, auch 8 ist super, enums sind geil. Aber es ist schon komisch zu sehen dass in einem Constructor Eigenscahften gesetzt sind, die nicht vorher definiert sind in der KLasse. Dass die Magisch da einfach drinne sind. sind wir echt schon soweit gekommen dass wir einfach die privaten eigenscahften nicht mehr definieren wollen? :D
@@VitalijMik Ja, solches mag ich auch nicht. Explizit ist besser als implizit.
@@I_am_Raziel oder der nullsafe operator, der wird in einigenn Projekten zu Fehler führen.
Früher musste man jeden if statement ausschreiben, dadurch konnte man deutlich sehen in der code coverage, welcher part von tests abgedeckt ist. Jetzt werden alle if statements weggekürzt und man weiß nicht mehr ob der code mit den tests abgedeckt ist.
Ich bin nicht gegen PHP oder so aber GERADE weil ich jeden Tag damit arbeite, darf ich ja auf einige dinge aufmerksam machen.
Der Zucker hat in JavaScript einen ganz anderen Hintergrund, bezüglich der Tatsache, das der Browser den Code verarbeitet und bei großen und vielen Scripten, dann doch viel Gewicht eingespart wird. Macht jetzt in PHP nicht so viel Sinn - aber : Für JavaScript - Entwickler ist die neue Syntax natürlich ganz nett. Man darf ja auch nicht vergessen, das PHP serverseitig einen ernstzunehmenden Konkurrenten mit JavaScript hat. Also ich finde es nett, muss aber nicht sein - dennoch werde ich es nutzen, da ich es in JavaScript gewohnt bin 😜. Ach und nen Compiler zur Realisierung für Desktopanwendungen - ein Traum 😍 - frag mal die ganzen Desktop - Offline / Online - Anwendungen. Ich meine ich habe in JavaScript die Möglichkeit meine App als „Desktop - Anwendung“ bereitzustellen. Allerdings ist das ein Thema was PHP schon längst hätte angehen können. Aber vielleicht kommt es ja als nächstes großes Ding.
Wobei man JavaScript mit PHP nicht einfach vergleichen kann. Auch wenn NodeJS mindestens das kann was auch PHP kann und noch viel mehr, ist die Arbeitsweise und Herangehensweise doch komplett anders. Stichwort Callback hell, ein PHP Entwickler kennt das zb nicht. Oder "Metasprachen" wie Typescript. Also man muss es kennen und verstehen, einfach so zu sagen "Ich steig mal um auf NodeJS" ist ja nicht. :D
@@VitalijMik absolut 😌. Die Möglichkeiten welche mit Node.js geschaffen wurden, haben ja tatsächlich auch erstmal nichts mit der Sprache JavaScript im Browser zu tuen, aber es wurde übernommen. Ich meine spätestens wenn wir bei 6G sind, brauche ich mir doch echt keine Gedanken mehr machen, bzgl dynamisch auf dem Server oder statisch, oder komplett dynamisch beim Clienten. Ich meine das muss ich eigentlich noch nichtmal mit 4G. Im Großen und Ganzen kann ich den ganzen Content mit JS importieren und sämtliches funktionelles für den Clienten auch. Dann bleibt für PHP nur noch das reine Backend - Datenbanken, Files, Sockets usw...
Was die Performance für den DOM - Contentload angeht, sehe ich da keine Unterschiede mehr, außer mein PHP - Backend ist komplett mit Generatoren aufgebaut, dann ja.
@@svenskanda wobei man auch dazu sagen muss, mit ein paar Tricks könnte man mit PHP die gleichen Ergebnisse erzielen wie mit NodeJS ;) Spoiler sitze da gerade an ein paar Experimenten ;)
@@VitalijMik Die sog. callback-hell gehört seit async/await der Geschichte an.
@@VitalijMik ich freue mich und werde das mal von dir Verfolgen - denn tief in meinen Herzen liebe ich PHP und wäre schon traurig nur noch mit JS zu arbeiten. Nicht nach all der Zeit und nicht nach all den Kopfschmerzen, die mir massige Anreihungen von Generatoren gebracht haben. Ich meine yield war schon ein Traum und jetzt freue ich mich auf den JIT.
Für den lieben Algorithmus ;)
Vielen Dank, falls jemand das Sieht, schaut unbedingt auf dem Kanal von Maximilian vorbei, ihr werdet nach seinen Videos sicherlich lachen, das verspreche ich euch :D
Der Pipe Operator ist aber super, sowas sollte jede Sprache haben. Aber mit Funktionen als Strings? wtf, ich weiß ja nicht.
Was meinst du?
@@VitalijMik Naja in PHP sind Funktionen ja keine Variablen wie in den meisten anderen Sprachen. Im Screenshot sieht man ja auch, dass die Funktionen nur als String übergeben werden und nicht als Objekt selbst.
Eine Funktion ist eine Funktion, ein Objekt ist ein Objekt. In PHP kannst du anonyme Funktionen als variablen abspeichern und diese weitergeben. Das nennt sich in jeder Sprache lambda. Auch arrow finctions gibt es in PHP in den neuesten Versionen. Dass eine Funktion als objects daherkommt ist eigentlich eine sonderheit von Javascript.
@@SEOTADEO $variable = function () {} und die variable lässt sich weiterreichen
Fairerweise muss man sagen: Die meisten Hoster laufen eh noch mit PHP5 ;) (just kidding)
Ja viele Script Kunden haben ja auch die Einstellung "Ich hab mir das Script 2004 Gekauft, es muss für immer laufen " :D
Ich finde, daß 5.x die bisher beste Version ist.
Ich nicht :p
@@VitalijMik 😄
Виталик жги👍🙂. Подписка
ага, жгу, спс :D
Is eh opensource der kann ja rausnehmen was er will 😊
wenn es so einfach wäre:D der c code von PHP ist schon komplexer :D
@@VitalijMik verdammt 😂🤣😂
Ich finde PHP einfach schrecklich. Habe einige Zeit in einer Firma damit gearbeitet und es fühlt sich alles so unelegant und willkürlich an. So eine schlechte Erfahrung mit einer Programmiersprache habe ich bisher neben PHP nur mit R gemacht.
Es ist halt alles Ansichtssache. Kann sein dass du alten PHP Code vor dir hattest. Ich arbeite seit über 10 Jahren damit und finde die Sprache toll. Ich habe drei Jahre intensiv c++ genutzt und wegen PHP auch viel mit js und typescript zu tun. Im Vergleich zu diesen Sprachen ist PHP doch viel verständlicher. Was genau hat dich denn gestört?
@@VitalijMik Mich stört vor allem, wie man Components definiert im Vergelich zu z.B. React. Wie man die Datentypen definiert, die ein Component als Input kriegen soll. Einfach nicht schön gemacht in PHP. Führt meiner Meinung nach zu unsauberem Arbeiten. Oder wie man Components z.B. in Flutter erstellt, ist viel sauberer.
Verstehe ich nicht. Du erstellt in PHP einfach eine Klasse. Genauso wie es in c# oder java der Fall ist. Danach kannst du die Klasse als typehint definieren. PHP basiert auf C und daher kommt viel aus der c syntax famlie.
@@VitalijMik Aber Klasse und Html Template sind nicht so eng miteinander vorwoben. Vielleicht habe ich mit einem unmodernen Framework gearbeitet. Und mit Sicherheit kenne ich mich weniger aus als du in dem Gebiet.
@@SEOTADEO will sagen in PHP wird eine Klasse genauso wie die componente in react und fluttr. Die Syntax ist nur anders aber es ist 1 zu 1 das gleiche. Ich vermute echt dass du auf der Arbeit irgendwie ganz komisch Erweiterung in den code einbauen musstest und das kommt oft vor , dass in den Firmen dinge gebaut werden die über Jahre gewachsen sind. Man muss da wirklich genauer hinschauen ob es wirklich was mit PHP zu tun hat oder der vorhandenene code der bereits was komsiches hat
Dein Hemd is schick.
Danke wollte mal Seriös beim Video wirken :D