Alternative Programmiermethoden zu klassischem Source Code

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Antworten
Oprah Noodlemantra
Beiträge: 19
Registriert: 30.06.2015, 19:03

Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Oprah Noodlemantra »

Hallo,

im folgenden Video wird argumentiert, dass das Schreiben von Source Code sehr fehleranfällig ist, die ersten fünf Minuten Motivation kann man auch überspringen, denke ich. Zusammengefasst sind If-Statements schwierig zu lesen und zu verändern. Stattdessen wird ein alternativer Ansatz auf Basis von Wahrheitstabellen vorgestellt. Im Grunde entwickelt der Autor eine neue IDE, in der auch Funktionen usw. definiert werden können.

[vimeo]https://vimeo.com/140738254[/vimeo]

Ich finde, das sind sehr interessante Ansätze und frage mich, warum die eher ein Nischendasein fristen. Vielleicht ist es am Ende doch viel umständlicher so zu programmieren?
Benutzeravatar
Jonathan
Establishment
Beiträge: 2348
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Jonathan »

Ok, ich hab jetzt nur mal ne Minute reingeguckt um eine Vorstellung davon zu bekommen, was er macht.

Mein erster Eindruck: Die Sachen die ich entwickle bestehen zu 98% aus ziemlich banalen Algorithmen. Ich habe fast nie kompliziert verschachtelte if-Abfragen, zu locker 3/4 aller Abfragen hab ich nichtmal einen else-Zweig. Die ganze Komplexität kommt eher aus der Beziehung von Objekten untereinander, z.B. durch ein Entity-Component System. Der letzte komplizierte Algorithmus (also Algorithmus im Sinne von "würde man in einer Algorithmen-Vorlesung in der Uni durchnehmen") den ich implementiert habe war A* für Wegsuche in Graphen, da musste ich tatsächlich konzentriert Zeile für Zeile durchgehen und genau darauf achten, was wo passiert. Alles andere ist ziemlich simpel zu lesen und interessante Stellen entsprechend durch Kommentare erklärt.

Für sehr spezielle Anwendungsfälle mag der vorgestellte Ansatz nett sein, aber dann ist halt auch die Frage, was das für Anwendungsfälle sein sollen. Es gibt ja auch spezielle Logik-Sprachen wie Prolog, vielleicht geht das ein wenig in die Richtung. Vielleicht könnte man mit dieser IDE Skripte für KIs (also Gegner in Computerspielen) entwickeln oder so. Aber dann ist halt wirklich die Frage, wie hoch der Aufwand ist, dass in z.B. C++ einzubetten, worin dann alles andere geschrieben wäre.

Und was man nicht vergessen darf: Textdateien sind einfach mega geil, weil sie so unfassbar einfach zu benutzen sind. JSON ist toll, weil ich keinen Editor für meine Config-Dateien schreiben und bei jeder Änderung der Parameter neu anpassen muss. Weil es wunderbar mit Tools wie git funktioniert. Weil man sich über Datentypen so wenig Gedanken machen muss. Weil es dafür eine Vielzahl sehr ausgereifter Text-Editoren gibt. Und weil ich die durch Leerzeilen und Kommentare tatsächlich auch sehr leicht sehr übersichtlich strukturieren kann. Selbst so triviale Dinge wie "Suchen & Ersetzen" können super nützlich sein. All das fehlt halt in so einer grafischen GUI erstmal, man müsste da ohne Ende Features einbauen bis es sich ähnlich gut bedienen lässt.

Insgesamt denke ich, dass man diese Wahrheitstabellen vlt. im Informatikunterricht in der Schule mal einsetzen kann, sehr viel mehr Potential sehe ich darin dann aber nicht.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Krishty »

Naja, Menschen folgen unterschiedlichen Denkmustern. Einige finden Wahrheitstabellen vielleicht ganz geil, aber ich bin eher imperativ unterwegs. Ich binde mir auch den Schuh zu wenn er offen ist, und schlage nicht seinen Zustand auf einem Tabellendiagramm nach.

Als jemand, der aus Performance-Gründen gern Tabellen-orientiert programmiert, kann ich dir sicher sagen, dass der vorgestellte Ansatz nur gut klappt, so lange du in der extra dafür angefertigten IDE bleibst. Was okay ist, denn das ist mit den meisten Sprachen so. Deshalb ist es aber auch noch lange keine Revolution.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Jonathan
Establishment
Beiträge: 2348
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Jonathan »

Ich hab dann doch nochmal weiter geguckt, insbesondere den Teil über Polymorphie.
Ich muss sagen, der Mathematiker in mir freut sich schon über die Eleganz der Darstellung. In den Beispielen hat man wirklich eine gute Übersicht, was von wo kommt, und ich würde wohl zustimmen, dass wenn man sich an diese Tabellen gewöhnt hat, sie viel schneller zu lesen sind, als Code.
Aber der Pragmatiker in mir denkt halt auch direkt: Im echten Leben hab ich aber nicht von der einen Klasse eine 2 und von der anderen eine 4 die dann mit einer dritten Zahl multipliziert werden. Ich habe 10 Zeilen imperativen Code, der irgendwas macht. Was passiert, wenn ich DAS in meine Tabellen schreibe? Entweder muss man endlos scrollen und hat keine Übersicht mehr, oder man klappt alles zusammen in kleine Black-Boxes - aber dann sagt die Tabelle ja auch nur noch, dass an unterschiedlichen Stellen unterschiedliche Dinge passieren und ich weiß trotzdem nicht, was wo passiert.
Und das ist auch eigentlich schon der Grund, warum Polymorphie und OOP und das alles so nett ist - ich muss eben gerade nicht einen Überblick über alles haben was passiert. Ich schreibe den Code so, dass ich mir nur eine einzelne Funktion und ein paar Schnittstellen nach außen angucke und mir komplett egal ist, was dahinter passiert. Die Robustheit kommt dann nicht daher, dass ich alle Aspekte meines Programmes zur gleichen Zeit im Bewusstsein und verstanden habe, sondern dass ich prima zurecht komme, ohne diesen großen Überblick haben zu müssen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4252
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Chromanoid »

Ja ich glaube es ist viel umständlicher. Ich glaube Text ist einfach unheimlich mächtig, effizient und flexibel. Code speed-readen geht halt durch Formatierung und starke Muster echt gut. Lesen (und schreiben) tut der moderne Mensch ja auch extrem viel, so dass man da zusätzlich von Routine profitieren kann.

Ich habe mir das Video jetzt nicht wirklich reingezogen. Text wäre mir lieber ;). Was ich so gesehen habe, waren magic numbers und andere Sachen an denen ich Kommentare sehen will, die ich benannt haben möchte oder die ich in Sachen wie DMN Entscheidungstabellen extrahieren wollen würde. Also entweder Dinge, die Datencharakter haben und nicht so super im Code aufgehoben sind oder als Konzepte benannt werden sollten.

Ich finde bessere Integration und Verlinkung von Kommentaren und bessere Unterstützung von BDD im Sinne von literate programming da vielversprechender. Mindestens leichteres verlinken von Programmierkonstrukten in Kommentaren fehlt mir sehr. I.d.R. geht das ja nur in Methoden, Attribut und Klassenkommentaren... Letzteres dann auch nicht unbedingt schön.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Alexander Kornrumpf »

Zusammengefasst sind If-Statements schwierig zu lesen und zu verändern.
Ein bekanntes Anti-Pattern, das ich auch schon in Produktivcode gesehen habe ist sowas:

Code: Alles auswählen

if (foo) {
    //stuff
}
//more stuff
if (foo) {
   //more foo stuff
}
Was geht hier vor?
Eigentlich sind das zwei Fälle, die aber in "more stuff" gemeinsamen code haben, also hat sich jemand gedacht "ich verlasse hier mal das if zwischendurch". Dadurch ist nicht mehr ohne weiteres offensichtlich dass das obere if und das untere if zusammengehören. Wenn "more stuff" jetzt auch noch ein bisschen länger ist haben wir den Wartungsalptraum.

Was man eigentlich wollen würde, wäre ungefähr dieses:

Code: Alles auswählen

if (foo) {
    //stuff
    do_more_stuff();
    //more foo stuff
} else {
    do_more_stuff();
}
Ich erkläre jetzt nicht _warum_ das untere besser ist als das obere. Ich vermute für die meisten hier ist das sowieso offensichtlich oder sie kennen das anti-pattern aus eigener Anschauung. Nur um es explizit zu machen das ursprüngliche Problem, das das anti-parttern "lösen" sollte war, dass es Code gibt der in beiden Zweigen gleich ist, daher jetzt eben der Funktionsaufruf.

In der Realität sind es manchmal mehr als zwei Blöcke oder "more stuff" hängt (ggf. subtil) auch von foo ab. meiner Erfahrung ist selbst die Version, die ein vermeintliches Duplikat in kauf nimmt, manchmal klarer als die auseinandergezogenen Version, und es kommt vor, dass man den vermeintlich gemeinsamen Code besser schreiben kann, wenn man weiß in welchem Fall man ist. Symbolisch dann also dieses:

Code: Alles auswählen

if (foo) {
    //stuff
    //more stuff written in an optimal way w. r. t. foo
    //more foo stuff
} else {
    //more stuff written in an optimal way w. r. t. !foo
}
Ist natürlich ein tradeoff.

IntellliJ hat faktisch IDE Unterstützung für dieses Refactoring weil man dazu "nur" einen statischen Logik-Analyser braucht. Man kann folgendes machen:

Code: Alles auswählen

if (foo) {
    if (foo) {
        //stuff
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
else {
    if (foo) {
        //stuff
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
Das sind einfach zwei Kopien des ursprünglichen Codes identisch in einem if-else. Weil es nur zwei Fälle gibt und in beiden Fällen dasselbe steht, ist der Code äquivalent zur ursprünglichen Fassung.

IntelliJ kann erkennen, dass die werte der inneren ifs bekannt sind und diese abrollen bzw. entfernen ohne die Semantik zu ändern. Man _kann_ das natürlich von Hand machen, aber man macht ja manchmal auch Fehler. Also in diesem Spielzeugbeispiel vielleicht weniger, aber denkt euch realistischen Code.

Allein das gibt erfahrungsgemäß schon sehr viel Klarheit.

Was man dann am Ende, nachdem man ein bisschen damit gearbeitet hat, in den allermeisten Fällen als Ergebnis haben wird ist sowieso eher(!) dieses:

Code: Alles auswählen

if (foo) {
    handle_foo();
} else {
    handle_not_foo();
}
Weil sich eben rausstellt dass es doch zwei verschiedene Fälle sind die unterschiedlich behandelt werden und dann hat man halt für jeden der beiden Fälle eine Funktion, die den anderen Fall nicht kennen muss und innerhalb der beiden Fälle jeweils kein if und folglich auch kein Problem.

Und ja, das klingt völlig trivial, aber wie gesagt, ich habe das schon mehr als einmal in realem Code gesehen.

Die Pointe ist, dass IntelliJ das intern sehr ähnlich machen wird, wie das in dem Video gezeigte Tool, nur dass der Code halt code bleibt, was ich persönlich für einen Vorteil halte. Booleansche Logik ist nicht sooooo kompliziert und es gehört nicht viel Phantasie dazu sich ein Tool dafür zu basteln.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4252
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Chromanoid »

+1 Ich glaube das ist im Grunde divide and conquer. Da gewinnt man mit Text viel mehr Möglichkeiten. Alleine beim hin und herspringen würde ich bei den Tabellen glaube ich viel zu sehr vergessen, was ich vorher gesehen habe. Das ist ja bei Dateiwechseln schon gelegentlich schwierig. Wie durch eine Tür laufen...

Manchmal schafft man es ja auch die If-Konstrukte durch Verhaltensklassen abzulösen. Dann hat man plötzlich homogene Strategien statt einer zyklomatische Komplexitätsexplosion.
joeydee
Establishment
Beiträge: 1036
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von joeydee »

Ich beziehe mich mal auf die "Decision Table" ab ca. 2:45 im Video.
Der "Trick" dabei ist ja genaugenommen, auf "or" und "else" sowie Verschachtelungen vordergründig ganz zu verzichten und stattdessen nur noch serielle "and"-Testfolgen zu erlauben (== Tabellenspalten), was zwar erstmal nach vielen redundanten Tests aussieht, dafür aber viel intuitiver auf einen Blick zu begreifen ist, da die Struktur Stück für Stück (spaltenweise) separat betrachtet und nachvollzogen werden kann.

Dass das für bestimmte Anwendungsfälle tatsächlich Vorteile haben kann, kann ich nur bestätigen. In "Weentown" z.B. (Mini-Adventure vom vergangenen Halloween-Special) beruht die ganze Entwicklung und Notation der Spiellogik auf genau diesem Paradigma (allerdings ohne grafisches Tool, sondern direkt in Codezeilen, und auch nicht nachträglich optimiert und zusammengefasst). Ich denke, mit konventionellen if(and/or)else-Schachtelungen hätte ich schnell den Überblick verloren, bzw. die Trial-and-Error-Entwicklung der Story wäre ausschließlich hardcoded ohne Hilfsmittel so gar nicht möglich gewesen.

Der (Entwickler-)Vorteil besteht letztendlich darin, dass man in seiner Notation an jeder Stelle linear/seriell bleibt und nirgends mehr irgendwelchen Baumstrukturen geistig folgen muss (das rein geistige Merken von verschiedenen Zwischenergebnissen an verschiedenen Abzweigungen fällt Menschen i.d.R. ja eher schwer - mir jedenfalls).

Den offensichtlichen (Machinen-)Nachteil von redundanten Tests kann man entweder durch Zwischenübersetzung kompensieren, oder in simplen Fällen (wie bei mir stets der Fall) einfach hinnehmen.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Alexander Kornrumpf »

Interessante Betrachtungsweise, ich hätte behauptet, geschachtelte ifs sind in den meisten Fällen leichter zu lesen als zusammengesetzte booleansche Ausdrücke, aber wahrscheinlich gilt das insbesondere dann, wenn die Fälle an sich scchon eine natürliche Hierarchie bilden.

Sich zu "merken" in welchem Fall man gerade ist setzt schließlich voraus, dass man den Fall mental mit irgendeinem Konzept verbinden kann (sich also gerade _nicht_ ohne Kontext den Wert einzelner booleans merken muss) und das macht sein künstliches a, b, c Beispiel natürlich absichtlich kaputt.

Magst du ein Codeschnipsel aus Weentown zeigen, was den anderen Fall demonstriert?
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4252
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Chromanoid »

Sind das aber nicht genau Fälle, die man eigentlich nicht als Teil des Kompilats haben will? Das will man doch eigentlich im besten Fall während des Spielens ändern? Versteht mich nicht falsch, ich finde Entscheidungstabellen echt cool, aber eben eher als "modifizierbare Geschäftsregel", die wie Scripte eher als Daten zu behandeln sind. Natürlich verschwimmt die Trennung je nach Sprache etwas.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Tiles »

Ich finde, das sind sehr interessante Ansätze und frage mich, warum die eher ein Nischendasein fristen. Vielleicht ist es am Ende doch viel umständlicher so zu programmieren?
Ich hoffe mal ich habe das Video richtig verstanden, ich bin da nur kurz drübergeflogen. Den Tabellenansatz gibts schon ewig in Non Programming Tools wie Multimedia Fusion (formerly Click and Play. Das gabs schon zu Windows 95 Zeiten. Damit hatte ich viele Jahre meinen Spass) oder Scirra Construct oder auch der Gamemaker. Das inzwischen eingestellte Macromedia (später Adobe) Director spielt da auch mit rein, verwendete aber auch Javascript. Und auch Nodes gehören imho da mit rein. Du arbeitest mit existierenden Codeschnipseln, und verknüpfst sie entsprechend. Wieso er da im Video erzählt seine Methode würde ohne If auskommen ist mir ein Rätsel. Jeder seiner Statements da ist doch ein If. Eine Kondition. Wenn die und die Kondition eintritt -> löse die und die Aktion aus. If > then.

Eine Tabelle ist einfacher und schneller zu "programmieren". Fürs Rapid Prototyping ist das super. Aber eben auch limitierter. Du bist halt auf das angewiesen was es gibt. Und nativer Code hat die bessere Performance. Da kannst du auch eher noch was optimieren. Bei den Nodes bist du schon etwas freier in der Gestaltung. Da gibts zum Beispiel für Unreal die Blueprints. Und Unity hat den Playmaker. Das ist die modernere Variante von Non Programming. Und wenn du deinen Code komplett selber schreibst hast du halt die grösste Freiheit. Das macht allerdings auch die meiste Arbeit :)
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
joeydee
Establishment
Beiträge: 1036
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von joeydee »

Alexander Kornrumpf hat geschrieben: 05.04.2022, 13:26 Interessante Betrachtungsweise, ich hätte behauptet, geschachtelte ifs sind in den meisten Fällen leichter zu lesen als zusammengesetzte booleansche Ausdrücke
"geschachtelte ifs" vs. "zusammengesetzte boolesche Ausdrücke" wäre für das Paradigma ja kein "entweder - oder", sondern ein "weder - noch" :)
Wenn die Ausdrücke nur noch aus kommutativen And-Ketten bestehen dürfen, sind sie ja völlig ohne nachzudenken zu erfassen. Auch wenn Redundanz entsteht, sobald man das komplett ausschreibt. (Die Redundanz wird in seiner Tabelle u.a. deutlich wo in Spalte 2,3,4 ein gemeinsames "false" steht.)

fig5.jpg
fig5.jpg (59.93 KiB) 844 mal betrachtet
Diese Tab. aus dem Video wäre ja spaltenweise interpretiert und in Code ausgedrückt:

Code: Alles auswählen

            if(a==true) x=1;
            if(a==false && b==true) x=2;
            if(a==false && c==true) x=2;
            if(a==false && b==true && c==true) x=3;
Die Frage "Wann ist x=3?" lässt sich mit diesem Code auf einen Blick beantworten, im Vergleich zum im Video davor gezeigten Codesnippet.
Sollten aber in den Vergleichen und Zuweisungen Funktion angestoßen werden, kann Redundanz nicht nur unnötig, sondern gefährlich werden. Daher sage ich ganz deutlich: Ich bin kein Verfechter, dieses Paradigma überall 1:1 im Code anzuwenden, es gibt eher mehr Fälle wo das für mich absolut keinen Sinn macht.
Aber für eine State-Machine, die erst nach einem kompletten Logik-Step Dinge auslöst, wäre das Verhalten ok.

Also, gerade bei Storyentwicklung, wo sich mit der Zeit gerne mal wirre Konstrukte wie "Wenn a und b, aber nicht c, oder b und c ohne a, dafür aber mindestens 1 d, letzteres aber nur wenn, ..." bilden - was umgangssprachlich mit Kontext dann sogar noch verständlich wäre (also in einem Roman so abgedruckt und verstanden werden könnte) - da tut man sich aus meiner Erfahrung keinen Gefallen damit, zu versuchen, den Text 1:1 mit geklammerten bool-Ausdrücken und else-Verschachtelungen in einem Abwasch nachzuvollziehen.
Aber genau sowas entsteht ja oft, wenn man später NOCH eine Bedingung an einer bestimmten logischen Stelle dieser Kette einarbeiten möchte - und es kann passieren, dass dabei versehentlich ein bisher richtiger else-Zweig mit falschen Bedingungen entsteht, u.U. auch weit weg von der Änderungsstelle. Oder dass man die neue Bedingung eigentlich an mehreren Stellen einbauen muss, damit sie alle bisherigen Fälle auch wieder richtig erfasst. Oder man bemerkt, dass man den Baum durch die neue Bedingung nun ganz anders viel eleganter zusammenfassen könnte. Usw.

Wenn man solche Aufgaben stattdessen stur in reine AND-Ketten zerlegt, ohne else, können solche Änderungen deutlich leichter und besser wartbar werden. Ob man das später wieder zu eleganterem Code zusammenfasst, steht natürlich frei.
Alexander Kornrumpf hat geschrieben: 05.04.2022, 13:26 Sich zu "merken" in welchem Fall man gerade ist setzt schließlich voraus, dass man den Fall mental mit irgendeinem Konzept verbinden kann (sich also gerade _nicht_ ohne Kontext den Wert einzelner booleans merken muss) und das macht sein künstliches a, b, c Beispiel natürlich absichtlich kaputt.
Magst du ein Codeschnipsel aus Weentown zeigen
Ja, das abstrakte Beispiel am Videoanfang demonstriert nicht gerade die Praxis.
Paar Beispiele von mir wie ich das Paradigma genau nutze. Könnte zwar, aber stammt nicht 1:1 aus Weentown, denn das wäre ohne Kontext für Außenstehende wahrscheinlich noch unverständlicher :D

Erstmal zu meiner Syntax. Ich habe dafür eine sehr sehr simple String-Statemachine genutzt, eigentlich nur eine String-String-Hashtable. Ich tippe aber nicht jedesmal

Code: Alles auswählen

if(states["door"]=="open" and states["key"]=="inventory")states["message"]="dummer comment"
sondern über eine Helferfunktion abgekürzt nur

Code: Alles auswählen

exec("door?open;key?inventory;message:dummer comment");
"?" ist State-Vergleich, ":" ist Zuweisung, alle Zuweisungen in einer Zeile werden genau und nur dann durchgeführt, wenn alle zu prüfenden States der Zeile zutreffen (also ausnahmslos AND-Ketten). Vergleich ohne Zuweisung ist ebenso möglich wie Zuweisong ohne Vergleich für einen State.
Es ist außerdem keine dynamische Statemachine, die sofort irgendwelche Aktionsketten oder Events bei State-Änderung auslöst.
Damit würde das o.g. Beispiel so aussehen:

Code: Alles auswählen

            exec("a?true;x:1");
            exec("a?false;b?true;x:2");
            exec("a?false;c?true;x:2");
            exec("a?false;b?true;c?true;x:3");
Kann man jetzt anfangen händisch zusammenzufassen. Könnte man auch über einen (noch zu programmierenden) Vorinterpreter schicken der das optimiert. Kann man aber auch einfach so lassen, wenn der Code nicht zeitkritisch ist. Bei mir wird er z.B. nur 1x ausgelöst, wenn der Spieler ein Kommando wie "gehe Tür" auslöst.
Ich hätte in der Praxis evtl. noch die 3 "a?false" mit einem übergeordneten regulären if zu einem Block zusammengefasst, weil das die Lesbarkeit erhöht, mehr nicht.

Ein typischeres Praxisbeispiel, wie so eine hart gecodete Story bei mir aussieht:

Code: Alles auswählen

        //Wenn die Tür verschlossen ist und man den Schlüssel oder das Brecheisen hat, kann man die Tür damit öffnen; der jeweilige Gegenstand verschwindet bei Erfolg aus dem Inventar.
        exec("door?closed:open;command?use key with door:done;key?inv:kill;msg:I opened the door with the key.");
        exec("door?closed:open;command?use crowbar with door:done;crowbar?inv:kill;msg:I opened the door with the crowbar.");
Erste Zeile im Klartext: WENN (door==closed UND command==use key with door UND key==inv) DANN door=open, command=done, key=kill, msg=...
(Da die Syntax ja aus meiner Feder stammt, ist die für mich gut lesbar, auch wenn sie für euch jetzt sicher verwirrend erscheint.)
Was ich da in meinem Code notiere, ist also eigentlich nichts anderes als eine einfache Decision-Table, um 90 Grad gedreht.
Chromanoid hat geschrieben: 05.04.2022, 21:31 Sind das aber nicht genau Fälle, die man eigentlich nicht als Teil des Kompilats haben will? Das will man doch eigentlich im besten Fall während des Spielens ändern? Versteht mich nicht falsch, ich finde Entscheidungstabellen echt cool, aber eben eher als "modifizierbare Geschäftsregel", die wie Scripte eher als Daten zu behandeln sind. Natürlich verschwimmt die Trennung je nach Sprache etwas.
Genau. Gerade in meinem Anwendungsfall wird das ja überdeutlich, ich könnte ja jederzeit schreiben: foreach(string line in file)exec(line) und hätte damit die komplette Story raus aus dem Kompilat. Was man für eine Engine dann auch so machen würde.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2348
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Jonathan »

Mich erinnert das ganze übrigens auch ein wenig an UML-Diagramme. Die haben wir in der Schule und der Uni sehr ausführlich durchgenommen, und der Pitch klingt ja auch erstmal gar nicht so schlecht (man modelliert die Abhängigkeiten grafisch, hat eine viel bessere Übersicht, man hat eine Konzeptionsphase und eine Implementierungsphase, und so Stereotype wie "der Software-Architekt macht das Diagramm, der Inder implementiert es dann"), aber letztendlich hab ich in der echten Welt noch nie irgendjemanden gesehen, der die Dinger tatsächlich verwendet...

Bei komplizierten Designentscheidungen setzte ich mich tatsächlich manchmal erst hin und überlege mir was auf Papier oder im Texteditor. Aber das ist dann viel freier / abstrakter als UML-Diagramme. Ansonsten hatte ich bisher nie Probleme, die grobe Struktur im Kopf zu haben und die kniffeligen Details sind meist erst beim Implementieren der konkreten Funktionen aufgetaucht.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
starcow
Establishment
Beiträge: 522
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von starcow »

Alexander Kornrumpf hat geschrieben: 05.04.2022, 01:13

Code: Alles auswählen

if (foo) {
    if (foo) {
        //stuff
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
else {
    if (foo) {
        //stuff   <--- Kann doch gar nicht eintreten?
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
Sorry, falls meine Frage blöd sein sollte, aber das erste if im else-Block kann doch gar nicht eintreten?
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Alexander Kornrumpf »

starcow hat geschrieben: 07.04.2022, 15:08
Alexander Kornrumpf hat geschrieben: 05.04.2022, 01:13

Code: Alles auswählen

if (foo) {
    if (foo) {
        //stuff
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
else {
    if (foo) {
        //stuff   <--- Kann doch gar nicht eintreten?
    }
    //more stuff
    if (foo) {
       //more foo stuff
    }
}
Sorry, falls meine Frage blöd sein sollte, aber das erste if im else-Block kann doch gar nicht eintreten?
Das genau ist der Punkt, dass IntelliJ das erkennen kann und automatisch abrollen kann. Hatte ich auch oben geschrieben. Die Idee ist halt dass die IDE dir garantiert dass die Semantik gleich bleibt, wenn du sie benutzt und wenn du das von Hand machst, machst du vielleicht einen Fehler. Mit der IDE geht es auch schneller.
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 574
Registriert: 05.07.2003, 11:17

Re: Alternative Programmiermethoden zu klassischem Source Code

Beitrag von Lord Delvin »

Jonathan hat geschrieben: 07.04.2022, 13:27 Mich erinnert das ganze übrigens auch ein wenig an UML-Diagramme.
Tatsächlich ein sehr passender Vergleich.
Leute vergessen bei graphischen Darstellungen, dass eingerückter bunter Text, den in einer IDE mit Hotkeys navigiert auch nichts anderes ist.
Nur eben sehr sehr viel Kompakter als Knubbel mit beschrifteten Kanten. Für Neulinge vermutlich gewöhnungsbedürftig und wenn dir keiner zeigt wie man so arbeitet kommt man vermutlich jahrelang zu keinem produktiven Stil.

Letztlich müsste man sich statt Trivialbeispielen einfach mal ein paar Alltagsbeispiele in der Darstellung ansehen. Da wäre bei mir mein Bildschirm schnell nicht mehr groß genug für Zeug, das sonst in fünf-sechs Zeilen erledigt ist. OOP-Basching ist etwas, das immer den Redner disqualifiziert. Man kann OOP schlecht machen. Aber letztendlich gibt es nichts sonst, was einem sonst bei der Skalierung auf große Codebasen hilft.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Antworten