KI hat mehrere Schwachstellen bzw Punkte die beachtet werden müssen: 1. Es braucht immer eine Fachkraft die genau weiß wonach gesucht werden muss um auch ein verwertbares Ergebnis zu erzeugen. Wer nicht weiß nach was gesucht werden muss, wird auch nicht zum Ziel kommen. 2. Es braucht immer eine Fachkraft die das Ergebnis validieren und allgemein beurteilen kann. Den eine KI kann nicht sagen, was richtig oder falsch ist! 3. Ergebnisse sind mit Vorsicht zu genießen, denn oft gibt es mehrere Ansätze die korrekt sind, jedoch greift sich die KI den Prozess der Bildung einer eigenen Meinung vorweg bzw. bestimmt, was du als Ergebnis bekommst, obwohl du bspw. beim Recherchieren via Google aus x-Quellen zu einem anderen Ergebnis kommen würdest. 4. Die Qualität von KI erzeugten Ergebnissen ist nur so gut, wie die Datenqualität die für das Training verwendet wird. shit in = shit out.
Bei Code hilft es auch immer eine Dokumentation offen zu haben und zu schauen, ob in dem thread wiedermal irgendwelche Methoden, inkl. darauf aufbauender Logik, erfunden wurden und die KI, wieder im selben Thread, entsprechend zu bestrafen. Z.b. per Daumen nach unten im openai Client.
Endlich wirst Du mir sympathisch. :) Es gibt nicht die richtige oder falsche Architektur. Es ist immer eine Frage der Domäne. Bei MVC habe ich auch einige Funktionalität im Model. Alles, was eng mit den Daten verbunden ist, gehört für mich auch zu den Daten. So bekommt schon die Datenbank eigene Routines und Triggers. Low Level Datenlogik gehört für mich nicht in die Business Logic. Man muß sich nur jedes Mal überlegen: Ist die Logik jetzt eng nur auf die Daten bezogen, oder ist es schon Prozeßlogik. Konsistenzsicherung gehört für mich ganz klar zum Model. Meine Datenmodelle müssen so selbständig eigene Logik mitbringen, daß sie vom Controller erst gar nicht korrumpiert werden können. So einigen Fundamentalisten werden sich jetzt schon wieder die Fußnägel kräuseln von wegen saubere Trennung und so.
Vielen Dank für das tolle Video. Ich mag die Aufnahmen in der Natur wirklich sehr. Nur bei der ersten Drohnen-Aufnahme hat mich die schöne Naturaufnahme fast vom Zuhören abgelenkt. Ich denke, es wird viele Bereiche geben, in denen eine KI wie ChatGPT ein wunderbares Werkzeug ist und andere Bereiche, wo es weniger gut funktioniert (so wie es halt mit den meisten neuen Technologien ist).
Hey, sehr gerne, schön das es Dir gefällt. Das waren noch nicht mal die schönen Aufnahmen, das war nur das Warm-Up. Als die Sonne richtig gut stand, habe ich die Drohne in einen Baum "geschossen" und hatte keine Ersatzpropeller mehr dabei... :( Dauert noch etwas, bis das alles passt :) Gruß David
Ich glaube, die Frage nach einer "Architektur" stellt sich einer KI komplett anders. Eine KI benötigt keine Architektur im traditionellen Sinn. Warum soll eine KI in C++ oder Java "denken", oder Daten und Verhalten voneinander trennen? Warum sollte eine KI stattdessen nicht gleich z.B. das ELF File erstellen, wenn das HW Interface bekannt ist. Die "Architektur" erfüllt dann nur noch funktionale und nicht funktionale Anfprderungen, wie z.B. Performance, Sicherheit usw. Dagegen treten Anforderungen wie Erweiterbarkeit, Lesbarkeit, Verständlichkeit, Testbarkeit eher in den Hinergrund. Diese Anforderungen decken eher "Bedürfnisse" eines menschliechen Programmierers an die Software ab. Die Architektur, die die KI implementiert ist für Menschen dann am Ende auch nicht mehr als solche erkennbar, da wir aus einer riesen Menge von Einsen und Nullen kein Konzept mehr ableiten können, im Gegenssatz zu einer KI, die dann z.B. immer noch erweitern, testen und verstehen kann.
Tolles Video :D Hallo David, danke für das Video. Ich habe mir oft darüber Gedanken gemacht, warum wir so viele unterschiedliche Definitionen in der Softwareentwicklung haben. Du hast das super beantwortet. Dieses Problem hat unter anderem bei mir dazu geführt, dass ich zu jedem Thema in der Softwareentwicklung immer mindestens zwei Bücher zu dem gleichen Thema habe und mehrere Online-Quellen recherchiere, um in einem Thema überhaupt zu verstehen was im Kern gemeint ist. LG Grüße Erik und viel Spaß im Schnee :D
Wenn Robert Martin der Meinung ist, dass es immer ein Anti-Pattern ist Daten und Verhalten zu trennen, hat er ja offensichtlich nicht recht, wenn Du das Pattern erfolgreich verwendest. Dann sollte er seine Aussage in der Art abändern, dass es von der Architektur und dem Anwendungsfall abhängt und es sowohl ein Design Pattern als auch ein Anti-Pattern sein kann und die Umstände dann entsprechend genau definieren und voneinander abgrenzen. Das wäre zumindest hilfreich für viele Software-Entwickler, die die Entscheidung für das ein oder andere Pattern treffen müssen.
Ein IT Video in der Natur? Mal was anderes aber gefällt mir. :D Ich bin mega gespannt wie AI sich entwickeln wird und wie wir Programmiere damit in Zukunft arbeiten werden.
KI kommt mit verschiedenen Pattern prima klar. ChatGPT zum Beispiel kann man sagen, welche Architekturmuster man bei seinem Code haben möchte. Fortgeschrittene Tools können das noch weiter treiben, und benutzen ja den vorhandenen Code im Kontext. Das klappt jetzt schon erstaunlich gut. Komplett egal ist das bei manchen Anwendungsfällen, zum Beispiel mal eben ein Dockerfile schreiben.
Wenn man sen Begriff Daten durch den Begriff Zustand ersetzt, könnte man sagen, dass der Zustand und das Verhalten einer Klasse zusamme gehören, diese aber wohl, zum Lösen einer Aufgabe, auf außerhalb der Klasse gehaltene Daten zugreifen kann. Unter der Viraussetzung bin ich der Meinung, dass Daten auch ohne Verhalten sinnvoll existieren können.
Die Vorstellung, Daten und Verhalten zu trennen, kommt halt aus der prozeduralen Programmierung. Ist quasi das beste, was man in z.B. C machen kann. Es ist halt keine OOP, sondern prozedurale Programmierung mit Objekten. Was halt erstmal überhaupt nichts schlechtes ist. Ich sehe nur, dass viele die Begriffe nicht richtig verwenden. Ja, OOP will Daten und Verhalten miteinander verheiraten. Und ich weiß, dass das wie ein No True Scotsman klingt, aber wahre OOP machen
Ich finde deine Sichtweise interessant. Man könnte dann doch auch ChatGPT als Chance sehen, dass wir in der SE ein bisschen vereinheitlichen? Ich fände es nicht schlecht :-P
Hey, die Notwendigkeit war schon immer da, hat trotzdem nie geklappt. ich würde mich darüber freuen, aber bin nicht besonders optimistisch :) Gruß David
Ich stimme zu, komma, aber... Einerseits handelt es sich ja um Software-"Entwicklung". Diese Entwicklung zieht sich ja, wie du schon sagst, eine Weile hin. Wir waren mal bei Mainframe-First mit dummen Terminals, sind zurückgegangen auf Alles-Auf-Den-Client, dann kam Azure mit Cloudlösungen, ... kurzum: es ist ein weites Feld mit ständigen Neuerungen. Wenn man den Entwickler nun aus diesem Kreislauf rauszieht, wer genau liefert denn dann die Vorlagen für das KI-Training? Andererseits wissen wir, dass die Industrie nichts mehr liebt als Kostenersparnis, was dazu führt, dass Sonderfälle zwar nicht vom Algorithmus abgedeckt sind, aber 80% ja auch ausreichen - ein paar haben dann eben verloren. Ich denke zB an SCHUFA-Ermittlungen etc. Was, wenn dem Großteil diese 08/15-Lösungen ausreichen und nur noch ein elitärer Anteil an der Entwicklung selbst teilnehmen darf weil zu teuer? Ich würd mir zwar wünschen, dass es nicht dazu kommt, hab aber wenig Hoffnung, da auch alle anderen Produkte der Industrie immer mehr in der Qualität abnehmen - weil zu teuer.
Ein sehr gutes Video obgleich dieses mal ein deutliches "disagree". Zustimmung was die Uneinheitlichkeit, fehlende Formen angeht dafür multiple Kosmen jeder unterschiedlich und oft doch funktionierend. Doch aus meiner Sicht falscher Schluß daraus. Die Vorstellung dass ein Mensch bessere Entscheidungen diesbezüglich trifft als eine KI welche trotz aller Diversität wesentlich mehr Training hat als der Mensch könnte bestenfalls naiv sein. ja, auch ich würde es begrüßen wenn der Mensch hier den besseren Überblick hat, die KI dem Menschen die Tools und den Code reicht wie ein Operateur das Besteck erhält doch ... doch das erscheint mir einfach sehr unrealistisch.
Ich habe sehr gute Erfahrungen mit IODA nach Ralf Westphal gemacht. Integration (keine Logik) Operationen (Logik) Daten (keine Logik) API Application Interfaces
Ja, und dann gleich noch eine Frage hinterher: Wie hast Du das Video filmisch aufgenommen? War noch jemand dabei, oder hast Du eine Drohne dabei gehabt?
Es hört sich für mich an als würdet ihr beide von Datenstruturen in 2 Sichtweisen reden und dabei falsche Worte verweden. Beispielsweise der Eine redet von Umfahren (rundherum fahren) und der Andere von Umfahren (drüber fahren). Dieses Problem sieht man in der IT extrem oft! Thema Datenstrukturen gibt es ja Daten die getauscht werden (Data Transfere Object) und Daten die auf etwas basieren (Data handling object). beides sind datenstrukturen bzw. beknhalten datenstrukturen und das eine ist besser zu trennen von den Tätigkeiten/Methoden und das Andere nicht.
Die Kruxs bei der Sache ist doch. Ein Softwareentwickler entwickelt so etwas, und man wundert sich hinterher warum man dann selber nicht mehr gebraucht wird. Hmmm. Wie eine Selbsterfüllende Prophezeihung.
Der hat schon bei vielem recht. Die Clean Architecture ist sehr cool für die richtigen Use-Cases. Wenn du Anwendungen mit viel Fachlogik baust, die nur hier und da auf nen Adapter zugreifen müssen und diese Anwendung dann noch stark portierbar sein muss auf verschiedene Plattformen und Datenspeicher Lösungen, ist das extrem praktisch vor allem in Kombination mit TDD. Das Problem ist nur, dass in der Realität fast keiner von uns solche Software baut. Unsere Logik zielt oft nicht auf ein Objekt, sondern auf Transaktionen, die mehrere Objekte verändern. Meistens besteht die "Businesslogik" aus 10 Zeilen Validierungen und der Rest ist Mapping von/auf Adapter und eine Operation über mehrere Objekte. Darum sieht fast jede clean/onion/hex architecture aus wie ne verunglückte Komponenten/Schichten Architektur, weil die Hälfte der Fachlogik in den Domain Objekten ist und die andere Hälfte steckt in irgendwelchen "service" oder use-case Klassen außen rum, weil sie nicht eindeutig zugeordnet werden kann und dann gibt es auch code, wo man nie eindeutig festlegen konnte, ob das jetzt eigentlich zu Entity A gehört oder zu Entity B. Außerdem löst die Architektur ein Problem, dass wir durch Techniken wie Dependency Injection eigentlich kaum noch haben. Ne Spring Boot Anwendung ist bereits so portabel und hat so eine hohe Unterstützung für vollständig automatische Tests, dass man wirklich keine Argumente mehr für ne Clean Architecure hat. Außer eben in Exoten Projekten, wo wahnsinnig viel Code in der "Logik Schicht" liegt und die Logik auch einen starken Objekt-Bezug hat. Am Ende macht es aber trotzdem nichts einfacher, gut aufgebaute "Schichten" sind genauso gut testbar. Und TDD so wie es mal gedacht war, ist eigentlich auch genial, wurde nur komplett korrumpiert von einem falschen Verständnis und kurzen Internet Tutorials Z.B. glauben die meisten, dass jede einzelne Methode im System den TDD Zyklus durchlaufen muss, dabei geht es eigentlich um die public Methoden einer Unit/Komponente und der refactoring part ist dann ja dafür da, den Code hinter dieser Methode beliebig zu strukturieren (auch in mehrere Methode, Klassen, whatever), während der Test sicherstellt, dass mein Refactoring nichts kaputt macht. Das Agile manifest war auch mal ne gute idee.
