o11c

The hope for semantic HTML died the day they said "stop using <i>, use <em>", regardless of what the actual purpose of the italics was (it's usually not emphasis).

I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.

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.

Any statically-typed language has this. In pseudo-Java:

  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

... really?

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

Hmm, the is `type` the static type or the dynamic type, for languages where both apply?

The author of the article is claiming it extends beyond ads.

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.

At a glance, that looks like worse than merely the negligence of using a new technology.

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.

Related: doctors will refuse to test you to see if what you're suffering from is a particular condition unless that condition actually has a known treatment.

Those are not unrelated. Both from my family and from looking at the research, there's a strong correlation between long/difficult births (sometimes explicitly hypoxia) and autism.

There's a reason I prefer "lots" over "infinity".

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.

For the "all zeros" case, my concern is that you said you're forcing a reset every 1024 words. This implies that if you have N kilowords of zero data, then it takes N times as much space as a single kiloword of data.

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.

This is missing a lot of context.

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?

Better option: just wrap it in a unique struct.

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.

Compiler speed matters. I will confess to not as much practical knowledge of -O3, but -O2 is usually reasonable fast to compile.

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 <optimized out> (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.