Cushman

Maybe it's just me -- and I never met the man -- but I've never had someone convince me they understood what it's like to be terminally depressed as completely as the writing of DFW. It boggles my mind that someone could miss or misbelieve that.

The way that "This is Water" speech/pamphlet is brought up in particular horrifies me. Hindsight granted, it's always read to me as someone who, stuck in a deep, dark hole for so long, has given up on finding a way out. Blaming himself for being there in the first place. Standing so close to an answer, but unable to see it. And we know how the story ends.

It's a feeling I know well, and I'm routinely shocked how people without (I assume) first-hand experience with depression can completely ignore the darkness there, and see something banal or even encouraging.

All of what you're saying is true, about the speed of real algorithms running on real hardware with real problem sizes.

But if you're talking about big-O, you are explicitly not talking about that. You're talking about how the speed of the algorithm hypothetically scales as some parameter tends to infinity.

To wit, O(n) doesn't mean "this algorithm takes kn time to run for a given n", it means "this algorithm's runtime for all n > c for is bounded above by nk for some c and k".

Sound like a analytic club that's rarely accurate to real-world performance? Yup, that's big-O :)

Or maybe, since O(1) is in O(log n), you can cover your bases by just calling everything logarithmic regardless :)

That example may have misfired-- perhaps consider that sorting an array of n elements requires addressing n elements, which requires arithmetic on words of log n bits, which are therefore log time operations. Limiting the size of each element won't help your complexity.

But we really don't care about that very much. In this case.

It's kind of described in that SO post I linked-- you can assume a constant-time hashing operation, but if that offends your conscience, assume an "integer RAM" model where arithmetic operations up to a certain word size w are constant time. Then you can observe that any reasonable w is inconsequential to your problem domain, and go back to treating hashing as a constant-time operation :)

The idea is that the fact that w increases at least as the log of n is shared by all computations modeled in integer RAM, so it's not a useful contribution to analysis at that scale. It's in the model, it's just not generally useful to the model. If you ever find yourself asking, is the bit width relevant? You can do some math and get a straight answer.

Of course real world algorithms often hash strings which complicates the analysis, but that's orthogonal, like my misstep earlier in implying the size of an element rather than the size of n. The mathematical sense in which hashing time must increase with the log of n is a fact of all algorithms that have ns.

I think your surprise at this just stems from wanting a rigorous definition for something that's more of a modeling tool, with different models to choose from. In real life, there's the time on the wall since you clicked "Run", and everything else is theorygramming.

Just speaking for myself, it seemed like a pretty good-natured mix of thoughtful musing on the nature of universal computation, and gentle mockery of the idea that universal computation means there's one right answer for anything. I'd be surprised if it's meant to skewer any one viewpoint in particular.

This is mostly an issue with terms. Most (all?) of the operations we call constant-time, say, comparison, are technically logarithmic in the number of bits on real computers.

Since that's usually not relevant to big-O analysis, we can sidestep the issue by specifying what we're counting: rather than say that mergesort is in O((log n) log (log n)) time, we say it takes O(n log n) comparisons.

Whether you think of that as a theoretical computer with a constant-time comparison instruction or as a real computer with a commonsense (2^64) upper bound, the upshot is that we don't care. As long as what we're studying is sorting, not comparison, it will fall out of every algorithm, so the difference isn't important even in theory.

It's still an important thing to notice, though-- there are plenty of cases where you definitely do care about counting bits.

In more detail: http://cs.stackexchange.com/questions/1643/how-can-we-assume...

You don't need a license to write code for a hair-cutting robot either, but I'll bet you want one before you put it on somebody's head.

This is a perfect example of the kind of humor that belongs on HN. Actually had me nodding along in parts, then screwing up my face at others. By the time I was sure it was satire, I was committed enough to see it through to the end.

Best of all, I expect sincere discussion of the merits of the argument in this thread. Well executed, and heh heh.

In ES3 you'd need destructors, I think. But yes, agreed on all points :)

And yet-- is the Symbol approach not metaprogramming? It's clearly a much saner way to shoehorn this feature in, but it's still a shoehorn. And the underlying magic in both cases is in fact simple closure scope, which is really what I wanted to demonstrate.

Edit: And I guess my broader point, to make this more constructive, is that in JS these kinds of idioms live on a continuum of metaprogramming, and for the sanity of your co-contributors you usually want to be doing as little of that as necessary. Like others, I'm wary of presenting something like your example as a "design pattern" without that context.

Edit 2: To illustrate what I mean, I swear to you that if this pattern is adopted widely you will find code like this in the wild:

    ... = > {
    let accountNumberKey = Symbol('accountNumber');
    return class Account {
      constructor (accountNumber) {
          this[accountNumberKey] = accountNumber;
          this.accountNumberKey = accountNumberKey; // ??? but transaction log works now

    ...

Np! Mind it is technically possible to do, check out my sibling comment if you haven't already.

This isn't quite the same; the parent is pointing out that you can implement `sameFirstName` without exposing `firstName` publicly at all, not even as a getter.

Er, to be clear, your example uses a closure. Your real question is, can this be done without `Symbol`?

And it can, since the symbol is just a secret stored in a closure and there are other sorts of secrets. Aside from the "Math.random() + {enumerable: false}" suggestion found elsewhere, you can reproduce the precise[0] semantics of your example using something like:

    // Please do not actually write code like this
    var Person = (function() {
      var names = [];
      function Person(name) {
        this.key = names.length;
        names[this.key] = name;
      }
      Person.prototype.sameName = function(other) {
        return names[other.key] === names[this.key];
      };
      return Person;
    })();

Which is the ES3 generated by this CoffeeScript:

    class Person
      names = []
      constructor: (name)->
        @key = names.length
        names[@key] = name
      sameName: (other)->
        names[other.key] is names[@key]

Of course these implementations do something dramatically different behind the scenes, and I emphatically don't think people should follow this example, but the interface is the same. Edit: Except that I left `.key` as an editable property, which is problematic. We'll leave that bit as an exercise, though.

Whether `names[this.key]` is as "nice" to work with as `this[nameKey]` is, uh, left up to the reader; personally, count me in the camp that doing either of those things is nuttypants compared to `this._name`.

[0]: Assuming that `otherPerson` in your constructor is a typo, of course ;P

So then, you don't believe that harm reduction doesn't justify illegal activity, you just think what Silk Road specifically did doesn't qualify as "harm reduction"?

That's fine; I disagree, but I'm not interested in litigating it here. But your original parent actually was arguing along those lines, cf. "rat poison" et cetera, so perhaps you'd like to retroactively not reject that as "not a reasonable argument".

It really is.

If the law is hurting people, and breaking the law helps people, it's completely reasonable to use that argument to morally justify your illegal behavior. I'd be interested to hear your argument why it is not.

Edit: Though to be clear that wouldn't work to justify all your illegal behavior, if that included like hypothetically trying to have someone killed.

This comment defines the middlebrow dismissal.

Unless you live in a jurisdiction where the purchase of narcotics is legal (Mars?) the meaning of "People have a right to buy drugs" is quite clear.

In a world where the laws you invoke are responsible for so much suffering and death, to come in with a "Well, legally" and pretend the moral dimension does not exist is... well, I've already said what that is.

Sure, but there isn't much of a difference there. Again, in 2014 we knew we'd be looking at something like 2x1080p with 90hz vsync. Nobody would tell you you'd need something less than a high-end gaming PC to spit all those frames out.

Edit: The consumer confusion arose because Oculus released developer hardware with significantly lower requirements, and a lot of enthusiasts jumped on the bandwagon. But if you were developing for that hardware, you always knew it was insufficient for consumers, and that the release version would need a lot more muscle behind it.

Eh, I feel like we're just talking past each other at this point. Just to clarify exactly what my position is:

We posit that it makes sense to have a "backup": A physically isolated, self-sufficient ecosystem in which human civilization might continue independently. We can decide to put this backup in a distant gravity well, and call it a "colony". Or, we could decide to put it somewhere very, very safe on Earth, and maybe call it a "bunker".

My stance is that bunkers are universally preferable to colonies, at least for the foreseeable future of human technology: the bunker survives the same extinction events that the colony survives, and the inhabitants of the bunker have a better shot at rebuilding afterwards.

Reading between the lines, you seem to be supposing some event which destroys the bunker by definition. That would certainly suck for humanity, but it's answered by my most recent post: If there are human-extinction events the (Earth+)bunker wouldn't survive, there are dramatically more such events the (Earth+)colony wouldn't survive. So existentially, on the balance of probabilities, you are better served by building bunkers rather than colonies.

Mind you, I'm not saying there's no point in a colony; at some point, if you already have a dozen or a hundred bunkers, the marginal utility justifies the expense. And of course there are lots of reasons, both practical and sentimental, why we might want to go to Mars. It's just x-risk ain't a very good one.

> specs and requirements keep getting bumped

This is a (common) misperception based on hype. In fact, the release Rift hardware is more or less the Crescent Bay prototype they started demoing last September, and that was pretty close to Valve's "room demo" circa January of last year.

Oculus has been struggling with implementation problems and scaling, but the target spec for what counts as "consumer VR" hasn't changed much in years.

That sounds like a contradiction in terms. How does a Mars colony survive event X? An isolated population in an engineered ecosystem on Earth survives X with higher probability.

I'll even make a positive case for Earth being safer: Out of events which could destroy even a physically isolated, rad-hardened population, all of the most probable would also eradicate life on Mars. The most probable of those are deliberate actions by a malevolent entity, such as in a hard-takeoff UAI scenario.

In such an event, your only hope for long-term survival is to hide, and hidden is one thing an offworld colony can never be.

> In that hypothetical, Earth is what's hit by such an event. Let's say you have a self-sufficient colony of Mars of around 10,000 people. Let's say a civilization-destroying and mass-dying event happens on Earth. Would you be better off on Mars or on Earth? That's the argument that was constructed; that's the value of such an option if it did exist. A conditional, hypothetical argument, but whatever.

Er, I think that was the point, right? Take your hypothetical self-sufficient Mars colony, and build it on Earth instead-- underground, say. For far cheaper, you can have far more people living there, and even after an extinction-level event they will live on a more habitable planet than Mars.

Yeah, I'm not buying that. If your goal is to have a cache of humanity that survives x-risk scenarios, a dependent Mars colony is by definition not MVP because it is not V. For the enormous cost of building a human habitat in a distant gravity well, you've succeeded in protecting exactly 0 people against 0% of x-risk scenarios.

That sounds like exactly the sort of overinvestment in unproductive technology that MVP theory is designed to prevent.

Many do. People eat official Soylent because the convenience, specifically, is worth it to them.

However easy your recipe is, mixing a bag of powder with a pitcher of water is still faster, easier, and less to pay attention to.

Just in case you aren't aware, the latest update of Soylent (v1.4) has upped the fat. Carbs now account for 43% of the calorie count, which is (slightly) less than you'll see any mainstream source recommending.

Still nothing that counts as "low carb", but not exactly "a ton" either.

Technically, they don't even qualify for safe harbor protection since there's no registered agent, and their policy seems to be "we won't or can't remove anything for any reason".

So they might get a DMCA takedown request, but even if they comply with it they would still have liability and could still be sued.

> Our devotion to this goal is further accentuated by our Public Legal License, which stipulates that all the content on Frizbee is in the public domain, making us as a governing entity irresponsible for its propagation.

Well, whatever it is, I guess being "decentralized" exempts you from copyright law.

Except we don't need to stop burning fuel, right? We just need to stop using it for net energy.

With enough "free" electricity we can "buy" fuels via carbon sequestration, and you can run your (somewhat pricier) camp stove as much as you want.

Would it be overly pedantic to point out that the syntax is CSS syntax? You seem to have an issue with vocabulary and semantics, not syntax.

Slight correction, it is amazing. https://share.oculus.com/app/minecrift

Yeah, it actually would not be a big deal except that after you move hjkl, you need to move dhtn, and then... I wound up with a couple of slightly different mnemonics, but not enough to be really confusing if I sit down at a strange terminal.

This really shouldn't be downvoted, it's basically the only thing keeping folks from switching. Talking as someone with a super-custom Dvorak vim layout, here-- you'll run into software that just won't work without switching to US.

In practice, the combined strategy of Dvorak+QWERTY command keys, application-specific layout settings, and a rarely-used keybind to swap manually makes this manageable on a day-to-day basis, but it's definitely not ideal. Blame the dumb legacy technology driving keyboards, if you're mad.