<p>We have before us a question that is apparently of very little interest to almost everyone:</p>
<blockquote>
<p>What makes this particular machine that is powered by electricity different from electrical machines that don't answer questions?</p>
</blockquote>
<p>We know that computers manipulate symbols. How do symbols touch the world and cause lights to go on, cars to turn left, nuclear missiles to leave their silos...? It seems like an interesting, important, urgent question, which is a deep part of the reality humans have constructed for a couple lifetimes. And, people, especially students and teachers of computer related subjects, yawn and look at their iPhones instead, perhaps to order something to be delivered. Or turn off the light they left on at home.</p>
<p>I am tempted to simply leave the world to its fate, except that I am stuck here with you, and your choices and knowledge affect my future. So I selfishly try to get you to wake up.</p>
<p>Someone said that <strong>systems with too many levels are difficult to reason about</strong>. It was probably someone in the CS field, so you can argue with them if you disagree. Someone else said that we learn from the concrete to the abstract, the particular to the general, simple to complex. All I am saying is that the point where symbols affect the physical world is pretty definite, and without that in operation, we wouldn't have to worry about things like missiles unintentionally leaving their silos, or automated cars hitting people. That seems to me like the place to start teaching, just like you start shop class in a shop. <em>Don't put your hand on that!</em> Sorry, back to what I was saying...</p>
<p>In the book <strong>Rationality</strong> by Steven Pinker, he says:</p>
<blockquote>
<p>The moral is that reasoning with logical rules at some point must simply be <em>executed</em> by a mechanism that is hardwired into the machine or brain and runs because that's how the circuitry works, not because it consults a rule telling it what to do. We program apps into a computer, but its CPU is not itself an app; it's a piece of silicon in which elementary operations like comparing symbols and adding numbers have been burned.</p>
</blockquote>
<p>If you don't think that this is the vital thing to know about a computer, I am not sure why, but you could take it up with him, as he is a more successful reasoner than I am.</p>

CC BY-SA 4.0
2022-01-17T06:26:42.370Z
At the CS level we could go over these points. But this is more meta than your original q and may better be there??
Rushi
CC BY-SA 4.0
2022-01-17T15:44:41.400Z
You cannot articulate an outcome advantage, so you instead ask, *isn't it good that someone cares about this?*   Was the original question largely rhetorical?  If so, then do not say that others could not persuade you because their reasoning was not sound, because in truth, you came to it with a closed mind and could not ever have been persuaded.  (There is real wisdom in some of these answers, and I hope you do come back to them in time and think about them more carefully.)
Ben I.
CC BY-SA 4.0
2022-01-17T15:45:27.363Z
That last comment was not to attack you, but to prompt you to honestly consider your motive in asking the question.  Were you trying to learn, or trying to persuade?
Ben I.
CC BY-SA 4.0
2022-01-17T15:47:33.370Z
Also, on a moderator note, if someone has attacked you (and not just your idea), please flag it. (Including, I suppose, my own comment above us if you believe it to be an attack. We have multiple moderators, and I certainly do not handle flags on my own work.)
Ben I.
CC BY-SA 4.0
2022-01-18T13:04:48.500Z
@BenI. I had originally asked this Question on Meta, and I wish that had been respected. As for me being able to be persuaded, no. See my comment to Flater's Answer where I mention Weather. This fundamental knowledge is not optional, it's the whole point of how computers got created. Somehow people have lost sight of this. It is baffling to me, like forgetting to realize that food dishes were made because we need calories, not to look good on the plate.
Scott Rowe
CC BY-SA 4.0
2022-01-18T13:35:07.143Z
@ScottRowe It's not a question about the governance of the site, so it's not meta.
Ben I.
CC BY-SA 4.0
2022-01-18T13:39:55.307Z
@ScottRowe That analogy is bizarre.  One is about *purpose* of the action, and the other is... not.  At all.  We did not create computers with the PURPOSE of making "five" operations.  You're examining an implementation detail at one level and declaring it to be the most important, most fundamental point.  It's important!  But it's one level of abstraction, and in spite of your protestations to the contrary, it's *not* where the physical meets the computational, and it never has been.
Ben I.
CC BY-SA 4.0
2022-01-18T13:58:03.847Z
You are keenly intelligent, but I find your inability to "see" even the most basic fact patterns and baby-basic facts about this topic frustrating to say the least.  You confidently assert things that are strictly and obviously incorrect, use those assertions to justify your position, and refuse to see otherwise simply because you refuse to see.  You have Made Up Your Mind.  This was never a reasoned discussion because you were never intending to be reasonable.  I find your intransigence frustrating, so I am going to disengage now.  I am done discussing this topic with you.
Ben I.
CC BY-SA 4.0
2022-01-19T03:10:57.057Z
I side with @BenI on the facts  (90%). And with Scott on the emotion 95% — if Sturgeon's law is a universal truth how come we don't apply it to CSE? ...whence it becomes a Meta-CSE question
Rushi
CC BY-SA 4.0
2022-01-29T04:46:22.190Z
Re new additions: Yes its true @ScottRowe : Some of the most significant innovators in CS have been motivated by AI considerations. Off the bat I can think of Turing, McCarthy, Minsky.  All these were primarily interested in AI but their contributions o far beyond. I particularly recommend Minsky's [Turing Award](https://amturing.acm.org/award_winners/minsky_7440781.cfm)
Rushi
CC BY-SA 4.0
2022-01-29T11:06:43.153Z
@Rusi Ok, I wasn't thinking about AI particularly. Rather Ada Lovelace's insight about representing symbols as numbers then conveniently meets a number handling tool, and a completely new world opens up. But that doesn't mean that the people blind to that stunning change-point will get it. I have a friend with 2 PhDs, a major book and 4 patents in information algorithms, but as far as I know everyone is ignoring her. "*See and see but do not perceive, hear and hear but do not understand*"
Scott Rowe
CC BY-SA 4.0
2022-01-29T17:16:25.083Z
If you think a CPU is not an app, explain to me what branch prediction is, prefetch streams, out-of-order execution. Transcendental function through look-up tables & iterative refinement. Hashing functions for address translation. Your CPU is full of algorithms that address the deeper levels, invisible to us.
Victor Eijkhout
CC BY-SA 4.0
2022-01-29T21:18:43.120Z
@VictorEijkhout Those things are not *necessary*. We need to start teaching with what really *must* be there, because it's the place to start. There was a really cool book by a ship captain called, "First you have to row a little boat". I don't see people in other fields with this delusion, early math doesn't suffer with the urge to impart Ramanujan's findings, or physics throwing General Relativity at early students. People in CS seem just very bewildered. Maybe they didn't learn the basics first?
Scott Rowe
CC BY-SA 4.0
2022-01-16T22:44:05.997Z
2022-01-29T02:49:48.143Z
2022-01-29T02:49:48.143Z
Scott Rowe
<p>Buffy Ben Victor Eijkhout all in different ways talked of levels.
Let me try enumerating them for you from established sources. (Summarizing for brevity)</p>
<p>Weste Eshraghian book on CMOS VLSI gives these levels</p>
<blockquote>
<p>Digital VLSI design is often partitioned into five levels of abstractions: architecture design, microarchitecture design, logic design, circuit design, and physical design. (going downward)</p>
<ol>
<li>Architecture describes the functions of the system.</li>
<li>Microarchitecture describes how the architecture is partitioned into registers and functional units.</li>
<li>Logic describes how functional units are constructed. eg ripple carry adder Or lookahead</li>
<li>Circuit design describes how transistors are used to implement the logic.</li>
<li>Physical design describes the layout of the chip.</li>
</ol>
</blockquote>
<p>Going upwards Tanenbaum's classic Structured Computer Organization (better in my view than much that followed) discusses the levels of a computer as follows: (going upward) Overlap deliberate</p>
<blockquote>
<ol start="4">
<li>Digital logic level</li>
<li>Microarchitecture</li>
<li>ISP</li>
<li>Operating system (system calls as a VM over ISP)</li>
<li>Assembly language</li>
</ol>
</blockquote>
<p>On the other side we can go further down and reach solid state physics -- of which I know even less than VLSI!
Wikipedia gives these main branches:
(I am guessing the descending order)</p>
<blockquote>
<ol start="9">
<li>electromagnetism</li>
<li>metallurgy</li>
<li>crystallography</li>
<li>quantum mechanics</li>
</ol>
</blockquote>
<h1>A special level</h1>
<p>For some reason or other you believe that some level (nearabouts ISP?) is very special.  The onus is on you to explain why</p>

CC BY-SA 4.0
2022-01-11T15:57:42.867Z
Computers work by magic. The "special level" that you talk about is the lowest level that any given person understands. Everything above that special level makes sense, everything below it is magic. Most of us just ignore the magic and get on with our jobs. I think the OP's goal is to bring the student's "special level" down to match his own. They don't need to understand anything at a lower level than that because everything below that level is the magic stuff that _he_ feels comfortable ignoring.
Solomon Slow
CC BY-SA 4.0
2022-01-11T16:13:05.527Z
@SolomonSlow Well one could add one more list upwards: Assembly, C, C++, Haskell, Idris, Lean. And (speaking for myself) my comfort zone ends below Idris. Between Idris (etc) and Lean (etc) the level gap is really special (IMHO) -- the Turing computable level. So its more like we inhabit a comfort zone neighborhood : lowest level I consider relevant to highest level grokkable to my wits!
Rushi
CC BY-SA 4.0
2022-01-11T16:13:41.087Z
Also I dont know a fig about solid state physics; though I studied some quantum physics in college. ie the knowledge is usually scattered hole-y. And I add C++ with some reservations... Dont believe OOP is much good to anybody-- students, teachers, professionals -- but C++ gives some things independent of OOP
Rushi
CC BY-SA 4.0
2022-01-11T16:56:26.363Z
@SolomonSlow Thank you. For me the important point is where the program level affects the physical world level. The goal is to reveal how the magic works. Then it's not magic anymore. Above there are levels, yes, and below there are levels, but right at that interface is the part that really demands an explanation. How a computer is different from everything else. Didn't you want to know that somewhere early on? Did you wait patiently for someone to get around to explaining it?
Scott Rowe
CC BY-SA 4.0
2022-01-11T17:48:13.890Z
@ScottRowe, My "special level" was the gate level. I have an armchair understanding of what MOSFETs and relays do. BJTs are magic, but I understand how they can be combined to make logic gates. Once I dug down the the point where I understood how to build a rudimentary computer out of  NAND gates, I felt like I "knew" how a computer worked. OTOH, modern, high-performance, multi-core, super-scalar, desktop/server/mobile-device CPUs are pure magic as far as I know, and I am content to write out magic spells (Python, Java, and C++ code) that summon them to do my dark bidding.
Solomon Slow
CC BY-SA 4.0
2022-01-11T18:00:35.403Z
And that kinda proves ScottRowe's point @solomonslow. There is point where it's as though the rubber hits the road -- you can hear the scream, smell the sulphur. We are all *explaining it away* rather than *conveying the magic*. For me a giddy point was scheme when I wrote functions taking and returning functions. And used that to actually grade my students without variables
Rushi
CC BY-SA 4.0
2022-01-11T18:06:32.597Z
If @ScottRowe says modern computer (teaching) has taken away the fun the mystery, I have to agree ... somewhat reluctantly
Rushi
CC BY-SA 4.0
2022-01-12T14:05:03.623Z
My "special level" is at the digital logic level.  Once I saw everything move to booleans, it all connected for me.  And in particular, it was the carry adder that was my big a-ha moment.  @ScottRowe's special level still left everything feeling like magic to me, because it didn't answer the basic questions about physicality.  What was memory?  How did a command *happen*?  How could a computer even receive a "command"?  How could a computer manipulate numbers when it only had wires?
Ben I.
CC BY-SA 4.0
2022-01-12T15:03:11.797Z
@Ben I guess the larger meta() point Scott is making is that we teachers dont bother enough this sense of magic. In fact a teacher passionate about some level would/could convey the magic of that level for any/every level. What Scott doggedly does not get (as Buffy and others said) is that the "physical level" is only physical into-quotes: there are no gates, just transistors, no transistors/wires as the schematic shows, just a doped silicon wafer. I was actually contemplating making a CW answer with sense of magic(s) which *I* can imagine. And others fill others. 3 answers! A bit much
Rushi
CC BY-SA 4.0
2022-01-12T15:05:20.717Z
(cont) See this ["old joke"](https://matheducators.stackexchange.com/questions/1403#comment8485_1403). OTOH what @ScottRowe does get better than most but communicates more emotively is that we are in a mess with all this ill-thought-through abstraction. Right now Ive spent half a day grappling with this: firefox refuses to open local files. And with a strange `File not found` error. Turns out ubuntu has moved firefox from apt to snap -- a new snazzy shiny abstraction which loves me so dearly it treats me as my own intruder! Dozens of such glorious progresses I - or anyone -- could recount...
Rushi
CC BY-SA 4.0
2022-01-12T18:34:42.537Z
@BenI. Maybe the Frank Herbert quote "*In lieu of red tape*" should be applied to runaway development of computer systems. I did say that there is NO magic, and so any mysterious aspects should be explained.
Scott Rowe
CC BY-SA 4.0
2022-01-16T03:17:23.227Z
@ScottRowe : Heh! An accept!! And for an answer that was not meant to be an answer. But maybe it can become one?? As I was musing above maybe I "CW it" (community wiki). And then everyone can express their "special level" from the place of their own passion?  More at meta...
Rushi
CC BY-SA 4.0
2022-01-16T03:34:47.947Z
Your Answer is the only one that referred to levels. My whole question was about the point where one kind of thing links to another kind of thing, where "greenness disappears". That's what is meant by Science, everything else is just blithering.
Scott Rowe
CC BY-SA 4.0
2022-01-11T15:46:31.287Z
2022-01-11T15:46:31.287Z
Rushi
<p>Why 5 operations when <a href="https://en.wikipedia.org/wiki/One-instruction_set_computer" rel="noreferrer">one suffices</a>???   (The <a href="https://en.wikipedia.org/wiki/One-instruction_set_computer#Instruction_types" rel="noreferrer">subsection of above</a> showing the more usual machine instructions as &quot;macros&quot; implemented in terms of that one instruction)</p>
<p>Being sparse and minimal is great. But before that you need to wonder what CS really is about.
Here's some quotes from computer scientists that help you clarify your thoughts on that</p>
<ul>
<li><em>Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science</em> <a href="https://en.wikiquote.org/wiki/Computer_science#S_-_Z" rel="noreferrer">Michael Fellows</a></li>
<li><em>I don't need to waste my time with a computer just because I am a computer scientist</em>  <a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1305.html" rel="noreferrer">Dijkstra</a></li>
<li><em>Machine -- imperates<br />
Programmer -- declarates<br />
Language</em> -- <a href="http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html#relevate" rel="noreferrer">relevates</a><br />
<a href="http://blog.languager.org/" rel="noreferrer">R Mody</a></li>
<li><em>Computer Science is a science of the artificial</em> Simon and Newell</li>
<li><em>Simplicity does not precede complexity, but follows it</em> Alan Perlis<br />
(Which is simpler an assembly language program or a scheme program?)</li>
<li><em>A programming language is low level when its programs require attention to the irrelevant</em> Alan Perlis<br />
(&quot;What is there?&quot; Vs &quot;What is relevant?&quot; which question is more important?  For teachers??)</li>
<li><em>The computing scientist could not care less about the specific technology that might be used to realize machines, be it electronics, optics, pneumatics, or magic</em> <a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD924.html" rel="noreferrer">Dijkstra</a></li>
</ul>
<p>Comes to the nub of the matter: You seem to think (things like) assignment are important to teach because they are &quot;there&quot;.</p>
<p>People of the opposite mindset neither believe its important to teach.<br />
Nor for that matter even &quot;there&quot; -- I've <strong>never</strong> seen a machine having anything like an assignment opcode. Registers, memory -- in a dizzying hierarchy of caches -- indirection, addressing modes, stacks, interrupts... I could continue.  But nothing remotely like assignment.</p>
<blockquote>
<p>Maybe more students would take an interest, and fewer would be fuddled about assignment and variables later if we just told them straight up how the blooming thing functions?</p>
</blockquote>
<p>Maybe... And a few determined teachers even succeed at this herculean task. Maybe you're one of them...</p>
<p>But many more students would be engaged and teachers satisfied if we threw the baby-bathwater-mess -- assignment+imperative programming -- out and taught how to leap further with more hi level declarative languages.</p>
<p><sup> JFTR: I consider OOP a bigger mess than imperative programming. Another subject...</sup></p>
<p>And let me give the last word to Dijkstra (again!)</p>
<blockquote>
<p>It used to be the program’s purpose to instruct our computers;<br />
it became the computer’s purpose to execute our programs.</p>
</blockquote>

CC BY-SA 4.0
2022-01-10T17:49:43.580Z
How do computers make decisions? How does a material object do that? No description that does not include physical and logical can properly answer. So, the physical must be part of it or you are just going in circles. I have no patience for that, I want answers that terminate in stuff I know that is indisputable. And I wanted that as a child also. Aren't you glad someone does?
Scott Rowe
CC BY-SA 4.0
2022-01-10T18:07:51.640Z
They dont; *you do*. Computers are no more "deciders" than my gpas old vacuum-tube radio. Just think: When you write a program; with one result you say: *Hurrah it works!* With another you say: *O hell; A bug!* You say: Do you notice?? **YOU** not the computer. If it could it would and thered be no bugs!
Rushi
CC BY-SA 4.0
2022-01-10T18:25:37.713Z
@ScottRowe Notice that your question *What is it about being in Academics that makes you not hear a simple question with a simple answer?* I already answered. More bluntly: Assignment is as unnecessary as ptolemaic epicycles were post Copernicus. How is it that when your question is answered you always dont hear?
Rushi
CC BY-SA 4.0
2022-01-10T19:04:24.800Z
How can a material object (a brain) make decisions? I should have gone in to Neuroscience, but programming humans is frowned upon.
Scott Rowe
CC BY-SA 4.0
2022-01-10T19:09:33.823Z
Someday soon the computers will 'notice' and we had better be ready.
Scott Rowe
CC BY-SA 4.0
2022-01-10T19:09:40.933Z
Who said brains decide?? I said **you** decide. If you want to identify yourself with some body part... Go ahead. However I'd recommend a look at Lakoff embodied cognition https://en.m.wikipedia.org/wiki/Embodied_cognition As one road to curing 4 centuries of Cartesian dualism
Rushi
CC BY-SA 4.0
2022-01-10T19:10:40.503Z
The mind-body problem enters stage right.
Scott Rowe
CC BY-SA 4.0
2022-01-10T20:13:26.430Z
So it isn't just the brain, it's lots of physical things involved. Restated: How can any conceivable partly physical system make decisions? It is easier just to stick with the original question, because it has already been answered by someone.
Scott Rowe
CC BY-SA 4.0
2022-01-11T04:44:22.473Z
@ScottRowe Since I gather what you're *really* grumbling about is [stratospheric abstraction in OOP](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/)
I added a clarifying aside on that though that's a quite different q. Also a new header in the hope that you will rethink your "five magic ops"
Rushi
CC BY-SA 4.0
2022-01-11T13:19:51.910Z
Joel said, "*Sometimes smart thinkers just don’t know when to stop*" I suggest you ponder that and come up with a concise answer instead of dismissing the basis for the question. Unfortunately, this question was migrated to a place where it is not in scope. Not sure whose idea that was.
Scott Rowe
CC BY-SA 4.0
2022-01-10T15:07:24.593Z
2022-01-11T05:05:56.990Z
2022-01-11T05:05:56.990Z
Rushi
<blockquote>
<p>Why not teach people how computers work right away?</p>
</blockquote>
<p>A driving lesson does not start with a mechanic course. A cooking class does not begin with a chemistry class. A house painter can start working before they know how to make paint and pigments. Musicians don't learn to build an instrument before they learn to play it.</p>
<p>The content of a curriculum should be decided based on the relevance to the student. While it may be <em>interesting</em> to know, does it meaningfully change how students learn to develop software? By and large, I'd say no.</p>
<blockquote>
<p>That's what I wanted an answer to.</p>
</blockquote>
<p>You're conflating &quot;I'd like to know more about this&quot; with &quot;this should be taught by default&quot;. The former is perfectly fine, but the latter is not its logical conclusion.</p>
<p>Being interested in something is not a baseline for what kind of information would be interesting/relevant to everyone.</p>
<p>From an education perspective, several considerations need to be weighed, such as:</p>
<ul>
<li>Is it interesting to the students as a whole?</li>
<li>Is this knowledge necessary?</li>
<li>Is this knowledge relevant to the course goal?</li>
<li>Can it be explained with relative ease?</li>
</ul>
<p>Your question only passes the first of those bullet points at best (as I can't judge if the majority of students are interested in this as a staple of the curriculum), but IMHO not the other three.</p>
<p>If it adds more complexity and does not pay back meaningful dividends, it's superfluous information that, while interesting, doesn't particularly <em>need</em> to be in a curriculum.</p>

CC BY-SA 4.0
2022-01-17T13:53:38.673Z
Overall +1. But you need to examine your third bullet point. Course goals can be self serving.  Mostly we take these as given. And then within the frame of that as a given make judgments. But when the question is broad and more philosophical than specific like OP we need to be careful of our assumption.  eg When I was a student my COBOL course was among the more interesting  Should we then look to making the COBOL course better and better? Ok in a frame... But sometimes we also should (and do as for COBOL) ask: Is this course necessary in the larger picture?
Rushi
CC BY-SA 4.0
2022-01-17T13:54:59.750Z
JFTR: You are likely to find me in the more pro COBOL camp than most out here. But thats because of things like https://www.theserverside.com/feature/How-COVID-19-created-a-demand-for-COBOL-basics. Not the good course I had in student days!
Rushi
CC BY-SA 4.0
2022-01-17T13:55:45.627Z
@Rusi: I understand your point, and it is sort of why I avoided concrete stating what OP's course goal is because this can change the consideration. But given OP is talking about assignment and variables; I infer they're thinking about a programming course, in which I don't think such low level constructs meaningfully teach a student how to write software in the relatively high level languages we use nowadays.
Flater
CC BY-SA 4.0
2022-01-17T13:59:27.483Z
@Rusi: Even 10 years ago, my college gave us a week of COBOL and FORTRAN (each) as part of "the basics". While interesting, I don't quite agree that it is _relevant_ in today's development ecosphere. You are correct that some governmental applications still rely on ancient codebases; but I don't think you can correctly extend that to needing to include it in your average curriculum. It's a dying breed (although it's taken longer than it should to die out), and it's akin to requiring architects (building, not software) to learn medieval housebuilding techniques because of some old churches.
Flater
CC BY-SA 4.0
2022-01-17T14:00:55.370Z
Course goals can — and should — span a range from effective doing to up the [DIKW ladder](https://en.wikipedia.org/wiki/DIKW_pyramid). (From my pov) the difficulty with OP is that he is right in demanding more stuff up the ladder. And then suggesting that imperative programming is fine!!
Rushi
CC BY-SA 4.0
2022-01-17T14:04:44.737Z
Well... Thats a different argument: (In my book) Java is more obsolete than C++. And C++ more obsolete than C. Java has exactly one useful concept — interfaces. And one genuine use case — android. A choice which has cost google a billion dollars. But this is an argument for a different place... When a company spends to the tune of a billion dollars to advertise a technology, it behoves academics to be suspicious of it https://www.theregister.com/2003/06/09/sun_preps_500m_java_brand/
Rushi
CC BY-SA 4.0
2022-01-17T14:11:11.943Z
@Rusi: I think this cycles back to the goal of the curriculum. Based on OP's "assignments and variables" mention, I'm still in the mindset of a basic programming course, where such deep specifics and niches are a bit overkill. Not saying it won't be valuable to _anyone_ but I am suggesting it will only have value to a limited subset of people, limited enough that this course is likely not the time and place for it.
Flater
CC BY-SA 4.0
2022-01-18T12:56:00.030Z
I agree with Father's first paragraph, however, there is an overriding consideration for software. A similar case is Weather: the most important fact in weather is the energy of phase change of water. Without knowing how much that makes weather what it is, you essentially know nothing. Without knowing how a machine can choose and then affect the world, you know nothing. It is really as simple as that. An auto mechanic who didn't know that gasoline is flammable *and* explosive would be a danger to themselves and others. We are training software *mechanics*, not drivers.
Scott Rowe
CC BY-SA 4.0
2022-01-18T13:08:23.137Z
Someone saw fit to make software that changed where I wrote Flater above to father. You are a bad mind-reader!
Scott Rowe
CC BY-SA 4.0
2022-01-18T13:12:09.963Z
@ScottRowe: Your analogy is IMHO flawed, as your weather scenario involves investigating the root cause (energy of phase change of water) of the effect (weather events) you're predicting. "What makes a computer different from an electrical device" is _not_ a root cause to learning how to write software. At this point in time it is an esoteric and superfluous piece of trivia that does not directly drive knowledge on how to write basic code. Picking up your analogy, I'd counter that you don't need to know the energy of phase change of water in order to correctly use a barometer or pluviometer.
Flater
CC BY-SA 4.0
2022-01-18T13:20:07.870Z
But why would you even need to use a barometer if there was no water in the air? Why would we even bother to teach programming if a piece of metal was not in some mysterious way different from all other pieces of metal in being able to answer questions, decide and act? It is simply that people are not sufficiently grateful. They are asleep to the miracle and inured to how much our lives have been altered by it, in good ways, but now also harmful and dangerous ways. I have nothing more to say at this time.
Scott Rowe
CC BY-SA 4.0
2022-01-18T14:03:30.947Z
@ScottRowe: Education does not have to occur chronologically. Just because it is relevant in the complete understanding of how everything works does not make it relevant for the first X hours of basic education. Our bodies are the result of evolution over milennia but you don't need to know the physiology of a Neanderthal when studying medicine. You're arbitrarily drawing the line at what makes a computer a computer; but why draw the line there? Why not draw it at mining silicon, or the physics behind electricity? You're conflating what you find interesting with what is educationally relevant.
Flater
CC BY-SA 4.0
2022-01-18T14:05:35.917Z
@ScottRowe: If you were to require that every underlying principle going into X should be taught when teaching X, then education would stall as time goes on and technology progresses; and you'd be adding _tons_ of details that would simply overload beginner students and negatively impact both their learning and their desire to learn. I'm not saying it's not an interesting topic, I'm saying that it's not educationally relevant to bring up from the start, and can be left as an optional piece of trivia or a more advanced deep dive when the basics have already been taught.
Flater
CC BY-SA 4.0
2022-01-17T13:47:57.937Z
2022-01-17T13:47:57.937Z
Flater
<p>While it is possible to do as you suggest, and many people do it, I question its wisdom. There are many aspects to consider.</p>
<p>The most important, however, is that if you are teaching CS then the likely most important idea (meta) is abstraction itself. CS is full of abstractions, with programming and programming languages being one of the key elements and so, is a good place to introduce it. In fact, having experience with both, it is abstraction that is fundamental to the overlap between mathematics and computer science. They differ in many ways, but share abstraction as a goal as well as a tool.</p>
<p>If you try to avoid an abstract view and try to make everything as concrete as possible then you are doing the students a disservice in the long term. If that concrete view were necessary then there would be no reason for high level languages.</p>
<p>As humans, we depend, fundamentally on abstraction in our human languages and in our interactions. It isn't a foreign concept as it might be to a chimpanzee. Computer languages exploit what the forebrain does best.</p>
<p>Note that your conception of a machine is wildly outdated. It is, in fact, just an abstraction. There was a time (more than half a century ago) when such machines more or less existed, but no more. Others here have commented on the differences. You aren't describing a machine, but an abstraction of a machine to which computation can be reduced. But a Turing machine is, itself, such an abstraction.</p>
<p>Almost all modern computer languages (some special purpose ones excepted) are <em>Consistent</em> and <em>Turing Complete</em>. The implication of this is that you don't need to go outside the language to explain computation. And, doing so can be a distraction from learning to use the paradigm represented by a language properly. You don't need to know how a &quot;variable&quot; in Lisp is represented to program effectively with them. You don't need to know the internal representation of lists (which might actually vary depending on the efforts an optimizing compiler might take.) to manipulate them. In fact, trying to reduce the Lisp notations to the actual actions of a physical machine is going to inhibit the learning of a novice.</p>
<p>Certainly, by the time a student has a rich and complete education, they need to explore many of the abstraction levels used in computing. They probably also need to know something about the mappings between the levels if they are to extend the field as researchers. But the first course is not the place to do that if it forces them to try to write every Java program as if it were a C program or even a minimal (abstract) assembly language program. The compiler course will explore those issues once they have a foundation.</p>
<p>So, as the <a href="https://cseducators.stackexchange.com/a/7228/1293">answer of Ben I.</a> suggests, you can start at pretty much any level of abstraction for the first course, say the OO level, which I tend to use. Stay with that level and show that any program can be written thinking about the abstractions and tools available at that level <em>only</em>. Use good metaphors for things, but treat them as metaphors. You don't need to leave that level to explain what a variable is, for example.</p>
<hr />
<p>One of the reasons that people continue to suggest that this mapping <strong>must be taught to novices</strong> is that many teachers, having learned the field over a long period of time, actually grew up as the world of computing was changing, from simple machines and languages to richer and more useful ones. So, we learned low level stuff early on and that &quot;helped&quot; us when we moved to higher levels. It formed a base. And so, too many of us, in effect, teach with a historical view and ask our students to follow the same low to high path that we did. But, you don't need to recapitulate the history of computing to grok Python or Scheme. They are, remember, consistent and complete. In fact, if you try to do the <em>entire</em> history in the first course then the course will last for more than half a century and when you finish the course the students will be half a century behind the times. I've been doing this for half a century myself and I've learned a heckofa lot. But most of what I've learned is actually obsolete.</p>
<p>Pick an abstraction level (i.e. a paradigm). Pick a good language to represent that level. Teach <strong>that</strong>, so that students have the skills to understand computation at that level. Leave that level only with metaphor or with anecdotes, not to 'splain how it <em>really</em> works. Because it doesn't <em>really</em> work that way at all if you have ever peeked at an optimizing compiler.</p>
<p>The goal is insight.</p>
<hr />
<p>There are two Lisp list functions that I find instructive for thinking about the functional paradigm. Neither requires any machine view. Both require some essential <em>insight</em> into functional programming. The two functions are to <em>clone</em> a list and to <em>reverse</em> a list, both in linear time. If you don't care about time, both are easy, but you need to think like a lisper to grok these. Try them.</p>

CC BY-SA 4.0
2022-01-11T19:07:53.357Z
Good answer. I'll just remark that your "One of the reasons" section can be characterized as "Pedagogy recapitulates ontogeny" and that most people think this is bad. "most of what I've learned is actually obsolete" That takes courage to admit. I usualy don't come further than to say "I'm waiting for the concept of XYZ to make a come-back" :-)
Victor Eijkhout
CC BY-SA 4.0
2022-01-12T00:27:39.870Z
As we develop more levels and abstractions, I think it's important to have a through line that terminates on something real, so that if you ever do need to start a car with a pencil or broomstick, you can.
Scott Rowe
CC BY-SA 4.0
2022-01-16T03:30:47.707Z
When I first learned Lisp, around 1985, I thought it made sense because it was built on car, cdr and cons, which all related directly to machine operations. I could see the exact interface where the machine met the language, the hoofprint where the winged horse struck off. But 300 pages later in SICP they jump out of a perfectly good airplane, which we realize was never going to leave the ground. If Lisp is based in simplicity, and I am arguing for simplicity, why didn't Lisp live up to its promise after 60 years? If it is a good starting point why doesn't teaching start there?
Scott Rowe
CC BY-SA 4.0
2022-01-17T06:53:43.093Z
@ScottRowe Your last 2 sentences/questions are on point.  Perhaps the best answer in a short space is *Lisp fell between 2 stools* To the mainsream imperative programmers Lisp looks too weird and by implication mathematical to be useful. To the functional programmers (in 2022) Lisp is not a functional language but more or less python/ruby/javascript with idiosyncratic syntax.  There are other answers of course like *Lisp didnt live up?!  Look at clojure*  But I dont like this answer because the battlefield of TIOBE indices is unsavory to settle pedagogical questions.
Rushi
CC BY-SA 4.0
2022-01-17T07:00:45.003Z
Remember Fortran was functional in 1957. And Haskell will give way to Idris(ish) Agda(ish) in 2030 if I peer in my crystal ball. Lisp was FP between 1960 and 1980. From 80 it coalesced into Common Lisp plus Scheme. And after "Real World Haskell" I'd say the mantle passed. [JFTR: I love scheme and think Haskell has missed the boat/point. I'm describing the status quo not my preferences] As for SICP dropping subst model at pg 300 just switch to Haskell — there simply is no imperation/mutation ie Lisp's informal culture of FP gets baked into Haskell's formal semantics
Rushi
CC BY-SA 4.0
2022-01-11T15:32:56.260Z
2022-01-11T16:18:19.173Z
2022-01-11T16:18:19.173Z
Buffy
<p>First, I am not sure what the five operations you mention are.  And, or, xor, not are only four, and if you include the negations, you get nand, nor, and xnor.  I don't know whether you mean to move higher or lower on the abstraction ladder when you say &quot;five operations&quot;.</p>
<p>Here are some possibilities:</p>
<ul>
<li><p>The point at which is all becomes concrete is, I suppose physical chemistry, but I don't think you intend to start there.</p>
</li>
<li><p>Real computer pretend to be modified Turing Machines, but of course, real computers are strictly less powerful because they lack infinite memory.  In reality, they are actually very, very large Finite State Machines.  Do you mean to start there?</p>
</li>
<li><p>Do you mean to start with binary and arithmetic?  We are already quite high on the abstraction ladder at that point, since numbers as humans intuitively understand them don't really exist in the computer in any meaningful sense.</p>
</li>
<li><p>Do you mean to start with fetch, read, write, execute?  (I'm guessing not, since you referenced five things, and that is only four.)  Again, we're already far from anything concrete at this point, and we are also far lower than anything you'll see in an assembly language.  If I have my students begin here, they are not only entering at a highly abstract place, they are entering at an abstract place that has (a) gotten hard enough that it becomes hard for beginners to figure out steps on paper, and (b) is also low enough that it's also hard to see how a statement like <code>print(&quot;hello world&quot;)</code> could possibly map to it.</p>
</li>
<li><p>Do you mean to start with program stacks?  Stack and heap?  Simple CLI stuff?  Stdin, stdout?  When you say &quot;how assignment functions&quot;, this is my best guess for what you intend.</p>
</li>
<li><p>Do you want to start with assembly?  It's very, very, very difficult for a beginner to make sense of something as simple as</p>
<pre><code>`mov rdi, 1        ;   STDOUT_FILENO,` 
</code></pre>
</li>
<li><p>Do you want to start with &quot;hello world&quot; in C?  It's a natural point of entry, but of course, by the time you're there, you can't see down to the boolean algebra at all any more.  But at least you're in a procedural programming environment, so you can loop, call functions, and do a myriad of other things pretty easily.</p>
</li>
<li><p>Do you want to start with a higher level language like Java, Ruby, JavaScript, Python, Haskell, Scheme, or Prolog?  You're now in the world where students can immediately learn to do things that might matter directly in their lives.  But, of course, all of these languages are layers and layers and layers and layers of abstractions away from the &quot;computer&quot;.</p>
</li>
<li><p>Do you want to start with software engineering, and hit clean coding and objects and object patterns from day 1?</p>
</li>
</ul>
<p>So the first problem, and I really mean this: I have no idea what you're talking about when you say &quot;computers can do five things&quot; because I'm not aware of any layer of abstraction that has five things.</p>
<p>The reality is that, as a teacher, <strong>you can enter at any of these points</strong>.  But then you must work students slowly up and down from whatever point you have chosen, until the students understand every one of these layers.  (And make no mistake: that <em>is</em> the goal.  Students should understand all of these layers at some point or another.)</p>
<p>What you presumably don't <em>want</em> to do is take more than one point of entry, and then leave the work of linking them until much later.  (You might <em>have</em> to do this from time to time, but it should never be the goal, and you should make efforts to minimize the amount of time within the linking period.)</p>
<p>So, for a teacher, the natural question becomes <strong>&quot;at <em><strong>which</strong></em> point should I make my entry?&quot;</strong></p>
<p>It's an important question, and one that real teachers hotly debate.  Most of us have settled roughly in the C-to-(whatever high level language you choose) spectrum as the initial entry point, but it's not universally so.  Some teachers begin with something called &quot;Objects first&quot; which pulls students to an even higher level right from the start.  Some teachers begin from a more electrical level, such as Raspberry Pi, and work their way up from there.  Everyone can make a case for why they believe they are starting in a good place.</p>
<p>In truth, you can make a case for almost any point of entry. I think that people tend towards the higher levels of abstraction at the start because (1) kids in real life enjoy it and find it rewarding, year after year, and (2) it provides rich interactions with the computer that lend themselves to future explorations, no matter what the student's interests are.</p>
<p>In a very practical sense, I have students who gravitate towards processors and security.  I have students who gravitate towards UI and UX.  I have students who gravitate towards game programming.  I have students who gravitate towards game <em>design</em>.  I have students who gravitate towards web apps.  I have students who gravitate towards theoretical CS and mathematics.  If I have 30 real-life students, they will have 30 different centers of gravity in CS, so I want a point of entry that helps as many of them as possible towards their interests as fast as possible.  If I start at NAND gates, I do a disservice to my UX students, since it'll take them an extra year or two to get to the beginnings of what they want.</p>
<p>Does that make sense?  I'm not aware of <em>anyone</em> who argues that students shouldn't learn about every one of these layers, but there is a question of what order is most productive, a further question of what order helps students start learning about the things that interest them as quickly as possible, and a third question about what order helps students to learn things &quot;best&quot;.<sup>1</sup></p>
<p><sup>1</sup> - &quot;Best&quot; is also controversial, because people have radically different ideas about what the end-goal looks like, so the term cannot be well defined among the population.</p>

CC BY-SA 4.0
2022-01-11T11:19:29.203Z
Fetch Store Arithmetic Test / Compare Jump - these are things people can relate to, they are part of real machines and they're sufficient. "*More than this comes of evil.*" Can we agree that bridging this to the CPU would satisfy most kids? Could you do that once and for all, right at the start, and that it would prevent huge amounts of misunderstanding? So... Do.
Scott Rowe
CC BY-SA 4.0
2022-01-11T14:35:48.257Z
@ScottRowe Interesting abstraction layer. Each of the five 'operations' is an abstraction of its own, again demonstrating the fact that we, as humans, are driven to abstraction.
Gypsy Spellweaver
CC BY-SA 4.0
2022-01-12T02:09:30.407Z
@ScottRowe I teach that stuff in my processors elective, but modern computers don't do these any more. The processor isn't even aware of RAM addresses in modern computers. There's a whole other architecture to deal with read and write that starts with paging and ends in security measures. I'm not trying to be obstinate. I genuinely feel like the abstract layer you hold up as the most important just *isn't* the most important, nor the most helpful. I can't speak for every population, but I can say with certainty that the population I teach would not be happy if I started where you suggest.
Ben I.
CC BY-SA 4.0
2022-01-11T01:28:57.303Z
2022-01-11T19:02:52.727Z
2022-01-11T19:02:52.727Z
Ben I.
<p>I teach year 8, some of this: Boolean logic, combining Boolean logic to make a memory bit, and an adder. We also go the other way to discover how to make logic with dominos, switches (Shannon), cogs, etc. However the bottom up approach is not the best way. Noor is the top down. You need both. Many CS principles are true independent of how they are implemented.</p>

CC BY-SA 4.0
2022-01-27T10:51:44.423Z
So teach the principles.
Scott Rowe
CC BY-SA 4.0
2022-01-31T14:20:12.800Z
@ScottRowe `and` and `or` are true no mater if done with transistors, or cogs. Pattern matching and arithmetic are true no mater if done with Boolean logic, or the way (one of the ways) you learnt in maths class. The principles are up the abstraction. AN implementation is down. Yes teach implementations as well as principles, but don't teach that it is the only implementation, or that it is fundamental. It is not. We have many ways to implement it. For now it is CMOS transistors implements Boolean logic implements, adders, multipliers, etc, implements ...
ctrl-alt-delor
CC BY-SA 4.0
2022-01-31T15:25:51.077Z
I often wonder what will come next, it will be fascinating to see. But *for now*, it makes sense to simply pull the curtain back for a few minutes and show what the thing is doing. Some day, it might well be beyond human understanding, once computers start evolving themselves. Blink and we could miss it.
Scott Rowe
CC BY-SA 4.0
2022-01-17T09:42:00.053Z
2022-01-17T09:42:00.053Z
ctrl-alt-delor
<p>Maybe you have a point that there is a level to the hardware that is explainable. However, I don't see how it enlightens the use of a programming language.</p>
<p>Besides, I don't think you realize how much the explanation that you seem to be proposing is also an abstraction. How precise are you going to explain how a computer works? Independent functional units? Branch prediction? Out-of-order execution? Clock domains?</p>

CC BY-SA 4.0
2022-01-11T13:31:03.350Z
It enlightens the programmer, or in this more important case, the student. It only need be precise enough to get the point across, like all other human communication.
Scott Rowe
CC BY-SA 4.0
2022-01-11T14:03:32.043Z
But then you're back at my previous statement that the syntax/semantics of the programming language is precise enough.
Victor Eijkhout
CC BY-SA 4.0
2022-01-11T15:11:31.570Z
«*The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise*» That's Dijkstra again!  Though I agree with @ScottRowe more than he realizes . If you need to talk of memory you basically need a machine model.  The crucial difference we have is that he thinks its necessary, inevitable. I know its not necessary in a pure functional language.  But if you take that as too fringe for serious consideration (better than not knowing abt it at all!!) then you implicitly prove his point
Rushi
CC BY-SA 4.0
2022-01-11T15:17:42.583Z
@VictorEijkhout The language cannot explain how it can affect the physical world, so more is needed.
Scott Rowe
CC BY-SA 4.0
2022-01-11T15:20:44.003Z
@Rusi "*Everyone* talks *about the weather, but no one* does *anything about it!*"
Scott Rowe
CC BY-SA 4.0
2022-01-11T19:03:58.223Z
@Rusi The machine model you refer to is the Von Neumann architecture. And a lot of the misery in my field of high performance computing is that the instruction set of a computer offers a Von Neumann API (so to Scott the CPU indeed looks simple) while underneath is a whole bunch of magic (see the random keywords in my answer) to make it look that way, while it isn't remotely that.
Victor Eijkhout
CC BY-SA 4.0
2022-01-12T04:27:00.610Z
You [too](https://cseducators.stackexchange.com/questions/7226/driven-to-abstraction/7229?noredirect=1#comment18954_7233) are proving @ScottRowe point more than you probably realize. My restatement of point: We have too many layers of abstraction. If theyre not working why aren't we rethinking them? Ans1 (cynical): Because no one's in charge.. Ans2 : (enthusiastic) cutting edge research is all the time just doing that! Join the fray! I guess the truth is in between?
Rushi
CC BY-SA 4.0
2022-01-12T04:30:44.637Z
Case in point:  I had a friend who did his PhD in getting past Intel's cache hierarchy. Don't remember the details. But the summary is quite aligned to @ScottRowe : We make fancy abstractions. Then we do PhD's getting past/gaming them. Why... Why? Ans:Because there's no "We" at least in charge
Rushi
CC BY-SA 4.0
2022-01-12T10:57:03.847Z
@Rusi Yes. Someone is in charge of flying a plane. Should computers be able to contradict them? Then who's in charge?
Scott Rowe
CC BY-SA 4.0
2022-01-11T13:22:05.470Z
2022-01-11T13:22:05.470Z
Victor Eijkhout
<p>One recurring discussion I have on this site which I have never understood is:</p>
<p>Why not teach people how computers work right away?</p>
<p>This always leads people to speculate about cosmic strings and other not particularly relevant topics. No, just: what makes this particular machine that is powered by electricity <em>different from</em> electrical machines that don't answer questions? In simple terms, how can an object perform steps, and how can steps decide and result in new information?</p>
<p>It is not a hard question, and the answer, at least an initial one, takes about a half hour, even for a 14 year old. Why the resistance bordering on mania to just getting that over in the introduction? Maybe more students would take an interest, and fewer would be fuddled about assignment and variables later if we just told them straight up how the blooming thing functions? What's the motivation for explaining how the trick works in graduate school when you could get it over the first day?</p>

CC BY-SA 4.0
2022-01-10T13:32:02.827Z
Ultimately this is a question about levels. What level are you suggesting? Transistors? ... Scheme? Computer languages define a machine, even if an abstract one.
Buffy
CC BY-SA 4.0
2022-01-10T17:43:25.313Z
@Buffy The level of: there are memory variables and a CPU that can only do 5 things. And with just that, you can build up systems to do anything digital that is possible. Kind of like how with 3 elementary particles you can build up anything we can see, or with 4 DNA bases, you can represent all forms of life, or with 12 notes in a scale you can play most music. This is called a Generative description, and to me, it's the only description worth learning. It answers the question of how a *thing* can *make decisions*, which is profound. Descriptions that don't go that way don't seem interesting.
Scott Rowe
CC BY-SA 4.0
2022-01-10T18:42:07.357Z
@ScottRowe You really need to study alternate-to-Turing models https://en.wikipedia.org/wiki/Turing_machine_equivalents . You keep on harping on your 5 op machine as though its a God-made law. Its just a human artifact and concoction. (See my Simon Newell quote) Its your preferred mode and manner of thinking and teaching. And maybe you do a good job.  But its not necessary or inevitable just your preference. Peter Wegner had an insightful paper showing that OO:empiricism  :: FP:rationalism. Its not a question of fact but of perspective
Rushi
CC BY-SA 4.0
2022-01-10T19:05:44.627Z
JFTR: I consider voting on meta misguided and absurd.  Ie downvote not mine
Rushi
CC BY-SA 4.0
2022-01-10T19:06:22.263Z
You could teach kids how the non-Turing machines work, that would be great. Many kids probably would like to know.
Scott Rowe
CC BY-SA 4.0
2022-01-10T23:13:17.627Z
Re: Voting in Meta - “*At the devil’s booth are all things sold. Each ounce of dross costs its ounce of gold.*"
Scott Rowe
CC BY-SA 4.0
2022-01-11T01:27:04.183Z
Like Buffy says, there's way too many levels for a 1 hour discussion.  You can teach two levels and how they relate, but even that's complicated.  Toward the bottom, there's the hardware, which is an interpreter of machine code instructions (and below that, there's sequential and combinational logic, and below that there's gates, and below that process technology).  The hardware has physical storage that simply exists.  Layered above that, there's logical models of computing with variables that come and go, logical constructs like loops, objects, methods, data structures, commands & inquiries.
Erik Eidt
CC BY-SA 4.0
2022-01-11T11:12:39.207Z
@ErikEidt Sure. I think most people realize this, but they still want the "punch line" answer. What counts is the **level crossing** part where the computer-y stuff hits the hard physical-y stuff. That's what I wanted an answer to. All the rest is just your usual over-thought academic rubbish that we all don't want or need. Can be done in an hour. I reduced Normalization to 4 simple sentences. Easy to learn, hard to master, like Othello. Or...  Go. Unless you are a computer already. Then we'll have to explain how our brains could have designed *them*. See how that works?
Scott Rowe
CC BY-SA 4.0
2022-01-11T11:27:04.130Z
Migration, Moved to Chat... It would only be polite to ask first.
Scott Rowe
CC BY-SA 4.0
2022-01-11T11:40:17.870Z
Related QuestIon: [Concept of Variable](https://cseducators.stackexchange.com/questions/6462/concept-of-variable)
Scott Rowe
CC BY-SA 4.0
2022-01-12T04:41:05.320Z
@ScottRowe : Your objection to the migration proves its rightness more than you realize. CS is a subject. CSE is meta-CS already. Meta-CSE is meta² CS. Do you *really* want the square? Why do you not get metaness? Same reason you don't get functional programming perhaps? And that brings us back to the (wrong)  premises of your question 
Rushi
CC BY-SA 4.0
2022-01-17T10:00:16.537Z
_"Why not teach people how computers work **right away**?"_ A driving lesson does not start with a mechanic course. A cooking class does not begin with a chemistry class. A house painter can start working before they know how to make paint and pigments. Musicians don't learn to build an instrument before they learn to play it. _"That's what I wanted an answer to."_ This is not a baseline for what kind of information would be interesting/relevant to everyone. You're also conflating things such as (a) interesting (b) easily explained (c) necessary knowledge and (d) relevant to the course goal.
Flater
CC BY-SA 4.0
2022-01-17T12:15:43.350Z
This is worth a proper answer @Flater. By and large I'd agree but I'd pick few bones also
Rushi
CC BY-SA 4.0
2022-01-17T13:48:22.550Z
@Rusi Rephrased as an answer, albeit with some modifications.
Flater
CC BY-SA 4.0
2022-01-19T21:23:56.200Z
Related QuestIon: [Considering What Can Be Taught - Meta](https://cseducators.meta.stackexchange.com/questions/477/considering-what-can-be-taught)
Scott Rowe
CC BY-SA 4.0
2022-01-27T10:49:07.757Z
@Flater I think of programming as Engineering - building something that lasts which other people use instrumentally, to do other things. Yes, cooking is a responsibility if others consume the food. Maybe playing music is too if it will distract people so badly that they crash their car or fall off a cliff. But writing software is like designing food, or a car. It's not just a fun creative activity. Even writers are probably taught from the beginning that they will be held responsible for what they write, even if it is just on Twitter or something...
Scott Rowe
CC BY-SA 4.0
2022-01-27T11:43:55.180Z
@ScottRowe: In the "programming as recipe-writing" analogy, where the compiler/computer is the actual chef; you have to consider that the chefs (computers) have gotten better over time and need less explicit instructions today. In the past you needed to explain to your chefs the precise steps on how to make a béchamel sauce; but chefs today already know how to make it, so the recipe writer only needs to write down "Make a béchamel sauce", not the low-level instructions. Therefore, the specifics of how béchamel sauce is made is not longer _essential_ when teaching people how to write recipes.
Flater
CC BY-SA 4.0
2022-01-27T18:40:09.487Z
@Flater yes, but you are still responsible for knowing what is in it and not serving it to people with a food allergy. (Spoiler alert: I used to run a retreat center and cooked for and served lots of guests with all kinds of food issues.) So the level of the instructions doesn't affect your need to know what is happening - where important - at each level. There is not a way to automate out the responsibility, no matter how opaque the system becomes. That's why simplicity is always preferable.
Scott Rowe
<introductory-lesson><computational-thinking><hardware>
Driven to Abstraction
# Driven to Abstraction

(Asked by: username_0 on 2022-01-10)

One recurring discussion I have on this site which I have never understood is:

Why not teach people how computers work right away?

This always leads people to speculate about cosmic strings and other not particularly relevant topics. No, just: what makes this particular machine that is powered by electricity *different from* electrical machines that don't answer questions? In simple terms, how can an object perform steps, and how can steps decide and result in new information?

It is not a hard question, and the answer, at least an initial one, takes about a half hour, even for a 14 year old. Why the resistance bordering on mania to just getting that over in the introduction? Maybe more students would take an interest, and fewer would be fuddled about assignment and variables later if we just told them straight up how the blooming thing functions? What's the motivation for explaining how the trick works in graduate school when you could get it over the first day?

**Tags:** introductory-lesson, computational-thinking, hardware

> **Comments:**
> **username_1**: Ultimately this is a question about levels. What level are you suggesting? Transistors? ... Scheme? Computer languages define a machine, even if an abstract one.  
> **username_0**: @username_1 The level of: there are memory variables and a CPU that can only do 5 things. And with just that, you can build up systems to do anything digital that is possible. Kind of like how with 3 elementary particles you can build up anything we can see, or with 4 DNA bases, you can represent all forms of life, or with 12 notes in a scale you can play most music. This is called a Generative description, and to me, it's the only description worth learning. It answers the question of how a *thing* can *make decisions*, which is profound. Descriptions that don't go that way don't seem interesting.  
> **username_2**: @ScottRowe You really need to study alternate-to-Turing models https://en.wikipedia.org/wiki/Turing_machine_equivalents . You keep on harping on your 5 op machine as though its a God-made law. Its just a human artifact and concoction. (See my Simon Newell quote) Its your preferred mode and manner of thinking and teaching. And maybe you do a good job.  But its not necessary or inevitable just your preference. Peter Wegner had an insightful paper showing that OO:empiricism  :: FP:rationalism. Its not a question of fact but of perspective  
> **username_2**: JFTR: I consider voting on meta misguided and absurd.  Ie downvote not mine  
> **username_0**: You could teach kids how the non-Turing machines work, that would be great. Many kids probably would like to know.  
> **username_0**: Re: Voting in Meta - “*At the devil’s booth are all things sold. Each ounce of dross costs its ounce of gold.*"  
> **username_3**: Like username_1 says, there's way too many levels for a 1 hour discussion.  You can teach two levels and how they relate, but even that's complicated.  Toward the bottom, there's the hardware, which is an interpreter of machine code instructions (and below that, there's sequential and combinational logic, and below that there's gates, and below that process technology).  The hardware has physical storage that simply exists.  Layered above that, there's logical models of computing with variables that come and go, logical constructs like loops, objects, methods, data structures, commands & inquiries.  
> **username_0**: @ErikEidt Sure. I think most people realize this, but they still want the "punch line" answer. What counts is the **level crossing** part where the computer-y stuff hits the hard physical-y stuff. That's what I wanted an answer to. All the rest is just your usual over-thought academic rubbish that we all don't want or need. Can be done in an hour. I reduced Normalization to 4 simple sentences. Easy to learn, hard to master, like Othello. Or...  Go. Unless you are a computer already. Then we'll have to explain how our brains could have designed *them*. See how that works?  
> **username_0**: Migration, Moved to Chat... It would only be polite to ask first.  
> **username_0**: Related QuestIon: [Concept of Variable](https://cseducators.stackexchange.com/questions/6462/concept-of-variable)  
> **username_2**: @ScottRowe : Your objection to the migration proves its rightness more than you realize. CS is a subject. CSE is meta-CS already. Meta-CSE is meta² CS. Do you *really* want the square? Why do you not get metaness? Same reason you don't get functional programming perhaps? And that brings us back to the (wrong)  premises of your question   
> **username_4**: _"Why not teach people how computers work **right away**?"_ A driving lesson does not start with a mechanic course. A cooking class does not begin with a chemistry class. A house painter can start working before they know how to make paint and pigments. Musicians don't learn to build an instrument before they learn to play it. _"That's what I wanted an answer to."_ This is not a baseline for what kind of information would be interesting/relevant to everyone. You're also conflating things such as (a) interesting (b) easily explained (c) necessary knowledge and (d) relevant to the course goal.  
> **username_2**: This is worth a proper answer @username_4. By and large I'd agree but I'd pick few bones also  
> **username_4**: @Rusi Rephrased as an answer, albeit with some modifications.  
> **username_0**: Related QuestIon: [Considering What Can Be Taught - Meta](https://cseducators.meta.stackexchange.com/questions/477/considering-what-can-be-taught)  
> **username_0**: @username_4 I think of programming as Engineering - building something that lasts which other people use instrumentally, to do other things. Yes, cooking is a responsibility if others consume the food. Maybe playing music is too if it will distract people so badly that they crash their car or fall off a cliff. But writing software is like designing food, or a car. It's not just a fun creative activity. Even writers are probably taught from the beginning that they will be held responsible for what they write, even if it is just on Twitter or something...  
> **username_4**: @ScottRowe: In the "programming as recipe-writing" analogy, where the compiler/computer is the actual chef; you have to consider that the chefs (computers) have gotten better over time and need less explicit instructions today. In the past you needed to explain to your chefs the precise steps on how to make a béchamel sauce; but chefs today already know how to make it, so the recipe writer only needs to write down "Make a béchamel sauce", not the low-level instructions. Therefore, the specifics of how béchamel sauce is made is not longer _essential_ when teaching people how to write recipes.  
> **username_0**: @username_4 yes, but you are still responsible for knowing what is in it and not serving it to people with a food allergy. (Spoiler alert: I used to run a retreat center and cooked for and served lots of guests with all kinds of food issues.) So the level of the instructions doesn't affect your need to know what is happening - where important - at each level. There is not a way to automate out the responsibility, no matter how opaque the system becomes. That's why simplicity is always preferable.  

---

## 8 answers

### Answer by username_2 on 2022-01-11. Score: 4 | Accepted answer

username_1 Ben username_6 all in different ways talked of levels.
Let me try enumerating them for you from established sources. (Summarizing for brevity)

Weste Eshraghian book on CMOS VLSI gives these levels

> Digital VLSI design is often partitioned into five levels of abstractions: architecture design, microarchitecture design, logic design, circuit design, and physical design. (going downward)
>
> 1. Architecture describes the functions of the system.
> 2. Microarchitecture describes how the architecture is partitioned into registers and functional units.
> 3. Logic describes how functional units are constructed. eg ripple carry adder Or lookahead
> 4. Circuit design describes how transistors are used to implement the logic.
> 5. Physical design describes the layout of the chip.

Going upwards Tanenbaum's classic Structured Computer Organization (better in my view than much that followed) discusses the levels of a computer as follows: (going upward) Overlap deliberate

> 4. Digital logic level
> 5. Microarchitecture
> 6. ISP
> 7. Operating system (system calls as a VM over ISP)
> 8. Assembly language

On the other side we can go further down and reach solid state physics -- of which I know even less than VLSI!
Wikipedia gives these main branches:
(I am guessing the descending order)

> 9. electromagnetism
> 10. metallurgy
> 11. crystallography
> 12. quantum mechanics

# A special level

For some reason or other you believe that some level (nearabouts ISP?) is very special. The onus is on you to explain why

> **Comments:**
> **username_7**: Computers work by magic. The "special level" that you talk about is the lowest level that any given person understands. Everything above that special level makes sense, everything below it is magic. Most of us just ignore the magic and get on with our jobs. I think the OP's goal is to bring the student's "special level" down to match his own. They don't need to understand anything at a lower level than that because everything below that level is the magic stuff that _he_ feels comfortable ignoring.  
> **username_2**: @SolomonSlow Well one could add one more list upwards: Assembly, C, C++, Haskell, Idris, Lean. And (speaking for myself) my comfort zone ends below Idris. Between Idris (etc) and Lean (etc) the level gap is really special (IMHO) -- the Turing computable level. So its more like we inhabit a comfort zone neighborhood : lowest level I consider relevant to highest level grokkable to my wits!  
> **username_2**: Also I dont know a fig about solid state physics; though I studied some quantum physics in college. ie the knowledge is usually scattered hole-y. And I add C++ with some reservations... Dont believe OOP is much good to anybody-- students, teachers, professionals -- but C++ gives some things independent of OOP  
> **username_0**: @SolomonSlow Thank you. For me the important point is where the program level affects the physical world level. The goal is to reveal how the magic works. Then it's not magic anymore. Above there are levels, yes, and below there are levels, but right at that interface is the part that really demands an explanation. How a computer is different from everything else. Didn't you want to know that somewhere early on? Did you wait patiently for someone to get around to explaining it?  
> **username_7**: @ScottRowe, My "special level" was the gate level. I have an armchair understanding of what MOSFETs and relays do. BJTs are magic, but I understand how they can be combined to make logic gates. Once I dug down the the point where I understood how to build a rudimentary computer out of  NAND gates, I felt like I "knew" how a computer worked. OTOH, modern, high-performance, multi-core, super-scalar, desktop/server/mobile-device CPUs are pure magic as far as I know, and I am content to write out magic spells (Python, Java, and C++ code) that summon them to do my dark bidding.  
> **username_2**: And that kinda proves ScottRowe's point @solomonslow. There is point where it's as though the rubber hits the road -- you can hear the scream, smell the sulphur. We are all *explaining it away* rather than *conveying the magic*. For me a giddy point was scheme when I wrote functions taking and returning functions. And used that to actually grade my students without variables  
> **username_2**: If @ScottRowe says modern computer (teaching) has taken away the fun the mystery, I have to agree ... somewhat reluctantly  
> **username_5**: My "special level" is at the digital logic level.  Once I saw everything move to booleans, it all connected for me.  And in particular, it was the carry adder that was my big a-ha moment.  @ScottRowe's special level still left everything feeling like magic to me, because it didn't answer the basic questions about physicality.  What was memory?  How did a command *happen*?  How could a computer even receive a "command"?  How could a computer manipulate numbers when it only had wires?  
> **username_2**: @Ben I guess the larger meta() point Scott is making is that we teachers dont bother enough this sense of magic. In fact a teacher passionate about some level would/could convey the magic of that level for any/every level. What Scott doggedly does not get (as username_1 and others said) is that the "physical level" is only physical into-quotes: there are no gates, just transistors, no transistors/wires as the schematic shows, just a doped silicon wafer. I was actually contemplating making a CW answer with sense of magic(s) which *I* can imagine. And others fill others. 3 answers! A bit much  
> **username_2**: (cont) See this ["old joke"](https://matheducators.stackexchange.com/questions/1403#comment8485_1403). OTOH what @ScottRowe does get better than most but communicates more emotively is that we are in a mess with all this ill-thought-through abstraction. Right now Ive spent half a day grappling with this: firefox refuses to open local files. And with a strange `File not found` error. Turns out ubuntu has moved firefox from apt to snap -- a new snazzy shiny abstraction which loves me so dearly it treats me as my own intruder! Dozens of such glorious progresses I - or anyone -- could recount...  
> **username_0**: @BenI. Maybe the Frank Herbert quote "*In lieu of red tape*" should be applied to runaway development of computer systems. I did say that there is NO magic, and so any mysterious aspects should be explained.  
> **username_2**: @ScottRowe : Heh! An accept!! And for an answer that was not meant to be an answer. But maybe it can become one?? As I was musing above maybe I "CW it" (community wiki). And then everyone can express their "special level" from the place of their own passion?  More at meta...  
> **username_0**: Your Answer is the only one that referred to levels. My whole question was about the point where one kind of thing links to another kind of thing, where "greenness disappears". That's what is meant by Science, everything else is just blithering.  

---

### Answer by username_2 on 2022-01-10. Score: 6

Why 5 operations when [one suffices](https://en.wikipedia.org/wiki/One-instruction_set_computer)??? (The [subsection of above](https://en.wikipedia.org/wiki/One-instruction_set_computer#Instruction_types) showing the more usual machine instructions as "macros" implemented in terms of that one instruction)

Being sparse and minimal is great. But before that you need to wonder what CS really is about.
Here's some quotes from computer scientists that help you clarify your thoughts on that

* *Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science* [Michael Fellows](https://en.wikiquote.org/wiki/Computer_science#S_-_Z)
* *I don't need to waste my time with a computer just because I am a computer scientist* [Dijkstra](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1305.html)
* *Machine -- imperates  
  Programmer -- declarates  
  Language* -- [relevates](http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html#relevate)  
  [R Mody](http://blog.languager.org/)
* *Computer Science is a science of the artificial* Simon and Newell
* *Simplicity does not precede complexity, but follows it* Alan Perlis  
  (Which is simpler an assembly language program or a scheme program?)
* *A programming language is low level when its programs require attention to the irrelevant* Alan Perlis  
  ("What is there?" Vs "What is relevant?" which question is more important? For teachers??)
* *The computing scientist could not care less about the specific technology that might be used to realize machines, be it electronics, optics, pneumatics, or magic* [Dijkstra](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD924.html)

Comes to the nub of the matter: You seem to think (things like) assignment are important to teach because they are "there".

People of the opposite mindset neither believe its important to teach.  
Nor for that matter even "there" -- I've **never** seen a machine having anything like an assignment opcode. Registers, memory -- in a dizzying hierarchy of caches -- indirection, addressing modes, stacks, interrupts... I could continue. But nothing remotely like assignment.

> Maybe more students would take an interest, and fewer would be fuddled about assignment and variables later if we just told them straight up how the blooming thing functions?

Maybe... And a few determined teachers even succeed at this herculean task. Maybe you're one of them...

But many more students would be engaged and teachers satisfied if we threw the baby-bathwater-mess -- assignment+imperative programming -- out and taught how to leap further with more hi level declarative languages.

JFTR: I consider OOP a bigger mess than imperative programming. Another subject...

And let me give the last word to Dijkstra (again!)

> It used to be the program’s purpose to instruct our computers;  
> it became the computer’s purpose to execute our programs.

> **Comments:**
> **username_0**: How do computers make decisions? How does a material object do that? No description that does not include physical and logical can properly answer. So, the physical must be part of it or you are just going in circles. I have no patience for that, I want answers that terminate in stuff I know that is indisputable. And I wanted that as a child also. Aren't you glad someone does?  
> **username_2**: They dont; *you do*. Computers are no more "deciders" than my gpas old vacuum-tube radio. Just think: When you write a program; with one result you say: *Hurrah it works!* With another you say: *O hell; A bug!* You say: Do you notice?? **YOU** not the computer. If it could it would and thered be no bugs!  
> **username_2**: @ScottRowe Notice that your question *What is it about being in Academics that makes you not hear a simple question with a simple answer?* I already answered. More bluntly: Assignment is as unnecessary as ptolemaic epicycles were post Copernicus. How is it that when your question is answered you always dont hear?  
> **username_0**: How can a material object (a brain) make decisions? I should have gone in to Neuroscience, but programming humans is frowned upon.  
> **username_0**: Someday soon the computers will 'notice' and we had better be ready.  
> **username_2**: Who said brains decide?? I said **you** decide. If you want to identify yourself with some body part... Go ahead. However I'd recommend a look at Lakoff embodied cognition https://en.m.wikipedia.org/wiki/Embodied_cognition As one road to curing 4 centuries of Cartesian dualism  
> **username_0**: The mind-body problem enters stage right.  
> **username_0**: So it isn't just the brain, it's lots of physical things involved. Restated: How can any conceivable partly physical system make decisions? It is easier just to stick with the original question, because it has already been answered by someone.  
> **username_2**: @ScottRowe Since I gather what you're *really* grumbling about is [stratospheric abstraction in OOP](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/) I added a clarifying aside on that though that's a quite different q. Also a new header in the hope that you will rethink your "five magic ops"  
> **username_0**: Joel said, "*Sometimes smart thinkers just don’t know when to stop*" I suggest you ponder that and come up with a concise answer instead of dismissing the basis for the question. Unfortunately, this question was migrated to a place where it is not in scope. Not sure whose idea that was.  

---

### Answer by username_4 on 2022-01-17. Score: 4

> Why not teach people how computers work right away?

A driving lesson does not start with a mechanic course. A cooking class does not begin with a chemistry class. A house painter can start working before they know how to make paint and pigments. Musicians don't learn to build an instrument before they learn to play it.

The content of a curriculum should be decided based on the relevance to the student. While it may be *interesting* to know, does it meaningfully change how students learn to develop software? By and large, I'd say no.

> That's what I wanted an answer to.

You're conflating "I'd like to know more about this" with "this should be taught by default". The former is perfectly fine, but the latter is not its logical conclusion.

Being interested in something is not a baseline for what kind of information would be interesting/relevant to everyone.

From an education perspective, several considerations need to be weighed, such as:

* Is it interesting to the students as a whole?
* Is this knowledge necessary?
* Is this knowledge relevant to the course goal?
* Can it be explained with relative ease?

Your question only passes the first of those bullet points at best (as I can't judge if the majority of students are interested in this as a staple of the curriculum), but IMHO not the other three.

If it adds more complexity and does not pay back meaningful dividends, it's superfluous information that, while interesting, doesn't particularly *need* to be in a curriculum.

> **Comments:**
> **username_2**: Overall +1. But you need to examine your third bullet point. Course goals can be self serving.  Mostly we take these as given. And then within the frame of that as a given make judgments. But when the question is broad and more philosophical than specific like OP we need to be careful of our assumption.  eg When I was a student my COBOL course was among the more interesting  Should we then look to making the COBOL course better and better? Ok in a frame... But sometimes we also should (and do as for COBOL) ask: Is this course necessary in the larger picture?  
> **username_2**: JFTR: You are likely to find me in the more pro COBOL camp than most out here. But thats because of things like https://www.theserverside.com/feature/How-COVID-19-created-a-demand-for-COBOL-basics. Not the good course I had in student days!  
> **username_4**: @Rusi: I understand your point, and it is sort of why I avoided concrete stating what OP's course goal is because this can change the consideration. But given OP is talking about assignment and variables; I infer they're thinking about a programming course, in which I don't think such low level constructs meaningfully teach a student how to write software in the relatively high level languages we use nowadays.  
> **username_4**: @Rusi: Even 10 years ago, my college gave us a week of COBOL and FORTRAN (each) as part of "the basics". While interesting, I don't quite agree that it is _relevant_ in today's development ecosphere. You are correct that some governmental applications still rely on ancient codebases; but I don't think you can correctly extend that to needing to include it in your average curriculum. It's a dying breed (although it's taken longer than it should to die out), and it's akin to requiring architects (building, not software) to learn medieval housebuilding techniques because of some old churches.  
> **username_2**: Course goals can — and should — span a range from effective doing to up the [DIKW ladder](https://en.wikipedia.org/wiki/DIKW_pyramid). (From my pov) the difficulty with OP is that he is right in demanding more stuff up the ladder. And then suggesting that imperative programming is fine!!  
> **username_2**: Well... Thats a different argument: (In my book) Java is more obsolete than C++. And C++ more obsolete than C. Java has exactly one useful concept — interfaces. And one genuine use case — android. A choice which has cost google a billion dollars. But this is an argument for a different place... When a company spends to the tune of a billion dollars to advertise a technology, it behoves academics to be suspicious of it https://www.theregister.com/2003/06/09/sun_preps_500m_java_brand/  
> **username_4**: @Rusi: I think this cycles back to the goal of the curriculum. Based on OP's "assignments and variables" mention, I'm still in the mindset of a basic programming course, where such deep specifics and niches are a bit overkill. Not saying it won't be valuable to _anyone_ but I am suggesting it will only have value to a limited subset of people, limited enough that this course is likely not the time and place for it.  
> **username_0**: I agree with Father's first paragraph, however, there is an overriding consideration for software. A similar case is Weather: the most important fact in weather is the energy of phase change of water. Without knowing how much that makes weather what it is, you essentially know nothing. Without knowing how a machine can choose and then affect the world, you know nothing. It is really as simple as that. An auto mechanic who didn't know that gasoline is flammable *and* explosive would be a danger to themselves and others. We are training software *mechanics*, not drivers.  
> **username_0**: Someone saw fit to make software that changed where I wrote username_4 above to father. You are a bad mind-reader!  
> **username_4**: @ScottRowe: Your analogy is IMHO flawed, as your weather scenario involves investigating the root cause (energy of phase change of water) of the effect (weather events) you're predicting. "What makes a computer different from an electrical device" is _not_ a root cause to learning how to write software. At this point in time it is an esoteric and superfluous piece of trivia that does not directly drive knowledge on how to write basic code. Picking up your analogy, I'd counter that you don't need to know the energy of phase change of water in order to correctly use a barometer or pluviometer.  
> **username_0**: But why would you even need to use a barometer if there was no water in the air? Why would we even bother to teach programming if a piece of metal was not in some mysterious way different from all other pieces of metal in being able to answer questions, decide and act? It is simply that people are not sufficiently grateful. They are asleep to the miracle and inured to how much our lives have been altered by it, in good ways, but now also harmful and dangerous ways. I have nothing more to say at this time.  
> **username_4**: @ScottRowe: Education does not have to occur chronologically. Just because it is relevant in the complete understanding of how everything works does not make it relevant for the first X hours of basic education. Our bodies are the result of evolution over milennia but you don't need to know the physiology of a Neanderthal when studying medicine. You're arbitrarily drawing the line at what makes a computer a computer; but why draw the line there? Why not draw it at mining silicon, or the physics behind electricity? You're conflating what you find interesting with what is educationally relevant.  
> **username_4**: @ScottRowe: If you were to require that every underlying principle going into X should be taught when teaching X, then education would stall as time goes on and technology progresses; and you'd be adding _tons_ of details that would simply overload beginner students and negatively impact both their learning and their desire to learn. I'm not saying it's not an interesting topic, I'm saying that it's not educationally relevant to bring up from the start, and can be left as an optional piece of trivia or a more advanced deep dive when the basics have already been taught.  

---

### Answer by username_5 on 2022-01-11. Score: 4

First, I am not sure what the five operations you mention are.  And, or, xor, not are only four, and if you include the negations, you get nand, nor, and xnor.  I don't know whether you mean to move higher or lower on the abstraction ladder when you say "five operations".
Here are some possibilities:

The point at which is all becomes concrete is, I suppose physical chemistry, but I don't think you intend to start there.

Real computer pretend to be modified Turing Machines, but of course, real computers are strictly less powerful because they lack infinite memory.  In reality, they are actually very, very large Finite State Machines.  Do you mean to start there?

Do you mean to start with binary and arithmetic?  We are already quite high on the abstraction ladder at that point, since numbers as humans intuitively understand them don't really exist in the computer in any meaningful sense.

Do you mean to start with fetch, read, write, execute?  (I'm guessing not, since you referenced five things, and that is only four.)  Again, we're already far from anything concrete at this point, and we are also far lower than anything you'll see in an assembly language.  If I have my students begin here, they are not only entering at a highly abstract place, they are entering at an abstract place that has (a) gotten hard enough that it becomes hard for beginners to figure out steps on paper, and (b) is also low enough that it's also hard to see how a statement like print("hello world") could possibly map to it.

Do you mean to start with program stacks?  Stack and heap?  Simple CLI stuff?  Stdin, stdout?  When you say "how assignment functions", this is my best guess for what you intend.

Do you want to start with assembly?  It's very, very, very difficult for a beginner to make sense of something as simple as
`mov rdi, 1        ;   STDOUT_FILENO,` 


Do you want to start with "hello world" in C?  It's a natural point of entry, but of course, by the time you're there, you can't see down to the boolean algebra at all any more.  But at least you're in a procedural programming environment, so you can loop, call functions, and do a myriad of other things pretty easily.

Do you want to start with a higher level language like Java, Ruby, JavaScript, Python, Haskell, Scheme, or Prolog?  You're now in the world where students can immediately learn to do things that might matter directly in their lives.  But, of course, all of these languages are layers and layers and layers and layers of abstractions away from the "computer".

Do you want to start with software engineering, and hit clean coding and objects and object patterns from day 1?


So the first problem, and I really mean this: I have no idea what you're talking about when you say "computers can do five things" because I'm not aware of any layer of abstraction that has five things.
The reality is that, as a teacher, you can enter at any of these points.  But then you must work students slowly up and down from whatever point you have chosen, until the students understand every one of these layers.  (And make no mistake: that is the goal.  Students should understand all of these layers at some point or another.)
What you presumably don't want to do is take more than one point of entry, and then leave the work of linking them until much later.  (You might have to do this from time to time, but it should never be the goal, and you should make efforts to minimize the amount of time within the linking period.)
So, for a teacher, the natural question becomes "at which point should I make my entry?"
It's an important question, and one that real teachers hotly debate.  Most of us have settled roughly in the C-to-(whatever high level language you choose) spectrum as the initial entry point, but it's not universally so.  Some teachers begin with something called "Objects first" which pulls students to an even higher level right from the start.  Some teachers begin from a more electrical level, such as Raspberry Pi, and work their way up from there.  Everyone can make a case for why they believe they are starting in a good place.
In truth, you can make a case for almost any point of entry. I think that people tend towards the higher levels of abstraction at the start because (1) kids in real life enjoy it and find it rewarding, year after year, and (2) it provides rich interactions with the computer that lend themselves to future explorations, no matter what the student's interests are.
In a very practical sense, I have students who gravitate towards processors and security.  I have students who gravitate towards UI and UX.  I have students who gravitate towards game programming.  I have students who gravitate towards game design.  I have students who gravitate towards web apps.  I have students who gravitate towards theoretical CS and mathematics.  If I have 30 real-life students, they will have 30 different centers of gravity in CS, so I want a point of entry that helps as many of them as possible towards their interests as fast as possible.  If I start at NAND gates, I do a disservice to my UX students, since it'll take them an extra year or two to get to the beginnings of what they want.
Does that make sense?  I'm not aware of anyone who argues that students shouldn't learn about every one of these layers, but there is a question of what order is most productive, a further question of what order helps students start learning about the things that interest them as quickly as possible, and a third question about what order helps students to learn things "best".1
1 - "Best" is also controversial, because people have radically different ideas about what the end-goal looks like, so the term cannot be well defined among the population.

> **Comments:**
> **username_0**: Fetch Store Arithmetic Test / Compare Jump - these are things people can relate to, they are part of real machines and they're sufficient. "*More than this comes of evil.*" Can we agree that bridging this to the CPU would satisfy most kids? Could you do that once and for all, right at the start, and that it would prevent huge amounts of misunderstanding? So... Do.  
> **username_8**: @ScottRowe Interesting abstraction layer. Each of the five 'operations' is an abstraction of its own, again demonstrating the fact that we, as humans, are driven to abstraction.  
> **username_5**: @ScottRowe I teach that stuff in my processors elective, but modern computers don't do these any more. The processor isn't even aware of RAM addresses in modern computers. There's a whole other architecture to deal with read and write that starts with paging and ends in security measures. I'm not trying to be obstinate. I genuinely feel like the abstract layer you hold up as the most important just *isn't* the most important, nor the most helpful. I can't speak for every population, but I can say with certainty that the population I teach would not be happy if I started where you suggest.  

---

### Answer by username_1 on 2022-01-11. Score: 3

While it is possible to do as you suggest, and many people do it, I question its wisdom. There are many aspects to consider.

The most important, however, is that if you are teaching CS then the likely most important idea (meta) is abstraction itself. CS is full of abstractions, with programming and programming languages being one of the key elements and so, is a good place to introduce it. In fact, having experience with both, it is abstraction that is fundamental to the overlap between mathematics and computer science. They differ in many ways, but share abstraction as a goal as well as a tool.

If you try to avoid an abstract view and try to make everything as concrete as possible then you are doing the students a disservice in the long term. If that concrete view were necessary then there would be no reason for high level languages.

As humans, we depend, fundamentally on abstraction in our human languages and in our interactions. It isn't a foreign concept as it might be to a chimpanzee. Computer languages exploit what the forebrain does best.

Note that your conception of a machine is wildly outdated. It is, in fact, just an abstraction. There was a time (more than half a century ago) when such machines more or less existed, but no more. Others here have commented on the differences. You aren't describing a machine, but an abstraction of a machine to which computation can be reduced. But a Turing machine is, itself, such an abstraction.

Almost all modern computer languages (some special purpose ones excepted) are *Consistent* and *Turing Complete*. The implication of this is that you don't need to go outside the language to explain computation. And, doing so can be a distraction from learning to use the paradigm represented by a language properly. You don't need to know how a "variable" in Lisp is represented to program effectively with them. You don't need to know the internal representation of lists (which might actually vary depending on the efforts an optimizing compiler might take.) to manipulate them. In fact, trying to reduce the Lisp notations to the actual actions of a physical machine is going to inhibit the learning of a novice.

Certainly, by the time a student has a rich and complete education, they need to explore many of the abstraction levels used in computing. They probably also need to know something about the mappings between the levels if they are to extend the field as researchers. But the first course is not the place to do that if it forces them to try to write every Java program as if it were a C program or even a minimal (abstract) assembly language program. The compiler course will explore those issues once they have a foundation.

So, as the [answer of username_5](https://cseducators.stackexchange.com/a/7228/1293) suggests, you can start at pretty much any level of abstraction for the first course, say the OO level, which I tend to use. Stay with that level and show that any program can be written thinking about the abstractions and tools available at that level *only*. Use good metaphors for things, but treat them as metaphors. You don't need to leave that level to explain what a variable is, for example.

---

One of the reasons that people continue to suggest that this mapping **must be taught to novices** is that many teachers, having learned the field over a long period of time, actually grew up as the world of computing was changing, from simple machines and languages to richer and more useful ones. So, we learned low level stuff early on and that "helped" us when we moved to higher levels. It formed a base. And so, too many of us, in effect, teach with a historical view and ask our students to follow the same low to high path that we did. But, you don't need to recapitulate the history of computing to grok Python or Scheme. They are, remember, consistent and complete. In fact, if you try to do the *entire* history in the first course then the course will last for more than half a century and when you finish the course the students will be half a century behind the times. I've been doing this for half a century myself and I've learned a heckofa lot. But most of what I've learned is actually obsolete.

Pick an abstraction level (i.e. a paradigm). Pick a good language to represent that level. Teach **that**, so that students have the skills to understand computation at that level. Leave that level only with metaphor or with anecdotes, not to 'splain how it *really* works. Because it doesn't *really* work that way at all if you have ever peeked at an optimizing compiler.

The goal is insight.

---

There are two Lisp list functions that I find instructive for thinking about the functional paradigm. Neither requires any machine view. Both require some essential *insight* into functional programming. The two functions are to *clone* a list and to *reverse* a list, both in linear time. If you don't care about time, both are easy, but you need to think like a lisper to grok these. Try them.

> **Comments:**
> **username_6**: Good answer. I'll just remark that your "One of the reasons" section can be characterized as "Pedagogy recapitulates ontogeny" and that most people think this is bad. "most of what I've learned is actually obsolete" That takes courage to admit. I usualy don't come further than to say "I'm waiting for the concept of XYZ to make a come-back" :-)  
> **username_0**: As we develop more levels and abstractions, I think it's important to have a through line that terminates on something real, so that if you ever do need to start a car with a pencil or broomstick, you can.  
> **username_0**: When I first learned Lisp, around 1985, I thought it made sense because it was built on car, cdr and cons, which all related directly to machine operations. I could see the exact interface where the machine met the language, the hoofprint where the winged horse struck off. But 300 pages later in SICP they jump out of a perfectly good airplane, which we realize was never going to leave the ground. If Lisp is based in simplicity, and I am arguing for simplicity, why didn't Lisp live up to its promise after 60 years? If it is a good starting point why doesn't teaching start there?  
> **username_2**: @ScottRowe Your last 2 sentences/questions are on point.  Perhaps the best answer in a short space is *Lisp fell between 2 stools* To the mainsream imperative programmers Lisp looks too weird and by implication mathematical to be useful. To the functional programmers (in 2022) Lisp is not a functional language but more or less python/ruby/javascript with idiosyncratic syntax.  There are other answers of course like *Lisp didnt live up?!  Look at clojure*  But I dont like this answer because the battlefield of TIOBE indices is unsavory to settle pedagogical questions.  
> **username_2**: Remember Fortran was functional in 1957. And Haskell will give way to Idris(ish) Agda(ish) in 2030 if I peer in my crystal ball. Lisp was FP between 1960 and 1980. From 80 it coalesced into Common Lisp plus Scheme. And after "Real World Haskell" I'd say the mantle passed. [JFTR: I love scheme and think Haskell has missed the boat/point. I'm describing the status quo not my preferences] As for SICP dropping subst model at pg 300 just switch to Haskell — there simply is no imperation/mutation ie Lisp's informal culture of FP gets baked into Haskell's formal semantics  

---

### Answer by username_9 on 2022-01-17. Score: 2

I teach year 8, some of this: Boolean logic, combining Boolean logic to make a memory bit, and an adder. We also go the other way to discover how to make logic with dominos, switches (Shannon), cogs, etc. However the bottom up approach is not the best way. Noor is the top down. You need both. Many CS principles are true independent of how they are implemented.

> **Comments:**
> **username_0**: So teach the principles.  
> **username_9**: @ScottRowe `and` and `or` are true no mater if done with transistors, or cogs. Pattern matching and arithmetic are true no mater if done with Boolean logic, or the way (one of the ways) you learnt in maths class. The principles are up the abstraction. AN implementation is down. Yes teach implementations as well as principles, but don't teach that it is the only implementation, or that it is fundamental. It is not. We have many ways to implement it. For now it is CMOS transistors implements Boolean logic implements, adders, multipliers, etc, implements ...  
> **username_0**: I often wonder what will come next, it will be fascinating to see. But *for now*, it makes sense to simply pull the curtain back for a few minutes and show what the thing is doing. Some day, it might well be beyond human understanding, once computers start evolving themselves. Blink and we could miss it.  

---

### Answer by username_6 on 2022-01-11. Score: 2

Maybe you have a point that there is a level to the hardware that is explainable. However, I don't see how it enlightens the use of a programming language.

Besides, I don't think you realize how much the explanation that you seem to be proposing is also an abstraction. How precise are you going to explain how a computer works? Independent functional units? Branch prediction? Out-of-order execution? Clock domains?

> **Comments:**
> **username_0**: It enlightens the programmer, or in this more important case, the student. It only need be precise enough to get the point across, like all other human communication.  
> **username_6**: But then you're back at my previous statement that the syntax/semantics of the programming language is precise enough.  
> **username_2**: «*The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise*» That's Dijkstra again!  Though I agree with @ScottRowe more than he realizes . If you need to talk of memory you basically need a machine model.  The crucial difference we have is that he thinks its necessary, inevitable. I know its not necessary in a pure functional language.  But if you take that as too fringe for serious consideration (better than not knowing abt it at all!!) then you implicitly prove his point  
> **username_0**: @VictorEijkhout The language cannot explain how it can affect the physical world, so more is needed.  
> **username_0**: @Rusi "*Everyone* talks *about the weather, but no one* does *anything about it!*"  
> **username_6**: @Rusi The machine model you refer to is the Von Neumann architecture. And a lot of the misery in my field of high performance computing is that the instruction set of a computer offers a Von Neumann API (so to Scott the CPU indeed looks simple) while underneath is a whole bunch of magic (see the random keywords in my answer) to make it look that way, while it isn't remotely that.  
> **username_2**: You [too](https://cseducators.stackexchange.com/questions/7226/driven-to-abstraction/7229?noredirect=1#comment18954_7233) are proving @ScottRowe point more than you probably realize. My restatement of point: We have too many layers of abstraction. If theyre not working why aren't we rethinking them? Ans1 (cynical): Because no one's in charge.. Ans2 : (enthusiastic) cutting edge research is all the time just doing that! Join the fray! I guess the truth is in between?  
> **username_2**: Case in point:  I had a friend who did his PhD in getting past Intel's cache hierarchy. Don't remember the details. But the summary is quite aligned to @ScottRowe : We make fancy abstractions. Then we do PhD's getting past/gaming them. Why... Why? Ans:Because there's no "We" at least in charge  
> **username_0**: @Rusi Yes. Someone is in charge of flying a plane. Should computers be able to contradict them? Then who's in charge?  

---

### Answer by username_0 on 2022-01-16. Score: 1

We have before us a question that is apparently of very little interest to almost everyone:

> What makes this particular machine that is powered by electricity different from electrical machines that don't answer questions?

We know that computers manipulate symbols. How do symbols touch the world and cause lights to go on, cars to turn left, nuclear missiles to leave their silos...? It seems like an interesting, important, urgent question, which is a deep part of the reality humans have constructed for a couple lifetimes. And, people, especially students and teachers of computer related subjects, yawn and look at their iPhones instead, perhaps to order something to be delivered. Or turn off the light they left on at home.

I am tempted to simply leave the world to its fate, except that I am stuck here with you, and your choices and knowledge affect my future. So I selfishly try to get you to wake up.

Someone said that **systems with too many levels are difficult to reason about**. It was probably someone in the CS field, so you can argue with them if you disagree. Someone else said that we learn from the concrete to the abstract, the particular to the general, simple to complex. All I am saying is that the point where symbols affect the physical world is pretty definite, and without that in operation, we wouldn't have to worry about things like missiles unintentionally leaving their silos, or automated cars hitting people. That seems to me like the place to start teaching, just like you start shop class in a shop. *Don't put your hand on that!* Sorry, back to what I was saying...

In the book **Rationality** by Steven Pinker, he says:

> The moral is that reasoning with logical rules at some point must simply be *executed* by a mechanism that is hardwired into the machine or brain and runs because that's how the circuitry works, not because it consults a rule telling it what to do. We program apps into a computer, but its CPU is not itself an app; it's a piece of silicon in which elementary operations like comparing symbols and adding numbers have been burned.

If you don't think that this is the vital thing to know about a computer, I am not sure why, but you could take it up with him, as he is a more successful reasoner than I am.

> **Comments:**
> **username_2**: At the CS level we could go over these points. But this is more meta than your original q and may better be there??  
> **username_5**: You cannot articulate an outcome advantage, so you instead ask, *isn't it good that someone cares about this?*   Was the original question largely rhetorical?  If so, then do not say that others could not persuade you because their reasoning was not sound, because in truth, you came to it with a closed mind and could not ever have been persuaded.  (There is real wisdom in some of these answers, and I hope you do come back to them in time and think about them more carefully.)  
> **username_5**: That last comment was not to attack you, but to prompt you to honestly consider your motive in asking the question.  Were you trying to learn, or trying to persuade?  
> **username_5**: Also, on a moderator note, if someone has attacked you (and not just your idea), please flag it. (Including, I suppose, my own comment above us if you believe it to be an attack. We have multiple moderators, and I certainly do not handle flags on my own work.)  
> **username_0**: @BenI. I had originally asked this Question on Meta, and I wish that had been respected. As for me being able to be persuaded, no. See my comment to username_4's Answer where I mention Weather. This fundamental knowledge is not optional, it's the whole point of how computers got created. Somehow people have lost sight of this. It is baffling to me, like forgetting to realize that food dishes were made because we need calories, not to look good on the plate.  
> **username_5**: @ScottRowe It's not a question about the governance of the site, so it's not meta.  
> **username_5**: @ScottRowe That analogy is bizarre.  One is about *purpose* of the action, and the other is... not.  At all.  We did not create computers with the PURPOSE of making "five" operations.  You're examining an implementation detail at one level and declaring it to be the most important, most fundamental point.  It's important!  But it's one level of abstraction, and in spite of your protestations to the contrary, it's *not* where the physical meets the computational, and it never has been.  
> **username_5**: You are keenly intelligent, but I find your inability to "see" even the most basic fact patterns and baby-basic facts about this topic frustrating to say the least.  You confidently assert things that are strictly and obviously incorrect, use those assertions to justify your position, and refuse to see otherwise simply because you refuse to see.  You have Made Up Your Mind.  This was never a reasoned discussion because you were never intending to be reasonable.  I find your intransigence frustrating, so I am going to disengage now.  I am done discussing this topic with you.  
> **username_2**: I side with @BenI on the facts  (90%). And with Scott on the emotion 95% — if Sturgeon's law is a universal truth how come we don't apply it to CSE? ...whence it becomes a Meta-CSE question  
> **username_2**: Re new additions: Yes its true @ScottRowe : Some of the most significant innovators in CS have been motivated by AI considerations. Off the bat I can think of Turing, McCarthy, Minsky.  All these were primarily interested in AI but their contributions o far beyond. I particularly recommend Minsky's [Turing Award](https://amturing.acm.org/award_winners/minsky_7440781.cfm)  
> **username_0**: @Rusi Ok, I wasn't thinking about AI particularly. Rather Ada Lovelace's insight about representing symbols as numbers then conveniently meets a number handling tool, and a completely new world opens up. But that doesn't mean that the people blind to that stunning change-point will get it. I have a friend with 2 PhDs, a major book and 4 patents in information algorithms, but as far as I know everyone is ignoring her. "*See and see but do not perceive, hear and hear but do not understand*"  
> **username_6**: If you think a CPU is not an app, explain to me what branch prediction is, prefetch streams, out-of-order execution. Transcendental function through look-up tables & iterative refinement. Hashing functions for address translation. Your CPU is full of algorithms that address the deeper levels, invisible to us.  
> **username_0**: @VictorEijkhout Those things are not *necessary*. We need to start teaching with what really *must* be there, because it's the place to start. There was a really cool book by a ship captain called, "First you have to row a little boat". I don't see people in other fields with this delusion, early math doesn't suffer with the urge to impart Ramanujan's findings, or physics throwing General Relativity at early students. People in CS seem just very bewildered. Maybe they didn't learn the basics first?  

---

