Leszek

It means they'd avoid an article on the benefits of smoking if it's posted by a company selling cigarettes.

The dummies phrasing is my own, and I stand by it - I simply find the CFG way of thinking much easier to reason about than the SoN way, and I find myself falling back into it no matter how hard I try to follow what I totally (abstractly) appreciate is a more mathematically beautiful dependency/anti-dependency graph - I think that's a limitation of my ability to maintain that concept in my mind and that other people can do it better than me. I find it far easier to reason on CFG terms most of the time, and to raise the CFG temporarily into some dependency representation for doing eliminations/hoisting/LICM, than I do maintaining that dependency representation across all phases and accurately reasoning in each of those about what concrete dependency I forgot about when writing the reduction (concrete recent example, I tried to make reading from holes segfault by unmapping the hole, to force potential holey field access to always first compare against the sentinel, but I was foiled by TF since the load had no dependency on the hole compare branch and could be hosted above it). Implying that this was simply "some people" insisting on only thinking one way without trying to think the SoN way, or that it was some sort of CFG prejudice, is the actual strawman here.

(disclaimer: current V8 team member replying to senior ex-V8 team member)

I'd say there were a lot more things problematic in practice with SoN than not relaxing effect edges enough - I'd argue that the bigger problem was that a single effect chain was not enough to represent the flexibility that SoN promised, while keeping the costs, and getting that flexibility would mean effectively extending the effect chain to one effect colour per object per field. Maybe this was a JS specific idiosyncrasy, but my experience was that the effect chain became almost homomorphic to the control chain (and when it wasn't, we had bugs), and then you may as well merge the two into a CFG - if you have to skip over links in your effect chain to skip over certain kinds of effect then you can equally well skip over zero effect nodes too. With SoN, we got all the costs and (almost none) of the benefits, hoisting really isn't so difficult that you have to design your whole IR around it.

As for IR design and TFs good architectural decision, idk, I don't think it's all that different from what we ended up with in maglev. All those classes are just convenience views onto a consistent node layout (with e.g. the same trick as TF of putting inputs behind the node), and so far we haven't had issues with it - time will tell I suppose.

Overall, this narrative that TF, with it's SoN and other serial decisions, was super clever and built by very smart senior engineers that just all moved on and left behind just us dummies that don't get it -- I've honestly never argued against it. Hell, I can even agree with it, same as I totally believe Cliff when he says that he could easily solve every problem we struggled with (likely by doing it in the scheduler). Tony Stark built one in a cave with a bunch of scraps, but unfortunately I'm not Tony Stark, and we've ended up choosing human comprehension (instead of superhuman) as a design constraint so that us dummies can still work on it after all the senior engineers got promoted away or bored. I think this is a good decision and I stand by it.

Be careful to check whether you're in a glass house before throwing stones - "layoff" used to mean a temporary release from employment for seasonal labour before it meant a permanent one (https://www.etymonline.com/word/layoff). "Standard" as an adjective also used to mean "being held to a standard of excellence" rather than "normal" or "average". It's ok for words to change meaning over time.

You can't currently "compile JS to Wasm", you can compile a JS engine (likely written in C++) to Wasm and run JS inside that (almost certainly at lower speed). So instead of "no more V8", it's closer to "ship V8 as part of the website, instead of part of the browser". Exposing DOM APIs to Wasm is a completely different question, though even those would actually have to be new APIs with a new API design that works for Wasm, since the existing DOM APIs are effectively defined in terms of JS objects being passed around.

The complex parts of JavaScript are the semantics, not the syntax. You could reasonably easily spec a bytecode for JS to get rid of the syntax part, but nothing would change in the complexity (almost all modern engines parse to bytecode as the first step and operate on bytecode from then on).

If you wanted to implement JS in wasm, you'd either need a bunch of wasm extensions for JS semantics (dynamic object shape, prototypal inheritance, etc), or you'd need to implement them in wasm from scratch and basically ship a JS runtime written in wasm. Either that, or you need to change the language, which means de facto adding a new language since the old JS still has to stick around for old pages.

I guess in this system, you'd also type lowercase letters by holding shift?

rr (https://rr-project.org/) and memory watchpoints are a godsend when it comes to analysing heap corruptions.

The signed length fields pre-date the sandbox, and at that point being able to corrupt the string length meant you already had an OOB write primitive and didn't need to get one via strings. The sandbox is the new weird thing, where now these in-sandbox corruptions can sometimes be promoted into out-of-sandbox corruptions if code on the boundary doesn't handle these sorts of edge cases.

I said it "protects" against bugs, not that it "removes" them. The Truffle architecture removes mismatches between JIT and interpreted code (when it doesn't have bugs itself, which is not guaranteed either), but it doesn't remove runtime or object model logic errors that affect both.

The V8 sandbox doesn't just protect against JIT issues, it also protects against logical issues in the runtime and object model.

Ok, person with anonymous account name.

It certainly disproves that it's a pattern without exceptions, and therefore invalidates or at least questions the idea that every instance of up and down (like which way up north is) has to be mapped to good and bad.

More likely in feet than metres.

Are you down for looking for counterexamples? Do you want to get to the bottom of why people cherry pick examples for their argument? Is this what you want to base your argument on, or should it be grounded in a more complete linguistic analysis?

The Dual-Kawase blur sounds like a texture-sampling-efficient variant of building a Gaussian pyramid (https://en.wikipedia.org/wiki/Pyramid_(image_processing))?

"The data presented in this article is sourced from the United Nations International Migration Stock for the year 2020."

It's not - the general path is a bailout for the fast path which continues where the fast path stopped, so you don't have to check the whole object for fastness (and you get the fast path up until the bailout)

What can't though?

Fast code isn't a quantum effect, it doesn't wait for a measurement to wave collapse into being fast. The _assertion_ that a certain piece of code is fast probably requires a measurement (maybe you can get away with reasoning, e.g. algorithmic complexity or counting instructions; each have their flaws but so does measurement).

I once destroyed an entire small enemy camp in a 5e campaign by causing an avalanche using Create Water -- arguing that the 10 gallons of water I create would be a whole lot of snow when taking into account the relative density of water and snow. Definitely a Rule of Cool moment, I don't think the spell wording is even that amenable to this interpretation.

And yet here you are saying it.

Something I find fascinating is that we know that P != EXPTIME, and that P <= NP <= EXPTIME, but have managed to prove neither P != NP nor NP != EXPTIME. NP has to be somewhere between them but we have no idea where.

The eval thing is listed as a potential performance cost, but it's actually super important for performance, because it allows the parser to statically know that sloppy eval is never called inside a function, and that variables can therefore be optimized away.

FWIW, I think the parent meant "function scoping vs lexical scoping" rather than "block scoping vs lexical scoping". You're correct that function scoping is technically a form of lexical scoping (where the scope is the function), but if you want to be _really_ pedantic, the ecma262 considers let/const to be "lexical binding"[0] as opposed to var being a "variable declaration"[1], where the former declares in the "Lexical Environment" while the latter declares in the "Variable Environment". These happen to be the same environment record on function entry.

[0] https://tc39.es/ecma262/#sec-let-and-const-declarations [1] https://tc39.es/ecma262/#sec-variable-statement

You're missing the "four" part of "four 2s"

Or JIT compilers, where compilation time is an important factor -- e.g. V8 uses variations on linear scan.

Related is the raven paradox (https://en.wikipedia.org/wiki/Raven_paradox), where for the statement "All of my hats are green", seeing _anything_ non-green that is not one of my hats is evidence in favour of the overall statement.

Agreed, NuN tagging is an awesome use of the NaN space, and it has the same benefits of being a no-op for pointers. I would only consider this for cases where NuN tagging is impossible, e.g. some system that needs more pointer bits than NuN tagging allows.

I'd add that the claim that this could be implemented in V8 doesn't take into account pointer compression, where on-heap V8 tagged pointers are 32-bit, not 64-bit.

Because Unicode 1.0 had already defined characters both at the start and end of the 16-bit range (https://www.unicode.org/versions/Unicode1.0.0/CodeCharts1.pd...), and UCS-2/UTF-16 had to be compatible with that.