Driven to Abstraction

Question

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?

Answer 1

Buffy Ben Victor Eijkhout 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

Answer 2

Why 5 operations when one suffices??? (The subsection of above 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
• I don't need to waste my time with a computer just because I am a computer scientist Dijkstra
• Machine -- imperates
  Programmer -- declarates
  Language -- relevates
  R Mody
• 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

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.

Answer 3

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".¹

¹ - "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.

Answer 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.

Answer 5

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 Ben I. 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.

Answer 6

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?

Answer 7

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.

Answer 8

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.