Buchempfehlung
Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie
Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie
Umfassend, aber leicht verständlich führt dieses Buch in die Programmierung von ATMEL AVR Mikrocontrollern ein. [Mehr Infos...]
FreeBASIC-Chat
Es sind Benutzer im FreeBASIC-Chat online.
(Stand:  )
FreeBASIC bei Twitter
Twitter FreeBASIC-Nachrichten jetzt auch über Twitter erhalten. Follow us!

Interview mit dkl

Im Dezember 2010 hatten wir Gelegenheit, dkl einige Fragen zu stellen. dkl ist Mitglied im fbc-Entwicklerteam und war für die meisten Compilerupdates der letzten Zeit verantwortlich.

Das komplette Interview

dkl, obwohl du erst 2010 zum "Core-Developer-Team" des Compilers dazugestoßen bist, bist du seit einiger Zeit der aktivste Entwickler im internationalen FreeBASIC-Projektteam und warst maßgeblich für die letzten Releases verantwortlich. Doch wie bist du eigentlich zum FreeBASIC-Projekt gekommen? Warst du bereits in der Vor-FreeBASIC-Ära in der BASIC-Nutzergemeinde aktiv?
Falls nicht, wie bist du zu so einer "exklusiven", bisher wenig bekannten, Programmiersprache gelangt?
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.
Stehst du für die Entwicklung des Compilers in regelmäßigem Kontakt zu den anderen FB-Entwicklern? Wie funktioniert die Koordination innerhalb des Teams? Und wie gut kennst du den Urvater des FreeBASIC-Projekts, v1ctor?
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.
Bekannt ist, dass du als einziges Mitglied des aktuellen fbc-Entwicklerteams aus Deutschland kommst, doch darüber hinaus weiß man in der deutschsprachigen Nutzergemeinde bisher relativ wenig von dir. An was arbeitet dkl so, wenn er nicht am Compiler arbeitet?
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.
Schon lange unterstützt FreeBASIC Windows, Linux und DOS. Welche Betriebssysteme setzt du gerne oder schwerpunktmäßig ein?
Windows XP und Ubuntu.
Als BASIC-Dialekt hat FreeBASIC oft keinen leichten Stand. Manch einer gibt der Sprache gar nicht erst die Chance, ihre attraktiven Seiten zu demonstrieren. Wo würdest du sagen liegen die wesentlichen Vorzüge von Sprache und Compiler?
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.
Ob Netzwerk-, Sound- oder Grafikprogrammierung - immer häufiger lautet in QBasic-Foren – national wie international – die Antwort sinngemäß:
"Am einfachsten wäre es, du würdest FreeBASIC statt QB verwenden, denn dort geht das problemlos."
Ist angesichts der Möglichkeiten von FreeBASIC und der Verbreitung von 64-Bit-Betriebssystemen QB endgültig tot?
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?
Ja, ein guter Punkt! :-)

Seit Beginn der Entwicklung des Compilers hat sich bei FreeBASIC ja viel getan. Was sind aus deiner Sicht die größten Meilensteine des Projekts bisher?
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.
Insbesondere im internationalen FreeBASIC-Forum gibt es bereits seit geraumer Zeit Diskussionen darüber, in welche Richtung die FreeBASIC-Entwicklung gehen soll: Einige würden sich besonders über eine Erweiterung der OOP-Features freuen; andere schlagen zum Beispiel eine große Standardbibliothek nach dem Vorbild von fbext vor, die beispielsweise "ready-to-use" Routinen für Listen, Bäume usw. enthalten könnte.
Was steht zur Zeit auf deiner Agenda, welche Neuerungen sind angedacht?
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.
OOP – bereits vorhin angesprochen – ist in FreeBASIC bisher nur teilweise implementiert. Es fehlt u. a. noch an der Möglichkeit, eine Klasse von einer anderen erben lassen zu können. Wenn die Unterstützung von OOP vertieft werden würde, an welchem Vorbild, schätzt du, würde sich OOP in FB orientieren? Java, C++ (inkl. Mehrfachvererbung), ...?
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.
FreeBASIC bietet dem Nutzer verschiedene Dialektmodi, darunter -lang qb und -lang fb. Wird die Unterstützung für verschiedene Dialektmodi auch in Zukunft beibehalten werden oder könnte es darauf hinauslaufen, dass diese zugunsten der Geschwindigkeit eingestellt wird?
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.
Aus meiner Sicht ist die portable fbgfxlib2 eins der Alleinstellungsmerkmale von FreeBASIC, das die Sprache besonders interessant macht. Beklagt wurde inzwischen, dass die fbgfxlib2 leider nicht threadsafe ist. Wie könnte die Entwicklung der fbgfxlib2 in Zukunft weitergehen? Gibt es Aussichten, dass sich jemand des Teilprojekts annehmen könnte?
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.
Vor einiger Zeit gab es im internationalen Forum eine Diskussion über das "FB-Ökosystem" und darüber, wie die freebasic.net-Website zukünftig umgestaltet werden könnte.
Welche Verbesserungen würdest du in diesem Zusammenhang für besonders nützlich halten? Könnte sich freebasic.net zu einer Art englischsprachigem FreeBASIC-Portal entwickeln?
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.
v1ctor merkte einst im internationalen Forum zum damals neuen FB-Portal an:
Too bad i don't speak german, i always have the impression that there is more information about FB written in German than in English, amazing.
Wie würdest du heute die "Quellenlage" in Bezug auf FreeBASIC beurteilen?
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.
Immer wieder sind auch die Bibliotheksheader für FreeBASIC im Gespräch. Diese stets aktuell zu halten, ist eine Mammutaufgabe. Welches Vorgehen hältst du hier für sinnvoll?
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.
Ja, das sehe ich auch so. Bisher gibt es ja immerhin schon Bemühungen, eine Header-Sammlung auf Google Code anzulegen.

Ganz aktuell wird im internationalen Forum auch besprochen, welche Möglichkeiten es geben könnte, FreeBASIC auf Mac zu portieren. Ist das mittelfristig wohl machbar? Welcher Aufwand würde dahinterstecken?
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.
Seit Anfang 2010 enthält FreeBASIC den sog. C-Emitter. Was kann man sich konkret darunter vorstellen, welche Vorteile für das Projekt ergeben sich daraus theoretisch und wie steht es um deren Verwirklichung?
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.
Könnten dadurch auch 64-Bit-Versionen des Compilers möglich werden oder wären dazu deutlich tiefgreifendere Veränderungen notwendig?
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.
Nur wenige Mitglieder der Community trauen sich, sich intensiver mit dem Quelltext des Compilers auseinanderzusetzen und Code zum fbc beizutragen.
Welche Gründe könnten dafür verantwortlich sein? Ist das Projekt vielleicht schlichtweg zu komplex, um eine breitere Entwicklergemeinde einzubeziehen?
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.
Was würdest du FreeBASIC-Programmierern empfehlen, die gerne in die Entwicklung am Compiler einsteigen würden bzw. zunächst einmal den Compilercode verstehen möchten? Hast du bestimmte Literaturempfehlungen?
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.
Welche mit FreeBASIC entwickelten Projekte fandest du besonders interessant? Hast du Lieblings-Benutzerprojekte? :-)
Am interessantesten finde ich Spiele und Development-bezogene Sachen (IDEs, Compiler, etc). Besonders aufgefallen ist mir seinerzeit syn9's Prompt Critical.
Wenn du viel Zeit hättest, was würdest du selbst eigentlich gerne einmal mit FreeBASIC programmieren?
Ich picke einfach mal eins raus:
Ein 2D-Level-mit-quadratischen-Feldern-basiertes Spiel zum Thema Strichmännchen.
Vermutlich bist du ja in einigen IT-/Programmierbezogenen Internetcommunities unterwegs. Was ist an der FreeBASIC-Community besonders?
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.
Zum Schluss noch ein bisschen Orakeln... ;-) Wo denkst du steht das FreeBASIC-Projekt in – sagen wir – 2 Jahren?
Bei 0.5.
Vielen Dank für deine Antworten und die Zeit, die du dir für das Interview genommen hast! Wir wünschen dir weiterhin viel Spaß und Erfolg beim Projekt und freuen uns schon auf viele weitere Repository-Commits des Users dkls! ;-)