C23 also has the "no time travel" stipulation. I expect C23 should be immune to the example 1 program issue, because of that. A quick trial on godbolt (https://godbolt.org/z/8K81PYoYE) seems to agree, with the caveat that I didn't work out the right compiler options to show for sure.
C++26, IIRC, adds "no time travel" to C++. But note that your example still creates exploding chocolate, so what do you mean by "immune"? C compiler with -std=c23 -O1 produces literally the exact same assembly output.
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.
> That's no surprise, "unreachable()" is basically an instruction to the compiler to stop generating code from that point on, and the compiler obeyed.
It's not a command to compiler to stop generating code.
It's a permission slip that allows the compiler to assume that code that follows is dead code, eligible to be optimized out, including eliminating potentially dead stores and loads.
Which is to say, it's precisely what any other UB is, which is why deliberate use of UB is very bad idea.
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 I would also prefer a warning, or at least a guarding trap instruction. And maybe compilers should try harder to be friendly in this way.
But they can't be perfect, because the program specified something syntactically valid, but semantically invalid. The module/compiler pass that could theoretically detect it may simply not be issued the necessary information. E.g. a solver may be given the input that a value is in a given range, and from that simplify an operation. If the input is wrong, so is the output.
Reminds me of:
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
In the example from the article, though, there could be a pass that simply eliminated dead code. That pass is not a parser of the raw code, so how is it to know that actually, the "dead code" isn't?
And a standard that would require dead code elimination to replace not with empty, but with a trap instruction, could go very wrong. You don't want `if (false) { … }` to become `if (false) { trap(); }`. You want it just removed, if a previous pass deemed it dead. Or do you want `int main() { for(;;) {cli_loop();} }` to force adding a trap in the unreachable code after the loop? That's a lot of generated trap instructions.
So in general this means solving the halting problem. Yes, specifically in the post's example, "surely a sufficiently smart compiler could detect something this obvious". Maybe so, but how often is the bug actually this obvious?
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.
> 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.
Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D
It’s funny. The only people that regularly, seriously discuss skeuomorphism in software design are software developers. It was a big conversational topic among designers around the time Apple ditched the faux leather padding at the top of the calendar app. Developers started talking about it, I believe, because it’s an unusually concrete topic among typically abstract, nebulous, or artsy design conversations. Since then, there have been a zillion other big topics in the design world, and it’s largely considered a conceptual facet of design that’s just not very important. But developers, decades later, still discuss skeuomorphism in design like it’s one of the great important topics of the field. It’s not.
It would be like if smashing magazine put out an article in 2015 about everybody moving to a “microservices architecture” and then any time any kind of software development came up in a design forum, someone would awkwardly shoehorn the discussion into a framework of microservices vs monolithic applications. (Even better, when a developer would come along and try to give a more nuanced perspective, the designers would see themselves as the authority in the conversation because all the other designers around agreed with them.)
If you really want to dig into the nerdy conceptual side of icon design, triadic semiotics is the far more interesting rabbit hole to fall down.
This is exactly how our letters came about - 'A' originally was written sideways and represented an ox head, but now everybody just knows it as a letter.
I've seen an SD card icon used for a save icon before. I think conveniently the shape is similar enough to a floppy that you find it while scanning for it as well
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 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.
Even if you interpreted the bet generously to allow for a browser to render the content using JavaScript, if I understand the bet correctly, the condition of working with a command-line tool like curl would fail.
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.
It says that the browser must download "an HTML document that still contains the following text". I can see how either interpretation could work, but I would interpret "contains" as "the text is in the HTML document", not "rendering the HTML document in a JavaScript-capable browser displays the text".
(Though, that said, some approaches to rendering sites via JavaScript would still have that text in the initially downloaded HTML file as JavaScript data.)
As for the "or", I read it as "doing either X or Y must", not "either X must or Y must (not necessarily both)", but yeah, I can see either interpretation being valid.
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.
- if you split the rss document into its "items" i am not sure if you can store each item separately inside postgres using that XML data type
- if you store the whole document, you end up with a problem when say the feed partially updates after a few minutes
- one suggestion i hear from r/PostgreSQL is that you store the XML blob somewhere else like hstore or something and somehow index it back to postgres. I wonder how that works conceptually / architecturally speaking
The data is probably small enough and infrequently updated such that almost anything will work. If you split the items then you would have a separate episodes table with one row per episode joined to the podcasts table. If you store the whole XML in a row then you can overwrite the row when the feed changes. Doing the parsing and splitting into episodes in DB sounds better to me because your clients will otherwise constantly be repeating that work.
I would say that's a very sugarcoated version of the Monster energy drink ingredients list[1]. The real list is ten time longer than the ingredients list of a cup of black filter coffee. And one of the items is "natural flavors", which could be hiding a long list of things all by itself.
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.
