The Phonics of Computing Education
September 22, 2009 at 7:39 pm 39 comments
In 2005, Merrick Furst (then, our associate dean for undergraduate education) said to me, “I think of your Media Computation and contextualized computing as a kind of ‘whole language‘ approach to computing education. What are the phonics? What’s the computer science equivalent of the scales and etudes that musicians practice with to get the basics down?” At the time, I replied that getting students to understand why they’re learning to program, the relevance of what we were teaching them, was the most important factor. I still think that. But I’ve been pondering the phonics question for the last four years.
I was reminded of that question when listening to the NPR report on the end of PBS’ ‘Reading Rainbow.’ The beginning of the report chalked the demise up to a lack of funds, but as it went on, the report really sounded like a change of heart at PBS–driven by research findings.
“Reading Rainbow taught kids why to read,” [John] Grant [of WNED Buffalo] says. “You know, the love of reading — [the show] encouraged kids to pick up a book and to read.”
Linda Simensky, vice president for children’s programming at PBS, says that when Reading Rainbow was developed in the early 1980s, it was an era when the question was: “How do we get kids to read books?”
Since then, she explains, research has shown that teaching the mechanics of reading should be the network’s priority.
“Teaching the mechanics” — that’s what the “phonics” of computing education is about. Context tells us why. The mechanics tell us how.
We do a lousy job of teaching the mechanics of programming in computing classes. Our traditional tools of teaching programming are lecture and student practice with the interpreter or compiler.
- Pair-programming is just a twist on the student practice that doesn’t make the mechanics easier.
- Think about the perennial problem in Java of learning where to put the semi-colons. How do we help with that? We lecture on where to put semi-colons — yeah, we know how effective that is. We show example code — better than just lecturing, but since our assignments are rarely modification of code, students are mostly dealing with semi-colons on a blank sheet. Then, we throw students to the Java compiler, whose error messages in response to a missing or misplaced semi-colon are awful.
- Visual languages like Scratch or Alice reduce the mechanics. For CS students, they just postpone the inevitable. I don’t know of any evidence that the mechanics are easier in the textual language after facing the visual languages.
If the research on reading applies to computer science, then we ought to be doing much more to convey to students the mechanics of programming. What kinds of mechanics are important to teach? I’ve thought of three, and I’d really appreciate hearing your suggestions on others:
- The syntax of the programming language. I understand (somewhat) while error messages in the full compiler can’t be made much better. But surely we can build tools/tutorials/drills/etudes where students could practice the nitty-gritty details of language syntax with better feedback than compiler error messages. I feel guilty every time my Python students get the indentation wrong in their programs, because the error message is about quotation or indentation errors “somewhere around line X.” Surely I could build something to help them learn indentation short of tossing them in front of a speeding interpreter?
- How to read code. Everyone who comes to lecture gets to see and hear how the lecturer reads code. All 30% of them. There is a skill to knowing what to attend to in a program. Everyone knows to simply skip “public static void” in the main method of a Java class — everyone except the novice who doesn’t know which words are important and which can be safely ignored.
- How to tinker with code. Given a piece of code that you’re trying to understand, you know where to put print statements and what constants are worth tweaking to see the impact. How does a novice know that? We know that changing “i” to “j” as the index to the loop isn’t all that useful. How did we learn that? How do we teach that?
These activities are in the class of things that we experts never think about. They’re the “obvious” things that we simply ignore. Exactly! That’s what the “phonics”/mechanics are. How do we teach them? As experts, we know to simply ignore those matters and do them without thinking. As novices, they are yet another distraction, and cognitive load theory suggests that those “distractions” add up. In the end, we only have 7+/-2 chunks — that’s a human limit, and all those distractions are chunks that quickly add up to an impediment to getting at the learning we care about.
These “phonics”/mechanics are important, not just for the novice, but for the expert who is trying to bring herself up to speed on the latest technology. The practicing programmer who wants to learn Ruby or Scala doesn’t need to know why to program in these languages — she already has that. She wants to know how. She wants the mechanics of the language. Research on how to teach “phonics”/mechanics of a new language would go a long way towards bringing her up to speed on the new technology. (I’m choosing “she” in these examples explicitly because I’ve been thinking for a year now about the implications of Caroline Simard’s report for the Anita Borg Institute on the needs of mid-level technical women in IT.)
Teaching the “phonics”/mechanics of computing education is on my mind a lot these days. I’m thinking that it may be our most significant point of leverage in improving computing education. New curricula may not get adopted. The phonics of computing education crosses all curricula. Getting the phonics right helps both the novice and the practicing programmer learn new skills. Done right, phonics can be taught self-paced, even via distance learning, to act as a supplement to existing instruction. I still think that the context is our most important change to improve computing education, but teaching the phonics/mechanics well may be the most universal improvement we can make, the one that can help everyone regardless of curriculum.
Entry filed under: Uncategorized. Tags: computing education, phonics.
39 Comments Add your own
Leave a comment
Trackback this post | Subscribe to the comments via RSS Feed
Computing Ed Research - Guzdial's Take 
1.
Mark Miller | September 23, 2009 at 3:13 am
I’m glad you’re thinking along these lines, but to me phonics is learning the pieces of language at their most basic level. The only equivalent I can think of would be programming in assembly language, or in bytecode. There, you’re dealing with the most basic operations that run the machine. Each expression in a HLL is carrying out some combination of these instructions, rather like a word in English.
I think one thing that the old style Basic got right was that you could start right into doing something, dabbling, without having to have framing around what you’re doing (like in Java). Perhaps Python is like this as well. For example the first thing that a Basic student is taught to do is how to print something to the screen with the Print command. This gets students used to the idea that they are controlling what the computer is doing, getting it to repeat what they give it. The next thing they do which is kind of fun is to implement a primitive loop:
10 Print “Hello”
20 Goto 10
This gets them used to the idea of controlling program flow and its effects. Next they learn about variables. This starts to get tricky in some languages because they’re strictly typed, and therefor they also would need to learn about the concept of types. Old Basic actually made this a little easy, because it allowed implicit typing between integers and floats, and they didn’t need to be declared before they were used. They can get the idea of manipulating a variable by doing this:
I = 1
Now say:
Print I
Output: 1
This is a good time to differentiate between literals and variables.
Try this:
I = I + 1
Print I
Output: 2
It’s helpful to explore the assignment for a bit. “What does ‘I = I + 1’ mean?”
Next they can try a primitive loop, putting the above concepts together:
10 I = 1
20 Print I
30 I = I + 1
40 Goto 20
Next they can get the idea of controlling this loop with a conditional:
40 If I < 50 Then Goto 20
You can explore some interesting questions with this example:
Why did the program print the numbers 1 to 49?
What is the value of I when it comes to the "If" statement for the last time? (Or, "What is the value of I when the program is finished?")
For the answer they could type this after running it:
Print I
and they'd get the answer: 50
Why did this happen?
This introduces them to the idea that what they see happen on the screen is not necessarily connected to what's going on inside the program. This particular concept is one that every novice needs to learn (referring to your example that "switching the i and j indices doesn't change the way the program operates"). They may need to see more examples of this. I know I did when I was first learning.
Another thing to try is starting with a new program have them try:
10 Print I
20 I = I + 1
30 Goto 20
Have them run it and see what happens.
At least in Basic it would give them an error message related to an undefined variable.
Why did this happen?
Once they understand this, then they move on to formal loops, like:
10 For I = 1 to 19
20 Print I
30 Next I
To help cement the concept the same questions could be asked. This would also be a good time to introduce the idea of "chunking". People are able to look at a grouping of objects and assess something about them quickly. Computers deal with groupings through a "window" that "moves" in increments through them.
The important thing is to discuss the underlying concepts of what's going on inside the program, to get beyond what they intuitively think the language is telling them.
The way I introduced myself to the idea of procedures/functions and parameters was to use the Gosub command in Basic to “goto a subroutine”. And I’d have a set of variables that I used exclusively with each routine, which introduced the idea of parameters to a procedure. Once I got used to that then learning about procedures/functions in a language like Pascal came pretty easily.
Unfortunately they will have to learn to “divine” the meaning of error messages. It’s something that professional developers often have to deal with.
What I found was the best technique for me was to not get too sophisticated too quickly, because that would introduce too much to learn all at once. When I started to get into more substantial programs in Basic that would do something worthwhile, I would often start out not using anything more than simple commands in a straight linear stye. My programs got long in lines of code, and repetitive. I would repeat a block of code, but modify it a little to do “the same thing, but a little different”. They were very simple in structure. Once I got the program working I started seeing that there were patterns in these code blocks that I had copied over and over, and had modified a little bit each time. I realized I could optimize the structure. I could start to parameterize the code, and thereby make it more compact. This is a good practice anyway. Professionals do it. It’s called refactoring.
The big difference with today’s development environments is they offer much better debugging tools than I had. I think the way to get them started with learning debugging is to get them watching variables as programs run. Watch what happens to them. Give them some broken code with a small number of lines of code, and have them figure out what’s wrong with it. I suggest this because if you get into having them do projects right away they’ll generate PLENTY of their own bugs, but probably ones that will be hard to figure out. Giving them small problems will help them ease into learning about problem situations and how to solve them.
Anyway, hopefully you can glean something useful out of this.
2.
Mark Guzdial | September 23, 2009 at 6:58 am
Mark, think about the two analogies: scales and etudes in music, and phonics in reading. In neither of these is the student activity the real activity. Neither programming in Basic or Assembler is at a simpler mechanical level for the human, just for the computer. I’m thinking about tutorials, even drill-and-practice — smaller activities than actual programming, something where we can give more fine-grained and more helpful error messages. “It’s something that professional developers often have to deal with” is not a reasonable excuse for why we can’t give students better explanations for their mistakes.
3.
Mark Miller | September 24, 2009 at 2:12 am
Alright. I think I see something of what you’re getting at, a learning/tutorial environment. It reminds me of a concept I’ve heard Alan Kay talk about, which is a system that detects the knowledge level of the user, and adjusts its presentation of information to that knowledge level. Such a system doesn’t exist yet.
I’ve seen something similar to what you’re talking about in the IDEs that Microsoft offers, including the free “express” editions. It’s what I’d call “code hinting with tips”. It doesn’t cover all of the knowledge areas you talk about, just the syntax and some of the semantics. As the user types code into the IDE the editor applies a parser to the code (and may even do a little compiling in the background). As it detects syntax errors, including missing semicolons, it puts a red, squiggly underline under the area where it detects the error. If the user “hovers” their mouse cursor over the highlighted area the IDE displays a “tool tip” with a small message about the error. It can also detect the use of undeclared variables and types. The error tooltips were written to try to be descriptive, though they wouldn’t help a novice much.
I think a tool along these lines that has more instructive material built into it is doable, but I think it would be of limited utility. It wouldn’t cover all the knowledge areas you talk about.
Along the lines of the idea I talk about in the first paragraph, I think what would really be better in terms of meeting your goals (if your goal is prepping students for Java) would be a Java-like language that presents a simplified interface to the novice. For example, why teach that “you need to skip over ‘public static void'”? Why not just eliminate the visible signs of these tags from the language at first? Get rid of the concepts of public, protected, private; static vs. auto; void vs. other types. These can all be defaulted. It wouldn’t even be necessary to write a whole new compiler. A pre-compiler could do the job, inserting these elements into the code where needed for the real Java compiler.
As the students learn about these concepts, they can be gradually exposed to them in the language, so they can see how they work. This way there are no distractions in the language/programming learning process, and there’s no temptation to give a shallow presentation of the Java computing environment.
You say in your other comments that a new language would not be constructive, but simply teaching that “public static void” should be ignored is not going to be helpful down the road, either. These tags DO mean something in other contexts. They even mean something in the main() function. It’s just that they’re always there beside the main() function signature, and they always signal the same thing to the compiler. That’s why we ignore them. They become a pattern we recognize, but that doesn’t mean we don’t know what the pattern signifies. Teaching up front that it should be ignored indicates that it doesn’t mean anything to the student. They will get the impression that it’s just something stupid that’s there for no reason. Come to think of it, that’s not a bad conclusion. I’d have to agree, but in terms of learning the language, I don’t think it’s the right impression to give, because the notion that these tags are “meaningless” could transfer to other contexts when it’s important for the student to use them at their own discretion.
In terms of “how to tinker with code”, when you say that we know that swapping the variables “i” and “j” (assuming we swap them everywhere they’re used) doesn’t affect how the code runs at all, this comes from a fundamental principle of variables that programmers know: There’s nothing special about what a variable is called. They’re placeholders for something else. Swapping placeholders everywhere they’re used doesn’t change anything. Swapping the contents of those placeholders might, though. It’s something that students should be taught and allowed to experiment with.
I don’t know that even an intelligent system would be able to tell the difference between a student swapping variable names, mistakenly expecting something different to happen, from a student wanting to change a variable name to something more descriptive, for example. The only way it would know is if the student were allowed to interrogate the system: “I tried swapping these variables. I expected X from doing that. Why didn’t X happen?” The problem is the interrogation would likely need to be done in English, with the system using natural language processing to turn it into something formal that can be interpreted. Since the student is learning a formal language to begin with there’s no point in introducing another one.
An AI system might be able to determine from this query that the student expected something to change by changing a variable’s name. This is in error, and so the student needs to be educated about what variables are, and how they interact with other program elements.
Trying to answer why X didn’t happen is a harder one for such a system, and even if it could help with that, it might end up coddling the student by answering that question. This is something the student should ponder with their understanding of how variables actually work.
You’ve asked another hard question here. 🙂
4.
Mark Guzdial | September 24, 2009 at 9:03 am
I think we’re talking about the same thing now, Mark. We know that swapping the variable names doesn’t matter, but students don’t. I see students trying that and asking about that in the first weeks of class. It’s worth encouraging that behavior, to help students develop the right model. I agree that these kinds of tools don’t help with the kinds of students that Alan and Erik are focusing on, the ones who “are going to make it” (in Erik’s terms). I think that these tools will help student in Alan’s groups 2-3, and maybe 4. These are the students that Leigh Ann, Alfred, and I care about, aiming for computational literacy for all.
5.
Alan Kay | September 24, 2009 at 9:48 am
I’ve been mostly interested in all four of the groups since Adele and I realized in the mid-70s that “10% success” was going to happen regardless of our pedagogy, and that what we should be worrying about is the *rest* of the students who were not as well set up to learn the particular ideas we were trying to put forth.
Our goal then became “90% fluent” in any group of kids. This took more than 25 years to achieve, but did finally happen with the peculiar combination of ingredients, examples, kind of adult help, and general approach that Etoys employs.
This was good — for 9-11 year olds — and some of it still obtains for older children. But not all, and there are important ideas left out which really can’t be omitted when dealing with older students. And the particular history of Etoys — its original planned access through the Disney website, etc. — motivated leaving out a few ideas that we would have included if the aim had been classrooms, etc.
As in the Vivarium project (and its language Playground) before it, the children are presented with something more like an ecology of objects than programs and data. Massive parallelism is built in and automatic, all scripts are naturally set up to iterate, most loops are infinite, etc.
All changes are instant and live, etc.
So the “landscape” is tangible media made by the children — cars, animals, etc. — drawn by them, programming by them, interacting with each other, etc. They learn variables very easily because what is powerful and useful about them is built into the situation they are trying to create. And so forth.
Two white papers on this that might be of interest are:
1. http://www.vpri.org/pdf/rn2005001_learning.pdf
2. http://www.vpri.org/pdf/rn2005002_authoring.pdf
(“Scratch” is another similar system also using tiles to alleviate typing by beginners, and also built on top of Squeak.)
The point of view taken here includes a number of “prejudices”, two of which are:
1. systems thinking in terms of multiple entities in cooperative systems is where we want to get
2. Scientific thinking is the master skill we are after, and we will teach math and computing to support scientific thinking
This is kind of “Seymour applied to science goals”.
An important part of Etoys is that the programming itself is rather low level non-tricky stuff — a line is basically a simple expressions that changes the state of an object property, and a method will usually have several of these that together change the state of the object in terms of relationships between the properties of the objects in question.
This happens over and over with no explicit looping and the result is a “system in process”, usually to act out (simulate) some idea.
The methods start off with no parameters and the properties of the owning objects are used and modified. Later, the ability for methods to have parameters can be turned on, etc.
An important interesting consequence of this approach is that we find the children have an easier time writing parallel code than e.g. nested conditionals. It is easier to have the conditionals in different “processes”.
The basic idea here is to not have a lot of features in the language part of this, but to have very comprehensive powerful and simple ideas of “object” and “concurrency” which are used for all media (including the deconstructable UI itself) and for all things that the children make.
I.e. You can draw a car, get its “halo” of properties, get its “viewer”, one of the supplied behaviors will be “…turn by” (like LOGO’s “right”). The children quickly learn that there are no exceptions to this (the items in the UI of the viewer itself will show a halo and a viewer and have a “..turn by” and can be rotated under program control).
Most adults don’t think to do this because they have been conditioned to think of the UI as being made by gods (if they indeed think it was made at all, most think it came with the computer). But we made Etoys so every part of it can be taken apart by the children to help them with the idea that everything on a computer is *made* and they can be the *makers*.
This is like the old Model-T Fords that farm kids like me in the 30s and 40s could take apart and put together by age 12, as opposed to the impenetrable black box approach of most of today’s artifacts.
And so on and so forth. The idea here is to take the end-users really seriously, then find a few deep points of view that seem most important, then design and build a complete system that caters to both the users and the points of view. (This is likely to work a lot better than trying to squish together a wide variety of prospective learners with pretty bad languages made by people who don’t care.)
Again, just to be clear, I’m not advocating Etoys here for the problem at hand (its aim is elsewhere) but am strongly advocating the approach, and that there are few ideas that look more strongly both to the end-users and to the future, etc.)
Very best wishes,
Alan
6.
Erik Engbrecht | September 24, 2009 at 10:13 am
The funny thing that while in previous discussions I’d say I focused squarely on group 1, during this discussion I’ve been squarely focused on 2-3. 1-2 form the potential CS majors, and 3 the people who could potentially use computing as an effective tool. I consider group 4 by definition to be too expensive to be worth the investment (in other words, someone who could be economically helped is in group 3, not 4).
I don’t think the languages and tools we’ve been discussing would help much with group 1, and would probably annoy them. I know when I was a CS student I would have been annoyed if my first two years focused on a pedagogical language and development environment. But with hindsight I’d say it probably wouldn’t have hurt me and possibly would have helped.
7.
Alan Kay | September 24, 2009 at 10:37 am
Eric,
I think you make a very good point — both points actually.
Groups 2 and 3 really need a fair amount of scaffolding, but with it they will be successful. Group 1 won’t need much scaffolding for the simple stuff, but eventually many of them will become the “main enemy” because “cleverness doesn’t scale” — and it’s often the kids who are used to being the “smartest people in the room” growing up that are so limited when they get out into the larger world (where their chances of being the smartest diminish exponentially). And, as Jim Watson likes to say “If you are the smartest person in the room you are in the wrong room” (and he knows this from first experience).
At some pretty early point Knowledge trumps IQ, and more importantly Outlook trumps Knowledge. That this is not strongly seen or understood in computing is what is killing our field.
Cheers,
Alan
8.
Barry Brown | September 24, 2009 at 1:47 pm
What you’re describing are “language levels.” All unnecessary syntactic and semantic constructs are eliminated at first. They are introduced only when there is a pedagogic need to do so. For example, the concept of “public, private, and protected” are irrelevant until the student has a clear, curricular motivation to hide data and methods.
Language levels require curricular assistance and there is where most efforts fail. Although many instructors support the idea of language levels, few can agree on which features to introduce when. It takes the will of a strong committee of educators to design a curriculum that takes language levels into account.
9.
Tony Forster | September 23, 2009 at 5:55 am
You say “I don’t know of any evidence that the mechanics are easier in the textual language after facing the visual languages”
Which programming language makes it easier for students to learn to program http://www98.griffith.edu.au/dspace/bitstream/10072/24250/1/52212_1.pdf found that visual languages were better for introductory programming concepts
10.
Mark Guzdial | September 23, 2009 at 6:54 am
Tony, the paper you reference (no authors? no institutions?) is a qualitative analysis which placed languages on a continuum. That doesn’t say anything about learning mechanics, nor does it even really say much about what exactly was learned.
11.
Tony Forster | September 23, 2009 at 6:58 am
No it doesnt say all that much but I thought it relevant to the question
“no authors? no institutions?”
J Zagami, Griffith University, Australia
12.
Erik Engbrecht | September 23, 2009 at 7:24 am
Perhaps it would be programming with a non-Turing complete language with a strict, statically typed structure. The required mode of thinking is there, feedback on correctness is immediate, but full range of expression isn’t present.
Unfortunately I can’t think of any right now.
13.
Mark Guzdial | September 23, 2009 at 8:35 am
How about a worksheet where students put the semi-colons in the right place and get feedback on how they did? How about an audio of an expert reading a program out loud as an expert would (e.g., skipping over parts), with a pointer showing where she is in the code? How about a piece of code that students can only modify in certain spots, to scaffold tinkering? A new language means a new curriculum, which will result in the greatest and most important change — 5, 10, 25 years down the road. The mid-level expert who wants to learn Ruby isn’t helped by a new, different language that has easier features. If an educator wants to teach X, she doesn’t introduce a situation with X+Y+Z expected of the student — she has the student attend to X, and X alone. A reading teacher isn’t allowed to change the rules of English just because they’re too hard to learn. While I’d love to see better languages be used throughout industry, the ones that are there will be there for many years. What can we do to help today’s students (novice and mid-level) learn today’s languages?
14.
Erik Engbrecht | September 23, 2009 at 9:41 am
So what is X? Do you want to teach programming, or do you want to teach a programming language?
I’d say students struggle because they have to do two new things at once. First, they have to struggle with the mechanics of the language, interpreter, compiler, etc. To varying degrees, these things represent accidental complexity, but fortunately in many languages it’s rather trivial. Second, they have to contend with actually thinking about the program and its structure. This is the hard part and the essence of the task.
I think challenges like placing semicolons are red herrings. Placing a semicolon isn’t hard. But having the compiler yell at you about a missing or misplaced semicolon while you are struggling to think deep thoughts about the structure of your program is incredibly disturbing. The former is tangible while the later is not, so people latch on to the frustration of the distraction (the mechanics) when their real struggle is with the essence.
The challenge with the mechanics never goes away. Python will give you an attribute error because you mistyped something. Scala will give you a type error that makes your head want to explode. C++ will give you a template error that exceeds the size of your console buffer. The distractions never go away, they just become slightly more sophisticated.
Scales and etudes represent a core on which music can be built. They are a deep part of the essence of music. Placing semicolons and other such mechanics are not part of the essence of programming. They are just artifacts of the language.
Which is why I think the burden of the mechanics needs to be brought to the absolute minimum while the student learns the essence, otherwise the student will confuse the mechanics for the essence. Which, to be blunt, is probably the prevailing attitude among professional developers.
15.
Mark Guzdial | September 23, 2009 at 12:27 pm
I want to teach both, Erik. Students have to be successful at the language to be successful at the programming. Yes, the actual thinking is the hard part. I’m not giving up on the motivation, on the “whole language” aspect of CS. I’m recognizing that the research suggests we need both.
Semicolons are trivial only for the 50-70% of the students who pass CS1. Multiple studies of the non-passers, the ones who leave CS, show that struggling with the language is a major factor in them giving up. (Maureen Biggers’ “Stayers vs. Leavers” at SIGCSE 2008 is the recent paper that springs to mind.) Mechanics don’t go away, but you (for example) never have to think twice about semi-colons — the low-level stuff does go away, and you shift your focus. You figured out the low-level stuff. What do we provide to the 30-50% of the students who fail so they figure it out, too? Now, I don’t believe that we’ll get all those students. But we might make it easier to master the details with some educational focus on them. I want to help students past the mechanics so that they can learn the essence.
16.
Erik Engbrecht | September 23, 2009 at 5:28 pm
I just don’t believe that people are really struggling with semicolons, matching curly braces, etc etc. Or at least not people who are ever going to make it.
I do believe, however, that initially dealing with such things can completely destroy any state of flow that the student may be entering, and thus prevent the high-level of concentration that’s needed to program well.
That why I think such mechanical issues should be addressed by making them go away. “Professional” development environments can be awful for professionals, are extremely complicated even when they do work correctly, and are absolutely unnecessary for learning a language. Most “professional” programming languages are filled with complex rules and idiosyncrasies that can take months to learn to cope with and years to master.
Which is why I’m going to side with Alan and say that a pedagogical language with a simple, reliable IDE is required.
The student shouldn’t have to learn too many things at once. Learning programming, a complicated programming language, a complicate development environment, and sometimes an entire new OS and the command line[1] is too much. Students need something simple without all the alarming accidental complexity that professionals deal with on a daily basis.
[1] My own intro CS class required everything to be done on Solaris. I don’t think this was uncommon at the time, but I don’t think hardly any of the students had ever used Unix before, I don’t think most had much command line experience. (I never had used Unix but was comfortable with command lines) For many just figuring out how to print our a completed assignment, or call the shell script used to submit it, was an adventure. This is probably an example of what not to do, even though I personally thought it was a pretty good intro class.
17.
Alan Kay | September 23, 2009 at 1:27 pm
One of the several questions which seem more pertinent to me than the course of this discussion is: “Why insert any gratuitous difficulties when trying to teach something that is difficult for some people to learn?”.
In other words, there is considerable evidence by now that leaning to program is difficult for some (and also that systems design is really difficult for most).
So why not devise a programming language and an IDE that is ideally suited to the difficulties of the learners, and make it?
—-
The thing that bothers me quite a bit here is that the problems of teaching and learning are encountered within departments which claim to be the holders of CS wisdom and skills, yet almost never do they take the trouble to make pedagogical languages to help many of their students learn. (This wasn’t previously the case — many of the leading universities in the past did make special pedagogical languages just for the purpose of teaching.)
There are no doubt a number of reasons for this, including the idea that “they just have to learn what pros are using no matter how poorly designed and gnarly they might be”, and that “we are a research university, we don’t care about the teaching and learning processes”. And so forth.
But I’m also betting that most of these places would find themselves severely challenged to make such a programming language and IDE for their beginning students. (I don’t think they really know how without doing it the hard (and wrong) way.)
——–
I don’t like “phonics” as a metaphor, but my notions of “5 finger exercises” have been things like:
(a) being able to bootstrap a decent simple powerful meta-translator (such as some descendant of Meta II — now this is easier because of Alex Warth’s OMeta system which is particularly suited for this)
(b) being able to make a decent simple interpreter
(c) being able to make a decent simple graphics system
(d) being able to make a workable recognizer of hand-drawn symbols …
and so forth. These are all one pagers (or close to it) in any reasonable pedagogical language.
In other words, I think the better analogies are to learning basic *musical* elements as very fluent low-level skills, and the real parallels to these are “small powerful ‘nuggets that do’ “.
Best wishes,
Alan
18.
Mark Guzdial | September 23, 2009 at 8:36 pm
Alan, in the previous post (on the “Two Humps”), you suggested that there were three kinds of students, which I’m paraphrasing as (a) those who need a little help to achieve fluency, (b) those that need “a lot of scaffolding” to achieve fluency, and (c) those who need enormous amounts of help. How would you characterize that help or scaffolding? You suggest that the above are “5 finger exercises” — is attempting these meant to be that kind of help/scaffolding? Or is the help starting out with a simpler tool, e.g., like starting with Etoys, then moving on to Squeak?
What I am suggesting as mechanics/phonics/etudes for CS is mean to be that help or scaffolding, the kinds of things that support people in getting past the distracting details and into the deep thinking — which I would think would be a pre-requisite ability to attempt the exercises you describe above.
Cheers!
Mark
19.
Alan Kay | September 23, 2009 at 9:06 pm
Hi Mark,
I was just arbitrarily diving up the student space into 4 categories:
1. very predisposed to getting fluent
2. needs some scaffolding, then can get fluent
3. needs a lot to get fluent
4. needs enormous help (and may not be able to get fluent)
One example of scaffolding could be prior help in mathematical or in mechanical thinking. Etc.
But there are mixed metaphors here. “Etudes” and even 5 finger exercises don’t match up with what “phonics” is about — so I’m basically ignoring all of these.
When I started trying to design user interfaces in the 60s and then at PARC, a goal was to suppress gratuitous difficulties. And it was very easy to see that one big part of designing a programming language is partly a user interface problem (that most languages past and present just flunk).
So I’m arguing for just getting rid of the distracting details as much as possible.
I would not start with Etoys and try to go to Squeak. Etoys is really aimed at 9-11 year olds and does pretty well with them. Squeak is Smalltalk-80 and was a departure from the early Smalltalks that I designed (it is better at power than transparency).
But it would be pretty easy to design and implement a language for beginners which would be as straightforward as a programming language can be, and that would also be a proper subset of a language with much deeper properties.
A committee might have a difficult time with this because there would be lots of dispute between “favorite features” and attempts to look ahead to the next courses. This is one of many reasons why I prefer to design languges for the earlier grades which only have to be powerful for their young users, and not cater to strange ideas of teachers (or students) in subsequent years.
It seems to me that the difficult problem for the questions at hand is to put salt on the tail of the “content bird”, that is, to express what we would like the students to be fluent at by the end of the course, or at the end of their first two years.
There are lots of opinions about this (most of which I disagree with), but once some kind of a picture is agreed on, then these criteria should lead to a language design which can be revealed in pretty gentle stages over the climb to fluency.
To say this again, this has been done well many times in the past (and of course also done badly). But we can take heart from the successes and this should provide lots of motivation for people vitally interested in this set of problems today.
Best wishes,
Alan
20.
Rhodes Brown | September 23, 2009 at 3:41 pm
Mark, I think your observations are timely.
I was following the threads off of your “Searching for a new driver for CS” post and discovered the “Mathematician’s Lament” linked from Ian Bogost’s blog. Initially, I felt this article had a lot to say about current issues in CS Education. However, some of the phrases, which at first seemed clever, have been bothering me over the past couple of days. For example, consider his characterization of lower school math:
Now I realize that Lockhart is trying to be a little overly dramatic, but the comment belies a very important issue. Everyone needs to do some rote learning of symbol manipulation before they can do any significant mathematics. Indeed, I defy anyone to show me how you can discuss any significant, modern problem in physics, chemistry, economics, social science, etc. without the basic language of numbers, arithmetic and algebra. Sure, you might be able to describe the problem, but do discuss solutions you need these basics. So they have to be taught. It’s all well and good to aim for a focus on problems with real meaning and significance, but you need a basic language in which to ground such discussions–and everyday colloquial speak won’t always do the job.
Given this way of looking at things, perhaps one of the issues at the core of the “phonics” challenge in CS is that we are often asking adults to learn in the same way they did in grade 2! I have to say that some of the examples Mark Miller posted above look an awful lot like the things I programmed in grade 3, in Logo (Note: I was fortunate enough to attend a forward thinking school in my early years).
Maybe some find the process of learning a programming language difficult because just don’t realize how simple it is. “…This is a college course–there must be something more to this, some bigger picture that brings all the syntax rules into focus, something that I’m just not getting.” Nope. It’s just like grade 2. Learn your times tables. Learn how to carry the digit in addition. Learn where the semi-colon goes.
Success in CS is, unfortunately, founded learning a lot of symbol manipulations. And learning these basics shouldn’t be confounded with the critical thinking and problem-solving aspirations of higher education. The burden that we face is that, unlike English, or even Math, we have to go over the basics (because they are not currently taught in grade school) before we can move on to fun and interesting problems. The challenge this creates is that students expect more.
Based on this, I would say that the really interesting question for CS educators is not “How do we teach the basics better?” but “How can we do more with less?” In other words, how can we spread out the teaching of the basic “phonetics”, as you put it, and mix in more opportunities to apply the basics early in interesting ways?
21.
Mark Guzdial | September 23, 2009 at 8:39 pm
I agree, Rhodes. Have you read Andy DiSessa’s “Changing Minds”? He’s been arguing for real computational literacy, where bits of real computing are introduced throughout K-12. He’s created a system, Boxer, as a language and environment for developing this expertise.
While spreading out the teaching of computing across a students’ career is certainly the best way to do it, that’s a long term goal. Meanwhile, we need to figure out how to teach these “computing phonetics” even to young children. I think it’s worth trying to define those, so that they’re available to future teachers of younger computationalists.
22.
Barry Brown | September 23, 2009 at 4:57 pm
I’ve been thinking about this very same issue for a couple of years, after watching semester upon semester of students struggle with Java and not getting a whole lot out of it. I believe Erik and Alan have both hit upon solutions which are in sore need of more publicity.
We need a two-pronged approach to help novice students learn the mechanics:
a) Pedagogical languages — not necessarily Turing-complete — that address the learning challenges at appropriate times.
b) Instant feedback.
I’ll talk about (b) first. The first commenter, Mark Miller, reflects upon his early experiences with BASIC. Along with its relatively simple syntax and semantics was instant feedback. There was no need for an external editor, compiler, and runtime library. You just sat down and started programming. You could even try out expression right on the command line, giving you instant feedback about what did and did not work. I think this is crucial to any pedagogical approach.
Contemporary IDEs that have instant feedback include: DrScheme, DrJava, BlueJ, Squeak, Python (command line), Ruby (command line), and SML (command line).
For a whole week my intro students used nothing but the BlueJ CodePad to enter expressions and statements using objects, classes, and variables. They seemed to “get it”. Now they are using the editor to write programs and they don’t get it quite as much, but that is likely a reflection on the increased complexity of the problems.
I believe (a) is another crucial component. Even if we are teaching a professional language such as Java, Python, or Haskell, novices need a syntactic subset of the language that both enforces good mechanics (such as requiring “this” in front of every method and variable, fully-braced if/else statements, and proper camelCase, for example), AND provides error messages appropriate for that specific language subset.
Contemporary IDEs that support language subsets include DrScheme and DrJava. They are a joy to work with.
The novice students don’t mind that they’re not using the full-blown languages. I get resistance from more experienced users who wonder why I’m not teaching the “real” language.
As others have said before me: would you expect a first-year medical student to operate on live patients? Would a first-year mechanical engineer student build a real bridge? Of course not. So why do we expect CS students to use the same tools that professionals do?
23.
Mark Guzdial | September 23, 2009 at 6:15 pm
I love the idea of syntactic subset of the language with appropriate error messages, Barry — thanks!
24.
Barry Brown | September 24, 2009 at 8:56 pm
I must admit to being surprised at your reaction, Mark. Perhaps I am misreading it.
I’ve been working with — and advocating — language levels for several years. It’s become such a no-brainer for me that I’m honestly taken aback when others don’t have the same idea. I’m glad to see that you’re receptive.
Surely this is not the first you’ve heard of it, is it?
25.
Erik Engbrecht | September 23, 2009 at 6:24 pm
I love the med student analogy and mechanical engineer analogies.
26.
Mark Guzdial | September 24, 2009 at 9:50 pm
I am familiar with language levels — I’ve been a fan of DrScheme for many years. I’m thinking of something simpler than language levels, e.g., combine the language levels idea with these calls for non-Turing complete languages. Language Levels suggest, to me, that there’s a complete interpreter/compiler there, but we’re only showing part of it to you. I’d like to tone the language down even further, and give even more detailed error messages.
I’m imagining active essays with challenges/exercises/puzzles embedded, where the answers are bits of language code — they might actually get executed, but it’s definitely not a full Turing-complete language. The error messages can speak not just to the code entered, but to the context of the puzzle or essay. Language levels are fine, but the approach that I’m looking to explore is closer to a new kind of textbook/workbook/essay than to a new kind of language or IDE.
There are lots of ways to approach these issues of teaching the mechanics (phonics/etudes) of programming. Language levels do make sense. This discussion has generated some wonderful ideas that are influencing how I’m thinking of the problem — thanks to everyone contributing! The particular audience I’m most interested in (e.g. the students at 3 or 4 on Alan’s spectrum) would probably do better with more story than IDE (to provide context and narrative) and even simpler language so that the mechanics are manageable.
27.
Alan Kay | September 23, 2009 at 7:38 pm
One of the many delicious ironies of this discussion is that BASIC in fact was invented at Dartmouth to serve as a subset of a FORTRAN like language, and was slavish to this scheme to the extent of being done on simulated punched cards, and with simulated cards at the end of the program that would serve as data for the program. Just as it used to be done in the 50s and early 60s.
The interactive nature of BASIC actually came from a vastly superior lanugage and system — JOSS — done at RAND as a time-sharing system in the very early 60s. This was a real gem. And its form of interaction was much later adopted by BASIC (and as you might correcly guess, in a manner that was not as nice as the original JOSS).
In the mid-60s Butler Lampson did a wonderful version of JOSS using a very clever incremental compiler to produce a terrific efficient easy version of the JOSS language — called CAL — for students on the Berkeley Project Genie TSS (also completely built and programmed at Berkeley). I taught a number of introductory programming courses using CAL via TSS terminals at Utah in the late 60s.
To mention just one of many more pedagogical languages done for students in the 60s, PAL at MIT (Art Evans, Wozencraft, Jim Morris, etc.) was quite beautiful. Basically Landin’s ISWIM (so a kind of Lisp with a nice syntax) used interactively via the MIT CTSS terminals. This language was very simple on the one hand and extremely powerful semantically, so you could teach a wide range of programming ideas relatively easily. It was aimed extremely well at beginners.
Speaking as an old fogey (who also loves history, and especially the history of his own field), why wouldn’t all of these approaches be already well known? What kind of collective disinterest does most of our field have that causes it to “reinvent the flat tire” over and over, rather than trying to build on the best ideas of the past?
Best wishes,
Alan
28.
Erik Engbrecht | September 23, 2009 at 8:19 pm
Because we keep on getting paid quite well to build new flat tires and then to constantly pump air in them so that they can be used in a barely functional manner. In fact the pumping of air into flat tires while they move is possibly our industry’s biggest source of profit. Why would we stop building flat tires and cut off our largest and most reliable source of income?
29.
Mark Miller | September 24, 2009 at 3:10 am
And I’d say the reason why we get paid to reinvent the flat tire is that the people paying us can’t tell it’s a flat tire, because all the other tires they’ve seen were flat, too. They think it’s normal. As Alan has pointed out before, what reinforced the flat tire a few decades ago was bad hardware architecture (bad rims). What’s ironic is now that these “bad rims” have been improved to a point where the flat tire can be inflated people complain about the burdens a full tire puts on them (in terms of learning higher level concepts) and their systems (rims). They still use conventions that are no longer necessary, because they’re now entrenched in people’s thinking. People like what’s familiar and has wide social support.
30.
Mark Miller | September 25, 2009 at 9:26 pm
Hi Mark.
Still getting more of a sense of what you’re talking about. One of the images that ran through my head as you talked about this was an old game on the Apple II called Rocky’s Boots, published by The Learning Company back in 1982. I remember going through it when I was in high school. It also had little exercises that a student could play with, having to do with logic circuits. It was the first time I worked with something that really felt like a simulation environment.
What I really liked was the sequel called Robot Odyssey. It used the same simulation engine, but had the player solving much harder problems.
So what I see you’re talking about is having a system that sets up little exercises that each focus on isolated skill areas, and understanding of computing concepts. An image I got today for the example of understanding variables was to have a looping process in play with colored blocks representing variables, each one having an arrow pointing out of them to a value. The student could observe the effect that the variable (block) values were having on the system. One of the things the student could try is changing the color of the block to see if that has an effect (it doesn’t, but it might get the message across). Next they could try changing what the blocks point to (a different value), and see how this changes the effect on the system. So, this could get the point across “Changing the placeholders makes no difference, changing the values does.” One could extend this concept to types, if that’s desired. For example having different shapes to represent different types.
I like that you got into thinking about “phonics”, “scales”, “etudes”, because I’ve gotten this notion that it would be great if the field could begin to conceptualize computing concepts into atomic symbols and combinations of them. I first started getting this idea by working in Squeak/Smalltalk for a while. There were structures I wanted to create, but I kept having to instantiate objects for them. After a while I thought, “Why can’t I just symbolize this??” A little while later I happened upon Chris Crawford’s essays (“History of Thinking”), which he wrote in the mid-1990s, and this one line jumped out at me: “We need an alphabet!” I thought, “Yes we do!” About a year later I heard it mentioned that Douglas Engelbart has started thinking along the same lines, though there was no elaboration on what he thought about it.
Somehow I don’t think this will be as simple as symbolizing common patterns that we commonly use today. That’s a step, but I get the sense that the real alphabet if and when it comes pass while conceptualize concepts we haven’t even imagined yet. It is nice to see others thinking in the same direction.
31.
Alan Kay | September 26, 2009 at 8:52 am
Hi Mark (Miller)
Warren worked for me at Atari for a while in the early 80s and I was (and am) a great fan of Rocky’s Boots.
When the TLC folks brought me Robot Odyssey to look at, I told them it was the greatest game concept I had seen, but that it wouldn’t work in the form it was in. This proved to be the case.
The prediction was made correctly because they had missed a really important idea — and one that is germane to your comment. That not every form of expression that is sweet at one scale for one kind of problem will be able to move gracefully into other domains.
In the case of Robot Odyssey, the problem was that it is just not a good idea at all to try to do robot programming in logic operations (where it was a wonderful idea for Rocky’s Boots). The complexity of the thinking and construction task goes up much faster than the functionality achieved (this is why software was invented for computers). It was excruciating to program the robots!
I told them that if they used something like LOGO (or a LOGO like version of PLANNER or Prolog) to program the robots, they would have the world’s greatest game. But they stuck to the logic elements and it was not at all suited even to deep Rocky’s Boots aficionados.
Warren was a true genius for Rocky’s Boots (it’s still great on absolute terms), but he wasn’t involved as a main factor in the design of Robot Odyssey (I think he would have made different choices).
In any case, this is a good example where one has to be careful about levels and supersets. I think it is much better to design the language that will be used by those who get fluent, and then subset this if necessary for beginners.
Cheers,
Alan
32.
Mark Miller | September 26, 2009 at 7:57 pm
Yep, I think Rocky’s Boots was well suited to the subject it tried to teach. I noticed fairly quickly that Robot Odyssey was using the same simulation scheme as Rocky’s Boots. In RB you went from room to room. Each room had a set of connectors with its own inputs and set of components to work with. In RO it was the same scheme. Everything was a “room”, even the insides of robots.
I agree with you that the use of logic circuits didn’t fit well for the domain of RO, but the sense I had of the problem was 1) screen area, and 2) an illogical relation of “logic circuits = timing”. It got to a point where it felt like they were kludging the system. Also, circuits got so complex that they overwhelmed the screen resolution of the Apple II. It became a “rats nest”. I discovered this is the reason they included a “chip lab” in the game, so you could wire up as many simpler circuits as you wanted to make a larger whole, “burn” the chip, and then use that in your robot, an involved process because you had to quit out of the game, load the “chip lab”, build a circuit, burn it, save it to disk, restart the game, load the circuit from disk and wire it up. Not a good design.
I liked the overall concept of RO because it felt like an “educational game”, whereas RB felt more like a series of tutorials with no point to it beyond completing each exercise. Though one did learn interesting things about logic circuits in the process.
From your description RO is an example of what I’ve complained about before (and I guess you have as well) of taking an existing design and merely adding on to it rather than designing the whole thing well from the ground up. It’s rather like how movie producers see a movie that does well and think “Let’s do a sequel that’s kind of like the original but different,” rather than realizing that the sequels that did well were really original movies in their own right, that only obliquely relate to the one that came before.
33.
There will always be friction « Computing Education Blog | October 6, 2009 at 12:12 pm
[…] when that “friction” is actually important, interesting, and is part of what is most challenging for our students to learn? What does it say about computer science if wanting to teach programming for creative expression […]
34.
Rethinking Science Education as Contextualized « Computing Education Blog | January 6, 2010 at 12:58 pm
[…] lessons for me from the last eight years is that relevance is critical, but students still need to learn stuff. They do need understand the history of what they’re learning. We need to figure out what […]
35.
Sally Fincher and women in computing education research for Ada Lovelace Day « Computing Education Blog | March 24, 2010 at 6:45 am
[…] my research directions. Her earlier study of female mid-level IT managers has been influencing my thinking about computing education beyond formal school. She’s just completed a new study of female senior-level managers which blows away […]
36.
Adele Goldberg: Modeling not Programming « Computing Education Blog | August 5, 2010 at 11:14 am
[…] the requirement that the modeler has to know how to connect the objects. Maybe that’s the phonics of computing. We have evidence from several sources that the simple ideas (variables and values, sequential […]
37.
In Toronto, Talking About CS Ed and CS4All « Computing Education Blog | November 21, 2010 at 10:01 pm
[…] I’m going to say — it’s about my students’ work, about worked examples and phonics, and about why textbooks are bad for CS Ed, and why distance education is important for […]
38.
What students get wrong when building computational physics models in Python: Cabellero thesis part 2 « Computing Education Blog | August 1, 2011 at 9:07 am
[…] how to map from a situation to a set of constants in a program. (Given that we know how much difficulty students have understanding variables in programs, I wouldn’t be surprised if they don’t really understand what the constants mean or […]
39.
What can the Uber Gender Pay Gap Study tell us about improving diversity in computing? | Computing Education Research Blog | March 5, 2018 at 7:01 am
[…] I first started thinking about the “phonics of computing education” and our ebooks, I was inspired by work from Caroline Simard that suggested that helping […]