The Origins of APL – 1974 Video

A really interesting interview with Kenneth Iverson and others on the development of APL.  What’s striking is that APL was invented as a human-to-human communication tool, used mostly in classrooms, which was years later turned into a programming language: The Origins of APL – 1974 Video by Catherine – MySpace Video.

The need for hybrids: A call for more DBR

I’ve been thinking a lot about two of the papers at Informatics Education Europe last week.

First paper: Faculty at UPC Barcelona decided that students were coming into CS2 with insufficient problem-solving skill.  The decided that part of the problem is that paper-based tests lead to grading based on student intent instead of on the actual code, e.g., we let students get away with more errors.  They decided to move to a pure “problem-oriented approach” for their CS1.  Students are given 100 worked example problems, and 200 problems to solve.  Students submit their solutions on-line, and get feedback on how well their programs succeeded against a test suite.  First test is free, all others dock points if unsuccessful.

The project was successful in that students coming into CS2 have much better problem-solving skills.  Unfortunately, only 20-25% of the students make it through.

That result surprised me, given what we know about worked examples research.  How much do students make use of the worked examples?  Answer: Almost none at all.  Students just try to solve the problems, and don’t actually try to learn anything.

Second paper: The Open University in The Netherlands actually teaches their CS1 face-to-face, for the most part.  Teacher and students drive to some common location and conduct classes in small groups of about 30. They decided to try an experiment where they ran the classes completely on-line.  One section of 13 was asynchronous — students posted to a threaded discussion group. Another section of 15 met in a synchronous forum with text chat and a shared whiteboard.  At the end of the 12 week term, the asynchronous class went from 13 down to 1, while the synchronous class went from 15 to 10, which was the drop-out rate that they normally have with face-to-face classes.

While these are both really interesting papers, nobody would ever want to do these classes as described again.  They make for interesting papers, where they only try one pure approach: Just problems, just synchronous, just asynchronous.  A real, successful class would be a hybrid of different approaches.

• Got an expensive face-to-face class? Add some synchronous on-line activities in lieu of some lectures.
• Got an asynchronous class where students are dropping out?  Add some synchronous and even face-to-face sessions to build up motivation.
• If students don’t read the problems, add some assignments where students have to demonstrate that they read, not just coded.  Add some lectures where problems are discussed.

Why don’t we read more papers like that?  Because hybrids don’t play well with our sense of rigorous experimental research.  We want to know exactly what inputs influenced what outcomes.  We want to know that problems or asynchronous discussions failed or succeeded, period.  Making it work doesn’t make for a paper that gets accepted in many forums.

The learning sciences community faced this same problem.  You can do a study that answers a question and results in a publication, but doesn’t really result in successful classroom.  Or you can mix things up so that it really works, but then you can’t get the results published.  They defined a model of research called design-based research (DBR), first proposed by Alan Collins and Ann Brown.  The idea is to build a classroom that works.  Through a process of measuring and iterating, or drawing off particular hypotheses to test in laboratory experiments, you develop evidence for what factors are influencing what outcomes.  DBR recognizes, however, that good solutions tend to have multiple interacting factors.

We need hybrid approaches.  Pure approaches only lead to good papers.  We have too many challenges in computing education to aim for only good papers.  We need great papers that show working educational contexts that other can replicate, where the factors are messy and will take us a while to tease apart and understand completely.  Documenting how we get it right and finding someplace to publish those papers are the first step. Understanding it factor-by-factor is a later step.