"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)."

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.

"One has nearly 10 times as many files, and 10 times as many lines of code as the other. Can you guess which one?"

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.

So, if Python and Ruby are "intelligent", and C and Java are "low-level", what are Perl and shell scripts? Because git's original user interface was, in fact, built out of shell scripts and Perl.

Whatever. It's remarkable how the intelligence of the programmer never seems to enter into this guy's calculation of how "intelligent" an application is.

[EDIT: Actually, having now dug through git's source repository and looked through git on my machine, it appears that the whole command-line UI is still written in Perl and shell. Thank god! For a minute there I thought that git wasn't "intelligent"! ;]

Lines of code is not an absolute metric for quality but it is a good rule of thumb (unless raw speed us the characteristic you are optimizing for.) Less code means the program or routine will be easier to read and understand and have fewer places for bugs to hide. Of course, this means lines of code in the syntax and standard libraries of the language: a program that calls a third-party library should be viewed as one that counts the lines in this library as well.

Well, git is written for speed.

Actually, the justification is given later on: tools like these, which do a lot of the commonly-repeated work for you, make it easier for you to focus on the purpose of your application as opposed to overcoming the limitations of the tool itself.

Zack, I'm directing this straight at you since I see you're the author of this post.

Honestly, posts like this are just detrimental to both communities. They're immature and show a complete lack of understanding of software development. Choosing the right tool for the job is rarely easy as "high level" and "low level".

Git was created to solve a specific need: Distributed development of the Linux kernel. The fact that it's been adopted by so many developers outside of the Kernel community shows that it is at minimum an adequate tool for the job. I'd go ahead and say, for those developers, Git > Mercurial. That's why they choose it.

For the developers who choose Mercurial, Mercurial > Git. That's why they've chosen Mercurial.

Please, before you publish stuff like this, remember that we're all on the same team. Next time, advocate Mercurial by talking about how it's improved your workflow. Talk about why Mercurial is better than Git for you, perhaps talk about the technical differences of the underlying implementations on a conceptual level.

That way, maybe you could help someone make an informed choice about what to use, instead of basing their decision on something as silly as the language it's written in.

Contributing patches is an option, too. There's a shortage of people in the open source world who are good at UI design.

Even this comment is a higher level of detail than that which was provided in the article.

In the end I think what you're saying is relatively intuitive but the internet needs less arguments based on value judgments, and more discussion centered on things we can point to, at the very least, as generally agreed upon facts.

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.

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.

And the Mercurial devs probably think the same regarding Git.

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.

Exactly. I am a huge Python fan and have contemplated giving Mercurial a go just because I know I could hack it myself if need be and that'd be cool. But I've gotten to the point where I know my way around Git well enough that I can't justify it. Besides familiarity with the commands, I've also gotten used to the workflow, which I'm sure differs under Mercurial.

"I've also gotten used to the workflow, which I'm sure differs under Mercurial."

Yes and no.

The workflow for managing branches is different, because you usually just clone an hg repo to do a branch, and then merge as needed.

The workflow for more complex things isn't quite as different as most people seem to think, though; mainly the difference is that in hg the answer is "use a patch queue". Operations on patch queues are somewhat lower level than, say, git's rebase, but all the power is still there (and there's a rebase extension which will let you do it all in one go if that's your thing).

What's been interesting to me is seeing the evolution of the "popular" git workflow over time. Originally, people hyped things like rebasing and editing commit history, but gradually the emphasis has shifted away from that and the best practices have solidified around using those features only when they're necessary, which is much less often than a lot of folks originally believed. And, amusingly, that's very close to the way hg has always been used: you can do lots of fancy stuff, but you should have a good reason for doing so (and should typically never do so after you've pushed to other folks or they've pulled from you).

From the fine article:

    In a spirit of irony, ohcount has been rewritten from Ruby to C.

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.

Actually, a pretty big feature of high-level languages is being reminded over and over that you never need to re-write the vast majority of most programs. For many tasks, two lines of awk or half a page of Python is quite sufficient. (And when something is a legitimate hotspot and benefits from being rewritten in C, it's not selling out. Where the heck did that idea come from?)

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.

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).

Seriously though, the idea that Linus designed a sub par interface for git because he was sooo 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.

The fact that it has a good Python API (courtesy of being written in Python) is a nice bonus.

This could be included in a list of more acceptable arguments for Hg. Along with a list of interface comparisons for common actions that points to a "saner interface", an explanation of the branching strategy differences would make for a blog worthy article.

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.

How would git be better at dealing with (or avoiding) a corrupted repo than hg?