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
<[EMAIL PROTECTED]>**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/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
