6 ms·

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with ot

• Avshalom 11y ago
  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"
• slapresta 11y ago
  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)
  • krupan 11y ago
    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.
    • alecdbrooks 11y ago
      >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.
  • pjmlp 11y ago
    > 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.
    • amake 11y ago
      > English did not won. Apparently not.
    • slapresta 11y ago
      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.
• Grishnakh 11y ago
  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.
  • bsder 11y ago
    > 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/ https://xkcd.com/1597/