jfager

It's "Thinking, Fast and Slow", and the study in question is hardly "key" to the book, it gets all of one paragraph in chapter 4.

Based on the actual voting record, on the most serious issues, she's about on par with the worst president of the modern era. Cruz and Trump would be worse, sure, but not by "a million times", more like 2x.

Four years of letting Republicans remind everyone how terrible they are at governing for a chance to be rid of Clinton for good and take back Congress and the White House in 2020? Maybe worth it.

The person Lessig would theoretically be Nadering, you do realize that as a Senator she voted on the wrong side of all of those bad things you're pointing out, right?

"as opposed to"? People only have one money?

I threw $n at a shot to get an honest, articulate voice on stage at an early-primary-season debate, to hopefully influence the party/eventual candidate's agenda. It didn't work. Oh well.

I have a $500 iPad sitting on my coffee table gathering dust, too, which was the bigger waste?

The actual damages that resulted from his actions were pretty small and purely financial.

Even if you prosecute on the basis of what could have happened (maybe we start charging everyone who runs a red light with manslaughter?), we're still not reaching the level of physical harm to anyone or (barring complete negligence on the part of the Tribune) a catastrophic material loss.

You really think society's need to avenge that wrong is worth spending $30k a year to hold him in federal prison, exposing him to possible violent harm, and depriving him of his future? Sorry, but that's insane. He should pay the actual damages, a punitive fine, and perform community service, tops.

Keys posted active credentials to a forum, and those credentials were used by others to deface a website. Do you regard that as a fair statement of what happened? Still completely insane to send someone to prison for that.

Keys is an asshole, and low-level nonviolent drug offenders absolutely should not be treated as they are.

Both of these things are completely irrelevant to the fact that any jail time for defacing a website is completely insane, the result of a witch-hunt mentality surrounding computer-based crimes.

Do you have any pointers to papers describing how vote auditing techniques extend to liquid democracy? The Google paper doesn't even acknowledge the problem, much less describe a solution, and most of the other papers I've read on the topic are either extremely handwavy on the technical details of privacy or make the same assumption as Google, that its good enough to hide votes from the participants but 'the system' still knows.

I'm a big fan of this general idea but taken to the limit of being able to delegate all issue votes to any person goes too far, and I'd prefer a system that elected representatives who accrue a threshold number of votes. There are a few reasons for this, but I'll just talk about one here, privacy.

Privacy is addressed in the paper but I think the real issues with it are just glossed over. "You get to see how your delegate votes" is great and should absolutely be true, but there are two other sorts of privacy that matter: privacy from the electoral system itself, and privacy from closely related people.

In very Googley fashion, this paper seems to take for granted that of course you'd trust the system itself with the knowledge of your votes and delegates, and that its privacy-respecting duty is fulfilled by simply not broadcasting that knowledge to the unauthorized public. But that's a terrible way to run a government that at least partially relies on a secret ballot as a means of expressing dissent and effecting change in the government itself, for hopefully obvious reasons.

The other form of privacy that matters is on a much smaller scale. A delegate who can exercise the votes of an arbitrarily small number of people is also capable of ensuring they are exercising the votes of a specific set of people. An abusive husband/father/wife/mother/boss/etc can know simply from the count of votes they hold whether their victims are following through on their command, and via transitive delegation they can pool that power with collaborators.

I'm bored of C++ apologists pretending like there's really such a thing as 'modern and idiomatic C++11/14' that any two C++ programmers actually agree on, or that you'd ever actually see practiced consistently in the wild.

You can no-true-Scotsman code that compiles, runs, and blows up in your face with any modern C++ compiler all you want, it doesn't change the fact that Rust eliminates entire classes of errors that are trivial to hit in C++.

In the cases where your application can benefit from parallelizing simple operations over a large data set stored in a collection, `parallel()` is fine.

It's even fine in the case where you're pulling data from a file or other low-latency sequential data source, assuming that the cost of filling a spliterator buffer is less than your cost of processing.

But there's a list of gotchas all more dangerous than the "magic make it faster" button of .parallel() imply:

- For the sequential data source case, if the cost of filling the spliterator buffers is higher than the cost of processing, you're just wasting a ton of overhead trying to use parallel.

- You have to be aware that by default all uses of parallel() run on the same threadpool, which makes it a potential timebomb if someone uses it in the context of, say, a webserver where multiple requests might all individually process streams. This also means blocking operations during stream processing are very dangerous.

- Mutating an external variable goes from being fine for a sequential stream to a race condition for a parallel one.

- You can't hand out Streams that you intend to be executed sequentially, b/c your callers can just call parallel() whenever they want.

And, yes, all of these considerations make the api more complicated than one operating over plain old iterators.

The main reason they build these on Stream rather than Iterable is b/c they wanted to include the `parallel()` method, which works via "spliterators" rather than plain old iterators.

In other words, in order to support a gimmick you can actually use in production in a maybe a handful of use cases, they complicated the api for the use cases you hit 99% of the time. Awesome.