I believe you misunderstand what "average" is: Americans (or people in general), on average, do not fly much.

Some — eg. those who've moved for work — probably fly 10-15x the average, and 10-15x of people fly 1/100th of average. Flying cost and availability correlate with average needs, but that presupposes that some people have higher needs altogether.

Yes, when you have an obvious reason to track some data, do it: I do not think anyone questions that.

Proactively capturing and tracking everything you can to prep for any future is too much work that would really steal your time from, you know, actually living a life.

This is the obvious "benefit" of hindsight. Yes, you accidentally had access to data that provided historical patterns you exactly could use.

But, for anyone who does, there is another 1000 who do not when something hits them: many illnesses develop gradually, and all of our tests (thousands of blood tests, scans and imaging tech...) would benefit from having historical data when we were "ok".

Similarly, you probably did not have more data than what Apple provided to help narrow the problem you still had, right?

And if everyone was put under so many tests, we'd actually be "solving" a bunch of non-issues for people over-reacting to small deviations from "normal" range.

Apple watch helps you with a few parameters — not to be discounted — but I don't really see it as a counter.

With Linux systems, if there wasn't a configuration option to override something, you'd be able to create a fork and still do it. So low level layers in Linux have become flexible enough that you do not need to do it, even if there are opinionated UIs on top.

That's a good one, I must admit.

FWIW, Serbian Cyrillic cursive does not have that issue, or at least not as bad: https://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/%D...

How fast can you write in cursive vs non-cursive? I am much slower in non-cursive when writing.

The only issue is that my cursive is pretty lousy looking.

I'd hedge to say roughly the same, but that's writing print in chicken-scratch handwriting (which is my norm) and under-practiced with cursive. I'd suspect after using cursive a bit I would speed up. Similar to using home-row when typing vs pick-and-peck or whatever they call it

My phone would transcribe even quicker than that, though, which would probably be my go-to instead of hand-writing

I find it hard to speak into my phone while I am in a live meeting and trying to summarize my instant thoughts for paper or my Remarkable :)

Vector tracing was a thing way back, and from there, it was probably some simple programming to make a font out of a number of vector glyph images.

In fairness to GP, they said VCS, not Git, even if they are somewhat synonomous today. Other VCSes did support graph histories.

Still, "3rd dimension" code reasoning (backwards in time) has never been merged well with code editing.

> In fairness to GP, they said VCS, not Git

I did say VCS, but I also don't know what Git is missing in this relation.

> Other VCSes did support graph histories.

How does Git do not?

> Still, "3rd dimension" code reasoning (backwards in time) has never been merged well with code editing.

Maybe it's not perfect, but Git seems to do that just fine for my taste. What is missing there?

> Other VCSes did support graph histories.

Yes, git ain't the only one, but apart from interface difference, they are pretty much compatible in what they allow you to record in the history, I think?

Part of the problem here is that we use git for two only weakly correlated purposes:

- A history of the code

- Make nice and reviewable proposals for code changes ('Pull Request')

For the former, you want to be honest. For the latter, you want to present a polished 'lie'.

> - A history of the code

Which is a causal history, not a editing log. So I don't perceive these to be actually different.

Not really. Launchpad.net does not have any public branches I could share atm as an example, but Bazaar (now breezy) allowed having a nested "merge commit": your trunk would have "flattened" merge commits ("Merge branch foo"), and under it you could easily get to each individual commit by a developer ("Prototype", "Add test"...). It would really be shown as a tree, but smartness was wven richer.

This was made possible by using a DAG for commit storage and referencing, instead of relying on file contents and series of commits per reference. Merge behaviour was much smarter in case of diverging tip or criss-cross merges. But this ultimately was harder and slower to implement, and developers did not value this enough and they instead accepted the Git trade-offs.

So you seamlessly did both with a different VCS without splitting those up: in a sense, computers and software worried about that for us.

I am not quite sure what you are describing here. Git's underlying commit graph is a DAG.

You can use different, custom merge-drivers (or whatever it's called) for Git to get the behaviour you describe here.

Certainly, but merges are treated differently by default, and getting to this sort of output would require "custom" tooling for things like "git log".

Whereas bzr just did the expected thing.

You can select whether you want the diff to the first or the second parent, which is the difference between collapsing and expanding merges. You can also completely collapse merges by showing first-parent-history.

Or I do not understand what you mean with "the expected thing".

Yes, `git log --first-parent` has been a godsend for coping with our team's messy non-cleaned up history.

Good naming and good tests can get you 90% of the way to "why" too.

Agreed. Tests are documentation too. Tests are the "contract": "my code solves those issues. If you have to modify my tests, you have a different understanding than I had and should make sure it is what you want".

Having "grown up" on free software, I've always been quick to jump into code when documentation was dubious or lacking: there is only one canonical source of truth, and you need to be good at reading it.

Though I'd note two kinds of documentation: docs how software is built (seldom needed if you have good source code), and how it is operated. When it comes to the former, I jump into code even sooner as documentation rarely answers my questions.

Still, I do believe that literate programming is the best of both worlds, and I frequently lament the dead practice of doing "doctests" with Python (though I guess Jupyter notebooks are in a similar vein).

Usually, the automated tests are the best documentation you can have!