ludwik

It's not "code" that was written to mimic humans. It's weights that were trained, and exhibit behaviors that were not anticipated by the people doing the training.

Just a reminder that there are two completely separate store chains called "Aldi": Aldi Nord and Aldi Süd. Depending on where you are, you may be referring to a completely different Aldi.

I'm fairly sure that nobody at Google thinks it's the search engine's job to "console [the user] and be an empathetic listener rather than just find what [they are] looking for on the internet." It seems quite clear to me that this is a bug - undesired behavior caused by the LLM not properly understanding the context / use case in which it is being used (and, more broadly, by the use of general-purpose models trained to handle all kinds of different tasks).

[Disclaimer: I do work on AI at Google, but nothing related to Search, so this is my subjective personal opinion, not based on any first-hand knowledge of this specific case.]

You are talking about switching between models, the parent comment was about switching between harnesses. Not the same thing.

That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.

It is a sound argument in the context of trying to estimate what it costs them to generate this specific output. They have training cost eather way.

It sounds like, of the three options given, you are squarely in the “authorities” camp (although it seems to me that you interpret the question as asking what you believe should happen, whereas it appears to be asking what happens in practice). Wouldn’t it be interesting to hear the other points of view?

Why this is preferable? I would rather have the apps I use represented as a list of apps in my system (drawing on a couple of decades of established UX conventions for how they are displayed and how I can interact with them), the web content I'm reading represented as tabs in my browser, and my terminal sessions represented in my terminal. You present the destruction of this simple separation of concerns as a benefit, but don't explain why it is one.

> From the various reports, including by people aware of gmail's stance, gmail may have had a bug allowing it at some point.

I think these are simply people who cannot believe that someone might give out an email address they do not actually own, either because they are confused or because they make one up on the spot just to fill in a required form field. So when they receive messages intended for someone else but addressed to another variant of their own address, they treat that as proof that the intended recipient owns that variant. In reality, people giving out email addresses they do not own is extremely common.

I see a lot of people swearing up and down that they have seen proof that such a Gmail bug exists. But whenever you dig into the details, it turns out that all they have actually seen is emails intended for someone else arriving in their inbox. There is never any direct evidence that two people were able to register two Gmail addresses that normalize to the same canonical address.

Wait, what you're describing sounds like Gmail working exactly as documented. If I understand correctly, your name is something like John P. Smith, and there is also someone named John Psmith. You own [email protected], which means you also own every variation of that address created by adding or removing dots, such as [email protected] or [email protected]. This of course includes [email protected]. It is entirely yours, and nobody else can have it. If someone gives it out as their own address, they are simply confused.

I registered my Gmail account very shortly after the invite-only public beta began, so my Gmail username is simply my first name (in this example, it would be [email protected]). Believe me, I know a thing or two about confused people giving out email addresses that don't belong to them.

Importantly, the dot-normalization rule was there from the very beginning. You learned about it alongside all the other kooky ways Google had decided to reimagine email, including 1 GB of storage, conversation threading, and an interface with a prominent "Archive" button but no visible "Delete" button.

I understand that this isn't entirely clear-cut and that people will interpret it differently, but in my opinion, there is a significant difference between "a webpage that contains text X" and "an HTML document that contains text X." "Webpage" and "HTML document" are not synonyms - "HTML document" has a much narrower meaning.

In my mind, the part that is most likely to fail is "return an HTML document that still contains the following text." Nowadays, more and more "HTML documents" do not contain any content at all, just some JavaScript that is responsible for then fetching and displaying the content.

Since this is a long-standing, real-world problem that linters solved, how could it not be relevant to a discussion about the usefulness of linters?

And the choice of whether to use tabs or spaces does not affect semantics. It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.

It definitely is relevant to a discussion about linters. And as I said on my comment - it's just an example, I mentioned other types of discussions as well.

Oh, absolutely. I started writing Python professionally in 2010. Whenever a new group of people started working on a Python project, one of the first things they had to decide was tabs versus spaces. Everyone would begin by saying that the question was unimportant and silly, but then immediately add a “but” followed by a detailed justification of their personal preference. That would lead to people spending two full days exchanging arguments and links to blog posts.

Worse, sometimes you would start working on a project without having that discussion first, only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces. You would then have to pause the work, go back, have the discussion, and decide who was going to fix all the code committed so far.

This only stopped when linters became popular. They may be a little like vaccines: when they work, you do not see them working, so it is easy to forget what things were like before. But believe me, when they appeared, they were a breath of fresh air. We could finally focus on discussing the work rather than the conventions.

And tabs versus spaces is only one example. There used to be PR discussions about countless style issues throughout the entire lifetime of a project. That was not entirely unreasonable, because a consistent style genuinely makes a project easier to work on. But when every individual convention has to be negotiated by humans, it takes enormous amounts of energy and becomes tedious very quickly.