yyqux

Alternative title: "American public paranoid, susceptible to leading survey questions".

Total bollocks. The statement simply discloses some more specific numbers about procedures that were never secret to begin with. The fact that a law enforcement agency could get a court order for an individual's data was never secret: it was even in the online documentation for the site!

Why is this surprising to anyone? I mean, bloody hell, anyone who's watched Law & Order should know that there are lawful procedures for these things.

Right, and a house is a liability as well as an asset: at that sort of price, the main cost of owning the house is the ongoing maintenance, utilities, etc.

No. There's mixed evidence about whether coffee is moderately good/moderately bad/neutral for you in sane quantities (i.e. a few cups a day). There's plenty of evidence that eating salty/sugary sodas and snacks is bad for you in similar quantities.

This is a great optimization technique to have up your sleeve. The downside of course is that if you're dynamically allocating and freeing nodes you can end up having to write your own memory allocator.

Asymptotically, sure, you're right. Constant factors are often important in practice, and simple cost models (e.g. ones that don't model cache locality) will no longer give you a decent estimate of constant-factor differences in performance between algorithms.

I think the issue here is that, in the past, with shallower cache hierarchies, models that assumed a constant cost per memory access would maybe be off by smallish factor (I don't know, maybe 50%).

However, now memory access is frequently the limiting factor for an algorithm, and there can easily be an order of magnitude in variation between the average memory access latency for different algorithms (i.e. cache-smart versus cache-dumb).

They're pretty good at using the right tool for the right job. There are plenty of places where they use arrays or other data structures too.

In a lot of cases they really want to be able to do O(1) inserts/deletes at the beginning/end of the list, which is where linked lists do have a major advantage.

Short linked lists aren't too bad, using them for storing bulk data is mostly a bad idea unless you can't avoid it.

Linked lists are a good fit for functional languages, and arrays aren't a great fit: this can be a major obstacle to writing Haskell code that is both idiomatic and efficient.

This is pretty reasonable advice. There was a time when linked-lists didn't have such a massive performance disadvantage compared with more contiguous data structures, but that time has passed and I'm not sure that the programming community is fully aware of it (certainly you wouldn't be explicitly told it in most CS programs). Memory efficiency is also often terrible on 64-bit machines, especially for doubly-linked lists.

Sometimes they're the right data structure, but I've definitely come across programmers who want to use a linked list for everything, even in code where performance is important.

Edit: the general advice that you should avoid linked lists for performance reason is good. The idea that you should never use them I just took as additional trolling for page views.

In 2001 we'll all be playing Duke Nukem Forever on our SPARC desktops running GNU Hurd.

Why do you automobile engineers keep talking to each other about pistons and transmissions, and all that nonsense, it's absurd. I just want a car that gets me from A to B and doesn't use too much gas. I don't see what that has to do with engine seals.

The biggest problem with TED is that people leave the talks thinking they understand more about a topic than they actually do. There's a big difference between having a general sense of the problems a field is dealing with, and actually understanding it well enough to apply it to anything.

I think the first is great when it comes to public understand of science, if you can do it well. The second is a bit problematic when people are left with a misleading impression of what they know.

I found this remarkably unconvincing: none of the arguments really seem to address the actual concerns with deflationary currencies, but seem to be directed at some (vaguely implied) strawman. I mean, why is the fact that there is a liquid market for bitcoins relevant at all? I don't think that has any bearing on whether a deflationary currency is bad or not. One failure mode for a currency is that it's completely illiquid, but that's not the most likely problem. E.g. there was always a liquid market for gold but it's probably the main example of a deflationary currency in practice.

Tel Aviv is in Europe now?

It's the only language that has quality, actively-developed compilers, excellent support for multidimensional arrays and can be very effectively optimized. The libraries are a bonus, but support for proper multidimensional arrays (i.e. not arrays of pointers to arrays) in other widely-used high-performance languages it either crippled or non-existent. It's a bit baffling that something better hasn't come along, but I think the wealth of Fortran libraries and amount of work on compiling it would make it hard for a new language to get traction.