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 **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/