"karate chop flashlight" love this description! That's exactly why I've stayed with Motorola after my G5 just got too slow. I'm now on a Moto G Pro from 09/2020, it's getting fairly slow but all in all it gets the job done.

This. I have argued with plenty of developers on why comments are useful, and the counter arguments are always the same.

I believe it boils down to a lack of foresight. At some point in time, someone is going to revisit your code, and even just a small `// Sorry this is awful, we have to X but this was difficult because of Y` will go a long way.

While I (try to) have very fluid opinions in all aspects of programming, the usefulness of comments is not something I (think!) I'll ever budge on. :)

> // Sorry this is awful, we have to X but this was difficult because of Y

You don’t know how many times I’ve seen this with a cute little GitLens inline message of “Brian Smith, 10 years ago”. If Brian couldn’t figure it out 10 years ago, I’m not likely going to attempt it either, especially if it has been working for 10 years.

But knowing what Brian was considering at the time is useful, both due avoiding redoing that and for realising that some constraints may have been lifted.

And in a few million years, the next intelligent life form will examine remains of human texts, and wonder: with all the tools and knowledge they possessed, how could they not have prevented their demise?

(Sorry for pessimism and offtopicism)

We are but puny agents of entropy.

I'm trying difft for git now and I also really like it. One reason why I think it shouldn't be the default is that it hides whitespace differences. Maybe that's configurable though, haven't looked into that

It's a tad silly that they made this the default

That’s not the only silly thing they did. Ansible is awful.

That is so obvious.. yet I've never thought to try this in 10 years of using git.

For your mypy performance question, make sure it's using incremental mode [1] so that it can skip checks on code that didn't change. Yes, it is probably among the slowest of type checkers, but it is also quite thorough.

[1] https://mypy.readthedocs.io/en/stable/command_line.html#incr...

It sounds like incremental mode is the default now? I've noticed that it runs much faster after the initial run, with no special configuration

But that link also mentions daemon mode [1], which supposedly "can be 10 or more times faster", so that could be something to try. Running as a persistent server with an in-memory cache is probably part of why LSP-based type checkers like Pyright can perform better than mypy.

[1] https://mypy.readthedocs.io/en/stable/mypy_daemon.html#mypy-...

And that's why I never trust/use x.0.0 releases because they must have missed something :)

Same reason why many people wait a couple of days before updating their OS to the next major version.

Sorry did you say days? Still on macOS 10.14 after almost 5 years. It'll be fine~

Depending on how much that equality check is deciding the application's performance, jsonifying to compare stuff is fairly ok.

Just beware of any lists which you'll need to sort manually (on both sides) to prevent false negatives :)

I bet they also pulled out the "but the code will change and then the comments become invalid, or even gasp misleading"?

Absolutely, and could not be convinced that if the code and comments got out of sync then it was likely that the function name would no longer make sense, and that's when we get real trouble.

There were horror stories with that codebase, like index.php was set as the default error handler, started by immediately returning 200 OK before going anywhere near URL dispatching, and then displaying a page that said 404 despite returning 200 if it couldn't find the URL.