"Applications written in higher-level, dynamic languages (like Python and Ruby) are always going to be more ‘intelligent’ than those written in low-level, static languages (like C and Java)."<p>He positions this as a given, and moves on with his only justification being that websites feel "smoother to use" when written with Django or Rails.<p>"One has nearly 10 times as many files, and 10 times as many lines of code as the other. Can you guess which one?"<p>In addition to being snarky, I think the lines of code written as a metric for software quality is as about as useful as selling software with "smoother to use" printed on the box.
I never get these Git vs. Mercurial debates. I don't see why they matter. Pick something you like & are comfortable with & can use well - and then learn that tool well.<p>Linus certainly doesn't care if you think Mercurial's better than Git. He doesn't agree. He wrote a tool to help him manage the Linux kernel source trees, something it does well. His goals never have been making the most elegant or intelligent software, but making good software that works. And it's a strategy that's succeeded.<p>And the Mercurial devs probably think the same regarding Git.<p>As an aside, I wonder what would have happened had not Linus popularized distributed version control systems. I doubt we'd even be having this discussion. I certainly hadn't been exposed before hearing about the BitKeeper debacle.
From the fine article:<p><pre><code> In a spirit of irony, ohcount has been rewritten from Ruby to C.
</code></pre>
Wasn't it the whole point of high level languages to be able to prototype quickly, and then perhaps re-write selected parts in lower level for better performance and portability? This even happened to Hg; parts of it (diff, IIRC) got implemented in C later on for better performance.
What puts Git in a class of its own is the astonishing efficiency of its implementation. It is one of those rare instances where a quantitative difference becomes a qualitative one and in my opinion makes Git an engineering masterpiece.<p>Obviously this is related to its being a C program. The OP's error in comparing code sizes is the implicit assumption that all other things are equal.
Under this bullet-proof logic the best applications would be written in AppleScript (spoiler alert: they're not).<p>Seriously though, the idea that Linus designed a sub par interface for git because he was <i>sooo</i> busy mallocing and freeing is laughable.
I just like hg because it has -- in my opinion -- a saner interface and a more useful branch strategy for the types of stuff I'm usually doing.<p>The fact that it has a good Python API (courtesy of being written in Python) is a nice bonus.
Clearly the guy who wrote this has never had to deal with a corrupted repo before. I have never used Hg but it happened to me enough times in Subversion to convince me to switch to Git. The lines of code metric is silly. How about who /wrote/ those lines? I'm very happy entrusting my version control to the same guy who wrote my operating system, thank you.
A lot of the commenters need to read <a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a> (the section titled 'The Blub Paradox' is particularly relevant, but the entire essay is fantastic). In addition, the concepts of essential complexity and accidental complexity are addressed quite comprehensively in Fred Brooks' essay 'No Silver Bullet' (Google it).