skysight-inc/HackerNews huggingface dataset:
This is a good article, and it goes into detail in the origins of tipping and why different countries tip differently that I hadn't seen before. But it only covers the restaurant industry. What about all the other jobs where tipping is expected? How about jobs where we're unsure whether to tip?

For example, since this is Hacker News, how about all the service industry startups, such as the transportation companies Uber and Lyft, or Postmates, or Instacart, or the many others that have sprung up? Of all of these, Uber is the only one I can think of that explicitly doesn't provide a means to tip. Most of these companies do offer a way to tip (although they generally leave the default at $0). When I use one of these companies, occasionally I ask the driver / delivery person / whoever what the expectation is, and usually the answer is something along the lines of the tip is completely optional and is provided because some people explicitly want to tip. But this answer is very unsatisfying, since I don't know if they're being truthful or if they've been instructed to tell people it's optional. Ultimately, I'm always left with a little bit of anxiety about whether I really should be tipping, and if so, how much is appropriate.
Personal Search (Node.js) getting closer to reality with information model
Fair points - we don't allow failed servers back into replica sets and rely on writing to multiple nodes instead of the disk as source of truth.

This may not suit everyone and absolutely does not suit financial transactions. You can bend Mongo to do it using additional collections and money movement logs... but, why bother when it's simpler to use MySQL/Postgres?
IIRC, it's just the dBs/time and not headphones specifically that contribute to hearing loss. If your ear drums are getting 100 dBs from speakers or 100 dBs from headphones, it should cause the same amount of damage over the same time.

Also "60% of maximum volume" is a poor metric due to differences in headphone impedance and sensitivity.
agreed! async/await is much easier to understand (and explain) than promises, and let's agree to not even talk about callbacks.
Location: North Carolina

Remote : Yes

Willing to Relocate : Depends on the offer.

Technologies: Ruby, Obj-C, Swift, JS/CoffeeScript

Resume : Available upon Request.

Email : taintedz@gmail.com

I'm a Ruby/iOS developer currently, always looking for new opportunities. I'm especially interested in remote work. If you're in need of an experienced developer, drop me a line.
Sadly, the much-discussed explosive second half of the PATENTS file is still present: https://github.com/facebook/react/blob/91b45641b8bfbdecace94...
Learning to Program Is a Loser's Game
I wonder how Google feels about this. Seems like it's in the same ballpark as buying links and/or guest posts. Obviously everyone does it, but this is so blatantly out in the open, exchanging money for social shares. Hopefully Google doesn't penalize airpair like they did rapgenius.
How do you make that not vulnerable to injection unless you're escaping all variables that might be used in a query?

It was just a mockup. But you are right, in reality it would end up looking more like this (and use custom interpolation for escaping):

s.add "WHERE foo > $(bar)"

Likewise a smart syntax for clause combining (AND/OR) and some kind of nesting would probably be needed.

I believe both of these problems should be solvable without compromising the simplicity of the approach.
Fair enough, and I led Mozilla to work in earnest with Adobe on ES4 and Tamarin, to get MS to re-engage with Ecma TC39 beyond ES3 (also for ScreamingMonkey: ActiveScripting uplift of IE to support ES4 via Flash without MS's cooperation).

But we couldn't map AS3 directly to ES4, because Flash was too different from the Web: single SWF link-step and static typing were two big diffs.

Even now static typing in dynamic code loading environment, or "gradual" or "hybrid typing" if you will, is not quite a solved problem. SoundScript or whatever it's called is an experiment, as the V8 folks have been careful to say.
YC is fast becoming a tumor on the whole startup scene.
Totally. While it seems appropriate that a product like Dropbox would require some very careful risk management and quality control, this feels like a joyless environment, despite the occasional use of memes in quality control threads.
Literally everything is harder with young children. Not just YC. That doesn't mean the world is ageist. That means that parenting is hard work that comes at the expense of your other priorities.
Yeah, I kind of assumed this was standard operating procedure, like Anderson Cooper's "internship" at the CIA.
Come on, turn the cheek. Sheeze. If you are really feeling vindictive, just forward the OP, that will make him think twice next time.

Edit, removed sarcasm
Those sound pretty damning to me. Especially coming from a billionaire.
I can't help but think how this reflects on YC's previous words in regard to diversity in the tech industry. The obvious snark involves the word "myth" or expanding YC's diversity to include people on record as opposing it, but my intent is not to express snark. No surprise when money trumps the need for explanation. I guess being a billionaire means never having to say you're sorry.

Good luck.
I think you're drawing a false correlation here between no-tip countries and poor service. There may be countries that don't have a custom of tipping and also have poor service, but there's very little reason to think that the two are actually related. For the same reason, there's very little to think that level of service in restaurants in the US is related to the expectation of the tip.

More generally, if a country seems to have poor restaurant service overall, that's a cultural thing. Introducing tipping would be unlikely to change it. To think otherwise is to think that waiters are only doing their job on the hope that they get a consideration, and that without that financial lure, they'd become lazy do-nothings. And that's both highly insulting and also illogical, because there's nothing unique about the job of being a waiter that would cause people to be lazy who would otherwise perform their job adequately in every other industry.
The biggest potential problem is using a file/global-scoped "use strict" directive in a .js file that gets concatenated and minified with other files that are not strict mode compliant, thus unintentionally modifying the behavior of any code that's concatenated after the strict mode script.

This issue bit Amazon in the ass a while back and gave rise to JSHint checking for function-level strict mode declarations only and the general rule-of-thumb to not use strict mode in production code.
This probably wouldn't work unless you are an extremely exceptional candidate (ex: a leader in the field, major contributor to an open source project they use internally, etc). Most of the time employers have the upper hand since there are a number of people applying to a single position. So if a number of qualified candidates apply, and one hands them an "employer challenge", their resume will be thrown in the trash.
Its a little tricky since producing a sine wave at high frequency on an arduino without extra hardware is hard. Likewise adjusting it finely is also hard. Also if you have a sensor and not a plain transducer, you can't change its programming.

Also, piezoelectric transducers can have a somewhat limited frequency range.

I've actually been looking into making some high quality sonar equipment from scratch, but getting good datasheets on ultrasonic transducers has been a royal pain in the butt.
Your comment reveals something often overlooked by the crowd shouting "OMG Bitcoin doesn't have chargebacks". Most people shop from merchants they trust, most merchants are honest, most disputes are resolved without chargebacks. Therefore chargebacks aren't really that needed or that important for most transactions.

IOW: you would have no problem paying Amazon in bitcoins, because you trust them.
"accessing missing properties throws" will just lead to a lot of use of try/catch, and the issues that entails. It's frankly doubtful whether it will speed things up at all, if there is any penalty to throwing try/catch everywhere.
That's an interesting and I think valid point. Older people tend to find it easier to raise money just on their own, make connections on their own, etc. They also have more experience, so they need less mentoring.

Maybe they just don't need accelerators as much, therefore there's no niche for one that caters to that crowd.
I think you are getting blinded by to much of a "halo".

After all that's a bit like thinking that someone has to go to an Ivy League school (let's say Harvard) or "game over".

We all know that there are many successful people that didn't, and that additionally aren't even college graduates (and didn't drop out of an Ivy School either).

And by the way, YC is not the entire entrepreneurial world either.
Ignore them all, use these:

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

http://blog.jle.im/entry/io-monad-considered-harmful
For Software Engineers, citizens from these 4 countries can get work Visas other than an H1-B:

Canada
Mexico
Singapore
Chile

The first two on the TN Visa, and the latter two on the H1-B1 Visa, the cap has never been reached on either.
That seems like a bigger issue for TS, which aims to be a superset of JavaScript, vs. CoffeeScript which is a totally different language.

And I think the parent comment was concerned CS/TS would break as ES changes underneath.
And if it isn't clear, yeah, I think forwarding this to the company he has the potential of ruining this guy's life.

Call me soft hearted, I guess.
I mean, there's a difference between looking at someone because they're talking or you're engaging in the meeting with them and staring directly at their boobs. I've been in situations where people are obviously gawping at me and it's incredibly uncomfortable and it's a much, much different experience than when they're idly looking around a conference room because they're bored.
What I've heard is that games aren't particularly heavy on the GC anyway, because they load in the objects in the level and then they don't create much else in terms of objects. There's just not all that much to be collected. I guess it's a bit more complicated for open-world games that need to load and delete game world objects on-the-fly, though.
> I disagree, all little humans learn how to make that piercing scream often attributed to little girls.

You apparently don't actually know any little boys and girls because their screams sound nothing alike. Boys do manage a nice scream, but it doesn't sound the same, especially past the age of 3.

> Little boys will likely do it less as they begin to be socialized and thus wedged into gender roles

Again with this nonsense canard? Why is there such an inability to recognize that boys and girls are different? Next you'll tell me people aren't born knowing what gender they are, but rather it's "socialized" into them.

A desire for equality will not be achieved by erasing all differences, but by celebrating all differences, and recognizing each is valuable in its own way.
If you left their income solely up to their employers, it would be more predictable. But it would also almost certainly be considerably lower.
My policy (I'm co-in-charge of recruiting at Matasano/NCC, and a lot of folks report to me) is this:

1) Hire based on current ability, not potential. Hiring based on potential is a minefield that our whole process is designed to avoid. ("Enthusiasm," "cultural fit," talking a good game without being able to walk the walk, etc.)

2) Be aggressively fair in giving out promotions and raises. Keeping someone's salary low because they're bad at asking for raises is not a good long-term strategy, especially in consulting.

Seems to be working out.
You say politically correct and I say treating people with respect.
You look at the face of the person who's talking. Or, if there's a presentation, you look at the material being presented. You might also look at your phone or notes or computer. but those are all somewhat rude for other reasons.
Pragmatically, how does subsetting matter? ES6 transpilation will be a requirement for many more years. Once you transpile, all the ES6 requirements blow up (eg. not extending prototypes).

A more particular criticism. How does forcing let statements on everyone improve performance?

All it does is force implicit (rather than explicit) scoping rules on JS developers because devs from other languages don't seem to be able to understand functional scoping or hoisting. It's a huge case of X language isn't like Y language that I already know, so let's change the unfamiliar language.
- Yes, legal fees are counted
- this includes government filing fees (you may be referring to PERM advertising, which is part of the Green Card process)
- no
- this is an experiment from the team at Teleborder.com, which is a complete global mobility platform
The world would benefit much more from him starting a worthy alternative to YC. Few others are in a position to do so. He probably thinks there would be no profit in competing against what he sees as YC's monopoly.
As a fan of go, I was also a bit disappointed at all the gotchas and how easy it is to make it wrong: if

let result = await db.post({});

works, why can't I

docs.forEach((doc) => await db.post(doc))

? I still have to keep promises somewhere in my head and work around them.

But I saw this post [0] the other day where the author reuses csp and go stuff and introduces them to js to basically achieve asynchronous actions in a synchronous manner:

function dbPost(doc) {
var ch = chan();
db.post(doc).then(function (res) {
csp.putAsync(ch, res);
})
return ch;
}

docs.forEach((doc) => yield csp.takeAsync(dbPost(doc)))

or, for your code:

go(function* () {
let db = new PouchDB('mydb');
let result = yield take(dbPost({}));
let doc = yield take(dbGet({}));
console.log(doc);
})

There still is some boilerplate compared to a fully synchronous code (and it introduces the notion of channels, which do have an added value other than just asynchronously waiting for a result), but overall I see it much more capable at the task than what is described in OP's article.

[0] http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-...
Ireland just accidentally legalised ecstasy, ketamine and magic mushrooms
Incredible, great work!
Australian can also get a E-3 visa, which is similar to a H1-B.
No doubt. Nevertheless:

https://duckduckgo.com/?q=apple+tax+ireland

The loophole(s) may have been closed, but I doubt Apple left them voluntarily.
A global study on human randomness
>Regardless, this has to be among the most formidable grouping of startup talent and brains in the valley.

Awfully broad statement. I might agree if you added "cash" to the list. ;)
Because many legal constructs in javascript preclude various optimisations that could otherwise deliver near-native performance.

Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur.

Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours.

Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.
> That depends on what actual results you can deliver.

Nothing to do with me. I plan on purchasing the results.

> If it's not very much, that's not a fallacy, it's a demonstration.

Rats' lifespans have been doubled[0]. And there are medications which are used for other conditions being looked at: like rapamycin (or the development of a variant), and metformin.

There are also supplements like the newly released nicotinamide riboside.

Plus, people such as Google (via Calico) are developing treatments targeting the longevity gene FOXO3.

The area is vast. And you've just demonstrated my point. What you've said sounds reasonable, but is actually bullshit.

[0] http://www.kurzweilai.net/fullerene-c60-administration-doubl...

Edit: Grammar.
The 10ms number is an upper bound. You will only see pauses that long if you generating large amounts of garbage, which is relatively easy to avoid.
That model may not always work well. At least one country I know of interviews you at your point of departure as to whether your IT department has recently had your laptop in their possession.
"This is very annoying to go to a restaurant and it appears to be more complicated for you to get water than it is when you're eating at home. This is what you often experience in no-tipping-countries restaurants"

I think you are mistaken here.

In tipping countries waiters basically beg you to leave as soon as you've eaten. They are always around you to upsell something (bigger tip) or to passive aggressively bring you your check. Eating out for only an hour is common.

In non-tipping countries however, the waiter simply leaves you alone to eat in peace. They don't ask you "Do you need anything else" every 5 minutes. People on average stay out more because of this.

Which is why you feel ignored. Different cultures.
There is an important difference between tech companies and many other kinds of workplaces. Tech has a greater tendency to consume people outside of work. Many go home from a day of programming, and relax by programming open source or hobby projects. They want to socialize with other tech people, because tech is their life.

Most other lines of work don't seem to spill out as much from the office, and people in them seem to socialize more outside their field. If X and Y are married, I think P(X is in field F|Y is in field F) is generally higher when F is a tech field than when it is not.

So even if tech were 50/50 male/female, I think we'd still have more problems than other fields (although if women were equally represented and powerful, more of the complaints would be from men being hit on by women at work...).

Sometimes I think tech companies should set up some kind of internal dating or matchmaking site, and establish a rule that if an employee is interested in exploring romantic or sexual relationships with coworkers, they have to go through that site. Communication otherwise must be kept on a professional level.
Like most other people here I'm not a real biologist either, but incest does not need to be a problem. Almost all dog-races are the result of lots and lots of inbreeding.

Ill effects of incest can be avoided with https://en.wikipedia.org/wiki/Genetic_purging . In case there are only very few individuals left that's probably not what one wants to do, though.
How about the entire company sits at one continuous "superdesk"?

"The challenge was to create the most collaborative, creative environment possible. The result? A desk that we could all share, literally--4,400 square feet of undulating, unbroken awesomeness to keep people and ideas flowing."

You can't make this shit up.

http://www.inc.com/christine-lagorio/meet-the-barbarian-supe...
Manage as in write all the code that ensures adherence to the schema. If you say that the field called "score" is an int in a schema-ful DB, then insert an array, the DB will throw an error. If you do that in a schema-less DB, it will not unless you add a check yourself. If you are not using some type of unified DB access layer, you must perform this check every time you write a value. You must also perform the check every time you read a value, since someone else might have written something different to the DB while you weren't looking. This you take on doing much more work, yet gain flexibility and possibly some space savings (as in, you are not storing empty cells if you don't want to).
Most cases of mixins (especially ones that involve state, as you allude to) can be implemented via composition by creating wrapper components instead. This is how Relay (http://facebook.github.io/react/blog/2015/02/20/introducing-...) works and makes different components more contained and easier to reason about. Here's one description of how to develop containers (really, higher-order components) from someone who works on Relay:

https://github.com/ericclemmons/react-resolver/issues/8#issu...

(We know people are excited about React Native and we're working hard to get it out the door – keep your eyes peeled!)
Pretty sure the parent was talking about what I elaborated on -- see in particular

"... because when the underlying JS changes (Like ES5->ES6) it can cause big breakage and/or confusion (Will CS classes work like classes do in ES6?)"

Having two kinds of for-of loops and two kinds of classes, even if CS tries to present only its flavor and hide the underlying (but you can still escape out to raw JS from CS), does make for confusion.

Also, separate point, ES6 sucks oxygen from CS, so while I expect CS to live on, it won't see as much adoption as it would have absent ES6.

The reason to consider this is that if it's a big enough oxygen-sucking effect, CS might want to break its own backward compatibility in order to re-align with JS. I've heard talk of such a change, but I haven't talked about it Jeremy or Michael. Pointers welcome.
Not really. It's a way to enable increased performance by disallowing certain hard-to-optimise constructs.
> Sometimes I think tech companies should set up some kind of internal dating or matchmaking site, and establish a rule that if an employee is interested in exploring romantic or sexual relationships with coworkers, they have to go through that site.

I feel a great disturbance in the force as if a million lawyers cried out in horror/glee and where at once silenced.
I think it's important for the VM, which is what I got as to why they are proposing strong mode and sound types.

I imagine that let and const afford optimizations to the VM.
Second this. The AMD open source Linux drivers are better than the Nvidia ones. It's the proprietary where Nvidia wins. You don't really need those unless you want to run games, though.
They explain that, they are aiming for faster execution and less bugs. Faster execution requires that the VM and the language changes. They tried this with Dart but that hasn't become popular, now they try again with something different and with smaller changes.
One of the hidden complexities of food service is that tipping often serves as a tax dodge. Servers often wind up taking home a fair amount of cash but reporting poverty-grade incomes.

I knew one lady who got a Section 8 voucher this way. She definitely did not qualify on what she regularly took home.
I missed the Q&A question about standardization, and that alleviates some of the concerns about how this will be play out.

But again, the concern is that Google is going to go ahead with this even before any approval. So when every single javascript related product from Google is already using it, what's preventing Google from just shrugging and going "oh well" and just continuing on with their modifications?

What is V8 for if not for Chrome (since V8 is not beholden to node/iojs)?
Adding New Relic APM and SERVERS monitoring to your dockerized ghost app