I'm not sure how this would "ruled on", but my take is that the website itself has enough functionality, enough ways to view and slice and dice the info, so to speak, that it can be tried out, and is not merely a "list".
> Imagine approaching fundamental scientific research like that. "Welp, it can't make money, so it won't happen."
> There is more to society than capitalism.
I don't read GP like that. I read it as "we should recognize a situation of unstable incentives for an important outcome, and start thinking about other solutions."
Any one off event is an example. But I assume you know that, so can you clarify what you mean by "a probability that can not be analyzed in terms of frequencies or other proportions"?
That's clever rhetoric, but for most use cases it's just not true, and that's the point of the original article. There are legitimate use cases for native apps, but many of them could be converted to an instantly loading, 50-100KB web page without losing any functionality. As opposed to a 50-300MB native app, which you need a fast connection to install, and starts up more slowly than the web page every time you use it.
> We take tech literacy for granted, because it's like a dozen levels down fundamental to our entire field. But the tech illiterati exist, and they love apps.
They "love apps" because apple and android have spent billions to break their mental models and convince them that "you use apps to do things on your phone". Literally. That's the extent of most people's understanding.
So, sure, they "want" apps in the same sense that early internet users "wanted" AOL because in their minds AOL and the internet were indistinguishable. But actual free choice requires an understanding of the choices.
This affinity for verbal tics, too, seems learned from humans...
See, for example, "synergy", "proactive", "in the loop," and hundreds more that proliferate in corporate jargon with even more senselessness than the LLMs.
Is there any realistic road to having them outlawed nationwide? Eg, ignoring probabilities here, could a wildly successful grassroots program where it became an issue as politically salient as immigration or abortion eventually lead to legislation banning them?
I strongly recommend against auto-squashing. It creates large commits without the semantic intent of the author. In a large PR, you want clean, small, semantic commits, which makes it much easier to review and understand.
Becoming very comfortable with "rebase --interactive" and other cmds for editing your (local!) history before merging helps a lot. Once you are, it only adds 5m or so of extra work to most PRs. And while acquiring this knowledge used to be difficult, LLMs make it very easy these days.
I would add that (related to your "maintainability" point) ensuring the code is as simple as possible, and thus much more likely to be "debuggable by review", is a goal of review. Even that won't prevent bugs in the absolute sense, as you rightly say, but it boosts your probabilities.
It's a good practice. Worth mentioning also: the same can be done with ordinary git log, assuming everyone is using git well. A proper git log of yesterday's work can be like your work newspaper with coffee.