Hacker News Reader

I don't think it's an indictment since it's a clear tradeoff. Yes git isn't intuitive or self explanatory for newcomers, but that's only because it's optimised to be maximally efficient for experienced users.

To me, this is a sensible decision. The target users of git will use it day in and day out for decades, in this case it makes sense to prioritise experienced usage. For onboarding new users there are plenty of good tutorials, and I think in the long run it makes sense to put the legwork in with those, rather than switch to a more intuitive but less efficient porcelain.

I disagree. Git is complex solution to a complex problem (collaborative code management), so it's understandable there are complexities in mastering Git. However the UI of Git just doesn't make sense in some area's, especially to a newcomer. For a lot of people it's enough to understand the basic concepts with commands that make sense. But as it is right now the UI turns this in to hard to remember concepts and command arguments that belong more in a trivia quiz than a user guide. Also see: https://gitless.com/#research

> Yes git isn't intuitive or self explanatory for newcomers, but that's only because it's optimised to be maximally efficient for experienced users.

But that implies that a trade-off has to be there, which it does not. If you design your features well, it can both be quite intuitive for newcomers while still affording efficiency for experts.

A great example is the staging area in git. It is a horrible feature, that causes lots of interactions with other commands that are inconsistent and unclear, especially for newcomers. How to do it better? Just make the staging area a full-fledged commit. Considering that it's already pretty easy to edit a commit anyways, promoting the workflow of just polishing a commit before publication is more intuitive for users, and it means questions like "how do I see what the diff of the staging area by itself is?" is really just "how do I see what the diff of a commit by itself is?" One of those questions I already know the answer to, the other I don't.

It is encouraging with the work going into the `git checkout` split into `git switch` and `git restore` that there is growing pressure among git developers to make things more consistent for users and smooth over some of the roadblocks, including some of the confusion between the staging index and the working directory.

Mercurial solves the same problem but does it in a much more intuitive fashion without compromises for power users. Saying git is optimised for power users is just after-the-fact rationalization of git's horrible UI.

it's optimised to be maximally efficient for experienced users.

Except it's not. It's an ad-hoc accretion of overlapping functions with unintuitive naming. An attempt is being made to rectify this with the "switch" command, but it's a long way from being optimized for anything at all.

We certainly tolerate it for word processors, it is called LaTeX, and a majority of CS papers are written in it. It is pretty complex, and you sometimes need a help of outside expert, but I cannot imagine using Word instead for complex documents. One you get past the learning curve you can be much more productive.

Hm.. replace a few words and you will get a paragraph about git.

In my experience, the only advantages LaTeX has over Word are mathematics typesetting and being able to be checked into source control. Word has a fair amount of powerful features for document layout, that are often much more easily discoverable than LaTeX (although there's no indication that "Replace All" means "replace all in selection" if you've selected it).

Word certainly has a number of powerful features, but every time I use it, I find it is really hard to have your document look consistent.

In LaTeX (or Markdown, or some other markup), it is pretty easy to enforce common style: font name, font size, indentation, space around figures, and so on.

In Word, not so much -- one bad copy-paste, and your document has a few words in unusual font, or "11.8" pt characters, or "1.17" line spacing. This is especially bad if you are working together, and some of your collaborators are using non-English language -- you see a mix of "Heading 1" and "Titre 1", each configured separately.

I am pretty happy that now that I am not longer in academia, I don't need to deal with either Word or LaTeX -- it's all Markdown, JIRA's markup or, in the extreme cases, Google Docs. Still, if I had to produce a fancy looking document today, I'd probably go for LaTeX with a GUI like Lyx -- good discoverability, and pretty clean .tex files on output.

> We don't tolerate this for, say, word processors; people don't go to a piece of paper to lay out their headings and only then work out the incantations necessary to achieve that result.

There's a reasonably significant set of people that do this sort of thing. The backlash against word processors in favor of simpler focused writing tools or even simpler word processors is what I'd offer as evidence. Scott Hanselmann's video series on "How to REALLY use Word." is another example. (Word has offered powerful stylesheet features since at least 1991 and very few people actually use them, even those that could benefit.)

Very true. But the word processor example is a little scewed. It depends on the audience and the value they want to get from the tool, take Latex for example which is widely used writing scripts, being far away from WYSIWYG.

Have a look at Gitless[0]. It's a layer on top op Git which simplifies/rearranges some of the concepts and commands of Git while still manipulating the Git DB in the same way (you can switch back and forth between Git and Gitless seamlessly).

[0] https://gitless.com/