Parsons puzzles are a useful tool for teaching basic programming skills. A Parsons puzzle asks students to solve a programming problem by rearranging tiles marked with code lines. This is a useful bridge towards writing code.
I just added a Parsons puzzle editor to the CodeCheck autograder that makes puzzle authoring easy and enjoyable.
In a Parsons puzzle, students are given code in scrambled order. They rearrange the lines so that the code fulfills a given task. These puzzles are popular for teaching programming. Researchers have found that performance on solving Parsons puzzles correlates well with performance on code-writing exercises, while reducing cognitive load and frustration.
Here is an example:
The name comes from Dale Parsons, who, together with Patricia Haden invented the puzzle form.
A commonly used library for presenting Parsons puzzles is js-parsons.
Here is an example:
Here is a builder tool for creating puzzle instances. It works well enough for simple problems, but there are issues.
class MyClass and public int myMethod1()?myMethod1 or myMethod2 comes first.These issues can be addressed, but they get pretty complex. With js-parsons, you can map each tile to a line of Python (!) code, and then specify two blocks of Python code to be prepended and appended to turn the tile mappings into a running program. Then the tool checks whether the generated code causes certain variables to have expected values. It is tedious to author, and feedback to students isn't great.
In the electronic texts for my introductory books (Big Java, Big C++, Python for Everyone), I used a different tool whose markup language makes it easy to specify fixed and draggable tiles, tiles with multiple lines, tiles that can be interchanged with others, distractor tiles, and even tiles with pseudocode. Here is an example:
But ever so often, some clever student found a valid solution that I had not thought about and that didn't pass validation. The markup language is not powerful enough to express all valid solutions. Improving it would make problem authoring more complex and tedious.
I'd like to use more Parsons puzzles, but there has to be an easier way to author them.
Parsons problems are a stepping stone to writing actual code. I have an autograder, CodeCheck, in which students enter code into a text area. The code is compiled and evaluated. There are plenty of other autograders like that. CodeCheck is optimized for my use case. It is really fast to author a new problem. You write a solution, hide the parts that you want the students to fill in, specify some test cases, and you are done. Here is an example:
/**
Print the number of positive and negative inputs.
*/
//IN 1 2 -3 -4 5 6 Q
//IN -1 -2 -3 -4 -5 Q
//IN -1 -2 0 4 -5 Q
//IN 1 2 3 4 Q
//IN Q
import java.util.Scanner;
public class CountPosNeg
{
public static void main(String[] args)
{
// Declare variables positive, negative
//HIDE
int positive = 0;
int negative = 0;
//EDIT ...
Scanner in = new Scanner(System.in);
while (in.hasNextInt())
{
// Read the next integer
// Increment the appropriate variable
//HIDE
int input = in.nextInt();
if (input < 0)
{
negative++;
}
if (input > 0)
{
positive++;
}
//EDIT ...
}
System.out.println("Positive: " + positive);
System.out.println("Negative: " + negative);
}
}
Note the //IN, //HIDE, and //EDIT pseudocomments that tell CodeCheck how to present and check the problem.
Click this link to see what the problem looks like for a student.
And here is a key point: The solution code compiles and runs. You can develop it at your leisure, using your favorite IDE, and then upload it once you got all the kinks out. That's a lot faster than a builder tool where you have to type in bits and pieces, and fix any mistakes in the builder UI.
The key insight is that the tile dragging UI is a kind of editor. The autograder simply takes the code from all the dragged and fixed tiles, in the order in which they appear. If that passes the tests, it's good enough. Since students can't write arbitrary code, you don't even need many test cases.
So, that's what I did. I took out the battle-tested tile dragging code from my electronic textbook and bolted it onto CodeCheck. That's what you saw in the first example.
How do you author a problem? With a slightly different set of pseudocomments. In the simplest case, add //TILE on top, and the file bursts into one tile per line. But in practice, you will want to give students an outline and only apply the tiling to the interesting code. Like this:
/**
Print the number of positive and negative inputs.
*/
//IN 1 2 -3 -4 5 6 Q
//IN -1 -2 -3 -4 -5 Q
//IN -1 -2 0 4 -5 Q
//IN 1 2 3 4 Q
//IN Q
import java.util.Scanner;
public class CountPosNeg
{
public static void main(String[] args)
{
//TILE
int positive = 0;
int negative = 0;
//FIXED
Scanner in = new Scanner(System.in);
while (in.hasNextInt())
{
//TILE
int input = in.nextInt();
if (input < 0)
//OR if (input <= 0)
{
negative++;
}
if (input > 0)
//OR if (input >= 0)
{
positive++;
}
//FIXED
}
//TILE 2
System.out.println("Positive: " + positive);
System.out.println("Negative: " + negative);
//FIXED
}
}
To minimize the tedium of braces, opening braces are automatically attached to tiles. When a student drags one, the closing brace is dragged with it. See the result here.
That's all. Parsons problems the easy way. Of course, you can use all of the many features of the battle-tested CodeCheck. Here are the instructions for distractors and multi-line tiles.
Try it out. Turn a demo program into a problem, upload it here, and give the resulting URL to your students.
Comments powered by Talkyard.