Thursday, December 6, 2007

The Darkside is Here

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 shows 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.

Sunday, April 15, 2007

Steve is Not an Acceptable Lisper

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.