RUN-Talk - Wie geht es weiter mit GFA-Basic?
RUN! Software ist sicher jedem GFA-Programmierer ein Begriff und neben RGF Software die wohl wichtigste Firma für Anhänger des Basics. Seit einiger Zeit ist es aber sehr ruhig um RUN! geworden, im Gespräch packen sie aber aus: neues faceVALUE, ein Update von ergo!pro und ein neuer GFA-Editor versprechen den darbenden GFA-Programmierern neue Hoffnung.
Von RUN hat man in der letzten Zeit nicht mehr viel gehört, was habt ihr inzwischen gemacht?
Hallo Matthias! Zunächst einmal - das wissen unsere Kunden in der Regel - sind wir teils berufstätig, teils im Studium. Unsere Haupttätigkeit kann daher leider nicht bei RUN! liegen. Während ich 1998 eines unserer Produkte, faceVALUE, entsprechend amateurhaft verkaufte, tauchte auch bei Ulli Gruszka plötzlich der Bedarf auf, seine Weiterentwicklung von einem anderen Produkt, ergo!pro, zu vertreiben. Wir beschlossen, mein Geschäft hierzu zu verwenden, das Ganze dabei zu verheiraten und auch professioneller zu verpacken. RUN! war geboren. Seitdem versuchen wir so professionell wie eben möglich unseren Kunden entgegenzutreten. Aber auch diese wissen, dass wir uns leider primär um unsere Berufe kümmern müssen. Dies war in den letzten 18 Monaten bei uns allen sehr verstärkt der Fall.
Untätig waren wir jedoch nie. Wann immer es unsere Freizeit zuließ, haben wir an einem GEM-Editor für GFA-Basic-Quelltexte gearbeitet. Seit einigen Wochen geht es endlich auch wieder bei ergo!pro, faceVALUE und BASTARD weiter.
Was ist bei RUN in nächster Zeit geplant?
Nun. Wir sind keine Hektiker. Es gibt Menschen, die das bemängeln, es gibt aber auch solche, die gerade das gut finden. Wir arbeiten an einer (vielleicht endgültigen) Version von ergo!pro, an einer leicht fortgeschrittenen Version von faceVALUE, ein neuer BASTARD kommt in Kürze, und natürlich: unser Editor soll es endlich in die ernste Testphase schaffen. Wir setzen uns dabei keine zeitlichen Ziele, weil wir die ohnehin nie einhalten. Nur manchmal möchte ein emsiger Redakteur auf Teufel komm raus einen Termin hören. (Grins.)
Ah ja. Wie war das noch gleich mit einem Termin?
Unseren eigenen Hoffnungen nach schaffen wir dies noch in diesem Jahr. Aber das Jahr ist nur noch kurz.
ergo!pro und faceVALUE sind zweifelsohne Produkte, ohne die kaum noch ein GFA-Programmierer auskommt. Wie war bisher die Resonanz der User?
Die Resonanz ist nicht groß, aber äußerst positiv. Wir haben leider nach wie vor nur wenige Kunden, was insbesondere auch damit zusammenhängen könnte, dass wir nicht im englischsprachigen Raum vertreten sind. "Exporte" gehen meist in die Niederlande, ganz selten nach Skandinavien, Großbritannien oder Frankreich. Wir arbeiten an der Zweisprachigkeit, aber auf unterster Flamme. Die Kunden, die sich melden, melden sich meist sehr engagiert mit Lob und Kritik. Der Konsens ist eigentlich, dass unsere Richtung stimme, in der Ausführung es jedoch auch mal schneller gehen dürfe.
Für Beta-Tester gibt es schon seit einiger Zeit eine neue Beta von faceVALUE. Wann kommt ein offizielles Update?
Wir hoffen in diesem Jahr. Die Arbeit findet momentan an der Doku statt, aber es juckt uns schon die ganze Zeit, die Engine - also die grosse Bibliothek - so zu zerhacken, dass endlich auch wirklich schlanke faceVALUE-Programme entstehen können. Wir hatten dies bereits einmal vorgenommen, aber ehe wir die Arbeiten abschließen konnten, mussten wir an einer alter Version weiterarbeiten. Diese Modularisierung wäre ungeheuer wichtig, auch für die zukünftige Weiterverwendbarkeit. Hier müssen wir sehen, was die (Frei-)Zeit bringt. "Notfalls" gibt es ein Zwischenupdate.
Was wird die Version leisten?
Gearbeitet wurde eher an "Kleinigkeiten" wie einer verbesserten Cursor-Navigation, an Copy/Paste in Eingabefeldern, an neuen Hilfsfunktionen im Fensterhandling, bei BubbleHelp oder bei GEMScript - und daneben natürlich auch an der Fehlerreduzierung. Wer sich aber ernsthaft mit dem Thema Benutzeroberfläche auseinandersetzt, wird wissen, wie wichtig dabei "Kleinigkeiten" sind. Eine große Sache gab es jedoch: Das ehemals englische faceVALUE wird nun endlich zweisprachig. Uns geht es auch hierbei zunächst um die deutsche Sprache: Alle Ausgaben sind nun auch in deutsch möglich.
Lohnt es sich für nicht RUN-ler überhaupt, Code an euch zu schicken? In der Vergangenheit wurden Code-Einsendungen (z.B. OLGA) nur spärlich berücksichtigt?
Ja - selbstverständlich lohnt es sich. Zu meiner Schande muss ich gestehen, dass ich zum Thema OLGA keine Einsendung auf meiner Platte finden kann. Wohl aber zu anderen Themen, die teilweilse in der Tat auch in der aktuellen Version noch nicht Einzug erhalten haben. Andererseits gibt es auch Einsendungen, die sehr schnell berücksichtigt wurden. Wenn etwas nicht schnell umgesetzt wird, dann hat es oftmals damit zu tun, dass es konzeptionelle Änderungen am leider nicht perfekten faceVALUE bedürfte.
Ich möchte aber in dem Zusammenhang gerne auch darauf hinweisen, dass faceVALUE seit der Version 2.0 bereits eine sehr weite Modulschnittstelle besitzt. Wo immer möglich sollte ein Einsender seine Routinen in ein solches Modul (ein "WRINKLE") verpacken. Wir helfen gerne bei der Feinarbeit und beim Einhalten der Standards. Diese Module sind sofort für jeden faceVALUE-Benutzer einsetzbar.
In faceVALUE gibt es einige Funktion die fehlen, z.B. Registerkarten oder scrollbare Editfelder. Was tut sich dort in Zukunft?
Gerade das sind zwei Dinge, die wie oben angesprochen zumindest nicht sofort in aktuelle Konzepte von faceVALUE passen. Gerade dafür (nicht zu vergessen sind auch die Kontext-Popups, um die drei meistgefragtesten Funktionen zu komplettieren) wäre der genannte Umbau der Engine so wichtig. Erst wenn die Modulstruktur geklärt ist, können einschneidende Veränderungen durchgeführt werden. Entmutigen sollen diese Worte nicht. Wir wollen die Sache richtig machen und hoffen selbst, endlich Zeit dafür zu finden. Aber wenn man genau hinsieht, dann handelt es sich bei den drei Funktionen auch gleichzeitig um Funktionen, die wir vermutlich für unseren Editor bald auch selbst brauchen werden. Man sollte nicht vergessen, dass wir hin und wieder auch selbst eine Anwendung entwickeln, und nicht nur Werkzeuge. (Grins.)
Warum sollte jemand auf den neuen GFA-Editor wechseln, wenn der alte, gewohnte Editor mit BASTARD funktioniert?
Wer in der BASTARD-Lösung tatsächlich bereits das Ende der Fahnenstange sieht und damit zufrieden sein sollte, den werden auch wir nicht zu einem Wechsel bringen können. Aber wenn der RUN!-Editor so wird, wie wir ihn uns vorstellen, wird er für jeden ernsthaften GFA-Programmierer unumgängliche Vorteile bringen.
Selbstverständlich gibt es eine unmittelbare Syntaxprüfung, es gibt weiterhin die Befehlsabkürzungen und es wird die faltbaren Unterprogramme geben (daran wird gerade gearbeitet). Die wichtigste Errungenschaft der letzten Monate war jedoch, dass der Editor nicht nur ein Editor im (un)gewohnten GEM-Ambiente sein wird, sondern dass er auch einen RUN-Knopf erhalten wird.
In vieler Nächte Arbeit haben wir (und spätestens hier muss der Name von Ingo Schmidt, dem dritten RUN!-Mitglied genannt werden) eine Möglichkeit gefunden vom originalen GFA-Basic-Editor die Interpreterfähigkeit abzuspalten. Die erste Version des RUN!-Editors wird dies nur spärlich ausnutzen. Wichtig ist hier zunächst, dass der Interpreter als sauberer Prozess läuft, selbst unter den höchsten Sicherheitsstufen, die MiNT derzeit zu bieten hat, und dass im Falle eines Laufzeitfehlers wie gewohnt der Cursor in der Programmzeile landen wird, in der der Fehler auftrat. Aber für spätere Versionen sind Funktionen möglich, von denen man als GFAler bislang nur träumen konnte. Verraten dürfen wir hier leider noch nichts.
Basic-Dialekte auf anderen Systemen kennen viele Befehle, die das Programmieren angenehmer und übersichtlicher machen, z.B. einen einzigen Befehl um Sounds abzuspielen. Wird es in der Richtung etwas im GFA-Editor geben?
Nun, den Befehl um eine Sounddatei abzuspielen, findet man in faceVALUE - er heißt call_gemjing. (grinst schon wieder) Dank richtet sich in diesem Zusammenhang an Götz Hoffart für GEMJing.
Aber zur Sache: Wir sehen nicht ganz den (eindringlichen) Sinn für neue Befehle. Letztendlich unterscheiden sich in Basic die Anweisungen und die Unterprogrammaufrufe nur deshalb syntaktisch, weil die Basic-Interpreter sie unterschiedlich behandeln müssen. In anderen Programmiersprachen gibt es diese Unterscheidung nicht. Wichtig ist daher in diesem Zusammenhang nicht der Einbau neuer Befehle sondern vielmehr das Realisieren einer Modulschnittstelle, wenigstens in Form von einbindbaren Bibliotheken. Dann kann man bliebig und austauschbar neue "Befehle" (sprich: Unterprogramme) einbinden. Dies ist natürlich angedacht.
Kurioserweise akzeptieren Basic-Programmierer einen Befehl erst dann als neuen Befehl, wenn er sich auch syntaktisch von den Unterprogrammaufrufen abhebt. Wir wissen nicht wieso, aber wir sehen das genauso. Daher denken wir in der Tat darüber nach, Aufrufe von Bibliotheksroutinen im Editor wie die von eingebauten Anweisungen darzustellen. Das hat aber in der momentanen Phase keine Priorität.
Bei all den Änderungen stellt sich natürlich die Frage: Wann kommt ein vollständiges RUN!Basic?
Diese Frage stellen wir uns oft. Mit dem gleichen Schmunzeln im Gesicht. Gerade die Frage, ob man nicht die Energie, die man in den GFA-Editor steckt, nicht lieber in ein eigenes Entwicklungssystem stecken sollte, tauchte häufig in unseren Köpfen auf. Man sollte wissen, dass die OT/OB-Lib letztendlich nur ein "Abspaltprodukt" des Editors ist, und deren Entwicklung schon in das Jahr 1996 zurückgeht. Aber hier hat letztendlich immer wieder die (Fehl?-)Einsicht gesiegt, zunächst mal überhaupt ein aktuelles Entwicklungssystem zusammenzustellen, ehe man ein völlig eigenes entwickelt. Und deshalb arbeiteten wir emsig weiter am GFA-Editor und nicht am RUN!-Basic. Insgeheim hoffen wir auch, mit dem Editor (nennenswerte) finanzielle Unterstützung zu erhalten, was wir damit begründen, dass dieser auch in den englischsprachigen Raum verkauft werden kann. Zumindest könnten die Kapazitäten in diesem Raum dann mal ausgelotet werden. Von der Unterstützung wird es letztendlich abhängen, wie und wie schnell wir an einem neuen Entwicklungssystem arbeiten können. Aber wenn wir uns an solche Dinge heranwagen, erinnern wir uns auch stets an die zeitliche Differenz zwischen 1996 und 2003, die es brauchte, um den GFA-Editor zu realisieren - wenngleich wir sicherlich nicht bei Null anfangen müssen.
Hat GFA angesichts der vielen Patches noch Zukunft?
Die "vielen" Patches beziehen sich meist auf den Editor und den Interpreter. Glücklicherweise sind hier die oben genannten Fortschritte gemacht. Die anderen betreffen den Compiler und seine Komponenten - doch deren Zahl ist ja eher gering, wenn nicht sogar gleich eins. Unglaublich große Verdienste hat hier Richard Gordon Faika mit seiner Licom-Lib und dem, was dazugehört, erzielt. In ruhigen Winternächten denkt Richard bestimmt weiter darüber nach, den Compiler vielleicht doch noch selbst zu stricken. Die Sprache "GFA" dient ihm wie uns als Grundlage. Sie ist eine wichtige Schnittstelle, um überhaupt etwas aufbauen zu können. Dem Produkt "GFA" messen wir nur deshalb noch eine Rolle in der Zukunft bei, weil es sich - wenn auch mit schwindendem Anteil - immer und immer wieder als funktionierendes Werkzeug behauptet hat. Aus irgendeinem Grund wurden entdeckte Mängel von vielen findigen Leuten ausgeräumt, nie jedoch so, dass das Produkt komplett ersetzbar geworden wäre. Man denke an den Versuch von GFA-Basic 4, der genau daran jämmerlich gescheitert ist.
So etwas wie ein Basic-Dialekt ist für jedes System wichtig - sonst droht es entweder auszusterben oder zu "verkommerzialisieren". Wenn man von Karsten Lüdersens Omikron-Publikationen absieht, sind uns aus den letzten Jahren keine nennenswerten Veröffentlichungen in anderen Basic-Dialekten bekannt. Dagegen scheint uns subjektiv gesehen bei GFA-Basic noch richtig "was los zu sein" - gerade bei den kleinen Programmen wie bei aICQ, dem MiNT-Setter oder Gunnar Gröbels PPP-Programmen, um nur einige Beispiele zu nennen von anderen GFA-Programmen wie Luna und Homepage-Penguin mal ganz zu schweigen.
Wie beurteilt ihr den Atari-Markt zur Zeit?
Wir beobachten mit Freude die rege Entwicklung im Open-Source-Bereich. Leider können wir uns daran nur bedingt beteiligen, weil wir auch weiterhin vorhaben, an Messen usw. teilzunehmen - und das kostet Geld. Vielleicht schaffen wir einen Beitrag einmal dahingehend, dass aus faceVALUE-Programmen die Kunden-Anteile leicht heraustrennbar gemacht werden, damit auch solche Programme "open source" werden können. Gerade Marc Anton Kehr leistet mit faceVALUE sehr viel um den Open-Source-Bereich herum, ohne bspw. selbst seine Quelltexte veröffentlichen zu können - falls er das überhaupt möchte.
Wir denken, beides ist richtig und wichtig: Open-Source garantiert Projekte, die nicht einfach aussterben können, kommerzielle Produkte garantieren jedoch ein gewisses Kapital, das einfach nötig ist, um Kommunikation wie die Messen und die Druckmedien bereitzustellen. Sollte man zum Beispiel bei Woller, bei ROM logicware, bei invers und anderswo weiter vorankommen - womit wir übrigens ja wieder im Open-Source-Bereich wären, denn der aktuelle GNU-Compiler ist ja Voraussetzung für ein Papyrus 10A -, wäre vermutlich genug finanzieller Rückhalt da, auch die kommende Zeit anzupacken. In diesem Zusammenhang bauen wir auch weiterhin auf die gute Arbeit der ST-Computer.
Haltet ihr einen eigenentwickelten Clone oder eher eine Emulator-Lösung (z.B. ARAnyM) für sinnvoll?
Das ist schwer zu sagen. Ich selbst habe mit PC-Hardware selten gute Erfahrungen gemacht. Normalerweise immer dann, wenn es um Ausnahmesituationen ging, gab es Probleme. Auch der Energieverbrauch ist in meinen Augen überzogen. Daher bin ich eher abgeneigt gegenüber Emulatoren, die auf PC-Hardware basieren. Andererseits scheint es immens schwer zu sein, ein (bezahlbares) Trägersystem mit nicht-PC-Hardware zu finden, insbesondere seit Apple wieder dicht gemacht hat und die Hardware wieder ausschliesslich selbst herstellt. Wenn irgendwer die Energie aufbringt, einen neuen Clone auf die Beine zu stellen und die Hardware entsprechend zu dokumentieren, hätte er bei uns in jedem Fall schonmal zwei Kunden gefunden. Unterdessen sollten die Programmierer, die es nicht ohnehin schon tun, darauf hinarbeiten, portable Programme zu schreiben. Andernfalls kommen wir nie von der 68k-Architektur weg - egal ob mit Emulator oder Clone.
Noch ein paar letzte Worte an die Atari-Gemeinde?
Danke - nein. Dazu ist es nämlich noch viel zu früh! :-)))
Vielen Dank für das Gespräch keep on RUN!ning ;)