To everyone either 1) comparing it to some sci-fi text or 2) saying it is unparsable: It is no accident. This is written like a religious text.
I am not kidding. It might have came out like this by accident, but i could spend days mapping the semiotics of this to, say, scientology "books".
The most blatant technique there is the slightly out of place technical terms and insertion of sci-fi elements. Here is a paper on christian texts and the use of metaphor on the willingness of the audience http://cogprints.org/4863/1/Cognitive_Semiotics_and_On-Line_...
Before readers run out and try this, there is a technique and protocol that should be followed, or you won't like the consequences. I'll let a post on /r/natureismetal do the typing for me [1], and here's a copy-pasta for those who don't want to click through (more scientific explanation [2] of why this works within seconds...to make sure around these bastards from hell, I gave 'em two minutes to display proof of death---put a stick in the drowned mass and lift it up---before I moved on to hunting down the next raft):
-------- clip here --------
You're all going to love this. It's environmentally friendly, it's inexpensive, it's 100% lethal, and makes them die in the most horrible manner possible.
Dish soap.
Put a tablespoon or two into a spray bottle, then add about 2-3 cups of water. Swish the water to mix. Do not shake! You don't want foam in the bottle.
MOVE. UP. STREAM. Seriously, you don't want to be downstream of this when it happens.
Now, starting in the middle of the mass, start spritzing with the soapy water, and work your way out to the edges.
The soap will break the surface tension, and act as a wetting agent on the ants. As a result, the water will now start wicking up their bodies, enveloping them like living quicksand. And with the surface tension broken, the mass of ants will start to sink.
Remember, start in the middle! This will cause the center to sink first, and drag the edges down last. The ants will all hold on to each other and drag every last one below the surface. With a soft bloop, the entire mass will drop.
Remember how I said to move upstream? If you're downstream, the entire submerged mass could end up wrapped around your legs. Where they will immediately begin clawing their way to the surface, using you as a ladder.
Best of all, you can scale up your operation, and load a backpack sprayer with a bottle of Dawn and a few gallons of water. Then just wade through your neighborhood, wiping them out for the benefit of everyone!
cwmma gets a lot right here: Promises have always been contentious in JS (and TC39) and Domenic has indeed had the patience of a saint attempting to wrangle the various points of view into a coherent proposal.
TC39 as a group is generally very motivated to find positive-sum outcomes and find solutions that address everyone's constraints in a satisfactory way. That doesn't usually mean design-by-committee: champions work on a coherent design that they feel hangs together, and the committee provides feedback on constraints, not solutions.
As a member of TC39, I'm usually representing ergonomic concerns and the small-company JavaScript developer perspective. I've had a lot of luck, over the years, in giving champions my perspective and letting them come back with an improved proposal.
The staging process (which I started sketching out on my blog[1]) has made the back-and-forth easier, which each stage representing further consensus that the constraints of individual members have been incorporated.
Unfortunately, I fear that promise cancellation may be a rare design problem with some zero-sum questions.
It's worth noting that there has been no objection, on the committee, to adding cancellation to the spec in some form.
The key questions have been:
First. Is cancellation a normal rejection (a regular exception, like from `throw`) or a new kind of abrupt completion (which `finally` would see but not `catch`). The current status quo on the committee, I believe, is that multiple people would have liked to see "third-state" (as Domenic called it) work, but the compatibility issues with it appear fatal.
Second. Should promises themselves be cancelled (`promise.cancel()`) or should there be some kind of capability token threaded through promises.
What that would look like:
let [sendCancel, recvCancel] = CancelToken.pair();
fetchPerson(person.id, recvCancel);
async function fetchPerson(id, token) {
// assume fetch is retrofitted with cancel token support
let person = await fetch(`/users/${id}`, { token });
}
// when the cancel button is clicked, cancel the fetch
cancelButton.onclick = sendCancel;
This approach had many supporters in the committee, largely because a number of committee members have rejected the idea of `promise.cancel()` (in part because of ideological reasons about giving promise consumers the power to affect other promise consumers, in part because of a problem[2] Domenic raised early about the timing of cancellation, and in part because C# uses cancel tokens[3]).
In practice, this would mean that intermediate async functions would need to thread through cancel tokens, which is something that bothered me a lot.
For example, it would have this affect on Ember, if we wanted to adopt cancel tokens:
In other words, any async hook (or callback) would need to manually thread tokens through. In Ember, we'd like to be able to cancel async tasks that were initiated for a previous screen or for a part of the screen that the user has navigated away from.
In this case, if the user forgot to take the cancel token (which would likely happen all the time in practice), we would simply have no way to cancel the ongoing async.
We noticed this problem when designing ember-concurrency[4] (by the venerable Alex Matchneer), and chose to use generators instead, which are more flexible than async functions, and can be cancelled from the outside.
At last week's Ember Face to Face, we discussed this problem, and decided that the ergonomic problems with using cancel tokens in hooks were sufficiently bad that we are unlikely to use async functions for Ember hooks if cancellation requires manually propagating cancel tokens. Instead, we'd do this:
The `*` is a little more cryptic, but it's actually shorter than `async`, and doesn't require people to thread cancel token through APIs.
Also notable: because JavaScript doesn't have overloading (unlike C#), it is difficult to establish a convention for where to put the cancel token ("last parameter", vs. "the name `token` in the last parameter as an options bag" vs. "first parameter"). Because cancellation needs to be retrofitted onto a number of existing promise-producing APIs, no one solution works. This makes creating general purpose libraries that work with "promise-producing functions that can be cancelled" almost impossible.
The last bit (since I started talking about Ember) is my personal opinion on cancel tokens. On the flip side, a number of people on the committee have a very strongly held belief that cancel tokens are the only way to avoid leaking powerful capabilities to promise consumers.
A third option, making a new Task subclass of Promise that would have added cancellation capabilities, was rejected early on the grounds that it would bifurcate the ecosystem and just mean that everyone had to use Task instead of Promise. I personally think we rejected that option too early. It may be the case that Task is the right general-purpose answer, but people with concerns about leaking capabilities to multiple consumers should cast their Tasks to Promises before passing them around.
As I said, I think this may be a (very, very) rare case where a positive-sum outcome is impossible, and where we need, as a committee, to discuss what options are available that would minimize the costs of making a particular decision. Unfortunately, we're not there yet.
Domenic has done a great job herding the perspective cats here, and I found his presentations on this topic always enlightening. I hope the committee can be honest enough about the competing goals in the problem of cancellation so that Domenic will feel comfortable participating again on this topic.
I am not kidding. It might have came out like this by accident, but i could spend days mapping the semiotics of this to, say, scientology "books".
The most blatant technique there is the slightly out of place technical terms and insertion of sci-fi elements. Here is a paper on christian texts and the use of metaphor on the willingness of the audience http://cogprints.org/4863/1/Cognitive_Semiotics_and_On-Line_...