961 karma · joined March 12, 2009
This is a terrible assumption. 71% of the planet's surface is practically devoid of talent.
You could say there's a back-and-forth between hardware and software, but to me it looks like software is playing catchup. "Oh I've got 16-wide vectors now? Ok let me go back and completely change everything." "What, I can't load a vector from an odd-numbered array position? Hmm, there goes THAT algorithm." The electrical engineers are running us.
The metric presented here is much better for rating authors because it gives more of an author's peers an opportunity to vouch for him by citing his work, as opposed to only a small editorial board and review committee who decide if he gets into TopJournalX.
Adding a pagerank-style coefficient (increasing the weight of citations that come from well-cited papers) would make this metric even better for precisely the reason you state: papers exist in perpetuity. If I write a paper now but it is ignored for 50 years, then someone builds upon that to break ground in an entirely new field, then I deserve some indirect credit for that. The journal I published in does not.
http://shopping.yahoo.com/articles/yshoppingarticles/204/con...
I have this sneaking suspicion that its harvested by third-world leukemia patients, or fertilized with aborted ponies or something else terrible, because it's too good to be true. I live out in the sticks and my coffee options are the grocery store and the gas station. It's not only tastes better, it's half the price of any other whole-bean coffee you can find in a typical grocery store. (I like whole-bean original myself. The Columbian is too sour for me.)
It's the difference between C's qsort and C++'s std::sort. The latter blows the former out of the water when sorting small things. This brand of polymorphism is unique to C++ and until someone does it better (which no one seems to have any interest in, except maybe Walter Bright) then C++ will always be "the best C."
http://en.wikipedia.org/wiki/Necrotizing_fasciitis
These are rare, but strep throat is pretty common.
Although you're free to discount ML and its ilk (OCaml, Haskell) as non-mainstream.
Obviously not a resident of the central valley.
Yeah I don't really see whats magical about this program, its just really intensive. If you took all the underachievers from other schools and tutored them for 6 hours a day then those school's scores would rise too.
It's sort of like the "epiphany" of clear-build-hold in Iraq. No shit - the secret to progress is focusing on fundamentals and working your ass off? But then again, maybe common sense in bureaucracy is magical.
Of course, to any rationally-thinking being, today is 2009-05-07, which is meaningless.
This article, and the one in the thread you linked to, are talking about large corporations, not startups. There will always be a shortage at the high end. That's what makes it the high end.
Incidentally, the article you indirectly linked to quotes a Duke professor whose opinion largely agrees with the opinion of the UC Davis professor. Last I checked, Duke was a pretty well-regarded university, so I guess that means he's right. Or is there a flaw in that logic?
"You have an attitude problem"
Also, the article mentions specifically that Toyota and Honda use a lot of American-made parts, which are of higher quality than whatever Ford/GM/Chrysler are using (doesn't say where they are getting parts from) and that is a major contributor to the difference.
for ( int i=0; i<ni; ++i )
for ( int j=0; j<nj; ++j )
for ( int k=0; k<nk; ++k ) {
a[ k*ni*nj + j*ni + i ] = ...
}
which sucks. Optimizing multidimensional array access (which characterizes most of scientific computing) is much easier for a Fortran compiler.Intel C vs Intel Fortran : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
(I'm not even going to link to the GCC Fortran benchmarks. They're embarrassing.)
C is no slower than Fortran on any of those benchmarks, and on some it cleans Fortran's clock. The aliasing issue is the only thing Fortran has going in its favor, but clearly its not ubiquitous. The n-body benchmark, for instance, is fairly typical numerical code. You might even think, since it's simultaneously reading and writing through multiple pointers of the same type, that aliasing is an issue, but its not. And in the rare case that it becomes an issue, there's compiler hints (e.g. C99 restrict) for that.
Picking Fortran over C solely because of aliasing worries is premature optimization of the worst kind.
The complaint was that there aren't any mature libraries that go a step further, beyond feeding manually-constructed query strings to the DB connection, preventing injection vulns at the type level, etc. In an OO language this would be an object-relational mapper. I think the functional crowd is still trying to figure out what a "functional-relational mapper" is supposed to look like.