[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