8 ms·

> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "ev

> They all have [their] merits That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine". It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oops"² in exchange for new powers. We sometimes even actively try to deny others the very powers we refused to take. Here, you were very close to make that mistake about svn vs Git/Hg/Darcs. Git doesn't dominates svn yet, but I'm sure it will. Then, subversion will deserve "you should stop using it". But most often, this mistake is made with programming languages (it's a variation on the blub paradox). And the effects are far worse there. [1]: http://wiki.lesswrong.com/wiki/Fallacy_of_gray http://wiki.lesswrong.com/wiki/Fallacy_of_gray [2]:http://wiki.lesswrong.com/wiki/Oops http://wiki.lesswrong.com/wiki/Oops

selectnull 16y ago
You use words and phrases such as "poisonous meme", "should be fought tooth and nail", "demonstrably better in every way for every foreseeable usage", "dominates"... Strong words. I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.
- loup-vaillant 16y ago
  Some of my words ("poisonous") strengthen my statements. Others ("demonstrably better") restrict them. I'm aware that the relative power of tools isn't a total order. For instance, I disagree with "git > svn". For now. Therefore, bashing svn and praising git specifically isn't a good idea. But distribution may well dominate centralization for version control in general. I think the article has a point there.
  - selectnull 16y ago
    Like I said, in general, I agree with the message (of the article) which is in a nutshell: git is newer and uses a different paradigm than svn which helps in many ways. Like I also said, I didn't like the tone of the article which was "svn is dead and you should be moving along". I also think the article has a point. I just don't think it was written in most productive (dare I say fair?) way.
eli 16y ago
But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage." > We sometimes even actively try to deny others the very powers we refused to take. Huh? Who was that directed at?
- dustingetz 16y ago
  I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.
  - eli 16y ago
    I'm not personally a big SVN defender/apologist, but I'll bite. Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.
    - loup-vaillant 16y ago
      Of course transitions always cost something. For instance, C++ is the best when all your developers know C++ and have to extend a C++ code base. This examples are short term, and don't answer the question "is the new tool eventually better than the old one"? If so, consider switching costs. If not, don't even bother. So, a better example in the svn vs git matchup would be the handling of locks for binary files. Assuming of course you can't fix it yourself.
    - dustingetz 16y ago
      well obviously, but the point is in a vaccuum, git as a tool appears to be superior in every way that matters.
      - mistermann 16y ago
qubot 16y ago
Who made you the authority of what is "better"? Decisions to use tools comes from context, and there is nothing wrong with choosing a tool that fits the job. Are people who say that "every tool has qualities, therefore they're all fine" always trying to say that it does not matter what tool you use? If they are worth their salt, they will choose tool A if tool A works and is "better" than B, but will not assume B is inheritable inferior in all projects. The whole idea is to recognize the qualities of tools and asking yourself if you can really use them. Suggesting that one tool is always better enables a mindset similar to that in manifest destiny ("[God told us] our culture is better than yours, so be like us"). I'm not saying you can not be "gray" and "wrong", but being gray is not unconditionally wrong and certainly does not deserve to be called "poison".
- loup-vaillant 16y ago
  First, I agree 100% with what you just wrote. To the letter, at least. Now it doesn't mean we shouldn't be weary of sentences like "right tool for the job", "every tools has qualities". While they are correct generalities, they are often used to justify not to change habits: "We'll use C++. Don't say that, every tools have qualities. Besides, this is a big project. Languages are just tools, and you better use one that fits the job". You could try to go against this trend: "But, because it's big doesn't mean we have to use C++. It doesn't mean you have to use only one language. It doesn't mean you have to squeeze every cycle out of your CPU. What about C + Lua? Simplicity by default, and speed where you need it". But if you have to overcome fear of changing one's habits, this won't be enough. Also, you seem to think that no tool dominates another. With that I disagree. Let's start with a contrived example: Lisp vs Blub, where Blub is Lisp without macros. I think it's reasonable to say that Lisp dominates Blub. A similar reasoning led me to think that ML dominates Java and C#[1] (at least if I pretend libraries don't exist and programmers know ML). Sure, it hurts feelings to say to someone that his favourite tool is strictly worse than some other tool. But it doesn't make it wrong. [1]: http://www.loup-vaillant.fr/articles/classes-suck http://www.loup-vaillant.fr/articles/classes-suck

selectnull 16y ago

You use words and phrases such as "poisonous meme", "should be fought tooth and nail", "demonstrably better in every way for every foreseeable usage", "dominates"... Strong words. I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.

loup-vaillant 16y ago
Some of my words ("poisonous") strengthen my statements. Others ("demonstrably better") restrict them. I'm aware that the relative power of tools isn't a total order. For instance, I disagree with "git > svn". For now. Therefore, bashing svn and praising git specifically isn't a good idea. But distribution may well dominate centralization for version control in general. I think the article has a point there.
- selectnull 16y ago
  Like I said, in general, I agree with the message (of the article) which is in a nutshell: git is newer and uses a different paradigm than svn which helps in many ways. Like I also said, I didn't like the tone of the article which was "svn is dead and you should be moving along". I also think the article has a point. I just don't think it was written in most productive (dare I say fair?) way.

eli 16y ago

But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage." > We sometimes even actively try to deny others the very powers we refused to take. Huh? Who was that directed at?

dustingetz 16y ago
I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.
- eli 16y ago
  I'm not personally a big SVN defender/apologist, but I'll bite. Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.
  - loup-vaillant 16y ago
    Of course transitions always cost something. For instance, C++ is the best when all your developers know C++ and have to extend a C++ code base. This examples are short term, and don't answer the question "is the new tool eventually better than the old one"? If so, consider switching costs. If not, don't even bother. So, a better example in the svn vs git matchup would be the handling of locks for binary files. Assuming of course you can't fix it yourself.
  - dustingetz 16y ago
    well obviously, but the point is in a vaccuum, git as a tool appears to be superior in every way that matters.
    - mistermann 16y ago

qubot 16y ago

Who made you the authority of what is "better"? Decisions to use tools comes from context, and there is nothing wrong with choosing a tool that fits the job. Are people who say that "every tool has qualities, therefore they're all fine" always trying to say that it does not matter what tool you use? If they are worth their salt, they will choose tool A if tool A works and is "better" than B, but will not assume B is inheritable inferior in all projects. The whole idea is to recognize the qualities of tools and asking yourself if you can really use them. Suggesting that one tool is always better enables a mindset similar to that in manifest destiny ("[God told us] our culture is better than yours, so be like us"). I'm not saying you can not be "gray" and "wrong", but being gray is not unconditionally wrong and certainly does not deserve to be called "poison".

loup-vaillant 16y ago
First, I agree 100% with what you just wrote. To the letter, at least. Now it doesn't mean we shouldn't be weary of sentences like "right tool for the job", "every tools has qualities". While they are correct generalities, they are often used to justify not to change habits: "We'll use C++. Don't say that, every tools have qualities. Besides, this is a big project. Languages are just tools, and you better use one that fits the job". You could try to go against this trend: "But, because it's big doesn't mean we have to use C++. It doesn't mean you have to use only one language. It doesn't mean you have to squeeze every cycle out of your CPU. What about C + Lua? Simplicity by default, and speed where you need it". But if you have to overcome fear of changing one's habits, this won't be enough. Also, you seem to think that no tool dominates another. With that I disagree. Let's start with a contrived example: Lisp vs Blub, where Blub is Lisp without macros. I think it's reasonable to say that Lisp dominates Blub. A similar reasoning led me to think that ML dominates Java and C#[1] (at least if I pretend libraries don't exist and programmers know ML). Sure, it hurts feelings to say to someone that his favourite tool is strictly worse than some other tool. But it doesn't make it wrong. [1]: http://www.loup-vaillant.fr/articles/classes-suck http://www.loup-vaillant.fr/articles/classes-suck