3 ms·

At 15 thousand lines, git-annex is only 5 thousand lines less of haskell than darcs. I happen to know, since I wrote git-annex. I'm not sure where you're coming

by joeyh 15y ago

At 15 thousand lines, git-annex is only 5 thousand lines less of haskell than darcs. I happen to know, since I wrote git-annex. I'm not sure where you're coming from with your statement about there only being two large haskell programs. For that matter, I don't know if I'd consider darc's 20 kloc very large. Or that I'd consider another haskell program I wrote, github-backup, to be small -- that 2 kloc program sits at the apex of a lot of libraries, and probably combined they have more lines of code than darcs. Your whole premise about lines of code feels thoroughly flawed to me. Anyway, As a git extension, git-annex is expected to run quite fast. I've never had any difficulty, in writing git-annex, with the speed of haskell code. I'm sure darcs is slow due to its patch theory thing, not due to its implementation language.

duaneb 15y ago
> I'm not sure where you're coming from with your statement about there only being two large haskell programs. I concede the point, but I'd rather say that there's only one large haskell program. Let's consider large C/C++ programs: 1. Chromium clocks in around 4 million lines of code. 2. LLVM/clang together has a (fuzzy) estimate of ~1165539 LOC on my system. 3. GHC has unknown lines of code, and I am unsure as how to count it, whether to include the standard library, etc, but it has at least 100k, so we'll just call that sufficiently large. Now, I know haskell can be fast—I've spent a lot of time myself hand-tuning ghc processed code. But I've noticed that unless I can trace the bottleneck to a single function or small set of functions, optimization to near-c levels is extremely difficult. Now, even 2-3x slower than c—far slower than ghc-generated code—is still very fast, so I'm not calling haskell slow. Far from it.
- joeyh 15y ago
  Actually, there are packages in hackage with > 100 kloc: CHXHtml KiCS-debugger HaRe

by joeyh 15y ago

duaneb 15y ago

> I'm not sure where you're coming from with your statement about there only being two large haskell programs. I concede the point, but I'd rather say that there's only one large haskell program. Let's consider large C/C++ programs: 1. Chromium clocks in around 4 million lines of code. 2. LLVM/clang together has a (fuzzy) estimate of ~1165539 LOC on my system. 3. GHC has unknown lines of code, and I am unsure as how to count it, whether to include the standard library, etc, but it has at least 100k, so we'll just call that sufficiently large. Now, I know haskell can be fast—I've spent a lot of time myself hand-tuning ghc processed code. But I've noticed that unless I can trace the bottleneck to a single function or small set of functions, optimization to near-c levels is extremely difficult. Now, even 2-3x slower than c—far slower than ghc-generated code—is still very fast, so I'm not calling haskell slow. Far from it.

joeyh 15y ago
Actually, there are packages in hackage with > 100 kloc: CHXHtml KiCS-debugger HaRe