I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.

  class Parent {};
  class Child extends Parent {};
  class Wrapper
  {
      Parent foo;
  }

  w = new Wrapper();
  w.foo = new Child();

  evaluate w.foo;
  // static type: Parent
  // dynamic type: Child

Many words came to mind when I saw this warning, but nothing really adds to the incredulity of this one word.

That does not appear to be what the court actually said, however.

And I 100% believe that all advertisements should require review by a documented human before posting, so that someone can be held accountable. In the absence of this it is perfectly acceptable to hold the entire organization liable.

The whole point of 3D printing is that the material is moldable when hot but rigid when it cools. And people really should be aware that engines get hot.

For your "quicksort of 4 elements" example, I would note that the algorithm doesn't care - it still works - and the choice of when to switch to insertion sort is a mere matter of tuning thresholds.

Good compression algorithms effectively use the same storage for highly-redundant data (not limited to all zeros or even all the same single word, though all zeros can sometimes be a bit smaller), whether it's 1 kiloword or 1 gigaword (there might be a couple bytes difference since they need to specify a longer variable-size integer).

And this does not require giving up on random-access if you care about that - you can just separately include an "extent table" (works for large regular repeats - you will have to detect this anyway for other compression strategies, which normally give up on random-access), or (for small repeats only) use strides, or ...

For reference, BTRFS uses 128KiB chunks for its compression to support mmap and seeking. Of course, the caller should make sure to keep decompressed chunks in cache.

What integer patterns does it do well on, and what patterns does it do poorly on?

How many strategies does it support? It only mentions delta which is not compression. Huffman, RLE, variable-length encoding ...

Does it really just "give up" at C/1024 compression if your input is a gigabyte of zeros?

There are perhaps only 3 numbers: 0, 1, and lots. A fair argument might be made that 2 also exists, but for anything higher, you need to think about your abstraction.

For cases where -O2 is too slow to compile, dropping a single nasty TU down to -O1 is often beneficial. -O0 is usually not useful - while faster for tiny TUs, -O1 is still pretty fast for them, and for anything larger, the increased binary size bloat of -O0 is likely to kill your link time compared to -O1's slimness.

Also debuggability matters. GCC's `-O2` is quite debuggable once you learn how to work past the possibility of hitting an (going up a frame or dereferencing a casted register is often all you need); this is unlike Clang, which every time I check still gives up entirely.

The real argument is -O1 vs -O2 (since -O1 is a major improvement over -O0 and -O3 is a negligible improvement over -O2) ... I suppose originally I defaulted to -O2 because that's what's generally used by distributions, which compile rarely but run the code often. This differs from development ... but does mean you're staying on the best-tested path (hitting an ICE is pretty common as it is); also, defaulting to -O2 means you know when one of your TUs hits the nasty slowness.

While mostly obsolete now, I have also heard of cases where 32-bit x86 inline asm has difficulty fulfilling constraints under register pressure at low optimization levels.

And programs full of pointer-chasing are quite pessimized; highly-OO code is a common example, which includes almost all GUIs, even in C++.

Blowing the dust out does run into the problem of some laptops being designed to only open with use of a chainsaw. I've ruined a couple laptops that way.

There are so many React websites where I see weird update bugs (e.g. updates for some parts of the page delayed by 3 seconds [not blocking render, the rest of the page is updating], or total wipe of something instead of incremental upgrades - weren't these the very problems React was supposed to solve?).

Mere excessive bloatedness I don't blame React for; all sorts of web dev fails at that.

===

The main question I have for Remix is: does the explicit `.update` trigger immediately, or does it wait so it can coalesce multiple updates?