For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more Cushman's commentsregister

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.


Is this blog post a dig on Rich Hickey's talk 'Simple Made Easy'?


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 an acceptable description.


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.


Oh wow, I totally missed that. Thanks for clarifying!


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


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


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

Oops, yup. Fixed.

Your solution is pretty clever, though it leaks memory like a sieve. To get around that, you end up needing something like weak maps.

Once you have those, when you do the pattern you suggest, you are basically doing metaprogramming and reinventing the very idea of an "object" yourself from scratch.

That can be fun to do, but to me it starts to feel less like expressing "the same thing" and more like implementing a new language that lets you express the same thing. Just because I can implement a GC in C, that doesn't mean C has a GC. :)


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

    ...


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.


Since you specifically requested my argument...

I'd agree that lawbreaking is a reasonable moral choice, but not in this case. Moral lawbreaking, in my view, is done when there is a clear benefit or reason to the lawbreaking. And by clear I mean clear to a reasonable and moral person, and not just a speculative personal opinion.

Given that frame of reference, I would argue that (1) the notion that online drug dealing would lead to harm reduction for a drug addict is speculative rather than clear; (2) the harm caused by improved access to hard drugs by more potential addicts would be tremendous and therefore likely exceed any potential harm reduction; (3) given Ulbrict's apparent willingness to hire hitmen, I find it impossible to believe he was in any way motivated by concern for others.


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".


In the original, "not a reasonable argument" was specific to this instance. I try to avoid generalizations as one can almost always manage to find a corner case exception.


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.


> 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.


I'm also talking about the required specs of the machine that will be driving the goggles.


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.


> 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.


How do they survive a mass dying?


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.


Mars colony survives a mass dying in this hypothetical by not being the target planet of the mass dying.

Of course, you have threats that can impact both. Improvement by degrees is still beneficial though. Even though a backup is not useful for this type of risk, in the original hypothetical it is useful.

Also, of course you can switch the hypothetical around and consider Mars getting hit by the mass dying event. But we're talking about the value of having a backup and considering low likelihood situations where having that backup shows its existential benefit.


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.


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.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You