Archive for April 14, 2010

CMU releases a new kids language for robots — in C!

CMU’s press release about their new robot language doesn’t make much sense to me.

  • The language should be “easy enough for elementary students to use, but powerful enough for college-level engineering courses.”  Why?  Is it even possible to do that?  And why is it desirable?
  • It’s based on “industry-standard C programming language”?!?  I’ve argued previously that it is probably now criminally negligent to teach C or C++ as a first programming language — there’s enough evidence that it’s too hard for students, and we do know how to do it better.
  • “Hundreds of thousands of children gain their first programming experience with robots.” Can that really be right?  Only about 16,000 students took the AP CS test last year.  Let’s take that as a starting place.  There’s a multiple of that actually taking CS classes in high school, but the multiplier is not ten.  There’s a lot more CS in high school than elementary school, and relatively few high schools have robots.  I don’t buy their numbers — I’d like to see the evidence.
  • They argue that it should all be C because it is the language that children “likely will use for years to come” and “will help them transition to those used by professionals.”  The key criteria for a children’s programming is that it will help them in transitioning to industry?  For 10-15 years later?  Do we even know what people will be using in industry in 10-15 years?  And should it really be the focus in elementary school to prepare these students for professional software development?

The folks at CMU do terrific work thaI rave about regularly here.  I think this one isn’t in the right direction.

Carnegie Mellon University’s Robotics Academy announces the release of ROBOTC2.0®, a programming language for robots and an accompanying suite of training tools that are easy enough for elementary students to use, but powerful enough for college-level engineering courses.Like the original, this latest version of ROBOTC is an implementation of the industry-standard C programming language and has a modern programming environment that can grow as students move from elementary through college-level robot programming…“Computer programming is not taught at the middle school level, yet hundreds of thousands of children gain their first programming experience with robots,” said Robin Shoop, director of the Robotics Academy. “We introduced ROBOTC four years ago because students working with robots should spend their time learning scientific, mathematical and engineering principles, not learning a different programming language for each robot platform. Also, the programming environment students use should be compatible with a language such as C that they likely will use for years to come and with an interface that will help them transition to those used by professionals.”

via SCHOOL OF COMPUTER SCIENCE, Carnegie Mellon.

April 14, 2010 at 9:52 pm 18 comments

Is learning to program inherently hard?

In our educational technology class yesterday, we read and discussed a classic paper by John Anderson, Albert Corbett, Ken Koedinger, and Ray Pelletier, Cognitive Tutors: Lessons Learned from The Journal of the Learning Sciences (1995, 4(2), 167-207).  This paper presented 10 years worth of data on cognitive tutors, including the Lisp Tutor.  When the Lisp Tutor was tested in 1984, tutor-using students completed exercises 30% faster and performed 43% better on a posttest.  In 1991, they did a more careful evaluation under a structure that was more like a real course.  In that one, tutor-using students completed exercises 64% faster and still did 30% better on a posttest.  Wow!

Yet, the students weren’t really learning to program.  Yes, they learned Lisp really well.  They knew nothing about debugging.  They didn’t know anything about going from a problem to a program.  In class, we made the good argument that those limitations are good things.  The Lisp Tutor succeeded because it made the task manageable. CS1 has too large a cognitive load.

But here’s the question we got to wondering about: Could you build a cognitive tutor for all of programming?  Cognitive tutors teach process, like problem-solving.  They guide students through a process using a technique they call “model-tracing.”  Designing is not a fixed process — there is no single path, and it involves tradeoffs.  Debugging is an immensely difficult task, requiring the programmer to internalize a dynamic mental model of the program.  These aren’t traceable problem-solving processes.

CHI2010 is going on this week here in Atlanta. I’m actually not attending (too expensive for too little that’s close to what I do), but I am following the Twitter feed and reading some of the papers.  One of those is a really interesting paper on Toque: designing a cooking-based programming language for and with children. A group of researchers at U. Maryland College Park (with the always-intriguing Allison Druin) worked with children to design a programming language for themselves and other children, which they programmed using a visual notation input through body motions (tracked via a Wiimote).  As I scanned through the paper, the headline leaped out at me,“Confusing and Boring”: Loops. Even when you have gifted designers, non-textual languages, and no keyboards, loops are just hard.

So what makes programming so hard to learn?  Here’s a possibility: It’s inherently hard.  Maybe the task of programming is innately one of the most complex cognitive tasks that humans have ever created.

Is it really harder than most other tasks? In considering this premise, I keep coming back to debugging.  Physics wants students to develop a mental model of the physical world, one where gravity tugs and friction resists and electromagnetism is understood even if never seen.  We have evidence that not all students really develop this complete mental model.  However, using equations that can be applied plug-and-chug, and a limited model, students can get by, and even take jobs using this more-limited model of Physics understanding.

How do you debug without really understanding how the code works?  How do you debug at all without developing a mental model of the program?  There are still cognitive scientists who disbelieve that humans actually develop executable/runnable mental models at all.  I bet someone could prove that they exist using computer programming, because programmers have to have them to successfully understand and fix program behavior.

I don’t really believe that programming is the most cognitively complex activity humans have created.  I am wondering about how hard it is, how to measure that complexity, and how the challenge of computing education may be greater than the challenge of other forms of STEM education.

April 14, 2010 at 10:41 am 15 comments


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 6,297 other followers

Feeds

Recent Posts

Blog Stats

  • 1,672,107 hits
April 2010
M T W T F S S
« Mar   May »
 1234
567891011
12131415161718
19202122232425
2627282930  

CS Teaching Tips