TL;DR: modelling the stock market incorrectly with a normal distribution leads to the conclusion that the current circumstances arise once every 43 thousand years.
Is there an unstated connection to computational complexity here? The article focuses on the number of possibilities and basically argues that N is impractically large, but I think that means there's an implicit claim behind that that we don't have an efficient search algorithm so the large N is fatal rather than a hardware problem. Does that make sense to anyone else?
I think trust is important, yes. Self awareness is, too—sometimes it's enough for the gatekeeper to stop and ask themselves if they've checked their biases. Another tool is for the metagatekeeper to periodically review the gatekeeper's decisions; the metagatekeeper can be the next level up of management, or it could be a set of peers who check each other.
However you do it, it's a matter of "who watches the watchers?"
A compelling post. Something it doesn't mention that I immediately wonder about is how you ensure the decision to escalate from "a quick DM" to a "full business case review" (or whatever) isn't unreasonably biased.
If everyone is working with good intent then this doesn't matter. But the real world is full of unconscious 'isms so I suspect there's a risk that underrepresented folks are more likely to trip the extra process flag and thereby get slowed down disproportionately, leading to negative feedback loops.
I didn't know Gor very well, but I had the pleasure of interacting with him at a handful of WG21 meetings. Upon first meeting him, I was overawed by the chance to meet such a luminary in the C++ world, but he instantly put me at ease once we started talking. He flattered me by saying that he and his team were really happy with Unifex, and he helped make my first C++ proposal a success by both offering feedback that made the paper better and then advocating for it in LEWG meetings. Every interaction I had with him was a pleasure. I'm sad he's gone.
I'm working on a proposal for C++29 to extend `std::execution` by introducing a type-erased sender (P4223 https://wg21.link/p4223).
I discovered this week, while the paper was being reviewed by SG1, that I've accidentally stumbled into tackling a rather important problem. Senders as shipped in C++26 can really only express the async equivalent of inline functions because, except for `task`, all the standard senders fully encode the shape of their computation in their type. With something like the `function` I'm proposing, you can use senders to express async algorithms that are separately compiled, just like sync functions.
If the feature lands in a shape similar to what I've proposed in P4223R0, then I think an obvious extension is to modify the core language to support a newer kind of "coroutine" that allows you to define a sender with imperative code. My vision here is that we act on the observation that `std::execution` is a language feature implemented in the library by teaching the compiler how to turn imperative C++ with `co_await`s sprinkled through it into the corresponding sender and operation state. I think this would open the door to putting async object lifetime analysis and optimization where it belongs (in the compiler) without the overheads and inconveniences of C++20 coroutines. It would even let us apply the inliner to async functions when the compiler can see the body of an async callee, not just its declaration.
For now, my next step is to write P4223R1 to incorporate feedback from this past week's WG21 meeting, and continue exploring the design space around specifying sender attributes for a `function`—I'm thinking the current approach of specifying query function signatures needs to be replaced with a key-value object like receiver environments, but I'm not sure yet what consequences that change would have on the design.
TL;DR: modelling the stock market incorrectly with a normal distribution leads to the conclusion that the current circumstances arise once every 43 thousand years.