[darcs-users] GHC and Darcs

Don Stewart dons at galois.com
Wed Jul 30 17:32:45 UTC 2008


dagit:
>    On Wed, Jul 30, 2008 at 6:34 AM, Patrick Waugh <[1]ptwaugh at gmail.com>
>    wrote:
> 
>      Good find.
> 
>      I have to say that I have to agree.
> 
>      I had to go back to the old version in order to get darcs-client (of
>      darcs-server) to work, because I don't have time to learn Haskell.
>      I'd really rather use darcs2, because of improvements, but oh well.
> 
>    I saw your email about darcs-client and darcs-server, but I was rather
>    confused since darcs is just darcs.  That is, there is no separate server
>    and client components.
>    
> 
>      We program in C++, C#, or Java, and Haskell code really looks very
>      unmaintainable us compared to proper OO code.  But, to each their own.
>       I think when even the quick sort example on the GHC site admits that
>      in reality it doesn't scale, and is really slow, etc. Anyone can see
>      that while for certain problems it might be a cool tool, it might not
>      be the be all end all.
> 
>    I'm starting to think that it's rather unfortunate that Darcs is so
>    distinguished by its implementation language.  I've seen flaws in Darcs
>    blamed on myths surrounding Haskell, and worse about functional
>    programming languages in general.  I don't, personally, think C# or Java
>    would be good languages for Darcs (mostly due to them not being well
>    supported on as many platforms as either C++ or Haskell), but C++ is an
>    interesting one to consider.  Originally, David did write Darcs in C++,
>    but he found that it was hard to debug and develop an experimental new
>    program in C++ so he switched to Haskell.  This switch allowed David, and
>    other very bright developers, to quickly get a working version control
>    system up and running.
> 
>    Haskell can certainly be made to scale and Darcs has lead to at least one
>    major de facto library that is quite high performance.  The ByteString
>    library spun off from Darcs's FastPackedStrings and now allows Haskell
>    developers to work with string processing that would be considered
>    optimized even compared to C string processing.  In fact, ByteString is
>    mostly C with a cleverly optimized Haskell wrapper.  What this shows is

Hmm, no! ByteString is 99.9% Haskell, with 7 lines of C for two
functions -- and those are obsolete.

>    that where scaling and performance are not attainable in Haskell, we have
>    the option to mix in other languages that are more suitable.  This
>    actually increases our ability to develop interesting applications.  We
>    use the expressive, rapid prototyping features of Haskell and once we
>    figure out the algorithms and abstractions that solve the problem we can
>    optimize them away by mixing in languages with established performance
>    characteristics, such as C.

-- Don


More information about the darcs-users mailing list