jonahx

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."

It unequivocally is AI. It's just not LLM-powered.

The rising LLM = AI equivalency is unfortunate.

I'll say that first code snippet is a fantastic TLDR.

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.

Historically true, but the original intent quickly dissolved once they app store took off and they realized the cash cow they had on their hands.

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.

If phone companies' geofence info requires a warrant, it makes zero sense that flock info does not.

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?

Until people believe, nothing will change.

I'm with you here.

When they believe, everything will change.

Taken literally, this is absurd. Belief might be necessary for change, but it's not sufficient!

That's why there is so much impetus toward despair.

Sometimes people really are in hopeless situations. It seems cruel to blame their despair on not believing enough.

Antidotically,

Anecdotally

It makes sense. People generally want at least one of: money or decision-making power.

If they have to negotiate, constantly settle, and get no money, that's a hard sell.

I think the better solution for a web page login form specifically is to disable the button "onPressDown", so this error path is impossible.

For users with JS disabled, your solution seems good.

My first thought when reading the article was: "The generous interpretation here is that whoever is fielding reports gets so many false positives that they miss true positives (like this report), especially if there's any gray area."

I'm not saying that excuses it, but it is one likely explanation for how it happened. When looking at just one report, the response seems negligent. When looking at a pile of 1000 nonsense reports, with a handful like this, I understand the difficulty.

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.

Ofc you're correct in that sense.

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.

The concept of cheating is largely unique to academia and a few uptight professions

What? The concept of cheating exists in marriages, sports, relationships, business agreements, accounting, and nearly every facet of human life.

Very cool site, but I had to leave when my mac laptop started burning my thighs...

Yes, at the prodding of the reviewer (from wikipedia):

After the announcement, Nick Katz was appointed as one of the referees to review Wiles's manuscript. In the course of his review, he asked Wiles a series of clarifying questions that led Wiles to recognise that the proof contained a gap.

It seems likely Katz played a crucial role here.

Wiles is just a prominent example. In practice, other humans often play this "verification role" for mathematicians, whether via a formal review process or informal discussion.

It would be great if someone could explain to me how AI improves this situation.

It's main utility is in the search step, not the verification step. The search is the bulk of the work and creativity. Separately, as the sibling commenter pointed out, it will likely get better at the verification step as well, with integrations of tools like Lean.

One hallucination in 300 steps of logic is enough to destroy the entire proof.

The situation with human mathematicians is not much different. Eg, Wiles original proof of Fermat's Last Theorem contained errors found by reviewers, which he later repaired.

Many programmers program for fun outside of work.

There is something very wrong on chrome mac, for me at least.

I mouse over the horizontal section and everything starts blinking and jittering wildly, then disappears. Vertical section has same issue.

I found a lot of interesting, if speculative, thoughts in the article, but...

Superhuman means unverifiable

is not true for at least large classes of problems. The recent solution of the "unit distance" problem comes to mind, or any future AI-solved math problem that was beyond the capabilities of humans. You can tell it's superhuman (it's doing things humans can't) and you can easily verify its results are correct.

For other classes of problems (eg, policy suggestions for large scale systems like the economy), the point is fair.

Yes, this is true. And is a bigger problem on large teams. One mitigation is a comment by the original author at both sites that there may be a coupling in the future.

But, again, the point is that you don't know yet whether you have a single source of truth or not. It's a question of the relative badness of duplication vs premature abstraction in cases where the code may diverge or converge in the future. There is no generic answer. But as a heuristic, based on my personal experience, I have always found premature abstractions to be more painful to work with. Even more so when someone else has authored them.

I believe that "single source of truth" is a principle that should always be followed

Fundamentally, the article addresses cases where it's not clear yet how many sources of truth there will be. Are the two spots in the code using the same algorithm, or slightly different versions? More importantly, will they change for the same sorts of reasons?

The title adage (correctly, imo) argues that making two different things the same will cause you more pain than making two same things different via duplication. In the latter thing case, the "damage" is just having to make the same changes twice, or doing a refactor to introduce the abstraction. In the former case, you have to keep adding to your abstraction, or undo it. Most crucially, it breaks "locality", which is the only property you really care about when making changes. I just want to make this change and not worry about side effects to unrelated parts of the system.

Assuming this pans out, every other professional linguist in the world has had the option to use Claude or other LLMs, but has not solved this problem, despite the incentives for doing so. It stands to reason the human is adding crucial value.