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 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. But, the other point you bring up, the one of OO and maintainability is hard to discuss. This is an almost political point, but one that certainly deserves equal attention. It's been shown that technical people will debate the merits of tool X vs. tool Y (also language, platform or methodology) at length and sometimes fervently; hopefully we can avoid that here. The most I can say is that I understand and respect your point of view, and I challenge you, or anyone else that wants to develop on Darcs without learning Haskell, to make your own Darcs compatible program in your favorite programming language. If the claims people make about wanting to help with Darcs but only if it's written in Java/C++/etc are true then you'll succeed in attractiving devs and it will be a win for everyone. And I'm sure people here would be happy to answer questions that come up as you're working on such a project. I'd love it to be a big success because I think darcs itself is a move > in the right direction. Indeed, as evidenced by the influence Darcs has had one many other version control systems. Linus quite liked many features of Darcs, and probably would have used it if the performance would have been sufficient for kernel dev. Thus we can be sure that Darcs was one of the vcs that inspired Git. If you start a reimplementation of Darcs, please announce it here. Thanks for your feedback, Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
