The resolution appears to be there are two quite different worlds: First there is the world of peer-reviewed research papers in computer science where the goal is to present knowledge that is new, correct, and significant and that sometimes results in code. And second there is the world of commercial computing that is heavily about just code. But these two worlds are very different. In particular, the research papers are not trying to document or describe code. Moreover, in the knowledge presented in a research paper, that knowledge is supposed to be in the form of text, possibly with some math, but not in code. E.g., the original paper with heap sort didn't need code; Knuth's presentation of heap sort in TACP has only a little code, in his language MIX which few people bother to understand, that is not essential.
"Is the math supposed to be clearly explained in text or just the starting conditions from which the rest of the formulae just tell the story for you?"
Again, you are asking too much from the math. Again, 'math' is supposed to be written in complete sentences. In particular there is no 'new language'. I illustrated with F = ma: You are supposed to get nearly all "the story" from the text and not the equations. Well written math doesn't ask a reader to get "the story" "just" or even primarily from the equations. If you don't want to accept this description of good writing in math, then so be it, and our main difference will be right there and not "all over the place".
Again, yet again, once again, the knowledge is supposed to be in the text, in well written paragraphs, in complete sentences, and there is no 'new language'. For an equation such as F = ma, that is a part of speech, a noun. And again, yet again, the surrounding text is supposed to be so good that the equation is hardly needed. Again, yet again, one more time, please read it this time, you are not supposed to have to dig the meaning out of the equations in more than a peripheral sense.
"Moving on to DNS having security holes and other problems with protocols made with reference implementations -- how is this relevant?"
Because, again, the code, including in a 'reference implementation', doesn't mean anything. We shouldn't ask to determine correctness, or even the quality of the design or engineering, just from the code, not even code with mnemonic identifier names and many in-line comments. The 'relevance' is that we see that the DNS code had security problems, that is, was not high quality design or engineering, and the reason for those problems is that high quality design and engineering are in text and NOT in code. So, with just the code, we have no solid, rational support of the quality of the design or engineering. Instead, about all we have is the code. Then to know if the code has high quality, we just deploy it and wait for the bug reports. Then we study the code, see where the problem is, patch the code, deploy it again, and wait for more bug reports. NOT good. NOT high quality design or engineering.
We do NOT design or engineer airplanes like in a 'reference implementation' of DNS. Instead, before the plane carries passengers, we have a mountain of rock solid engineering, heavily in text, saying that the plane is safe. We do NOT primarily determine the safety of an airplane by putting one million passengers in it. In DNS, we determined the quality of the work primarily by deploying it, using it in real networks, getting the bug reports, and then fixing the bugs. So, the DNS engineering was shoddy work compared with nearly all of the rest of engineering.
Broadly we just cannot expect to have delivered high quality software when what is delivered is mostly just the software. Instead, the quality has to be in a document almost entirely in text. In high quality? Yes. In common commercial practice? No.
Fundamentally it is the text that really matters, NOT the code. Again, yet again, given the text, the code is supposed to be routine. This holds in 'research level' 'knowledge'. Sure, this doesn't hold in routine commercial practice.
"Lots of scientific papers get published that later turn out to be wrong, whole fields of study sometimes look really good and push our understanding of the world but ultimately go away as 'the wrong approach'. This is just progress,"
No, you are not describing "progress" but are describing just mistakes, that are sometimes costly, and are to be avoided strongly.
"When you say the 'knowledge of a paper' should stand on its own, without the need for the circuits, code, etc to understand it -- this is true of many fields, but not true when the paper is about the circuit, the code, etc."
No, not really: We're talking about peer-reviewed research publications of 'knowledge'. That 'knowledge' is not really supposed to be about the circuit or the code. Instead, the circuit or code are supposed to be routine implementations of the knowledge in the paper.
You want to elevate the circuit or code to the level of knowledge, and that is backwards and wrong. Your goal of elevating code to the level of knowledge and what is primary is not promising. In simple, blunt terms, so far without serious exceptions, 'knowledge' is communicated in text, possibly with some math, in a natural language. That's all we've got. There ain't no more.
"Then that very thing should indeed be presented, otherwise no amount of text will properly explain it, other than a 1000 words where a picture would suffice."
In the communication of knowledge, we don't depend primarily on pictures, figures, diagrams, schematics or code. Instead we communicate knowledge in text, possibly with some math. Again, good examples are in books by Knuth, Ullman, Sedgewick, etc.
Again, yet again, once again, please try actually to read it this time, there has been a long tradition in math that there should be no diagrams or pictures at all, not even in vector calculus. Much of the motivation was to have the discipline to make SURE that the content was in text, just text, with some math, and NOT in pictures. Again, we didn't want the content to be in pictures. This point is SERIOUS about keeping up the quality of the material.
For pedagogy, a picture can be terrific, but 100% of the content should also be in the text.
"As for your famous lab scientist -- why is it ok that he wants to make notebooks and other lab stuff available, but when we ask for code to be put in a public repo when reviewing papers we are suddenly breaking knowledge?"
We're not. Put all the code in public repositories you want. Put in 1000 KLOC. Fine with me. But the code in the repository is not going to be part of the paper, e.g., it will not be reviewed in the peer-review process. Moreover, the paper just MUST make sense with no reference at all to the code. Again, the code is NOT the knowledge or the subject of the research paper. Again, the paper is NOT about the code; it is not a paper describing the code; the code is not the 'contribution to knowledge'. Instead, the code is at most a hopefully routine implementation of the knowledge in the research paper.
"No matter what you say about text being the only way to transmit knowledge, there are plenty of occasions where a simple digram transmits much more meaning to me than reams of text, I am visual thinker and learner."
Fine. So are many people. But such ways of 'transmitting knowledge' are NOT what we are talking about. We're talking about peer-reviewed research papers. Tutorial presentations can be very different. Movies are very different. TV is very different, even some of the TV cooking shows that try to be instructional are very different.
Maybe the main point of misunderstanding is, practical computing is nearly all about code, just the code, and, thus, you have accepted that computer science research papers can be about describing code. No. Instead, for such papers, any code is supposed to be just an implementation of the knowledge in the research paper and routine. The knowledge in the research paper is NOT 'code'.
The knowledge in a peer-reviewed research paper is supposed to be rock solid, and, again, yet again, we don't communicate that with pictures or code.
Pictures and code? In tutorials, fine. In commercial work, sure. In research papers, only a few lines of 'pseudo-code' in a picture that is not essential to the paper. Understand now?
"Is the math supposed to be clearly explained in text or just the starting conditions from which the rest of the formulae just tell the story for you?"
Again, you are asking too much from the math. Again, 'math' is supposed to be written in complete sentences. In particular there is no 'new language'. I illustrated with F = ma: You are supposed to get nearly all "the story" from the text and not the equations. Well written math doesn't ask a reader to get "the story" "just" or even primarily from the equations. If you don't want to accept this description of good writing in math, then so be it, and our main difference will be right there and not "all over the place".
Again, yet again, once again, the knowledge is supposed to be in the text, in well written paragraphs, in complete sentences, and there is no 'new language'. For an equation such as F = ma, that is a part of speech, a noun. And again, yet again, the surrounding text is supposed to be so good that the equation is hardly needed. Again, yet again, one more time, please read it this time, you are not supposed to have to dig the meaning out of the equations in more than a peripheral sense.
"Moving on to DNS having security holes and other problems with protocols made with reference implementations -- how is this relevant?"
Because, again, the code, including in a 'reference implementation', doesn't mean anything. We shouldn't ask to determine correctness, or even the quality of the design or engineering, just from the code, not even code with mnemonic identifier names and many in-line comments. The 'relevance' is that we see that the DNS code had security problems, that is, was not high quality design or engineering, and the reason for those problems is that high quality design and engineering are in text and NOT in code. So, with just the code, we have no solid, rational support of the quality of the design or engineering. Instead, about all we have is the code. Then to know if the code has high quality, we just deploy it and wait for the bug reports. Then we study the code, see where the problem is, patch the code, deploy it again, and wait for more bug reports. NOT good. NOT high quality design or engineering.
We do NOT design or engineer airplanes like in a 'reference implementation' of DNS. Instead, before the plane carries passengers, we have a mountain of rock solid engineering, heavily in text, saying that the plane is safe. We do NOT primarily determine the safety of an airplane by putting one million passengers in it. In DNS, we determined the quality of the work primarily by deploying it, using it in real networks, getting the bug reports, and then fixing the bugs. So, the DNS engineering was shoddy work compared with nearly all of the rest of engineering.
Broadly we just cannot expect to have delivered high quality software when what is delivered is mostly just the software. Instead, the quality has to be in a document almost entirely in text. In high quality? Yes. In common commercial practice? No.
Fundamentally it is the text that really matters, NOT the code. Again, yet again, given the text, the code is supposed to be routine. This holds in 'research level' 'knowledge'. Sure, this doesn't hold in routine commercial practice.
"Lots of scientific papers get published that later turn out to be wrong, whole fields of study sometimes look really good and push our understanding of the world but ultimately go away as 'the wrong approach'. This is just progress,"
No, you are not describing "progress" but are describing just mistakes, that are sometimes costly, and are to be avoided strongly.
"When you say the 'knowledge of a paper' should stand on its own, without the need for the circuits, code, etc to understand it -- this is true of many fields, but not true when the paper is about the circuit, the code, etc."
No, not really: We're talking about peer-reviewed research publications of 'knowledge'. That 'knowledge' is not really supposed to be about the circuit or the code. Instead, the circuit or code are supposed to be routine implementations of the knowledge in the paper.
You want to elevate the circuit or code to the level of knowledge, and that is backwards and wrong. Your goal of elevating code to the level of knowledge and what is primary is not promising. In simple, blunt terms, so far without serious exceptions, 'knowledge' is communicated in text, possibly with some math, in a natural language. That's all we've got. There ain't no more.
"Then that very thing should indeed be presented, otherwise no amount of text will properly explain it, other than a 1000 words where a picture would suffice."
In the communication of knowledge, we don't depend primarily on pictures, figures, diagrams, schematics or code. Instead we communicate knowledge in text, possibly with some math. Again, good examples are in books by Knuth, Ullman, Sedgewick, etc.
Again, yet again, once again, please try actually to read it this time, there has been a long tradition in math that there should be no diagrams or pictures at all, not even in vector calculus. Much of the motivation was to have the discipline to make SURE that the content was in text, just text, with some math, and NOT in pictures. Again, we didn't want the content to be in pictures. This point is SERIOUS about keeping up the quality of the material.
For pedagogy, a picture can be terrific, but 100% of the content should also be in the text.
"As for your famous lab scientist -- why is it ok that he wants to make notebooks and other lab stuff available, but when we ask for code to be put in a public repo when reviewing papers we are suddenly breaking knowledge?"
We're not. Put all the code in public repositories you want. Put in 1000 KLOC. Fine with me. But the code in the repository is not going to be part of the paper, e.g., it will not be reviewed in the peer-review process. Moreover, the paper just MUST make sense with no reference at all to the code. Again, the code is NOT the knowledge or the subject of the research paper. Again, the paper is NOT about the code; it is not a paper describing the code; the code is not the 'contribution to knowledge'. Instead, the code is at most a hopefully routine implementation of the knowledge in the research paper.
"No matter what you say about text being the only way to transmit knowledge, there are plenty of occasions where a simple digram transmits much more meaning to me than reams of text, I am visual thinker and learner."
Fine. So are many people. But such ways of 'transmitting knowledge' are NOT what we are talking about. We're talking about peer-reviewed research papers. Tutorial presentations can be very different. Movies are very different. TV is very different, even some of the TV cooking shows that try to be instructional are very different.
Maybe the main point of misunderstanding is, practical computing is nearly all about code, just the code, and, thus, you have accepted that computer science research papers can be about describing code. No. Instead, for such papers, any code is supposed to be just an implementation of the knowledge in the research paper and routine. The knowledge in the research paper is NOT 'code'.
The knowledge in a peer-reviewed research paper is supposed to be rock solid, and, again, yet again, we don't communicate that with pictures or code.
Pictures and code? In tutorials, fine. In commercial work, sure. In research papers, only a few lines of 'pseudo-code' in a picture that is not essential to the paper. Understand now?