Every once in a while I don't recognize someone and I go through this whole thing of bringing up every biographical detail about them I remember and all the things we've talked about to show that I'm not an asshole who wasn't paying attention in the past. Fortunately, I have a decent memory for such things.

But also, I suspect the article is just wrong. "The hard languages got easy first" isn't true in practice and the impressive examples given are not representative or as magical as the poster makes them out to be.

The takeaway might be right in the end, but the post isn't right in the beginning.

I'm not sure this is true.

Sometimes. Sometimes they practice by text or phone.

> They’re also good at extracting information in a way that (at least currently) sycophantic LLMs don’t replicate.

If I had to guess, I think I'd guess that mainstream LLM chatbots are better at getting honest and applicable medical histories than most doctors. People are less likely to lie/hide/prevaricate and get more time with the person.

One of the things I respected OpenAI for at the release of ChatGPT was not trying to prevent these topics. My employer at the time had a cutting-edge internal LLM chatbot for a which was post-trained to avoid them, something I think they were forced to be braver about in their public release because of the competitive landscape.

It's definitely striking, I can't deny that. I crossed the last remnants of an almost-extinct glacier last year that my guide guessed would be gone in 1-3 years: at the beginning of his career it was a real glacer with non-trivial extents, crevasses, etc.

Wikimedia also seems to have a presence in the UK https://wikimedia.org.uk/ that presumably would be affected.

In most cases they might have enough pull to get folks blacklisted by payment processors, but wikimedia in particular might win that one.

    with sql_context(columns="x"):
        query, values = sql(t"SELECT {col} FROM y")

1. this is relying on the `col = "x"` in the previous example

2. columns is a set of strings, so it might be sql_context(columns={"foo", "bar", "x"}) to allow those as valid options. It just happens that "x" is a collection supporting the `in` operator so it works much like the set {"x"} would.

2a. (You might hope that something would convert such a string to a singleton set, but I don't think it does, which would have weird results with a multi-letter string.)