Designing a programming language: Don’t Be Clever

One lesson of programming language design? Don’t try to be too clever!

Here is an example from JavaScript​:

When you compare

0 == ‘0’

the system tries to be clever: “Comparing a number and a string? You probably meant to see whether the string contains the character ‘0’, so let’s just say ‘yes’!”, it thinks. So the result is true.

When you compare

0 == ”

it tries to be even cleverer: “Ahh, perhaps you meant to check whether the length of the string is zero! Let’s just help the user here and not require them to call a ‘length’ function. So tedious. It’s true!”

But of course

‘0’ == ”

“Comparing two strings – got it. Are they the same? No! Returning false.”

The result of all this: The fundamental property of transitivity of equality is broken in JavaScript!

a == b and b == c, therefore a == c ?

Not in JavaScript, it isn’t! How can anyone voluntarily program in a language like this?!

The lessons for me? Give me static typing any day. And don’t try to be clever when designing a language. Spelling things out is a good thing, not a bad thing.

The terrible state of MCQs

In academia – as in many other contexts – Multiple Choice Questions (MCQs) are a fact of life. We have many situations in which we need to assess a large cohort of learners, and MCQs make this easier.

Here, I don’t want to debate the value of MCQs as an examination technique in general, but talk about how they are written. If we accept that they are part of our work, let’s at least make them not terrible.

There are three very common ways in which MCQs can be obviously bad. I see them all the time.

They are:

  1. The question only examines surface knowledge
  2. The distractors are random
  3. The off-by-one way of writing distractors

Let’s look at each briefly.

The question only examines surface knowledge

This is quite an easy and obvious shortcoming to recognise: Often, MCQs just ask questions about terminology. They do not touch on concepts or deeper understanding. This is a very common trap to fall into for people who are not used to writing MCQs. Writing MCQs that test understanding is harder, and it’s easy to slip into the trap of just testing surface issues.

We have probably all seen it.

When you write your questions, examine each question critically in this light. Strive for meaningful questions.

The distractors are random

Another very common gripe of mine is that the distractors (the incorrect options in MCQs) are chosen at random. Let’s consider an example. Assume we have this question:

Question 54:

What is the output of the following segment of code?

        int sum = 0;   
        for (int i=0; i<=5; i+=2) {
            sum = sum + i;
        }
        System.out.println(sum);

If you speak Java, then you can work out that the answer is 6. So we use 6 as one of the possible options, and add a few random distractors:

Answer:

(A) 1
(B) 896
(C) 6
(D) -4
(E) 5

In this case, if students have a common misconception, they may arrive at an answer that is not on the list. For example, a student who does not understand that this definition makes the loop increment by 2 might assume that the answer is 15. But 15 is not on the list. So the student is implicitly told that they are wrong, and they can discard unlikely options (“Negative? – No.” “More then 800? – No.”) and make a random guess between a few remaining options.

This question is even worse in a way: Another common mistake is not being able to correctly distinguish between <= and < in the loop condition, and getting the answer wrong because of this. The way the question is written, however, it is not even possible to expose this misconception, because both variants happen to result in the same output!

A badly written question.

The off-by-one way of writing distractors

The other very common pattern I see all the time has an example in this question.

Question 31:

 Which of the following code segment would execute the stored procedure “getPassword()” located in a database server?

  1. CallableStatement cs = con.prepareCall("{call.getPassword()}");
    cs.executeQuery();
  2. CallabledStatement callable = con.prepareCall("{call getPassword()}");
    callable.executeUpdate();
  3. CallableStatement cab = con.prepareCall("{call getPassword()}");
    cab.executeQuery();
  4. Callablestatement cstate = con.prepareCall("{call getpassword()}");
    cstate.executeQuery();

The way questions like this are written is usually this: The question setter writes the correct response, and then creates three distractors by introducing one error in each.

It is trivial to reverse-engineer the correct answer from this. To do this, we spot the differences, and for each differences discard the odd one out. For example:

  • One difference is that “{call getpassword()}” is written with a dot in the middle once, but without the dot three times. So the dot is the odd one out, we discard Answer 1.
  • Another difference: CallableStatement is written with w capital S three times, with lowercase s once. So we discard answer 4.
  • Last one: The second line calls executeQuery() three times, and executeUpdate() once. Answer 2 is out.

And voilà – there is our answer: 3. We can do this without any knowledge or understanding of the subject matter. Keep your eyes open for this pattern in MCQ tests. It is astonishing how often you will see this question pattern.

A better example

Here is an example of something you could do:

Question 8:

HashMap<Integer, String> myMap = new HashMap<>();

myMap.put(2, "Tiger");
myMap.put(4, "Lion");
myMap.put(13, "Lion");
myMap.put(2, "Elephant");
myMap.put(3, "Chicken");

System.out.println(myMap.get(2));

When you try to compile and run this code, what will happen?

    1. The code has an error, because the value “Lion” is used twice in the HashMap.
    2. The code has an error, because the key 2 is used twice in the HashMap.
    3. The code will run and print “Tiger”.
    4. The code will run and print “Lion”.
    5. The code will run and print “Elephant”.

 In this case, the question tests an understanding of how maps work.

  • Option 1 tests the possible misconception that values cannot appear twice in a map.
  • Keys, on the other hand, are unique in a map. Option 2 tests the misconception that they cannot be replaced by a new entry.
  • Option 3 tests the misconception that the first entry for a given key persists.
  • Option 4 tests the misconception that the get(n)-parameter is an index, mirroring list-behaviour (referring to either the second or third element entered, depending whether the list is zero-based or one-based).
  • And Option 5 is correct.

This is by far not all that there is to say about MCQ writing. But it’s a start. It is the absolute minimum you should consider if ever you find yourself in the position to write and MCQ test.

Announcement: Strype – a frame-based Python system

Strype logoLast week, we have officially released Strype 1.0, a new Python editor and runtime system running entirely in a web browser. After being in development and available for preview and testing for some time, the system is now fully supported for use in classrooms or for individuals wishing to learn Python programming.

Strype’s most unique feature is its frame-based editor, a novel code entry and manipulation technique which makes writing of code quicker, easier and less error prone. In a manner similar to block-based systems, statements are entered and manipulated as single entities, and are laid out on screen automatically. Many syntax errors are avoided, indentation errors are not possible.

Sample of Strype code

While frame-based editing profits from some of the same advantages as block-based programming, it does not, however, suffers the same restrictions: programs in Strype have to full power of the Python language, purely keyboard-based efficient editing is supported, and programs retain the readability, navigability and maintainability of standard Python systems.

Strype is available free of charge, with no installation needed.

Links:

Strype webpage

The Strype editor

The Strype editor for micro:bit

Strype user community

Strype was developed by the Programming Education Tools Group at King’s College London. Team members: Pierre Weill-Tessier, Neil Brown, Michael Kölling

The New Joy of Code – 01: Introduction

Finally it is here: The first of the New Joy of Code programming series.

In this series of videos I will show you how to program in Greenfoot and Stride. Later in the series, we will also get to programming in Java. But ultimately, what you will learn are the principles of object-oriented programming, which you should then be able to apply to any language.

This first episode shows you what Greenfoot is, and what Stride looks like.

Download Greenfoot here.

Check back soon for more episodes.

 

The New Joy of Code – Coming Soon!

The most popular pages on this blog are the episodes of the ‘Joy Of Code’ video series, which teaches programming with Greenfoot. This video series, however, is somewhat outdated by now. So I have decided to update it and start again.

So, coming soon: The New Joy of Code. It will be similar to the old one, a series of short videos that can be used for self study, or in a classroom, but there will be differences: First, I will, of course, use a recent version of Greenfoot (Version 3.1.0 at the moment), but more importantly: I will use our new language Stride for the tutorial. We will later also transition into Java, but Stride is such a great language for beginning to program, that I really want to start with that.

With the videos – you’ll see!

Full paper on Frame-Based Editing out now

We (that is: Neil, Amjad and I) have worked on Stride and its frame-based editor for about four years now, and there is a lot of work in it.

First, Stride was designed and released as part of Greenfoot, and we wrote a few smaller papers about specific aspects of use cases around Stride. Then, more recently, we also incorporated Stride into BlueJ, making the new frame-based editor available to a much larger audience.

Frame editorIn parallel, we have worked on a comprehensive paper, describing the design ideas and rationale behind many of the detailed aspects. It also describes related work and background (which you might like to read in its own right if you are interested in the history of block-based systems or structure editing), and a few small user studies.

I’m glad it is out now; you can read it here:

Kölling, Brown & Altadmri: Frame-Based Editing

It has been published in a special edition of the Journal of Visual Languages and Sentient Systems (focussed on blocks programming). The rest of the special issue is very much worth reading as well – you can find it here.

I would like to thank all our reviewers who contributed many useful comments and suggestions, especially Jens Mönig and John Maloney, and the special editions editor Franklyn Turbak.

Greenfoot LIVE

In order to provide more ways to support teachers who are using Greenfoot (or thinking about using Greenfoot), as well as anyone else interested in Greenfoot, we are starting a series of live chat sessions:

Greenfoot Live
Programming Education Chat With The Greenfoot Team

Greenfoot Live will be a regular chat event where members of the Greenfoot team will be live online and talk about Greenfoot, among ourselves and with you – the users of Greenfoot. The event is aimed mostly at teachers who use Greenfoot in their classes, but also at general Greenfoot users.

We will discuss educational aspects, as well as general programming topics, related to Greenfoot.

You will have a chance to listen to us talk, as well as ask questions.

The first Greenfoot Live event will be held on

Monday, 8 May 2017, at 5pm UK time

That is

  • 5pm in the UK
  • 4pm GMT
  • 9am in San Francisco
  • 12noon in New York
  • 18:00 in Germany, Scandinavia, Italy, France, …
  • 2am in Sydney (sorry…)

You can join us here.

After this first event on 8 May, we will host Greenfoot Live every two weeks. Recordings of these events will be accessible afterwards for viewing retrospectively.

Don’t forget to mark this date in your diary with a big red pen and join us in a couple of weeks!

BlueJ 4 brings a bag of new features


After concentrating on Greenfoot for some time, we have now worked on and released a significant new version of BlueJ: BlueJ version 4.0.

The most exciting new feature for me is the addition of Stride. (I will say a few more words about that in a moment.) But independent of Stride, there are a number of other bits of new functionality that are worth mentioning. These include the addition of Git support, support for writing and running JavaFX applications, a rewrite of a large part of the user interface in JavaFX, a tabbed editor, a fundamental redesign of error reporting, support for HiDPI displays and numerous smaller improvements.

While we were at it, we have also removed some bits that – for various reasons – do not seem worth supporting anymore. These are support for CVS, JavaME and Applets. A bit more about this below as well.

Let’s go through the main features in a little more detail, and I can tell you what we have done and why we have done it.

Git support

[Git logo]People have asked us for support for Git for quite some time. This is not surprising: Git has become the most popular version control system for some years now, and even though Subversion is often good enough for educational situations with small projects, publicly available, free Subversion repositories have disappeared quickly over the last few years. Simultaneously, free Git repositories – such as GitHub – are flourishing. So we have now moved with the times: We have removed support for CVS (which was always a bit terrible) and added Git support. We still support Subversion, as before.

Git, however, has a somewhat different model of work. We have not fully exploited that yet. As before with Subversion, we support only a subset of its functionality. Version control systems offer help in two distinct areas: One is, well, version control (which allows version rollback, etc), and the other is teamwork (which allows integrating code from multiple developers). While they are often used together, they each also make sense on their own: A single developer might use version control, or a team might use team integration tools without version rollback.

So far, we have always only supported the team work aspects of the source control systems. With Subversion in BlueJ, you can update and commit, but not branch or roll back to prior version. Currently, our Git implementation mirrors this and supports the same functionality.

Git, however, can be used somewhat differently. Since it is a distributed source control systems, it makes much more sense to want to use Git with a local repository, just for backup and version rollback. We are currently investigating whether we modify and extend our Git support to offer something like this as well.

At the moment, BlueJ offers a nice, simple and functional interface for Git – ideal to start learning about source control – just as it did for Subversion. (If you want to try it, some setup and use information is here.)

Support for JavaFX

Javafx_logo_colorJavaFX is the new Java GUI toolkit. AWT has been out for many years, Swing has thoroughly replaced it long ago and has been the GUI toolkit for everything Java for the last 15 years or so. Yet now, Swing itself is on the way out.

JavaFX has much better support for modern GUI design, from styling over visual effects to animations. It has taken a few years, but JavaFX has now become good enough that it is ready to replace Swing for all modern new development work. Oracle has said that they will no longer develop Swing. The future is FX.

Running JavaFX in BlueJ has been almost impossible, since its invocation differs from normal method calls. (Well, there were some tricks one could use if one knew enough of the internal workings, but it was really not straightforward.)

Now, if you write a JavaFX main class (by inheriting from JavaFX’s Application class), you will automatically get a ‘Run JavaFX Application’ option in your class menu. That’s it – use it, and all is well.

But it gets even better: If you have used JavaFX, you will know that it makes use of CSS files for styling. And you can now create and edit CSS files (which are plain text files) straight from within BlueJ!

BlueJ interfaceInterface rewrite

We did not only support JavaFX for BlueJ users, we also started to rewrite BlueJ’s own user interface in JavaFX. There were a number of reasons for it: Firstly, the Stride editor could not have been written without JavaFX. It has a much more modern, dynamic interface than our old Java editor. Secondly, we were receiving an increasing number of bug reports from users with HiDPI displays. Swing does not always cope well with this. And finally, making use of some of FX’s features, such as the ease of creating animations, allowed us to make some aspects of the interface nicer.

All is not well, though. Not the whole interface has been rewritten yet, and some parts are very difficult to rewrite, for technical reasons. Thus, BlueJ currently uses a mix of Swing and JavaFX for its interface – a fact that itself creates some problems. Incorrect display on HiDPI screens, for example, while reduced, is not completely gone.

We are still working on that. JDK 9, when it comes out later this year, will help, and we are still doing what we can with JDK 8 until then.

The new editor, or: Tabs, finally

The BlueJ editor now has tabs! Some users have asked for this for the last 10 years, while others liked the multi-window model. The world has decisively moved to tabs for most applications, though, and this is now the model that most users are familiar and comfortable with.

Having your code in tabs, instead of windows, has, however, one drawback: You cannot show code side-by-side. To retain that option, we have added functionality, available by right-clicking the tab rider, to move any tab to a different window. This way, code still can be displayed side-by-side, for easy comparison.

Improved error reporting

ErrorsFor many years – in fact, since its creation in 1999 – BlueJ has reported one error at a time: When the Compile button was pressed, BlueJ highlighted the first error and stopped for you to fix it.

This has now changed in three ways: Firstly, all errors are displayed at the same time. Secondly, the errors are marked in the source code with a squiggly red underline (and the error message is displayed near the error when you click on it or the mouse hovers over it), and thirdly, the error checking happens automatically as you type. This way, errors are marked as you make them, for you to come back to at any time of your choosing to fix them.

Stride – A new language

windowThe most substantial new feature in BlueJ 4 is the addition of Stride as a new supported language. Stride was first developed and published as part of Greenfoot, and has been in use there for about a year. It has met with substantial interest since its publication and we received regular requests to include it in BlueJ.

So here it is.

So, what actually is Stride? Stride is a very Java-like language that differs mostly in its frame-based editor. This editor offers new program entry and manipulation interactions that try to get the best out of block-based and text-based editing. Not by displaying the two modes side-by-side, as some other systems do, but at the same time.

I will not talk about it much in this post (but instead introduce it more fully in a future article), but if you are curious, there are some sources where you can have a look: This page briefly describes frame-based editing, and there is a short series of videos demonstrating how to use it. Don’t worry that the videos make use of Greenfoot rather than BlueJ – the language is the same.

The Stride implementation in BlueJ has been significantly improved since publication in Greenfoot. The performance and functionality of the editor is better – progress that will also make it into the next Greenfoot release.

I will write more about Stride in BlueJ later. For now, just note that you can now write in Stride in addition to writing in Java. If you are a teacher, especially at school level, this has the potential to substantially change how you introduce programming.

Spring clean: What’s out

We always try to keep BlueJ small and simple, at least in its appearance, functionality and interface. If we continually add things, this gets very hard. Thus, sometimes things should go out as well.

We have taken the opportunity of this new release to throw out a few things that are getting old and are not much used anymore. These are support for applets, CVS and JavaME. I know that there are still a few people using some of this. Some teachers, for example, use applets as an introductory framework. To those teachers – sorry. But these are dying technologies, and you should move on. JavaFX, for example, provides a much nicer alternative to applets for those who want to start with a graphical framework. CVS – once the most used version control system – has been superseded first by Subversion, and now by Git, and JavaME – well, what is there to say.

Miscellaneous other aspects

A couple of assorted other issues may be worth mentioning:

  • The JDK is now bundled with the BlueJ download on Windows and MacOS. This makes downloading and installing easier (since you don’t need two separate, dependent downloads) and ensures that BlueJ always runs with a Java version that it has been tested on, and we know it works. It will no longer be broken by running with an incompatible JDK.
  • BlueJ 4 does not currently work on the Raspberry Pi. This is because JavaFX is not available on the Pi at the moment. BlueJ 3.1.7 continues to be available in the Raspberry Pi image.

Try it!

So, if this sounds interesting, download BlueJ now and try it out! If you are a teacher, join us in the Blueroom for more discussion about use and pedagogy.

Let me know in the comments what you think of it, what questions you have, and what aspects you would like me to write more about.