Wir haben die Geschichte der Programmiersprache LPC von ihren Anfängen, ihren Paradigmen und ihrem Weltverständnis her untersucht und versucht, einen Überblick über die Entwicklung und den Aufbau darzustellen. Dabei haben wir uns auf Quellen aus zeitgenössischen Publikationen gestützt, die auch Postings in Newsgroups, privat verschickte und später veröffentlichte Emails und andere im WWW zu findende Texte umfaßt. Ziel unseres Berichtes ist, darzulegen, in welchem sozialen Umfeld LPC und seine Vorläufer entstanden sind und wie die typische Entwicklung einer Sprache (und dem, was dazugehört) verläuft.
Die Sprache LPC ist eine Spezialsprache für die Programmierung von MUDs [MUDS]. Diese Einschränkung der Anwendung ist in letzter Zeit jedoch aufgehoben worden, seit Abarten (Pike, Micro-LPC) unter anderem auch für die Programmierung von WWW-Seiten verwendet werden können. Der WWW-Server Roxen [ROXEN] z.B. interpretiert Pike-Scripte.
Die ursprüngliche Anwendung jedoch ist viel stärker eingeschränkt und hat die Sprache in ihrem Design stark beeinflußt. LPC ist dafür ausgelegt, eine Welt zu simulieren und Teilnehmern an der Simulation die Einflußnahme zu ermöglichen. Daher ist es auch in starkem Maße auf einen Multi-User-Betrieb vorbereitet.
Da diese Simulationen zumeist als Spiel aufgefaßt werden und sich auch auf den ersten Blick so darstellen, ist die Wissenschaftlichkeit der Anwendung und damit der Sprache in Frage gestellt. In letzter Zeit jedoch sind mehr und mehr wissenschaftliche Schriften zum Thema der MUDs veröffentlicht worden, und eine breitere Anerkennung des Themas zeichnet sich ab.
UNFINISHED: textadventure, rollenspiele
Im Jahr 1979 wurde in Essex, England, das erste Programm geschrieben und installiert, das den Namen MUD trug. Einer der späteren Entwickler, Richard Bartle, beschreibt den Prozeß der anfänglichen Entwicklung der Programms als einen Alleingang von Roy Trubshaw, der (laut Bartle) mehr an den technischen Aspekten interessiert gewesen sei. Er selbst (Bartle) sei dagegen mehr mit dem Design der simulierten Welt befaßt gewesen.
Schon hier zeigt sich eine typische Aufteilung, die wir auch später immer wieder bemerken werden: eine Arbeitsteilung zwischen eher technisch- und eher design-orientierten Entwicklern.
Das erste MUD war in MACRO-10 geschrieben (ein Assembler), wurde später auf BCPL umgeschrieben und verwandte für die Darstellung der Welt eine Datenbank. Diese Datenbank war in einer Sprache dargestellt, die MUDDL hieß, MUD Definition Language. Mit dieser Datenbank konnte das MUD während der Laufzeit (also ohne Herunterfahren des MUDs) erweitert und beeinflußt werden. MUDDL ist damit ein früher Vorläufer von LPC.
Gegen Ende der 80er Jahre verbreitete sich eine andere Art von MUDs, die AberMUDs, die in der Universität von Aberystwyth, Groß Britannien, entwickelt worden waren. AberMUDs sind nicht während der Laufzeit erweiterbar und besitzen keine spezielle Sprache, in der man die Welt beschreibt. Die Welt wird in der Sprache beschrieben, in der auch die Laufzeitumgebung geschrieben ist -- in allen mir bekannten Fällen ist dies C.
Aus AberMUD entwickelte sich das eher sozial orientierte TinyMUD, bei dem die Teilnehmer während der Teilnahme mit speziellen Kommandos das Spiel in begrenztem Umfang erweitern können. Diese Kommandos sind jedoch sehr rudimentär und kaum als eigenständige Programmiersprache zu bezeichnen. Vielmehr kann man mit ihnen eine Art komplexe Konfiguration der Objekte vornehmen. TinyMUDs sind in ihrem Design auch weniger auf programmtechnische Erweiterung ausgelegt, sondern betonen vielmehr den sozialen Aspekt der Gemeinschaft der Teilnehmer [ILIAN].
Anfang der 90er Jahre begann Lars Pensjö, ein Student aus Schweden, schließlich mit der Entwicklung eines eigenen MUD-Systems, das LPMUD genannt wird. Im wesentlichen besteht das LPMUD aus einer in C geschriebenen Laufzeitumgebung (siehe unten zum Thema Driver), die eine eigene Sprache compiliert und interpretiert. Diese Sprache ist LPC. Sie ist objektorientiert, in der Syntax stark an C angelehnt und hat umfangreiche Möglichkeiten zur String-Verarbeitung.
LPC wird in LPMUDs benutzt, um die Welt zu modellieren. Einiges an Modellierung wird allerdings auch aus Effizienzgründen schon im Driver getan.
Wie auch schon bei der Entwicklung vom ersten MUD in Essex beschreibt Pensjö sein Hauptinteresse darin, die Möglichkeit der Umsetzung seiner Vision zu zeigen. Als sein MUD schließlich den Punkt erreichte, daß man die modellierte Welt hätte erweitern müssen, zog er sich aus dem Schaffensprozess zurück und überließ das Mud Anderen [LARS].
Die objektorientierte Programmierung wird von jeher für die Simulation von komplexen Abläufen eingesetzt. Schon die ersten derartigen Programmiersprachen sehen diesen Aspekt als wesentlichen Vorteil und Merkmal der Objektorientierung an. [SIMULA]
Häufig wird bei objektorientierter Programmierung eine sehr abstrakte Sicht auf die Welt, die modelliert wird, zugrunde gelegt. In LPC gibt es -- anders als z.B. in C++ -- keine abstrakten Klassen, die nicht instanziiert werden können. Jedes Objekt wird mit einigen Grundfunktionalitäten ausgestattet; so hat z.B. jedes Objekt eine Inventarverwaltung (für sich darin befindende Objekte), eine gewisse Helligkeit usw.
Vererbung ist in LPC multipel möglich (ein Objekt kann die Eigenschaften mehrerer anderer Objekte erben). Vererbungsbäume in LPC sind typischerweise nicht sehr tief; eine Fackel erbt z.B. die Eigenschaften von "Gegenstand" und von "brennbar", "Gegenstand" erbt noch einige Basis-Funktionen für Gewicht, Wert undd ergleichen. Die Vererbung wird also auf verhältnismäßig konkreter und wenig abstrakter Ebene eingesetzt.
Da LPC als Beschreibungssprache einer simulierten Welt nur Sinn macht, wenn man es in einem Mehrbenutzerkontext einsetzt, werden MUDs üblicherweise an das Internet angeschlossen. Die Teilnehmer bauen eine Telnet-Verbindung auf, über die sie mit dem Rechner, auf dem das MUD installiert ist, kommunizieren. Auf diesem Rechner läuft ein Programm, das Driver genannt wird.
Der Driver ist ein in einer üblichen Programmiersprache geschriebenes Programm, (heute meist C), nicht in einer Beschreibungssprache der modellierten Welt. Er verwaltet die Telnet-Verbindungen der einzelnen Teilnehmer, leitet ihre Eingaben an bestimmte ausgezeichnete Objekte im MUD weiter und schickt Ausgaben der verschiedenen Objekte nach außen weiter.
Der Driver enthält außerdem einen Compiler, der die in LPC geschriebenen Objekte in einen leichter interpretierbaren Bytecode umwandelt, und einen Interpreter, der diesen Bytecode abarbeitet.
Weltweit gibt es vielleicht ein paar Dutzend verschiedene LPC-Driver, von denen eine Handvoll von sehr vielen MUDs eingesetzt wird. Alle verwendeten Driver unterscheiden sich dabei in geringem Maße.
Ein spezielles Objekt ist das Master-Objekt, das das wesentliche Kommunikationsmedium darstellt, wenn Informationen aus der modellierten Welt in den Driver gelangen sollen oder umgekehrt. Der Master ist als Objekt ebenfalls in LPC geschrieben.
Die in den Objekten in LPC geschriebenen Funktionen werden "lokale
Funktionen" oder kurz "Lfuns" genannt, die Funktionen, die man
aufrufen kann, ohne daß sie in LPC formuliert worden sind (in
Smalltalk werden sie "Primitiven" genannt), heißen in LPC "Externe
Funktionen" oder kurz "Efuns". Dies sind üblicherweise die
einfachsten mit Ausgabe von Text betrauten Funktionen, wie z.B. die
Efun tell_object(), mit der man eine Zeichenkette an
einen Teilnehmer senden kann, oder z.B. mathematische Funktionen.
Den Umfang der Efuns kann man erweitern, indem man in einem weiteren speziellen Objekt Funktionen ergänzt. Alle Funktionen, die in diesem Objekt stehen, sind global für alle Objekte als sogenannte Simul-Efuns verfügbar. Für den LPC-Programmierer macht es keinen Unterschied, ob eine Funktion Efun oder Simul-Efun ist, er behandelt sie gleich.
Ein MUD wird üblicherweise auf einem Rechner installiert und dort von jemandem gewartet. Meist wird diese Aufgabe von mehreren Personen geteilt, da sie -- je nach Größe des MUDs -- recht umfangreich sein kann. Die Aufgaben der Administration reichen von der Vertretung des MUDs nach außen (z.B. Interviews und Stellungnahmen zu MUD-bezogenen Themen) über die Entscheidung sozialer Fragen (z.B. über das Ausschließen von Teilnehmern, die in irgendeiner Weise aufgefallen sind) bis hin zur Wartung des Codes. Für uns interessant ist vor allem dieser letzte Aspekt.
Da in den modellierten Welten gewisse Konzepte immer wieder verwendet werden, werden häufig vorkommende Objekte und Funktionalitäten in der sogenannten Corelib von der Administration gesammelt und allgemein zur Verfügung gestellt. (Tatsächlich ist es eher so, daß die Corelib zum größten Teil am Anfang der Entstehung eines MUDs vorhanden ist und später nur noch selten wesentlich erweitert wird.)
Die Anzahl der verschiedenen Corelibs weltweit dürfte so ziemlich gleich der Anzahl der MUDs sein, da eigentlich jedes MUD früher oder später seine Corelib variiert und dabei selten Gleichheiten in verschiedenen MUDs auftreten dürften. Die Anzahl der MUDs weltweit schätzen wir auf 1000 bis 2000 über das Internet erreichbare und unzählige privat installierte MUDs, die zum Entwickeln dienen.
Master- und Simul-Efun-Objekt werden mit zur Corelib gezählt.
Die "eigentliche" Modellierung der Welt (also Gegenden und spezialisiertere Objekte) geschieht zumeist nicht in der Corelib und wird auch nicht von der Administration eines MUDs ausformuliert. Ein Großteil dieses Bereiches wird von einzelnen Teilnehmern getan. Solche Teilnehmer werden "Wizard" genannt.
Den Teil des LPC-Codes, der von Wizards geschrieben worden ist, nennen wir Arealib.
Arealib und Corelib werden zusammen als Mudlib bezeichnet.
Bei den komplizierten Beziehungen, die zwischen den verschiedenen Teilen eines MUDs bestehen, ist die Frage gerechtfertigt, was alles zu LPC gehört und was nicht Sprache, sondern Anwendung der Sprache ist. Diese Frage ist auch deshalb gerechtfertigt, weil sich die Sprache für verschiedene Personen unterschiedlich darstellt. Der normale Anwender (ein Wizard) wird die Simul-Efuns nicht von den Efuns unterscheiden und sie mit zu LPC zählen; jemand, der den Driver modifiziert, interessiert sich nur in begrenztem Umfang für die vielen verschiedenen Simul-Efun-Objekte der vielen verschiedenen MUDs.
Die Grenze ist nicht eindeutig logisch festzumachen, es ist vielmehr eine Frage der Definition. Wir haben uns entschieden, alles als Teil von LPC zu betrachten, was bis zur Corelib zählt. Damit gibt es pro MUD einen LPC-Dialekt und damit auch nicht nur eine Sozialgeschichte von LPC, sondern viele verschiedene. Es soll nicht Sinn dieses Textes sein, Hunderte von MUDs zu untersuchen, vielmehr werden wir versuchen, generelle Tendenzen aufzuzeigen, die sich in den meisten MUDs finden lassen und die als typisch für LPC gelten können.
Die Sozialgeschichte einer Programmiersprache beinhaltet natürlich die an der Entstehung und Weiterentwicklung beteiligten Personen. Um ihren Einfluß beurteilen zu können, müssen wir wissen, welche Personen(-Gruppen) an welcher Stelle direkten technischen Einfluß auf die Sprache haben, indem sie Programmcode ändern.
Die Entwickler und Erweiterer der Driver sind oft nicht an ein MUD gebunden, haben aber in der Regel ein "Heim-MUD", dem sie sich besonders verbunden fühlen. Die meisten MUDs jedoch benutzen nur einen Driver, ohne über Teilnehmer zu verfügen, die etwas am Driver ändern. Die Anzahl der Personen, die einen Driver warten, ist nicht sehr groß, üblicherweise weniger als zehn Personen (nicht mitgezählt die Personen, die Hinweise über Fehler u.ä. im Driver liefern).
Jedes MUD hat eine Administration (s.o.), die sich um die Wartung der Corelib kümmert. Die Administration eines MUDs besteht meist aus wenigen Personen, die sich bisweilen durch andere Mitglieder des MUDs bei ihren Aufgaben unterstützen lassen (siehe hierzu vor allem [ILIAN]). Hierbei ist häufig eine Aufteilung der Administration in einen technischeren Teil und einen spiel- und sozialbezogeneren Teil zu bemerken. Die technischer orientierten Mitglieder der Administration beschäftigen sich eher mit dem Master und dem Simul-Efun-Objekt, wogegen die anderen eher den Rest der Corelib warten.
Die Arealib eines MUDs wird von den Wizards gestaltet. Ihr Einfluß auf LPC ist deshalb nicht direkt vorhanden, da die Arealib von uns nicht als Teil von LPC betrachtet wird. Wir werden später sehen, daß der Einfluß auf indirektem Wege jedoch nicht ausgeschlossen werden kann.
soziale entwicklung - am anfang rollenspiele (nicht computer-basiert) und textadventure (computer-basiert) (anfang 80er) - unterschiedliche selbstverstaendnisse der beiden. rollenspiele basieren auf der idee, eine _geschichte_ durch interaktion aller mitspieler zu gestalten (die mitspieler sind die helden der geschichte); textadventures basieren auf der idee, eine vorgegebene geschichte (evt. mit varianten) durch das loesen von puzzles voranzutreiben. - versuch, rollenspiele (multiplayer) auf computer zu bringen. urspruenglich mud1 (bartle) labyrinthspiel (hunt the wumpus, nethack + multiplayer) - teilung in rollenspielanhaenger (tinymud) und textadventureanhaenger (abermud) - synthese aus beiden typen in lpmud mit textadventureschwerpunkt, da kein menschlicher spielleiter und rollenspielschwerpunkt, da komplexe simulierte welt zu verfuegung steht. - staerkere automatisierung bei lpmuds, also spielleitung wird durch computer uebernommen => entsprechende sprache notwendig - erste version von lpc orientiert zwar an (nicht oo) C. oo-aspekt bedingt durch simulierungsaspekt - (oo-aspekt erschien so selbstverstaendlich (vermutlich aufgrund der weiten verbreitung), dass es nicht explizit erwaehnt wird --> http://www.NeoSoft.com/genesis/lpmud.html) ---------------------------------------------------------------------- direkte soziale einfluesse - einfluss der teilnehmer eines muds auf die sprache LPC - viele teilnehmer haben auch adventure- und rollenspiel-interesse, bestimmte genres usw. - einfluss dieses interesses auf die sprache ist vorhanden: + interesse beeinflusst mud-wahl (am anfang der "karriere", also spieler) sowie verhalten und umgangsformen im spiel + interesse beeinflusst arealib-code, den teilnehmer spaeter als wizards programmieren. (z.b. flair) + interesse beeinflusst corelib-code, den administrative teilnehmer produzieren. (z.b. automatisches rollenspiel-kampfsystem) + prinzip der corelib-aenderungen gilt auch fuer driver-aenderungen, nur dass aenderungen noch deutlich seltener sind (s.u.) - die art des einflusses wird mit jeder sozialen stufe im mud abstrakter. + know-how ist notwendig, um die abstraktheit eines problems richtig einzustufen und aenderungen an der richtigen stelle vorzunehmen (arealib, corelib, driver) + bei fehlendem know-how werden haeufig workarounds an der falschen stelle eingesetzt ("code-hygiene"). + nur ganz kleine gruppe von entwicklern ist in der lage, aenderungen auf der ebene des drivers vorzunehmen. + die abstraktheit der typischen probleme steigt mit dem alter des muds (da die einfachen probleme schon alle geloest und implementiert sind und deshalb als uninteressant gelten). ---------------------------------------------------------------------- indirekte soziale einfluesse - wuensche der spieler ("ich will ein pferd!") beeinflussen wuensche der wizards - wuensche der wizards ("ich brauche etwas, auf dem man reiten kann!") beeinflussen wuensche der admin - wuensche der admin ("ich brauche eine mobile sitzgelegenheit!") beeinflussen wuensche der driver-entwickler