Keep that in mind when they make arguments about propofol... Which is one of the drugs mentioned in https://www.theatlantic.com/health/archive/2017/12/surgical-... and https://gwern.net/doc/psychology/neuroscience/pain/anesthesi...

https://web.archive.org/web/20120411063647/http://squid314.l...

"What did the doctor say? He told me that they couldn’t up the anesthetic because an overdose could cause respiratory arrest, and that it wouldn’t matter because the anaesthetic on any dose caused severe short term memory loss and whatever happened the patient would forget all about it. The second point, at least, was right on. One patient spent the entire procedure writhing in agony and screaming something incoherent to God. The doctor finished the procedure, took out the endoscope, and cut off the anesthetic, and the patient turned his head, looked the doctor right in the eye, smiled, and said, laughing “Wow, that wasn’t bad at all! Guess I slept right through it!”"

This is why LLMs are really great 'knocking off the todo/wishlist' of things you always meant to do. The problem, as far as broader discussions of 'productivity multipliers' or 'total factor productivity' go is that there's a certain perverse diminishing returns to such wishlist items (if each item was all that important, why didn't it get done before?), they generally only apply to a small part of a large complicated whole (what % of your ecosystem/business/community as a whole is the login page, as pleasing and profitable as that fix is relative to the investment? Probably not a big %), and they are also finite (what happens when you have worked through your backlog of lowhanging fruit?).

So in a way it's proving its own point. Why painfully write out by hand in English when the LLM will do a better job by porting your English prompt to AIglish and get +235 points and #3 on HN?

The LLMs follow the rules rigorously (barring a handful of inessential remaining errors like 'wires'), but show that you can easily satisfy the letter and not the spirit of the exercise, and that Grow-Speech can be flimsy and arbitrary once you start trying to use it seriously for something much more ambitious than https://gwern.net/doc/cs/algorithm/1998-steele.pdf because you just start using phrases or obscure Anglo-Saxon words (even if you can't go full Anglish).

When I look back at it now, I realize that Steele spends a lot of the apparently impressive length on fluff or descriptive language, and trades heavily on the fact that we already know what a programming language is or what an integer or an object is. I do not think anyone who doesn't have at least a hazy grasp of 'object' is really going to grasp a definition like:

> An object is a datum the meanings of whose parts are laid down by a set of language rules. In the Java programming language, these rules use types to make clear which parts of an object may cite other objects. Objects may be grouped to form classes. Knowing the class of an object tells you most of what you need to know of how that object acts. Objects may have fields; each field of an object can hold a datum. Which datum it holds may change from time to time. Each field may have a type, which tells you what data can be in that field at run time (and, what is more, it tells you what data can not be in that field at run time).

But when you try to tell people about something genuinely unfamiliar like REINFORCE, the obscurity becomes clear. (I'm going to revise REINFORCE to "a rule that makes moves in runs that beat a base more apt, and moves in runs that fall short less apt"... but it's not that much better, honestly.)

The point was it was dangerous in a way they didn't even realize was an issue, for a thin business rationale. Unless you are going to do thorough tests and understand the risk you are taking (which they did not, as evidenced by screwing it up systematically at scale for years), you should not be doing it.

And it's not obvious that they are correct in their tightened-up testing, because even if a link is correct at the time they test it, it could break at any time thereafter.

> to which you appear to be a generally-satisfied customer!

No matter what _X_ is, _X_ would have to be a pretty epic screwup to make a customer unsubscribe solely over that! I never claimed it was such a major epic screwup that it could do that. So that is an unreasonable criterion: "well, you didn't outright quit, so I guess it can't be that bad." Indeed, but I never said it was, and somewhat bad is still bad; I was in fact fairly annoyed by the random breakage, and at the margin, everything matters. If TB did a few other things, in sum, they could potentially convince me to let my subscription lapse. An annoyance here, a papercut here, and pretty soon a generally-satisfied customer is no longer so satisfied...

Example: The Browser is a well known link aggregation paid periodical. I subscribe, and every 1 in 10 or 20 links I clicked, it'd just break outright and I'd have to tediously edit the URL to fix it (assuming the website didn't do a silent ninja URL edit and make it impossible for me to remember what URL I opened possibly days or weeks ago in a tab and potentially fix it). This was annoying enough to bother me regularly, but not enough to figure out a workaround.

Why? ...Because TB was injecting a '?referrer=The_Browser' or something, and the receiving website server got confused by an invalid query and errored out. 'Wow, how careless of The Browser! Are they really so incompetent as to not even check their URLs before mailing an issue out to paying subscribers?'

I wondered the same thing, and I eventually complained to them. It turns out, they did check all their URLs carefully before emailing them out... emphasis on 'before', which meant that they were checking the query-string-free versions, which of course worked fine. (This is a good example of a testing failure due to not testing end-to-end or integration testing: they should have been testing draft emails sent to a testing account, to check for all possible issues like MIME mangling, not just query string shenanigans.)

After that they fixed it by making sure they injected the query string before they checked the URLs. (I suggested not injecting it at all, but they said that for business reasons, it was too valuable to show receiving websites exactly how much traffic TB was driving to them on net, because referrers are typically stripped from emails and reshares and just in general - this, BTW, is why the OP suggestion of 'just set a HTTP referrer header!' is naive and limited to very narrow niches where you can be sure that you can, in fact, just set the referrer header.)

But this error was affecting them for god knows how long and how many readers and how many clicks, and they didn't know. Because why would they? The most important thing any programmer or web dev should know about users is that "they may never tell you": https://pointersgonewild.com/2019/11/02/they-might-never-tel... (excerpts & more examples: https://gwern.net/ref/chevalier-boisvert-2019 ). No matter how badly broken a feature or service or URL may be, the odds are good that no user will ever tell you that. Laziness, public goods, learned helplessness / low standards, I don't know what it is, but never assume that you are aware of severe breakage (or vice-versa, as a user, never assume the creator is aware of even the most extreme problem or error).

Even the biggest businesses.... I was watching a friend the other day try to set up a bank account in Central America, and clicking on one of the few banks' websites to download the forms on their main web page. None of the form PDF download links worked. "That's not a good sign", they said. No, but also not as surprising as you might think - the bank might have no idea that some server config tweak broke their form links. After all, at least while I was watching, my friend didn't tell them about their problem either!

Ah yes. I remember this in Penny Arcade: https://www.penny-arcade.com/comic/2004/03/24/the-adventures...

Just as their words are presumed to be meaningful and worth reading... but slightly less so every day, I fear.

Preserved by whom? Many leaks are done by old or ex-employees who quietly kept a shall we say 'backup' of their work. More than one 'official' re-release has been rumored to be an embarrassed company quietly filing the serial numbers off a rogue leak because they realized way too late that their archival practices were inadequate.