Mark Guzdial's Amazon Blog

What is the role of language in learning programming? (Part 2 of "What makes programming so hard?")

7:14 AM PDT, October 25, 2007

Many people responded to my entry "What makes programming so hard?" I appreciate all the interest and the feedback! My colleague, Blair MacIntyre, gave me some particularly lovely and pointed feedback. He told me that he liked the blog entry, and that I made research in computing education interesting, even compelling. He felt like he might want to do work in this area. However, he also told me that I make the research too scary, the questions too hard to answer. So, let me lay out some more accessible questions--the next questions to answer, the ones that lead towards answering the big questions.

John Pane wrote me and provided me with some additional information about his dissertation work that I had missed in my summary. His subjects in his study were only 10 years old, and he only gave them 1/2 day of instruction in his video game system. So, his results aren't such an obvious answer to the question of the role of language in learning programming. His dissertation work then suggests a bunch of other questions that we might want to ask (some of which John has explored in his later research):

Maybe 10 year olds are too young, not having proceeded far enough up the Piagetian steps toward abstract thinking. Could adults do better?
Is 1/2 day of instruction enough? We might expect someone to learn a word processing system with 1/2 day of instruction. However, programming has more inherent complexity. Perhaps we might compare it to something like constructing a spreadsheet. Can someone learn more about programming using a well-designed system like John's in 1/2 day than a comparable someone might learn about spreadsheets in the same 1/2 day?
John had to make a bunch of design decisions in the construction of his user interface. Maybe there are better design decisions. Exploring variations of his user interface might have different results.

All of these questions lead to the general question of the role of language in learning programming. Certainly, there is some role. Eric Roberts of Stanford has observed that the downturn in interest and enrollment in CS came at the same time that the predominant introductory language in the U.S. moved from Pascal to C++ and then Java. (One phrase that I heard at the ACM SIGCSE conference a couple years ago: "How bad was using C++ in intro courses? It was so bad that Java looked better!") Most computing teachers who have worked over these 20 years will tell you that C++ and Java are clearly harder for students to use than Pascal. Measuring that additional complexity is a significant challenge (see earlier blog posting on the challenge of assessing learning about programming). Part of the problem is syntactic. C++ and Java require more typing and have more syntactic rules than earlier intro languages (Pascal, and also Logo or even Basic). There's another level of complexity, though -- the model of computation that a language requires the programmer to use.

I have argued previously in this blog that objects are hard, that object-oriented programming is harder than procedure or function oriented programming. I will address the role of paradigm in introductory programming in a later blog entry. Even leaving that alone, it's pretty clear that "public static void main(String [] args)" requires a lot of explanation, and that's where you start in Java. That's a lot of inherent cognitive complexity, even if the syntax were easier.

Experience with Alice is an example of how cognitive complexity trumps syntactic complexity. Alice, as I'm sure most of you readers know, is a visual programming environment for storytelling. We teach Alice and Scratch (another visual language), as well as Python and Java to computer science teachers in our workshops. Alice has no syntax to type--you simply drag and drop the language components. You can't get a syntax error.

However, we found that it takes teachers longer to get started with Alice than with Python. We can get teachers to write their own Python Media Computation code in half a day--we'll start in the morning, and teachers will code some fun image manipulations at our lunch break. Alice has a longer learning curve. No, there are no syntax errors, but if you try to drag the wrong thing into the wrong place, it won't drop--and you won't get any messages explaining why. You can't use Alice unless you understand the underlying computational model. You simply can't assemble pieces appropriately without knowing that model and assembling according to that model. It's not a simple model, and that's where most of the effort goes in learning Alice.

And yet, teachers love Alice, and seem more likely to adopt it for their classes than our Python Media Computation. Why? That's part of Lijun Ni's research, which I've mentioned previously in this blog -- and there's more to talk about there, as well. Let me suggest here one big part of it. Alice is about storytelling, and we teach Python for media computation. Storytelling is an even bigger motivator, an even more fundamental driver of human behavior, than manipulating media. I continue to believe that the most significant bit in helping people learn programming is the motivation. What are you doing with programming? The language can get in the way, but people will go through a huge amount of effort to do something that they want to do.

.jsOffDisplayBlock { display: block; } .jsOffDisplayInline { display: inline; } .jsOffVisibility { visibility: visible; } .jsOnDisplayBlock { display: none; } .jsOnDisplayNoneBlock { display: block; } .jsOnDisplayNoneInline { display: inline; } .jsOnDisplayInline { display: none; } .jsOnVisibility { visibility: hidden; } .jqOnDisplayBlock { display: none; } .jqOnDisplayInline { display: none; } .jqOnVisibility { visibility: hidden; } .jqOnDisplayNoneBlock { display: block; } .jqOnDisplayNoneInline { display: inline; }

Post a comment

See latest post

Sort: Oldest first | Newest first

Showing 1-6 of 6 posts in this discussion

Initial post: Oct 25, 2007 12:12 PM PDT
Last edited by the author on Oct 25, 2007 12:14 PM PDT

Mr. William H. Kerr says:

I haven't used Alice, unfortunately, but am familiar with game maker (mark overmars), scratch, etoys and python.

Using the visual drag and drop features of game maker a student can make a simple game in 10 minutes. The model is event driven. For example, a Create event can be linked to a move action, which has speed and direction properties. There are also Collision events, Alarm events and Step events (for monitoring) which are more sophisticated. I'm not sure how this compares with Alice but it seems to me that some UIs have evolved to the point of being more accessible cognitively to more and more learners, the trend is in a good direction

Won't programming languages continue to evolve further so that they will require less exactness (human to machine current requirement) and become more tolerant of ambiguity (human to human evolved reality)? I don't know enough to know how this will look but that pathway will build on visual / kinesthetic elements rather than textual elements, surely?

Syntax error elimination is valuable in visual/kinesthetic languages because it enables the student to tackle the cognitive problems without the mental clutter of having to simultaneously deal with syntax errors, which can be debilitating for beginners

So, I'd see motivation (game making is motivating for some but not all students) in combination with a visual/kinesthetic language such as the ones I've mentioned (UIs vary, not all are good) as the best way to start programming for young learners.

- Bill Kerr
http://billkerr2.blogspot.com/

Reply to this post

Permalink | Report abuse
1 of 1 people think this post adds to the discussion. Do you?

In reply to an earlier post on Oct 25, 2007 1:10 PM PDT

Mark Guzdial says:

Hi Bill! The question is how hard it is to learn those events, for someone who doesn't have a prior notion of event models. Collisions occur in the real world, but they are things to avoid. There is an understanding of the computational world expected in these tools.

I completely agree about evolution of languages toward allowing more ambiguity, and I can understand the belief that that may involve visual and kinesthetic elements. However, there is still the challenge of matching the computational model to the user's abilities. (I was going to write "expectations," but I don't know what we can expect user's to think about computation before their first language.)

Reply to this post

Permalink | Report abuse
Do you think this post adds to the discussion?

In reply to an earlier post on Oct 28, 2007 1:48 PM PDT

Anthony W. Hursh says:

This is somewhat anecdotal, but this past summer we added a small Scratch activity to our first ed tech course (we run an on-line Ed.M. degree program for working K-12 teachers).

The activity required that they include custom sound, motion, audio, a custom costume, and some sort of keyboard or mouse input.

Even though very few of the teachers had programmed before in any meaningful way, and even though their Scratch training consisted of a fifteen minute demo (plus the on-line resources from the Scratch team), 19 of 20 students managed to produce a basic Scratch project (the exception was engaged in a cross-country move, so I don't believe that this was due to him not getting it).

This is wildly at variance with my previous experience at introducing programming to programming-naive audiences (using "easy" languages like Javascript, Excel macros, and Visual Basic).

I did call the activity "creating an animation" rather than "writing a program". I wonder if that had anything to do with it?

I think your point about storytelling is well-taken. Even though it wasn't required, several of them did produce some sort of simple story (the others tended toward animated multiple-choice quizzes and the like). I think I'll explicitly ask them to do a story next time.

Maybe next summer we can add Alice. :-)

Reply to this post

Permalink | Report abuse
1 of 1 people think this post adds to the discussion. Do you?

In reply to an earlier post on Oct 30, 2007 3:29 PM PDT

Mark Miller says:

Anthony:

I think you hit on something. Dr. Randy Pausch, the creator of Alice, talked about a former student of his suggesting in her doctoral thesis that the context a programming system is introduced in can matter in terms of how well the students learn it. She suggested that rather than call Alice development "programming", that he instead recast the course as "storytelling with a computer". She found that female students, for example, became more motivated to learn Alice than with the "programming" approach.

I've heard a couple people talk about this idea, now: "Teaching programming while doing something else," just don't call it "programming". One was Pausch's story. Another I came upon just recently was a speech that Richard Stallman gave 5 years ago (at http://www.gnu.org/gnu/rms-lisp.html) on his history with Lisp and Emacs. Stallman was the original author of Emacs, originally written in assembly language. It had a macro extension language that was the same one used by the TECO editor, which was terrible. He knew it, too. It was just a first attempt. Someone else rewrote Emacs in Lisp. The extension language was Lisp as well. He did the same thing when introducing Emacs to his staff that Pausch eventually did with Alice. He told them they could add their own features to Emacs, and he showed them how by describing the Lisp notation. An important thing was he did NOT call it "programming". He didn't want to scare people off. An interesting thing happened. Stallman said that even secretaries, people who didn't think they could program, were adding their own features to Emacs using Lisp! And this was back in the 1970s. This is impressive to me.

I wonder if it's not just terminology. I think maybe what people don't like about "programming" is they think it's an end in itself, and they're not interested in that. What they really want to do is make the computer do their own thing, so they don't have to try to find a software package that will do just what they want. They can make it do it themselves. I think this was always the primary interest in programming. It was for me. Perhaps what a larger audience of people find attractive about the activity of programming is more domain specific. They like it because they can use a computer to tell stories, or as Mark Guzdial has done with students, help them create their own unique artistic expressions.

Reply to this post

Permalink | Report abuse
2 of 2 people think this post adds to the discussion. Do you?

In reply to an earlier post on Nov 3, 2007 2:17 PM PDT

Mark Guzdial says:

Ted Kosan sent this to me and asked me to post it for him:

After years of teaching programming to beginners using a variety of high-level languages, I finally concluded that starting beginners with
a high-level language produced results which were not as good as the ones I experienced learning assembly language programming on a Commodore 64 in the 1980s. I then radically shifted my approach and started teaching beginners (mostly high school students and college freshman) how computers work at their lowest levels before teaching them a high level language.

The approach I have taken also involves a story, but it is a story
about how a computer works as told to a young person called Pat. The results I have been getting with this approach have been very good and
it has made teaching programming to beginners fun again :-)

If anyone is interested in looking at the materials I have created for
beginning programmers, they can be found on this website:

http://professorandpat.org

Ted Kosan

Reply to this post

Permalink | Report abuse
Do you think this post adds to the discussion?

In reply to an earlier post on Nov 18, 2007 11:23 AM PST
Last edited by the author on Nov 18, 2007 11:30 AM PST

Mark Miller says:

Interesting approach. As I may have mentioned earlier, when I was a kid learning programming in the early 1980s I knew a few kids who programmed in machine code on the Apple IIs. The 6502 instruction set (the one the Apple used then) was very simple, though personally I think assembly language is easier to grasp. Machine code meant typing in hexadecimal numbers for everything, opcodes and operands. For whatever reason I found this low level stuff intimidating. I used to hear horror stories that if you weren't careful in machine code you could corrupt a disk you had in the drive. On some machines you could burn out chips, so they didn't function anymore, etc. It felt like playing with fire. I didn't get into it until college, and an interesting thing happened. I dreaded getting into it, but I discovered in lab after lab I got programs to run correctly on the first try sometimes. Sometimes the third. I noticed I didn't have to struggle much to get a program to run correctly like I did sometimes with HLLs. I think the reason was the architecture was simple. The instruction set wasn't complicated. We had a CPU manual that told us exactly what each instruction did. I think that helped the most. There was no mysterious "magic" going on at all, like it felt like sometimes in HLLs. Everything was very explicit.

The only caveat I'd give is I don't know that this approach would work well for today's HLLs. Maybe I have a narrow view. I don't see the connection between learning assembly and learning Java, for example. It was good for learning BASIC, C, and Pascal, because in those languages you sometimes used direct memory addressing (aka "pointers"). In Java you use references, which are like pointers, but have different properties. In assembly language, for example, you learn indexed addressing where you can offset from an address mathematically. You can't do this with references. You also work directly with memory. In Java you work indirectly with memory. Beyond working directly at the bytecode level, I can't think of an equivalent to what Kosan is talking about. Maybe it doesn't matter. Maybe just understanding the basic mechanics, even though it's inconsistent between the two models, is helpful.

Reply to this post

Permalink | Report abuse
Do you think this post adds to the discussion?

‹ Previous 1 Next ›

Mark Guzdial's Amazon Blog

What is the role of language in learning programming? (Part 2 of "What makes programming so hard?")

Bio

Where's My Stuff?

Shipping & Returns

Need Help?