427 karma · joined February 26, 2009
Presume (for argument's sake) that we accept the premise that foreign keys do not scale. Then the question is whether there exists some sort of realistic migration strategy once usage grows past that. If it does, then using FK makes total sense until we hit that point, doesn't it? And if true this should apply to 99% of users.
But if there exists no such migration strategy, then maybe the guy has a point?
I am quoting the word "dimension", because applying a precisely defined mathematics concept to something messier (like programming) will require a certain amount of hand waving and squinting.
Python gets some dislike, and there are a few significant projects trying to get off it. As a blanket statement I don't think dynamic languages work well at a company like Google.
Disclosure: I work for Google, but honestly I don't think it has particularly biased me to say nice things about Google Fi.
> The stack-based C API is not comfortable to use.
What is so uncomfortable about it? I think it's absolutely fantastic. There's nothing you can't do with it, and if you really want a heavyweight "magic" binding library you can do that on top of it. But you'll find even then you occasionally need to fall back to the "raw" API.
But obviously a number of people must have known. I don't know how they approach and recruit these people, it's above my paygrade.
If what I read is true then this is the first thing that has truly rocked my confidence that the company generally tries to do the right thing (while making money of course, we're not a charity). I expect significant internal backlash if they proceed and I hope they learn from this.
"This patch is crap. Stupid this silly that, and how many times have I said you can't break userland."
vs.
"I won't accept this patch as-is, or possibly at all. It has the following problems [...] and I don't feel you respect userland stability enough."
I really don't see how the second version compromises on the clarity or kernel quality.
Sound is linear, so yes. Any signal can be represented correctly as a sum of frequencies.
> wouldn't higher bit depth increase the fidelity in the range the audio does fill?
When you do the maths quantisation turns into the original sound + quantization noise. The bit range determines the noise (dither helps here). So it's a question of whether the noise is loud enough to hear. There are samples on the internet you can try to determine yourself at which stage you can notice the noise. It's shocking how few bits are actually required.
For a sloppy recording or repeated processing the quantisation noise goes up, so more bits are required.
As an aside, I developed my "snap" layout using a genetic algorithm run over the corpus of my programming career, then shifted around for aesthetic taste. It's served me well for more than ten years.
EDIT:
^{}\ 1+[]
@*:/" 0=();
~|&# _-<>You can't make business decisions without having some idea of estimates, so I find that arguments like this are used to weasel out of making any sort of commitment. Go ahead, add a big buffer, try to take uncertainty into account, pad, pad, pad - at least after all that we'll have some idea.
On the other hand a very real problem I've often faced is when the target date is an input into the estimation process. I.e. we want to ship by May 2017, go estimate until the estimation fits this target date. Of course, after estimation the target date can be an input into requirements scoping, after which you can re-estimate.
The fighter jet AI technique is hard-coded to a very specific problem domain, and could only be reproduced in a different problem domain by doing it from scratch.
The technique used by AlphaGo is at least closer to the idea that we can eventually build generically trainable machines that can learn to do a variety of tasks, without having to code them from scratch every time.