That's "Cue". Que/Queue and Cue have completely different meanings.
Maybe he meant "Qué Godzilla jokes!", a Spanglish exclamation roughly translated as "Such [wonderful/awful] Godzilla jokes [can be made/have been made]!"
This explains why there are no arrogant people over the age of 30, yes?
Did you really just say XML?
And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.
You might actually want the pointer to be able to change. You may have a pointer to _some_ literal string, but want to be able to change _which_ literal you are pointing to.
*whoosh*
Back at ya.
Unless the exploration of the game space was exhaustive, there's no proof.
Wikipedia claims that exhaustive search has been performed, assuming that the same hand numbering is used:
http://en.wikipedia.org/wiki/FreeCell#Impossible_games
Either there's an error in translation or the MIT trained nuclear engineer has forgotten what probability theory is.
Having multiple means of cooling a reactor sounds like a good idea, but that will only reduce the probability of disaster.
But his point is that making assumptions based on probabilities calculations based on other assumptions is the problem. Anything with a physically plausible likelihood of happening is worth considering how to guard against, and nobody should settle on "good enough" without at least laying out the associated probabilities and any assumptions that went into those calculations. At least not where catastrophic repercussions are the _likely_ outcome of miscalculation.
Of course the regulators have to be willing to challenge assumptions, and ferret them out when probabilities are presented without accompanying substantiation.
Aren't those exponents reversed?
2048^4 vs 102^8?
1.7 * 10^13 vs 1.1 * 10^16?
So completely random is still better in this sense. Just hard to remember and maybe hard to input. xkcd compared "uncommon word + common substitutions + a couple random characters".
No, it doesn't. Just using a different scale (x = 2y).
A few seggestions:
Try to take over the world
Try to index the world's information
They're Page-y and the Brin.
Larry and the Brin?
They're dinky, they're Page-y and the Brin, Brin, Brin, Brin,
They're cagey, they're Page-y...
They're scary, they're Larry...
They'll take over the world
They'll catalog the world
They'll overthrow the earth
They'll monetize the earth
I for one love the Bible, and I found this hilarious, not trollish.
The summary is way off. Transistors are analog devices, so TTL may behave digitally but that's only because a lot of work was done to make that happen. All that's happening here is taking analog devices with certain characteristics and using them to model an analog process with certain other characteristics. No small feat mind you.
Stack Overflow reputation is cumulative. This means that if two people are providing answers of the same quality and at the same rate over time, the folks who have been there longest will have higher reputations, and that the higher reputation will reflect only tenure. Not any kind of quality.
If you want to look at quality, you should be looking at a metric that is something like (total reputation / number of months active). Even this is imperfect of course, since if people take a hiatus or something that will present the appearance of worse quality using this metric.
I was going to say that this fatal flaw invalidated the conclusions because the correlation between reputation and age just reflected the older people being around longer. The problem with that is that Stack Overflow opened in 2008. That's not enough time to explain a linear trend that tracks from age 16 to nearly age 50, but the final conclusion "So, senior coders earn their higher reputation by providing more answers, not by having answers of (significantly) higher quality." should still be re-examined with tenure-controlled analysis to try and see whether older aged members have been members longer.
The problem that I've found with TDD is that it encourages people to write code that tests the wrong thing. I like using it, because I gradually grow a set of regression tests and can be reasonably confident that I haven't broken anything, but I've seen a lot of people write tests that check for specific details, so you make a 5 line change to their code and then have to modify 100 lines of tests - not because you've broken anything, but because their tests were checking for implementation details rather than valid semantics.
I don't think it's TDD per se that encourages such bad practices. It's a complete misunderstanding of the purpose of tests. I guess I'm not big on low-level unit testing because it generally ends up breaking things down so much to the level that you do end up testing implementations rather than interactions. And thus you end up with Development-Driven Testing, an anti-pattern if I ever saw one.
So the problem is again with the application of processes and best practices without any understanding of what they're for and why they work. Because the people doing the work aren't good enough to understand and the people managing them aren't good enough to explain.
I don't think you understood a word of what I was saying. The whole point of TDD is the reality of code change.
Our policy is, when in doubt, do the right thing. -- Roy L. Ash, ex-president, Litton Industries
