Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome.

For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Facebook won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or "spoken languages" (English won)

It seems to me that programming languages have far stronger network effects than any other example you or I are throwing out. If one project uses git and another mercurial and they want to work together, there are ways (hg-git, plain old patches). Try incorporating some java code in a ruby project, however. No possible way that is going to fly. Yet, we (at least the hacker news crowd) haven't declared any language as "winner". I really hope version control does not stagnate at git.

>Try incorporating some java code in a ruby project, however. No possible way that is going to fly.

I don't think this example is convincing. There are too many languages to expect arbitrary pairings to combine well. (Not to mention the fact that googling "java ruby" returns JRuby, which apparently lets you do just what you describe.)

I do agree with your last point: Even when we look at similar languages, like Python and Ruby, we don't declare one a winner, generally.

> English won

English did not won.

It might be widely spoken in the 21st century, but so were Greek, Egyptian, Latin, French, Portuguese and Spanish once upon a time.

I might be writing this in English now, but saying it won implies no change in common language will ever happen again.

Given the history of mankind and some of the countries I had the pleasure to visit on my life so far, I doubt it.

Specially since most of the people I know, do happen to speak three foreign languages on average.

> English did not won.

Apparently not.

Well, yes. Everything else I've mentioned is also dependant on cultural contexts that may vary dramatically over time. I surely hope Facebook hasn't won forever.

For what it's worth, I'm not a native English speaker.

While emacs and vim are still duking it out people are CONSTANTLY defaulting to or arguing the case for this or that because "the right tool for the job" 90% of the time means "the tool the community supports for my problem"

It's the old diversity vs. centralization/standardization argument.

Too many programming languages leads to too much fragmentation, not enough programmers well-versed in the languages, etc. Most times, we pick a language today based not on how optimized the language is for the problem, but on the availability of programmers who know how to use it. Haskell might be great, but if you're a business trying to build something, you'll have a much easier time hiring experienced C++ programmers. However, different languages have different strengths and weaknesses and applicability to certain problems, so you don't want to just standardize on one either. You probably wouldn't use Haskell on a project that is a good fit for C and needs low-level access to hardware.

It's not much different with version control, except that fundamentally all such systems aim to solve the exact same problem: managing and keeping track of source-code changes in a project. They go about it differently (distributed vs. non-distributed is a big factor), and offer different features, but they all want to do the exact same thing. And here again, programmer familiarity is an important factor. Working with git is not even remotely like working with ClearCase, for example. So people tend to gravitate towards popular choices, which was SVN before, and now has become git. So if you pick Hg for your project, you're going to probably have to spend more time getting contributors up to speed on it than if you picked something more popular like git.

One big factor in these debates is: how easy is it to change from one to another? Another is: how easy is it for individuals to pick their favorite and use that regardless of what others use? For programming languages and version control, you can't easily change between them, and everyone needs to be using the same one on a particular project (unless you do something where one part is written in one language and linked to another part in a different language through bindings, but this doesn't apply to version control). For editors, this isn't the case usually: any programmer can use whatever they want for the most part, and it has no effect on what others use.

As for your other examples, build tools are the same as version control: everyone has to use the same one on a project. You can't have one person build with make/autotools and another with scons and another with CMake. This doesn't mean you can't change it later if there's a compelling reason, but there's inertia to overcome once a project is built a certain way. ASCII did win, that should be obvious. Even Unicode is largely based on ASCII with utf-8.

> but on the availability of programmers who know how to use it

The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it.

Relevant xkcd: https://xkcd.com/1597/

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out.

Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

I think that comic also accurately describes the problem leading to that as well: it dismisses any explanation of Git's underlying mechanics and repository structure as ignorable rambling prefacing the command to do what you want.

It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memorizing commands for cvs and svn. However, now that I understand that underlying structure, every new git tool or function just provides additional means of transforming the repository structure I have into the repository structure I want.

You don't stop learning programming once you've memorized a rote sequence of steps to run a half-dozen algorithms on a hash table. And you don't stop learning git once you've memorized a rote sequence of steps to run a half-dozen algorithms on a git repository structure.

I don't mean that to suggest that git has no room to improve in its UI; far from it. But that particular comic seems to excuse a self-perpetuating problem of not wanting to learn something useful, and instead relying on people who did learn that useful thing while simultaneously belittling them for knowing it.

One of my problems with git is that I don't want to have to understand anything and source code control. It isn't something I am interested in. All I want to do is merge from upstream and commit my changes. Mercurial lets me do this without needing to understand much, whereas git makes me understand all sorts of stuff just to get this basic job done. Why should I have to understand the structure of the repository to merge something? Seems like a classic case of the UI exposing the implementation details. I get that if you are managing a large project you might want all of Git's features, but since that's not me, I just do what the XKCD comic suggests.

Learning git internals can be useful but I'm really sad that its also required. If git's UI weren't so leaky a beginner would be able to go very far with just the "graph theory model" as guidance, which is much simpler to understand.

That's the problem with git. It's extremely powerful, but requires a lot of knowledge to use well. It's a lot like a F1 racing car: the performance of such a car is phenomenal compared to a regular car, but the driver has to really know what he's doing to operate the thing at all. Just google for "F1 steering wheel" to see the controls they have to operate.

Honestly I think it's an accident of history that git became so popular for software development outside of Linux kernel development.

It doesn't help that git is really a good example of evolution, as seen in the UI. It would have been better if it had been architected more thoroughly before releasing for general use.

> The moment something ridiculous needs to be done like a rebase

Rebase, "ridiculous"? Uh oh. It's a very valuable tool and it's a quite simple concept. I agree that the user interface could be less confusing, though.

Git is just a malleable graph made out of patches. The concept is really simple (even simpler than hg). The UI could be better but the manpages are rather good at explaining how it works.

Just because something is conceptually simple does not make it simple to use. Similarly pointers are simple. They are things (usually variables) used to point to other things in memory by storing the memory address of the target. They are simple. And yet their usage is very complex.

Ridiculous, as in, a case where we actually need it is rare enough that by the time the need arises, everyone's forgotten how it works.

We're not in a shop where one-off merge commits are a thing anyone really cares about, so rebases usually mean things like "Somebody used the wrong committer name" or "Somebody did a branch merge incorrectly and now the history makes no sense".

The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

(1): The, IMO, canonical example for awful documentation design - why does a user credential switching program open with a primer to EBNF when it's hardly necessary?

> The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

Perhaps that's might apply to some git manpages, but man git-rebase in particular is really good. It has exactly what you want, example situations, the command lines to achieve them, complete with pretty ascii art diagrams.

It could still be improved, though. There might be some "oops I screwed up, what next" situations too. I think `git rebase --abort` works most of the time these days but it wasn't always so.

That's actually quite interesting - I remember similar comments (Phd required, or Phds aren't able to understand it) cropping up in discussions of the GNU autotools toolchain. (With a fair bit if justification, in my own experience, although I understand the results tended to be better for those who were shell script gurus...)

Autotools is actually quite simple to understand.

If your install needs autotools, your install is broken. :)

The number of projects that need autotools in this day and age is vanishingly small. A small script (bash/python/perl/ruby) that checks exactly what you need and then runs make instead of copying 15 years of cargo cult m4 is far superior to autotools.

It gets much worse once you step out of the open source software and start up communities.

This is exactly what keeps me on Mercurial.

I can teach Mercurial to CEO's, artists, students, etc. and some of them will be better than me on it with a week or two. All of them "get it" and it's "low friction"--they can commit and forget about it. People who need it can handle merging and the rest can ignore it. People who need branches can use it and the rest can ignore it. etc.

git doesn't allow this. git is all or nothing. Either you inload the whole mental model, or you WILL wedge your repository somehow when you execute a command that doesn't quite do what you think it does. At that point, you will spend 4 hours combing Stack Overflow for the answer. Or you will just pull up the filesystem copy of the git repo you made before executing any command other than "git pull" or "git clone".