I do information security for a living. [...]

So do I.

Pulling off an effective MITM assumes that the ends aren't doing effective mutual validation. Now, that's true much, much more often than it should be, but jumping from "most people do X badly" to "Y's effort to implement X is doomed to failure" isn't exactly a reasonable position when X doesn't violate any theoretical constraints (as so many attempted products do -- "X must have a key to decrypt Y, but must not be able to copy Y", etc).

...and you need to keep control of that vehicle for a few weeks to get it into a friendly port for unloading, during which time (1) folks with guns are doing their best to find you, and (2) you have no hostages to use as bargaining chips if they do so.

That's an awfully high-risk venture to get the kind of talent you'd need to hijack control in the first place [stealing private keys used to encrypt/authenticate the control chanel, etc] to sign off on.

FTFY. No need for subtlety.

Or accuracy, apparently. That story was debunked.

even worse then. you must be paying for the automation with speed.

"Must"?

If you pay attention, you might notice that the languages in question have strong metaprogramming support (and one of them has native immutable data structures with structural-sharing updates and typical log32n performance, and transactional memory baked in deep).

The metaprogramming support means that there's lots of room to do compile-time analysis and optimization, and the native transactional memory support means that the cell abstractions aren't doing much that the language's designers haven't already put a lot of effort into making fast.

Sure, there's performance overhead -- but it's overhead that's built to parallelize well. Whereas traditional locking can deadlock, Clojure ensures that there's always useful work going on somewhere -- the worst case you get into is that other threads' work needs to be thrown away on conflict. That's a model that scales a lot better to the highly parallel hardware of a decade from now than the conventional approaches today.

That's why "subsidized" is a relevant thing. :)

No; they support only their own hardware (Moto X w/ custom firmware).

On the other hand, it's a no-contract subsidized current-gen phone, and it's the first device I've had where manufacturer firmware is actually an improvement on AOSP.

I switched over from T-Mo. Republic's implementation is considerably better, particularly the handoff support.

If I could get reliable cell coverage in my home, I'd pay $200-300 for that.

Switch to Republic, and your voice, SMS and MMS all run over your WiFi, and hand off to Sprint's cell network when out-of-range.

Which gives you reliable coverage in your home, and a deep discount from a typical carrier's monthly rates.

-- Satisfied customer. (Well, moderately satisfied -- Sprint's 4G coverage in Austin was iffy until they got a bunch of tower repairs done; that they let it go for such a long time didn't speak well).

RIght. but now you are deleting most of the appeal of reactive programming by having to go back to explicitly managing dependencies.

I do? I didn't notice myself explicitly managing dependencies when using Trellis or Hoplon.

Well. I really shouldn't be letting myself getting sucked into this, but.

A world in which freedom of contract is unhindered is a world in which Shelley v. Kramer would have been differently decided. I prefer not to live in that world.

You can't assure when, where and how variables might be changing in some outer reaches of your program while another part of the program is assuming they are momentarily fixed.

Huh? All the reactive programming frameworks I've used (Python's Trellis, various cell-model approaches in Clojure) have transactional memory, so things never appear to be happening in parallel.

Reactive programming without transactional memory is Doing It Wrong.

A world in which not all promises are enforceable is not a world without enforceable promises.

Neither history or the world we live in presently has any shortage of examples of power or information imbalances resulting in individuals being unable, on a large scale, to effectively represent their own best interests.

But then -- we're continuing a conversation I expect we both know will be ultimately unproductive. Surely we can find a better use of our time. :)

I care more about equitable outcomes than about freedom of contract. As such, I do not expect our positions to be reconcilable.

Before continuing this discussion, allow me one question, which I believe should adequately establish whether we have any reasonable chance of being able to reach an agreement on principals, even should we come to agree on facts.

Do you consider it appropriate for a risk pool to contain individuals with varying levels of inherent risk? Consider, for instance, the common case of a risk pool consisting of the set of employees participating in a large enterprise's health plan. Is it appropriate for individuals who are at an inherently high personal risk (on account of genetic predisposition, disability, medical history, or known or predictable factors) to be subsidized by those who are not, or should the pool be stratified into bands by inherent risk level, and thus serving only its traditional role of spreading the costs of unpredictable (and, hopefully, non-clustering) events?

As the person who's building large-scale automation that uses SSH as its backing transport, anything that requires escalation to something that isn't SSH might as well be hands-and-eyes -- it's something my tools can't touch, and if the tools can't touch it, it might as well not exist.

See again, "too large a scale for issue remediation to depend on human involvement".