I have found that a hybrid viewport screenshot + textual 'semantic snapshot' approach leads to the best outcomes, though sometimes text-only can be fine if the underlying page is not made of a complete mess of frameworks that would otherwise confuse normal click handlers, etc.
I think using a logical diff to do pass/fail checking is clever, though I wonder if there are failure modes there that may confuse things, such as verifying highly dynamic webpages that change their content even without active user interactions.
Totally agree - hybrid approaches can work well, especially on messy pages. We’ve seen the same tradeoff.
On the verification side though, dynamic pages are exactly the reason why we scope assertions narrowly (specific predicates, bounded retries using eventually() function) instead of diffing the whole page. If the expected condition can’t be proven within that window, we fail fast rather than guessing.
How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.
We need to agree to disagree on this one; the claim that C is fine and does not cause harm due to its multitude of foot-guns, I think, is an egregious and false claim. So don't make false claims and don't post toxic positivity, I guess?
A budget that is influenced by the budgets of everything else. If you have $100 in free 'foo' money for 'foo' efforts, suddenly you do not need to fund 'foo' from your general fund and you can move those dollars you would have otherwise used for it to instead be used for anything else you want.
Wouldn't faster boot times mean that scale-out can be done on-demand? Whether this is preferable or not over poorer runtime performance is up to the domain, no?
When scaling out, edge latency will overshadow kernel boot-up times: speeding up boot-up from 1.5s to 150ms will not have any perceived impact on app performance when scaling on edge to meet the demand.
This logic does not follow from or to "That's 100 times more than I thought." You can be both horrified at something and also understand that it is thing that happens.
And the way English generally uses the Roman alphabet (obviously excluding the zillions of irregularities) isn't that far off from how most European languages use the Roman alphabet.
I'd expect that Spanish, German and French speakers would benefit just as much as English speakers from these changes.
> And the way English generally uses the Roman alphabet (obviously excluding the zillions of irregularities) isn't that far off from how most European languages use the Roman alphabet.
Its not far off from the union of how all other European languages use the Roman alphabet, would be closer to accurate.
Sure, but the point is this isn't really making romanized Japanese more English-like. It's making it more similar to how just about every other language already uses the Roman alphabet. This isn't an Anglo-centric thing, it's just good common sense - unless your goal is to make it harder to pronounce your language properly, which seems like an obvious own-goal.
About 30% of people worldwide use a language that's not written in Roman alphabet.
Additionally, being written in Roman alphabet doesn't neccessarily mean it's clear how to pronounce it. Hungarians calls their country "Magyarország", but unless you know Hungarian, you will be surprised with how it's pronounced. Same as "Chenonceaux", "Tekirdağ" or "Crkvina".
Those are especially pathological cases, and not especially relevant to this discussion, as the romanization rules are explicitly designed to be consistent.
We're not talking about words like worcestershire. I'm talking about words like "bat" "monkey" "chimichanga". Those that follow the rules. There can't possibly be irregular spellings using the romanizations we're talking about!
> It's making it more similar to how just about every other language already uses the Roman alphabet.
There is no way "every other language already uses the Roman alphabet."
Many languages are internally consistent in how they use it, but those that are aren't consistent with each other. And then there is English, which does pretty much everything any other language which uses the Roman alphabet does somewhere, and probably a few that none of the other extant languages normally using that alphabet do with it, on top.
I think using a logical diff to do pass/fail checking is clever, though I wonder if there are failure modes there that may confuse things, such as verifying highly dynamic webpages that change their content even without active user interactions.
reply