Common Lisp gilt, wie keine andere, als die "programmierbare Programmiersprache". Nur wenige Programmiersprachen ermöglichen es, derart einfach neue Programmiersprachen zu entwickeln. In meinem Artikel "Evolution einer Skriptsprache" (erschienen in Ausgabe 3'2007 der Toolbox) zeigte ich die vollständige Implementierung einer kleinen Programmiersprache mit dem Namen "Fun".

Ein wesentlich beeindruckenderes Beispiel ist hingegen die Python-Implementierung CL-Python von Willem Broekema.

Tags:lisp, python

Seit der Jahrtausendwende konnte man den Eindruck gewinnen, es sei am Horizont endlich die Annäherung einer Lösung in Sicht; der lange anhaltende Konflikt der Regierung der Volksrepublik China mit der tibetischen Exilregierung schien auf beiden Seiten zumindest grundsätzliche Gesprächsbereitschaft durchscheinen zu lassen.

Die aktuellen Entwicklungen zeigen ein anderes Bild: Die Welt ist sprachlos ob der Bilder die aus Tibet ins Ausland durchdringen: Am 49. Jahrestag des tibetischen Aufstands gegen die Kommunistische Partei Chinas demonstrierten buddhistische Mönche für die Freilassung ihrer letztes Jahr inhaftierten Ordensbrüder; diese hatten die Verleihung der Goldmedallie des Kongresses der Vereinigten Staaten an den im Exil lebenden Dalai Lama gefeiert.

Die Stimmung schlägt um

Die Demonstration wandelte sich schnell in offene Proteste gegen die chinesische Regierung; Tibet solle Unabhängig werden, verlangte die aufgebrachte Menge und steigerte sich bis hin zu gewaltsamen Übergriffen, Brandschatzungen und Plünderungen. Korrespondenten verschiedener ausländischer Nachrichtendienste und Touristen berichteten vom gewaltsamen Vorgehen gegen nicht-tibetanische Bevölkerungsgruppen wie den zugewanderten Han und Hui (Die Han stellen mit weit über 90% den größten Anteil des aus 55 ethnischen Gruppen bestehenden Vielvölkerstaats China dar; die Hui gehören zu einer muslimischen Minderheit). Laut einem Beitrag von James Miles, Tibet-Korrespondent des "Economist", hatte es sich es sich sowohl um kleine Gruppen Jugendlicher gehandelt, als auch um Ansammlungen von dutzenden Männern, Frauen und Kindern die randalierend und plündernd durch die Straßen getobt hätten um Steinbrocken nach Autos, Fensterscheiben und flüchtenden Chinesen zu werfen. Autos und geplünderte Läden wurden in Brand gesteckt. Miles berichtete auch von gemischten Gefühlen Ortsansässiger: Ein Mönch soll ihm geschildert haben, wie er einen Jugendlichen versteckt habe, der sich - verfolgt vom wütenden Mob - vor ihm auf den Boden geworfen hätte; der Junge wäre ein Angehöriger der chinesichen Han-Bevölkerungsgruppe gewesen. Es sieht alles danach aus, als ob sich nun der lange angestaute Hass auf die von der Regierung angesiedelten chinesischen Einwanderer in einer Welle unkontrollierter Gewalt entlädt. Der Dalai Lama spricht seit langem von einem "kulturellem Genozid" gegenüber den Traditionen und der Lebensweise seines Volkes; die umstrittene Politik der "Sinisierung Tibets" würde Tibeter zur Minderheit im eigenen Land machen. Die chinesische Regierung investiert zwar viel Geld in Infrastruktur wie Straßen und Gebäude, aber wenig in die Weiterbildung oder Förderung der tibetischen Bevölkerung. Viele Tibeter sind Analphabeten; wichtige Ämter oder Arbeitsplätze bleiben ihnen mangels Bildung verschlossen. Stattdessen werden immer mehr Chinesen in die Region migriert um diese Aufgaben zu übernehmen. Tibet ist nicht die einzige Region in der Volksrepublik China, in der den Minderheiten der Aufstieg zu Wohlstand und einem guten Leben verschlossen blieb. Es gehört nicht viel Fantasie dazu, sich vorzustellen, dass der Regierung in Peking alles daran liegt eine Ausweitung der Proteste über das ganze Land zu verhindern.

Volkskrieg gegen den Separatismus

Prompt hat die Führung in Peking reagiert: Mit Tränengas, Schlagstöcken und massiver Präsenz von Polizei und paramilitärischen Truppen versuchen sie dem Treiben ein Ende zu setzen. Es soll scheinbar ein deutliches Zeichen gesetzt werden: Soweit und nicht weiter!
Regierungen in aller Welt reagieren - wie erwartet - entsetzt, rufen die chinesiche Führung zur Mäßigung auf und erhalten als Reaktion eine Erklärung, man habe einen "Volkskrieg gegen den Separatismus" ausgerufen; ein Ultimatum wird an die Aufständischen gestellt.
Für viele bei uns scheint die Situation vollkommen klar zu sein: Tibet müsse frei sein! Wieder ein unabhängiger Staat. Das Unrecht, begonnen mit dem Einmarsch der chinesischen Volksbefreiungsarmee im Jahre 1959, müsse rückgängig gemacht werden. Doch ist diese Sicht so unstrittig richtig? Scheinbar identifizieren sich selbst weite Teile der westlichen Medienlandschaft fast reflexhaft mit diesem Bild. Eines ist klar: Die Regierung der Volksrepublik China und die Exilregierung Tibets sind sich offensichtlich uneinig darüber, wann Tibet ein Teil von China wurde und ob dies legitim war.

Jahrhundertelange Auseinandersetzungen

Kriegerische Auseinandersetzungen zwischen Tibet und China gehen bis ins siebte Jahrhundert zurück. Sogar die damalige chinesische Hauptstadt Chang'an (heute Xi'an) fällt im achten Jahrhundert in die Hände der Tibeter: Der chinesische Kaiser hatte sich geweigert weiter Tribut zu zahlen. Unter der Herrschaft des Mongolen Kublai Khans als chinesischer Kaiser gelingt es schließlich 1268 n. Chr. Tibet zu erobern. Die mongolischen Herrscher lassen das Land von tibetischen Geistlichen führen. Altan Khan verleiht Sonam Gyatso, dem Großabt der Gelugpa, einer der vier Hauptschulen des tibetischen Buddhismus, den Titel "Dalai Lama" - "Ozeangleicher Lehrer". Bis 1959 galten die Dalai Lamas sowohl als geistige wie auch politische Führer eines streng hierokratisch organisierten feudalistischen Kirchenstaates. Ein Großteil der Bevölkerung bestand aus abhängigen Bauern, die für die Lamas alle nötigen Arbeiten verrichteten. Anfang des 18. Jahrhunderts - die Mongolen in China sind mittlerweile von den Mandschus abgelöst - wird die Hauptstadt Tibets vom mongolischen Fürsten Lha bzang Khan eingenommen; der 6. Dalai Lama wird nach China vertrieben und ein anderer an seine Stelle gesetzt. Nach Machtkämpfen verschiedener mongolischer Stämme marschiert ein Heer der Qing-Dynastie (China unter Mandschu-Herrschaft) auf Lhasa und befreit Tibet von der Terrorherrschaft des westmongolischen Stamms der Dsungaren. Die Tibeter setzen den 7. Dalai Lama ein und laut tibetischen Quellen beginnt zwischen China und Tibet eine bis 1900 anhaltende "Patron-Priester-Beziehung"; zum beiderseitigem Vorteil: Die Tibeter standen im Schutz des chinesischen Reiches (u. a. gegen Nepal) und China hatte eine klare Regelung seiner Grenzen und Gebietsansprüche gegenüber Ländern wie Indien und Nepal.

Angriff aus Großbritannien

Doch auch damit endet die lange Kette der Eroberungskriege um Tibet nicht. Aus Angst, Russland könnte Großbritannien mit dem Aufbau von Handelsbeziehungen zu Tibet zuvorkommen, erobern britische Truppen 1904 kurzerhand das Land und töten in einem Massaker nahezu die vollständige tibetische Armee von 1500 Mann; der Dalai Lama flieht in die Mongolei. Drei Jahre später wird Tibet in einem Abkommen zwischen Großbritannien, China und Russland der Schutzherrschaft Chinas unterstellt. Die chinesische Führung der Qing-Dynastie versucht in den kommenden Jahren diese Ansprüche durch den Einsatz militärischer Mittel zu sichern. Doch im Jahr 1911 endet die Qing-Dynastie unter dem letzten chinesischen Kaiser Pu Yi in der Xinhai-Revolution; die in Tibet stationierten Truppen verlassen das Land. Wenige Monate später wurde die Republik China gegründet - und Tibet als Provinz Chinas gewertet. Entgegen diesen Plänen erklärt der 13. Dalai Lama Tibet für unabhängig und kehrt 1913 nach acht Jahren im Exil in seine Heimat zurück, obwohl kein anderer Staat die Unabhängigkeitserklärung anerkennt.

Das Ende der Lama-Herrschaft

Im China der 20er und 30er Jahre tobten Bürgerkriege und der Zweite Japanisch-Chinesische Krieg. Trotzdem wurde immer wieder versucht die Ansprüche auf Tibet durchzusetzen. Nach der kommunistischen Revolution und der Gründung der Volksrepublik China im Oktober 1949 wurde abermals Anspruch auf Tibet erhoben: Tibet sollte vom britischen "Imperialistischen Joch" und von der Feudalherrschaft des Dalai Lamas befreit werden. Zu diesem Zeitpunkt waren etwa 700000 der 1,25 Mio. Tibeter abhängige Arbeiter, die auf den Klostergütern der Lamas zur Arbeit verpflichtet wurden. Das Leben der Bevölkerung glich damit tatsächlich jenen Umständen, wie sie im feudalen europäischen Mittelalter vorherrschten. Die Volksbefreiungsarmee besetzt im Oktober 1950 das Land. Einen Monat nach der Kapitulation übernimmt der 14. Dalai Lama im Alter von 15 Jahren – ungewöhnlich früh – die Regierung Tibets. Er steht für einen neuen Kurs, grundlegende Reformen und demokratische Grundlagen. Unter dem Druck der chinesischen Regierung unterzeichnen Vertreter der tibetischen Regierung das 17-Punkte-Abkommen in dem Tibet regionale Autonomie und Religionsfreiheit zugesichert wurden. Auch das bestehende politische System Tibets sollte unangetastet bleiben. Obwohl die Vertreter ohne die Zustimmung ihrer Regierung unterschrieben, stimmte diese später trotzdem zu; insbesondere da das bestehende polititsche System beibehalten werden sollte.

Bis zur Gegenwart

Durch die Bildung von Volkskommunen sollten die in einigen Teilen Tibets lebenden Nomadenstämme sesshaft werden. Diese Entwicklung widersprach nach Ansicht vieler Tibeter den Versprechungen des 17-Punkte-Abkommens. Es kam immer wieder zu Aufständen, die mit Gewalt niedergezwungen wurden; Strafaktionen folgten. Am 10. März 1959 kommt es zum Volksaufstand in Tibet und der Dalai Lama flüchtet sich ins Exil nach Indien.

Ein Paradigmenwechsel in Tibet

Bis heute hat sich an diesem Status nichts geändert. Fast jedes Jahr kommt es am Jahrestag des Volksaufstands zu Protesten in Tibet. Der Unterschied heute: Bislang waren die tibetischen Protestierenden stets verhältnismäßig friedlich – hier liegt eindeutig ein Paradigmenwechsel vor. Vor allem unter jüngeren Tibetern wird zunehmend eine höhere Gewaltbereitschaft vertreten; der gewaltfreie Kurs des Dalai Lama gilt unter Ihnen mittlerweile als überholt. Die kommenden Wochen werden zeigen wie sich die Lage im nun abgeschotteten Tibet entwickelt. Hat der Dalai Lama die Kontrolle über die Tibetfriedensbewegungen verloren?

Tags:tibet, china

Wie manche meiner Leser bereits wissen, arbeite ich als Journalist. Ich habe mein Weblog bislang hauptsächlich genutzt, um Neuigkeiten zu meinen Open Source Projekten zu veröffentlichen. Ich habe mich jetzt dazu entschieden mehr Arbeit in mein Weblog zu stecken - CODEartist.org wird in Zukunft mehr Themen bieten und bilingual (Englisch/Deutsch) sein. Nicht alle Artikel werden in beiden Sprachen veröffentlicht werden. Die Artikel über Common Lisp werden - wie bislang auch - in der Kategorie "Lisp" einsortiert sein; damit sollte es für Planet Lisp möglich sein die Lisp-Inhalte vom Rest zu trennen.

I really think that Gary brought up the discussion about Lisp library packaging at the right time. My logs definitely seem to hint at the existence of a formidable interest about this topic. I've taken a look at Matthew Kennedy's Lispy project, which strives to be a next generation package manager for common lisp and Gary brought up another topic, which I've thought about some years ago: an abstraction of modules above single systems (I called it "worlds").

Lispy

DISCLAIMER: I've just looked very briefly at the code of Lispy!

Matthew Kennedy's Lispy aims to be simple and easy to use and is based on concepts which are proven to work for Linux distributions. Lispy is not really centrally organized, but it doesn't seem to emphasize distributed facilities very much. It seems to be quite easy though to setup a Lispy repository - all you need is some web space and a mapping file which stores metadata about all provided packages. As far as I understood it, versions are handled as chronological markers and there is a distinction between versions which come from package authors and versions which are managed by the Lispy system. There are MD5 sums of the asdf-system tarballs to enable efficient ways for verification of integrity and authentication. Matthew's design is based on his experience from managing Lisp packages for the Gentoo portage project and it actually is designed as a system to manage package distributions. In regard to my find/acquire/verify/authenticate quadruple he decided not to conflate loading of packages and installation of packages into one operation (acquire); this is maybe indeed the better thing to do. I didn't understand really who is responsible for the creation of the mapping-files; particularly where the :depends-on information is coming from. My opinion about Lispy is, that it looks very well designed. On the first sight it seems to be more suited for package maintainers than for developers. That may sound a bit weird, what I actually mean is that it seems to be more suited to manage released versions of a package. What should I do if I need a particular (perhaps locally patched) version of a package for only a particular project? If I understand Lispy right, then I would define a repository (mapping-file) for each such project. It also doesn't seem to support fetching packages out of scm repositories (cvs, darcs, svn...) and defines asdf-packages as tarballs. I still think the MD5/SHA digest should be computed from a defined order of the files of a source package and not from a tarball. Perhaps there could be an ASDF operation which computes the digest instead of compiling the files - so the digest would be defined only by the files relevant to the ASDF-System.

Worlds Apart

To me a world in the common lisp system management context is a logical bundle of systems used in a particular project or setting. It defines the context needed for development and deployment. A system-version could be uniquely identified by its system-name and a digest from the defined order of the content files. This would also mean, that world is actually defined by the a set of particular versions of asdf-packages. If one changes one of the packages it is not the same world anymore. This is similar to the concept of identity in git (see e. g. Nikodemus Siivola's explanation) Gary's command-set for working with worlds (he called them "environments") looks a bit to procedural to me. I would prefer a more declarative syntax. So instead of writing CREATE-WORLD and CLONE-WORLD as a user I would rather use a DEFINE-WORLD macro which defines the dependencies of a world. A world should know anything needed to upgrade the systems if needed. So if a system in my world is defined to track the changes of a particular branch in a scm system - so be it. I think worlds could be quite similar to the shelfs of cl-librarian. The main difference between "worlds" and "mapping repositories" (like in lispy) is that the first is a set of asdf-systems from the standpoint of a asdf-package user and the latter is from the standpoint of a package-publisher. The only reason to publish a world definition is actually to readily deployable (batteries included) projects. So the packages within a world should in some way depend on each other while the packages within a mapping repository (a "distribution") may have the only common point that they are maintained by the same person.

Tags:asdf, lisp

An often raised complaint against ASDF is the quite unfriendly syntax of one of its most basic operations: Loading a system.

(asdf:operate 'asdf:load-op :my-system)

I think this can not really be an issue, can it? How often does one actually have to type this thing? Systems are typically loaded as dependents of other systems. So I wouldn't actually use ASDF:OPERATE! I just type the system-name in the :depends-on clause of my system definition.

Interactive Development!

The sole exception to this is interactive development. It is quite common to load a system to try something out without officially adding it as an dependency to your system. Perhaps you do not even have a system for your code yet. The point here is: Loading a system while doing interactive development does not really need to be by directly using the programmatic interface of the ASDF-library; I'm using an editor command within the LispWorks IDE to interactively load a system. This even provides me with name-completion for asdf-systems. Writing something similar for slime should be trivial (if it doesn't exist yet).

Why Not Colon Commands?

A recent discussion on comp.LANg.lisp about colon commands on the lisp REPL showed that most common lisp implementations provide such a REPL command feature; why not just define an :asdf, :load-asdf or :la colon-command?

Tags:asdf, lisp, lispworks

Gary King, a fellow lisper and diligent blogger started a discussion about making asdf-install better. First: I do not use asdf-install either. Before I tell you why I don't use it let me try to think about the points Gary raised.

1. It doesn't play well with Windows

Gary's first argument is that asdf-install doesn't work well with Windows, because of it's use of Unix utilities for tasks like archiving or signing/verifying. I agree that this is an issue, but nothing that couldn't be solved by just using ports of those utilities for windows.

2. It doesn't play well with itself

The second argument just describe some obvious short-comings of asdf-install. It doesn't handle updating your libraries in any way and it can only download and install tarballs. Gary is right here too; asdf-install is just not enough.

What do I think?

Gary is a smart guy and definitely is on the right track with his idea. I do not agree is his idea to make asdf-install better, but only because I think that asdf-install isn't a good base for anything. I think managing asdf-packages is too important to be left outside of lisp. I think there are enough high-quality libraries to handle the necessary tasks in common lisp and without airy callouts to shell utilities.

Well... but asdf-install is written in lisp!

Technically yes, but if you look into other general purpose lisp-libraries, you will see that a good lisp library should be flexible enough to adapt to many different use cases. A good lisp package manager needs to be extensible in at least four directions:

1. How to find packages (cliki, cl-user.net...)
2. How to acquire packages (e. g. tarball, zip, CVS, Darcs, SVN, git, e-mail, local folder)
3. How to verify integrity of packages
4. How to authenticate the identity of the supplier of a package

Finding a package should be a decentralized task. It should be possible to easily setup your own package registry. There could be different technologies used, but I think there should be at least a web-based one which doesn't demand more than some static web space. An interesting point here is, that finding a package might not necessarily be a proactive step. Maybe one could register to some typical package feeds, and as soon as a new version is announced, it will be acquired by the system. If the protocols of this component are done right, than there is no perceivable difference in finding a package somewhere in the internet or already installed on your harddrive. There should be no need for symlinks or *central-registry* hacking. The installed packages happen just to be cached on your harddrive

There is nothing special behind the technologies to acquire the packages. One important thing is the change of notion for an asdf-package. Up to now it was actually a tarball with a certain structure. This does not hold anymore if we want to acquire packages through other channels like version control systems. Maybe an asdf-package should defined as the decompressed folder. The handling of a compressed asdf-package seems obvious to me, regardless of it being archived using tar/gz, zip or whatever.

The most obvious way to verify the integrity of an asdf-package seems to be a digest algorithm like MD5 or SHA. But if we define asdf-packages to be just folders and not tarballs anymore, we have the problem, that there is no obvious way how to compute the digest (because there is no defined order of its components). One idea may be to include a manifest-file with each asdf-package and use the order defined by this manifest to compute the digest; there may certainly be different ideas. A manifest-file could be useful for other things too though. It should be a very easy one step action to bless a package as released and create the necessary stuff like the digest and perhaps the manifest.

I've not thought very much about authentication. There are some evident solutions possible; one of it actually used already by asdf-install. The crux is to find a way which will actually be used, instead of just switched off by most users.

The package manager should understand different versions of a package. In the past the version-info was always encoded in the system-definition. I'm not sure if this is the right place for it. Regardless of this; the package manager has to handle packages with and without versions. The version-number is probably a good idea to order the different package-versions by age. But time is only one dimension in which different versions of a package could be placed. I think there should be something like a unique identifier for each version of a package and the best candidate for this would be the digest for the concrete asdf-package.

The package manager needs to handle dependencies between asdf-packages in a better way than just trying to load it and acquire the package on fail (like it is done in asdf-install). Actually this approach seems caused by a misfeature of asdf itself; there doesn't seem to be a way to ask an asdf-system for its dependencies.

My wishlist in very short: A new package-manager for asdf should:

1. be written in common lisp
2. be able to use different package sources
3. be written in common lisp
4. not mandate airy-fary use of OS-dependent stuff like symlinks
5. be written in common lisp
6. neither makes downloading nor finding packages a centralized task
7. be written in common lisp
8. have well-defined CLOS protocols for future extension
9. and of course: It should be written in plain common lisp!

Thanks for your time! I really want to hear what you think about this ideas.

Tags:asdf, library, lisp

For most of my projects I'm using the distributed revision control system darcs. I particularly like how easy and streamlined it is. Creating repositories, branches or pushing single patches around is just a matter of a few minutes in learning time. Another nice feature is, that you can commit only parts of the changes in a single file; darcs will just ask you about each change. Choosing the changes one wants to record on the command line can be a tedious process though. This is why I wrote us an internal tool called "Darkside" which allows us to easily pick all changes using a straightforward dialog. The following screenshot shows the "Patch Recorder" tool of Darkside. An editor pane below the change-tree shows which lines were removed (red) and which were added (green). Darkside is written in LispWorks using CAPI.

The next screenshot show the second tab-pane of the interface. Here one can write the log-message for the current record. I extended darcs' notion of a patch name a little bit by providing a combo-box with certain tags like "Feature", "Change", "Bugfix" and so on. The selected tag gets enclosed in brackets and then prepended before the patch-name. This is actually just a convention we developed using darcs. The list-pane below the log-editor shows other patches which have been recorded before. It is possible to double-click those lines to paste the log-text of this patch into the log-editor.

CL-Darcs: A Common Lisp Implementation

The original darcs (which is used in Darkside too) is written in Haskell, a statically typed functional programming language. The installation is simple: just copy the executable somewhere into your path. Wouldn't it be nice to have an implementation of darcs in common lisp? Well, we have luck! Thanks to Magnus Henoch's cl-darcs there is already a common lisp library which aims to be compatible with the original darcs implementation. The code is nicely structured and good readable. One really missing thing for a cl-darcs to ensure compatibility to the original darcs is an extensive test-suite. But Magnus implements the command-line interface of darcs on top of the common lisp API so that one can use the official darcs test suite. I think cl-darcs is a very promising project.

Tags:lisp, darcs, capi, lispworks, gui

I've now completely rebuilt my server based on Edi Weitz' amazing webserver hunchentoot. Currently I'm investigating on how to make PHP work with it without resorting to apache again.

Tags:lisp, hunchentoot, web

CODEartist.org was down for maintenance for a while now. There will be more from me as soon as some of my current projects are finished. Stay tuned for some lisp-related announcements here...

Steve Yegge raised an interesting point in his blog. He mentions that some time ago Eric Kidd wrote an article called Why Ruby is an Acceptable Lisp and Steves article is meant as a response to that claiming that Lisp itself may not be an acceptable Lisp at all.
Steve said in his introduction:

I guarantee you there isn't one single Lisp programmer out there who uses exclusively Lisp. Instead we spend our time hacking around its inadequacies, often in other languages.

Well I've used Lisp almost exclusively in the last 6 years. I do not think it has to be this way - I have absolutely no problem using another programming language if it fits better to the demands of my tasks. I also learned many other languages in this six years; but for most problems that came up I did use Lisp and it never was a real problem.
Steve seems a bit obsessed about "length" in all kinds of shades so I will try to give an elaborate overview of the points he raised:

Problem 1: Which Lisp

In short this section talks about how difficult it is to choose a Lisp because there are so many implementations of it. I never quite understood what the problem was with this. I'm quite happy to have a multidimensional choice out of commercial/non-commercial, bytecompiled, native, Mac, Windows, Linux, Solaris, big, small, slow, fast, embeddable, whatever implementations of Lisp.According to Steve, choosing a Lisp seems difficult too, because Paul Graham planned to create his own Lisp (Arc) and this would mean something like "don't use Lisp!". I always thought choosing a programming language should be done by analysing ones needs and what is offered from the available options.
Steve mentioned another difficulty arising, when a hypothetical newbie chooses a Common Lisp implementation:

Eventually, if they stick with Lisp at all, they learn they can override most of these defaults in nonportable ways, which makes things infinitesimally more bearable.

Well - it seems Steve himself is not yet at the point were he realizes that exactly this adaptability is what makes Lisp the language it is. For me "CL" means not only "Common Lisp", but also "Compiler Language". I know no other language which makes it so easy to adapt it to that kind of language you want and need.

Problem 2: Worthless Spec

This section argues that the Common Lisp spec (ANS X3.226-1994) is ancient. Well it's twelve years from that time - maybe thats really a long time for a language spec. He claims that everytime someone proposes to update the standard someone else does not agree to that. That's true - there are many people who think redoing the official standards process which lead to ANSI Common Lisp might be to much work for the gain. What I do not understand with Steve's concerns about this topic is, why other languages like Ruby or Python are allowed to evolve without any official standard at all and Common Lisp is only allowed to change through a labour intensive ANSI process?
Some years ago someone suggested creating a COMMON-LISP-2006 package (I've updated the year 'cause I cannot remember when the proposal was) and extending the language the way one wants within this package. This technique is used by many Lispers to adapt CL to their needs and it could also get used to adapt "Common Lisp the Language". Even better would be an approach which would be modular; allowing CL2006 implementations to implement only parts of the CL2006 package tree. But I think such an approach is not really needed. As with any current programming language: Solutions grow out of actual problems. If there is no solution for a particular problem, someone will write a solution for it if he needs it. Interoperability and reuse are programming problems too and people will write solutions.It's not a new thing for Lisp - not even for any other Programming Language - that there are people who like more to talk, argue and discuss than to simply sit down and solve their problems. Fortunately the Lisp community has quite a lot talented programmers who have contributed in a constructive and helpful way to create useful solutions for Lisp-using people.

Problem 3: CLOS

Steve claims some things which are factually not true with CLOS. I recommend any Lisper to get a copy of the book "The Art of the Metaobject Protocol" - IMHO this is an essential lecture for any programmer who wants to understand object oriented programming; not only in Lisp. For the curious: you can read what Steve got wrong with CLOS (and other things) by reading the comments to his blog entry. I don't think its necessary to duplicate what already was said.

Problem 4: Macros

Steve builds up an analogy between CL Macros and duct tape. While being entertaining to read, I don't see were this story fits with the topic of Lisp being no acceptable Lisp. The points raised are old: "hygienic" vs "not-hygienic" macros, whining about the syntax - the only new and innovative one is Steve's complete misunderstanding that CLOS is made as just a set of macros.
Problem 4: Type System(Yes the numbering is quoted right - Steve has chosen to use this for an analogy between type systems and incorrectly numbering headings) In this section Steve promises to talk more about type systems - but not now. There is nothing more than a loose mention that the CL type system may be flexible but not enough. After his claim that Haskell and OCaml are faster because of their type systems my intention to read up his next posting about type systems dropped below zero.
I think this whole exercise in trying to write a rant about something you do not even fully comprehend is entertaining but useless.

Tags:lisp, blog