[darcs-users] [Haskell-cafe] Re: poll: how can we help you contribute to darcs?

[Ashley Moran]

On Aug 03, 2008, at 12:53 pm, Lele Gaifax wrote:

> I fail to see what's so cool with GitHub: a quick overview didn't
> reveal anything that couldn't be done with, say, Trac+Darcs. Can you
> elaborate on that?

Hi Lele

It probably doesn't do anything you couldn't in Trac+darcs.  But  
that's not the point - it's easy to jump on there, and fork a repo,  
track the changes in both directions.  The barrier to working on a  
project on there is virtually nil (there is, of course, the issue of  
figuring out git when you've got the source on your machine, but  
that's a separate issue).

What GitHub does really well is build a community around the repos.   
They could have used Hg or bzr or pretty much and DVCS and been as  
successful, but they (unfortunately) chose git.


> IMHO, the biggest problem with darcs is with its underdocumented (from
> the technical point of view) code base, that only an handful of people
> understand. As already stated, I doubt Haskell is the real culprit
> here: the algorithms are effectively difficult to explain in any
> language, English to starts with. I wish David used a less succint
> coding style, and could spend some time to enlight and mentor new
> developers, but that's the way it is.

My issue with the code base is the lack of unit tests.  Coming from a  
Ruby background, I'm used to very short methods with very specific  
tests, often for things that to new programmers look trivial.  To  
RSpec users, these unit tests *are* the documentation.  By comparison,  
darcs only has functional tests, and it's hard to see how you can tell  
what code is covered by them.  This would make me very wary about  
hacking at the code, not knowing if I could inadvertently break  
something.  It also means you have to understand much bigger chunks of  
code to know how to fix something.  I've very often fixed a bug in  
Ruby code because there's a one-line spec that describes exactly the  
behaviour that is at fault (or a missing one for the case I want).

I don't know what the standard for Haskell testing is, and how FP  
testing compares to OOP testing.

As a very trivial example the function  "showPatchInfo :: PatchInfo ->  
Doc" could do with a test to show it produces output of the format  
"Initial import Ashley Moran  
<ashley.moran at patchspace.co.uk>**20080630153800]" (and if it  
*doesn't*, that is the point I'm making!)

I think having the patch algorithms broken down and tested in this way  
would be the best form of documentation, although a plain-English  
specification would probably also be necessary.  Simpler stuff (like  
showPatchInfo) just needs something to demonstrate what it does.

Just my (naive) opinion coming from a OOP, test-obsessed background.

Ashley


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/