Hacker News Reader

Comment by Guvante | Hacker News Reader

I think git gets a bad rep because no one can agree how to use it.

GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways.

And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of course reverse merges are the worst but that is a can of worms...

When pushing to a branch you can never force push but you always force push a PR branch...

Hell sometimes the easiest things create unsolvable rifts. I know of the main repo as origin and fork for my fork. Some have learned that the main repo is upstream and origin is your fork.

Neither is necessarily wrong but good luck being clear when origin can refer to two locations with such extreme use cases.

View on HN

To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.

Reminds me of what Bungie said in one of their GDCs. They don’t mind it (too much) if people get heated on their forum or subreddit, because people who care about Destiny are the ones that get worked up. It’s when most stop complaining or praising that they get worried, because it means apathy has set in.

This is a bit of wisdom that is easy to miss when you are developing a product. When people are getting worked about something and are very vocal, positive or negative, it means they care in some way. Instead of going into the doom spiral of “nobody likes what I’m building,” you can reframe it to be, “people are very passionate about what I’m building,” which is a better way to start the discussion of how to make what you have better.

The opposite of love is not hate, it’s apathy.

YoshiP director/producer of FFXIV from Square Enix said the same thing.

"3. Learn to listen and adapt. A complaint is worth twice a compliment. The silent always leave first. If citizens are complaining, it means they still care."

It's very much a "glass half full" perspective, which gets tiresome from somebody like Bjarne who is very resistant to the idea that he's made mistakes. It excuses lots of bad mistakes because hey, if people really felt that way they wouldn't use C++ right? But of course increasingly they aren't using C++ because it sucks, which is why they were complaining.

Unlike C++, Git has put considerable work into responding to complaints, understanding that while yes, they wouldn't complain if they didn't use it, they also wouldn't complain if there weren't so many things to complain about. Lots of things we use every day don't get many complaints because there's nothing much wrong with them. Even the brutal Git command line is less hostile today than it was originally.

I feel like you are being a bit unfair to Bjarne to to my knowledge isn't so much saying "we didn't make mistakes" as much as "we didn't make mistakes we should fix".

C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level.

That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse.

As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway".

Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.

Bjarne is quite happy to admit that we made mistakes, but that wasn't my criticism was it? I'm saying that Bjarne doesn't like to admit that Bjarne made mistakes.

You can't be vague and make your point here. I explained a category of "mistakes" and you simply repeated your point.

To be clear my point wasn't about who made the mistake but that some categories of mistake aren't fixable. Oftentimes people conflate "don't change it" with "it wasn't a mistake".

Found an "I made a mistake" that is very explicitly self owned. Finding counterfactuals is nearly impossible so going to leave it at that without more specificity.

> Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. With generic programming, the x.f(y) vs. f(x,y) distinction becomes a library design and usage issue (an inflexibility). With concepts, such problems get formalized. Again, the issues and solutions go back decades. Allowing virtual arguments for f(x,y,z) gives us multimethods.

Yes, Bjarne wants Unified Function Call Syntax, he has wanted UFCS since at least the 1990s, years prior to C++ 98 but was not able to get WG21 to standardize it, not least because there are a bunch of tricky questions you need to answer to add UFCS and Bjarne's answers are... not the ones everybody else prefers.

The paragraph you're citing is from C++ proposal P1962, in 2019 - it's Bjarne basically arguing, as usual, that he should get his way and blaming the committee for the resulting problems. In that section Bjarne says that OK, he has just spent an entire paper telling people that they shouldn't have the certainty they do, but why defer to him, surely he can be wrong too? This is the sole example from that text where he admits to any mistake, over 25 years ago, and he blames everybody else for the mistake anyway saying it was "fashionable" to do this even though he pointed out the problems.

We should distinguish between problems which actually aren't fixable and problems which it was decided not to fix, I don't see a lot of the former in C++, but I do see a lot of the latter. And decisions can be changed.

No, it was Bjarne saying "We definitely did make some mistakes, but we got enough of the important things right."

A philosophy that has helped me: Do what makes sense for your immediate goal and then reassess and adapt.

In practice, I actively rebase my commits in a PR with the sole focus of "What will make this easiest to review?". Then, once the review is completely I ask "What will make this easiest to operate and understand in the future?" I might squash everything together, or I might restructure into independently deployable pieces to facilitate rollback.

The point is that all these things might have different needs and it's ok to do different things at different times. But that's requires a little more judgement from individuals and is difficult to teach and enforce across larger teams.

It's important to distinguish between 'local disagreements' and 'social disagreements'.

The former are things that don't affect anyone else. Eg your co-workers don't care if you your remotes 'origin' and 'upstream', or 'fork' and 'origin'.

The latter are things you need to coordinate on with other people. Eg how you want your git history to look like in the end.

But my point is even the social disagreements are only social for your repo.

For the entirety of git they are local disagreements.

For your point, I would introduce another conceptual level. Perhaps named, 'local', 'social per repo', and 'global'.

Squishing 'local' and 'social per repo' sweeps away on important distinction, IMHO.

git gets bad rep because its cli is a terrible mess

if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

Would their git provide file system access?

What a perfect comment: it’s impossible to conclusively declare it snark (unwelcome in HN comments) or a simple observation of fact (desired in HN comments).

Shakes head: oh Apple, can’t live with you, can’t live without you.

Eh. Apple’s cli utilities are hot garbage, and with some of the poorest documentation you can find when they’re at all documented.

As bad as git is, and god knows it’s bad, launchctl is in an other galaxy of unusability.

At least launchctl is usable as a cli. Look at the xcode command line tools, in particular try to sign a bundle from the command line.

> if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

Why then does every dev I am aware of who use Apple start by installing Homebrew?

Also, you are talking about the same Apple that has a menu system that closes the menu if you click at a submenu?

I mean, it breaks at least two reasonable assumptions:

- clicking on a branch node would work on the branch like clicking on a leaf node affects the leaf

- clicking the menu works like everywhere else

Or the same Apple UX where, if I opened a dialog in my browser I cannot use the same browser to look up in the wiki where on the file server I am supposed to find a certain file I am supposed to upload?

Or the same Apple UX where there is a different shortcut depending on whether I want to switch between windows of the same app or windows from different apps?

The same Apple UX where I had to learn from application to application which features were in the menu and which were hidden under one or another gear icon?

That said, I am considering another for my next laptop.

But their UX is well and truly overrated IMNSHO.

> Or the same Apple UX where there is a different shortcut depending on whether I want to switch between windows of the same app or windows from different apps?

That one is on purpose, and I vastly prefer it to (what I presume you are implying) the "alt-tab across every window in the universe". I'm delighted that even Ubuntu now honors the alt-backtick versus alt-tab distinction, although I'd bet that is configurable, which is likely what you're asking for, too

My experience is that the Windows windowing system supports keyboard navigation through the UI elements much, much more than Apple (and often Ubuntu, too). I do prefer that, but not enough to use a vastly inferior OS that just happens to have strong keyboard UI navigation support

> My experience is that the Windows windowing system supports keyboard navigation through the UI elements much, much more than Apple (and often Ubuntu, too).

That's due to historical reasons. While both X11 and Apple could assume the presence of a mouse, it was an optional add-on for a PC back in the MS-DOS days; the original 16-bit Windows had to be fully usable even in the absence of a mouse (the only thing which came with Windows and didn't work without a mouse was the image editor Paintbrush). A lot of that keyboard-oriented legacy still survives in the Windows API.

> menu system that closes the menu if you click at a submenu?

Mine doesn't do this, unless I'm misunderstanding what you mean by submenu (I'm thinking of the thing that has a > at the end. Also why would you want to click it when it opens automatically on hover?)

> if I opened a dialog

So close it, or look up the thing before you open a modal, a rather common concept across many platforms.

> there is a different shortcut

Granularity is bad... why exactly? But a tip, get HyperSwitch (this is the real reason for writing this comment)

The last one I don't even get how you mean the OS designer would get involved with how exactly applications are made. What would the alternative mechanism be, forcing (how?) them to put everything in menus? What about right-click menus, should they be banned? How is any of this unique to Apple?

I'm not saying they are infallible, but these are some weird ass examples.

> Get Hyperswitch

I'm guessing you don't mean the payment platform, and the loads of other stuff I found while searching for that. Looks like quite a saturated name!

Anyway, for the curious: https://bahoom.com/hyperswitch

You may write 10 or even 100 examples

It's not that important, point stands regardless

Git's CLI UX is terrible.

Reply on news.ycombinator.com