HN user

yyqux

74 karma
Posts0
Comments30
View on HN
No posts found.

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.

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.

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.

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.

I think it would be a bit premature to call MariaDB superior to MySQL.

Also it should be noted that the InnoDB storage engine was developed outside of MySQL AB. InnoDB is a helluva lot better than MyISAM for most applications because of performance and support for transactions, consistency, etc. Without it I don't think that MySQL would be a good candidate for many applications, particularly given that Postgres has improved a lot. I.e. I'm not sure Monty should really get credit for everything about MySQL/MariaDB.

Yep, I'm not in love with Java, but it's turned out to be the language I'm using on a couple of larger projects. And you know what, I'm perfectly productive in it, even though its more verbose. For shorter scripts it is a pain compared to, say Python, and I miss having a REPL to experiment in. But I don't find that to affect productivity though for a larger project.

I've seen dramatic speedups reducing an array from ~10mb to ~1mb. The problem was that the algorithm did multiple passes over the array, and each pass it would pull in blocks from main memory, only to evict them later on before they could be reused.

It depends a lot on the workload, but you'll see dramatic performance differences well before you fill up main memory.

R&R's defense strategy seems currently to pretend that they weren't claiming anything in particular by the paper originally: "hey man, I was just putting it out there. I didn't, like, mean anything by it."

But their own public pronouncements, and the way they responded to other's interpretations of the results, pretty much indicated that they though they'd found firm evidence that there was some big non-linearity at 90%.

And then the bytecode is interpreted. It's faster than interpreting the AST or source directly, but it's still pretty slow.

Java compiles the bytecode on the fly. Back in older JVMs where Java interpreted the bytecode it was also slow as hell.

There is a large variance in how well departments look after their students. Some will give you a decent stipend and some security of income. Others you will be totally dependent on the good-will of your advisor, or have to fight for teaching assistant positions.

If this is true, then it doesn't actually do anything to confirm the argument of the original article. The opposite actually. If you had selected a random sample of people and placed them in jobs in Google, then sure, that would provide a lot of evidence that academic performance doesn't matter. But that isn't what happened: this is a sample of people who already made it past the Google hiring filter, which allegedly is placing too much weight on credentials.

If the premise of the original article was correct though, you would expect that the uncredentialed people who made it past the hiring bar would be far stronger than the people who got an unjustified boost based on their credentials and the prejudices.

If it's true that easy-to-measure academic credentials are basically uncorrelated with job performance, then that's probably a good indication that their hiring process actually is well-calibrated: if people with poor credentials were doing better than people with good credentials, then their hiring process isn't giving sufficient weight to non-academic factors. If people with good credentials were doing better than people with poor credentials, that would indicate that they were putting too much weight on credentials and could improve hiring by weighing other factors.

I don't see the correlation between income and usage. E.g. look at Missisippi and Minnesota.

I don't think the article was saying that here was any connection between political beliefs, they were just presenting it in the same way as political maps are shown.

Yes, it works fairly well, but unfortunately has crushed the capitalist Ubermenschen who never had a chance to build TurboTax Australia under the government's boot heel.

I've actually had my return automatically amended a couple of times to give me more money back based on tax rulings on deductions.

The argument seems to be that Americans don't sufficiently resent paying taxes already because it's too efficient, so we have to make their lives even more inconvenient. The amount of complaining about taxes I hear on a day to day basis I think entirely discredits the premise of the argument.

Yes, I went to the DMV in Illinois to get my license and managed to complete the eyesight, written and driving tests and walk out the door with my new license in maybe an hour and a half. I didn't even have an appointment.

I'm aware this isn't the case in all states, but that says more about the priorities and competence of the people running those governments than it does anything else. Unfortunately a lot of people seem resigned to the idea that things are going to be run poorly and don't even bother punishing the politicians who are shirking their responsibility of administration and blaming their own failures on some abstract idea that government is always inefficient.