Stride – A new programming language for beginners

At the Greenfoot headquarters, we – that is: Neil Brown, Amjad Altadmri and myself – have recently worked on creating a new language within the Greenfoot environment: Stride.

The interesting thing about Stride is not so much the language design itself, but its interaction design: editing programs involves different interactions than existing editors.

The goal is that Stride sits halfway between block-based systems (such as Scratch, AppInventor, PencilCode, Alice, etc.) and text-based editors (such as Java or Python), maintaining advantages of both.

I will start a series of posts (text and/or video) here over the next few weeks trying to tell you what Stride is and why you should care. In the meantime, you can get Greenfoot, install it, and have Stride ready to go when the introduction here starts. Stride is built into Greenfoot from version 3 onwards.

Check back soon for the first overview video.

Java 7 for introductory programming — does it make a difference?

The recently released BlueJ 3.0.5 brought full support for Java 7. While it is always good to be up-to-date with the latest versions — what does that actually mean for introductory programming teaching?

Java 7 brought a considerable list of new features to the Java system. Most of them deal with fairly advanced or specialised topics, and will have no influence on introductory teaching with Java. Some, however, will become visible even close to the beginning of programming. Here, I give a short overview of what’s new, and what you — as a teacher of introductory programming — should be aware of.

Java 7 – What’s new

Most of the new features in Java 7 are under the hood or in specialised libraries. These are very unlikely to affect an introductory programming course.

Improvements to the internals of the JDK include changes to the VM to support dynamically typed languages and improvements to the class loader architecture. On the library side, there are new frameworks for concurrency, cryptography and new versions of JDBC and Unicode. All these will not be relevant for most introductory courses.

The two areas that are relevant are “Project Coin”, the code name given to a project defining several small language enhancements, and NIO.2, a new library for I/O. We’ll discuss these in more detail in a moment.

Equally important, what’s not included in this release includes support for closures (known as “Project Lambda”). This would have been the most significant change to Java since the introduction of generics in Java 5 or, arguably, since the original definition of the Java language in 1995. Project Lambda has, however, been deferred to JDK 8 in what’s known as Plan B. JDK 8 is currently scheduled for release in late 2012.

So, which of the new Java 7 features are actually relevant for our intro programming course?

NIO.2

The I/O classes in Java have been improved several times over the years. The release of JDK 1.4 in 2002 brought some significant improvements in the somewhat short-sightedly named NIO library. The naming is rather less than ideal, since it stands for “New I/O”, and the passing of time dictates that everything new will eventually get old.

Which brings us to Java 7 and the New New I/O. So what will this be called now — NNIO? Well, the designers settled on NIO.2.

NIO.2 brings a number of new classes and interface, some with very useful methods. If you are doing any programming that accesses the file system, it’s worth familiarising yourself with these. Particularly interesting are the Files and Paths classes, and the Path interface, which you can find in the java.nio.file package.

All other relevant new features are part of Project Coin. They are diamond notation, strings-in-switch and improved exception handling.

Project Coin

Diamond notation

Generic type details on the right hand side of an assignment can now be inferred. For example, where in Java 6 we had to write

   HashSet<String, Monster> monsters = new HashSet<String, Monster>();

to declare a HashSet variable and initialise it with a fresh HashSet object, in Java 7 we can write

   HashSet<String, Monster> monsters = new HashSet<>();

In other words: We do not have to repeat the generic types of the HashSet on the right hand side, and can instead just write <>. (This syntax is the reason that this construct is known as the “diamond notation”). The effect of this is exactly as the Java 6 version above. It is a purely syntactic shortcut. The compiler will fill in the generic types by copying them from the variable declaration on the left, and all behaves just as before. Of course, the old notation is still allowed.

Strings in switch statements

The variable used in switch statements can now be of type String. For example

   switch (command) {
       case "go":
          goForward();
          break;
       case "help":
          showHelp();
          break;
       default:
          unknownCommand();
          break;
   }

Before Java 7, strings could not be used in switch statements.

Improved exception handling 1: multi-catch

It is now possible to catch multiple exceptions in a single exception handler. For example:

   try {
      file = new File("readme.txt");
      process(file);
   }
   catch (FileNotFoundException | UnsupportedEncodingException ex) {
      ...
   }

As you can see in this example, the catch clause can list multiple types of exception in its header, separated with an OR symbol, to catch any of these types of exception.

Improved exception handling 2: try-with-resources

The second new feature relating to exceptions is called try-with-resources. It solves a hard problem: It was previously surprisingly hard to correctly guarantee that resources (such as files or network connections) were correctly closed in the case of an exception.

The new construct solves this. Look at this example:

   try (FileWriter writer = new FileWriter(filename)) {
      ...
   }
   catch (IOException e) {
      ...
   }

Before Java 7, the standard way to close a resource (a FileWriter in this example) would have been in a finally block, which followed the catch block. In Java 7, the FileWriter is opened in round brackets following the try keyword, marking it as a resource to be auto-closed. Once the try/catch block is completed, the resource will automatically be closed by the Java runtime system.

For classes to be used with the auto-close mechanism, they must implement the new AutoCloseable interface. All the relevant classes in the Java library have been retrofitted to implement this interface.

That already sums up the relevant Java 7 changes. As we can see — not much to worry about here. (This will be different next year, when JDK 8 will bring us closures. I expect we will have to have a lively discussion then about how to treat these in a first-year course. But we can leave that for a while.)

To find out more about the new constructs in Java 7, see this summary. The next version of the Object First book (5th edition, to be released in late October) includes discussion of these new features.


Note: This post was first published in the Blueroom.

Comparing Scratch, Alice and Greenfoot

logosAt ITiCSE 2009 and again at SIGCSE 2010, we had panel session: Comparing Alice, Greenfoot and Scratch. The session came about because all three development teams – the Scratch, Alice and Greenfoot teams – were regularly asked one question: What’s the difference?

All three systems aim to let young people learn about programming. Many teachers (as well as parents or kids) have heard of more than one of them, but deciding which one to use can be difficult. While there are clear differences, the time it takes to evaluate all three of them is not trivial.

The panel session turned out to be very popular. The room was packed full, and we got plenty of questions afterwards. So we decided to create a written version of this session. And it’s now available.

We wrote a set of papers, which have now been published in a special issue of the ACM Transactions of Computing Education (TOCE). Each paper was written by a key member of the design team of one of the environments. The papers are more extensive and more in depth than the panel was (we all took the chance to write about various aspects our systems, which we had intended for some time, but never got around to doing), but they also aim to record some of the discussion that we had at the time.

Target age groups for Alice, Scratch and Greenfoot

The TOCE special issue consists of an introduction, three papers (one each) about the three environments, and a discussion section at the end. They are


(NOTE: All papers are available in the ACM digital library. ACM allows authors to also publish the papers on their own web sites. I will link to those freely available copies when they have been made available by the authors. So check back in a little while if you could not get all you were interested in.)

Quality-oriented teaching of programming

One of the great mysteries of introductory programming education is what’s commonly known among computing education practitioners as the double hump.

The double hump refers to the marks distribution in a typical introductory programming course. Here is an example:

chart1

Figure 1: The double hump distribution of marks in a programming course


This graph shows a typical distribution of final marks in a first programming course. We have a whole bunch of students getting very good marks and a lot of them failing. Mark Guzdial, in a blog post, calls it the 20% Rule:

“In every introduction to programming course, 20% of the students just get it effortlessly — you could lock them in a dimly lit closet with a reference manual, and they’d still figure out how to program. 20% of the class never seems to get it.”

The surprising thing about this distribution is how constant it seems to be. It has been observed in programming courses all over the world, largely independent of geographical or social context, and over a long period of time: The same pattern that we observe now existed 10 years ago, and 20 years ago, and 30 years ago.

(And an ironic side note is that we as teachers tend to react to this by aiming our teaching at the medium level—thus teaching to a group that contains hardly any students at all…)

So what is this telling us?

For programming teachers, this poses some interesting questions and challenges. One conclusion has been that the ability to understand programming is somehow intrinsic. That there are people who are just good at it, and others how simply cannot get it. This has led to a whole lot of research about programming ability predictors: ways in which we can predict, by looking at people’s prior activities, performance, social context, or any other aspect of their lives, or with a hopefully simple test, whether or not they will be successful in learning programming before we make them go through it.

Some people really believe in these predictors, some do not. I am generally in the second category. Let’s say, I am at least highly sceptical. The first paper linked above, for example, draws what I believe to be severely invalid conclusions. It interprets the data in a way that the data just does not support. But that’s a story for another day.

What I really want to talk about is an idea that I picked up from a fascinating seminar that Anthony Robins gave a few months ago in our department: That the cause of the high failure rate that we are observing might not be any kind of intrinsic capability, but caused by the sequential nature of the material we are teaching.

What is going on might be this: The material in programming courses is highly hierarchical. Every topic strongly builds on the topics previously covered. Thus, if you don’t understand one section of the course, you will likely also struggle in the following sections, unless you spend extra time to catch up and make up for what you missed before.

Therefore, programming courses are self-amplifying systems. If you fall behind a bit towards the beginning, for whatever reason, you are likely to fall more and more behind in the following weeks and months. If you get ahead early, you are likely to stay ahead, or even move further ahead. The short of it is that this dependancy of performance on prior performance in the course will automatically divide the class into two distinct groups whose performance drifts further apart as time goes on.

Voilá, the double hump is born.

Anthony, in his seminar, made some very interesting points that provided strong indicators that this might be what’s going on. He is, as far as I know, in the process of publishing these findings, so I won’t go into too much detail here. (I will update this post with a link once his paper is out.) We can leave discussion of whether we belive this or not for another day.

For today, I’ll simply state that I find it entirely plausible that this is at the root of the problem. So for now, I will work with the premise that the double hump is not caused by some intrinsic personal capability, but by the strong hierarchical nature of the material we teach.

The question that I asked myself then is: What should we do about it?

My conclusion is that we need to shift from quantity-oriented teaching to quality-oriented teaching. Here is what I mean.

In a typical programming course at a university today, we may have a number of assessments. (For the purpose of this argument it does not matter what that number is—it might be a smaller number of large assessments or a larger number of small ones.) Students get marked on every assessment, and they pass the course if their average grade is above some defined pass level. Figure 2 shows a student in this scheme.

chart2

Figure 2: A good student attempts six assessments and passes most of them

In this example, there are six assessments and the student is doing okay: The average mark is above the pass level. The pattern for a weak student might look like Figure 3: The student also attempts six assessments, but mostly fails.

chart3
Figure 3: A weak student attempts six assessments and mostly fails

And this is a problem. It is not only a problem that the student is failing, it is a failure to teach sensibly if we believe in the hierarchical nature of our material. Once the student severely fails Assessment 2, there is really no point to let him/her move on to Assessment 3. In fact, it’s ridiculous. We are essentially saying: “We have just established that you did not understand concept X, so now go on to study concept Y, which is harder and builds on concept X.”

Now, that’s just plainly stupid.

We have essentially demonstrated that you have no chance to move to something harder, and then make you move on to something harder. Without giving you a break to catch up. The problem is: This is exactly what we usually do.

So what can we do about it? The solution might be to re-orient the pass line in our diagram (Figure 4).

chart4
Figure 4: Re-thinking the pass level

Typically, in our courses, the x-axis (number of assignment students do) is fixed, while the y-axis (quality of submissions) is variable. And we define success as reaching a given level of quality (see Figure 3).

We should turn that around. We should fix the y-axis and make the x-axis variable, thus re-defining success as successfully completing a certain number of assessments. This means that every student has to achieve a defined minimum level of quality in each assessment before they are allowed to move on to the next assessment. The differentiation between students then is not what quality level they have achieved, but how many stages of assessment they have managed to complete. In a diagram, it looks like this: Figure 5 shows a good student at the end of the course. Nine assessments have been completed, beyond the pass level of assessment 6.

chart5
Figure 5: A good student completing enough assessments to pass

The graph for a struggling student then looks like this (Figure 6).

chart6
Figure 6: A a struggling students failing to reach pass level

This student has not reached pass level and fails the course. Note, however, the difference here to our student in Figure 3: There are no assessments recorded below the minimum accepted quality level. (Every submission attempt with insufficient quality is simply judged as “not completed”.)

I don’t believe that this scheme will solve all our problems, but I do believe that it has a number of advantages:

  • Students may have a higher chance of success. Instead of early failure leading almost automatically to a sequence of further failures, they have a chance to recover.
  • Students who learn at different speeds can all survive.
  • Especially good students can go even further than they did in the past, because we can allow them to move forward according to their own capabilities.
  • More flexibility in dealing with temporary problems: If a student misses the first three weeks of class, be it because of illness or any other reason, they may still pass the class instead of having no chance.
  • Even failing students learn something. Instead of failing to understand every topic (Figure 3), they can at least spend their time understanding a few topics (Figure 6).

There are a number of problems and challenges as well, of course. The obvious difficulty is that we must be able to allow different students to work on different material at the same time. Every student effectively progresses at their own personal pace, and the teaching must support this.

Is this organisationally possible? I think so.

It is not easy, and it requires us to severely change how we teach, but I think it’s worth it. It will require different form of instruction (away from big lectures to the whole class) and different form of assessment (away from giving everyone the same task and assessing it by just submitting source code). Otherwise there would be a problem with plagiarism. We might need to assess by interviewing students to actually test their understanding!

Does this create work? Sure. But I think it’s worth it. And I actually believe that, once the change is made, the workload for teachers will be comparable to what we have now.

In an ideal world, this way of learning would have the result that different students learn the same material in a different amount of time. In reality, we will not get away from fixed length courses for the time being.

This means, that—at the end of a course—different students will have studied different amounts of material. Some students who move on to the next course will have covered the advanced material, some have not.

There will be an objection from other teachers that we let students pass who have not seen all the material, and that they do not know some concepts that they should know.

While this is true, I don’t believe that this is any different from our current situation. Which teacher would really claim that all students who passed their course have understood all concepts they were teaching? If one of my current student just barely clears the pass mark, there is a lot that we have covered that they don’t know. Claiming that they know more material because I talked over their heads about more advanced concepts for longer is nonsense.

I would rather have a student who properly understands 50% of the concepts than a student who half understands (and half misunderstands!) everything.

It’s open: The Greenfoot Gallery

For the past few months, we have worked on creating the Greenfoot Gallery – and now it’s finally officially open.

The Greenfoot Gallery is a place for people to publish their Greenfoot scenarios, and try out other people’s work, comment on it, rate it, etc. Think of it as a kind of YouTube for Greenfoot games. Have a look!

You can use the Gallery (look at scenarios, play) straight away, or you can create an account for yourself to comment on them or upload your own.

Uploading content to the Gallery is easy: Use the ‘Export’ function in Greenfoot, and you’re almost there.

Programming is not hard – Knowing what to program is hard

Programming is not hard.

Sure, there are plenty of examples you can pull out of the bag that have really brain-numbingly complex algorithms in them, and they are indeed hard to program, but they are really the exception. For most programmers and most programs, this is not the case.

Most programs that fail do so not because the implementation is done badly or fails altogether, but because they implement the wrong things. Its not that the programming was hard, but that they programmed something nobody wants.

Deciding what you should program is where all the beef is.
Continue reading

Teaching My Daughter To Code, Part IV: Return of the Daleks

Welcome back, dear readers, to the fourth part of Sophie’s journey of writing a DrWho computer game with Greenfoot and Java.

If you have read the previous parts, then thank you for sticking with us for so long! (If not, you may like to start reading here: Part I, Part II, Part III).

I’ll try to make it short today – it’s been a long day, and it’s getting late. But this programming session I’d like to record took place five days ago, I have only sparse notes, and I’d like to get it down before I forget too much. I have been busy this week, so I haven’t had time to write this up earlier, but there was so much lovely and encouraging feedback on the previous posts that encouraged me to continue writing this up.

Thus, without further delay, on to the next task: Reaching the TARDIS with the energy pellets!
Continue reading

Teaching My Daughter To Code, Part III: Prepare The TARDIS!

The third part of my endeavours to write a Dr Who computer game with my daughter

If you’re reading this, then you probably already have an idea what this is about: An ongoing project to write a Dr Who-themed computer game with my daughter Sophie, who is 10 years old. (Yes, she’s 10 now – it was her birthday earlier this week!)

This is the third part of this story. In part I we got the Doctor to move, and in part II we added some Daleks. This time, we giving the Doctor something to do, something worthy of the last of the Time Lords: Collecting energy pellets for the TARDIS.

Continue reading

Teaching My Daughter To Code, Part II: Invasion of the Daleks

Second part of my endeavours to write a computer game with my daughter

A few days ago, I have written about starting to teach my daughter some programming by inventing and implementing a game with Greenfoot and Java. Here’s the second part of that journey.

This time, I had thought a little more in advance about what might be a good thing to tackle next. Putting floors in, so that the Doctor would just walk on those levels (and ladders to go up and down)? Or other moves: jumping, ducking, etc?

I decided the most interesting thing would be to put some opponents in – other actors that you could run away from, and who could catch you. With the Doctor, it’s pretty obvious who that should be: the Daleks! (They are the Doctor’s prime enemy, after all.)

When I came home from work, I suggested this to Sophie. Happily, she agreed.

Continue reading