[darcs-users] GHC and Darcs

[Jason Dagit]

On Wed, Jul 30, 2008 at 10:32 AM, Don Stewart <dons at galois.com> wrote:

> 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.


Oh, sorry for spreading misinformation!  It's great to hear that the rock
solid performance of ByteString is pretty much just Haskell.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20080730/d237ef76/attachment.htm