szmmctag

  • Stack-Limits

    Ich habe die abkürzende Arc-Syntax für eine Funktion mit einem Argument mit der Version in Lists on a stack verglichen. In Arc wäre z.B. dieser Code mit 8 Token normal:

    [a (b X _)]

    Das ist eine Funktion mit einem Argument (das implizit "`_`" heißt), die `b` mit den Argumenten `X` und `_` aufruft und das Argebnis als Argument für den Aufruf von `a` nutzt. Das gleiche in Lists on a Stack:

    (a b X)

    Das sind nur 5 Token. Da Kürze ein fundamentales Ziel von Arc ist, könnte man nun behaupten, dass ein ständig implizit genutzter Stack sehr gut geeignet ist, um das Ziel von Arc zu erreichen. Ich habe damit nur ein Problem:

    Ich finde, dass bei der Arc-Version schneller erkennbar ist, was der Code macht.

    Der Grund dafür ist, dass die Arc-Syntax der Intention des Codes entspricht. Bei der Lists on a stack-Version ist nicht ersichtlich, ob zum Beispiel `b` vielleicht eine Funktion ohne Argumente ist und `a` zwei Argumente annimmt (den Rückgabewert von `b` sowie den Inhalt der Variablen `X`). Ob die gezeigte Funktion überhaupt Argumente vom Stack liest, ist ebenfalls nicht ersichtlich.

    Klar, mit vernünftigen Bezeichnern und im Kontext wäre das eher ersichtlich. Und klar, man kann ja in Lists on a stack ein Argument benennen, wo dies die Lesbarkeit des Codes verbessert, dadurch wird auch noch etwas klarer, was passiert:

    | K (a b X K)

    Aber es bleibt dabei immer noch manches unklar (obwohl wir auch hier bereits 8 Token zählen). Das ist wohl einfach der Fluch einer stackbasierten Sprache. Der Schlüsselpunkt bei der Sache ist aber, dass Syntax und Semantik in der Arc-Version sich entsprechen. Lists on a stack kann dies als stackbasierte Sprache nicht erzwingen, da sie zusätzliche Freiheitsgrade bietet, die dem entgegenstehen. Aber es spricht ja nichts dagegen, dem Programmierer die Option zu geben, je nach Fall diese Freiheitsgrade aufzugeben, um die Intention von Code expliziter zu machen, zumal hierbei die Möglichkeit besteht, dies zum Vorbeugen von stackbasierten Bugs zu nutzen. Ich schlage hierfür folgende Syntax vor:

    {...code... N}

    Code, der so umschlossen ist, soll ganz normal ausgeführt werden, mit einem Unterschied: Die Untergrenze des Stacks wird für die Dauer der Ausführung verschoben, und zwar so, dass nur noch `N` Elemente sichtbar sind. Der entsprechende Code in unserem Beispiel wäre also:

    (a {b X 1})

    Der Code "`b X`" sieht also genau ein weiteres Stack-Element (eben jenes, das wir oben beispielhaft `K` nannten). Es wird hier also explizit angegeben, wie viel vom Stack der Aufruf von `b` nutzt/verbraucht.

    Dadurch kann also bei Bedarf explizit gemacht werden, wie viele Stack-Elemente eine Funktion nutzt. Die Syntax für sich genommen bietet immer noch nicht die gleiche Menge an Informationen wie der betreffende Arc-Code, aber wir haben ein Mittel, um Code klarer zu strukturieren und Fehlern vorzubeugen, ohne dafür die Möglichkeiten eines globalen Stacks aufzugeben.

    Wie kann ich dieses Feature nutzen, um Fehlern vorzubeugen? Wenn ich eine Funktion (nennen wir sie `azubi`) an eine Funktion (nennen wir sie `chef`) übergebe, kann ich `azubi` in einem Kontext ausführen lassen, in dem sie nur auf die Stack-Elemente zugreifen kann, die für sie vorgesehen sind, wärend interne Stack-Werte von `chef` dadurch nicht durcheinander gebracht werden können. Wenn man das bei der Implementierung von `map` nutzt, sieht das so aus:

    map: | sub # Lst -> New-Lst
    (unless (nil? .)
      (recons ({sub 1}) recurse^))

    Hier wird also `sub` davor geschützt, irrtümlicherweise zu viel vom Stack zu entfernen - allerdings nicht davor, zu viel darauf zurück zu lassen; ein solches Feature wäre aber auch ohne weiteres möglich und müsste so aussehen:

    {OUT ...code... IN}

    Dabei gibt `IN` an, wie viele Argumente der Code vom Stack lesen darf, und `OUT` bestimmt wieviele Elemente am Ende auf dem Stack liegen müssen. Dann wird bei `map` also genau spezifiziert, welches Verhalten von `sub` erwartet wird:

    map: | sub # Lst -> New-Lst
    (unless (nil? .)
      (recons ({1 sub 1}) recurse^))

    In einer auf Performance optimierten Version können diese Prüfungen natürlich alle entfallen. Sie dienen nur dazu, die Intention von Code explizit zu machen und beim Entwickeln auch zu prüfen, dass diese Anforderungen eingehalten werden.

  • Implementierung des Geistesblitzes ;-) (Infogami-Blog, ca. 2 Jahre alt)

    (Keywords: Programmierung, Lists on a stack)

    Ich habe mir ein paar Gedanken dazu gemacht, wie das Zeug aus dem vorherigen Blog-Eintrag implementiert werden kann. Wir benötigen eine globale Mutex (`pthread_mutex_t`) _m_, sowie für jede Co-Routine _r1_, _r2_, ..., _rN_ eine passende Condition-Variable (`pthread_cond_t`) _c1_, _c2_, ..., _cN_ und natürlich auch je einen Thread (`pthread_t`). Wenn wir in Co-Routine _rX_ sind, dann funktioniert der Wechsel zu Co-Routine _rY_ (und das anschließende Warten auf die Erlaubnis, selbst weiterzulaufen) so:

    pthread_cond_signal (cY);
    pthread_cond_wait (cX, m);

    Wenn ich keinen Denkfehler gemacht habe, dann ist das ganze also recht simpel. Natürlich müssen noch an diversen anderen Stellen pthread-spezifische Funktionen benutzt werden, etwa gibt es Dinge, die lokal für jeden Thread existieren, wie der Daten-Stack.

    Der Vollständigkeit halber: Um diese Funktionalität zu implementieren, werde ich am besten in mehreren Schritten vorgehen:

    * Den Evaluator-Code so modifizieren, dass er darauf vorbereitet ist, dass es mehrere Co-Routinen geben kann
    * pthreads schon benutzen (etwa für den nun lokalen Daten-Stack, und für Cleanup-Aufgaben), aber es existiert immer noch nur eine Co-Routine
    * Mehrere Co-Routinen ermöglichen

    Nach den ersten beiden Schritten wird natürlich geprüft, ob alles noch so funktioniert wie bisher. Wenn nicht, dann ist relativ klar wo das Problem liegen muss.

  • Ein Geistesblitz (Infogami-Blog, ca. 2 Jahre alt)

    (Keywords: Lists on a stack, Programmierung)

    Ich habe ja schon einige Zeit überlegt, wie ich ein Feature, das Threads, Co-Routinen oder Continuations entspricht, sinnvoll in Lists on a stack integrieren kann. Ich glaube, eben habe ich die Lösung gefunden.

    Ein solches Feature zu haben ist nicht unwichtig, denn es handelt sich dabei um ein Programmiersprachen-Konzept, ohne das viele Probleme nur sehr unelegant ausgedrückt werden können. Wenn es nur einen Stack gibt, und man entsprechend nicht an passender Stelle zu einem anderen wechseln kann und zurück, dann muss man seien Code völlig anders (und zwar erheblich komplizierter) organisieren, um bestimmte Ergebnisse zu erzielen.

    Als einfaches Beispiel sei das Problem eines modalen Dialoges in einer GUI genannt. Den Code dafür zu schreiben ist simpel (im Prinzip nur eine Zeile zum Aufruf des Dialoges), aber für den Benutzer ist es sehr unangenehm, wenn er nicht das Hauptfenster der Anwendung benutzen kann, bis er den Dialog geschlossen hat. Soll nun der Dialog nicht modal sein, wird der Code entsprechend komplizierter - Es sei denn man verwendet Continuations, denn damit kann man den Code so schreiben, als sei der Dialog modal, aber für den Benutzer ist er nicht-modal! (Es gibt ein Guile-Gtk Beispiel, das genau dies demonstriert - hat mich damals sehr beeindruckt).

    Im Grunde sind Threads, Continuations und Co-Routinen äquivalent. Ich habe in Scheme schon mal Co-Routinen mit Hilfe von Continuations implementiert, das war geradezu trivial. Threads haben lediglich die zusätzliche Eigenschaft, dass man nicht explizit zu einem anderen Stack wechselt, sondern dies automatisch nach einer gewissen Zeit passiert. Das hat gewisse Vorteile, aber zumindest bei Verwendung von Shared State handelt man sich auch viele Schwierigkeiten damit ein, weil die Threads synchronisiert werden müssen. Im Interpreter von Lists on a stack komme ich letztendlich nicht ohne Shared State aus.

    Die Anforderungen im Hinblick auf Lists on a stack waren nun (natürlich) Folgende:

    * Es darf den Interpreter nicht deutlich komplizierter machen
    * Es muss auch im Compiler funktionieren
    * Auch der Compiler darf dadurch nicht deutlich komplizierter werden
    * Es sollte möglichst portabel sein
    * Es sollte optional sein (vor allem wenn es nicht zu 100% portabel ist)

    Gemessen daran, dass es sich doch um ein sehr fundamentales Feature handelt, sind das recht hohe Ansprüche. Ich schrieb mir allerdings gerade auf ein Blatt Papier das Problem und schaute es mir an. Dann schrieb ich darunter: "Es muss eine einfache Lösung dafür geben." Und schon wusste ich sie: Ich verwende POSIX Threads, um Co-Routinen zu implementieren.

    POSIX Threads sind eine ziemlich portable Möglichkeit, mehrere Stacks in C verwenden zu können. Das ist notwendig, weil ein Stack-Frame in Lists on a stack einem Stack-Frame in C entspricht (in einem Interpreter könnte man das noch vermeiden, doch spätestens in einem Compiler kommt man daran kaum vorbei, weil sonst die Effizienz erheblich schwindet).

    Wenn ich Co-Routinen implementiere, bleibt mir der ganze Aufwand der Synchronisierung von Threads erspart, und lediglich der Code des Evaluators muss geändert werden, um das Feature zu integrieren. Ich verwende dann praktisch einen "Global Lock", damit immer nur ein POSIX-Thread zugleich läuft. Dabei ist auch naheliegend, dass der ganze Zauber optional ist.

    Dann bleibt nur zu hoffen, dass die praktische Umsetzung so gut klappt wie erhofft.

  • Die heilige Schildkröte (Infogami-Blog, ca. 2 Jahre alt)

    (Keywords: Taoismus, Bücher, Zitate)

    Als Tschuang-Tse einst an einem Flusse saß und angelte, kamen zwei Abgesandte des Königs eines mächtigen Staates im Süden zu ihm und bekundeten die Absicht des Königs, Tschuang-Tse die innere Verwaltung seines Staates zu übertragen.

    Tschuang-Tse sprach: "Ich habe gehört, dass es in eurem Reich eine heilige Schildkröte gibt, die ist nun wohl schon 3000 Jahre tot, aber der König bewahrt sie in Tücher gewickelt in einem Schrein in seiner Tempelhalle auf. Was aber denkt ihr, wäre der Schildkröte lieber: tot zu sein und durch die Aufbewahrung ihrer Gebeine geehrt zu werden, oder zu leben und ihr Hinterteil durch den Morast zu schleifen?"

    Die Abgesandten des Königs entgegneten: "Es wäre ihr wohl lieber zu leben und ihr Hinterteil durch den Morast zu schleifen."

    Tschuang-Tse sprach: "Geht eures Weges. Ich ziehe es vor, mein Hinterteil durch den Morast zu schleifen."

    ------------------------------------------

    Ich bin ja bekanntlich ein kleiner Philosoph. Zum Glück gibt es aber auch große Philosophen. :-) Einer davon - und ich bin ein großer Fan von ihm - ist Tschuang-Tse (oft auch als Dschuang-Dsi geschrieben). Als kleine Auswahl seiner Texte empfehle ich das Buch "Dichtung und Weisheit" (Insel-Verlag). Mein Favorit ist dabei obiger Text, denn er verbindet alles, was typisch ist für Tschunag-Tse: Die Benutzung gelungener Metaphern, eine ordentliche Portion Humor und einen unkonventionellen Standpunkt, der keine bloße Theorie bleibt, sondern das tägliche Leben betrifft.

  • Edsger Dijkstra (Infogami-Blog, ca. 2 Jahre alt)

    (Keywords: Informatik, Programmiersprachen, Zitate)

    Hier poste ich mal meine Zitate-Sammlung des berühmten Informatikers. Ich finde, er hat eine Menge sehr kluger Dinge gesagt...

    "The tools we use have a profound (and devious!) influence on our thinking habbits, and, therefore, on our thinking abilities." -- Edsger Dijkstra

    "Simplicity is prerequisite to reliability." -- Edsger Dijkstra

    "In their capacity as a tool, computers will be nothing but a ripple on the surface of our culture. In their capacity as intellectual challange, they are without precedent in the cultural history of mankind." -- Edsger Dijkstra

    "Do only what only you can do." -- Edsger Dijkstra (attributed)

    "Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?" -- Edsger Dijkstra

    "I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language - our basic tool, mind you! - already escapes our intellectual control." -- Edsger Dijkstra in his 1972 Turing Award lecture

    "The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague." -- Edsger Dijkstra

    "The only problems we can really solve in a satisfactory manner are those that finally admit nicely a factored solution." -- Edsger Dijkstra

    "Object-oriented programming is an exceptionally bad idea which could only have originated in California." -- Edsger Dijkstra (attributed)

    "There is an upper bound on the speed with which society can absorb progress, and I guess I have still to learn how to be more patient." -- Edsger Dijkstra, 1986

  • Eigene Zitate (Infogami-Blog, ca. 2 jahre alt)

    (Keywords: Programmierung, Programmiersprachen, Zitate)

    Sich selbst zu zitieren ist toll, also los! ;-)

    "Learning from failures is nice in theory... but in practice, it sucks." -- Wolfgang Jährling, 2002

    "Wir entwickeln mit hohem Aufwand komplexe Systeme, deren zahlreiche Features am von Anwendern erzielten Resultat wenig ändern, die Produktivität aber senken." -- Wolfgang Jährling, 2002

    "Programmieren in C ist einfach: Man schreibt "for (i = 0; i <", dann fängt man an zu überlegen." -- Wolfgang Jährling, 2004

    "I like the so-called Very High Level Languages, because they try to come close to LISP." -- Wolfgang Jährling, 2002

    "When we were five people in a CAR, and I was asked whether I have enough space, I replied "I don't need much space, I'm an empty list". -- Wolfgang Jährling, 2003

    "The problem with statically typed languages is that you have to emulate dynamic typing all the time." -- Wolfgang Jährling, February 2004

    "But the problem with dynamically typed languages is that you have to emulate static typing all the time." -- Wolfgang Jährling, September 2004

    "Die Lieder der Beatles waren kurz, die Texte einfach und die Melodien einprägsam. Wir Programmierer können noch viel von den Beatles lernen!" -- Wolfgang Jährling, 2004

    "Erfahrungen sind ein Produkt von Überzeugungen - Nicht umgekehrt!" -- Wolfgang Jährling

  • Was gute Programmierer können (Infogami-Blog, ca. 2 jahre alt)

    (Keywords: Programmierung, enorm kluge Gedanken)

    Früher dachte ich immer, dass ein guter Programmierer in der Lage ist, unglaublich komplexe Dinge hinzukriegen, an denen ein Anfänger scheitern würde. Von einem gewissen Blickwinkel aus ist das ein ziemlicher Irrtum. Zwar entwickelt sich im Laufe der Zeit auch die Fähigkeit, komplexere Arbeitsschritte ausführen zu können, aber diese Fähigkeit lässt sich insgesamt doch nur sehr begrenzt entwickeln.

    Viel wichtiger ist eine andere Fähigkeit. Nämlich die, sofort zu erkennen wenn eine Aufgabe zu komplex ist um sie direkt zu bewältigen. Der fähige Programmierer wird diese dann in mehrere kleine Schritte aufteilen und Stück für Stück bearbeiten und spart dadurch eine riesige Menge an Zeit gegenüber dem Unwissenden, der sich überschätzt und an den Aufgaben scheitert, die er sich vorgenommen hat. Der gute Programmierer weiß also, wie unfähig er eigentlich ist, während der unfähige Programmierer sich für sehr kompetent hält. ("Die Dummen sind so sicher, und die Gescheiten so voller Zweifel" sagte mal Bertrand Russell.)

    Dazu ein Beispiel: Wenn man ein Stück Code schreiben möchte und einem sofort klar ist, dass der Code am Ende kürzer und verständlicher wäre, wenn man eine entsprechende Abstraktion verwendet, die dann auch für ähnliche Probleme genutzt werden kann, wird der schlechte Programmierer sofort die Abstraktion bauen und verwenden. Das wird natürlich im Regelfall nicht funktionieren (weil fast nichts sofort funktioniert). Den Fehler zu finden ist dann relativ aufwendig, weil man nicht weiß in welchem Layer das Problem liegt: In der Abstraktion oder in dem Code, der sie verwendet. Der gute Programmierer hingegen wird zunächst Code schreiben, der keine Abstraktion verwendet und sobald dieser funktioniert, ihn entsprechend abstrahieren. Statt einer komplexen Sache macht er zwei einfache.

    Vielleicht meinte Alan Perlis vor allem das, als er schrieb: "In programming, everything we do is a special case of something more general -- and often we know it too quickly."

  • Tao Te King für Programmierer ;-) (Infogami-Blog, ca. 2 jahre alt)

    (Keywords: Programmierung, Taoismus)

    Weil das Tao Te King so schwer zu verstehen ist, hier mal die Version, die wenigstens für Programmierer nachvollziehbar ist. Die ersten drei Abschnitte immerhin.

    KAPITEL 1

    Das Tao, dass sich dokumentieren lässt,
    ist nicht das ewige Tao.
    Die Software, die wir implementieren können,
    ist nicht die ewige Software.

    "Design" ist der Ursprung aller Abstraktionen.
    "Implementierung" ist der Ursprung allen Quelltextes.

    Darum führt das Studium des Designs
    zum Erkennen des Wesentlichen.
    Und das Studium der Implementierung
    nur zum Verständnis von Einzelheiten.

    Aber beide sind nur verschiedene Blickwinkel
    auf die gleiche Sache.
    In ihrer Einheit sind sie ein Geheimnis.
    Das Geheimnis aller Geheimnisse,
    das Tor zu erfolgreicher Wartung.

    KAPITEL 2

    Wenn manche Dinge als benutzerfreundlich gelten,
    werden andere Dinge schwer zu bedienen.
    Wenn manche Dinge als korrekt gelten,
    werden andere Dinge fehlerhaft.

    Design und Implementierung erzeugen einander.
    Ausdruck und Funktion stützen einander.
    High-Level und Low-Level bestimmen einander.
    Entwicklung und Release folgen einander.

    Daher programmiert der Hacker,
    ohne etwas zu tun,
    und dokumentiert,
    ohne etwas zu schreiben.

    Die Bugs tauchen auf,
    und er nimmt sie zur Kenntnis.
    Die Bugs werden entfernt,
    und er vergisst sie wieder.
    Er programmiert, erwartet aber dabei nichts.
    Wenn sein Code geschrieben ist, vergisst er ihn.
    Eben darum währt er ewig.

    KAPITEL 3

    Würdigt man die Programmierer zu sehr,
    werden die Benutzer zu schüchtern.
    Wird Ansehen zu sehr angestrebt,
    versuchen die Leute, ihre Fehler zu verheimlichen.
    Hat man zu große Pläne,
    verliert man den Überblick.

  • Lat-Tse spricht

    (Keywords: Taoismus, Zitate)

    Nochmal ein Text von Tschuang-Tze bzw. ein Auszug daraus.

    Nan Yung Tschu sprach:

    "Wenn ich nicht nach Pflicht frage,
    so verletze ich die anderen;
    halte ich auf Pflicht,
    so bringe ich mich selbst ins Unglück.

    Wenn ich keine Liebe habe,
    so ist dies schlecht für die anderen Menschen;
    habe ich Liebe,
    so bringe ich mich selbst ins Unglück.

    Wenn ich keine Erkenntnis habe,
    so nennen mich die Leute töricht;
    habe ich Erkenntnis,
    so bringe ich mich selbst ins Unglück.

    Wie kann ich diesen Schwierigkeiten entgehen?"

    Lao Tse sprach:

    "Kannst du die Einheit festhalten?
    Kannst du ohne Orakel und Wahrsagung Heil und Unheil erkennen?
    Kannst du haltmachen, kannst du aufhören?
    Kannst du die anderen in Ruhe lassen und den Frieden nur in dir selbst suchen?
    Kannst du einfältig sein?"

    Nan Yung Tschu sprach:

    "Ist denn dies das Wesen des höchsten Menschen?"

    Lao Tse sprach:

    "Noch nicht.
    Er streitet sich nicht mit den Menschen um Gewinn und Schaden.
    Er lässt sich nicht ein auf ihre Seltsamkeiten.
    Er lässt sich nicht ein auf ihre Pläne.
    Er lässt sich nicht ein auf ihre Geschäfte."

    Nan Yung Tschu sprach:

    "Ist dann also dies das Höchste?"

    Lao Tse sprach:

    "So weit sind wir noch nicht.
    Kannst du sein wie ein Kind?

    Ein Kind bewegt sich und weiß nicht, was es tut.
    Ein Kind geht und weiß nicht wohin.

    Wenn man so ist, so naht einem weder Leid noch Glück.
    Wenn man frei ist von Leid und Glück,
    so ist man dem Menschenelend entkommen."

  • Wie Lists on a Stack entstand

    (Keywords: Programmierung, Programmiersprachen, Lists on a stack)

    Von diversen Ausnahmen abgesehen gibt es in Programmen nur einige geschwindigkeitskritische Stellen. Die Idee, diese in einer performanten und gut optimierbaren Sprache wie C zu schreiben, während man den großen Rest in einer High-Level-Sprache schreibt, die sehr ausdrucksstark ist - Diese Idee hat mich schon im Jahr 2001 überzeugt.

    Welche Sprachen ich dafür einsetzen will, da konnte ich mich allerdings nicht sofort entscheiden. Als Low-Level-Sprache war C noch relativ naheliegend, auch wenn ich zwischenzeitlich sogar mal Pascal in Erwägung gezogen hatte. Als High-Level-Sprache begann ich mit Ruby, doch die Ausdruckskraft von LISP hat mich 2002 dazu gebracht, die Scheme-Implementierung Guile zu nutzen ("LISP is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud." -- Joel Moses).

    Guile ist sicher ein nützliches Stück Software; es besteht aber aus rund 68.000 Zeilen C-Code. Der Quellcode des Evaluators beginnt mit dem Kommentar: "This is the evaluator. Like any real monster, it has three heads." Das ist nur solange lustig, bis man bemerkt dass es auch wahr ist. Die Kernfunktion des Evaluators besteht aus über 1400 Zeilen überwiegend nicht-trivialem Code. Ein Monster, tatsächlich. Aber nicht das schlimmste Monster.

    2003 wollte ich Guile als High-Level-Sprache für ein Computerspiel nutzen, dessen Kern in C geschrieben war. Dazu musste ich ein Stück Code schreiben, dass mit dem Garbage-Collector (GC) von Guile interagiert. Dieser Code enthielt einen Fehler, der dazu führte, dass irgendwann der GC irgendwo abstürzte. Diesen Fehler konnte man natürlich nicht systematisch mit Hilfe eines Debuggers finden. Das fand ich sehr unangenehm. Was ich an Microsoft Windows immer am wenigsten mochte war, dass es oftmals praktisch unmöglich war, die Ursache von Fehlern zu finden, weil das System nicht durchschaubar war. Dabei spielt es auch keine große Rolle, ob das nun an proprietärer oder komplizierter Technologie liegt, der Effekt ist (leider) der gleiche: Man ist hilflos.

    2004 habe ich eine Unmenge an Material gelesen, sowohl alte Dokumente von berühmten Informatikern wie Edsger Dijkstra, als auch aktuelle Papers über moderne Entwicklungen wie AOP. Ich bin dabei zu der Ansicht gelangt, dass insgesamt die Informatik bzw. die Software-Entwicklung eher eine falsche Richtung eingeschlagen hat (auch wenn natürlich viele neuere Entwicklungen auch gut sind). Ich habe dann die Hoffnung aufgegeben, dass jemand anderes die Software schreiben wird die ich haben will, und habe beschlossen es selbst zu tun.

    Natürlich benutze ich eine Menge komplexer Software. So wie RMS nicht-freie Software benutzen musste, um die ersten GNU-tools zu schreiben, muss ich eben auch komplexe Software benutzen, bis ich einen Ersatz dafür habe. ;-)

    Anfangs dachte ich, die Lösung die ich haben will sei einfach ein simples LISP ohne GC. Ich nannte das dann Polliwog, für "POlliwog is Like LIsp WithOut Garbage-collection". Im Jahr 2005 habe ich das eigentliche Problem erkannt, nämlich dass ich eine ausdrucksstarke Sprache ohne komplizierte Komponenten will. Die Stärken von LISP habe ich soweit möglich beibehalten (insbesondere das intensive Arbeiten mit Listen), und einige Stärken von Forth/PostScript kamen dazu, weil die Sprache nun stackbasiert ist. Entsprechend wurde das Projekt umbenannt in "Lists on a stack".

    Nun habe ich es 2006 geschafft, eine erste benutzbare Version fertigzustellen, die aus ca. 3.500 Zeilen C-Code besteht. Die ein oder andere Baustelle gibt es zwar noch (und der Umfanng dürfte zumindest auf 4.000 Zeilen wachsen), aber ich kann nun anfangen damit ernsthaften Code zu schreiben. Was die Ausdrucksstärke angeht, hat die Sprache bislang meine Erwartungen sogar übertroffen. Ich habe noch nicht genügend Erfahrung damit, um endgültig beurteilen zu können, ob mein Ansatz praktikabel ist, aber eben diese Erfahrung werde ich nun sammeln.

    Update 2008:

    In den Jahren 2007 und 2008 kam ich kaum dazu, an Lists on a Stack zu arbeiten, aber momentan bin ich hochmotiviert und habe viele Lösungsideen für alte Probleme.

Footer:

Die auf diesen Webseiten sichtbaren Daten und Inhalte stammen vom Blog-Inhaber, blog.de ist für die Inhalte dieser Webseiten nicht verantwortlich.