Interview mit helium© Thomas Antoni, Januar 2004
|
Vorwort von Thomas Antonihelium ist ein unerbittlicher Verfechter eines guten Programmierstils. Mit Proben seiner Programmierkünste macht sich helium aber leider sehr rar. Es gibt da kaum etwas von ihm, was man im Internet herunterladen könnte. Ich freue mich, dass helium mir dieses Interview gewährt hat und wir nun interessante Dinge über seine Hobbies und Projekte erfahren werden. InterviewThomas: Wie kommst Du eigentlich zu dem Nicknamen "helium"? Hat das mit der Sonne zu tun (griech. hélios = "Sonne"). ) oder mit dem "Luftballon-Gas"? helium: Ich weiß selbst nicht mehr, wie ich dazu gekommen bin. Ich habe ihn auf jeden Fall schon etwas länger. Ich weiß nur noch, dass ich mit 'nem Freund im Schwimmbad war und wir uns über Nicknames unterhalten haben und ich da irgendwie auf "helium" gekommen bin. Thomas: Dann hat es wohl doch etwas mit der helios-Sonne zu tun, denn bei Regen geht man wohl kaum ins Schwimmbad :) Wie lautet eigentlich Dein richtiger Name? helium: Der wird nicht verraten (Datenschutz :)) Thomas: Wie alt bist Du und wo wohnst Du? helium: Ich bin 20 und damit wohl einer der älteren QB- Programmierer. Ich wohne in Burscheid, einer kleinen 20000- Einwohner- Stadt nahe bei Leverkusen. Thomas: Naja, es gibt schon noch wesentlich ältere QB- Fans. Ich selber bin 56, und die älteste Person in meiner QB-Adresskartei ist ein 79-jähriger Professor! helium, was machst Du ausbildungs- bzw. berufsmäßig? helium: Ich bin an einem Kolleg für Informatik in Köln. Dort bilde ich mich zum Informatisch-Technischen Assistenten aus und mache gleichzeitig noch mein Fachabi. Thomas: Hast Du eine eigene Webseite? Wenn ja: Was erwartet den Besucher dort? helium: Jein. Ich habe zwar eine Webseite mit der Internetadresse http://helium.piranho.de. An der habe ich aber seit über zwei Jahren nicht mehr wirklich was getan. Im Moment arbeite ich gelegentlich an einem grundlegenden Update. Hauptsächlich wird es um C++ und um VST gehen. VST ist eine Schnittstelle für Audioplugins. Der QB-Teil wird auf meiner Seite recht kurz ausfallen. Aber es gibt ja genügend andere gute Seiten zu dem Thema. Thomas: Wie sieht Dein Webdesign-Konzept aus? Mir fällt auf, dass Du bei Deinem QB- Modern ein helles, luftiges und schlankes Design verwendest. helium: Das stimmt. Ich mag diese total überfüllten Designs nicht. Ich hab ein wenig 'rumexperimentiert und bin zu dem Schluss gekommen, das mir helle Designs besser gefallen. OK, das Design meiner alten Site ist nicht grade hell, aber es ist auch schon ziemlich alt. Bei völlig übeladenen Designs braucht man Ewigkeiten, bis man endlich erkennt, wo sich denn eigentlich der Teil befindet, den man gerade sucht. Es gibt beispielsweise Freemail-Anbieter, bei denen man in einem riesigen Haufen von Bildchen, Text und sonstigen Elementen irgendwo einen winzig kleinen Link 'raussuchen muss, um sich überhaupt anzumelden. Thomas: Die Vorabversion Deines "Modernes QB" finde ich übrigens äußerst vielversprechend. Damit füllst Du eine echte Lücke. Endlich mal ein Tutorial, das viele Fragen von fortgeschrittenen Programmierern beantwortet und diesen wertvolle Tipps gibt. Doch nun weiter in unserem Interview: Deine HTML-Seiten setzen keinen besonderen Browser und keine besondere Bildschirmauflösung voraus. Du legst also offensichtlich Wert darauf, dass möglichst jeder Surfer sie lesen kann. helium: Ja, auf jeden Fall. Wenn ich auf eine Seite komme, die mir sagt, dass man am besten den Internet Explorer und eine Auflösung von 800x600 verwenden sollte und ich gerade unter Linux mit dem Konquerer in einer Auflösung von 1024x768 arbeite und deshalb ein total verfälschtes und zudem viel zu kleines Gebilde vor mir auf dem Bildschirm habe, dann regt mich das irgendwie auf. Solche Seiten besuche ich garantiert kein zweites mal. Ich will schließlich, dass möglichst viele Besucher meine Texte lesen können und nicht nur eine kleine Gruppe von Leuten irgendwelche Spezialeffekte sieht. Natürlich sollte das Ganze trotzdem ansprechend aufgemacht sein. Wenn man eine Seite hässlich findet, wird man wohl nicht so gerne auf ihr verweilen. Thomas: Ich habe ein wenig in Deinen HTML-Quellcode "hineingespitzt" und festgestellt, dass Du keinen visuellen WYSIWYG-Editor verwendest, sondern den braven, rein textbasierten Text-Editor "Phase 5" von Ulli Meybohm. helium: Ja. Das ist der beste mir bekannte HTML-Editor. Er erleichtert einem das Schreiben, indem er automatisch die Abschlusstags anfügt, etc. Und irgendwie liegen mir WYSIWYG-Editoren nicht sonderlich. Ich schreibe den Code lieber selber. So weiß ich genau, dass mein Code sich an den W3C-Standard hält und meine Seite mit allen Browsern korrekt angezeigt wird, die zu den W3C- Konventionen kompatibel sind. Thomas: Du lagerst fast alle Formatfestlegungen in ein extenes CSS-Stylesheet aus ... helium: Ich finde das viel bequemer als tausende von verschachtelten Tags, durch die ich nachher selber nicht mehr durchblicke. Außerdem kann man sein Design so viel leichter anpassen. Wenn man denkt "och die Überschriften könnten doch ein wenig dunkler sein", dann kann man einfach in der zentralen Stylesheet-Datei die Farbe ändern statt sich durch Unmengen von Dateien zu wurschteln. Thomas: Außerdem verwendest Du Grafiken sparsam und legst offensichtlich auf schnelle Ladezeiten wert. helium: Meine eigene Internet-Anbindung ist recht langsam, und ich will auch auf andere Surfer mit langsamem Internetzugang Rücksicht nehmen. Ich wüsste auch gar nicht, wie ich dutzende von Grafiken sinnvoll einsetzen sollte. Thomas: Wie war Dein Werdegang als Programmierer? helium: Ein Freund von mir hat die Grundlagen von QBasic von seinem Vater gelernt, als wir in der fünften Klasse waren. Ich glaube, das war 1992 oder 1993. Der hat es mir dann beigebracht. Anfangs haben wir uns die meisten Informationen selbst aus der QBasic- Onlinehilfe zusammengesucht. Später habe ich dann www.qb45.com entdeckt, das zu der Zeit das größte QBasic-Portal überhaupt war. Da habe ich Unmengen gelernt. Inzwischen ist die Gemeinschaft dort ziemlich geschrumpft. Um meinen Horizont ein wenig zu erweitern, habe ich ein wenig C aus einem Buch gelernt. Das war glaube ich 1998. Viele Dinge gefielen mir an C irgendwie besser als an BASIC. Aber da ich totaler Anfänger war, bekam ich Vieles einfach nicht hin. Deswegen bin ich erstmal bei QBasic geblieben, denn hier hatte ich inzwischen schon ein einigermaßen großes Wissen. 2000 habe ich mir dann mal C++ angesehen. Anfangs verstand ich das objektorientierte Programmieren überhaupt nicht, da ich quasi mein Leben lang prozedural programmiert habe. Als ich es dann endlich begriffen hatte, wollte ich es nicht mehr missen. Die Vorteile sind einfach gigantisch. Von da an habe ich mich nur noch mit C++ beschäftigt. Inzwischen habe ich sogar "Modern C++ Design" von Andrei Alexandrescu gelesen, eines der besten Bücher für weit Fortgeschrittene. Durch diesen Buchtitel bin ich übrigens auf den Namen "Modernes QB" gekommen, von dem du ja bereits die Vorabversion kennst. Für die, die es nicht kennen: Es ist ein Tutorial, das sich mit Themen für Fortgeschrittene und Profis in QB beschäftig. Beinahe hätte ich es vergessen: An der Schule in Informatik habe ich ein wenig Object Pascal gelernt - besser bekannt unter dem Namen "Delphi". Das ist eine der am meisten verbreiteten Entwicklungsumgebungen. Wenn ich heute das Programmieren anfangen sollte, wäre Delphi vermutlich die Sprache der Wahl, da es recht einfach zu erlernen ist, aber dennoch moderne Programmiertechniken unterstützt. In letzter Zeit habe ich mir auch mal einige andere Sprachen angeguckt. Ich habe sie nicht wirklich gelernt, sondern nur so eine Art kurzen Crashkurs gemacht - einfach um zu erfahren, was es sonst noch so gibt. Falls es jemanden interessiert: Die interessantesten Sprachen,die ich gefunden habe, sind BETA, Lisp und Haskell. Der recht bekannte Quicksort-Algorithmus sieht in Haskell beispielsweise so aus: qsort [] = [] qsort (x:xs) = qsort [y | y <- xs, y < x] ++ x ++ ... ... qsort [y | y <- xs, y >= x]Kürzer gehts wohl kaum :) Thomas: Was ist das denn nun das Schwierige an der objektorientierten Programmierung mit C++? helium: Es geht eigentlich nicht speziell um C++, sondern um die Objektorientierung allgmein. Man geht einfach ganz anders vor. Man muss lernen, zu erkennen, welche Objekte es in dem Problem gibt, das das Programm behandeln soll, und welche Fähigkeiten und Eigenschaften diese Objekte haben und welche davon wiederum wichtig für die Lösung des Problems sind. In QB schreibt man Prozeduren. Denen gibt man dann ihre Daten, und die arbeiten damit. Anschließend erhält man möglicherweise ein Ergebnis oder sie schreiben bzw. malen etwas auf den Bildschirm oder machen irgendwelche andere Datenausgaben. In der Objektorientierung gibt es keine Trennung zwischen Daten und Prozeduren. Es gibt nur Objekte. Ein Objekt hat seine Daten, die der Benutzer des Objekts aber eigentlich nie zu Gesicht bekommt. Angenommen du schreibst ein Strategiespiel mit Panzern. Dieses Spiel soll realistisch sein, weshalb der Panzer nur eine begrenzte Menge Treibstoff hat. In einem objektorientierten Programm würde man einfach einem Panzerobjekt sagen, dass es irgendwo hin fahren soll: toller_Panzer.fahre_nach(Bielefeld);
Wenn der Panzer Sprit hat, wird er das tun, wenn nicht, wird er irgendwann
einfach stehen bleiben. Darum muss ich mich aber nicht kümmern. Das macht das
Panzerobjekt selber. Wie das Ganze implementiert ist, interessiert mich nicht.
Ich verwende einfach die Schnittstelle, die mir ein "Panzer" zur Verfügung
stellt. Hier ist 'fahre_nach' ein Teil dieser Schnittstelle. Derjenige, der die
Panzerklasse geschieben hat, kann jederzeit die komplette Implementierung
und zwar nicht nur der Prozeduren, sondern auch der Datendarstellung modifizieren,
ohne dass ich als Benutzer der Klasse irgendetwas an meinem Code ändern muss.
Eine Klasse ist die Beschreibung dessen, wie ein Objekt funktioniert.
Um das etwas besser erklären zu können, verwende ich jetzt mal ein anderes Beispiel: Nehmen wir ein Programm, das Personaldaten verwaltet. Es merkt sich Namen und Adresse. In QB vielleicht so realisiert: Type Person name As String strasse As String Ort as String Postleitzahl as Integer End TypeNatürlich werden noch ein paar Prozeduren dazu geschrieben. Jetzt verwenden einige Leute diesen Typ mit den dazugehörenden Prozeduren. Der Autor des Ganzen stellt fest, dass sehr oft aus einem Datenfeld von "Personen" die 'rausgesucht werden, die ungefähr im selben Teil Deutschlands wohnen, also diejenigen, deren ersten beiden Ziffern der Postleitzahl identisch zu der gesuchten Ziffernfolge sind. Da seine Prozedur sehr langsam ist, weil sie erstmal aus einem als Integer gespeicherten Wert die ersten beiden Ziffern bestimmen muss, welche dann verglichen werden, hat er folgende Idee: Er speichert die Postleitzahl nicht mehr als Integer, sondern als String. Jetzt haben alle Programmierer, ein Problem. Sie müssen ihre gesamten Programme so umstricken, dass sie jetzt mit einem String statt einer Zahl klarkommen. In einem objektorientierten Programm gibt's solche Probleme nicht. Die Klasse bietet eine feste Schnittstelle, die ich verwende, egal wie oft der Autor der Klasse die interne Struktur umstellt. Ich habe eine Methode "postleitzahl", die mir die Postleitzahl als Zahl zurückgibt. Wenn der Autor sich jetzt entscheidet, intern einen String zu verwenden, um die Geschwindigkeit zu steigern oder einfach, um es sich einfacher zu machen, bestimmte neue Funktionen zu implementieren, ist das völlig egal. Die Methode "postleitzahl" liefert einfach weiterhin eine Zahl, auch wenn sie jetzt einen String umwandeln muss. Das heißt, an meinem Programm ändert sich gar nichts, aber ich profitiere trotzdem von den Optimierungen, die der Autor der Klasse vornimmt. Thomas: Sag doch mal ein paar Worte zu Deinen QBasic Programmen. helium: Da habe ich ein Problem: Ich habe hunderte von Programmen angefangen, aber kaum eins fertig gestellt. In der Zeit, als jeder ein FakeOS geschrieben hat, habe ich natürlich auch eins programmiert. Allerdings habe ich es im Gegensatz zu den meisten anderen nie veröffentlicht. Dann habe ich ein paar kleine physikalische Simulationen mit einem Freund zusammen geschrieben. Beispielsweise eine Gravitationssimulation, in der man Planeten sich um Sonnen drehen lassen kann, etc. Thomas: Was sind denn die Gründe dafür, dass Du so wenige QB-Projekte fertiggestellt hast? helium: Keine Ahnung. Ich hab immer wieder etwas Neues angefangen, und lange bevor es fertig war, hatte ich eine neue Idee, die ich viel interessanter fand, und deshalb der anderen vorgezogen habe. Thomas: Ich hoffe, dass Du doch noch Dieses oder Jenes fertigstellen wirst und wir es dann auf Deiner neuen Homepage bewundern können. In welchen Sprachen programmierst Du heute am liebsten? helium: Inzwischen eigentlich nur noch in C++, die meiner Meinung nach mächtigste Sprache, die es gibt. Ich kann immer noch ein wenig Object Pascal - sprich Delphi - und auch etwas Java. Thomas: Kannst Du etwas über Deine momentanen Projekte berichten? helium: Momentan arbeite ich an einem VST-Plugin. Dabei handelt es sich um einen virtuellen Gitarrenverstärker. VST ist eine Schnittstelle von Steinberg, mit deren Hilfe man virtuelle Audioeffekte und Instrumente schreiben kann, die sich dann in Audioeditoren oder Sequencern verwenden lassen. Bisher habe ich nur recht kleine Effekte geschrieben, die es alle auf meiner zukünftigen Seite zum Herunterladen geben wird. Dieses Plugin ist das erste wirklich komplexe. Thomas: Kannst Du das für diejenigen von uns, die keine erfahrenen Musik- Enthusiasten sind, etwas genauer erklären? Was ist "Steinberg" genau? Was macht ein "virtueller Guitarrenverstärker", ein "Audioeditor" und ein "Sequencer?" helium: Steinberg ist eine deutsche Firma, die vor allem durch ihr Programm Cubase bekannt geworden ist. Weltweit gibt es eigentlich nur einen echten Konkurenten: Logic, der jetzt von Appel aufgekauft wurde. Somit gibt's auf dem PC eigentlich gar keine Konkurenz mehr. Cubase ist ein Sequenzer. Ein virtueller Gitarrenverstärker simuliert einen echten Gitarrenverstärker. Du schließt deine Gitarre an den Rechner an - über einen Vorverstärker oder eine DI-Box, aber das ist jetzt eher uninteressant. Das, was aus der Gitarre 'rauskommt wird dann von dem virtuellen Verstärker ("Amp") bearbeitet und klingt anschließend so, als würde man über einen echten Verstärker spielen. Das heißt, man kann, wenn man will, den Sound verzerren, etc. Das Wichtigste ist aber der virtuelle Lautsprecher am Ende. Lautsprecher von Gitarrenamps versuchen nämlich keinesfalls den Sound - so wie eine HiFi Anlage - möglichst originalgetreu wiederzugeben. Es gibt nur einen einzigen großen Lautsprecher, der die hohen Frequenzen ziemlich stark dämpft. Würde man ein normales Musikstück darüber abspielen, klänge es extrem dumpf. Ein Audioeditor ist ein Programm, das dazu dient, Klangmaterial zu bearbeiten. Einfache Funktionen sind: Teile herausschneiden, lauter oder leiser machen, etc. So wie man mit einem Texteditor Texte bearbeitet (editiert), so bearbeitet man mit einem Audioeditor eben Klangmaterial. Ein Sequenzer ist eine Software, mit der man Musikstücke arrangiert. Es ist quasi ein Programm, mit dem man komponiert. Ich denke, ich sollte hier aber nicht genauer darauf eingehen, da das sonst recht umfangreich werden könnte. Thomas: Wozu braucht man diese Dinge eigentlich? Kann damit jemand gute Musik machen, der - so wie ich - total unmusikalisch ist und kein Instrument spielen kann? helium: Nein. Tut mir leid. Es ist wie bei der Malerei. Diese Werkzeuge sind quasi der Pinsel, und ein guter Pinsel macht noch keinen Künstler. Thomas: Oder geht es darum, die vorhandene Musik aufzupeppen und um zusätzliche Instrumente zu erweitern? Oder sparst Du Dir nur einen echten Guitarrenverstärker, indem Du die PC-Hardware mit Soundkarte dafür verwendest? helium: Das Aufnehmen mit einem echten Verstärker ist immer etwas kompliziert. Man muss Ewigkeiten rumprobieren, bis man das Mikrofon so vor der Box (dem Cabinet) plaziert hat, dass es gut klingt. Außerdem ist mein Verstärker tatsächlich nicht grade der beste. Thomas: Was rätst Du einem QB-Programmierer, der sein Game netzwerkfähig machen will, z.B. über TCP/IP oder IPX? helium: Ich selbst habe so etwas noch nie versucht. Ich habe aber einige Tutorials und weitere Texte von anderen QBasic-Programmierern, die das bereits gemacht haben. Wenn jemand das wirklich vorhat, kann ich die Texte mal raussuchen. Inzwischen habe ich über 350 MB an Texten und Beispielprogrammen runtergeladen, die irgendwelche Programmierthemen rund um QB erläutern und demonstrieren. Es ist zwar fast alles Englisch, aber ich bin sicher, dass ich auch einen recht guten deutschen Text habe. Thomas: Das klingt interessant. Könntest Du mir die Texte zur Verfügung stellen? Ich würde sie dann eventuell mit auf meine QBasic CD-ROM packen, die ich auf www.qbasic.d zum Selbstkostenpreis verkaufe. helium, was rätst Du einem QB-Programmierer, der aus seinem Programm heraus aufs Internet zugreifen und z.B. E-Mails versenden will? helium: Ich weiß nicht, ob das wirklich sinnvoll ist. QB ist einfach nicht geeignet für so etwas. Ich glaube, CEB (richtig heißt er Sebastian Mate) hat so etwas mal gemacht. Ich würde einem QB-Programmierer ehrlich gesagt dazu raten, sich über einen Umstieg auf eine modernere Sprache Gedanken zu machen, wenn er solche Programmierprojekte in Angriff nehmen will. Thomas: CEBs Internet-Toolsammlung "GetWeb" ist leider auf CEBs Webseite www.sm-gimi.de nicht mehr verfügbar. Wie siehst Du die Zukunft von QBasic, QuickBasic und MS-DOS? helium: Ich schätze sie recht schlecht ein. Microsoft will von DOS ja schon längst nichts mehr wissen. Bereits jetzt gibt es Probleme, QBasic unter Windows 2000 und XP zu betreiben. Einige wenige werden aus Nostalgie vielleicht weiterhin QuickBasic einsetzen. Zur Zeit wird es - so weit ich weiß - auch nur noch an Schulen verwendet, um ins Programmieren einzusteigen. Dazu ist QBasic sicherlich immer noch geeignet, da es unter den DOS-BASICs eines der besten, wenn nicht sogar das beste, auf jeden Fall aber das beliebteste ist. Die Grundlagen der Programmierung wie Bedingungen, Schleifen usw. lassen sich an QBasic wunderbar demonstrieren. Ich selbst würde jedem Einsteiger aber raten, möglichst schnell auf eine objektorientierte Sprache umzusteigen, beispielsweise Java, da es recht leicht ist. Thomas: Auf welche Windows-Programmiersprache sollte ein QB-Fan aufsteigen a) wenn er nur hobbymäßig programmieren will bzw. b) wenn er einen IT-Beruf anstrebt? helium: Ein echter Fan wird wohl gerne bei einem BASIC bleiben, vor allem wenn er nur hobbymaßig programmiert. Vor allem beim Hobbyprogrammierer hängt das von den Interessen ab. Wenn er gerne kleine Spiele schreiben und nicht viel Neues lernen will, ist vermutlich ein Umstieg auf Blitz Basic anzuraten. Der Umstieg ist nicht sonderlich dramatisch. Dadurch, dass BB wesentlich moderner ist und auf hochoptimierten Schnittstellen wie DirectX aufsetzt, sind die Möglichkeiten, was das Spieleprogrammieren angeht, schon mal wesentlich größer. Außerdem lassen sich manche Dinge deutlich bequemer erledigen, da die Sprache zahlreiche flexiblere Datenstrukturen bereitstellt. An der Vorgehensweise, wie man ein Programm erstellt, ändert sich gar nichts. Alles, was man tun muss, ist, ein paar neue Befehle lernen. Mit den meisten anderen BASICs habe ich keine besonders großen Erfahrungen. PureBasic soll ganz gut sein und auch recht erschwinglich. Falls man Linux und KDE verwenden könnte KBasic interessant sein. Wenn es gar nicht um echte Programme geht, sondern nur darum, irgendwelche Aufgaben zu automatisieren, Shellscripte / Batchdateien dazu aber nicht ausreichen, sollten man am besten zu einer Scriptsprache greifen. Die bekanntesten sind wohl PHP, Perl, Phyton und Ruby. Von Perl rate ich dringenst ab, da du dir deinen Programmierstil damit total versaust. PHP ist eigentlich nur innerhalb von Webseiten wirklich interessant, da aber echt gut. Python ist eine objektorientierte Scriptsprache mit einer recht mächtigen Bibliothek. Sie zwingt einen zu einer ordentlichen Formatierung, da Zusammenhänge durch Einrücken definiert werden. Sie ist sehr einfach zu erlernen und recht flexibel. Ich denke, dass Sie für QB-Programmierer recht gut als Aufsteigersprache geeignet ist. Ruby ist ebenfalls eine OOP-Sprache (OOP = Object-Oriented Programming) und auf jeden Fall einen Blick wert, auch wenn es zum Teil für Anfänger recht verwirrend ist, da man selbst grundlegende Dinge auf tausenden von verschiedenen Arten schreiben kann. Für besonders ambitionierte Hobbyprogrammierer und die, die Programmieren zum Beruf machen wollen, sollte es dann aber doch etwas anderes sein. BASIC-Sprachen sind prinzipiell nur für sehr kleine Projekte geeignet. VisualBasic .NET ist hier vielleicht eine Ausnahme, auch im Gegensatz zu seinen Vorgängern. In großen Projekten kann aber die Objektorientierung ihre Stärken voll ausspielen, weshalb der Umstieg auf eine OOP-Sprache quasi Pflicht ist. Genau das ist aber erstmal eine Hürde, da die Vorgehensweise eine ganz andere ist, als die in der prozeduralen Programmierung. Statt die zu erledigenden Aufgaben zu suchen und in Prozeduren (in QB Subs und Functions) zu packen, sucht man die in der Problemstellung vorkommenden Objekte, beschreibt sie und lässt sie miteinander interagieren. Einmal gelernte Vorgehensweisen wieder zu "vergessen" ist aber recht schwer, wie ich selber erfahren musste. Welche Sprachen sind denn objektorientiert? Da gibt es viele: C++, Java, C#, D, Objective-C, Object Pascal, Eiffel, Sather, Smalltalk und noch viele weitere. Allerdings sollten die hier genannten die interessantesten sein, wobei D und Sather weniger wichtig sind. Für den Einsatz im Internet ist wohl Java das Geeignetste. C# ist ein Java-Klon, der fast keine eigenen Ideen umsetzt sondern nur ein klein wenig C++ einfließen lässt. Aus meiner Sicht ist C# nicht sonderlich interessant. Übrigens: C# wird "C Sharp" gesprochen; englisch für die Note Cis. Smalltalk ist eine der ersten objektorientierten Sprachen überhaupt. (Die erste war Simula67, dazwischen kenne ich keine). Smalltalk hat die Grundlagen übernommen und die Objektorientierung nochmals in besonders klarer Form herausgearbeitet. Smalltalk ist wohl eine der reinsten OOP-Sprachen überhaupt. Allerdings ist die Bedeutung dieser Sprache eher gering. Objective-C basiert auf der prozeduralen Sprache C - erweitert um die Möglichkeiten von Smalltalk. Eingesetzt wird Objective-C eigentlich nur auf dem Mac. Die gesamte Cocoa-Bibliothek von OS X wurde in Objective-C geschreiben. Eiffel ist ganz nett, meiner Meinung nach aber nicht unbedingt die erste Wahl, es sei denn, man will in einem Unternehmen arbeiten, das Eiffel einsetzt. Object Pascal/Delphi ist auf jeden Fall eine ernst zu nehmende Sprache auch für größere Projekte. Dennoch ist sie auch für Anfänger recht leicht zu erlernen. Da man aber als QB-Programmierer das prozedurale Programmieren gewöhnt ist, sollte man mit einer Sprache anfangen, die einen ein wenig zwingt, objektorientiert zu programmieren. Ansonsten braucht man wesentlich mehr Disziplin. Deswegen ist Java wirklich nicht schlecht, vor allem wegen der großen Ähnlichkeit zu C#, ein Vorteil, wenn man tatsächlich mal gezwungen sein sollte, in C# zu programmieren. Auch der Umstieg auf C++ ist nicht ganz so schwer. C++ ist meine persönliche Lieblingssprache. Sie ist recht komplex, bietet dafür aber unglaubliche Möglichkeiten. Dinge von denen man in anderen Sprachen nicht mal zu träumen wagt, sind hier problemlos möglich. Na gut, so problemlos ist es doch nicht immer, aber es gibt quasi nichts, was man in C++ nicht irgenwie nachbauen kann. Der Aufwand, C++ zu lernen, ist zwar größer, aber er lohnt sich auf jeden Fall. C++ ist keine rein objektorientierte Sprache, sondern bietet auch alle Möglichkeiten der prozeduralen Sprache C, wobei selbst hier die Möglichkeiten wesentlich größer sind, als in QB. Neben der Objektorientierung wird das generische Programmieren in einem Umfang unterstützt wie in keiner anderen Sprache. Generisches Programmieren ist das Schreiben von Code, der wiederum anderen Code erzeugt. Dadurch ist es teilweise sogar möglich, funktional zu programmieren. Was man unter "funktional" versteht, habe ich weiter oben schon zum Thema Haskell ausgeführt. Thomas: Lohnt es sich, zunächst C zu lernen, um dann erst auf das objektorientierte C++ umzusteigen? helium: Nein auf keinen Fall. Von diesem Umweg würde ich auf jeden Fall abraten. Das erschwert den Umstieg nur unnötig. Thomas: Was rätst Du einem QBasic Spiele-Programmierer, der Animationen, Sound und Mausbedienung in seine Spiele und sonstigen Programme hineinbringen will? helium: Da würde ich nicht das Rad neu erfinden, sondern eine gute Multimedia-Bibliothek für QuickBasic verwenden. Die bekanntesten in Frage kommenden Bibliotheken sind DirectQB, UGL und die Future.Lib. DiectQB ist aber so alt, dass selbst ich nur noch das Ende seiner Entwicklung mitbekommen habe. Die Future.lib wird inzwischen auch nicht mehr weiter entwickelt, bietet aber alles Wichtige. UGL ist die wohl beste Bibliothek, die für QB existiert. Sie ist schneller als alle anderen Bibliotheken und bietet zudem mehr Möglichkeiten. Allerdings ist die Future.Lib immer noch die am weitetsten verbreitetste, weshalb man hierzu wesentlich mehr Material findet und es auch mehr Leute gibt, die einem helfen können. Wenn man noch nicht so weit in die Spieleprogrammierung eingedrungen ist, sollte man zur Future.Lib greifen, als weiter Fortgeschrittener auf jeden Fall zu UGL. Thomas: Wie schafft man sich den nötigen freien Speicherplatz für seine Spiele und überwindet die für QBasic geltende 160 KB Grenze für die max. Länge von Code und Daten? helium: Da rate ich euch: Ladet möglichst viel dynamisch, d.h. zur Laufzeit, aus Dateien statt alles fest in den Code einzubauen. Das erleichtert es vor allem auch, Dinge zu ändern. Thomas: Welche weiteren Ratschläge kannst Du einem QBasic- Einsteiger geben? helium: Puh. Er sollte auf jeden Fall ein gutes Forum besuchen, wie beispielsweise Schlotzzs Forum, das beispielsweise über www.qbasic.de/forum erreichbar ist. Dort werden alle seine Fragen beantwortet. Auf www.qbasic.de gibt's auch einige Tutorials, die er lesen kann und Beispielprogramme, aus denen sich viel lernen lässt. Falls er englisch speicht sollte er auch www.qb45.com besuchen. Die Auswahl an Texten, Tutorials und Beispielprogrammen ist noch größer, und dort findet er ebenfalls ein Forum, das von recht kompetenten QB- Programmierern besucht wird. Thomas: Spiele für Linux - denkst Du über sowas nach? helium: Ja auf jeden Fall. Ich selbst verwende (in C++) OpenGL für Grafik und SDL für alles andere, beide extrem portabel (leider beide komplett prozedural, weshalb ich mir erstmal einen Wrapper schreiben musste). Natürlich sind die Dinge, die ich da so schreibe, nur kleine Spielereien. Ich hoffe aber, der Markt wächst in die Richtung, dass professionelle Spiele gleichermaßen für Windows und Linux (und vielleicht auch MacOS X) entwickelt werden. Thomas: Was ist ein Wrapper? helium: Ein Wrapper ist etwas, das man um etwas Vorhandenes herumbaut, um seine Funktion zu erweitern, oder es an die gestellten Forderungen anzupassen. Das ist echt schwer zu erklären. In dem Fall habe ich einen Wrapper um die SDL- Schnittstelle gebaut. Von außen sieht es jetzt ganz anders aus (eben objektorientiert) und lässt sich viel leichter verwenden, intern werden aber genau die selben Funktionen benutzt. Thomas: Spieleprogrammierung in VB oder Delphi - macht das Sinn? helium: In VB eher nicht. Die Sprache ist einfach nicht geeignet. Delphi aber auf jeden Fall. Delphi ist verdammt schnell und bietet Schnittstellen zu den wichtigsten Bibliotheken. Ich glaube sowieso, dass Delphi oft unterschätzt wird. Einige enstzunehmende Produkte wurden in Delphi geschrieben, ohne dass es jemand gemerkt hat. Thomas: Ja das stimmt, z.B. der vorhin angesprochene Phase 5 HTML-Editor von Ulli Meybohm. helium, was planst Du eigentlich für Zukunftsprojekte? helium: Naja, ich muss erstmal meinen Gitarrenverstärker fertig bekommen. Ich habe schon einige Ideen für weitere Audioplugins. So viele, dass ich da niemals hinterherkommen werde. Thomas: Wie willst Du Dich beruflich entwickeln? helium: Programmierer ist auf jeden Fall etwas, was in Frage kommt. Ich habe aber auch überlegt, vielleicht Physik zu studieren. Ich werde mal sehen. Wenn ich mich fürs Programmieren entscheide, werde ich hoffentlich etwas im Audiobereich finden. Thomas: Warum hört man so wenig von PowerBASIC und VB-DOS - im Vergleich zu QuickBasic? helium: Früher kam man im Internet sehr leicht an QB4.5. PowerBasic musste man kaufen und auch VB-DOS gabs eigentlich nirgendwo. Es hat ziemlich lange gedauert, bis ich überhaupt erfahren hatte, das es das gibt. Deswegen wurden auch die Bibliotheken für QB4.5 entwickelt. Obwohl dann QBX 7.1 (PDS) im Internet weiter verbreitet wurde, gab es die Bibliotheken aber immer noch nur für QB4.5. Deshalb wurde es auch noch ziemlich lange weiter verwendet. Ein Umstieg auf PowerBASIC oder VB-DOS war genau wegen dieser Bibliotheken uninteressant, da man dort nicht die Möglichkeit hatte, SVGA-Auflösungen zu verwenden usw. Thomas: Was sind Deine Lieblings-Webseiten? helium: Meine Lieblings-Anlaufstellen im Internet sind:
helium: Musik. Ich Spiele Gitarre, Bass und Trompete, suche zur Zeit aber eine Band. Thomas: Vielen Dank helium für die höchst aufschlussreichen Antworten. Willst Du noch einen Abschiedsgruß an den Leser richten und etwas von Deinen Erfahrungen als Programmierer und Mensch weitergeben? helium: Wie wär's an dieser Stelle mit 'nem Standardprogrammiererspruch (der aber vollkommen ernst gemeint ist), wie "premature optimization is the root of all evil". Thomas: Da muss ich doch mal nachfragen: "premature optimization is the root of all evil" ... was heißt das genau und wie setzt man es in die Praxis um? helium: Wörtlich "Voreilige Optimierungen sind die Wurzel alles Bösen". Konkret heißt das, dass man nicht versuchen soll, alles direkt möglichst auf Geschwindigkeit zu trimmen und dafür Code in Kauf zu nehmen, den man selbst nicht mehr versteht, so nach dem Motto "Hauptsache, es läuft irgendwie und ist schnell", sondern dass man vernünftigen Code schreibt, der leicht verständlich und anpassbar ist. Sollte ein Teil tatsächlich zu langsam sein, kann man dann hinterher immer noch in aller Ruhe optimieren. |
| [zur Startseite http://www.antonis.de] [zur framelosen Startseite] |