If you tried to bake a cake with a recipe and/or knowledge of what ingredients go into a cake and how to put them together, but mis-measured the eggs/used high-protein flour and so ended up with a shitty cake I would cry no-true-Scotsman when someone said you weren't making a cake.
This is quite ironic, considering your sig:
Analogies don't equal equalities, they are merely somewhat analogous.
This is not a useful analogy of the one-time-pad issue, because in that case, the distinction is not predicated on an ad-hoc definition.
The essence of the no-true-Scotsman fallacy is its arbitrary and entirely self-referential circularity: the definition of trueness implicitly adopted by the fallacy's maker is exactly that which (in his mind) makes his argument true - nothing more, nothing less. In particular, it is not derived from any consideration beyond the fallacious argument, and it is not a useful definition in any wider context.
You claim that it is a no-true-Scotsman fallacy to say that an encryption key is not a one-time pad if it is used more than once.
Firstly, it is important to note that this is a narrow claim about semantics: what, exactly, can the the phrase 'one-time pad' be used to denote? It is not a claim about encryption (even though it is made in the context of encryption) because the facts of encryption do not depend on whether this claim is correct.
For your claim to be correct, the assertion 'an encryption key that has been reused is not a one-time pad' must be ad-hoc, introduced solely for the purpose of making an argument look valid, but it is the opposite of that. As you yourself point out, non-reuse is essential to the purpose for what one-time pads are created and used, so the assertion is predicated on a very meaningful distinction. Therefore, it is not a no-true-Scotsman fallacy.
You may think you are still right on the usage issue. Rather than take a position on it, the rest of us can ignore it, because we can make ourselves perfectly clear to one another by considering the context in which the phrase is used. In particular, your original claim that the citation (about the security of one-time-pad-encrypted messages) was incomplete is still wrong, as it very adequately covered the ways in which a key intended to be a one-time pad can be misused.
Strictly speaking, Venona was the project to decrypt the intercepted messages, started once it was realized that the encryption keys were being reused. Nevertheless, MrNaz is adopting troll-like behavior in his snarky and cryptic post, and his post here, unlike yours, contributes nothing to the discussion.
Yes, otherwise there is no possibility of consider improper use at all.
But the possibility of improper use is considered in the citation that you questioned, through its very explicit list of conditions that must be met for the encryption to be unbreakable. You are being pedantic in an attempt to cover a mistake you made, but we can all see that the citation was satisfactory (it contained sufficient information for its purpose), and therefore that you were mistaken (or shall we say pointlessly pedantic, if we are being pedantic?) to say the citation was incomplete.
While watching "The Diving Bell and the Butterfly", it occurred to me that knowing morse code would give you the best chance of communicating from this frightening state.
There's nothing wrong with your view, and it is one that the younger me would have endorsed, but it turns out that the range of music I like keeps on growing, without any effort on my part, and without making myself suffer through music that I am not enjoying. My collection of recorded music goes largely unplayed these days, as I often find it more satisfying to listen to something I have never heard before.
As Flynn demonstrates, a typical IQ test question on the abstract reasoning “Similarities” subtest might ask “How are dogs and rabbits alike?” While our grandparents were more likely to say something along the lines of “Dogs are used to hunt rabbits,” today we are more likely to say the “correct” answer, “Dogs and rabbits are both mammals.” Our grandparents were more likely to see the world in concrete, utilitarian terms (dogs hunt rabbits), but today we are more likely to think in abstractions (the category of “mammal”).
This is claimed to be evidence for Flynn's argument that we have shifted to more abstract thinking. A simpler explanation would be that more people today have been taught that dogs and rabbits are both mammals, and are simply recalling that fact, which doesn't call for abstract thinking.
I do not know if this is a poor example for making Flynn's case, or an indication of its weakness.
The article tells us nothing about whether the change can be attributed to the slimming of a fat tail on the low side of the distribution in test-scoring ability. My understanding is that the renormalization of scores is done under the assumption that the underlying distribution is Gaussian-normal, an assumption that seems to be at least somewhat controversial. Could this practice be hiding evidence that could help explain the effect?
How is it not compression? It reduces the data size being transferred and is recoverable on the other end. Maybe I'm not an expert, but isn't that _exactly_ the definition of compression?
While I agree with the people who say that it is not data compression, it is also worth noting that the question is beside the point - you may as well say 'it is communication' as if the fact that something of that nature has been done before renders it irrelevant. The point is that it is a clever, useful and significant extension to the state of the art.
I think they are simply saying that the count is not statistically significant, as it is at about the background level of the clean room they are working in, and three of the four types identified match contaminants on the equipment.
...So the title here, in the BBC website and some of the comments are way off.
I think your analysis makes some valid points but is somewhat complacent. Firstly, I am not convinced that the concept of a corner case is valid in security matters; attackers do not randomly stumble upon vulnerabilities, they assiduously seek them out, and a great many exploits are based on 'corner cases'. If you were ripped off to the extent of your credit limit, would you dismiss it as just a corner case?
The fact that 'card-not-present' fraud went up is hardly surprising, and not much of an indication that EMV is secure; criminals will naturally chose the easiest attacks, especially before they have had time to test the new technology. As the "card-not-present" window closes, EMV will come under greater attack, and then we will get a better idea of how secure it is in practice.
It is not particularly helpful to say that EMV is secure but the implementation is faulty, as it is useless without implementations. You might as well say that the cliff-edge is safe because it is hitting the ground that kills you. The backers of EMV have to take control of the whole development and implementation process for it to be trustworthy: as far as security is concerned, half a fence is no fence.
Whenever errors start showing up, it is reasonable to assume that they are just a sample of the problems that are out there. When dumb errors start showing up, it is reasonable to assume that the implementation was in the hands of people who did not try too hard to do it right, and who probably could not have done a good job if they tried.
The dissembling and apparently complacent response of the banks to these disclosures underlines the researchers' point (made in an earlier paper) that the banks' stated primary goal of chip & pin is to divest themselves of the cost of fraud. I find it disturbing that in many cases they have been able to pass the cost on to customers without producing transaction logs that might have vindicated the customer. This is a social rather than technical issue, but all security issues are, to a degree. It is only through the possibility of costly sanctions that we can realistically expect the banks to give customer security its due attention.
That's right, this is at least the second independent way Chip & Pin has been found to be broken. The banks claim to have multiple layers of security, but what they actually have are multiple breaches of security.
Another reason for collapsed blocks of code are often that a class or method gets so big, you need to collapse out code to have any oversight. But you can also very easy split a big class in multiple classes (composition) or split a big method into smaller. For example, if you have one big method, then you can very easy put that method in a new class and use composition.
Factoring can definitely be taken too far. If you were to convert every block into a method, you would have a great many methods with long argument lists, and it would be difficult to come up with meaningful names for these methods, as each block's purpose is so closely tied to the context in which it appears. You would end up with code that jumps around so much that it would be very hard to see what it does. This happens, and there have been many times when I would have liked a composing tool to convert a deeply-nested tree of tiny methods into a sequentially-readable algorithm.
I think you are missing the point that comment- and block-collapsing within an editor/viewing is temporary and reversible. You can start by reading the comments, but once you understand them, you might want to collapse them selectively to get a better look at the code. Think of it as a form of variable and adaptive abstraction (the root of the word abstraction is the Latin for 'draw (pull) away'.) Hiding exception-handling blocks can be helpful, too, so long as exceptions have been used correctly and are not used for control flow in the normal execution of the algorithm.
True, but documentation can also be achieved by other means than just comments.
Comments are still useful as a link from the code to the relevant part of the documentation, in cases where there are some non-obvious issues being attended to.
VortexCortex; While I think I understand what you are saying, most of the time the phrase 'self-documenting code' is used, it refers to comment-free code, and the idea that it alone is all the documentation you need. To go against common usage invites confusion; for example, you and Mr Brooke do not seem to be in disagreement, though at first appearance, you seem to be.
What you describe seems to be close in spirit to Knuth's idea of Literate Programming (though not his specific implementation of the idea.)
Stop using comments for everything. I just counted from the Slashdot posts here what comments are all for: For Bug-Tracker, Documentation, Source Control System.
You correctly identify the first and third uses of comments as being wrong, but for alerting the reader to the fact that there is some non-obvious reason behind the design of some section of code, there is no better way than using a comment. Even if the design is documented elsewhere (as it should be), a reference to the appropriate part of the documentation placed in the relevant parts of the code is very helpful in preventing someone overlooking it. This is particularly helpful for cross-cutting concerns that are not localized to one part of the code.
You need to understand that comments are only for one entity only: for the developer as a human. For the compiler comments are just non-existent. They don't have a syntax, they don't compile and they don't run.
This is completely irrelevant, because the whole reason behind high-level languages is for them to be human-readable. The goal is to make the program more understandable to human, but a language that has the necessary and sufficient syntax to be compiled is insufficiently expressive to explain the reason for its existence and the intent behind its writer's choices (for example, showing that code is secure often involves proving certain theorems about it.) This requires additional, non-compilable documentation, and once again, comments are the best way to alert the reader to these facts, even if (or preferably) only as references to external documentation.
Perhaps you are one of those people who believe that all code can be self-documenting? If so, then before you ever use or assert this opinion again, please complete this exercise: implement the quicksort algorithm in the language of your choice in such a way that the code alone clearly explains 1) a proof of its correctness, and 2) a proof that it is O(n lg n) on average but can be O(N^2) in the worst case. (that's just the starter: there are many more difficult problems, some involving concurrency and security, if you complete this one.)
If you start writing a comment like: This algorithm must run in 50ms and needs to assume that corner-case and that issue. Then why are you not writing a test that ensures just that?
Writing a test would be the right thing to do, but why stop there, when you could also add a comment? The criterion being tested for is a fact that you must necessarily know before you write the test, and before you write any code that is specifically designed to satisfy it. You, as author, have this knowledge, and you also know what steps you took to ensure the code satisfied the requirement. The subsequent reader initially does not know any of these things and needs to learn them. It seems that your preferred way is to set a trap in the form of a test that is triggered if they happen to unknowingly violate the rule, as if it were some sort of dungeons-and-dragons game. If this is the way you work, I would hate to have to read your code, and I would never contract you to write any.
Perhaps you are one of those people who believe that all testing code can be self-documenting? Because testing can, in general, require Turing-equivalence in its implementation, my comments about self-documenting code apply here. Furthermore, there is the question of knowing which tests cover which parts of the code, which is not necessarily obvious, especially where the issues are cross-cutting concerns such as concurrency, security and performance. Finally, you should be aware that no amount of testing can prove the correctness of code. Let us suppose you have developed some tricky aspect of the code through a reasoned argument for its correctness, as is often the case for security issues. No amount of test cases will serve to explain to the reader the logic by which you derived the implementation.
Perhaps you
Good code can show what is being done, but it can't show different approaches which were rejected. Comments can explain why certain shortcuts are valid or not valid in a way which won't be obvious from the code.
to which you replied:
No, that is for what tests are.
Suppose you have a situation where, because of the unusual distribution of the data, what would appear to be an obvious implementation would actually be inefficient. What are you going to do - write a test that times the execution of the code on a large sample of data? Even if you did, it would be inordinately and pedantically obtuse not to make mention of the issue with a comment in the code. We cannot assume that it will be obvious that this test refers to this particular algorithm (for example, due to cross-cutting concerns such as concurrency, the implementation may not be localized to a module), we cannot assume that the reason why there is a problem will be obvious from the test, and we cannot assume that there is an efficient way for the person reading the code in question to determine which tests' results are influenced by it, and therefore which tests should be read in conjunction with the code.
As Zero_Kelvin also mentioned, tests don't explain why the code was written the way it was, and what I have presented above is just one example that should make this point clear to anyone (I'm assuming that you would not allow comments in the test code, as that would seem to defeat your purpose.) Understanding code is hard enough without its author turning it into some sort of puzzle that can only be solved by deducing the intent of the author through an examination of the tests he wrote for it.
I find it difficult to believe that believers in self-documenting code understand how much, and what sort of information goes into the writing of software, and therefore I find it difficult to believe that they can do it effectively.
My opinion on hide or collapse stuff is very easy: it's a bad idea. Sooner or later developers will hide a lot of stuff, code, comments, it's like why it is a bad idea to hide stuff under the carped: clean up your room and not hide the dirt under the carpet.
The judicious hiding of information is what abstraction is all about, and abstraction is the main technique we have to cope with the complexity of software. It only works if the hidden stuff has well-defined semantics, and to communicate those semantics we need documentation that is at a higher level of abstraction than code.
In order to not only publish anything, but get a study through initial approval stages you have to do comprehensive review of existing work.
So are you saying that any student who has had a research topic approved has already demonstrated adequate background knowledge, either simply by getting that study approved, or at least will have done so by the time it is published? I may well be mistaken, but I thought the scope of graduate education was rather broader than that needed to complete a specific research project, no matter how deep and thorough its preparation was.
Is there any reason to believe that the problem is any worse at Coursera than at meatspace universities?
If it were 'only' at the same level as at degree-awarding universities, it would still be a puzzle: why do they bother to do so? Finding out why some people do take the time to plagiarize their way through a Coursera course might help in understanding plagiarism elsewhere, and also into the Dunning-Kruger effect and what seems (to a curmudgeon like me) to be an increasing culture of self-deception in general. On the other hand, perhaps it's mainly an occasional response to a deadline that the student can't meet, either for unexpected external reasons or poor planning on their part.
Frequent comment I hear is "I wish I didn't have to do all the busy work and could just focus on my research" when I talk about school to my SO..
For the SO in this case, who may well have a comprehensive knowledge of the larger field, the non-research coursework may well be busy-work, but I doubt that this is the case for most students. If graduate students focused solely on their research, this would exacerbate the current problem of researchers not always being aware of relevant established results and current research topics. Journals and conferences exist to spread this knowledge, but to be effective, their participants need to be familiar with of the state of the art in the broader field.
right now it is breaking under the weight of a valuation...
Facebook is hardly breaking. It continues to do its business, bringing in the cash and growing at what would be an extremely fast rate by normal standards. While a falling stock price would normally be an indication of something being amiss, in this case it is merely a follow-on from the irrational exuberance of the IPO -- and, thanks to that exuberance, it is in a stronger position financially than if rationality had prevailed.
I am no fan of Facebook, but the purpose of an IPO is to raise cash for an enterprise, and I have to say it did this rather successfully, taking from the dumb money that thought it was going to be the smart money by flipping its allocation to what it regarded as the dumb money.
Presumably the patch was certified. If so, clearly certification means nothing because it didn't catch saved file corruption differences between versions, which would be one of the primary things certification should test. He should ask for his certification payment back.
Certification by the platform vendor should check that the game correctly uses the platform, but it cannot check that the game correctly implements its own semantics - that's a job only the game developer has responsibility for. This case concerns a file intended to save the state of the game so that it can be resumed from that state. In some cases, the file is incorrectly written, so the game resumes in an unintended state. You can only tell that this is buggy behavior if you understand what was supposed to happen: comparing the file to the one written by the previous version is not a valid test, because the point of a patch is to change some aspects of the previous version's behavior, and how, in general, is the platform vendor supposed to tell which differences between the versions are intended and which are errors?
A mixture of autonomous and human-controlled vehicles presents the problem that a subset of the drivers in the mix will game the system, recklessly cutting-off any vehicle they believe is under autonomous control, if it's to their advantage (or because their assholes tell them to do it.) Drivers in the NYC metro area might well believe this would be indistinguishable from the current situation, but I imagine it could be worse.
This would be a problem with both full-time and emergency-only autonomy, but it might be easier to identify the autonomous vehicles in the former case, by observing how they are driven.
Slashdot Mirror
If you tried to bake a cake with a recipe and/or knowledge of what ingredients go into a cake and how to put them together, but mis-measured the eggs/used high-protein flour and so ended up with a shitty cake I would cry no-true-Scotsman when someone said you weren't making a cake.
This is quite ironic, considering your sig:
Analogies don't equal equalities, they are merely somewhat analogous.
This is not a useful analogy of the one-time-pad issue, because in that case, the distinction is not predicated on an ad-hoc definition.
The essence of the no-true-Scotsman fallacy is its arbitrary and entirely self-referential circularity: the definition of trueness implicitly adopted by the fallacy's maker is exactly that which (in his mind) makes his argument true - nothing more, nothing less. In particular, it is not derived from any consideration beyond the fallacious argument, and it is not a useful definition in any wider context.
You claim that it is a no-true-Scotsman fallacy to say that an encryption key is not a one-time pad if it is used more than once.
Firstly, it is important to note that this is a narrow claim about semantics: what, exactly, can the the phrase 'one-time pad' be used to denote? It is not a claim about encryption (even though it is made in the context of encryption) because the facts of encryption do not depend on whether this claim is correct.
For your claim to be correct, the assertion 'an encryption key that has been reused is not a one-time pad' must be ad-hoc, introduced solely for the purpose of making an argument look valid, but it is the opposite of that. As you yourself point out, non-reuse is essential to the purpose for what one-time pads are created and used, so the assertion is predicated on a very meaningful distinction. Therefore, it is not a no-true-Scotsman fallacy.
You may think you are still right on the usage issue. Rather than take a position on it, the rest of us can ignore it, because we can make ourselves perfectly clear to one another by considering the context in which the phrase is used. In particular, your original claim that the citation (about the security of one-time-pad-encrypted messages) was incomplete is still wrong, as it very adequately covered the ways in which a key intended to be a one-time pad can be misused.
Strictly speaking, Venona was the project to decrypt the intercepted messages, started once it was realized that the encryption keys were being reused. Nevertheless, MrNaz is adopting troll-like behavior in his snarky and cryptic post, and his post here, unlike yours, contributes nothing to the discussion.
Yes, otherwise there is no possibility of consider improper use at all.
But the possibility of improper use is considered in the citation that you questioned, through its very explicit list of conditions that must be met for the encryption to be unbreakable. You are being pedantic in an attempt to cover a mistake you made, but we can all see that the citation was satisfactory (it contained sufficient information for its purpose), and therefore that you were mistaken (or shall we say pointlessly pedantic, if we are being pedantic?) to say the citation was incomplete.
While watching "The Diving Bell and the Butterfly", it occurred to me that knowing morse code would give you the best chance of communicating from this frightening state.
There's nothing wrong with your view, and it is one that the younger me would have endorsed, but it turns out that the range of music I like keeps on growing, without any effort on my part, and without making myself suffer through music that I am not enjoying. My collection of recorded music goes largely unplayed these days, as I often find it more satisfying to listen to something I have never heard before.
Covering it in the EULA does not necessarily make it either reasonable or unremarkable.
As Flynn demonstrates, a typical IQ test question on the abstract reasoning “Similarities” subtest might ask “How are dogs and rabbits alike?” While our grandparents were more likely to say something along the lines of “Dogs are used to hunt rabbits,” today we are more likely to say the “correct” answer, “Dogs and rabbits are both mammals.” Our grandparents were more likely to see the world in concrete, utilitarian terms (dogs hunt rabbits), but today we are more likely to think in abstractions (the category of “mammal”).
This is claimed to be evidence for Flynn's argument that we have shifted to more abstract thinking. A simpler explanation would be that more people today have been taught that dogs and rabbits are both mammals, and are simply recalling that fact, which doesn't call for abstract thinking.
I do not know if this is a poor example for making Flynn's case, or an indication of its weakness.
The article tells us nothing about whether the change can be attributed to the slimming of a fat tail on the low side of the distribution in test-scoring ability. My understanding is that the renormalization of scores is done under the assumption that the underlying distribution is Gaussian-normal, an assumption that seems to be at least somewhat controversial. Could this practice be hiding evidence that could help explain the effect?
Another novel in which analytical engines play a part.
How is it not compression? It reduces the data size being transferred and is recoverable on the other end. Maybe I'm not an expert, but isn't that _exactly_ the definition of compression?
While I agree with the people who say that it is not data compression, it is also worth noting that the question is beside the point - you may as well say 'it is communication' as if the fact that something of that nature has been done before renders it irrelevant. The point is that it is a clever, useful and significant extension to the state of the art.
I think they are simply saying that the count is not statistically significant, as it is at about the background level of the clean room they are working in, and three of the four types identified match contaminants on the equipment.
The exposure wasn't in password STORAGE, it was in password LOGGING.
This case shows that in the context of security, that is a distinction without a difference.
...So the title here, in the BBC website and some of the comments are way off.
I think your analysis makes some valid points but is somewhat complacent. Firstly, I am not convinced that the concept of a corner case is valid in security matters; attackers do not randomly stumble upon vulnerabilities, they assiduously seek them out, and a great many exploits are based on 'corner cases'. If you were ripped off to the extent of your credit limit, would you dismiss it as just a corner case?
The fact that 'card-not-present' fraud went up is hardly surprising, and not much of an indication that EMV is secure; criminals will naturally chose the easiest attacks, especially before they have had time to test the new technology. As the "card-not-present" window closes, EMV will come under greater attack, and then we will get a better idea of how secure it is in practice.
It is not particularly helpful to say that EMV is secure but the implementation is faulty, as it is useless without implementations. You might as well say that the cliff-edge is safe because it is hitting the ground that kills you. The backers of EMV have to take control of the whole development and implementation process for it to be trustworthy: as far as security is concerned, half a fence is no fence.
Whenever errors start showing up, it is reasonable to assume that they are just a sample of the problems that are out there. When dumb errors start showing up, it is reasonable to assume that the implementation was in the hands of people who did not try too hard to do it right, and who probably could not have done a good job if they tried.
The dissembling and apparently complacent response of the banks to these disclosures underlines the researchers' point (made in an earlier paper) that the banks' stated primary goal of chip & pin is to divest themselves of the cost of fraud. I find it disturbing that in many cases they have been able to pass the cost on to customers without producing transaction logs that might have vindicated the customer. This is a social rather than technical issue, but all security issues are, to a degree. It is only through the possibility of costly sanctions that we can realistically expect the banks to give customer security its due attention.
That's right, this is at least the second independent way Chip & Pin has been found to be broken. The banks claim to have multiple layers of security, but what they actually have are multiple breaches of security.
Another reason for collapsed blocks of code are often that a class or method gets so big, you need to collapse out code to have any oversight. But you can also very easy split a big class in multiple classes (composition) or split a big method into smaller. For example, if you have one big method, then you can very easy put that method in a new class and use composition.
Factoring can definitely be taken too far. If you were to convert every block into a method, you would have a great many methods with long argument lists, and it would be difficult to come up with meaningful names for these methods, as each block's purpose is so closely tied to the context in which it appears. You would end up with code that jumps around so much that it would be very hard to see what it does. This happens, and there have been many times when I would have liked a composing tool to convert a deeply-nested tree of tiny methods into a sequentially-readable algorithm.
I think you are missing the point that comment- and block-collapsing within an editor/viewing is temporary and reversible. You can start by reading the comments, but once you understand them, you might want to collapse them selectively to get a better look at the code. Think of it as a form of variable and adaptive abstraction (the root of the word abstraction is the Latin for 'draw (pull) away'.) Hiding exception-handling blocks can be helpful, too, so long as exceptions have been used correctly and are not used for control flow in the normal execution of the algorithm.
True, but documentation can also be achieved by other means than just comments.
Comments are still useful as a link from the code to the relevant part of the documentation, in cases where there are some non-obvious issues being attended to.
What you describe seems to be close in spirit to Knuth's idea of Literate Programming (though not his specific implementation of the idea.)
Stop using comments for everything. I just counted from the Slashdot posts here what comments are all for: For Bug-Tracker, Documentation, Source Control System.
You correctly identify the first and third uses of comments as being wrong, but for alerting the reader to the fact that there is some non-obvious reason behind the design of some section of code, there is no better way than using a comment. Even if the design is documented elsewhere (as it should be), a reference to the appropriate part of the documentation placed in the relevant parts of the code is very helpful in preventing someone overlooking it. This is particularly helpful for cross-cutting concerns that are not localized to one part of the code.
You need to understand that comments are only for one entity only: for the developer as a human. For the compiler comments are just non-existent. They don't have a syntax, they don't compile and they don't run.
This is completely irrelevant, because the whole reason behind high-level languages is for them to be human-readable. The goal is to make the program more understandable to human, but a language that has the necessary and sufficient syntax to be compiled is insufficiently expressive to explain the reason for its existence and the intent behind its writer's choices (for example, showing that code is secure often involves proving certain theorems about it.) This requires additional, non-compilable documentation, and once again, comments are the best way to alert the reader to these facts, even if (or preferably) only as references to external documentation.
Perhaps you are one of those people who believe that all code can be self-documenting? If so, then before you ever use or assert this opinion again, please complete this exercise: implement the quicksort algorithm in the language of your choice in such a way that the code alone clearly explains 1) a proof of its correctness, and 2) a proof that it is O(n lg n) on average but can be O(N^2) in the worst case. (that's just the starter: there are many more difficult problems, some involving concurrency and security, if you complete this one.)
If you start writing a comment like: This algorithm must run in 50ms and needs to assume that corner-case and that issue. Then why are you not writing a test that ensures just that?
Writing a test would be the right thing to do, but why stop there, when you could also add a comment? The criterion being tested for is a fact that you must necessarily know before you write the test, and before you write any code that is specifically designed to satisfy it. You, as author, have this knowledge, and you also know what steps you took to ensure the code satisfied the requirement. The subsequent reader initially does not know any of these things and needs to learn them. It seems that your preferred way is to set a trap in the form of a test that is triggered if they happen to unknowingly violate the rule, as if it were some sort of dungeons-and-dragons game. If this is the way you work, I would hate to have to read your code, and I would never contract you to write any.
Perhaps you are one of those people who believe that all testing code can be self-documenting? Because testing can, in general, require Turing-equivalence in its implementation, my comments about self-documenting code apply here. Furthermore, there is the question of knowing which tests cover which parts of the code, which is not necessarily obvious, especially where the issues are cross-cutting concerns such as concurrency, security and performance. Finally, you should be aware that no amount of testing can prove the correctness of code. Let us suppose you have developed some tricky aspect of the code through a reasoned argument for its correctness, as is often the case for security issues. No amount of test cases will serve to explain to the reader the logic by which you derived the implementation. Perhaps you
Good code can show what is being done, but it can't show different approaches which were rejected. Comments can explain why certain shortcuts are valid or not valid in a way which won't be obvious from the code.
to which you replied:
No, that is for what tests are.
Suppose you have a situation where, because of the unusual distribution of the data, what would appear to be an obvious implementation would actually be inefficient. What are you going to do - write a test that times the execution of the code on a large sample of data? Even if you did, it would be inordinately and pedantically obtuse not to make mention of the issue with a comment in the code. We cannot assume that it will be obvious that this test refers to this particular algorithm (for example, due to cross-cutting concerns such as concurrency, the implementation may not be localized to a module), we cannot assume that the reason why there is a problem will be obvious from the test, and we cannot assume that there is an efficient way for the person reading the code in question to determine which tests' results are influenced by it, and therefore which tests should be read in conjunction with the code.
As Zero_Kelvin also mentioned, tests don't explain why the code was written the way it was, and what I have presented above is just one example that should make this point clear to anyone (I'm assuming that you would not allow comments in the test code, as that would seem to defeat your purpose.) Understanding code is hard enough without its author turning it into some sort of puzzle that can only be solved by deducing the intent of the author through an examination of the tests he wrote for it.
I find it difficult to believe that believers in self-documenting code understand how much, and what sort of information goes into the writing of software, and therefore I find it difficult to believe that they can do it effectively.
My opinion on hide or collapse stuff is very easy: it's a bad idea. Sooner or later developers will hide a lot of stuff, code, comments, it's like why it is a bad idea to hide stuff under the carped: clean up your room and not hide the dirt under the carpet.
The judicious hiding of information is what abstraction is all about, and abstraction is the main technique we have to cope with the complexity of software. It only works if the hidden stuff has well-defined semantics, and to communicate those semantics we need documentation that is at a higher level of abstraction than code.
In order to not only publish anything, but get a study through initial approval stages you have to do comprehensive review of existing work.
So are you saying that any student who has had a research topic approved has already demonstrated adequate background knowledge, either simply by getting that study approved, or at least will have done so by the time it is published? I may well be mistaken, but I thought the scope of graduate education was rather broader than that needed to complete a specific research project, no matter how deep and thorough its preparation was.
Is there any reason to believe that the problem is any worse at Coursera than at meatspace universities?
If it were 'only' at the same level as at degree-awarding universities, it would still be a puzzle: why do they bother to do so? Finding out why some people do take the time to plagiarize their way through a Coursera course might help in understanding plagiarism elsewhere, and also into the Dunning-Kruger effect and what seems (to a curmudgeon like me) to be an increasing culture of self-deception in general. On the other hand, perhaps it's mainly an occasional response to a deadline that the student can't meet, either for unexpected external reasons or poor planning on their part.
Frequent comment I hear is "I wish I didn't have to do all the busy work and could just focus on my research" when I talk about school to my SO. .
For the SO in this case, who may well have a comprehensive knowledge of the larger field, the non-research coursework may well be busy-work, but I doubt that this is the case for most students. If graduate students focused solely on their research, this would exacerbate the current problem of researchers not always being aware of relevant established results and current research topics. Journals and conferences exist to spread this knowledge, but to be effective, their participants need to be familiar with of the state of the art in the broader field.
right now it is breaking under the weight of a valuation...
Facebook is hardly breaking. It continues to do its business, bringing in the cash and growing at what would be an extremely fast rate by normal standards. While a falling stock price would normally be an indication of something being amiss, in this case it is merely a follow-on from the irrational exuberance of the IPO -- and, thanks to that exuberance, it is in a stronger position financially than if rationality had prevailed.
I am no fan of Facebook, but the purpose of an IPO is to raise cash for an enterprise, and I have to say it did this rather successfully, taking from the dumb money that thought it was going to be the smart money by flipping its allocation to what it regarded as the dumb money.
Presumably the patch was certified. If so, clearly certification means nothing because it didn't catch saved file corruption differences between versions, which would be one of the primary things certification should test. He should ask for his certification payment back.
Certification by the platform vendor should check that the game correctly uses the platform, but it cannot check that the game correctly implements its own semantics - that's a job only the game developer has responsibility for. This case concerns a file intended to save the state of the game so that it can be resumed from that state. In some cases, the file is incorrectly written, so the game resumes in an unintended state. You can only tell that this is buggy behavior if you understand what was supposed to happen: comparing the file to the one written by the previous version is not a valid test, because the point of a patch is to change some aspects of the previous version's behavior, and how, in general, is the platform vendor supposed to tell which differences between the versions are intended and which are errors?
A mixture of autonomous and human-controlled vehicles presents the problem that a subset of the drivers in the mix will game the system, recklessly cutting-off any vehicle they believe is under autonomous control, if it's to their advantage (or because their assholes tell them to do it.) Drivers in the NYC metro area might well believe this would be indistinguishable from the current situation, but I imagine it could be worse.
This would be a problem with both full-time and emergency-only autonomy, but it might be easier to identify the autonomous vehicles in the former case, by observing how they are driven.