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]!"
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.
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.
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".
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.
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.
TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.
No, TDD is painful, but it's a long-term investment. If you code once and never have to touch it again, you can get away with making it work right without tests. But if you want to be able to grow your system, you want something to make sure that you don't kill the old functionality in the process of building the new. And sometimes it's just helpful to spell out the expectations of new functionality ahead of time so that you know when you've achieved it.
Process for the sake of process is pointless. And if you have good reason to work around or jettison a given process, go for it. As I told the other programmers at my job, the only piece of our process we would probably consider an absolute necessity is source control. Code review is highly recommended, tests are very strongly pushed, formatting standards are there for good reasons, but there are times when they are not helpful.
The problem always comes down to whether or not your developers are adults with good decision-making capabilities. Process is too often employed as a way to allow you to get stuff done with people of average or less ability, but process also hurts them because they can't figure out when the process is unhelpful. And if process is imposed by fiat, those who could figure that out are frustrated by having to go through the motions. But if you have trustworthy people and you actually trust them, you institute the process for their benefit, and when it's not useful they know not to use it.
No it doesn't. You can be religious and think ID is a bunch of hooey. This isn't an either-or proposition.
Of course it isn't.
But it IS "an either-or proposition" if you insist on a LITERAL interpretation of The Bible.
You can be religious and understand/accept evolution and understand that "The Garden of Eden" was a parable.
You CANNOT believe that The Garden of Eden was a physical location on Earth and understand/accept evolution.
Insistence on a literal intepretation is not a pre-requisite for believing in Adam, the Garden of Eden, eternal sin, or Jesus dying for our sins. You've resorted to a straw man. I don't insist that all the details were exactly as reported. I do believe in the vast majority of the Jesus narrative. I'm open to there having been an actual physical Garden of Eden in some form or fashion, and possibly there being a key ancestral couple like Adam and Eve.
You're right in that there findings are not a big deal. But its also a good thing that they looked into it. Imagine if it had been the computers' fault and nobody checked into it. This kind of shit would just keep happening...
So instead, it's the people's fault, and this kind of shit will just keep happening...
Basically Wikileaks is trying to change the world so that we are so afraid of things we do in private being revealed that we don't do anything bad. They are doing this in the name of the public, and there is something to that, but they don't seem to care if they are crossing the lines between appropriately private matters and ones where the light of day would do significant public good. They absolve themselves of responsibility by adopting a pretty much filterless approach to revelation. There are great costs accompanying the benefits they provide, and though in the grand balance they may have done more good than harm so far, the magnitude of the stakes could tip the scale the other way very quickly.
RTFL. The letter indicates that cosmic rays are more likely to be distributed throughout the body due to higher energy, whereas the lower energy X-rays used for back-scattering will likely have concentrated impact on the skin.
Slashdot Mirror
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]!"
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.
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.
TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.
No, TDD is painful, but it's a long-term investment. If you code once and never have to touch it again, you can get away with making it work right without tests. But if you want to be able to grow your system, you want something to make sure that you don't kill the old functionality in the process of building the new. And sometimes it's just helpful to spell out the expectations of new functionality ahead of time so that you know when you've achieved it.
Process for the sake of process is pointless. And if you have good reason to work around or jettison a given process, go for it. As I told the other programmers at my job, the only piece of our process we would probably consider an absolute necessity is source control. Code review is highly recommended, tests are very strongly pushed, formatting standards are there for good reasons, but there are times when they are not helpful.
The problem always comes down to whether or not your developers are adults with good decision-making capabilities. Process is too often employed as a way to allow you to get stuff done with people of average or less ability, but process also hurts them because they can't figure out when the process is unhelpful. And if process is imposed by fiat, those who could figure that out are frustrated by having to go through the motions. But if you have trustworthy people and you actually trust them, you institute the process for their benefit, and when it's not useful they know not to use it.
He was still hung over from the JaegerMonkey party.
Of course it isn't.
But it IS "an either-or proposition" if you insist on a LITERAL interpretation of The Bible.
You can be religious and understand/accept evolution and understand that "The Garden of Eden" was a parable.
You CANNOT believe that The Garden of Eden was a physical location on Earth and understand/accept evolution.
Insistence on a literal intepretation is not a pre-requisite for believing in Adam, the Garden of Eden, eternal sin, or Jesus dying for our sins. You've resorted to a straw man. I don't insist that all the details were exactly as reported. I do believe in the vast majority of the Jesus narrative. I'm open to there having been an actual physical Garden of Eden in some form or fashion, and possibly there being a key ancestral couple like Adam and Eve.
are you saying he's weak-minded?
That wasn't an ellipsis. It was ASCII art.
That was a "Reply" vs. "Reply All" joke.
Whoosh.
The coffee table eats mice to power itself.
But what does it need power for? It's pretty much a coffee table without the energy the mouse will provide!
It needs power so that it can eat mice, duh!
You're right in that there findings are not a big deal. But its also a good thing that they looked into it. Imagine if it had been the computers' fault and nobody checked into it. This kind of shit would just keep happening...
So instead, it's the people's fault, and this kind of shit will just keep happening...
A portmanteau of meme and name?
Basically Wikileaks is trying to change the world so that we are so afraid of things we do in private being revealed that we don't do anything bad. They are doing this in the name of the public, and there is something to that, but they don't seem to care if they are crossing the lines between appropriately private matters and ones where the light of day would do significant public good. They absolve themselves of responsibility by adopting a pretty much filterless approach to revelation. There are great costs accompanying the benefits they provide, and though in the grand balance they may have done more good than harm so far, the magnitude of the stakes could tip the scale the other way very quickly.
RTFL. The letter indicates that cosmic rays are more likely to be distributed throughout the body due to higher energy, whereas the lower energy X-rays used for back-scattering will likely have concentrated impact on the skin.
F-sharp (pseudo musical notation)