[Projekt] Type Research Programming Language

[Lord Delvin]

Zu Closures:
Ich mag fn, fun und Co. überhaupt nicht. Da finde ich es in Typescript schöner: type TaxCalculator = (amount: number) => number;.Nur whitespaces und Wörter als Trenner kommt mir immer irgendwie komisch vor, weil sich dadurch meist keine schöne "natürliche" Weise ergibt, wie Linebreaks und Einrichtungen zu laufen haben.

Eigentlich ging es um Funktionstypen, Typescript verwendet dieselbe Syntax aber für beides. Das wäre bei mir nicht möglich, weil ein Typ ein Wert ist und bei gleicher Syntax kein Mensch mehr verstehen würde, was gemeint ist. Eigentlich hat mich TypeScript jetzt final davon überzeugt, dass ich das mit den Namen doch gleich einbaue und dafür aber die Syntax mit dem "def" nehme, weil es für nichttriviale Typen am lesbarsten ist.

[Lord Delvin]

Ehrlich gesagt, ich verstehe das Beispiel und deine Ausführungen dazu nicht. Ich denke dass Leute die schonmal mit Java oder JavaScript gearbeitet haben, erwarten dass sie sowas machen können (Pseudocode)

Code: Alles auswählen

collection.removeIf(element -> element.property > someQuasiConstantFromOuterScope)

Hab' da mal was vorbereitet :)

Code: Alles auswählen

var buff = "HÖLLä".chars().toBuffer()
buff.removeIf c do (c > 'L')
"HLL".chars().sameElements[character.`==`](buff.iterator())

Das removeIf bindet eine lokale Variable c und einen Ausdruck in () oder {} und wendet ihn auf jedes element in buff an.
Ausführlichere Tests: https://github.com/tyr-lang/stdlib/blob ... Buffer.tyr
Und die Implementierung: https://github.com/tyr-lang/stdlib/blob ... r.tyr#L142

Hab' jetzt die Funktionstypliterale, Funktionstemplates, ein paar Bugs gefixt und leider auch teilweise eine neu Templatetyptheorie. Wird wohl mit Generics weitergehen :)

[Lord Delvin]

Hatte irgendwann Abends nebenher mal angefangen eine ArrayDeque zu implementieren. Tat in ein paar Tests, aber irgendwie nicht in einem mit 100 Elementen. Weil ich immer nur mit Compilerbugs konfrontiert bin, dachte ich aber irgendwie, der Code sei ok und der Compiler hat eine Macke. Gibt schon länger valgrind-Integration. Also valgrind angeschaut; sagt irgendwas von write. Ratlos gesucht, nichts gefunden, was auf einen Bug hindeutet. Naja wenn man sich das anschaut, sieht das so aus:

Code: Alles auswählen

==55238== Command: ./main.1.tests
==55238== 
==55238== Invalid write of size 8
==55238==    at 0x401301: ??? (tyr.container/ArrayDeque.tyr:112)
==55238==    by 0x404701: main.T test loop (main/main.tyr:15)
==55238==    by 0x404701: main (unkown:0)
==55238==  Address 0x4a5d0f8 is 8 bytes after a block of size 64 alloc'd
==55238==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==55238==    by 0x4046D1: tyr.container.ArrayDeque[tyr.lang.String].new(tyr.container.ArrayDeque[tyr.lang.String],tyr.lang.container.index_t):tyr.lang.void (tyr.container/ArrayDeque.tyr:52)
==55238==    by 0x4046D1: main.T test loop (main/main.tyr:9)
==55238==    by 0x4046D1: main (unkown:0)
==55238== 
==55238== Invalid write of size 8
==55238==    at 0x401301: ??? (tyr.container/ArrayDeque.tyr:112)
==55238==    by 0x40470F: main.T test loop (main/main.tyr:16)
==55238==    by 0x40470F: main (unkown:0)
==55238==  Address 0x4a5d100 is 16 bytes after a block of size 64 alloc'd
==55238==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==55238==    by 0x4046D1: tyr.container.ArrayDeque[tyr.lang.String].new(tyr.container.ArrayDeque[tyr.lang.String],tyr.lang.container.index_t):tyr.lang.void (tyr.container/ArrayDeque.tyr:52)
==55238==    by 0x4046D1: main.T test loop (main/main.tyr:9)
==55238==    by 0x4046D1: main (unkown:0)
==55238== 
whob==55238== 
==55238== HEAP SUMMARY:
==55238==     in use at exit: 0 bytes in 0 blocks
==55238==   total heap usage: 3 allocs, 3 frees, 1,128 bytes allocated
==55238== 
==55238== All heap blocks were freed -- no leaks are possible

Wenn man jetzt einen Schritt zurücktritt stellt man natürlich fest, dass ich in den ArrayDeques das Problem habe, dass die validen Elemente über den Rand des backing Arrays hinaus an den Anfang wrappen. D.h. einfach data(end++) ist jetzt *nicht direkt* die richtige Implementierung für ein append.

Ich muss einfach mehr an mich und meine Tools glauben :-/

Was ich ehrlich gesagt nicht ganz verstehe, ist, warum der clang memory sanitizer nichts sinnvolles beizutragen hatte. Letztlich bedeutet das für das Projekt aber, dass ich die Check-Bounds-Optionen spätestens mit 0.9 reinbauen werde. Brauch dafür aber erstmal Exceptions. Und vielleicht freie Variablen in der Templatetyptheorie; muss ich mal schauen.

[Lord Delvin]

Hatte in letzter Zeit wenig zu erzählen, weil ich entweder keine Zeit hatte oder nur an Dingen gearbeitet habe, die mir wenig erwähnenswert erschienen. Jetzt bin ich an einem Punkt, an dem ich mal wieder was entscheiden muss. Hab's mal hier aufgeschrieben. Mir noch etwas unklar, was ich von der Plattform halten soll; egal.
Im Kern mache ich gerade mit mir selbst aus, wie ich switch über den Typ des Ziels implementieren soll. Also grob etwas um schreiben zu können:

Code: Alles auswählen

switch e := nextEvent() {
  if MouseEvent { ... }
  if KeyBoardEvent { ... }
  else { ... }
}

Und e soll natürlich den Typ haben, den das if testet, wenn man es verwendet. Bin gespannt, wie sich das anfühlt, wenn ich's gebaut habe :)

[Lord Delvin]

Bin gerade mal wieder in der Hölle der impliziten Casts am Aufräumen. Weil sich bei mir gerade einige Flexibilisierungen ergeben würden, die mir teilweise unplausibel erscheinen, wollte ich mal wissen, was C++ macht. Da gilt "Conversion functions can be inherited and can be virtual, but cannot be static. A conversion function in the derived class does not hide a conversion function in the base class unless they are converting to the same type.", was mich sehr irritiert, weil es bei mir bis jetzt immer andersrum war. Hat jemand eine Idee, was deren Problem mit static ist?
Ich frage mich gerade ernsthaft, ob ich mir gerade sehr hart in den Fuß schieße oder ob das einfach aus meiner "representational transparency" kommt.

[Lord Delvin]

Hab' mal wieder versucht, das was ich mache und die Hintergründe in einem Artikel zu beschreiben: https://medium.com/@feldentm/tyr-2-towa ... 723a25d4ac

Diesmal gehts um Call Operator und was da so alles dran hängt.

[Lord Delvin]

Und noch was habe ich aufgeschrieben: https://medium.com/@feldentm/tyr-3-elab ... 0e6dcce64b

Diesmal geht's um Konsequenzen mit denen man Leben muss, wenn man alle Vorwärtsdeklarationen automatisch vom Compiler machen lässt.

[Lord Delvin]

Habe gerade geprüft, wie gut LLVM meinen switch class code optimieren kann. Es stellt sich raus, dass der test

Code: Alles auswählen

var r = ""
switch class r {
  if String false
  if StringLiteral true
  else false
}

einfach komplett rausoptimiert wird. Wenn man ihn kaputt macht, z.B. indem man r mit null initialisiert, dann wird er zu false rausoptimiert. Genau so, wie ich mir das gewünscht habe. Zeigt einmal mehr, wie sehr man auch i.A. LTO haben will :)

[Lord Delvin]

Habe die letzten Tage gelernt, dass break und continue einfach doch eine ganze Ecke komplizierter sind, als man eigentlich denken würde und einen Artikel dazu geschrieben. Ich hatte ja am Anfang des Projekts gesagt, dass man für brauchbare Forschungsergebnisse aus dieser Spielzeugsprachenecke raus muss. Ist tatsächlich so und liefert manchmal sehr verblüffende Erkentnisse. Am Ende hatte ich tatsächlich ziemlich viel Spaß damit die ganzen verrückten Sachen wie do while über Funktionszeiger zu testen und zu sehen, dass es jetzt alles zusammenpasst :)

[Lord Delvin]

Weil ich immer wieder Diskussionen führe, wie man Software testet, habe ich einen Artikel geschrieben, in dem ich einen Schritt vor dem Release beleuchte, bei dem man sich die Coverage anschaut und versucht darauf basierend Beispiele zu finden. Im Kern Whitebox-Integrationstests. Keine Ahnung ob es jemandem wirklich hilft. Habe ein paar Beispiele reingepackt; teilweise finde ich's erschreckend, teilweise sind es nur obskure Randfälle, die eh keinen getroffen hätten.

Das Release ist jetzt auch fertig. Screenshots mit einem SDL/OpenGL Dreieck hatte ich glaube ich schon gezeigt. Langsam muss man da echt einfach mal Content hinstellen, damit Leute sehen, dass es wirklich brauchbar ist.

Erkenntnis für die Community hier ist vermutlich, dass zwei Jahre schon ein grenzwertig weiter Schritt ist. Ungeachtet der Motivation. Und was am Ende unerlässlich ist, ist sehr viel Disziplin auch unangenehme Sachen zu machen, wie sechs Monate Refactoring, um Architekturprobleme zu beseitigen, intensives Testen und eben einfach Bugs fixen. Das gilt natürlich genauso für irgendwelche Spiele, die ich darauf aufbauen würde, weil man da genauso erreichen muss, dass es beim Release irgendwie Sinn ergibt und lustig ist und nicht einfach crasht. Feinschliff ist immer Aufwand.

[NytroX]

Glückwunsch zum Release! :-)

was am Ende unerlässlich ist, ist sehr viel Disziplin auch unangenehme Sachen zu machen

Ich glaube das ist der Nummer 1 Grund warum Hobbyprojekte nicht fertig werden. Inklusive meiner.
Man muss sich halt echt Zeit nehmen, Tests schreiben, Coverage durchgehen usw. damit da ein gutes Produkt draus wird.

[Lord Delvin]

Das intern über Status/Either/Error zu machen verursacht halt im regulären Code verteilte Kosten

Ja, stimmt. Das ist das größte Problem daran. Allerdings verursachen Exceptions das auch - einfach weil der Compiler plötzlich aufhört, Cross-Function Optimierungen zu machen.
Für mich sieht ein
int f(int a, int b) throws c halt immer automatisch aus wie
void f(int* ret, c* ex, int a, int b)
Das macht übrigens auch die Rückgabe schneller als ein Rückgabewert. Aber der Compiler macht das meist schon alleine, und muss es in einigen Situationen auch tun nach dem neuen C++ Standard. Jai macht das auch so, weil schneller.
Nachteil ist aber hier: mehr Argumente bedeutet ggf. mehr Register Usage beim Aufruf - und damit ggf. auch auslagern auf den Stack, was es dann wieder langsamer macht.

Also wie mans macht, es hilft alles nichts. Irgendwie muss man die Fehler mitbekommen und behandeln, die perfekte Lösung ist noch nicht gefunden :-)

https://www.open-std.org/jtc1/sc22/wg21 ... 1947r0.pdf

Da drin wurde der Sache schonmal auf den Grund gegangen. Ein paar interessante Auszüge:

Schemes that consider an exception throw as just an alternative return path was considered different: not C++ exception handling

=> Dummer Kommentar von mir: ÄÄh, warum? ;-P

simply demonstrating that a throw is slower than a return does not demonstrate a violation [of the zero-overhead principle]

=> returns sind also schneller

Alternative schemes based on “markers” in stack frames were tried early on, but their performance was deemed inferior

=> Tabellen-basierte Abarbeitung ist also relativ optimal für Exceptions ohne Rückgabewerte.

In Summe ist das soweit ich weiß immer noch Stand der Dinge.
Siehe auch hier der Talk von Herb Sutter: https://www.youtube.com/watch?v=ARYP83yNAWk&t=1200s

Wenn ich also eine Programmier-Sprache entwerfen würde, dann würde ich die schnellste aktuell bekannte Methode verwenden, die auch die Compiler noch gut optimieren -> Rückgabewerte (bzw. mit Syntactic Sugar).
Natürlich kannst du auch neue Wege gehen - im Paper steht auch dass es für den tabellenbasierten Ansatz durchaus noch Optimierungspotenzial gibt.

Würde mich auf jeden Fall interessieren wie es am Ende bei dir aussieht :-)
Zu den versteckten Kosten auch, finde ich super spannend was du da findest :-)

Mal schauen ob ich die Diskussion hierher verlegen kann.
Danke auf jeden Fall für den Link; sollte ich vielleicht auch nochmal spezifisch drauf eingehen. Irgendwie isses aber zu warm um klar zu denken, was zu schreiben oder weiter zu programmieren. Für Haus mit Klimaanlage verdiene ich zu wenig :-/

Also erstmal, weil ich's hier noch nicht verlinkt habe: https://medium.com/@feldentm/designing- ... b54a550e7a
Mein größtes Problem ist tatsächlich erstmal das Memorymanagement, weil ich sicher nicht C++ RTTI oder RAII implementieren werde.
Hatte so schon drei drafts rumliegen, vermutlich schreibe ich aber erstmal dazu einen Kommentar, weil ich weniger drüber nachdenken muss und man direkt was spannendes sagen kann und mir auch bei meinen Begründungen Zusammenhänge klar geworden sind, die ich sonst vermutlich nicht kommuniziert hätte. Für mich ist C++-ABI-Kompatibilität natürlich kein Ziel. Mandat für mich sind derzeit POSIX, ELF, DWARF. Ob ich Itanium ABI EH nehme oder das wirklich clang oder gcc kompatibel mache entscheide ich später. Zumal ich demnächst vermutlich den vierten Ansatz implementiere, weil die cross function optimization tatsächlich für mich was kritisches ist. Habe einen Test dazu geschrieben und wenn ich's nicht optimiert bekomme, sobald da ein finally in der Standardbibliothek steht muss ich mir deutlich überlegen, ob ich nicht aufgebe. In der Größenordnung wie ich das in Tyr machen will, könnte man das in C++ höchstens als LTO implementieren. Bin mir aber nicht sicher ob man das da bezahlen will, weil ich erwarten würde, dass man die erforderlichen Informationen nochmal herleiten müsste.

Zu deinen Fragen:

1) Weil das Go-style errors sind, sich das wie in Go verhält, mit struct schon immer ging und ein komplett anderes ABI hat.

2) Return ist erstmal erheblich schneller. Goto auch. Das ist nicht der Punkt; er schreibt eigentlich ganz passende Fragen auf, die man sich an der Stelle stellen muss. Für mich, insbesondere aus der Praxis, spannend, ist die Frage nach Wurfdistanz und Wahrscheinlichkeit. Wenn du eine Konfigurationskonsistenzprüfung hast, dann ist die Wahrscheinlichkeit quasi null, du undwindest vermutlich den Großteil deines Stacks. Sein bad_alloc Beispiel finde ich auch passend. Für das allermeiste was ich in meinem Leben gesehen habe ist es vollkommen ok so einen Java-style stacktrace in dem Fall zu haben und sich dann zu überlegen, was schiefgegangen ist. Kenne auch Ecken, wo man das fangen will. Selbst wenn man das fängt und einfach durch Lastabwurf löst ist es extrem unwahrscheinlich. Da die Chance vermutlich <1:1mio. Da willst du nicht aus jedem new einen Fehlerwert rausbekommen, falls es vielleicht nicht gut lief und erst recht nicht manuell bis ans Workpackagemanagement unwinden.

3) Nein, da geht's denke ich um was anderes. Du könntest Handleraddressen in deinen Stackframe packen. Das hat aber wieder verteilte Kosten im Gutfall.

Meine persönliche Position wäre ehrlich gesagt nicht zu sagen, dass man die 1:100 kassiert, sondern eher 1:1mio. Würde früher oder später in meine Tests auch ein nothrow reinbauen, was im Prinzip deaktiviertes Exceptionhandling wäre. Vielleicht unter anderem Namen. Ich meine, 1:100 würde bedeuten, dass man sich bei 'nem Mittelgroßen ArrayBuffer einfach den Rangecheck schenkt und auf die Exception beim Überschreiten des Rands hofft. WTF?

Wo's unklarer wird ist sowas wie JSON deserialisieren, dass man von irgendwoher bekommt. Wäre meine Lebenserfahrung aber auch eher, dass man voll auf den Gutfall optimieren will. Das meiste ist dann doch Maschinenkommunikation die das richtig macht. Momentan wäre mir aber nicht mal klar, wie man das seriös benchmarkt. Zumal ich eine local throw optimization habe und das binder inlining; vermutlich muss man ne breite Menge an Fällen benchmarken und hoffen, dass man am Ende irgendwas draus schließen kann.

[Lord Delvin]

So, habe jetzt mal meine Gedanken zu dem Thema aufgeschrieben: https://medium.com/@feldentm/exception- ... 6b6d5cf4fe
Wenn ich das endlich mit in die Templates reinbekommen habe, dann kann ich aufschreiben, was ich am Ende machen will. Vorher ist es nicht sinnvoll, weil ich einfach zu viel ändere und spätestens in drei Monaten anfangen will die anderen Themen fertig zu machen, die ich für das Release haben will, weil's sonst wieder zwei Jahre dauert und nicht eins. Mal schauen; immerhin haben die Exceptions ein paar natürliche Schnittkanten, an denen man ein paar Releases abwarten kann, weils nur abstruse Randfälle sind.

[Lord Delvin]

(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.

[Schrompf]

Du wirst sicherlich wissen, wovon Du da redest, aber ich weiß es nicht. Irgendein theoretisches Konzeptproblem in Deiner Programmiersprache? Hab ich das richtig verstanden? Und jetzt weißt Du nicht, wie's weitergehen soll?

Falls es das ist, dann: reparier es doch. Du hast doch keine Nutzer, oder? Also kannst Du umwerfen und saubermachen, wie es nötig ist. Ist doch Dein Baby.

[Lord Delvin]

Falls es das ist, dann: reparier es doch.

Ja, richtig ;) Nein im ernst. Mir ging's nicht darum, das Problem selbst zu beschreiben, weil ich's selbst auch nicht verstanden habe. Es gingen etwa 70 Integrationstests nicht und mir war nicht klar warum und nach wochenlangem Suchen auch nicht klar, wie ich weiter machen sollte.

Was geholfen hat, war ein paar mal einen Schritt zurück zu treten und dann mit einem letztlich zufälligen anderen Integrationstest weiterzumachen. Ich war zurecht der Meinung, dass ich's nicht verstehe. Glücklicherweise war es am Ende nur ein Fehler, der quasi alle Tests kaputt gemacht hat. Eine Zeile Code, keine 10 Zeichen Editdistanz. Allerdings muss ich sagen, dass ich verstehe, warum ich das nicht gleich richtig gemacht habe. An der Stelle hat man mindestens drei plausibel wirkende Optionen und ich hatte mich halt für eine falsche entschieden. Tatsächlich war erst die dritte die richtige.

Bleibt aber trotzdem irgendwo die Frage, wann man sein Hobbyprojekt aufgeben würde, wenn man feststeckt ;)
Sechs Monate Umbau ohne erkennbare Aussicht auf Erfolg ist für mich zumindest grob die Schmerzgrenze.
Ist halt auch so ein Softwareding, dass du nichts sagen kannst und dann eine Zeile Code änderst und danach noch etwa einen Tag brauchst, um dir sicher zu sein, dass es wirklich funktioniert. Bin jetzt zumindest an einem Punkt, an dem ich alle nicht-Exception Integrationstests schaffe, die jemals gingen.

[Schrompf]

Ah, verstehe. Und ja, das ist ne knifflige Frage. Ich habe schon manches Projekt zu Grabe getragen, weil ich an irgendnen kritischen Problem feststeckte. Aber es gibt ja auch Leute mit mehr Durchhaltevermögen.