tdg

My reply is here: https://news.ycombinator.com/item?id=16398806

I don't get it.

He says there are IQ differences between people. Who are these "people" if not men and women? He either means men are smarter or he just randomly went on a tangent.

Let me ask you, when he says there are IQ differences between people, which groups of people do you think he means?

Here (section "Why we are blind"): "[...] the Left tends to deny science concerning biological differences between people (e.g., IQ and sex differences)"

I don't know how else to read that other than "men are smarter". Is there any other reading?

It definitely mentions it. Here (section "Why we are blind"):

"[...] the Left tends to deny science concerning biological differences between people (e.g., IQ and sex differences)"

I don't know how else to read that other than "men are smarter". Is there any other reading?

Some states in US allow you to take a photo of your ballot. This means they can already do the things you mention. But they don't, because it is illegal. It will continue to remain illegal.

If you are very worried about such a scenario, verify that your vote is on the blockchain, then destroy your receipt.

This idea encrypts your ballot with your voter ID + some secret key that you know and creates encrypted data E. It, then, publishes a (E, your ballot) pair. Since only you can decrypt E, others won't know how you vote.

Hmm, turns out I am wrong about the second point. Obj-C does not store the refcount in the pointer address:

https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

They store it in isa field. Still, as long as you also call any virtual method of the object (or due to cache lines, use any field), it will still be pretty fast.

I don't get how your code works. Why do you decrement first, then increment?

Regardless, your explanation is mostly correct. There will be an incref/decref pair for most accesses. However, LLVM (and Apple's refcount implementation) does 2 very important optimizations:

- LLVM can recognize (via static code analysis) redundant incref/decref pairs and take them out.

- I can't find the link for it right now, but Objective-C usually stores refcount inside the pointer (in other words, the memory address) itself. So as long as your refcount is small enough (which it will be 99% of the time), incref and decrefs don't thrash caches but work on the value already in register.

Not to be nitpicking but a common criticism of China is that they manipulate their currency to _increase_ the value of dollar not devalue it.

This is not PFS but a simplified example of how you may not be able to decrypt a conversation with one side's private key:

Server X and User Y are communicating. Some guy Z has X's private key. Z is also passively listening the communication.

- Y sends its public key to X. X sends its public key.

- Y generates a random number (A), encrypts with X's public key sends to X.

- Both X and Z decrypt the number. Now X, Y and Z all know the number A.

- X generates a random number (B), encrypts with Y's public key, sends to Y.

- Since Z does not have Y's private key, it can't decrypt it . At this point, X and Y know A and B, Z only knows A.

- X and Y use a predetermined algorithm using A and B as inputs to generate a new key. Further communications are encrypted/decrypted with this key.

- Z can't decrypt the communication.

A lot of Keynesian economists are arguing that now is not the time for austerity. The government's current mission should be to lower employment even if it means higher deficits (and debt) _for now_. Once we are out of this slump, the argument is that most of the deficit will take care of itself (since some of the deficit is lower tax revenue because of unemployment + cost of automatic stabilizers such as unemployment benefits). We still need to fix the rest of the deficit/debt problem after the crisis, though.

The second important argument is that (again, right now), this emphasis on austerity is actively making things worse.

Simple. You use unique smart pointers if you do not know the size of your data at compile time.

Last year had an extra week. So per-week profit is higher (which is what should matter).

Goroutines are extremely lightweight. It is common to run hundreds of thousands of them on one machine. (The main reason for that is goroutines start off with a very small stack and extend it as necessary)

It is up to executorService to decide how many threads to use to execute those tasks. But they will be executed in threads. So you are unlikely to have more than a few hundred(maybe a few thousand?) of them around at any time.

That's exactly like BigTable[1]. It makes sense that they built on top of that.

[1] http://static.googleusercontent.com/external_content/untrust...

First of all, congratulations on what seems to be a very well executed rewrite.

That being said, it will be interesting to see how this compares to all the stories about dangers of rewriting. I definitely want to see an update in a few months about the results.