"The mental model for Git is needlessly complex"
News flash: Many programmers love complexity.
Complexity == popularity == profit
Prove me wrong, please (I seek simpler stuff)
News flash: Many programmers love complexity.
Complexity == popularity == profit
Prove me wrong, please (I seek simpler stuff)
I used to get into exploring every nook and cranny of every config file and endlessly tweaking settings.
Now I strive to use everything with default settings if at all possible.
Not sure if you're trying to argue that Linus was a "new/inexperienced" programmer when he first wrote git.
I think the "it's too complex" argument against git is misplaced, or at least not complete. I don't find git "complicated for complexity's" sake (e.g. looking at Enterprise Java Beans back in the day), but it has a very specific workflow in mind for its conceptual model, and if you don't understand that conceptual model, you're just going to be confused.
It took me a while to grok that model, but once I did it clicked and I understood it. Not saying it's optimal, but it also has a lot of benefits.
This is an 18wheeler that can haul anything but for "basic" dev doing simple administrative apps, a bicycle VCS is more than enough. A lot of dev I've met don't even understand the deep ramifications of multiples branches with any VCS so understanding the complexity of git is way above what we require of them.
Git has a lot of benefits but I'm not quite sure that it's really a good thing that it is slowly becoming the de facto standard.
Wait and see...
Now I want my operating system and my tools to shut up and get out of my way because whatever irrelevant thing they think is important is not what I ever need to be working on.
"Git doesn't do X so I'll just make this tool to add the feature"
One hundred tools and a few consolidations into toolkits later you have a massively complex tool chain scope creeped from some much smaller problem deep down in git
Everyone will agree with us of course, but suggest something minor like "hey maybe you don't need react" and here come the reservations. To paraphrase Alan Kay, everybody likes simplicity except for the simplicity part.
Loving complexity for the sake of complexity or sake of job-security or competitive advantage covers only small subset of situations.
There’re a lot more cases where seemingly simple problem has a lot of hidden complexity, and only complex enough solutions succeed at successfully solving it and staying competitive on the market…
Entire node/js/ts ecosystem resonates strongly here. They reinvent the wheel, assign it a new name, thought-leaders market those inventions to every corner of the tech ecosystem, and then they add another few layers to their build chain.
It is easier to design complex systems and harder to simplify. Also complex systems have positive economic incentives like consulting training books or that if simple will not be sustainable.
We don't use DVCSes for their own sake, we use them to accomplish something else. To the extent that the DVCS gets in the way, it's an opportunity cost.