Re: [Gnu-arch-users] Re: darcs vs tla

[Catalin Marinas]

On Mon, 2004-11-08 at 23:20, Dustin Sallings wrote:
> > A second problem I think is Haskell. Not so many people can help with
> > coding and it is also much slower than C or C++. The today's compilers
> > are not smart enough to optimally deal with pure functional
> > languages.
> 
>       This is clearly wrong.   Haskell was the #1 reason that pointed me in 
> the direction of darcs (and no, I didn't know very much of it at the 
> time).  I greatly support projects creating software in higher level 
> languages instead of holding so fast to the belief that it'll be slow 
> if they do it in anything other than C.

I don't have any experience with Haskell but, from the comments of the
2004's ICFP contest comments, it seems to be much slower than the
equivalent C++ code (equivalent meaning achieving the same result, not
trying to write C++ code in Haskell).

On the other hand, darcs would probably still be around version 0.2 if
David started writing it in C. Since darcs-1.0 is out, probably more
work will go into optimisation and we might soon see some improvements.

>       I write a lot of code in OCaml (not purely functional, though most of 
> my code is), and I can assure you *that* compiler optimizes very well 
> compared to gcc.  It does not seem intuitive to me that a low-level 
> compiler such as C could optimize better than a high level compiler 
> such as that of ghc, ocaml, eiffel, etc...  

[I think this gets OT] In C, the main optimiser is the programmer, not
the compiler. I also agree that programs look much nicer and easier to
write in a high level language. What I noticed with functional languages
is that they might generate a lot of garbage. While in impure languages
like LISP you can optimise this later (using things like rplaca), I
don't know whether this can be done in Haskell. Haskell also uses lazy
evaluation, meaning that more of the state of the program needs to be
preserved, increasing the memory usage. That's why I said that the
compilers might not be ready for pure languages yet. There are probably
hundreds of messages on this topic on comp.lang.functional.

>       I don't know that a source tree like the Linux kernel is all that 
> necessary, but darcs itself has had nearly 2,200 patches since 2002.  
> This is compared to about 4,000 in a project at my company with what I 
> consider to be a fairly rapidly developed project since December 2001.  
> (Actually, this project, too, is broken into two trees of about 4,000 
> patches and 3,500 patches in the same timeline).

There is already a darcs Linux repository at http://darcs.net/linux.
This proves that, if you have a powerful machine (1GB RAM prefered), you
could use darcs with the Linux kernel.

I suspect arch would also be a bit slow for a rate of 50 patches/day. It
might take a few minutes for each commit operation. You can optimise
this by hard-linking the tree to the revision library but many of the
links would be lost in few weeks of applying patches. But the big
difference is that the merge operation is fast, the patches are simply
applied onto the branch using the patch tool. Maybe time will tell if
the patch commuting operators are any different from a diff-generated
patch which preserves the context. The patch tool simply searches the
context and applies the patch when finding it. Darcs, on the other hand,
computes the exact position of inserting the changes by performing the
commutation. What the commutation operators add is the patch dependency
tracking (which you might or might not like in some cases).

One other thing I like in darcs is the possibility of cherry-picking
changes from any related repository because a merge operation doesn't
lose individual changesets. Arch generates a single patch after a
replay/commit sequence, no matter how many patches were applied. Anyway,
this is not a problem if you have a branching hierarchy and try to only
merge changes from the parent branch.

Catalin