munch117

Compare with this:

  double f(void* p) {
    return * (double*) p;
  }

No one is surprised that defensive code isn't issued to guard against p being NULL, unaligned, or pointing to a uint16_t. You told the compiler that p is actually pointing to a double, and it generates code accordingly.

It's the same thing here: You told the compiler very explicitly that anything following this point is unreachable, and it generated code accordingly.

I'm not defending writing code with UB. I would have preferred the compiler issuing a warning saying "you say this is unreachable, I don't believe that it is", when it's this obvious. Maybe issue a trap instruction. But there's nothing wrong it, per se. When you choose to override the compiler's judgment and insist that this point in code is unreachable, then the compiler takes your word for it.

Of course things go badly once we reach "unreachable()", continuing into the next function because the compiler didn't bother to add a "ret". That's no surprise, "unreachable()" is basically an instruction to the compiler to stop generating code from that point on, and the compiler obeyed.

Before that the observable side-effect, device_command=42, has already happened. With time travel allowed, could also have been omitted, which would have been a real problem.

I misread the article to think that is was about the latter problem. You are right, my mistake. I didn't consider that anyone could see the former as a problem at all: It's just the compiler doing exactly what it's told to do.

The default for paragraph layout does suck indeed. But at least the font you should be able to customize.

The page does not set a text size. You are complaining about your own browser's defaults.

Skeuomorphism didn't fail. It feel out of fashion with designers.

We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.

But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.

I read the or's as giving alternatives, only one of which needs to work.

I can see how other interpretations are possible, but I don't see anything especially generous about mine. I'm not "allowing" anything: To make a judgement you have to pick a web browser to try it with, and you'd probably pick the most popular one, in the most popular configuration, that seems the most fair. If that web browser happens to execute Javascript when you navigate to an URL, then that's just how it is.

If the text was returned using a staged process, whereby the server first returns an instruction (JavaScript), and the web browser then executes that instruction, which is what transfers the text, then that doesn't actually change anything. Those are just technical details of the transfer. You are viewing an HTML document on-screen; it makes no difference to this bet if it was returned to you by a different mechanism than originally conceived, since the bet doesn't specify any transfer mechanism, just that the URL was entered into a browser.

I think you are absolutely right.

The big problem with the Turing test always was that it doesn't take into account adversarial designs. They had those chatbot contests about a decade ago, where the chatbots would regularly pass the turing test, not because the bots were intelligent, but because they were packed with rhetorical tricks designed to avoid saying anything of substance.

By any meaningful measure, today's LLM's pass the Turing test. Except we may need to lobotomize them for the deception to work.

Absolutely store the raw data. For the reasons you state.

But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text.

> how will you handle updates to the feed?

When polling, consider using HTTP HEAD to check for changes before GET.

What you do when an article ID reappears with different content, that up to you. I think readers usually replace the old entry with the new content, silently. But it's not the only option.

Perhaps you are talking about the ripgrep issue itself, which is fine. The others are talking about the linked analysis, which is not.

For a piece of software designed by reading the specs and implementing accordingly, there acid3 would be a good way of demonstrating the quality of the result.

But is that what happened? If you pass tests that conflict with the specs, then that implies that the implementation is not based on specs, but on feedback from the test. Which means it may be designed to pass the test, and not much good once you go outside the test examples.

I'll extend the benefit of the doubt and say that it's possible that the implementation is based on an older version of specs, one that matches the tests. But it doesn't inspire confidence that all we're shown is a single screenshot and no source code.

Invisible until moused over, or scrolled by other means. Barely visible even then. In the wrong place. It may be "just styled", but it's certainly not fine.

If ease of repair is what you care about, then yes.

But in absolute terms, sockets do make things more likely to fail. A socketed design means you have an assembly step where something is put into that socket. Probably manually. Cables and sockets can be tugged at and twisted. Dirt and moisture can get in between. Suppliers can use the wrong metal in connectors. Some errors will be caught by QC, which means that you never see them, but they still affect the manufacturer's bottom line.

Like bot403 said: "Just depends on what your priorities are."