On Wed, Jul 30, 2008 at 10:32 AM, Don Stewart <[EMAIL PROTECTED]> wrote:
> dagit: > > On Wed, Jul 30, 2008 at 6:34 AM, Patrick Waugh <[EMAIL PROTECTED]> > > 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
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
