(muss ein bisschen Gedanken zu Projektmanagement aufschreiben und kanalisieren; vielleicht hilft's ja wem)
Wenn man sich die Aktivität meines Githubprofils anschaut, würde man meinen, ich hätte in den letzten sechs Monaten einfach nichts mehr gemacht. Tatsächlich war ich aber relativ aktiv. Das ganze wurde von einem scheinbar banalen Test ausgelöst:
Code: Alles auswählen
type def id(p : Block[void]) = p.eval()
type def twice(p : Block[void]) = id(p)
test "twice identity" {
twice({return true})
}
Was passieren müsste: id und twice binden jeweils Blöcke und evaluieren sie einmal. Der Witz hier: twice gibt seinen Parameter unevaluiert weiter. Mit eval wäre es vermutlich seit Tyr 0.4 gegangen. Ohne eval sollte es auch gehen, schließlich sind die Typen gleich und es wäre nicht wirklich vermittelbar, warum es dann nicht gehen sollte.
Ich hatte das glaub' irgendwann letztes Jahr gemerkt und gedacht, dass man's einfach nebenher machen kann.
Das war ein ziemlicher Irrglaube. Der Punkt ist, dass man durch's weiterreichen von p irgendwo in der Mitte der Substitution, die das {return true} einsetzen müsste zwei unterschiedliche Sichten auf p auf dem Stack hat und die alte Substitutionstheorie annahm, dass das nicht passieren kann. Im Kern wurde unten p durch p' ersetzt, obwohl man gleich {return true} hätte einsetzen müssen.
Irrglaube Nummer zwei war, dass man einfach Substitutionen delegieren kann, um "nach oben zu schauen".
Der Irrglaube hieran ist das "einfach".
Eine tatsächlich spannende Erkenntnis unterwegs ist, dass meine Tests zwar insgesamt sehr gut sind, aber gerade bei den Substitutionen doch noch zu einfach.
Was ich durchs Delegieren gelernt habe ist, dass viele Tests eher zufällig funktioniert haben, aber bei größeren Stapeln abwechselnder Substitutionen nicht mehr korrekt gewesen wären. Teilweise sind die Seiteneffekte auch an falsche Stellen substituiert worden, was man nicht gemerkt hat, weil sie insgesamt nur einmal da waren und die Gesamtzahl für den Test somit korrekt war. Wäre in der Praxis auch erstmal in Ordnung gewesen.
Nun der Teil, der eigentlich nichts spezielles mehr mit meinem Projekt zu tun hat und der mich seit etwa zwei Monaten beschäftigt:
Der Sinn von Arbeit ist, ein Ergebnis zu produzieren.
Wenn man irgendwo steckenbleibt, dann sollte man sich zumindest mal überlegen, ob man nicht einfach zurückkehrt und einen anderen Weg nimmt.
Bei mir z.B. den Test ins nächste Release verschieben und wirklich nur noch strikt die Exceptions implementieren.
Was im Prinzip dafür spräche wäre, dass ich wieder releases machen kann, neue Releases definieren und an Features bzw. Integration arbeiten; eigentlich sind auf der Roadmap bis zur 1.0 außer Integration kaum noch Features übrig.
Ich könnte Artikel schreiben und Themen abschließen.
Was auch dafür spricht ist, dass ich nach sechs Monaten das gefühl habe, ein unabsehbar tiefes Loch gegraben zu haben. Ich bin pro verfügbare Zeit langsamer als früher, weil ich eine Substitutionstheorie entworfen habe, die jedweder Intuition entbehrt und weil die motivierenden Erfolge ausbleiben.
Allerdings muss man sagen, dass ich durch die neue Substitutionstheorie jede Menge Fehler gefunden habe.
Das was ich da mache ist unzweifelhaft richtig.
Außerdem bin ich nicht in der Lage, einfach vor dem Umbau zu forken, das Release fertig zu machen und die Änderungen dann zu mergen.
Der Kern meiner inneren Architektur ist nicht mehr API-kompatibel und da ist auch nichts zu machen, schlicht weil Delegation ein anderes Zustandsmanagement erfordert.
Ich will hier keine "du schaffst das" Reaktionen provozieren; die Frage an die Runde ist eher, was man für gute Optionen hat und was die erwartbaren Auswirkungen wären bzw. womit ihr gute Erfahrungen gemacht habt. Was ich selbst sehe:
Durchhalten; in der Hoffnung, dass das Ende des Tunnels bald erreicht ist.
Das Projekt aufgeben; was mit AI machen, das ich als Student mal angefangen habe und damals gruselig fand. Etwas komisch, nach acht Jahren aufzugeben, wenn man vom Zielumfang grob 90% geschafft hat.
Die Roadmap aufgeben und alle Architekturumbauten auf der Roadmap direkt umbauen. Die Option mag ich nicht besonders, da sie zwar erfolgversprechend ist, aber a) ein Todesmarsch und b) das Problem eigentlich auch ohne Sachen, die ich erst im nächsten Release bauen will, lösbar sein *sollte*.
Bigtech-Style Programmiersprachen Entwicklung: Was nicht geht ist einfach schlechter Stil. D.h. einen Stylechecker bauen, der das Problem versteckt oder das Blockpassing entfernen und behaupten, dass das eigentlich nie hätte gehen dürfen. Der Ansatz widerstrebt mir und und widerspricht auch dem Zweck des Projekts, aber ich glaube ich hätte zumindest bei vielen verbreiteten Sprache Beispiele dafür. Ehrlich gesagt habe ich gerade etwas gezuckt als mir klar wurde, wie viele mir sofort eingefallen sind.