Momentan bin ich, auch aufgrund meiner beruflichen Situation, mal wieder ziemlich damit beschäftigt, meine alten Ideen von damals mal wieder nach vorne zu bringen.
Es geht vor allem um mein Sorgenkind, was man schon fast als Vaporware bezeichnen könnten… RapidBATCH 6. RapidBATCH ist ein Projekt, welches ich 2001 mit 15 Jahren begonnen habe und was Aufgrund durch eine immense Medienpopularität wahrlich äusserst bekannt geworden ist: Eine einfache Batchsprache mit EXE-Compiler. Programmiert, damals, in QuickBasic. Der Compiler war natürlich eher Fake, es war eher ein Obfuscator, der Code an einen Interpreter, der diesen Code aus sich selbst ließt und dann ausführt, hängt. Aber es hatte den anschein, man hätte einen EXE-Compiler. Selbiges Konzept ging bis zur Version 5.1, die letzte veröffentlichte RapidBATCH-Version einher.
Nach dem Release der (leider immer noch aktuellen) Version 5.1 und meiner damaligen privaten Situation (die nicht sehr rosig war) habe ich mich sehr viel mit dem Thema Compilerbau beschäftigt. Das hat aber dann immer mehr dazu geführt, dass die Ideen von damals immer mehr in Frage gestellt wurden… es musste immer besser werden… was auch der Grund ist warum es kein RapidBATCH 5.2 gab, welches sogar in seiner damaligen Beta-Version einen echten Rekursiv-Descent Parser mit sich brachte. Aber es war mir zu heikel, dass damals weiter zu machen… RapidBATCH 6 wurde prototypsiert… und immer weiterentwickelt. Bis hin zu einer wahrlich soliden Basis. Aber sie war mir nicht *perfekt* genug. Ich könnte mir eigentlich sowas von in den Arsch treten damals diese Entscheidung getroffen zu haben. Die Sourcen davon habe ich alle noch, aber sie sind sowas von inkompatibel mit der aktuellen libphorward, welche schon damals in Teilen existierte… man kann sie nicht einfach mal umbiegen und alles läuft so wie vorher.
So ein Scheiß… RapidBATCH 6 war vollends prototypisiert… es hatte einen sogar opimierenden Compiler, basierte vollständig auf einer stack-basierten Virtual Machine namens Phosphor, implementierte bereits eine Basis-Version (konsolenbasiert) der urspünglichen Version 5.1 mit zusätzlichen Features der Version 6
- Ein ECHTER Compiler!
- Verschachtelte Funktionsaufrufe
- Neue Schleifen WHILE…WEND und EACH…IN…NEXT
- Assioziative Arrays
Ich hatte Klaus F. und Andi H. im Boot… die wären mitgegangen… ich hab es vergeigt.
Bitte…hier… seht euch diese geilen Screenshots an… es ist unglaublich, was das Ding damals konnte… ein geniales Stück Software, doch geschrieben für die Katz.
Und nur eine Auswahl der damaligen Demo-Programme, die bereits FUNKTIONIERTEN….
|
|
[i] = 6 [a:'Hello'] = 'Hello' func bla: [d] print [d] ret [d] # [d] endfunc [a:bla( 'Hello' )] = bla( 'yeaah' ) print [a:'HelloHello'] |
und
|
|
[str] = 'Hello World' [p] = getlen( [str] ) print 'Die länge von "' # [str] # '" beträgt ' # [p] # ' Zeichen!' print 'Und das Zeichen an Offset 4 ist "' # getcharat( [str], 4 ) # '"' [i] = 0 repeat [i] = [i] + 1 print 'Zeichen an Offset ' # [i] # ' ist "' # getcharat( [str], [i] ) # '"' until [i] = getlen( [str] ) |
…verdammt, ich könnte kotzen, wenn ich dran denke, das alles in die Tonne gepfeffert zu haben. Scheiss Drang zur Perfektion. Scheiss Entscheidung. Alles für’n ARSCH. SCHEISSE!!!
Was hab ich davon heute? UniCC… ein Parser Generator den kein Schwein braucht und der völlig überladen ist. Aber es musste sein. Sowas wie ein Ziel, das erreicht werden muss und keinen Sinn macht. Jetzt bastel ich mir wieder einen zurecht und baue die libphorward zum Multi-Paradigma Parser Generator mit verdammten Features die keine Sau jemals nutzen wird… und dann diese leeren Versprechungen… RapidbATCH 6, die Vaporware, die Niemals kommt… NEIN. Ich will das verdammt nochmal nicht mehr.
Ich wünschte, ich könnte die Zeit zurückdrehen, nach 2008, und mir selbst in den Arsch treten, diesen Weg beschritten zu haben. RapidBATCH hatte seine Chance und ich habe sie vollends in den Sand gesetzt. Alles mir zu verdanken, einem Volldeppen, der mit seiner Perfektion nicht zurecht kam.
Tja, was haben wir heute. Einen haufen Sourcecode, der nicht übersetzbar ist. Nicht ohne massive Anpassung.
- phosphor, die Virtual Machine
- rb6core, der RapidBATCH 6 Sprachkern mit Compiler
- rb6, die RapidBATCH 6 Sprachlibrary mit den Funktionen
Alles nicht mehr übersetzbar. Zu viel zu ändern. Zu viele Ansätze, es besser zu machen.
Ich muss eigentlich nochmal von vorn anfangen, und dann das beste in einem ganzheitlichen Projekt zusammenfassen.. aber selbst das rede ich schon seit Jahren. Immer wieder diese Versuche.
Nur wenn, dann alles als freie Software. Ich glaube, dass RapidBATCH nur so eine Chance hat, weiter zu leben, und vielleicht doch noch mal Anklang in der seit Jahren treuen Community zu bekommen. Die es trägt und was draus macht. Einen anderen Weg gibt es nicht. Und einen anderen Weg will ich auch nicht.
Seit einigen Jahren dümpelt in meinem Sourceverzeichnis auch noch das Verzeichnis rapidbatch rum. Ein Ansatz, das alles unter ein neues Dach, basierend auf libphorward und UniCC, zu bringen. Bisher nicht sehr viel Inhalt. Nur lose Module, ohne wirklichen Zweck und Zusammenhang. Hier mal eine Graphik, da mal ein fetzen Code.
Es muss weiter gehen. Es MUSS.
Ab morgen hab ich den Rest der Woche Urlaub. Möchte das gute Wetter nutzen und fliegen gehen. Und wer weiß… vielleicht schraubt sich diese Tage doch mal ein Entschluss zusammen, der RapidBATCH doch noch dahin bringt, wo es einst in einem Prototypen auf einem sehr gutem Wege war… es wird Zeit… es muss Zeit werden. Es MUSS.
