Almost every good content creator is only on YouTube.

Nah Python is weird about static types - it only defines the syntax, not the semantics.

Ditch Mypy. Pyright is much much much better.

If I'm understanding you correctly, you can create a branch to mark where you are git branch tmp then abort the rebase. Switch to tmp get the history like you wanted, then switch back. Finally do a git rebase -i again, but immediately git reset --hard tmp. Now you have the resolved commits you want, and can delete any you don't want to do again with git --edit-todo.

Maybe.

Ah yeah LibrePCB is the only one I haven't tried actually. I guess I was put off by the name - I've found that projects that focus on geeky freedom tend to not care at all about UX, but it sounds like that isn't the case here so I'll definitely give it a shot, thanks!

Easily above average code for Python. I'm going to pick on one method:

def _set_float_icon(self, is_floating: bool):
            """ set the float icon depending on the status of the parent dock widget """
            if is_floating:
                self.float_button.setIcon(self.icon_dock)
            else:
                self.float_button.setIcon(self.icon_float)

First, Python does have ternary expressions so you can

self.float_button.setIcon(self.icon_dock if is_floating else self.icon_float)

Second, what does this code do?

foo._set_float_icon(true)

Kind of surprising that it sets the icon to icon_dock right? There are two easy fixes:

1. Use *, is_floating: bool so you have to name the parameter when you call it.
2. I'd probably rename it to _update_float_icon() or something.

Also use Black or Ruff to auto-format your code (it's pretty well formatted already but those will still improve it and for zero effort).

Not many people back up continuously, so this is still useful.

Presumably you could just buy that paper size? They're pretty similar sizes; printers all support both sizes. I've never had an issue printing a US Letter sized PDF (which I assume I have done).

Kind of weird that you guys stick to US Letter when switching would be zero effort. I guess to be fair there aren't really any practical benefits either.

Well that just sounds insane. Isn't the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?

Ugh yeah that's infuriating on Github search too. Obviously if I'm searching for some identifier I don't want 10 pages of results in /tests.

How hard can it be? Just weight anything with test in the file path lower than everything else. Job done.

I do like the author's overall point that we should try and fix the issues rather than just pretend they don't exist.

However a lot of these seem to be things that people have obviously thought of already, and they've thought about it more than the author and found problems that he just hasn't got to yet. Incremental linking for example. Yeah obvious idea but did he think about all of these issues?

Good brainstorm anyway.

It is very powerful, but it is painfully obvious that no one has ever gone back and said, “but what if anyone else who wants to use this is not a Linux cli guru and already has an expert understanding of git commands?”.

This x100. I mean I think I know the answer - Git was written by a C kernel guy, and the devs that it attracted are C guys. The kind of people who think user friendliness is a weakness. Guess how you contribute a patch to Git? Well step 1 is reading a 10 page essay... Needless to say that isn't going to attract many people that care about beginners.

Yeah I have to second UnfortunateShort. Benchmarking papers are on average very bad, often because they're trying to push a particular idea or product and are very biased, or because they're like "my first benchmark" and done by people who don't know what they're doing.

A classic one that gets referenced a lot is "Energy Efficiency Across Programming Languages" I which the authors seriously benchmarked programs from the very heavily gamed Computer Language Benchmarks Game, and concluded among other things that JavaScript is much more energy efficient than Typescript.

The only realistic way to benchmark different languages is to take implementations that weren't written to be fast in a benchmark. For example Rosetta Code, or maybe leetcode.com solutions.

Or to do it yourself. But that requires you to be experienced in many languages.

Difficult for obvious reasons.