PHP

Hallo und herzlich willkommen bei einem neuen Deep Dive von der Programmierbar. Und wir haben heute ein Thema auf der Agenda, das mir ganz persönlich sehr am Herzen liegt, nämlich sprechen wir heute über PAP. Und weil PAP nicht nur mir am Herzen liegt, sondern auch anderen Leuten da draußen, haben wir uns einen von denen eingeladen und haben heute den Sebastian Veltmann bei uns hier im virtuellen Studio. Hallo! Hi! Und neben mir ist auch noch der Fabi wie immer mit dabei. Hi! Und wir wollen heute ein bisschen über PAP sprechen. Sebastian, wenn man bei dir aufs LinkedIn Profil klickt, steht da als allererstes Lead Technical Advisor bei Check24. Was hat das mit PAP zu tun? Ui, das ist nicht so einfach zu beantworten. Grundsätzlich ist es so Check24 24 ist ja nicht nur eine wirkliche Company, sondern ist so eine Gruppierung aus vielen verschiedenen Companies. Und sehr viele dieser Companies setzen PAP ein. Auch die, in denen ich ursprünglich mal so als Entwickler noch unterwegs war, haben PAP eingesetzt und setzen das auch immer noch massiv ein. Als Technical Advisor ist das jetzt ja, es ist so eine Mischung aus Inhouse Consulting und Trainings, würde ich mal sagen. So in die Richtung geht das. Und wofür wird PAP bei Tchech24 so genutzt? Oh ja, also grundsätzlich für das, wofür es ursprünglich mal gebaut war, Webseiten auszuliefern. Aber in den Produkten, wo es eingesetzt wird, ist es wirklich der komplette Stake, sage ich jetzt mal. Also alles quasi, was die Website macht, Schnittstellen, APIs, Middleware zu native Apps, Backends im Sinne von CRM Systemen, selbst entwickelte oder Content Management Systeme und so weiter und so weiter. Also wirklich das komplette Spektrum, würde ich mal sagen. Also CLI-Applikationen, Cronjobs, wirklich das volle Spektrum. Cool. Fabi, welche großen Buden kennst du sonst noch so, die PAP benutzen? Oh, ehrlich. Das ist aus dem Stehgreif, die noch PAP benutzen. Irgendwie gefühlt bin ich über PAP nachdenke, weil in meiner Welt findet es nicht wirklich viel statt. Ich weiß, dass wir bei LOTUM früher auf jeden Fall noch zu den Zeiten, wo wir noch ein Produkt irgendwie entwickelt haben, das hieß Kingmeal, das war noch nicht in der Games-Branche waren, da wird PAP auf jeden Fall eingesetzt. Und sonst immer, wenn ich über PAP nachdenke, denke ich immer nur so: „PAP, aber dann denke ich immer an Lara, weil du denkst so: „Hey, das ist doch eigentlich so cool. Und das ist so mein Gedanke, ehrlich gesagt, zu PAP. Aber ansonsten, ich kenne … Weiß gar nicht, wer setzt PAP ein? Mir kommt keiner in den Sinn. Das ist nämlich genau der Punkt. Also das war genau die richtige Antwort. Die meisten Leute, wenn man sie da draußen fragt, so: „Wer benutzt irgendwie noch PAP?, die können irgendwie nicht viel nennen. Oder nennen so was wie: „Ja, früher habe ich das auch mal gemacht, aber heute macht das doch irgendwie keiner mehr. Und vergessen dann, dass irgendwie Mediawiki, also Wikipedia, WordPress, Tabler, Facebook, Slack. Also die setzen ja alle... Okay, auf WordPress hätte ich. Kommen können. Ja, okay. Die setzen ja alle immer noch oder schon immer ja auch PAP ein und machen ja alle zusammen schon einen sehr, sehr großen Teil des öffentlichen Internets irgendwie aus. Und das ist irgendwie für mich immer dieser sehr interessante Widerspruch, dass niemand so PAP kennt oder auf dem Schirm hat, aber gefühlt eigentlich jeder mindestens einmal am Tag auf irgendeiner Website ist oder wahrscheinlich auch mehrfach, die irgendwie von PAP getrieben ist. Und das wäre so meine erste Frage an euch und ich glaube, ich habe da sehr unterschiedliche Perspektiven drauf. Wo kommt diese Dissonanz so her? Wieso hat keiner PAP auf dem Schirm, obwohl er es jeden Tag im Browser hat? Na ja, ehrlicherweise sieht man es ja nicht. Also was ist, was es jetzt ist. Also selbst wenn im Hintergrund einer einen WordPress installiert hat, kann er das so manipulieren, dass jetzt nicht jeder sofort sieht, dass es ein WordPress ist. Ich kann einen Shop betreiben und vielleicht die Experten sehen, dass das im Ursprung vielleicht mal ein Magento war, was da drunter liegt. Aber sieht man das so als nicht-PAP-ler? Ich glaube nicht, würde ich mal behaupten. Also deswegen, ich glaube, ich meine, weißt du, womit die Google Website ausgeliefert wird? Na ja, es gibt ja schon Firmen, die sehr local über ihren Stacks sind. Also wenn du irgendwie so an GitHub denkst oder Shopify, die reden halt viel über Rubi Onrails und sowas. Aber viele von den Firmen, die so PAP verwenden, die nutzen das und sprechen halt nicht so drüber. Ich weiß nicht. Vielleicht denken sie, dass es mit so einem Stigma belastet oder so. Aber es ist halt, gefühlt hat PAP da so ein PR Problem. Aber das ist das, was ich auch vorhin meinte mit meinem Beispiel von Larawell und PAP. Weil wenn ich an PAP denke, denke ich irgendwie an dieses Mäh. Und wenn ich an Larawell denke, denke ich so, das ist auch frisch und coolund so, Moment mal, das passt nicht zusammen, dass ich das, dass ich diese Dissonanz irgendwie habe in meinem Kopf. Deswegen würde ich wahrscheinlich auch sagen, dadurch, dass ich, ich glaube, das letzte Mal, dass ich was mit PAP gemacht habe, war wahrscheinlich noch vor dem Larawell Release. Ich würde sagen, irgendwie sowas wie vielleicht so 2011/2012. Okay, das war ungefähr, als Lara wieder rauskam. Aber so wahrscheinlich würde ich tippen ein Marketingproblem, aber ich bin auch kein PAP Experte. Da würde mich interessieren, Sebastian, wenn ihr jetzt bei Check24 seid, wurde dann diese Diskussion schon mal geführt, was anderes als P&P einzusetzen? Und was kam raus? Ja, natürlich wird die geführt. In ganz vielen Bereichen wird die Diskussion geführt. Ehrlicherweise ist das -die Antwort ist natürlich immer it Depends. Grundsätzlich jetzt da, wo wir Webseiten ausliefern und sage ich jetzt mal in dem Bereich, wo unsere großen Applikationen damit laufen, macht es für uns überhaupt gar keinen Sinn, von der Sprache wegzugehen. Erstens ist die Sprache extrem gut Maintenance. Das heißt, sie entwickelt sich weiter. Es gibt irgendwie gar keine Ansichten, dass das PAP im nächsten Jahr nicht mehr weiterentwickelt wird. Das heißt, für uns gibt es auch keinen Grund, von der Sprache jetzt an unseren bestehenden Systemen wegzugehen. Es gibt bei neuen Systemen immer wieder stärkere Diskussionen, was gemacht wird. Und dann ist es ganz oft so, dass es eben heißt Hey, wir haben das Know how in der Company. Ein extrem großer Teil unserer Softwareentwickler würde sich, glaube ich, selbst PAP Entwickler nennen oder würden PAP als ihre Hauptsprache bezeichnen. Und dann macht es auch keinen Sinn, wenn die Sprache das macht, was sie soll und das, was man braucht, dann drüber nachzudenken, sie zu wechseln. Und die andere Seite des Depends ist: Es gibt natürlich schon auch Dinge, für die PAP niemals gebaut wurde. Also jetzt einen Demen zu schreiben oder so was, irgendwas, was nonstop läuft. Man kann das mittlerweile auch alles machen, das ist auch alles okay. Aber da ist es dann auch mal total legitim zu sagen: Hey, lass uns doch mal an bestimmten Stellen über eine andere Technologie nachdenken. Aber diese Diskussion komplett wegzugehen oder so, die ist nicht existent. Also das macht für uns keinen Sinn. Aber ist es denn, es macht ja dann trotzdem Unterschiede, wo du sagst: Okay, es macht keinen Sinn für euch wegzugehen. Oder wenn wir jetzt auf dem Greenfield anfangen würdest und sagen würdest okay, ist denn, also ist PAP für dich eine valide Alternative oder ist es ein, weil wir uns darauf committed haben und unser Stack sieht so aus, unsere Entwicklerlandschaft sieht so aus? Nee, also es ist definitiv eine super valide Alternative für alles, was Web angeht. Also weil es ist eine, auch wenn man es nicht glaubt oder man es nicht hört, wird das Marketing Problem, aber es ist eine extrem beliebte Programmiersprache und sie ist extrem weit verbreitet. Und dementsprechend sage ich mal, ist das Recruiting für diese Programmiersprache auch völlig okay. Also dass wir über Recruiting lange streiten können, wie gut das ist und wie schwer es ist Entwickler zu bekommen, ist klar. Aber der Markt an PAP Entwicklern ist schon entsprechend groß, auch in Deutschland und international. Auf jeden Fall. Deswegen ist das nicht so, wir haben das jetzt und das müssen wir jetzt und eigentlich würden wir gerne davon weg, sondern: „Nö, also das ist da und das nutzen wir. Und wenn wir was Neues machen oder so, dann steht das definitiv ganz oben auf dem Zettel. Du hast ja eben gesagt, PAP ist eine gut mentinte Sprache und wir haben ja auch das PAP 8.3 Release hier mal als Anlass genommen, zusammen darüber zu sprechen. Ich glaube aber trotzdem, dass das Bild, das viele Leute von PAP im Kopf haben, noch so aus PAP 5 Zeiten stammt. Wahrscheinlich noch älter. Also wahrscheinlich noch aus PAP 4 Zeiten. Also zu Zeiten, wo es halt auch wirklich eine Hacking Sprache war. Also keine Objektorientierung. In vier gab es schon Objekte, aber reden wir mal nicht drüber. So richtig kamen die ja erst in fünf. Und klar, wenn du irgendwann mit PAP 3 oder 4 angefangen hast und an Software gearbeitet hast, die damit geschrieben wurde, dann war das sicherlich nicht so eine tolle Erfahrung. Aber was zeichnet denn für dich jetzt am Ende eine well-mintainte Sprache aus? Also das stellst du so in den Raum. Aber woran machst du das fest? Was sind für dich so die guten Eigenschaften? Na ja, es gibt Security Patches regelmäßig, wenn es Probleme gibt. Es gibt regelmäßig neue Releases. Ja, es gibt aktive Entwickler, die daran arbeiten. Es gibt einen definierten Prozess, wie die Sprache weiterentwickelt wird. Pap ist ja wirklich eine der wenigen wirklichen Open Source Sprachen. Also die Features kommen aus der Community, der Code kommt aus der Community und die Entscheidung darüber, was gemacht wird, kommt aus der Community. So ein bisschen in Anführungszeichen. Aber es ist schon, es ist schon extrem Open Source, muss man sagen. Also zeigt mir eine andere Programmiersprache. Aber ist das ein Vorteil oder ist das ein Nachteil? Also wenn man sich jetzt anguckt, hinter TypeScript steht Microsoft, hinter DATE steht Google. Das ist ja auch so ein gewisser Vertrauensvorschuss, den man da vielleicht bekommt. Und du sagst zu Recht, PAP ist Open Source. Ich würde das auch so unterschreiben. Aber wenn ich mir jetzt angucke, als neuer Entwickler oder als Firma, die ein Produkt bauen will, auf welchen Stake will ich setzen? Auf diesen Open Source, den hier die Community seit 25 Jahren durch die Gegend schleift? Oder 20 Jahre? Doch, 25 Jahre. Länger schon. Oder halt auf eines von diesen Sprachkonstrukten, was irgendwie von diesen ganzen großen Valley Firmen hier irgendwie gepusht wird. Ja, kannst du natürlich immer argumentieren. Und klar könntest du behaupten, wenn irgendwas von Microsoft Maintennt wird, dann hat das einen Vertrauensvorschuss. Pep gibt es, wie du schon sagst, seit 25 Jahren. Das sieht nicht so aus, als würde es irgendwann mal aufhören momentan. Und deswegen, also es ist für mich nicht so relevant. Die Sprache wird auf jeden Fall, so wie es momentan aussieht, weiterentwickelt. Wir haben erst seit kurzem eine wirkliche PAP Foundation, die auch durch Spenden finanziert wird und die wirklich Vollzeitentwickler einstellt, an PAP zu arbeiten. Das haben wir noch nicht lange. Das heißt, ich würde eher sagen, ja, die 25 Jahre haben diese Sprache extrem, sagen wir mal erwachsen gemacht in allem, in allen Bereichen. Und dass da viele Kinderprobleme noch drinstecken in dieser Sprache und Quarks. Aber im Endeffekt, in welcher Programmiersprache ist das nicht so? Also wir können sicherlich über Mengenverhältnisse reden und so, aber sorry, also wenn du PAP heute anständig benutzt, dann hast du mit diesen ganzen Quarks nicht mehr so richtig viel zu tun. Die Sprache ist ja das eine. Das andere ist ja so das gesamte Ökosystem drumherum. Und ohne jetzt hier zu sehr in die Vergangenheit abzudrängen, aber ich habe ja auch früher mal PAP gemacht. Und ich komme ja auch aus so einem sehr großen PAP Ökosystem eigentlich raus. Und jedes Mal, wenn ich mir andere Sprachen angucke, fällt mir gefühlt zuallererst erst mal auf, was alles nicht da ist im Vergleich zu PAP, also zu modernem PAP. Gute Package Manager, irgendwie Testing Tools, Runner, statische Code Analyse, das ist ja alles mittlerweile sehr, sehr ausgereift. Aber auch alles Sachen, die halt eben zu PAP fünf oder 4 Zeiten noch so überhaupt nicht da waren. Was sind so deiner Meinung nach die großen wichtigen Änderungen, Neuerungen im Ökosystem, die PAP dann noch mal so einen richtigen Schub gegeben haben? Also ich glaube, ganz vorneweg musst du, musst du glaube ich wirklich Composer nennen. Also der Package Manager von von PAP. In welcher Version kam der? Ich bin PAP Newbie, habe ich malWann kam der? Oder ist er überhaupt mit einem Versionsreleas gekommen oder zu welcher? Der ist Open Source entwickelt, nicht von irgendwelchen offiziellen PAP Releases, sondern ist komplett Community-driven auch wieder so ein Thema. 2016 kam, obwohl die Composer eins geht Gold war das quasi. Von daher ich schaue gerade mal ein bisschen in der Liste. Auf alle Fälle war es vor Fabi's PAP-Zeit. Ja, 2011 war Composer. Da muss es aber schon gegeben haben. Das fällt. Ungefähr zusammen. Ob du es benutzt hast, steht ja noch mal auf einem anderen Platz. Ja gut, du musst sagen, ich meine, das muss man auch sagen. Deswegen meine, das Ding ist halt auch PAP war so ein Ding, damit haben wir glaube ich ein Uni Projekt umgesetzt. Und da war es auch so, gefühlt hat man irgendwie einen Teil davon gemacht. Das wurde vor entschieden, so PAP mach es einfach mal so. Und auch wie das da aufgesetzt wurde, man hat irgendwie einen kleinen Teil gemacht. Ich war nicht wirklich an der Entscheidung dabei. Ich habe dort irgendwie das kleine Rädchen gemacht, was irgendwie da jetzt wichtig war für das Projekt. Und ich glaube, ich bin auch nicht in den Flake von PAP gekommen. Ich denke auch schon damals hätte man bessere Setups wählen können, als wahrscheinlich in diesem Kontext gewählt wurden. Aber gefühlt ist es aber auch so ein bisschen das mit PAP. Meistens hat man sehr Early Kontakt damit. Also ich habe PAP vorher auch mal so für irgendwelche, keine Ahnung, für meine Counterstrike Clans irgendwelche Webseiten auf jeden Fall damit auch mal umgesetzt. Und da hat einfach nur irgendwas gemacht, damit es funktioniert. Dann kam irgendwie die Uni-Zeit, wo es schon ein bisschen professioneller war, aber gefühlt hat man dann in einem professionellen Umfeld, in dem man dann entwickelt hat, direkt, ist man direkt auf andere Technologien umgestiegen, zumindest in dem Umfeld, in dem ich gelandet bin. Und vielleicht ist das auch was davon, dass man sehr früh damit Kontakt hat und einfach nur so es muss irgendwie funktionieren gebaut hat und sich gar nicht so wirklich mit dem Ökosystem beschäftigt hat. Also da hat PAP im Prinzip, also ich weiß nicht, was das Gegenteil von einem Henne-Ei-Problem ist, eine Henne-Ei-Lösung. Weil also PAP ist ja immer noch überall ja quasi vorinstalliert. Also jeder kleinste Hoster, den du irgendwie buchen kannst, da ist irgendwie ist irgendwie PAP dabei und es läuft schon jeder, jedes V-Server Ding, jede Mini-Distro von Ubuntu oder was weiß ich, ist irgendwie PAP schon mit dabei. Und das macht es einfach unglaublich einfach auch damit loszulegen. Ich meine, ich habe früher auch so Pups Webseiten damit gebaut, weil es halt einfach da war und ging und man sich nicht erst irgendwelche Java Runtimes installieren musste und keine Ahnung was alles so tun musste. Das hat halt funktioniert so und das ist, glaube ich, für ganz, ganz viele, die damit anfangen, insbesondere wenn sie so auch sehr früh in ihrer Tech-Karriere stehen, wahrscheinlich der viel entscheidendere Punkt als wie wichtig ist es oder wie groß das Ökosystem, wie geil ist die Syntax und keine Ahnung, sondern läuft es halt einfach out of the box bei mir und kann ich was damit anfangen? Ich glaube, das ist aber auch ein Teil des Problems, weil es läuft natürlich dann total pure, also wirklich nur PAP ohne Ökosystem. Und wenn du dich dann nicht damit beschäftigst, also wirklich mit der Sprache und was, was bietet mir das Ökosystem? Weil es kommt ja nicht von PAP offiziell das Ökosystem. Das Ökosystem sind ja auch wieder nur Projekte, die irgendwo drumherum entstehen. Und dann hast du natürlich mit dem Plane PAP, wenn du damit arbeitest, auch da kann ich den Frust natürlich schon ein bisschen nachvollziehen. Nicht typisierte Sprache und der ganze Kram, das kann schon zu deutlichem Frust führen an bestimmten Stellen. Und ich habe Composer 2011 auch nicht auf dem Schirm gehabt. Also muss ich ganz ehrlich sagen, sondern das war bei mir wahrscheinlich schon deutlich später, dass ich es wirklich massiv eingesetzt habe. Aber ich glaube, es kam dann auch einfach. Es war einfach dieser Boom, irgendwie Sachen auf GitHub zu haben und Librarys von GitHub automatisch installieren zu können und so. Und das hat Composer dann, da die das von Anfang an irgendwie quasi mit mit einbedacht hatten, das hat dann dem Ganzen den Mega-Boost gegeben. Wie einfach es war, selbst ein Package zu veröffentlichen und das irgendwie über Composer installierbar zu machen. Also das war quasi dann auch der Bust nochmal, Leute dazu zu bewegen, Tools zu bauen, die man einfach darüber easy installieren kann. Und irgendwann hat sich dann halt so die Kern oder die großen Produkte herauskristallisiert, die dann einfach jeder verwendet. So Testing Frameworks oder statische Code Analyse und der ganze Kram. Das heißt, wie ist es aktuell so, wenn duWas ist so ein Typisches, jetzt sage ich mal, vielleicht Full-Stack Web-Applikationen zu bauen? Was ist ein Typ? Was wäre so ein typisches Stack gerade so? Was müsste ich? Was müsste ich? Welche Begriffe müsste ich kennen als PNUB? Ja, also du hast ja schon gesagt, Larawell ist glaube ich gerade, ja, ich würde sagen, das ist das hippe PNUP Framework gerade. Dann solltest du sicherlich was von PNP, Sten oder FAM gehört haben, die wirklich statische Code Analyse machen, also die deinen Code irgendwie schauen. Benutzt du die richtigen Typen? Kann das überhaupt hingehen? Fängst du alle Fehlermeldungen ab? Und solche Sachen? Benutzt du die PAP internen Funktionen, die ein bisschen quirly sind, richtig? Und all sowas. Also das wird da alles abgefragt. Dann sicherlich Testing. Also PAP Unit ist glaube ich so ein Thema, das ist ein Testing Framework, macht immer total Sinn. Und auch ja klar, Composer kommt dann automatisch über einen Package Manager. Wenn du irgendwie Larawell installierst, dann werden die dir das schon vorbeten und sagen hier bitte benutzt Composer, es zu installieren. Und damit bist du dann schon relativ gut aufgestellt, sage ich jetzt mal. Und dann, das Spektrum ist wirklich riesengroß. Also wirklich riesengroß. Und ja, dann benutzt du noch eine Idee, die deine Sprache anständig unterstützt? Und dann bis zu SET. Fabi fängt jetzt an mit seinem nächsten PAP Projekt. Ja, ich glaube, das war halt auch so ein Thema. Ich glaube, also ein Eklips oder so, und die gab es ja schon ewig für andere Programmiersprachen. Und auch das war schon immer ein Thema, das ja, bevor Chatbrains so richtig eingestiegen ist oder damals SENT mit SENT Studio waren die IDEs jetzt nicht so so stark wie sie in anderen Programmiersprachen, vor allem in hart typisierten oder kompilierten Sprachen sind. Und auch da kann man natürlich dann immer sagen Ja, ist alles ein bisschen wonky. Aber das Thema hat sich quasi auch erledigt. Also keine Ahnung. Also ich schäme mich jetzt nicht, Werbung für für für Chatbrains zu machen. Pap STORM ist eine extrem gute Idee und die die Unterstützung mittlerweile für die Sprache ist ist Wahnsinn. Von daher ja nur es gesagt zu haben in der Microsoft Idee habe ich gehört geht es auch. Aber ja, also ich meine, ich sage jetzt auch schon, wir sind jetzt mittlerweile bei Minute 22 in diesem Podcast und gefühlt ist es so, dass wir machen einen Podcast über eine Programmiersprache und wenn wir bei anderen Programmiersprachen damit anfangen, wird meistens über Feuer und Flamme einfach darüber geredet, was so eine tolle Sprache ist und so und gefühlt bei PAP musst du dir erst mal die ersten 20 Minuten dir anhören von uns. So ein bisschen dem... Wir sagen erst mal eigentlich alles, wie schlecht alles ist und du musst dich ein bisschen rechtfertigen dafür. Und das ist ja auch schon irgendwie ein Setup, wo du jetzt erst mal beweisen musst, wann habt ihr denn große Schritte in der Sprache gemacht und wo steht ihr denn jetzt irgendwie gerade? Aber vielleicht so, daraus eine Frage zu formulieren. Ja, du hast ja vorhin gesagt, was sind denn so die großen Steps? Und sind wir beim Composer irgendwie abgebogen, wenn du das mal in das Heute heben würdest, mit der aktuellen PAP Version? Würdest du sagen, es gibt noch so große Schritte zu tun wie zum Beispiel Composer, wo du gesagt hast Version 5, wie da Objektorientierung, fängt überhaupt erst so richtig an? Ist denn da noch viel aufzuholen? Oder würdest du einfach sagen, wenn PAP jetzt rauskommen würde, könnte ich genauso gut hier in einem Podcast sein und über das neue Hippekid reden? Oder ist daran irgendwas noch gerechtfertigt aktuell? Eigentlich muss man ehrlicherweise sagen, haben sich die Sprachen alle so so nah angenähert, dass es nicht mehr so die riesigen Unterschiede gibt. Es gibt natürlich die klassischen Unterschiede im Sinne von hart typisiert, schwach typisiert und Compilt und Skriptsprache und so, aber die Sprachen selber, irgendwie, dass Functions mittlerweile überall First Class Citizen sind und man Functions als Variablen speichern kann und so ein Quatsch, das ist mittlerweile in allen Programmiersprachen so mit Closures und wie es nicht alles heißt. Da hat PEP mittlerweile auch irgendwie eine Syntax, die sexy ist. Hat auch ein bisschen gedauert, aber ich glaube nicht, dass vom Feature Set, dass sich die Sprachen, die Sprache an sich unterscheiden. Ich glaube, es macht schon einen Unterschied, ob du in so einem PAP Umfeld unterwegs bist, so einem 'Load all, Destoy all', also so ein PNP Script. Du fährst es hoch und danach ist es weg. Oder ob du in so einem Node Kontext bist, wo alles nonstop läuft irgendwie und du eher so internes Request Handling machst. Aber auch da verschwindet ja der Unterschied immer mehr. Also wenn du. Dir anguckst, was. Da Frameworks teilweise versuchen und was mit Just in time Compilation und Caching irgendwie gemacht wird. Also selbst PAP als so klassische Skriptsprache versucht ja immer mehr auch diesen anderen Sprachkonstrukten ähnlicher zu werden. Auf jeden Fall. Und ich glaube, das ist das. Also wenn mir noch irgendwas fehlt, dann ist es, ich traue mich nicht zu sagen, aber es ist parallele Execution von PAP Code. Also wirklich quasi das, was du in anderen Sprachen quasi asynchron hast. Das gibt es in PAP. Es gibt jetzt die Fibres und das geht in so eine Richtung. Ja, ich weiß nicht, ob die das jemals machen werden, aber wenn die quasi noch, wenn die so was einfaches hinbekämen, wie man quasi in GO als GO-Routine hat oder sowas. Also wenn es sowas noch gäbe, so triviales oder, also parallel Execution ist nie trivial, aber so einfach verfügbare Sachen, das wäre glaube ich noch so ein Killer, der die Sprache echt noch mal richtig boosten würde. Wie machst du es denn heute, wenn du vor so einer Aufgabe stehst? Also in den meisten Fällen macht man ja quasi Web Requests und dann fängst du halt an mit Multicurl. Du benutzt ein React PAP zum Beispiel, so was zu machen. Oder du gehst über Queues und arbeitest quasi über Queues und Worker und arbeitest so ein bisschen das Problem ein bisschen drum rum. Dann wird es nicht in der Sprache selbst gelöst, sondern du machst dann irgendwie ein Revit MQ drüber oder ein Redis oder sowas. Also das Tooling, so was zu implementieren, ist auch für die Sprache hundertprozentig verfügbar. Manche Sachen sind halt ein bisschen umständlicher, sage ich jetzt mal, aber alles im normalen Bereich, sage ich jetzt mal. Und wenn wir uns jetzt an Fabi halten und mehr versuchen, das geile Zeug von PAP zu pushen und uns weniger darauf zu fokussieren, was alles nicht funktioniert, was ist denn so mit dein Lieblingsfeature oder welcher Teil von der Sprache, wenn du ihn gerade benutzt beim Arbeiten, beim Schreiben ist, wo du denkst, das ist aber richtig cool und richtig einfach für mich. Also was ich total unterschätzen gelernt habe, ist lose Typisierung. Also das ist jetzt so ein zweischneidiges Schwert, weil es auf der einen Seite natürlich ein bisschen fehleranfälliger ist. Auf der anderen Seite gibt es einem so viel Flexibilität, bestimmte Dinge viel, viel einfacher zu machen und viel, viel effizienter. Typische Skriptsprache einfach. Also das ist schon... Also ich finde, wenn man sich an das Tooling gewöhnt oder wenn man das Tooling mal am Start hat, wie ein Composer, ein PAP Unit, ein PAP Sten, ist es ein extrem cooles Entwickeln. Also es geht einfach extrem schnell von der Hand. Mittlerweile gibt es ja sogar Tooling, Framework-Versionen abzugraden, also so ein Rack Door, das nächste Tool in den Raum zu schmeißen. Wenn man eine Symphonie 6 Applikationen hat und sagt, ich möchte das gerne auf Symphonie 7 Upgraden. Da musst du glaub ich mal genauer erklären, was Rector macht, weil das ist was, das es nicht in jeder Sprache gibt. Ja, auf jeden Fall. Das gibt es definitiv nicht in jeder Sprache. Rector ist ein Tool, was grundsätzlich stellt es quasi zur... Also ist es ein Tool für Code Transformation. Also es nimmt Code als Input und gibt dir Code als Output. Und Rector ist quasi so ein Regelwerk oder ein Framework, quasi diese Regeln zu definieren, wie Code transformiert wird. Und innerhalb von diesem Rector Projekt werden so ein paar, sagen wir mal Standard Regelsätze werden da Maintennt. Du kannst deine eigenen schreiben, wenn du möchtest. Also du kannst deine von deinem komplett selbst entwickelten Framework, falls du mal so drauf warst und eins selbst geschrieben hast, könntest du quasi die Regeln schreiben, die deinen, sage ich jetzt mal, Custom Framework Code in ein bestehendes Open Source Framework transformieren. Und die Standardsachen, die so was wie ein Versionsupgrade von den Standard Frameworks, das ist oft quasi Bestandteil schon von Rector. Da musst du dich gar nicht drum kümmern. Das heißt aber, wenn ich es für mich nicht verstanden habe, ich nutze irgendein Framework und ich nutze Rector, wenn es zum Beispiel eine Major Upgrade von dem Framework gibt und es gibt irgendwie Breaking Changes, kann ich meinen Code dadurch Rector jagen und dann kriege ich den Code adaptiert, sodass alle Changes, die notwendig sind, das neue Framework zu benutzen, einfach funktionieren. Und diese Transformatoren werden dann geschrieben von den Framework-Maintenern, so die haben so Rector-spezifischen Files, die sie publischen oder? Oder so generell, es muss ja auch von irgendjemandem kommen. Also irgendwie... Ich kann es dir nicht sagen, wer das schreibt. Aber es gibt auf jeden Fall nette Menschen, die das tun und die das für einen machen. Zum Beispiel war es jetzt so, dass in einem PAP Unit Upgrade war es so, dass Return Types sind quasi in die Programmiersprache mit reingekommen, dass man Return Types definieren konnte und PAP hat das dann irgendwann adaptiert. Und das heißt irgendwann, wenn man die neue PAP Unit Version installiert hatte, dann sind die alten Tests fehlgeschlagen, weil das Interface jetzt gesagt hat, du musst einen Return Type definieren. Und da ist man mit Vector hingegangen und hat gesagt, konvertier mal bitte alle meine Unit Tests in die neue Version und der ist über alle Dateien drüber und hat einfach überall diesen Return Type hinzugefügt. Und dann war der Drops gelutscht. Das war meistens so eine, je nachdem wie groß die Test-Suite war, war das so ein paar Minuten Drops, sage ich jetzt mal, anstatt von alles händisch irgendwie anpassen oder irgendwie suchen und ersetzen schreiben oder sowas. Das heißt damit kann ich auch meinen PAP Versionsupgrade auch durchführen? Ja. Wie viel jetzt so ein bisschen auch wieder eine Newbie Frage, wie viel Prozent der Upgrade machen wir in Rector und wie viel macht man händisch oder macht man überhaupt welche händisch? Was ist so, wie hoch ist die Trefferquote? Das hängt ein bisschen davon ab. Ich glaube Rector ist, ich kann es schwierig einschätzen, ich glaube es ist mittlerweile super populär und auch super bekannt. Ich würde sagen, das ist so eine 50/50 Geschichte. Jetzt aus persönlicher Erfahrung. Also für so was wie ein PAP Unit Upgrade kann ich es super easy benutzen. Also wirklich super easy. Wenn ich sehr viel Custom Code habe, kann ich es für so ein Versionsupgrade easy benutzen. Also wenn ich sage okay, such mir mal alles was in 8/2 Breaking ist, wenn ich jetzt auf 8/3 gehe. Dafür ist es auch richtig, richtig gut. Ich bin jetzt nicht der Mensch, der super viel Erfahrung in Symphony oder Larawell hat. Das heißt, da könnte ich dir jetzt nicht mal eine Aussage treffen, wie gut das da funktioniert. Symphony ist ja eigentlich immer sehr stolz darauf, dass sie es schaffen, Round about zum Release Termin von der Version auch die Rektordateien zur Verfügung zu stellen. Und wer schreibt die? Die kommen schon auch aus der Community. Es ist jetzt nicht so, dass Sensorlabs als große Firma das irgendwie alles alleine schreibt. Aber es haben ja alle ein Interesse an der Community, so dass das irgendwie sauber über die Bühne läuft und dann klappt das irgendwie schon auch. Und gerade wenn du in so einem Space unterwegs bist wie vielleicht Magento, wo viele kommerzielle Agenturen auch irgendwie hinten dran stehen. Also für die ist das ja ein richtiger Cash-SAFe, wenn sie sich überlegen, wie viel Entwicklerzeit müsste ich da reinstecken, versus was könnte ich davon automatisieren? Und dementsprechend, ich sage mal, je größer und kommerzieller so ein Framework, so ein Library ist, desto besser sind deine Chancen da auch irgendwie so einen Support zu finden. Könnt ihr nochmal kurz für die Leute, die auch nicht PNP nutzen, nochmal zwei Sätze zu Symphonie, was das scheint ja ein großes PNP Framework zu sein. Was ist Symphonie? Ja, also Symphonie ist, wenn du mich fragst, der ich Slijly Biased da vielleicht bin, ist das große PAP Framework eigentlich. Also da wo man früher, wo alle irgendwie so die voll zu sein oder so gelaufen sind, ist Symphonie eigentlich so dein Standard heutzutage. Und sie haben es halt sehr gut geschafft, von Anfang an das so sehr auf einzelnen Komponenten zu bauen, was irgendwie auch dazu beiträgt, dass du den Symphonie Router, den findest du halt irgendwie heute in fast jeder Anwendung, unabhängig davon, ob sie jetzt irgendwie Symphonie nutzt oder nicht. Symphonie Templating mit mit TwinK kannst du halt irgendwie auch benutzen, auch wenn du das Framework nicht benutzen willst. Aber wenn du irgendwie deinen Blog, deine Website, deine statische Website, was auch immer baust, kannst du halt den Teil davon benutzen. Und so schaffen sie es halt, dass im Prinzip viele Entwickler schon mal mit Symphonie Komponenten gearbeitet haben und so diesen Weg kennengelernt haben, auch wenn sie vielleicht nicht zwangsläufig das ganze Framework benutzen. Und das Framework hat halt an und für sich auch noch den Vorteil, dass du es auch sehr minimalistisch benutzen kannst. Also kannst du im Prinzip den Router und das Templating zusammenwerfen und schon hast du so ein Microkernal Framework aufgebaut. Du musst da jetzt nicht Datenbankabstraktion und Service Container und keine Ahnung. Also du musst nicht gleich mit der Tür ins Haus fallen, sondern man kann sich da so sehr, sehr gut rein arbeiten. Gibt's jetzt glaube ich auch seit dieser nächste irgendwas Woche in der Version 6.4. Die Version 7.0 kommt dann Ende des Jahres wahrscheinlich mit den Breaking Changes wieder und ist eigentlich mittlerweile so mit Larawell, das ja ein bisschen jünger ist, aber auch auf den Symphonie Komponenten aufbaut wiederum eigentlich die beiden großen Frameworks, die du nimmst, wenn du irgendwie eine, ich sage mal seriöse PAP Anwendungen bauen willst. Sebastian, ich weiß jetzt nicht, ob bei Check24 vielleicht keins davon benutzt wird. Ich wollte jetzt nicht sagen, dass Check24 nicht. Seriös. Ist. Oh mein Gott. Sebastian, du sagtest ja auch, dass LarawellDas sind nicht so viel Erfahrung hat. Also nutzt ihr gar kein Larawell bei Check24 oder was ist euer, was ist euer PAP Stake? Wir haben früher sehr viel auf dem Sende Framework gearbeitet und dann nach Laminas migriert. Wirklich noch, ich meine, uns gibt es auch schon 24 Jahre, also auch schon ein bisschen länger. Die neuen Projekte, würde ich behaupten, sind fast alles Symphonie-Projekte. Wenn jetzt irgendwelche Kollegen von mir zuhören, schlagt mich nicht, wenn es nicht stimmt. Ich weiß zum Beispiel, dass unsere Firma in Österreich, also Check24. At, alles was bei denen PAP ist, läuft auf dem Larawell Framework. Das heißt auch da seid ihr bei Check24 und einfach auf dem, was das Framework angeht, im PAP Ecosystem habt ihr euch nicht. Auf eins gemeldet? Also wir versuchen schon so viel wie möglich. Also grundsätzlich ist uns Technologie nicht so super wichtig. Aber wenn wir uns mal für was entscheiden, dann versuchen wir schon auch, dass ein paar Teams, ein paar Firmen diese Technologie nutzen, damit die sich eben austauschen können und voneinander auch lernen können. Der Laden ist nun mal groß mittlerweile. Und dann will man vielleicht doch auch so den einen oder anderen Vorteil mal nutzen. Das heißt, es könnte jetzt nicht jedes Produkt die Ecke kommen, auch die ganz neuen und mit völlig abstrusen Technologien die Ecke kommen. Ich glaube, der Stake ist schon sehr breit, den wir insgesamt in der Firma haben. Aber klar, wenn wir sagen, dann würden wir jetzt nicht mehr sagen, okay, dann schreib dein Framework selber, sondern dann würden wir die Leute schon höflichst bitten, eines der Frameworks zu verwenden, die wir im Einsatz haben. Und wenn jetzt Fabi zu dir kommt und sein neues Projekt starten will, was würdest du ihm denn so empfehlen davon? Auch das ist wieder so eine Geschichte. Was willst du wirklich machen? Und das ist ja das Schöne an dem, es ist so ein Supermarkt und du läufst einfach und greifst ins Regal, was du gerade brauchst. Also wenn du eine kleine private Website baust, auf der nicht viel los ist, irgendwie so eine Profilwebsite, so was wie meine, da benutzt du halt Wordpress. Und auch da können die Leute so viel schimpfen wie sie wollen. Das Ding tut, was es tun soll. Das hat nicht mal eine halbe Stunde gedauert, es aufzusetzen. Und das längste, woran ich gesessen habe, ist quasi die Templates anzupassen, damit es so aussieht wie ich will. Aber ja, das war auch schon alles. Wenn du ein Shop System bauen willst, gibt es auch mehrere Möglichkeiten, die du hast, in welche Richtung du gehen kannst. Wenn du, sage ich jetzt mal eine wirkliche eigene Firmenwebsite bauen willst und jetzt nicht nur rein das Content Management brauchst, sondern da steckt wirklich Businesslogik dahinter, dann gehst du auf jeden Fall denke ich mal heutzutage entweder in ein Larawell oder ein Symphonie. Also ich glaube, Laminas ist immer noch so ein Ding, das irgendwo rumschwirrt. Aber ehrlicherweise wird glaube ich da jeder Richtung Laminas oder Symphonie gehen. Ist das so Teil von dem PR Problem, ohne jetzt wieder ins Negative abdriften zu wollen. Aber so wie du es gerade beschrieben hast, klang es ja so als du kannst im Prinzip alles mit PAP machen. Da gibt es so hier ein Framework, da ein Tool, was du benutzen kannst. Und dadurch, dass du halt gefühlt alles damit machen kannst und das nicht so diese eine sehr ausgeprägte Nische hat, wo es so super top performen kann, dass es dann halt so nicht diesen Moment gibt, wo die Leute sagen Ja, okay, also wenn ich jetzt was mit REST vielleicht, du willst irgendwie oder Go, du willst Binaries schicken, die irgendwie auf jedem Betriebssystem einfach so laufen, dann nimmst du halt eine von diesen Systemsprachen. Oder du willst irgendwie was bauen, was halt super reaktiv sein soll und kein Cycle verschwendet, dann nimmst du halt irgendwie ein Note oder TypeScript oder keine Ahnung so. Und weil das vielleicht das ist, was PAP so fehlt, so das kann alles. So ist es halt so ein sehr treuer, verlässlicher Traktor gefühlt, der dir irgendwie das alles schon macht, aber halt in keiner dieser Dimensionen so der Ferrari auf der Straße. Ja, ich glaube schon, dass es auch so ist. Die Leute halten sich halt immer sehr schnell an Sachen auf, die eine Sprache nicht kann. Und ohne zu entscheiden, ob das wirklich das ist, was ich jetzt brauche an der Sprache. Und ganz oft muss man ehrlich sagen, das was einem an PAP fehlt, ist im Normalfall nicht das was, was man braucht, sondern man braucht eben den Standard. Ich will irgendwie APIs zur Verfügung stellen, ich will schnell eine Website zusammenbauen, ich will anständiges Templating, vielleicht will ich ein Content Management von der Stange haben. Ich will einfaches Deployment und solche Themen. Ich will irgendwie das entsprechende Tooling drumherum haben und dafür ist es quasi nicht nur völlig in Ordnung. Es ist eine echt gute Programmiersprache. Aber witzigerweise, als du heute deine Frage formuliert hast, habe ich auch bei Sebastian es ausführt hat, gedacht, wieder über dieses Marketing Problem nachgedacht. Und der Tag, den ich hatte dazu war ja auch beim selben Gefühl mit so, kannst ja alles nehmen, kann auch viel und auch wegen WordPress kann man ja nichts sagen. Das ist ja auch das, was macht dein Ding, so macht alles gut. Und das ist ja auch das, was ein bisschen der Marketing spricht, der einem auch von der Sprache dann vielleicht so ein bisschen in den Mund gelegt wird. Also andere Sprachen machen es einem auch einfacher, es zu verkaufen. Ist denn vielleicht auch der Part, dass es komplett Open Source entwickelt wird und nicht wie jetzt bei anderen Sprachen vielleicht eine Firma hintendran steckt, die sich auch überlegen, wie es denn überhaupt, also wie ist unsere Marketingstrategie da hinten dran, sich auch ein Wording überlegen und Entwicklern irgendwie, sage ich mal, diese Pro Contra Argumente ein bisschen mit in den Mund legen, so ist es nicht vielleicht auch in Anführungsstrichen ein Problem, weil vielleicht ist es das noch gar nicht, aber so die, wenn es eine Open Source Community weiterentwickelt wird, wird sich auch niemand wahrscheinlich von den Entwicklern hinsetzen und sagen Okay, über die Marketingstrategie, die müssen wir jetzt noch mal überlegen, wie wir das jetzt irgendwie glatt ziehen, sondern eher gucken, das was wir haben, lass das einfach so gut wie möglich machen. Wir haben ein cooles Ökosystem und lass uns einfach eine Sprache machen, die einfach das tut, was es kann und einfach zu einer guten Sprache zu machen, nicht zu überlegen wie ist unser Marketing? Ehrlicherweise musst du ja sagen, glaube ich nicht, dass es wirklich Marketing für Programmiersprachen ist. Also keine Ahnung. Ich glaube, Microsoft macht vielleicht ein bisschen Marketing für seine Programmiersprachen oder so, aber ansonsten hast du ja nicht irgendwo, wenn du irgendwo auf YouTube unterwegs bist, kommt nicht auf einmal eine Werbung reingeflogen und sagt hier nutzt jetzt Node. Js, ist die beste Programmiersprache und so. Also ich glaube, es ist eher so Marketing technisch ist es schon so ein Thema, dass das PAP früher seine Macken hatte. Völlig völlig. Ja, es ist geschenkt sozusagen. Ja, muss man auch akzeptieren, dass das so war. Ich glaube, marketingtechnisch haben wir eher ein Problem im Sinne von die Entwickler noch mal wieder zu überzeugen, dem Ganzen noch mal eine Chance zu geben und heute noch mal drauf zu gucken. Und sie dann zu überzeugen, wie cool dieses Ökosystem eigentlich ist, weil die schon ihre, wenn du einmal von irgendeiner Programmiersprache oder einem Tool verbrannt wurdest als Entwickler, dann tust du dich natürlich entsprechend schwer, das noch mal zu versuchen. Also da sind wir glaube ich alle ähnlich gestrickt. Ja, das finde ich echt wirklich ein richtig gutes Argument, dass du sagst, der Großteil ist eigentlich, ich glaube, es gibt wenige Programmiersprachen, wo Leute einfach schon Kontakt mit der Sprache hatten auf den einen oder anderen Weg und irgendwie sich schon eine eigene Meinung darüber bilden konnten. Weil ich habe jetzt ja in unserer letzten Folge die Rubi und Rates Dokumentation bei den News als Pick genannt und da wird ja auch irgendwie drüber unterhalten, dass Rubi und Rates sich so ewig lang gegen das vermeintliche Argument wehren musste, dass sie nicht skalieren würden. Das Rubi und Rates skaliert ja nicht so. Und ich sage mal, wenn wir, P&P muss ich halt jetzt gegen Dinge, die vielleicht sogar in dem Fall gestimmt haben, weil Rubi und Rates hat es ja noch nicht mal gestimmt, dass es nicht skaliert, aber einfach gegen solche Argumente kämpfen muss, wo Leute auch schon den Eindruck hatten. Und ich sehe jetzt Rubi und Rates mit ein bisschen Abstand. Ich habe es nie wirklich genutzt und denke so, ja okay, das Geld nicht, ist mir jetzt erst mal egal, weil ich habe es noch nie ausprobiert. Ich habe erst mal Lust, es auszuprobieren. Und bei PAP denke ich, naja, ich habe es ja mal ausprobiert, Spaß gemacht, hat es mir nicht. Und irgendwie jetzt noch mal mich dazu zu bringen, das noch mal zu machen, auch wenn all diese Punkte gar nicht mehr wirklich stimmen, ist auf jeden Fall ein anderes Setting. Und da spielen glaube ich auch zwei Faktoren rein. Also der eine ist der, den wir eben schon gesagt haben, so es hatte so seine Macken früher, aber das hatten halt ganz viele andere Sprachen auch. Also es ist ja nicht so, dass PAP im Verhältnis seiner Zeit sonderlich schlecht war, sondern es war eigentlich genauso gut oder schlecht wie viele andere Sprachen damals auch. Also wenn du vor 25 Jahren Java geschrieben hast, war das bestimmt auch noch mal eine ganz andere Hölle als es irgendwie heute ist oder so was. Wenn du vor 25 Jahren Basic oder Visual Basic geschrieben hast, so 25 Jahre irgendwie so was. Das war auch irgendwie nicht bequem. Aber das bleibt halt einem so das im Kopf, was man selber erlebt hat und nicht die Relation zu den zu den anderen Sachen. Und dann der Punkt, den du auch gesagt hast, Fabi, so mit der Uni. Und viele Leute kommen halt früh in Kontakt damit. Da muss man ja auch sagen, also das gilt für mich auch, weil ich erst mal Kontakt mit PAP hatte, war ich halt auch kein mega geiler Entwickler. Vielleicht bin ich es heute nicht, ist ja egal. Aber das hilft natürlich auch nicht, das Beste aus dieser Sprache rauszuholen. Und dann hast du natürlich so das doppelte Hindernis. Die Leute hatten früh Kontakt damit. Sie wussten selber noch nicht so ganz, wie das mit diesem Entwickeln geht. Die Sprache hat es ihnen nicht gerade leichter gemacht. Und dann fällst du natürlich so in zwei Löcher gleichzeitig rein. Und diesen Eindruck wieder wegzumachen, das ist natürlich, wie Sebastian Zorecht gesagt hat, wahrscheinlich Schwerstarbeit. Ja, und der Punkt mit dem, was wir vorhin schon hatten Erstkontakt halt mit teilweise auch du alleine als Entwickler, dich einfach mal hingesetzt hast und so und Java vielleicht auch eher Sprachen, die dann in einem etwas professionelleren Umfeld oder Kontext irgendwie zumindestens deinen Erstkontakt hattest so und dass du vielleicht schon direkt zumindestens mit Leuten daran gearbeitet hast, die dir auch vielleicht bessere Seiten des Ökosystems und auch der Sprache zeigen konnten und so ein PAP. Also als ich es in der Uni genutzt habe, fand ich es schon einiges cooler und interessanter als ich es beim ersten Mal, als ich meine Website für meinen Counterstrik-Klan damit gebaut habe. So, da war es halt wirklich so, keine Ahnung, ich musste wirklich einfach nur tun, was es tun sollte. Und in der Uni war es so, dass ich dachte, ach, kann ja doch auch Spaß machen. Und dann habe ich es aber einfach nicht weitergeführt, dass man oftmals, glaube ich, viele damit Kontakt hatten in einem Setting, wo die Chance auch gar nicht groß dafür da war, das Ökosystem besser kennenzulernen. Man war wirklich selbst sehr dedikiert, sondern so einfach mal reinwerfen ins kalte Wasser und einfach mal rumprobieren. Ich glaube, die Sprache ist schon über 20 Jahre alt, ist nicht unbedingt, also ist in der Hinsicht nicht ein Vorteil. Also wie gesagt, wenn du vorher damit Kontakt hattest, dann dich nochmal damit zu beschäftigen ist tricky. Zum anderen kam die Sprache auch raus in so einer, so kurz vor dem. Com-boom. Und du musst ehrlich sagen, die Sprache, der Zugang zu dieser Sprache ist so einfach. Das musst du vielleicht auch für ein paar unserer Hörer erklären. Die sind ein bisschen jünger und wissen vielleicht nicht mehr, was der DOTKOM BUM war. Na ja, also als das Internet noch ganz klein war und so und dann irgendwie alle gemeint haben, sie brauchen eine Website. Das beschreibt man heute glaube ich noch als den dort com Boom, als dann jeder ins Internet gerannt ist und sich eine eigene Website hochgezogen hat. So wie jeder braucht einen Instagram Account heute oder jeder braucht einen TikTok-Account. So brauchte man früher dann eben seine eigene Website. Und da der Zugang zu dieser Sprache so einfach ist, wie ich schon gesagt habe, du hast gesagt, das ist bei jedem Hoster vorinstalliert. Es ist ein Klick und es läuft. Es ist in den Distros von den Betriebssystemen dabei. Es ist ein Installer irgendwie, den ich mir runterlade und das funktioniert sozusagen. Der Zugang so einfach war, dann benutzen das halt auch ganz viele Menschen, die eben noch nicht so viel Erfahrung damit haben oder mit Softwareentwicklung im Allgemeinen oder die, die an anderen Sachen gescheitert sind, die ihnen zu kompliziert waren oder die nicht verfügbar waren bei ihrem Hoster. Und dann hast du natürlich auch jede Menge Anwendungen von Menschen, die jetzt keine gelernten Softwareentwickler in dem Sinne sind oder noch super unerfahren. Und wenn dann Menschen mit solcher Software wieder in Kontakt kommen und darin weiterentwickeln sollen, sehen die natürlich auch die schönsten PAP Anwendungen, die man sich vorstellen kann. Das liegt aber nicht daran, dass das ein Problem der Sprache ist, sondern ich glaube, es ist zu sehr großen Teilen auch dem geschuldet, dass der Einstieg so einfach ist und du eben auch sehr viele Leute in dieser Programmiersprache hast, die mit dieser Sprache programmieren lernen. Also, und du siehst diesen Prozess, wie die das tun. Also über eine längere Zeit, wenn man sich Code in alten Geschichten anschaut. Und das ist genau bei mir war es ganz genauso, wie du gesagt hast. Ich habe auch kurz vor der Uni damit angefangen. Und ja, also heute, wenn ich mir die Sachen angucke, die ich damals geschrieben habe, dann würde ich auch sagen, das ist die schlechteste Programmiersprache der Welt. Aber wenn man ehrlich ist, ist es nicht die Programmiersprache, die so schlecht war zu der Zeit, sondern es war eher irgendwie der Mann, der in die Tasten gehauen hat. Aber im Umkehrschluss sorgt es natürlich dafür, dass das Ökosystem und die Leute, die das Ökosystem ausmachen, gefühlt auch sehr divers sind und manchmal auch diverser als bei bei anderen Programmiersprachen. Ja, ja, definitiv. Also ich finde auch und das ist auch etwas, was ich total angenehm empfinde. Es ist so, du hast ein extrem breites Spektrum. Du hast von den sehr grafisch affinen Menschen, die die die coole Agentur-Websiten bauen für Kunden, extremer Frontend Fokus, aber trotzdem P&P im Backend benutzen und auch mittlerweile eben sich da rein gefuchst haben, bis zu den absoluten, sag ich mal, Backend oder Datenbank Geschichten, die da im Hintergrund laufen. Und das macht gerade die Community auch so schön. Also du hast halt ein extrem großes Spektrum an Leuten, die da drin unterwegs sind. Extrem cool. Siehst du auch auf Konferenzen. Also wenn du auf P&P Konferenzen unterwegs bist, hast du auch von Agenturen über über kleinen Mittelstand, über über anfängliches Enterprise sage ich mal, bis komplettes Enterprise hast du hast du da wirklich alles, alles vertreten und das ist schon ein extrem cooler Austausch. Und vorhin hast du ja so ein bisschen, wenn wir jetzt mal einen Ausblick in die Zukunft machen, du hast so ein bisschen in Anführungsstrichen belächelt, irgendwie dabei gelacht, als du gesagt hast, dass die neuen Features, was entschieden wird, was reinkommt, auch aus der Community getätigt werden. Und jetzt auch in Zusammenhang mit das du gemeint hast, es gibt die PAP Foundation. Wie ist denn, wenn man so ein bisschen in die Zukunft für PAP blickt, so wie siehst du die Entwicklung? Also vielleicht erkläre uns gerne noch mal, warum du so ein bisschen belächelt hast, dass es aus der Community kommt das, was an neuen Features entwickelt wird. Und wie siehst du die Entwicklung von PAP in der Zukunft? Warum ich so ein bisschen geschmunzelt habe, war weil natürlich es gibt natürlich Core Entwickler, die zum Core von von PAP gehören, sage ich jetzt mal. Also ich kann grundsätzlich, also ich gehöre da nicht dazu. Nur das klarzustellen, keine Hate Mail an mich. Ich könnte jetzt natürlich, ich kann ein Feature vorschlagen und ich kann das auch implementieren, wenn ich das vorschlage. Aber das heißt nicht, dass es angenommen wird, sondern das machen immer noch die Core Entwickler. Das heißt, der PAP Core entscheidet quasi, in welche Richtung die Programmiersprache sich weiterentwickelt. Und zu diesem Core gehören natürlich jetzt auch die Foundation. Aber es ist ein Voting Prozess. Das heißt, der Core votet über jedes Feature und es gibt klare Regeln, wann ein Feature als angenommen gilt und wann nicht, wann es quasi abgelehnt wird. Und wie haben sich die Core Entwickler von PAP definiert? Also klar, in der Foundation gibt es jetzt sechs Parttime Entwickler, die da angestellt sind. Aber wie hat sich vorher, also natürlich irgendwie nach wahrscheinlich Menge an Commitments, aber wie wurde man Core Entwickler von PAP? Weißt du das? Also genau kann ich es dir nicht sagen. Aber es hat natürlich einfach damit was zu tun gehabt, wie viel Engagement du da reingesteckt hast und wie lange du dann auch irgendwie da immer mal wieder Engagement reingesteckt hast. Irgendwann ist dann quasi okay, das ist jetzt das X-te Feature und es sieht nicht so aus, als würdest du aufhören, dann komm doch bitte zum zum Chor dazu und jetzt hast du auch quasi ein Voting Recht sozusagen. Aber genau könnte ich es dir nicht sagen. Das Voting Recht haben nur die Core Entwickler. Okay. Ich glaube, ich habe kürzlich irgendwas gesehen, dass sie irgendwann anfangen wollten, NFCs auch für die Community Voten zu lassen, mal so ein Gefühl zu bekommen, wie die Community das sieht. Ich bin aber nicht auf dem letzten Stand, ob das schon umgesetzt ist oder ob das wirklich geplant ist. Kann sein. Wie gesagt, ich habe es nur irgendwie mal so halb mitbekommen. Da gibt es jetzt ein Portal für, aber ich glaube, es ist noch kein RFC wirklich da drüber schon gegangen. Aber ja, das fängt jetzt so langsam an. Von daher wird es Community mäßiger. Wobei man natürlich am Ende immer noch sagen muss, also für das RFC, was du irgendwie promoten willst als Änderung, dann hast du ja meistens schon eine Beispiel Implementierung dabei. Und dadurch, dass PAP ja keine self-hosted Sprache ist, sondern PAP ja quasi in C geschrieben ist, musst du das ja zumindest auch schon mal können. Und allein das legt ja schon mal so eine organische Latte an, sag ich mal, wer überhaupt da mitarbeiten kann oder nicht. Es gibt ja Sprachen wie SWIFT zum Beispiel, die sind self-hosted, du kannst SWIFT in SWift entwickeln und kannst quasi dann mit dem Wissen, was du schon hast, gleich direkt aktiv werden. Das ist da halt nicht so der Fall. Also du musst schon ein bisschen mehr mitbringen als nur ein cooler PAP Entwickler zu sein. Wenn ich jetzt 30 Jahre PAP entwickelt habe und alle Frameworks in und auswendig kann, so kann ich noch lange kein Core Entwickler sein. Oder zumindest nicht automatisch so. Das finden wir auch nochmal sehr gut als Kontext. Ja, es ist nicht so ein Selbstläufer. Also C ist halt doch immer noch wieder was anderes. Ja, also insbesondere wenn du halt von PAP kommst. Das ist ja dann auch noch mal eine krass andere Welt. Auf einmal musst du dich mit Pointern und Memory und sowas irgendwie alles beschäftigen, was PAP so jahrzehntelang für dich weg abstrahiert hat. Und dann willst du da was machen und zack geht das irgendwie in eine ganz andere Welt mal rein. Ja, ich glaube, das ist ja die große Hürde, glaube ich einfach auch. Also wirklich RFC aufzumachen. Aber wenn wir schon über Änderungen und Neuerungen sprechen, lass uns vielleicht einmal ganz kurz darüber sprechen, was PAP 8.3 jetzt alles mitbringen wird. Also wir müssen jetzt nicht das ganze Change Log irgendwie durchgehen. Vielleicht so ein, zwei, drei Highlights, die für dich irgendwie besonders interessant, wichtig, Breaking, wie auch immer bei dem Release sind. Und da vielleicht noch mal ganz kurz erwähnt für alle da draußen. Ja, PAP hat Breaking Changes auch in acht drei. So semantische Versionierung ist da bisher nur so teilweise angekommen. Also irgendwie im Ökosystem und in der Paket Management super gut. Aber PAP selbst hat so ein etwas anderes Verständnis davon. Ja, also genau für PAP ist glaube ich quasi jedes Jahr es ist, man wird es nicht Major Version nennen, aber es ist eben quasi eine Version, die auf jeden Fall Breaking Changes hat. Das heißt, mit jeder Version, die man eigentlich bekommt, sind eigentlich auch immer diese Deprications mit drin. Oder sagen wir mal, die Chancen sind da, dass du sie bekommst. Und dann, wenn du dann auf die nächste willst, musst du das quasi dann schon abgestellt haben. Features für acht drei. Es ist jetzt nicht so ein super riesen Release, würde ich mal sagen. Ich glaube, was viel hilft, gerade im API Kontext, ist eine Geschichte. Es gibt jetzt eine Json Validate Funktion. Vorher musstest du, Json zu validieren, immer das komplette Json quasi in den Ramm laden, also wirklich pausen und gucken, ob der Pauser einen Fehler verursacht hat. Und das geht jetzt deutlich schneller oder bzw. Memory schonender. Von daher ist das glaube ich was, was gerade irgendwie im API Kontext sicherlich vielleicht auch wirklich einen Performance Unterschied machen kann. Ansonsten... Ich meine, also Jan, erinnere ich mich falsch, er war nicht bei unserer Probeaufnahme mit dir für unsere erste Podcastfolge war nicht eines der Features aus PAP3. Das war das Feature mit den negativen Indizes in den Arrays. Das war doch, war doch, haben wir niemals releast. Aber das war doch, glaube ich, das Feature, was du damals. Vorgestellt hast, oder? Exakt. Exakt. Das war die erste unveröffentlichte Newsfolge, die wir aufgenommen haben. Komm, dann erzähl das doch noch mal so, dann können wir das noch mal wieder auferleben lassen in deiner ersten geheimen Folge, was die nie releast wurde. Was hat es denn mit den negativen Indizes auf sich? Sebastian, willst du oder soll ich. Das erzählen? Nee, nee, mach du ruhig. Die bequemen Features. Also wenn du ein Array hast und du hast den mit Indizes gefüllt, dann hast du an erster Stelle ist FU, an zweiter Stelle ist Bar und du fügst ein neues Element dazu FU Bar, dann ist anzunehmen, dass es an der dritten Stelle irgendwie kommt. So weit, so gut. Da sind es, glaube ich, auch alle Sprachen da draußen irgendwie einig. Wenn du jetzt aus irgendeinem Grund angefangen hast FU bei -5 und Bar bei -4 zu positionieren. Und dann ist eben die Frage Was passiert, wenn du FU Bar einfügst? An welcher Stelle in deinem Array wird das jetzt irgendwie platziert? Und Sebastian, willst du es auflösen? Also aktuell ist es dann an Position null. Ja, weil Position null noch nicht belegt ist und das ja der erste, der erste Index ist, den man quasi automatisch vergibt. Das heißt, man hat dann die Indexe minus 5 minus 4 und 0 in der neuen Version, also in PAP 83 ist es jetzt so, dass man ein minus 5, minus 4 und minus 3 bekommt. Also konsequentes Weiterzählen jetzt neu in PAP 83. Ja. Sehr frischig natürlich. Aber ich kann mir schon so ein paar vor. Wir haben auch damals in der Newsfolge so ein bisschen drüber gesprochen. Wenn du so halt mit mit räumlichen Koordinaten oder sowas arbeiten willst, wo du halt öfter mal ins Negative rutschst, da kann das schon den einen oder anderen Unterschied machen. Aber es ist wahrscheinlich ein Breaking Change, der weiß es nicht bei 3% der Entwickler aufschlagen wird, bei denen wahrscheinlich ziemlich hart, aber die anderen einfach überhaupt nicht tangieren wird. Ich hoffe auch. Aber mir fehlt auch manchmal einfach die Vorstellungskraft, was Menschen so programmieren. Also ich würde mich immer wundern, warum, also wieso man sich da drauf verlässt, dass wenn ich -5 reinschreibe, dass da null rauskommt beim anderen. Ich kann mir immer nur so vorstellen, dass die Leute irgendwie -5 reingeschrieben haben oder so und dann schreiben sie ein neues Element rein und dann haben sie irgendwann gelernt, ach, das neue ist ja auf null, dann benutze ich jetzt null und dann fliegt einem das natürlich so ein bisschen die Ohren. Aber ansonsten wie gesagt, mir fehlt immer so ein bisschen die Fantasie, wo das wirklich zu Problemen führt. Vielleicht willst du ein Array vorbefüllen mit Elementen, die auf alle Fälle vor dem sein sollen, was du später einfügst. Also keine Ahnung. Das ist. Alles sehr. Ja, und wenn du noch die, wenn du das, wenn du dich darauf verlassen hast, wenn du -3 einfügst, dass du noch Platz hast für -2 und -1, damit du dann noch quasi was dazwischen schieben kannst, wenn es sein muss. Ja, dann hast du natürlich jetzt ein bisschen die A-Karte gezogen. Ja, es lassen sich schon Anwendungsfälle konstruieren, so ist das nicht. Ich habe mal so ein bisschen geschaut, ob ich irgendwie in irgendeinem meiner Projekte Probleme sehe. Nö. Also es ist wirklich nirgendwo auch nur ansatzweise der Fall. Von daher bin ich noch mal mit einem blauen Auge davongekommen. Jetzt hast du ja auch schon gesagt, dass das PAP 8.3 Release so ein bisschen Slow und Steady eher ist von dem, was es so mitbringt. Und ich habe so den Eindruck und da wird mich dein Tag interessieren, diese höheren Mineral Releases bei PAP 8.3, 7.3, 5.3 damals auch noch. Die sind eigentlich immer nur noch aufbauend auf dem, was mit dem Major Release so kam. Also wir haben mit PAP 7 irgendwie viel starke Typisierung gesehen. So 7.1, 7.2, 7.3 haben das halt immer noch so ein bisschen ausgebaut, aber da hat an keiner Stelle so das Rad da neu erfunden. Und bei bei PAP 8 hatte ich so ein bisschen den Eindruck, na ja, PAP 8 so als generelles, ich sage mal Performance und Convenience Release für PAP, schleift da einfach viele Kanten ab, die noch so ein bisschen bisschen unrund waren. Und da fügt sich 8.3 dann einfach auch so ein. Also wenn man sich so anguckt, so was wie anonyme Read-only Klassen sind halt eine Fortführung von der Read- Only Capability. Overwrit Attribute sind auch irgendwie so ein Teil von naja, wir haben uns Vererbung und Developer Experience irgendwie nochmal Gedanken gemacht. Also alles im Prinzip so in dasselbe Hornblasen wie PAP 8. Aber so das ganze wirklich neue Zeug wird so ein bisschen vorgehalten für PAP 9 und die ganzen dort Releases, die halt so danach dann noch kommen. Ja, ich glaube, das macht ja auch total Sinn. Also dass quasi du du quasi bei einer Major Version, also wie wir es so nennen wollen, quasi bei einem 8.0, dass du da die wirklich neuen Features raushaust, dass du da wirklich hingehst und die großen Änderungen an der Engine, die gemacht werden, dass du die da einbaust und dass du dann die nächsten Versionen nutzt, noch Sachen auszubügeln. Also wie gesagt, mit den gerade Typisierung haben wir immer noch wieder Stellen, wo wir merken Ah, okay, aber das geht ja noch gar nicht. Diese Version. Es gibt in PAP eben viel zu viele Wege nach Rom manchmal. Und jeden Weg nach Rom dann abzudecken, das dauert manchmal ein bisschen. Und diese dort Releases, wie du sie nennst, die werden dann genau dafür benutzt, dann wirklich neue Features in die letzte kleine Ecke der existierenden Code Basis und der existierenden Features noch noch wieder mit reinzunehmen. Also wie du jetzt gesagt hast, es gibt Read- Only Geschichten, aber die gibt es schon eine Weile. Aber als wenn du eine anonyme Klasse hattest oder die anonym inline definiert hast, dann konntest du die nicht Read- Only machen. Und das sind so Sachen. Ah, okay, das ging ja auch noch. Lass es uns da jetzt auch noch irgendwie gerade einbauen. Von daher ist es auch gut, dass sie dann eben bei den bei den dort Releases jetzt nicht jedes Mal die Welt neu erfinden. Ich meine, wir würden uns alle wünschen, dass sie mit jedem Release die Performance 100 Prozent steigern. Da sind wir ein bisschen verwöhnt, irgendwie die letzten Jahre mit P&P. Aber das ist ja erstens utopisch und zweitens ist es ja, wir entwickeln ja auch selber Software. Von daher verstehen wir ja, wie das funktioniert. Und ich habe keine Ahnung, wie weit sie es dieses Mal, wie weit sie die dort Releases fahren. Ich bin nicht auf dem Stand, ob nächstes Jahr schon 9 kommt oder in zwei. Von daher. Aber ich bin ganz happy mit der Art, wie sie es machen. Gut, dann haben wir jetzt auch schon über die Stunde hier rum und wir wollen ja noch zu unserer anderen Kategorie kommen. Aber bevor wir dazu kommen, eine Frage: Fabi, willst du noch irgendwas zu PAP wissen? Also ich sage mal so, ich finde... Also irgendwie wie immer, wenn wir uns über Programmiersprachen unterhalten, denke ich immer danach, ist PAP einfach eine genauso valide als... Also mein Eindruck, wie gesagt, ich fang an mit diesem Podcast und habe gesagt, so PAP, mäh und Lara wäre irgendwie schon cool. Von daher kann ich irgendwie nicht so ganz falsch liegen mit... Also muss ich doch ziemlich falsch liegen mit meiner PAP-Wahrnehmung und so und denke jetzt im Nachgang des Podcasts, okay, auf jeden Fall liege ich falsch über PAP, weil warum sollte ich darüber mehr denken, wenn es so weit eingesetzt ist und so wie Sebastian es auch gezeigt hat, warum diese Argumente heutzutage nicht mehr stimmen. Ich denke weiterhin, dass PAP irgendwie ein Imageproblem hat so und ich hoffe, dass wir ein bisschen dazu beitragen konnten, dieses Image Problem zu beheben und denke jetzt eigentlich nur, ich denke jetzt weiterhin über Lara wäre auch cool und PAP denke ich ja, ist einfach eine Alternative. Das denke ich darüber. Aber deswegen eigentlich fehlt mir erst mal nichts. Ich würde eher vom Sebastian interessieren, ob er noch irgendwas denkt, das hätten wir mal über PAP fragen sollen, noch mein jetziges Image von PAP ist einfach eine valide Alternative hin zu, dass es der heißeste Scheiß auf dem Planeten noch verändert. Aber wahrscheinlich hat er es uns schon erzählt, wenn das der Fall wäre. Aber was haben wir nicht gefragt, was wir hätten fragen sollen? Ich glaube, wir haben alles ganz, ganz gut abgedeckt irgendwie. Und jetzt, wo du sagst, wir wollen gar nicht mehr der heißeste Scheiß sein, sondern es will der Scheiß sein, der einfach funktioniert und läuft, indem man irgendwie vorwärts kommt und ein paar Sachen, für die es gebaut ist, machen kann. Und das sind relativ viele. Ich glaube, als ich das letzte Mal auf einer Usergruppe war, wo du einen Vortrag gehalten hast, mit irgendwie TypeScript kannst du den heißen Scheiß machen und mit PAP kannst du ordentlich Geld verdienen, weil da halt einfach Software gebaut wird. Also jetzt nicht, dass du damit unglaublich reich wirst, aber da ist einfach, da ist kontinuierlich was zu tun, da ist halt viel Business, was irgendwie damit läuft. Da gibt es halt irgendwie immer was zu erledigen und das auch irgendwie in einem Kontext, wo halt gesunde, ausgereifte Business Modelle umgesetzt werden. Ja, ja, ja, genau auf jeden Fall. Also ich sage immer aus Spaß, denn das Dollar Zeichen werden wir hoffentlich nicht los, weil das steht ja dafür, dass wir Geld verdienen können mit mit BAP. Und es ist natürlich dann heißt es auch immer, mit Cowork kann man auch Geld verdienen, wenn man das heute entwickeln kann. Das kommt dann immer so ein bisschen ans Eis. Die Frage ist wie lange noch da wahrscheinlich. Genau. Ja, aber ich glaube, man ist jetzt, jetzt Spaß ein bisschen beiseite, aber es ist eine Programmiersprache, die wird nicht verschwinden. Also alleine das, was momentan damit umgesetzt ist, das zu Maintenance, weiterzuentwickeln. Und vor allem ich finde auch, dass der Unterschied ist auch damit kannst du coolen heißen Scheiß umsetzen. Ich meine, ihr seid bei Check24, da würden viele gerne dran mitentwickeln, weil ich weiß noch mein Vater, der ist im SAP Umfeld unterwegs und sagt immer auch mit ABAP kann man auch sehr gut Geld verdienen. Aber irgendwie da sehe ich noch nicht den Part, wie ich mit ABAP den heißen Scheiß entwickeln kann. Also genau dieses mit Dollar Zeichen sagen können können können noch andere Programmiersprachen sagen. Aber ich glaube mit PAP kann man eben auch cool und aktuell und mit coolen Technologien entwickeln. Ja, definitiv. Also man kann wirklich coole Produkte bauen. Punkt. Also. Ja, ich bin ja nicht so ein Freund vom Self Plug. Aber wie gesagt, ich finde unsere Produkte, also jetzt unsere Check24 Produkte, ich finde die ziemlich gut. Ich nutze die gerne, ich nutze die selber. Ich bin Kunde seit quasi Tag 2 und sehe auch keinen Grund, das in vielen Bereichen anders zu machen. Von daher ja, also man kann mit P&P schon richtig coolen Scheiß bauen. Wunderbar. Speaking of coole ProdukteWir haben noch Pics of the Day. Und ich schaue fragend in die Runde, ob jemand anfangen möchte. Wenn niemand anfängt, dann fang ich einfach an. Ich habe nämlich ein PAP Pick dabei, und zwar einen, den man vielleicht ein bisschen erklären muss. Wir sind ja hier alle, die wir hier im Studio sitzen, so Kinder der, ich sage mal 80er Jahre, ohne jetzt irgendwie jemandem hoffentlich zu nahe treten zu wollen. Und früher, als Computer noch Festplatten hatten, für die Jüngeren da draußen, das sind so drehende mechanische Scheiben, die früher in den Computern drin waren, wo wir unsere Daten drauf gespeichert haben, die musste man früher ab und zu defragmentieren. Das heißt Daten auf der Platte, die zusammen liegen, zusammenschieben, damit wir irgendwie schön schnell Daten auslesen und überschreiben können. So, während man seinen Computer so defragmentiert hat oder genauer gesagt seine Festplatte defragmentiert hat, hat insbesondere Windows einem immer so ein schönes Diffragmentation UI angezeigt, wo man schön so auf der Platten Map gesehen hat. Okay, ich schiebe jetzt Dateien von hier nach hier und dann kopiere ich was von A nach B. Und das waren ganz viele blinkende Kästchen, die man so drei vier Stunden angeguckt hat. Drei vier Stunden dauert für mein Pick nicht, aber ich bin vor zwei Wochen über ein PAP Library gestoßen, das dir, wenn du Unit Tests ausführst, im Prinzip genau diese Retro Ansicht generiert für deine Unit Tests, wo du im Prinzip so eine Matrix angezeigt kriegst und dann werden ab und zu so Kästchen grün, wenn ein Test läuft oder rot, wenn sie nicht laufen, so blinkt es dann da irgendwie so ein paar Minuten lang vor dir irgendwie auf und ab. Und das fand ich zum einen sehr cool, dass sich jemand die Zeit dafür gemacht hat. Wir verlinken das ja dann auch noch mal. Und zum anderen war es halt für mich so ein richtiges Retro Gefühl, weil ich habe früher, ich weiß nicht wie viele Stunden meines Lebens, ich vor dem Monitor gesessen habe, dem Defrager irgendwie zuzugucken, wie er meine Platte sortiert. Und jetzt damit die Unit Tests irgendwie zu visualisieren, fand ich einfach nur mega cool. So, das ist mein Pick of the Day hier. Ich brauche das Ding. Ich bin ein Kind der 90er, aber ich kann defragmentieren auch noch. Also es war auch bei mir. Noch ein Ding. Dann habe ich dich hoffentlich nicht zu sehr älter gemacht eben gerade. Ich bezahle dir die paar Jährchen. Ja, komm, dann bring ich mein Pick of the Day auch noch mit. Und zwar für diejenigen, die es ist ja ein Produkt, was durchaus viel eingesetzt wird und wir bei LOTAM für komplett unsere Analytics Suite eigentlich nutzen, ist Big Query. Also zum Beispiel wenn ihr Firefox oder Google Analytics oder ähnliches nutzt, landen ja auch die Rohdaten komplett in Big Query. Eben auch bei uns der Fall. Wir nutzen verschiedenste BI Tools da oben drauf. Aber ich. Muss sagen, ich habe in dem Fall wieder Excel bzw. Google Sheets lieben gelernt, weil gerade die, die irgendwie dann Hand-on unterwegs sind, wir als Entwickler, kennen es ja ganz gut mit SQL aus, wenn auch vielleicht nicht mit den ganzen BI Tools. Und in Big Query kann man ja SQL Syntax schreiben, ein bisschen spezifisch für Big Query, aber sehr nah an der grundsätzlichen SQL Syntax. Und Big Query bietet einem coole Exportmöglichkeiten an. Eine Exportmöglichkeit der Daten davon ist Google Sheets. Das heißt, man hat dann die Rohdaten Quelle in Big Query und kann mit Pivot Tabellen oder ähnlichem echt richtig coole Auswertungen machen, wenn man mal wirklich so ein Unique Case sich irgendwie anschauen will. Das heißt, wenn ihr mal so ein bisschen in Analytics rein reindeiben wollt und nicht immer euren BI Ansprechpartner, wo auch immer der sitzt in eurem Team oder auch nicht oder eure bestehenden Tools nutzen wollt, finde ich echt dann habe ich Google Sheets crazy, was man für coole Dinge damit irgendwie tun kann und auch Google Sheets sich echt mittlerweile coole Visualisierungsoptionen auch mitbringt, auch so coole Time Table Optionen, wenn ich irgendwie Verlaufe von Tests mir irgendwie anschauen will, wie so eine Art großes Time Table Diagramm sehen kann. Und ich finde diese Integration super mächtig dafür, dass man einfach noch mal ein bisschen die Daten sich anders visualisieren kann. Also alle Exportmöglichkeiten von Big Queries. Noch mal wirklich ein cooles Pick, was ich mittlerweile echt viel einsetze und gepaart damit, dass man einfach auch mittlerweile mit ChatGPT sich super einfach diese Queries auch schreiben lassen kann. Also du kannst mit Big Query einfach sagen, hier, das will ich analysieren, gib mir mal eine Big Query SQL Statement dafür und dann in Google Sheets importieren. Ist irgendwie ein cooler Flow, den ich echt häufig in letzter Zeit nutze. Da muss ich mal ganz doof nachfragen. Also wie viel Daten kann man denn in so ein Google Sheet reinschmeißen, bevor es nicht mehr funktioniert? Na ja, du würdest also du wirfst nicht die komplette Big Query Tabelle rein, sondern ja im Endeffekt das Ergebnis deines SQL Statements, also ist live mit der Datenbank verbunden. Ah, ist mehr so wie so eine Präparate View. Oder sowas? Genau. Also du hast dann, du hast dann wirklich eine dynamische Datenquelle. Das ist ein Sheet, die ist verbunden mit, also da ist ein Big Query Statement hinterlegt und du kriegst sozusagen automatisch kannst du die Query auch laufen lassen aus Google Sheets heraus. So, und siehst sozusagen die Antwort des SQL Statements, den Output und hast den in der Tabelle drin. Und auf diesem Output kannst du interagieren mit Pivot, mit was auch immer, was für Funktion auch immer du da nutzen möchtest. Und das ist wirklich cool. Cool. Sebastian. Ja, wo wir schon bei Shamless Self Plug sind. Erstens ganz kurz. Mich hast du jünger gemacht. Von daher danke. 80er macht mich deutlich jünger. Von daher alles gut. Ich hatte dich gerade so eingeschätzt. Zum Pick of the Day. Ich entwickle seit einer ganzen Weile eine PAP Library, die sich Capital Hook nennt. Das ist ein Git Hook Manager, der so ein grundsätzliches kleines Problem mit GitHooks löst, nämlich dass man GitHooks nicht ins Repository committen kann direkt. Also das Problem mit GitHooks oder das Problem, dass die kleine Problematik dahinter ist, dass man nicht in seinen, dass man GitHooks nicht pushen kann, zumindest nicht direkt im Hook Verzeichnis. Das hat Security Releasons, weil wenn ich ein Repository klone und da würden direkt Hooks ausgeführt, irgendwie in meiner User Berechtigung, nur weil ich ein Repository geklont habe, das wäre eher doof. Von daher muss man immer selbstständig hingehen und sich seine Hooks irgendwie selber installieren. Und das ist quasi das, was was was Capital Hook für einen erledigt. Es hat quasi, es hat noch so ein paar andere coole Features im Sinne von du kannst jetzt die Hooks in der Json Konfiguration verwalten und so ein paar nette Features benutzen. Das ist quasi als PAP Library gibt es das schon ein paar Jährchen. Es ist relativ erwachsen, würde ich sagen, als als Projekt. Seit ein paar Wochen schreibe ich quasi einen Go Port, weil eben genau dieses Thema kam. Ja, aber wieso brauche ich denn PAP? Ich will das einfach für mein, weiß ich nicht, mein SWIFT Projekt benutzen. Und dafür, ich meine, man kann das im Docker Container ausführen, aber die Leute zu überreden, ein PAP Tool zu benutzen, was sie im Docker Container ausführen, damit sie SWIFT entwickeln können, ist immer ein bisschen anstrengend. Also schreibe ich momentan einen Go-Port. Der ist quasi momentan noch in Beta, funktioniert aber schon weitestgehend. Also die Dokumentation ist online und alles. Das heißt, man kann den auch einfach per Brue installieren auf Mac oder sich für jede beliebige Plattform das Binnary runterladen. Und dann kann man quasi dieselbe Funktionalität, die PAP Entwickler schon lange genießen, kann man jetzt quasi in jeder anderen beliebigen Programmiersprache auf seinem System auch benutzen. Ich möchte einmal anmerken, dass Capital Hook als Name garantiert kein Branding Problem hat. Ich hoffe nicht. Also mal sehen. Auf jeden Fall war auch das erste, was ich gedacht habe, der ist sehr gut gewählt. Also wenn es dann mal den Go-Pod gibt, dann auch für uns. Für mich. Wie gesagt, BetafünIch bin gerade aktuell. Ich glaube, ich mache noch eine und eine davor und dann gibt es wahrscheinlich eins null. Ich denke mal so zwei Wochen oder so. Wunderbar. Dann tausend Dank für die Pics. Tausend Dank für die Zeit Sebastian. Tausend Dank für die Zeit Fabi. Und wir sprechen uns dann in zwei Wochen wieder. Im nächsten Deep Dive. Sehr gerne. Bis dann. Ciao, Ciao. Ciao. Ciao. Bis dann. Ciao.