Interview mit dkl

Zu FreeBASIC bin ich über eine Google-Suche gekommen, daran erinnere ich mich noch recht gut. Anfang 2005 war ich dabei, mit IBasic herum zu programmieren, denn damit konnte ich richtige Windows Fenster erstellen, richtige Programme, und richtige .exe Dateien, und nicht einfach nur 16-bit QBasic Konsolenprogramme. Das einzige Problem war, IBasic war nicht kostenlos, also habe ich dann nach "free basic" gesucht, und tatsächlich FreeBASIC gefunden. Als ich dann die Windows API Beispiele gesehen hatte (damals wusste ich noch nicht, was genau das denn war), war alles perfekt. Seitdem hab ich – mit FreeBASIC sozusagen – zuerst die Windows API, und dann die Open-Source-Welt, andere Sprachen, etc. kennengelernt.
Mit der QBasic Community hatte ich nichts zu tun, damals wusste ich nicht einmal, dass es sie gibt.

Das Team hat ein Development-Forum, darüber lief und läuft die meiste Kommunikation. Alles andere ist schwierig, wegen unterschiedlicher Zeitzonen. Für normale Bugfixes ist auch kaum Diskussion nötig, aber für andere Sachen muss man dann schonmal die Initiative ergreifen. Hauptproblem ist nach wie vor mangelnde Freizeit, abgesehen davon, dass viele das Projekt verlassen haben. Ich glaube, früher, so um FreeBASIC 0.15 - 0.18 herum, war viel mehr los.

Ich bin jedenfalls nicht der erste Deutsche im Team, mjs war ja lange Zeit dabei. Im Moment bringe ich viel Zeit für FreeBASIC auf; dafür habe ich andere Projekte, und auch eigene Projekte, erstmal aufgegeben.

Windows XP und Ubuntu.

FreeBASIC ist kostenlos, quelloffen, der Compiler ist selbst in FreeBASIC geschrieben, das ganze ist stabil, es ist C-kompatibel, läuft auf Linux, und hat eingebaute Grafikfunktionen. Welches andere BASIC kann das von sich behaupten? Man muss dieses Projekt einfach mit einer Portion Spaß und Liebe sehen. Nicht jeder wird es so super finden, aber viele haben es doch liebgewonnen.

Mich würde es freuen, wenn FreeBASIC entsprechend aktiv weiterentwickelt wird, um dauerhaft in der Lage zu sein, diesen hohen Anspüchen gerecht zu werden. Ob wir jetzt QB ersetzen oder nicht, ist egal, solange wir bei Anfängern den Programmiergeist wecken können. Können das andere Sprachen, andere Communities, außer QB/FB?

A) Die C-Kompatibilität, die alles erst möglich macht, und B) die Festlegung auf -lang qb, -lang fblite und -lang fb. Über die Richtung der Sprache gab es damals heftige, derbe Diskussionen, ich finde es beachtlich was das Team damals durchgesetzt hat.

Alles kommt sobald sich jemand drumkümmert. Wenn nichts passiert, heißt das, dass keiner daran arbeitet. Ich versuche momentan, den Compiler umzukrempeln, denn im Moment sind einige Dinge (wie z. B. Templates) gar nicht möglich, weil die Entwicklung zunächst nicht darauf ausgerichtet war.
Im Prinzip könnte man aber die meisten Sachen jetzt schon hinzufügen; wenn denn jemand Lust und Zeit hätte. Letztendlich darauf ist die aktuelle Entwicklung ja auch aus.
Aber es gibt auch noch so viele andere Sachen zu tun – die Laufzeit-/Grafik-Bibliotheken würden sich über Wartung oder andere Ansätze freuen, das Wiki und damit die ganze Dokumentation muss am Laufen gehalten werden, und Releases müssen gemacht werden.

Ich glaube v1ctor plante in Richtung Java, einfache Vererbung mit Interfaces. Allerdings trotzdem C++ kompatibel, so weit. Da denke ich mir, ok, dass ist schon irgendwo BASIC-like, aber wenn wir schon GCC's C++ ABI implementieren, dann können wir auch gleich aufs Ganze gehen, und dafür dann mehr C++-Bibliotheken direkt benutzen. Die Frage ist nicht einmal ob, sondern wer, wann und wie genau.

Wenigstens -lang qb wird erhalten bleiben werden müssen, denn wo wäre denn sonst der Spaß an der ganzen Sache, immerhin hat FB ja als 32bit QB angefangen. Und ohne -lang fblite gäbe es wieder massive Beschwerden der oldschool-FB Fans, das bleibt also auch.
Die einzelnen Dialekte machen im Compiler kaum einen Unterschied, erst recht nicht im Bezug auf Geschwindigkeit; es sind hauptsächlich ein paar Optionen die sich ändern, und einige Stellen im Parser, der eben gucken muss, welche Konstrukte jetzt erlaubt sind und welche nicht.

Ich habe von zwei verschiedenen Personen gehört, dass sie ein neues gfxlib schreiben wollen, aber mehr Konkretes gibt es nicht. Im Moment gibt es also leider keine direkten Pläne, außer vielleicht den ein oder anderen Bug zu beheben. Es wäre super, wenn sich jemand finden würde. Das gfxlib ist gar nicht so groß, allerdings steckt trotzdem eine Menge Arbeit drin, um die verschiedenen Modi/Treiber zu implementieren.

Eine bessere Website wäre wichtig. Die beiden Personen, die direkt in der Lage wären, die Website zu ändern, haben keine Zeit, und vermutlich ist das ganze auch nicht einfach. Ich bin mir nicht sicher, ob sich 1) jemand anderes findet, der sich mit dem Thema Website/Forum/CMS auskennt, und 2) derjenige Zugriff auf alles bekommen würde; das wäre eben eine schwierige Sache.

Die deutsche Community hat allerdings ein beeindruckendes Portal, besonders das Wiki ist der Hammer. Und das ist so auch nötig, immerhin kann nicht jeder Englisch. Ich glaube sowieso, dass Deutschland viel mehr OpenSource-Fans hat als manche anderen Länder (siehe Firefox, Ubuntu).
Die wichtigsten Quellen sind die Foren, ob nun das Englische (Original), das Deutsche, das Russische, oder ein anderes. Die Wikis kommen noch dazu, um eben ein gewisses Nachschlagewerk zu liefern. Außerdem gibt es sogar ein paar Youtube-Videos über FreeBASIC. Alles in allem finde ich es beeindruckend, was in den Wikis geleistet wurde. Was wir da haben, ist wertvoll.

Die Headers müss(t)en stets neu-übersetzt und dann bereitgestellt werden. Das ist nunmal Handarbeit, für die sich jemand finden muss. Und es werden ja auch immernoch Headers übersetzt, nur bis jetzt gibt es keinen Platz, wo man diese richtig unterbringen könnte.
Ein solches Projekt muss her, wo dann jeder leicht Headers abliefern kann, diese dann unter Umständen geprüft werden, und dann als Downloads zur Verfügung gestellt werden. Mit dem FreeBASIC Projekt selbst haben die Headers ja nicht so viel tun; FreeBASIC Releases können auch nicht immer alle verfügbaren Headers beinhalten, sondern man müsste sich diese (abgesehen vielleicht von den meist-benutzten) dann zusätzlich installieren.

Das kommt ganz auf die Fähigkeit der Person an. Vielleicht wird es mit einem grundsätzlich erneuerten fbc einfacher. Ich glaube, das wichtigste hier ist machbar, siehe AT&T Emitter. Danach müsste noch jemand ein gfxlib für Mac OS X schreiben; das stelle ich mir schwierig vor.

Der C-Emitter existiert grundsätzlich schon seit Jahren. Zunächst gab es ja die Idee, ein GCC Frontend zu machen. Dann aber den C-Emitter. Dann vielleicht ein LLVM Frontend. Alles, um FreeBASIC eben weiterzubringen, in den Bereichen OOP, Optimierungen, Portabilität. Mit dem C-Emitter erstellt fbc also C (für GCC) anstatt Assembly. Und GCC kann das dann wiederum compilen, aber eben für wesentlich mehr Systeme. Das läuft inzwischen auch ganz gut.
Für mich ist das aber nur eine Art Notlösung. Eigene Optimierungen im ASM Emitter wären mir viel lieber. Ich habe auch keine Lust, irgendwann mal FB zusammen mit GCC bereitstellen zu müssen.

Für 64bit wären noch mehr Änderungen nötig als nur ein C- oder x86_64-ASM-Emitter, diese Sache berücksichtige ich auch gerade.

Anfangs war für mich das Schwierigste, dass es keinen Einstiegspunkt gibt. Oder anders gesagt, es fehlt die Übersicht, weil man keinen Plan hat, was das Ding eigentlich so macht. .bas wird zu .asm, aber wie? Hinzu kam noch eine gewisse Unerfahrenheit mit Programmieren im Allgemeinen. Wer sich bei den ein oder anderen Konstrukten noch unsicher ist, kann sich in fbc schnell verirren, denn da geht es drunter und drüber. So hat sich fbc eben entwickelt, im Laufe der Jahre der Chicken-Egg-Probleme und neuen Features.
Ich arbeite auch daran, das aufzuräumen, denn es wird ja immer oft gesagt, der Code sei so unverständlich. Aber an der allgemeinen Struktur gibt es nicht viel zu rütteln, und man muss sich den Überblick irgendwie verschaffen.
Es gibt da aber leider keine Dokumentation; deswegen habe ich versucht, eine solche im Wiki anzufangen, aber auch das ist ungeheuer zeitaufwendig. Immerhin funktioniert fbc ja, der Code kann also kein kompletter Müll sein.

Ich würde sagen, im Laufe der Jahre ergibt sich die Erfahrung eben. Man fragt nach und lässt es sich erklären (das ist definitiv das Beste). Man guckt sich den Source Code an, ständig. Bei jeder Besonderheit, bei der man sich fragt, was würde fbc damit anfangen: in den Source Code reingucken und es rausfinden, schließlich muss alles ja irgendwo implementiert sein.
Bei mir lief es häufig so ab: Ich arbeitete an einem eigenen FreeBASIC Projekt, und brachte fbc zum Absturz. Also, fbc selbst mit -exx neu kompiliert, um zu sehen, wo der Crash passiert. Dann in diese Funktion reingeguckt. Oder eben ewig lange rumgesucht, siehe "caveman debugging". So kriegt man ein Gefühl für den Code. fbc ist auch nur ein FreeBASIC Programm, da gibt's keine Besonderheiten. Irgendwann findet man dann die Stelle, an der etwas falsch ist, z. B. ein Pointer, der NULL sein kann, aber nicht darauf überprüft wird, schreibt den Code leicht um, und erstellt einen Patch.

Am interessantesten finde ich Spiele und Development-bezogene Sachen (IDEs, Compiler, etc). Besonders aufgefallen ist mir seinerzeit syn9's Prompt Critical.

Ich picke einfach mal eins raus:
Ein 2D-Level-mit-quadratischen-Feldern-basiertes Spiel zum Thema Strichmännchen.

Die Community (Zumindest die Englische, die ich seit Jahren kenne) gefällt mir gut. Es ist schön, wie leicht man da Hilfe finden kann, ohne auf Ablehnung zu stoßen.

Bei 0.5.