Gespräch mit Adok zum Thema "Hugi Size Coding Competition"
geführt von mados
[mados] Der Name "Adok" ist aus der Diskmag-Szene nicht mehr wegzudenken. Man ist fast ein wenig überrascht wenn man bemerkt, dass du neben deinen publizistischen Tätigkeiten (lesen, schreiben, revidieren) auch richtig programmieren kannst. Welche Sprachen und Sprachdialekte hast du bis heute gelernt oder auch nur ausprobiert?
[Adok] Eine ganze Menge. Begonnen habe ich am C64 mit Basic, ich war damals 8 Jahre alt. Nachdem ich einen PC bekam, stieg ich auf QBasic um. Mit 12 schrieb ich meinen QBasic-Kurs, welcher immer noch im Internet im Umlauf ist (http://www.antonis.de/) und auf den ich auch heute noch jede Woche ein paar Reaktionen erhalte. Als ich 12 war, erlernte ich gleichzeitig x86-Assembler und C. Dafür habe ich auch Kurse geschrieben (ebenfalls auf http://www.antonis.de/ erhältlich). Das wären die Sprachen, mit denen ich mich am meisten beschäftigt habe. Daneben verbrachte ich auch ein wenig Zeit mit Pascal, Scheme, LISP, Perl, C++, Forth, Java, Fortran, COBOL, ABAP/5, Ada, PL/1 sowie Skriptsprachen (PHP, SGML-Derivate wie XML, HTML, XHTML, JavaScript, Batch usw.) und verschiedenen Anwendersprachen wie ZZT-OOP, DERIVE usf., aber ich widmete mich diesen nicht intensiv; Assembler, Basic und C sind die Sprachen, die ich am besten beherrsche.
[mados] Was waren für dich persönlich die Gründe, dich überhaupt mit diesen zum Teil doch sehr exotischen Sprachen zu beschäftigen?
[Adok] Der Grund, warum ich mit 8 Jahren überhaupt zu programmieren anfing, war, dass ich nicht länger bloß Konsument von Computerspielen sein wollte, sondern auch selbst neue Programme zu erstellen fähig sein wollte. Im Laufe der Zeit machte mir das Programmieren immer mehr Spaß, und ich empfand es als Herausforderung, mich mit immer neuen Programmiersprachen vertraut zu machen. Es ist genauso, wie wenn man eine neue menschliche Sprache erlernt: am Anfang hart, aber mit dem Erfolg kommt auch die Freude.
[mados] Es ist wohl bei jeder Sprache so, dass man sie nur dann richtig beherrscht, wenn man sie tatsächlich anwendet. Was waren damals deine größten und erfolgreichsten Projekte, die du programmiert oder an denen du mitgewirkt hast? Und - um langsam auf das eigentliche Thema dieses Gespräches einzuschwenken - wo hast du deine Assembler-Kenntnisse erstmals unter Beweis stellen können?
[Adok] Bei mir waren es eher kleine, private Projekte. Das größte war wohl noch die Engine für Hugi #9-#11, etwas mehr als 100 KByte Sourcecode. Ich schrieb aber auch - wie erwähnt - Programmierkurse für Assembler, Basic und C.
Meine Assemblerkenntnisse kamen, vom Kurs abgesehen, zum ersten Mal richtig zum Einsatz, als ich an einem Wettbewerb teilnahm, der von Dake/Calodox veranstaltet wurde. Es war eine Size Coding Competition - gegeben war eine einfache Aufgabe, welche in Assembler umzusetzen war. Das kleinste Programm würde gewinnen. Nach zwei Monaten Optimierens landete ich mit einem Entry von einer Größe von 61 Bytes den ersten Platz. Insgesamt gab es 23 Teilnehmer (von den Entries zu schließen, welche Pain 5/98 beiliegen). Dieser Wettbewerb machte mir so großen Spaß, dass ich mich schließlich entschloss, selbst eine Size Coding Competition zu organisieren.
[mados] Diese Zusammenfassung wirft einige Fragen auf. War Dakes Wettbewerb - der, so weit ich weiß, im Rahmen des Magazines Pain ablief - eine einmalige Aktion?
[Adok] Genau, der Wettbewerb fand im Rahmen des Magazines Pain statt. Er war nicht eine einmalige Aktion - es gab zwei solcher Wettbewerbe. Dieser hier war der letzte. Er fand Anfang 1998 statt.
[mados] War damals schon klar, dass du den Nachfolger bzw. die Fortsetzung zu Dakes Wettbewerb schaffen würdest? War die Hugi Compo überhaupt als Serie geplant?
[Adok] Die Hugi Compo war zunächst als einmaliges Ereignis geplant. Tatsächlich fing es so an: Ich hatte soeben meinen Erfolg bei Dakes Compo gelandet und war noch in Assembler-Euphorie. Da implementierte ich just for fun ein einfaches, Nibbles-ähnliches Spiel und überlegte, wie ich es in der Größe optimieren könnte. Nachdem ich mich etwa eine Stunde lang damit beschäftigt hatte (und auf etwa 80 Bytes gekommen war), dachte ich mir: Warum eigentlich nicht einen Wettbewerb veranstalten und sehen, wie weit andere Leute kommen bzw. was das tatsächliche Größenminimum sein könnte? Kurzerhand erstellte ich einen Regelpack, lud ihn auf ftp.scene.org und bastelte schnell eine Homepage zusammen, auf welcher stets die aktuelle Rangliste zu finden sein sollte. Ich kündigte die Compo zuerst im IRC an - noch voller Bange, ob überhaupt mehr als ein, zwei Leute teilnehmen würden. Tatsächlich aber stieß die Compo auf größeres Interesse, als ich gedacht hatte. Und nach Announcements in Newsgroups explodierte die Zahl der Einsendungen regelrecht. Ich glaube, jeden Tag sind 20 neue Entrys gekommen. Insgesamt beteiligten sich im Laufe der zwei Monate, die der Wettbewerb dauerte, über 80 Leute aus aller Herren Länder. Mehr als 70 hatten regelkonforme Entrys eingeschickt. Kurz gesagt, das Interesse übertraf alle meine Erwartungen. Die Compo war spannend bis zum Schluss, es gab oft Verschiebungen der Plätze, oftmals trennten nur wenige Bytes den 1. vom 10. Platz. Nachdem Altair schließlich mit unglaublichen 48 Bytes gesiegt hatte, gab es von Seiten verschiedener Teilnehmer Einwände zu einzelnen Entrys - in Folge dessen wurde eine Mailingliste geschaffen, welche die Diskussion über Regelkonformität ermöglichte. Es gab ein "Public Judgment" und ein paar Disqualifizierungen. Kurz, die Compo entwickelte sich interessanter und lebendiger, als ich es zunächst gedacht hätte. Jedenfalls entstand bald von Seiten vieler Teilnehmer der Wunsch, einen weiteren Wettbewerb zu veranstalten - so kam es zu der "Hugi Size Coding Competition Series".
[mados] Nach insgesamt vier Jahren ist inzwischen bereits die 15. Runde dieser Serie zu Ende gegangen. Haben sich die angedeuteten Regeln in dieser Zeit verändert?
[Adok] Die Regeln wurden im Laufe der Zeit erweitert. Anfangs war fast alles erlaubt; doch bald sah man, dass bestimmte Annahmen - etwa über Register- und Speicherzustände - auf manchen Systemen zutrafen, auf anderen nicht. Aus diesem Grund musste man sich auf bestimmte Konventionen einigen.
Dazu kommt noch das bereits erwähnte Public Judgement: Nach Einsendeschluss werden alle Entries veröffentlicht, und eine Woche lang hat jeder die Möglichkeit, per Mailingliste Einspruch zu erheben, wenn er beweisen kann, dass ein Entry nicht regelkonform ist. Entsprechend können Entries disqualifiziert bzw. mit Strafpunkten belegt werden.
[mados] Warst du von einem Ergebnis besonders beeindruckt oder überrascht?
[Adok] Ich war schon am Anfang überrascht, dass von den 80 Bytes ausgehend noch so viel mehr wegoptimiert werden konnte. Ständig werden in solchen Compos neue Rekorde aufgestellt, so dass mich mittlerweile gar nichts mehr überrascht. :) Umso mehr bin ich beeindruckt.
[mados] Welche Verbindungen hat der Wettbewerb, der doch von Anfang an sehr eigenständig war, zum Magazin?
[Adok] Der Wettbewerb fand unabhängig vom Magazin statt. Anfangs wurden neue Competitions in kürzeren Abständen veranstaltet, als neue Ausgaben von Hugi erschienen. Deshalb war es gar nicht praktikabel, beides miteinander zu verknüpfen. Im Hugi-Magazin wurden Hinweise auf neue Wettbewerbe publiziert, die Hugi-Compo-Website beinhaltete Links auf das Magazin, ansonsten liefen die beiden Dinge mehr oder weniger unabhängig voneinander ab.
Allerdings hat die Hugi-Compo sehr wohl dramatische Auswirkungen auf das Magazin gehabt. Erstens: Ich wurde erst durch die Hugi-Compo unter Democodern international bekannt; dieser Bekanntheitsgrad nützte dem Hugi-Magazin. Andernfalls wäre es für das Magazin schwieriger gewesen, derart schnell so populär zu werden. Wie gesagt, war die 10. Ausgabe noch zum Großteil in deutscher Sprache und nur in der deutschen Szene halbwegs bekannt, konnte die 11. bereits eine Vielzahl von englischen Artikeln aufweisen, und als die 12. kam, war Hugi bereits auf Platz 2 in den Hornet-Charts, direkt hinter Imphobia.
Zweitens: Sehr wichtige Supporter des Hugi-Diskmags sind über die Compo zu uns gestoßen, darunter TAD und Chris Dragan. Beide hatten zuvor nur periphäres Interesse an der Demoszene gehabt. Dadurch, dass die Hugi-Compo auch (bzw. vor allem) in allgemeinen Assembler-Programmier-Newsgroups beworben wurde, erweiterte sich das Einzugsgebiet von Hugi, und es wurden wertvolle Mitarbeiter gefunden.
Aber auch auf andere Weise profitierten die Szene bzw. Szener von der Hugi-Compo. Ein Beispiel ist Picard, Coder aus Ungarn. Picard war zwar schon vorher an der Demoszene interessiert, aber nur Mitglied einer kleinen, unbekannten Gruppe namens Hydrogen gewesen. Er meinte, dass er im Rahmen dieser Gruppe höchstens ein 4k-Intro hätte produzieren können. Durch seinen Erfolg in mehreren Hugi-Compos wurden die ungarischen Demogruppen Rhyme und Exceed auf Picard aufmerksam. Picard trat Rhyme bei, landete sehr rasch, nämlich bereits auf der Assembly 98 einen großen Erfolg mit dem 4k-Intro Mesha (1. Platz); später kam er zu Exceed und lieferte wichtige Beiträge für Projekte wie Heaven 7.
[mados] Einer Frage sind wir bis jetzt aus dem Weg gegangen: Warum? Worin liegt eigentlich der Anreiz, an einem Wettbewerb teilzunehmen, bei dem es einfach ausgedrückt um nichts anderes geht als um die kleinst mögliche Größe eines fest vorgegebenen Programmes?
[Adok] Es ist sicherlich eine Sache des Kräftemessens, zu sehen, ob man wirklich so gut in Assembler ist, wie man es geglaubt hat. Es ist ähnlich wie im Sport: Man will Höchstleistungen erbringen. Size-Optimieren dieser Art ist tatsächlich Extremsport. Es hat keinen direkten Praxisbezug, kein Programmierer braucht in diesen Dimensionen zu arbeiten. Aber man trainiert freilich sein logisches Denkvermögen, seine Fantasie, sein Gedächtnis, seine Ausdauer, und so hat es schon positive Auswirkungen auf das echte Leben.
[mados] Ist es nicht bedauerlich, dass der Aspekt der Geschwindigkeit bei dieser Konzentrierung auf die Größe unbeachtet bleibt? Oft sind ja die minimierten Programme sogar bedeutend langsamer.
[Adok] Es ist unvermeidlich, sich bei einem Wettbewerb entweder auf Größe oder Geschwindigkeit zu konzentrieren. Beides lässt sich nur in wenigen Fällen gleichzeitig auf die Spitze treiben, da - wie du sagst - die Lösungen mit geringerem Platzbedarf oftmals um einiges langsamer als voluminösere Fassungen sind.
Geschwindigkeitsoptimierung mag in der Praxis wichtiger sein als Größenminimierung. Andererseits ist die Ausführungsgeschwindigkeit stark von der Hardware abhängig, schwieriger zu messen, und ein superschnelles Programm ist angesichts der Leistungsfähigkeit heutiger Prozessoren weniger beeindruckend als ein winzigkleines.
[mados] Also geht es am Ende doch nur um Prestige?
[Adok] Sozusagen. :) Es ist doch eine Ehre, einen guten Platz in der "World League Table of Assembler" zu erreichen.
[mados] Dennoch taucht dein Name in dieser Tabelle nie auf. Das Warum ist natürlich klar, schließlich bist du der Einzige, der die ganze Zeit über Einblick in sämtliche Quellcodes hat. Bedauerst du das?
[Adok] Nein. Ich bin der Organisator, ich stehe damit über den Dingen. :) Das macht genauso viel Spaß.
[mados] Was wünschst du dir für die Zukunft der Hugi-Compo?
[Adok] Es mögen viele neue Leute an der Compo teilnehmen und mit geistreichen Entries die Welt bereichern!
[mados] In diesem Sinne: mov ax,4C00h; int 21h.
[Adok] Oder, wie es in der Hugi Size Coding Compo meistens getan wird: ret!