When you give up the idea of characters as your sole point of source code representation, a host of possibilities opens up to improve the visual appearance if your program. This short video shows some of then as implemented in Stride.
Stride is implemented in the Greenfoot environment, available from here.
In the third part of our series introducing Stride and frame-based editing, we look at the various ways in which the editor can provide you with help in writing your program. If you consider using Stride, it will come handy to know these sources of information.
Stride is implemented in the Greenfoot environment, available from here.
I was at a Dagstuhl seminar recently, about programming education, and one of the things we discussed were common misconceptions of novice programmers. One of these, reported by several seasoned programming teachers, was the difficulty in interpreting the assignment symbol in C-style languages:
number = 42
There are several things that can be misinterpreted here. Firstly, the equality operator is non-directional. Some students have problems remembering which way it operates. Consider this statement:
a = b
Which way does it assign? To all of us who have programmed for some time this may seem a silly question – we get used to the right-to-left semantics so thoroughly that we can hardly imagine it to be different. But for beginners? Not so clear. (And, of course, the direction is arbitrary; language designers could just as well have decided the other way.)
The second possible misconception is related to the previously learned meaning of the equals symbol: to express equality. This has been used in maths for centuries, and taught to most pupils before they ever encounter programming, and is quite different from assignment. Consider this code fragment:
a = 0;
b = a;
a = 7;
What, now, is the value of b? For learners holding the equality misconception, it will be 7. This is not entirely unreasonable; it is indeed an internally consistent mental model. The misconception is that variables, once expressed as equal, remain linked. So the equals symbol is interpreted as equality (“b is the same as a“), which might then remain true for the future.
Many people have commented for a long time that the C-style equality-as-assignment is not ideal. Many languages do better. Algol and Pascal, for example, already used a different symbol in the 1960s, quite explicitly to express the directionality more clearly, and to distinguish from equality:
number := 42
I have always like this much better than the single equals and have always been mildly annoyed by the C-style syntax.
So when we designed our language Stride recently, the question surfaced again. What should we choose?
We had two competing goals: On the one hand, we wanted the syntax to be clear and expressive, but on the other hand we want Stride to be a pathway into Java, so there is also a strong incentive to be consistent with Java syntax. (Java, of course, uses the C-style syntax, so these two goals are in conflict.)
At first, we prioritised the Java-compatibility argument and chose the equality symbol. The first release of Stride had this as the assignment operator. But then the Dagstuhl discussion happened, and I started to think again.
In Stride we have an advantage: Because the representation of the program is not directly typed in, but produced by the system in reaction to command keys, we are not restricted to characters that can easily be typed on a standard keyboard. So initially I considered going back to a syntax that Smalltalk used (in early versions, before it fell back onto the := variant), a left arrow:
I liked it for its clarity of expression, but it has one disadvantage in a teaching language that is intended to lead to Java and similar languages: it does not directly prepare learners for the equal symbol so widely used for assignment in other languages. After we discussed this in one of our team meetings, Neil Brown, one of our team members, came up with what I think is a brilliant compromise:
This is what assignment now looks like in Stride. The double arrow still has a visual link to an equals sign, but is clearly distinct from it; it is also clearly directional. We still use the equals key as a command key to enter an assignment, further reinforcing the link for the future.
Here’s what our assignment looks like in context:
I am very happy with it. I think it reads well and is the closest we can get to reaching two competing goals.
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.
At the beginning of April this year, we opened a new web site: the Greenroom.
The Greenroom is a web site where teachers who teach with Greenfoot can share resources and have discussions. It was clear for a while that sharing of resources was a powerful thing that was urgently needed for the Greenfoot community. Greenfoot is different from many other environments, teaching with it requires different projects and different ideas, and thus getting started with it, as a new teacher, is challenging. Having a community to talk to, to ask questions, to get ideas, to get tried and tested material, makes a huge difference.
Yet, this is a space where many have failed.
It is often said, with only slight exaggeration, that there are more teaching resource repositories than there are teaching resources. The fact is, countless resource repositories have been created, and most of them have tumbleweed blowing down the main street.
The typical pattern is this: A repository is opened, a flurry of activity follows, resources are submitted (often by the creators and other people personally involved or contacted), and then it dies down. A few months later, little is happening, resources are not maintained, few new resources are added, you can hear the cold wind blowing through empty spaces.
A high profile example is the repository of resources on the ACM SIGCSE website (one of the largest organisations in computer science education). It was – as far as I know – opened in early 2004, and initially attracted a good number of submissions. However, this quickly died down. Looking at the recent submissions, it seems that only four resources were submitted in all of 2008. This went down to three in 2009, with one single submission (so far) in 2010.
Now, I don’t want to pick on that one particular repository specifically. This pattern is not unsusual. I am pointing to it here as a typical example. Making repositories thrive is hard. (We have recently published a paper about this.) So, when we designed the Greenroom, we were very worried about meeting the same fate: spending a whole lot of effort in creating a repository site, only to have it die a slow, quiet death after a few short months.
I am happy to say that we seem to have avoided that fate. The Greenroom is alive and well.
From September 2009 to March 2010, the Greenroom existed as a Google Group. This gave us an excellent discussion forum, and quite poor storage of resources. Over these first six months, about 170 people signed up. Then, at the end of March 2010, we finished our custom implementation of the new Greenroom, and we were amazed at the result: even though only half of the Google Groups subscribers moved over, we surpassed the old subscriber numbers within two weeks, and then they continued to climb. Now, after eight months, we have about 900 people signed up. Lots of resources have been posted, and many interesting discussions are going on.
Subscriber numbers of the Greenroom; old (red) and new (orange)
So, what makes this site work, when so many others have failed?
I think, in building such a site, you need to address a number of questions:
And most importantly:
I think there are some design choices you can make to address many of these things. As a result, we have built a repository site that is quite different from others. We decided to not use a standard platform (because they only gave us the same old stuff that we didn’t want) and build our own from scratch. The main design choice, which makes most of the difference is this:
The site must be about people, not about stuff.
So we designed a site that is primarily about community, and then about material. There are many design details that embody this idea:
In short: I think people should re-think teaching repository design. It has worked for us. (More details about this are in our paper.) There is daily activity in the Greenroom, many people visit regularly, we have frequent interesting discussion in our forum, and a large number of excellent resources. It has been going much better than we dared to hope.
So, if you think about designing a resource repository, think about the people, not about things. And if you are a teacher interested in Greenfoot, join the Greenroom. There are many friendly people there happy to help.
![[image of code keypad]](https://blogs.kcl.ac.uk/proged/wp-content/blogs.dir/192/files/2010/06/keypad.jpg)
A security access keypad
Here is an image of a security access keypad. It controls access to a private parking area at the back of my house.
Maybe not quite as secure as intended…
Over the last couple of weeks, I have started to look in more detail into the proposals for adding closures to the Java language. The most discussed proposal right now is the BGGA proposal, so I’ve been concentrating on that one first.
To say it up front: I have always had some doubts about adding closures to Java, but with this proposal I am firmly in the “contra” camp.
I had originally intended to write up my views of the proposal here, and the problems I see with it, but I don’t think that is necessary in detail anymore. Several other people have recently done this.
If you’re new to this debate, I suggest you start by reading some of the following: There is, firstly, the original BGGA Closures proposal, Josh Bloch’s The Closures Controversy talk, in which he discusses some of the problems, and Neil Gafter’s response to Josh’s presentation.
And now there are two very nice commentaries, one by Bharath, and one by Tim Bray, both of which I very much agree with.
So, instead of repeating their arguments, I’d just like to add one different aspect to this debate: Looking at the Java Language design from an HCI perspective.
Wording is important in good human-computer interaction design. Wording of commands, messages, status and other interface elements can make a big difference. So let’s think for a minute about the word “safe”.
Safe is good, right? Is there anything bad about “safe”?
Firefox has a “Safe Mode”. And it’s a really bad idea. Why, you ask? “Safe” sounds really reassuring. An army of marketing experts could hardly come up with a better word, you would think.
So what’s not to like?