 Ich möchte euch willkommen heißen zu meinem Talk. Ich bitte euch nachsichtig zu sein, es ist mein erster Talk. Ich bin teilweise auch ein nervöser Vortragender. Ich hoffe, das legt sich mit der Zeit. Mein Name ist Ralf Alexander Barrett. Ich bin 35 Jahre alt, bin in die IT hineingewachsen. Ich habe nicht wirklich studiert. Bin Softwareentwickler bei der AVList GSMBH in Österreich Graz und mache das Ganze aus Leidenschaft. Hier geht es heute um, das schaut jetzt ein bisschen abstrakt aus, um Kausalität in nicht-linearen Systemen. Was das konkret bedeutet, das kommt noch. Ich werde ein paar von euch bitten, auf die Bühne zu kommen, weil wir hier ein kleiner Spielchen zur Veranschaulichung nicht-linearer Systeme durchführen werden, hoffentlich. Ich bräuchte vier Personen, mindestens bis zu 16, bitte. Ich fürchte, mit den Inlineskeits geht es nicht und du brauchst deine Füße. Mindestens bis zu 16. In dem Fall es geht beim heutigen Talk auch weniger um etwas technischer, sondern es geht darum, wie denke ich, nicht-lineare Systeme und wo bieten sie mir einen Vorteil. Es soll auch mehr eine Diskussion sein und kein Frontalvortrag. Ich gebe euch jetzt ein paar Sachen, also fünf Leute. Dann kriegt jeder von euch einmal einen Informationshalter. Dieser hält eine Information von der Art eines Bits in dem Fall. Einfach ein Schalter, den man ein- und ausschalten kann. Was ist die Information? Wenn ich euch betrachte, sehe ich viele Informationen, fünf genau und jede dieser Informationen besteht aus vielen anderen Informationen, Aspekten. Also ein Mensch hat zum Beispiel Augen, Füße, Hände und irgendwo mitten drinnen, in dem Fall im Schalter, den ihr alle habt, ist ein Atomarer-Wert drinnen, eben ein Bulscher-Wert, ein Aus. Ja, gut. Nun, Information allein ist ziemlich wertlos. Wenn keine Wirkung stattfindet, verändert sich Information nicht. Das heißt, Funktionalität ist prinzipiell einmal die Änderung von Information. Und wie ändert sich diese Information? Nun bereiten wir dieser Spiel vor. Ich werde euch so ein Sticker geben und dieser Sticker ist für euch ein Signal, auf das hin ihr den Schalter umlegt. Also wenn ich jetzt ein anderer Mitspieler bin und ihr den entgegen halte, nimmst du ihn. Wir müssen ihn beide angreifen und legst den Schalter um, falls dieser Ball bei dir ist. Okay, wenn es kommen später mehrere Zettel, wenn du und du zum Beispiel beide gleichzeitig ihm ein Zettel geben wollt, Sticker, Entschuldigung, dann muss einer von euch zweier klarerweise warten, weil jeder kann nur einen gleichzeitig behandeln. So, es wird bei dem Spiel, das Spiel ist durch Klopfen geregelt. Wenn ich einmal klopfe, also es ist getaktet. Eine Wirkung ist, ich nehme den Zettel, lege den Schalter um und halte den Zettel irgendwie im anderen entgegen. Und das jedes Mal, wenn ein Klopfen kommt. Wenn ich zweimal klopfe, heißt das Pause. Und ja, wir sind dann eigentlich schon fast so weit. Wir haben hier noch Möglichkeiten und Wahrscheinlichkeiten. Ihr seid jetzt fünf Personen. Geht es ein bisschen mehr in einen Bolg? Ich gebe dir den dann später wieder, so dass ihr, dass jeder jeden den Sticker geben kann. So, okay, wenn wir uns jetzt die Möglichkeiten anschauen, wenn du jetzt den Sticker hast, wie viele Möglichkeiten hast du den Sticker weiter zu geben? Okay, das heißt die Wahrscheinlichkeit, dass du den Sticker ihm gibst, 25 Prozent. Gut, so, dann kommen wir zum gesamten System. Das System besteht also aus Information. In dem Fall habt ihr zwei Informationen, nämlich habe ich den Ball oder nicht. Und ist der Schalter ein oder aus? So, dann fangen wir an. Also schalten nur dann umlegen, wenn man den Ball hat, ansonsten den Sticker einfach gleich weitergeben. Ah ja, und der Ball wird auch weitergegeben an eine beliebige Person, sobald drei Takte vorbei sind. Ich hoffe, das ist nicht zu kompliziert. Machen wir einen Testlauf. Okay, es ist eigentlich nicht wirklich wichtig. Gut, ich schmeiß den Ball einfach mal rein. Du hast jetzt initial den Sticker. Okay, gehen wir den Ball einfach jemandem anderen einfach draufsteigen. Okay, gut, dann halte den Zettel irgendwie im Hin und dann klopfen wir. Okay, du hast keinen Ball, also keinen Schalter umgelegt. Nächstes Mal klopfen. Okay, okay, nächstes Mal klopfen. Okay, nächstes Mal klopfen. Gut, wir haben es heraus. Jetzt machen wir das Ganze, also drei Takte hast du den Ball gehabt, natürlich weitergeben. Jetzt machen wir das Ganze ein bisschen komplizierter. Wenn du den Ball und den Zettel im gleichen Zug bekommst, dann hast du den Ball. Dann musst du ihn umlegen. Ganz ehrlich, so weit habe ich bei dem Spiel nicht gedacht. Aber ich sage mal, wenn du den Ball zu dem Zeitpunkt, wo du den Zettel in die Hand bekommst, wenn der unter deinen Fuss ist, dann legst du ihn um. Es ist auch nicht so wirklich wichtig, es geht eher darum, etwas zu zeigen. So, geben wir noch ein, zwei Bälle dazu. Nein, zwei kann man nicht haben. Also wenn du zum Beispiel den Ball ihm geben willst und er hat schon einen Ball, dann musst du warten, bis er seinen Ball los ist. Die Änderungen sind komplett irrelevant. Also sobald ich irgendwie das Ball ist, leg ich es um in einen Zug. Genau, genau. Wenn du den Zettel kriegst. Ich habe nicht wirklich einen Kriege, wenn ich ihn habe. Wenn du den Ball hast und den Zettel kriegst. Natürlich, wenn du den nächsten Zettel bekommst, dann auch. Dann muss man den Zettel weiter geben und den Ball. Nein, Ball und Zettel sind völlig unabhängig voneinander. Also muss sich selber weitergeben. Ich muss jetzt ganz ehrlich sagen, ich bin überfragt. Fangen wir einfach mal an. Aber ich glaube im Eifer des Gefechts kommst du gar nicht auf die Idee. So, wir haben hier noch einen Sticker, nehmt den auch. Okay, dann probieren wir das einmal. Du solltest den Ball drei mal halten. Okay, so, geht's? Okay, nächt das. So, jetzt noch einmal. Aber okay, ich sehe schon, dass das mit dem Ball, mit den Bällen und den Zetteln wird ein bisschen kompliziert. Worauf ich hinauswollte, ist, ihr habt zwei Aspekte, die unabhängig voneinander etwas tun können. Also ihr könnt gleichzeitig Zettel weitergeben beziehungsweise Schalter umlegen und den Ball weitergeben. Das hängt miteinander nicht wirklich zusammen. Darauf wollte ich hinaus, wir könnten den Ball jetzt einfach mal lassen. Dann ist es einfacher und wir legen immer den Schalter um. Das geht dann auch schneller. Okay, okay, ich mach nichts. Es geht nicht darum. Nein, du kannst keine zwei Zettel auf einmal bekommen. Nein, weil du keine zwei Zettel bekommen. Ja, aber derjenige, der andere muss einfach warten. Nein, warten ist besser. Okay, die Frage ist jetzt, was ist hier passiert? Erstens einmal, wie viele Dinge sind auf einmal passiert in diesem Spiel? Drei Zettel, gleichzeitig gewechselt und zusätzlich sind möglich von ein oder mehrere. Völlig ausreichend. Also mehrere. Es ist darum gegangen, in dem System passieren Dinge nebeneinander. Das heißt, es ist nicht klassisch sequenziell, wie wir Software-Entwickler die Dinge üblicherweise angehen. Wie hat sich das ganze System entwickelt? Hat er sich überhaupt entwickelt? Hat eine Entwicklung des Systems stattgefunden? Ja, aber welches System kehrt in den Anfangszustand zurück? Der Prozess, der die Änderung macht, beginnt direkt wieder von vorne. Es passiert immer derselbe. Aber der Zustand des Systems ist immer ein anderer. Also die Information des Systems entwickelt sich, die verändert sich über die Zeit. Okay, wie machen wir so etwas klassischerweise in der Programmierung, in der Softwareentwicklung? Also zuerst habe ich eine Log in die Datenmangst. Nein, ich rede nicht von dem, sondern generell, wie wir Software denken. Wir neigen dazu, Dinge sequenziell zu machen. Also Schritt A, Schritt B, Schritt C, Schritt D und so weiter. Manchmal sind wir ganz wagemotig und sagen, okay, wir können eigentlich zwei parallele Stränge von Schritt A, Schritt B, Schritt C haben. Aber sobald es dann darum geht, mehrere Dinge gleichzeitig passieren und nicht zwangsweise dieselben sind, wie ich mit dem Ball verdeutlichen wollte, wird es kompliziert. Nun, es gibt bereits Lösungsansätze dafür. Nämlich das Aektor-Model kennt vielleicht der eine oder andere von euch, ist eine wunderschöne Methode, um genau solche nicht-linearen Systeme zu machen. Die Frage ist, wo sind jetzt die Unterschiede? Also was unterscheidet unser übliches Vorgehen von so einem Modell, von so einem Ausführungsmodell, von einem nicht-linearen System? Es ist parallel. Jetzt nehmen wir mal an, ihr hättet es dicker werfen können. Was könnte ich dann mit euch machen? Könnte ich hergehen und sagen, okay, ich mache hier einen Schnitt rein und ihr wandert jetzt in diese Ecke. Würde das Ganze dann noch immer funktionieren? Und das ist vollkommen richtig, ja. Würde immer weiter funktionieren. Ein nicht- linearer System in der Art ist skalierbar. Wenn wir ein sequenzielles Programm haben, tun wir uns ein bisschen schwer mit dem Skalieren. Und wir haben jetzt auch noch den wunderbaren Vorteil, wenn wir die Aktionen von jedem von euch die Wirkungen in so Tasks backen, können wir das in eine Queue schmeißen, die dann in verschiedenen Threads abgearbeitet wird. Das heißt, wir haben auch in Loadbalancing dringend. So, okay, Abstraktion. Abstraktion ist immer schön. Was ist Abstraktion? Hier geht es um die Abstraktion in Systemen. Ich habe hier unten stehen vom Quark zum Menschen und weiter zur Welt. Das heißt, die kleinsten Teile, die wir kennen, sind Quarks. Dann haben wir eine Abstraktionsebene drüber, die Protonen, Neutronen, dann eine Abstraktionsebene drüber, die Atomkerne oder die Atome, darüber die Moleküle. Und dann irgendwann einmal, wenn wir ganz viel Moleküle nehmen, bekommen wir auch Proteine. Ganz viele Proteine geben eine Zelle und ganz viele Zellen geben einen Menschen. Das heißt, eine Information ist hierarchisch aufgebaut. Gut. Jetzt ist die Frage, wie denke ich das Ganze? Wenn ich jetzt fünf Leute habe, wir haben jetzt schon bemerkt, es wird ein bisschen schwierig. Wenn ich das jetzt in einer sequenziellen Anwendung machen möchte, kann es durchaus sehr kompliziert werden. Und die Frage ist warum? Wenn ich eine sequenzielle Anwendung habe, dann kann ich diese Anwendung meistens nur dadurch erfassen, dass ich außerhalb des Systems stehe mit meinen Gedanken und von oben drauf schaue. Also die sogenannte Top-down Perspektive nutze, um dieses System zu betrachten, zu erfassen. Wird dieser System umfangreich, tue ich mir dann schon etwas schwerer damit. Spreche ich von einem System wie zum Beispiel einer Smart City, wo ich dann ganz ganz ganz viele Einzelteile habe, die ganz ganz viele Dinge tun. Dann möchte ich den Menschen sehen, der das erfassen und kontrollieren kann. Das Schöne an nicht linearen Systemen ist, dass ich das Ganze aus seiner Bottom-Up-Perspektive betrachten kann. Das heißt, ich kann jetzt, wenn ihr jetzt meine Programmteile seid, kann ich jetzt sagen, ok, ich versetze mich in die Situation eines Programmteils und dann schaue ich, ok, was muss ich machen, was muss das andere Programmteil machen, wenn es mit mir interagiert. Und kann dadurch meine Software in Stücken aufbauen, ohne dass ich das Gesamtsystem zwangsweise überblicken muss. Ich sollte natürlich eine Ahnung haben, wohin ich will, was das tun soll am Ende. Aber ich kann es wie ein Lego, oder wie ein Lego-Haus zusammensetzen. Gut, das was wir jetzt gemacht haben, ich habe zu euch gesagt, ihr müsst beide den Zettel angreifen. Der Grundsatz war, weil an und für sich, wenn zwei Systeme interagieren, dann können sie das Prinzipile einmal nur über eine Wirkung tun. Es sei denn, und damit kommen wir zum Signal, es sei denn, wir haben ein Medium. Wenn wir ein Medium haben, dann können wir ein Signal schicken. Ok, nicht ganz. Das heißt im Endeffekt, ganz einfach, ich habe eine Information, die ich von meinem System abkoppeln kann, die in irgendeinem Medium drinnen ist und dann sich mit deinem System beeinflusst, also mit deinem System wechselwirkt. Das hat den Vorteil, Signale kann ich übers Netzwerk schicken. Ich kann die Information, das Mikrofon ist aus. Wo ist da der Einschalter? Nein, ist auf An. Ah, jetzt geht es wieder. Ja, vielleicht ist das Medium kurz einmal kollabiert, also in dem Fall der Raum. Nein, das wäre uns aufgefallen. Aber ja, auch elektromagnetische Wellen benötigen dem Raum, um sich ausbreiten zu können, also ein Medium. Ja, dieses Medium, sei es jetzt der Raum bei elektromagnetischen Wellen, sei es bei Schallwellen, die Luft oder beim Ball die Luft und der Raum. Dieses Medium transportiert das Signal und jetzt ist etwas bei Signale, Signale haben eine ganz interessante Eigenschaft, nämlich im Gegensatz zu Wirkungen sind sie variabel. Das heißt, wenn ich den Ball jetzt zu dir rüber rolle, dann verändert sich der, während der unterwegs ist. Also ich könnte dir jetzt eine Spieluhr auch zuwerfen. Hoffen, dass ich nicht einen Kopf treffe. Und diese Spieluhr würde derweil weiterspielen. Ist nur ein kleiner Gedanke, der vielleicht in Verbindung mit Blockchains gewisse Dinge ermöglichen kann. So, okay, dann sind wir schon bei der Causal Run Time. Das ist, also nein, bei Mensch, bei Mensch, bei Mensch, passt schon. Ich habe schon gedacht, ich bin ein bisschen früh dran. Der Mensch, welche Rolle spielt der Mensch? Bei einer klassischen Software ist das relativ klar. Der Mensch muss das System erfassen und er muss in der Lage sein, es zu kontrollieren, zu benutzen. Nun, das ist manchmal etwas schwer. Deswegen gibt es dann auch immer diese unzufriedenen Benutzer. Aber was hin und wieder passiert in der heutigen Zeit, ist, dass der Benutzer eigentlich kein Benutzer mehr ist, sondern ein Teil des Systems. Wo wäre das der Fall? Welche Systeme, die aktuell so modern sind, kennen wir, wo der Benutzer kein Benutzer ist, sondern ein Teil, wo er seine Aufgabe im System erfüllt. Social Media, Facebook, genau. Facebook will nicht von euch benutzt werden. Facebook will, dass ihr euren Teil dazu beiträgt. Naja, und manchmal ist der Mensch auch Gott, weil, wenn wir so ein System beobachten, wir haben eine Kausalität. Und Harald Lesch hat einmal so einen schönen Satz gesagt, der ursächlichste Verursacher war im Kontext des Urknalls. Das wäre dann Gott. Im Kontext eines Systems, wie wir es benutzen, eines PCs, wer ist der Benutzer, der den Einschalter drückt und damit die ursächlichste Ursache liefert. Bitte? Nein, ich will jetzt auch nicht wirklich von Religion. Nein, es geht hier einfach darum, dass in einem System Kausal schlüssig Dinge passieren und irgendwer muss zum ersten Mal sagen und jetzt fängt das ganze Spiel an. Gut, dann würde ich fragen, gibt es da zu fragen, wie das jetzt zusammen passt? Relativ einfach, relativ einfach passt das zusammen, das sind alles Menschen. Ja, ganz einfach, indem ich ein Stück Software gegen ein Menschen austausche und dann habe ich, wenn die alle Subsysteme werden, dann könnte ich doch einfach sagen, okay, ich spiele mit diesem System, ich mache einfach mit und somit Signale ins System hineinsenden und vom System Signale bekommen, die ich dann entsprechend bearbeiten kann bzw. darauf reagieren kann. Ist, denke ich, auch ein bisschen die intuitivere Art mit Systemen zu interagieren und vor allem es ist eine Art, wo man verstehen muss. Okay, sonst noch Fragen, ist das klar, was ich, die Denkweise, die ich versuche hier zu propagieren, sagen wir mal. Irgendwie, wir haben Menschen, die hier miteinander umsetzen und wie, also mir sitzt der Bogen nicht so ganz klar und wie werden sich das jetzt auf das Thema Vortrags passiert? Der Bogen kommt jetzt auch gleich, oder? Nein, ich habe gehofft, dass der Bogen schon gekommen ist. Okay, wie intagierst du mit anderen Menschen? Wie fährt sich das jetzt zu den, was war das, lineare Systeme? Nicht lineare Systeme funktionieren auf die genau gleiche Art und Weise. Das heißt, es ist intuitiv, dass du über Signale kommunizierst. Das ist im Endeffekt das, was ich aussagen will. Es ist viel intuitiver, über Signale zu kommunizieren, mit einem System zu kommunizieren, als ein System zu benutzen, Möglichkeiten dieser Systems quasi zu benutzen. Ich weiß, es ist im Endeffekt in der UI ist es ja trotzdem ähnlich, weil auch UI-Events sind am Ende des Tages nur Signale, aber leider sind das andere Gedanken. Genau, genau. Und was der Mensch gehört zu diesem nicht linearen System dazu? Genau. Das ist auch etwas, was so eine Software ermöglicht oder was das Ausführungsmodell ermöglicht. Dadurch, dass es ein skalierbarer System erlaubt, kann man im Endeffekt ein Netzwerk daraus machen, in dem dann auch viele Menschen miteinander interagieren. Man kann auch hergehen und einfach nur Menschen miteinander interagieren lassen. Sonst noch, oder ist das, ist, ist, ist, ist wichtig, dass dieses System verändern muss, dass wir Dinge tun müssen und nicht allein folgen oder so. Dann verliert der Programmierer eigentlich sein Gottverwachter. Hier siehst du dich hin und programmierst das durch, sondern in einem zunehmend komplexen Umfeld brauchen wir selbst steuerende Systeme, weil der sequenzielle Vorgang mit den Verfälzbaren aufhabe ich mir realisierbar ist. Er schafft praktisch Rahmenbedingungen und gibt dann den System die Chance, sich selbst zu organisieren. Da ist der Daprogrammier kein Wortersatz, der das durchmogeln wird, weil er aufhabe die Gandische und gar nicht realisierbar ist, bis du fertig bist, haben die Umfeldbedingungen längst wieder verändert, als wir vorne anfangen, sondern das praktisch ein ermöglichter, der dem System einen Raum vorgibt, in dem es sich dann selbst steuert. Genau. Das ist nicht genau meine Frage jetzt. Welch was für ein Raum muss ich vorgeben, wenn ich am Ende ein bestimmtes Ergebnis habe? Also, gibt es da irgendwie mit hohen Stimmen? Wenn du ein bestimmtes Ergebnis haben willst, dann ist die Frage, wenn du ein bestimmtes Ergebnis anstrebst und nicht das Dinge passieren, sondern das alles auf ein Ende hinausläuft, ob das dann die richtige Systementscheidung ist oder die richtige Architekturentscheidung. Aber wegen dem Ergebnis, also wenn du dir neuronale Netze anschaust, neuronale Netze können genauso als nicht linearer System ausgeführt werden. Ja genau, aber ich kann ja wieder irgendwie analysieren, ich kann ja auch irgendwie mein neuronales Netze da eingehend trainieren, dass wir am Ende einem Stimmen aufliefern. Am Ende? Ist das wirklich am Ende oder ist das einfach eine Eingabe und eine Ausgabe und du kannst dann noch eine Eingabe nachlegen? Ja, aber dass du das damit machst, was du gerne damit machen würdest, dass du das Ergebnis bekommst, ist ja kein Prozess, der irgendwo ein Ende findet, sondern es ist ein kontinuierlicher Prozess. Du gibst etwas im System und das spuckt am anderen Ende etwas aus und das kannst du beliebig oft wiederholen und das System läuft da, weil es wäre das Konzept nach dem wir funktionieren, dass sich etwas mit jeder Eingabe anpasst. Was ist das Endziel der Entwicklung neuronaler Netze? Nein, so wie ich es wahrnehme ist, also ja gut, nicht das kommerzielle Ziel, sondern das idealistische Ziel und das ist ja soweit ich das verstehe, dass das neuronale Netze oder die neuronalen Netze irgendwann einmal in der Lage sind zu tun, was wir tun. Ja, ich würde mal sagen, dass wir die Fähigkeit mit Komplexität umzugehen, quasi eine Maschine dafür bauen, dass wir das nicht wie Tiere jedes mal selber machen müssen, weil so ein normales Programm, das nicht lernfähig ist, kann halt eine Sache oder viele Sachen, aber es kann sie auf eine Weise, es kann sich nicht neuen Gegebenheiten anpassen und es kann nicht mehr Komplexität handeln, Hand haben, als der Programmierer gehandhabt hat oder die Programmierer oder innen oder so immer, aber auf jeden Fall der Punkt ist, man kann halt irgendwie mehr Komplexität Hand haben und man kann mit Veränderung umgehen, wenn man selbst lernt, das System hat. Das ist im Endeffekt genau, dass wir was wir menschen können und was wir von neuronalen Netzen irgendwann erhoffen. Ja, ein bisschen natürlich, aber ich glaube, wir sind noch sehr, sehr weit entfernt von neuronalen Netzen, die die Leistungsfähigkeit des menschlichen Gehirns haben. Ja, seid die Frage, auf welche Dimensionen das betrachtet? Das ist richtig, ja. Gut, aber wir sind jetzt ein bisschen ausgeschert, gibt es zu dem Thema noch irgendwelche Fragen? Wie gesagt, es ist hauptsächlich darum gegangen, oder mir geht es hauptsächlich darum, diese Arzt zu denken, vor allem die Button-Up-Perspektive ein bisschen und das Volk zu bringen aus dem ganz einfachen Grund. Die Komplexität von Systemen nimmt zu und irgendwann einmal sind wir Menschen mit unserem Erfassungsvermögen am Ende und können komplexe Systeme nicht mehr aus der Top-Down-Perspektive betrachten. Weswegen wir uns dann darauf einlassen müssen, dass wir Systeme erschaffen, die wir per se nicht kontrollieren und auch nicht kontrollieren können, sondern die in ihrer Architektur so beschaffen sind, dass keine Kontrolle notwendig ist. Bitte? Ich kann ja oft das System wiederum ein System bauen, das Milch, das System zu vorstellen. Ja, ich muss das Modell davon anschauen, sagen, kannst du einen Apfelfeld verbauen, das heißt nicht, dass du den Baum verstehst oder den Apfel, du weißt mir, dass du den Konzept verstehst, wie der Apfel fällt. Und du könntest natürlich auch ein Programm programmieren, das schaut, ob der Apfel eh richtig fällt. Aber das Programm kann wieder das nicht dem Baum als in seinem ganzen Wesen erfassen. Aber ja, funktioniert der Baum, man soll es nicht glauben. Ja, gut, es ist 35, also ich war relativ schnell. Gibt es noch irgendwelche Fragen oder es geht nicht nur um Fragen, sondern auch wenn jemand diesen Gedanken jetzt aufgenommen hat und etwas dazu sagen möchte, also etwas dazu beitragen möchte. Meine primäre Motivation von dem Ganzen ist, dass ich eben andere Menschen zu diesem Thema, zu diesen Gedanken sprechen höre, um selber vielleicht ein bisschen weiterzukommen. Okay. Wie schafft man das dann trotzdem irgendwie Parameter zu setzen, dass es nicht völlig aus dem Bruder läuft? Also wir hätten jetzt auch sagen können, wir geben jedes zweite Mal den Ball weiter. Die Regel war ja trotzdem da, also wie schafft man das solche Regeln zu schaffen, die dann von jedem Subsystem eingehalten werden? Naja, das Schöne ist, die schreibst du selber. Das ist ja der Code, den du schreibst. Nein, du musst nur das eine System für das du Code schreibst, überblicken und dann hast du die Signale, welche eine Schnittstelle darstellen und die andere Seite kann jemand anderer machen. Das ganze System überblicken muss keiner, solange sich die Leute auf Schnittstellen einigen können und es zu keinen Konflikten kommt. Also ich denke dann zwei Sachen, die dich vielleicht interessieren könnten. Ich weiß nicht, ob dir was wertvolles ist für deine Belange, aber erst ist es Zellularautomaten, wo ich eben genau, das ist quasi, ich habe eine Menge von sogenannten Zellen, Array oder sowas oder Grid und jedes davon hat dasselbe Programm und die laufen quasi parallel und machen irgendwas, zum Beispiel, wenn du Convays Game of Life kennst, das ist die Zellularautomaten. Genau, also das ist halt ähnlich wie wir am Anfang jede, du hast ja mehrere Systeme, die halt unabhängig voneinander irgendwas machen und das gesamte System macht dann irgendwelche Berechnungen oder sonstigen Schabernack. Die zweite Sache, die dich interessiert ist Chaos Theorie, da weiß ich auch nicht viel drüber, aber das ist, ja gut, dann mindestens ein Treffer. Danke, vielleicht was ich vergessen habe zu erwähnen, ist, wenn du Convays Game of Life gesagt hast, Convays Game of Life ist ein homogenes nicht linearer System. Homogen bedeutet, es gibt nur einen einzigen Aspekt, in dem das System interagiert, in dem Fall ist in der Nebenzelle etwas drinnen oder nicht, beziehungsweise wie viele Nebenzellen sind belegt, Nachbarzellen. Und deswegen habe ich die Bälle hier auch noch mitgebracht, weil ich eben zeigen wollte, es gibt die Möglichkeit, dass ein System inhomogen ist, sprich, dass deine Hände tun etwas, deine Füße tun etwas anderes, sind zwei unterschiedliche Aspekte und doch hat das eine Auswirkung auf das andere. Und alle können im Endeffekt gleichzeitig passieren und es ist nicht so, dass du dann acht Rats hast, in denen eigentlich überall das Gleiche passiert, sondern der eines Rats führt gerade den Sticker aus, die Handaktion und der andere Rats führt gerade eine Fußaktion aus, also dass das Ganze auch inhomogen sein kann in der Art und Weise, was es tut. Also nicht so wie bei GPUs, bei GPUs hat man ja das Problem, da muss man ja schauen, dass alles schön homogen ist, ansonsten geht die Performance in die Knie und dann macht man es besser auf der CPU. Aber ich denke, die Waremacht liegt in den inhomogenen Systemen. Ein praktisches Anwendungsbeispiel vielleicht, was wir gerade bei der AVL machen. Wir haben in der AVL viele Softwareprodukte für, also wir sind ein Autozulieferer, also wir liefern an Konzerne wie Daimler, VW, W noch immer. Und wir haben jetzt viele klassische Softwarestücke, von denen wir das Problem haben, wir wollen die jetzt irgendwie in eine Cloud bringen, die irgendwie miteinander vernetzen. Und das machen wir aktuell genau mit dem Aektor-Model, also konkret mit dem C++ Aektor-Framework. Funktioniert auch super, so weit wir es bis jetzt sagen können. Ja, aber im Endeffekt für so etwas ist das Ganze gut, zum vernetzen und miteinander interagieren. Dass du in der Schnittstelle auch noch eine Möglichkeit hast, Logik einzubringen. Also ein praktisches Beispiel eines unserer Softwarestücke heißt Concerto. Und das ist ein Datenanalyse-Tool, ist auch automatisierbar, hat eben eine API, genau über diese API wird es in das, was wir Application Cloud Service nennen, eingebunden. Und wir haben jetzt in der Schnittstelle selber eine Scheduling-Logik drinnen. Wenn wir jetzt direkt nur die API von einer Concerto-Instanz ansprechen würden, dann könnten wir das nicht machen. Aber so haben wir einen Client, der in diesem ACS-Netz drinnen hängt und der schickt ein Signal rein an alle Scheduler. Hier, ich habe einen Auftrag für euch. Und das geht eben an mehrere Scheduler, wird für viele Concerto-Instanzen enqueued. Jedes Scheduler kann mehrere Sessions haben, also mehrere Concertos kontrollieren. Gedacht ist es, dass es im Endeffekt für jeden Computer auf den mehrere Concertos laufen können einen Scheduler gibt. Man kann das Ganze natürlich auch anders skalieren. Und ja, das ist der Vorteil. Man hat einfach eine Möglichkeit, Logik in das Ganze hineinzubringen. Ja, ich kann es auch machen, was du gesagt hast. Was ist der Mehrwert? Ihre Event-Riven-Händler dazwischen, können Sie das selber? Ja, du machst das. Wenn du jetzt sagst, ich habe Broadcasting-Mechanismen drinnen oder ich habe irgendein Event-Händler, der das manischt, du machst ja im Endeffekt genau dasselbe. Nur mit dem Unterschied, dass du es nicht in einer klaren Architektur machst. Aber sobald du jetzt sagst, okay, ich habe irgendwann ein Service, der schedulet mir das und per Broadcast schicke ich meine Signale an die Services, an die Scheduler, die dann irgendwelche Services sind und die Concertos ansteuern, machst du ja genau dasselbe. Nur mit dem Unterschied, dass du viele unterschiedliche Werkzeuge dafür benutzt, was du vielleicht gar nicht tun willst, wenn du es mit einem einzigen Werkzeug auch lösen kannst. Ich weiß nicht, war das zufriedenstellend? Ist das wirklich? Was ist das für ein Wiederverteilung? Aber ich meine, das Konzept, das Konzept ist ja natürlich neu. Das Ektomodel gibt es jetzt 1973. Wir erkennen erst jetzt schon langsam, was es uns eigentlich ermöglicht, speziell in Zeiten der Multicore-Prozessoren, wo wir dann so davor stehen und uns denken, ja, okay, eigentlich benutzen wir neuen Core, wieso hat das Ding acht? Und das ist der Vorteil bei so einem System, es betreibt Load Balancing ganz automatisch, es betreibt Synchronisation ganz automatisch und man kann es quasi endloskalieren. Gut, dann möchte ich noch eine Folie. Ich habe privat ein Projekt, das nennt sich Causal, oder die Causal Runtime, und es geht im Endeffekt nur darum, dass Informationen miteinander interagieren können, Überwirkungen, also nicht über Signale. Man kann natürlich ein System, das über Signale funktioniert dann darauf davon abstrahieren und welches die Wirkungen im Endeffekt in einer Queue hinterlegt und diese Queue, diese Queue, oder die Wirkungen in dieser Queue wissen, welche Aspekte von den Informationen sie benötigen. Diese können ein- und ausgecheckt werden und Skipping Queue deswegen, weil ich im Endeffekt sage, gibt mir das nächste Element, für das alle Aspekte gerade verfügbar sind, sodass ich es ausführen kann, ohne einen Datenkonflikt hervorzurufen, einen Speicherkonflikt. Wenn es, wenn sich irgendwer für so eine Thematik interessiert, das Ganze ist in D geschrieben, ist auch eine ganz spannende Programmiersprache. Wenn das jemanden interessiert, bitte anschauen. Wenn jemand der Meinung ist, hey, das ist cool, dann möchte ich mich beteiligen, dann herzlich willkommen. Ja und damit sind wir eigentlich schon am Ende. Danke. Was, was, was? Frage. Also du hast deine Frage. Was erfüllt sein muss bei dieser Skipping Queue ist das, also die Wirkung erforder, die Wirkung passiert an Aspekten von Informationen. Also bei den Spielern hier, zum Beispiel der Hand, der händische Aspekt und es geht hier darum, dass dieser Aspekt nicht, nicht, oder ein Aspekt von einer Information nicht gleichzeitig verwendet werden kann. Das heißt, ja, die Aspekte A1, also die Blauen Kreise sind eine Information, irgendeine Information. Diese Information hat Aspekte. Genau, die A sind die Aspekte und die sind auscheckbar. Also die sind, die haben ein Check-in, Check-out System und die Queue schaut einfach nur, okay, ich habe jetzt als nächstes die Wirkung 1. Genau, die Wirkung sind die Queue und eine Funktion. Genau. Im Endeffekt, also praktisch kannst, wenn du jetzt so eine Struktur definierst, hierarchisch mit mehreren Unterstrukturen, kannst du im Endeffekt in jeder Ebene der Hierarchie kannst du sagen, okay, und das ist jetzt ein Aspekt. Das muss, wenn es benutzt wird, ausgecheckt und wieder eingeschickt werden. Also du kannst im Endeffekt auch bereits vorhandene Datensstrukturen einfach dazu machen, indem du, indem, einfach mit Aspekten versehen, indem du, in dem Fall einfach das Template dafür benutzt und dann wird das Ding ein- und auscheckbar und dann sind auch Datenkonflikte ausgeschlossen, hoffentlich. Die Queue wird von mehreren Strats abgearbeitet. Das habe ich jetzt nie. Also du kannst ja, kannst du jetzt irgendwie sagen, ich mache eine Wirkung 1, Wirkung 2, Wirkung 3 oder ich könnte die reiten Wirkung die vertauschen und je nachdem, wie die Ideen, die auch eigentlichkeiten sind, also welche Aspekten die brauchen und wie viele Strats ich habe, habe ich für mich auch in der Struktur, die ich in der Struktur nachdem die Ideen auch eigentlichkeiten sind, also welche Aspekten die brauchen und wie viele Strats ich habe, habe ich unterschiedliche Ausführungsreinfolge, warum die optimal sind. Die Ausführungsreinfolgen sind im Endeffekt durch die, durch die Reihenfolge, wie die Wirkungen in die Queue hineinkommen und wie die Aspekte gerade ausgecheckt oder eingecheckt sind. Also ganz praktisch ist das im Endeffekt das ganze Ding ist jetzt als Proof-of-Konzept verfügbar und hat 400 Zeilen. Ich bin da ein bisschen zeilen, ich bin da ein bisschen auf der Kissschiene, Kippitz-Simples-Diopet und ja, ich bin eigentlich mit dem Proof-of-Konzept sehr zufrieden und möchte das jetzt auch mit einem gescheiten Templating-System durchziehen, dass gewisse Dinge intuitiver zu machen sind. Okay, danke. Danke, dass ihr da wart, danke, dass ihr zugehört habt. Danke für eure Gedanken und ich wünsche euch einen schönen Abend.