i051101a: What Programmers Know

Status	Date	Description





	2006-01-30	Bertrand Russell's experience on being shown Euclid by his brother is important to the noticing of the working of mathematics. [not because it is right, but because it is successful]
	2006-01-30	The use of word problems in the teaching of elementary mathematics is an interesting case of working computations, without it being distinguished as such.
	2006-01-30	I need another piece on the working of computation that goes through the execution model and establishes the difference between purposive use and what the computation is unto itself. "How Computation Works."
	2006-01-30	Remove any of these that belong entirely in "What Computers Know." Leave everything else here to be dealt with, including moved elsewhere.
in progress	2005-11-11	Begin siphoning material that belongs in "Execution Architecture" over to folio i051001 too.
	2005-11-13	I want to add a note on "A UML Interpretation Dependency" and deal with the «interpretation» arrow and why I arranged it the way I did. This is worth being a little article on its own, with tying into Execution Architecture and related material by reference. (Something similar may happen with "A UML Manifestation Dependency."
	2005-11-13	Look at how not to deep end in Figure 4, and maybe move it down where it is presented incidentally, with more detail elsewhere now that I have what I have.
	2005-11-11	From #48.100-101 I am back to "admit" and "interpret" and "manifest" and I need to tie down some of this in the TROST Glossary. There is a valuable use of "realization" from Hilary Putnam too., and representation from Fred Brooks.
	2005-11-10	Find ACM doi for (Parnas 1985) and also find how (Brooks 1986) uses it.
	2005-11-09	harmonious in the sense of "showing accord" and there are also great terms like concordant, consonant, and congenial. I like the notion of the congeniality of nature! Amenability might be what I am looking for too [seems to involve some active participation, however, and I want an indifferent amenability]. To accord, as to bestow something on something is also interesting here.
	2005-11-09	To invest (that is, to dress up) something looks rather appealing, reflecting as it does on the clothes having no emperor (I love that) and there are the senses of giving something a quality or characteristic, or endowment. I would like to say that the endowment is a property of the thing, and I need to give up that, since it is always relative to our view, however harmonious the coincidence is.
	2005-11-09	The verb "to afford" is related to the Old English "to further." I am struggling to figure out what to do with "affordance" and how artifacts and objects afford or serve to manifest some conception, afford some usage.
	2005-11-09	I need to use manifest (verb) and manifestation in conjunction with the amenability of an artifact or behavior for our apprehension [conception formed by observation or experience] of an abstraction as if embodied by/in it. This must not be confused with a bill of lading or list of cargo or passengers (the noun sense of the word and only one of the verb senses, in English). I mean by manifest, being apparent, noticeable, revealed, and exhibited (I'll avoid expressed for now, I think).
	2005-11-09	In my 2005-11-06 TROST Discussion response to band about the Dyson article, I added in some concerns about the desire to have computers that think like we do when we are completely clueless how we think the way we do. This reminds me that there is an angle on this (for PvC in the BlunderDome) as part of my "trip report" on Code Camp. ~~I also need to go to their site and turn in my appraisals.[done 2005-11-09]~~ I also raised the notion of emergent intelligence/power through interactive behaviors and that is something for "Things to Notice, Things to Ponder" (obviously an evolving working-title [;<).
	2005-11-09	"Computers have been getting better and better at providing answers - but only to questions that programmers are able to ask." is a great bridge to "What Programmers Know." The quote is from George Dyson's "Turing's Cathedral", http://www.edge.org/3rd_culture/dyson05/dyson05_index.html, a link provided in a note from band on 2005-11-06 and filed under TROST Discussion.
	2005-11-09	I need to figure out where to deal with Church's Thesis and also introduce it in a way that relates to this situation. Band points out a need there in his 2005-11-07 TROST Discussion note from him.
	2005-11-09	Bill's comment about relationship to Turing and such in an e-mail exchange got me thinking about "Identifiers Computers Know" and what that tells us about "identification" via language. I have an outlinish note about that at #48.98. Some of this can be hinted in the "Things to Notice" section. Then there need to be further posts/articles and bridging to Numbering Peano on the matter.
	2005-11-08	From today's call with band: The current page will have the details of the critical ideas and detailed sketch. The blog post will provide a synopsis with the key points illustrated, and then that will be used as the basis for a synopsis of the key ideas on the cover page of the folio, so that it can be cited in either place.
	2005-10-26	Get a picture of Teh Amor doing something odd with balance and leaping or even being on my shoulders.
	2005-10-26	I'm reconciled between my characterization of the computer as a pure "doer" and what's in Winograd and Flores. I am looking for inherent qualities of computational models that basically guarantees a class of breakdowns. However, the at-handedness and all of that is certainly accurate, and the breakdowns can be either in a disconnection in the world or in the way that generalizations and projections about the computation are defective. And mechanical failures, of course.
	2005-10-21	From #48.68: What we are limited to is with respect to the manifestation that comes from what the engineers and electronics do. [dh:2005-11-11 What I was getting at here has to do with how the "what it is" is expressed as an abstraction.
	2005-10-17	From #48.54: The only "meaning" to computation, for the computer, is what it does. Not what it's for. It's a pure doer. This may need reference to Winograd & Flores where this appears to be at odds with their approach. [dh:2005-11-10 I think I can be reconciled with them in the sense that this is indeed what shows up when there's a breakdown. I'll need to be careful, and it might only be touched on here, with more under What Programmers Know.]
	2005-10-15	From #48.52: An important concern for higher-levels of abstraction - "The higher the level at which one thinks, the more numerous the primitive thought-elements one has to deal with. So programming languages are much more complex than machine languages, and natural languages are more complex still. Higher-level languages have higher-level vocabularies, more complex syntax, and richer semantics." (Brooks 1995, p.224-225). Brooks includes the explosion of class libraries as part of the complexity. My corollary: "Natural language makes it easier to say what we want. It advantages us little in saying how we are to get the computer to give it to us."
	2005-10-15	From #48.52: On the incidental and the accidental: When you start from the incidental, you don't know what to keep. "Much of the complexity in a software construct is, however, not due to conformity to the external world but rather to the implementation itself." (Brooks 1995, p.212)
	2005-10-15	From #48.52: I have this note: Code Lies. That is fascinating. It is related to the incidental versus the accidental.
	2005-10-15	From #48.52: "The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult ... . No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." (Brooks 1986, p. 195). This may be tied to Parnas, we need to find out.
	2005-10-15	From #48.51: "... Even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact debugging the specification." (Brooks 1986, p. 193).
	2005-10-15	From #48.51: "The hard thing about building software is deciding what to say, not saying it." (Brooks 1986, p. 191) and "In most cases it is the solution method, not the problem whose specification is to be given." (Brooks 1986, p. 193).
	2005-10-15	From #48.50: Obfuscation of code is a perfect example about how any meaning in code having to do with the intended use in the world is entirely expressed on our behalf and has nothing to do with what the computer does with what we've written. The comments and choices of layout, nomenclature, etc., are not only meaningless to the computer, they have no significance at all.
	2005-10-15	From #48.50: The idea that "code rules" or is the source of the specification of what the program does with regard to the intended usage is bogus. I need to point to that and inquire into what was the actual expression and what was meant by it. For us, the decorations on the code matter. For the computer, only what we are actually telling it to do is what matters, and it has no idea what that's for and what it preserves that matters.
	2005-10-15	From #48.50: "Formality and formalism. It is very easy to be seduced by the notion that the theory explains and comprehends reality. It is not so. It is always hypothetical and contingent on factors that are usually not identified." (This could figure for the computer as well as for the programmer knowledge cases.)
	2005-10-15	From #48.50: "The enactment of a theory. But this is not what it is. Even this is what it is for. But what was done was a theory was deviced and the procedure conforms to the theory." I'm not sure what I'm getting at here, but this can inspire something pertinent perhaps under both Computers and Programmers.
	2005-10-15	From #48.50: Brooks on not knowing how to build it, but what to build [and vice versa?]
	2005-10-15	From #48.53: Conceptual integrity and the integrity of the computer operation with respect to "the problem." 1. The computer can't check it's work (beyond checking that it did what it was told). 2. It can't stand back and conclude that the instructions given to it are incorrect (with respect to what?). It can't determine that the data are erroneous (rather than ill-formed or inconsistent: it can't determine that the data may be an incorrect representation of the intended information).
	2005-10-15	From #48.53: "Representation is the essence of programming." (Brooks 1995 p. 103). [dh:2005-11-10 In the diagrams, E is for encoding or expression. The game is to come up with rules of interpretation of the encoding by us so that we can write (represent) what we want and have the intended interpretation be apparent. We do these two things together so well that we don't realize that the spontaneous interpretation is not inherent in the expression but an automatic practice of recognition and that we have learned to lay down marks that for us inspire the intended interpretation. Something like that.]
	2005-10-15	From #48.50: "Formality and formalism. It is very easy to be seduced by the notion that the theory explains and comprehends reality. It is not so. It is always hypothetical and contingent on factors that are usually not identified." (This could figure for the computer as well as for the programmer knowledge cases.)
	2005-10-15	From #48.50: "The enactment of a theory. But this is not what it is. Even this is what it is for. But what was done was a theory was deviced and the procedure conforms to the theory." I'm not sure what I'm getting at here, but this can inspire something pertinent perhaps under both Computers and Programmers.
	2005-10-15	From #48.49: Must make it clear that this isn't about numbers and arithmetic as it is about only being able to operate formally. Is this something to mention or is the approach close enough?
	2005-10-14	From notebook #48.48: "What it's like to merely follow instructions in a rapid and unbelievably-reliable way is remarkably useful. But the instructions and what they are about are far removed from the world of human concerns. There is a barrier that we don't know how to cross."
	2005-10-14	Missing context, and its social impact too. [dh:2005-11-09 My posting about this on 11-08 on OpenFormula is relevant here, as is the examination of how Excel and OOo 2.0 Calc record spreadsheet information.][dh:2005-11-10 my 10-25 Orcmid's Lair posting on What Programmers Do as a teaser for all of this is also relevent.]
	2005-10-14	Is there anything in Weizenbaum that applies here or is that more on the social aspects than the technical/empirical nature that we want people to confirm with the simple experiments
	2005-10-14	We need to deal with the instrumental use of computers and establish the notion of purposive use, along with affordance. [dh:2005-10-26 I should be able to knock this off. It reminds me of Fred Gruenberger, too.]
	2005-10-14	MacKenzie on the difference between the formal world and the contingent world and Dijkstra's (European?) faith in mathematics and logic as being in reference to the world somehow is maybe too much, though I would like something pithy to use.
	2005-10-14	Metaphor Shear, Leaky Abstractions, and Spolsky (and maybe Alan Cooper) may fit in here with regard to the dissonance that is revealed when the gap is exposed, the disruption of the user's conceptual model
	2005-10-14	Kant on rationality and rational choice being immediately available without thinking is something to dig into with regard to "Blink" but maybe not here
	2005-10-14	The early "Uncol"-oriented languages: Jovial, Neliac [and Niklaus Wirth], and AED-0. What about SLANG and T.B. Steel, Jr.?
	2005-10-14	Failure modes having nothing to do with the situated use. Explanations invented by programmers that assume facts not in evidence. The error-message discussions by Alan Cooper fit here too.
	2005-10-14	Failure modes and the amount of effort related to "failures" and how to get out gracefully
	2005-10-14	Computers doing almost-arithmetic is important in that common mistakes of programmers involves forgetting that and writing their code as if the computer does for-sure-arithmetic.
	2005-10-14	The UNCOL notion or the UNCOL diagram. Oh, we have come up with the reason that code translators don't work very well. These are also great examples, but pretty geeky. Still .... This could be a riff on the Computational Deployment diagramming material if not here, but it connects. [dh:2005-10-26 Find the date of the Uncol papers and effort, because I related it to the effort to create a universal document architecture on a different topic.]
	2005-10-14	GUI programs make the problem harder to see and are also a source of inarticulate narration (and hence the UML interaction diagram as explanation); the code is, oddly, even more distant at the program level because of the fragmentation of the process and not knowing what the relationship between output and input is (and say it better than that). [dh:2005-10-26 This is also a problem with Literate Programming and Aspect Oriented Programming. No matter how you cut it, you've cut it [;<). This came up in Code Camp in a side-chat with the guy who presented on Software Factories. I must post my "trip report" on code camp.
	2005-10-14	Grady Booch (and Don Knuth) on reading code
	2005-10-14	Kitchen science and the Feynman approach
	2005-10-14	Code obfuscation as demonstration that what the computer uses of the program code has little to do with what the program is for. All the symbolism is for us. This affirms the importance of narration and Ward Cunningham's observation in that regard.
	2005-10-14	Work in the "Articulate What Matters" video clip from Ward Cunningham
	2005-10-14	Work in the "CodeAsExpression" video clip from Ward Cunningham
	2005-10-14	Is this the place for the Dijkstra singularity?
	2005-10-14	Dig up Dijkstra on narration
	2005-10-14	The place that would sell you a product that is better and cheaper than any competitor's, if only they had some in stock
	2005-10-14	And even that does not address "suitability for purpose." But it makes perfect sense that suitability for all and any purposes is disavowed by software developers.
	2005-10-14	The business of narrating the intention and having defined behavior is critical in being able to distinguish what is and is not a defect.
	2005-10-14	Do we extend theory-building to challenge the fallacy in "code rules" and "the code is the model"?
	2005-10-14	Is this the place to introduce Peter Naur on Theory Building [dh:2005-10-15 Looks like it, or maybe in "What Programmers Know" as a follow-on. The Ward Cunningham clips, and the Harry Pierson statements about code as model need to be dealt with, but maybe not here.]
	2005-10-13	Work in the Einstein quote. [dh:2005-11-09 No, it doesn't apply here until we begin to deal with the abstract nature of the computer and the abstraction, theory, invested in the software.][dh:2005-11-11 But I didn't move this and maybe because I am still not sure. There is a relationship to what Einstein and Hamming have said.]
done 2006-01-30	2005-11-09	Siphon materials from "What Computers Know" to here as we prepare for version 0.50 of that folio. [dh:2005-11-10 include noting material in my notebooks too.]
done	2005-11-09	Customize all pages of the folio to provide basic placeholder structure
done	2005-11-09	Customize to support initial work items for "What Programmers Know"