Except you're the one who brought up $200k as a number to begin with. And those people who sold themselves into debt slavery, by going to an extremely good school, may actually still hold jobs that will allow them to repay their loans eventually. Ignoring your arbitrary choice of debt number, we're looking at many people in debt and many of them without any college degree whatsoever.
And talking about parents isn't helpful. Parents are the ones watching the State of the Union address where the President talks about higher education and competing with China and then go out in the town and talk to the other parents about where their children are going to college and what their children are doing with their degrees. Thinking that only 18-year-olds can be fooled into saddling themselves with excessive debt is nonsense.
Hahahaha. I've totally posted my response to a recruiter on FB before, because I had to vent about it. He nails every important point, including that we should have some sympathy because they are incentivized, at least in the short term, to shotgun blast. OTOH, it sucks to complain at all about getting recruited when so many are unemployed or underemployed.
I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together.
A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.
I started thinking about the dictionary attacks, too, and ultimately you're right. Not worth enforcing and easy dropdown changing is eventually what we want. Thanks for your thoughts.
Yes. I totally agree. I would certainly love to support multiple distinct personas. There is an open question of how to do that while mitigating the damage potential. There are also cases where multiple personas might usefully be linked. For example, when commenting on programming issues you might want to link your persona to your stackoverflow identity or your HN account. Honestly, the biggest mistake I could make would be to assume I know what the community wants before we have a community. I think it's probably wise to err on the side of less friction and more prismatic identity and deal with restricting multiple signups if/when we need to. For now I plan to enforce uniqueness for outside identities (only one pseudonym per Twitter account) but also allow a basic reCAPTCHA username/password signup. If someone wants to contribute code to manage multiple personas within one account that would be fabulous, but annotation functionality feels more priority for me. If you think there's still a fundamental misunderstanding please continue, but I totally agree with your comment and don't think there's anything about it that's incompatible with my current vision.
Thanks! Wherever possible I'd like to ditch the personal information after signup and just keep a hash or something that we can use to prevent multiple accounts using the same Twitter, OpenID, etc, linking only these opaque tokens to user IDs in our database. I'm trying to put together our user tables and login system in the next day or so and welcome any comments or concerns you have with the implementation. Feel free to jump into our dev list or #hypothes.is on Freenode.
I think Jon was just trying to provide some information on the spectrum of possible identity solutions one can choose from. At Hypothes.is, it's extremely unlikely we would try to do anything like this. However, it does represent a form of "verified pseudonymous" identity, in which your uniqueness as an entity is verified by a central authority, but that identity is never exposed. See my comment below for more information about what we might actually implement.
We're not trying to compete for attention in the social web. Part of that is reflected in our involvement with the W3C Open Annotation Working Group (http://www.w3.org/community/openannotation/). While Hypothes.is may be one place to publish, the goal is to provide better linking and referencing tools to facilitate aggregators and plugins that can bring the conversation back to the source material. In other words, to bring this conversation on HN into the RWW frame and vice versa and to allow better quoting and transclusion between these content silos.
Quite the opposite, actually. I will be seriously considering the privacy implications of everything we do. One of our core principles is a commitment to pseudonymous accounts. To the extent we allow multiple identities to be linked to one account, it will be in your control to do so (or not) as suits your multi-faceted persona, tin foil hat paranoias, or legitimate privacy concerns. While we understand there is a social cost to cheap pseudonyms (see Friedman, Resnick (2001) http://www.si.umich.edu/~presnick/papers/identifiers/081199....), we believe we can develop a reputation system and a user community that resists gaming attempts without significant barriers to entry or privacy-invading personal information mining.
The goal of Hypothes.is is, on the contrary, to be a forum where you can voice your opposition to policies you find to be ushering in a police state and have the community weigh in on an informed discussion.
That's only true under the assumption that popularity is the only factor in visibility. On hacker news that's not even true entirely because there's a temporal factor: new postings remain visible for at least a short time. However, there may exist other possible ways to artificially increase visibility in order to promote diversity. Some of these methods are the research subject of Paul Resnick at the University of Michigan who is listed as an advisor.
My understanding is that attempts will be made to algorithmically promote diversity and to reward/punish social behaviors in such as way as to discourage discursive protectionism.
Not necessarily. A callback function with the standard signature under the hood is implied. If the author is controlling flow into and out of these execution contexts there is no reason an error passed to the implicit callback cannot cause an exception to be thrown into the original execution. Throwing exceptions into coroutines is a fairly normal pattern.
There's room for improvement. Most programmers shouldn't need to know how to write asynchronous code just as they shouldn't need to know how to write concurrent code. Consider mutexes vs Java's 'sychronized' vs transactional memory: there's a way forward, and it's to reduce complexity for the average programmer.
Remember that not everyone is as awesomely brilliant as you are.