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.
This video is mostly for those who want to get a first impression of Greenfoot. We write a simple game in seven minutes (realtime; no cuts!), using Stride. For those who already know Greenfoot with Java: You will see that writing in Stride is not very different to writing in Java. For those new to Greenfoot: This is a quick introduction to Greenfoot and Stride at the same time.
As always, Greenfoot is available for free download.
This is the first in a series of videos introducing Stride. Don’t be put off by the intro at the beginning – you will see code soon enough.
I welcome questions and comments, especially suggestions what you would like me to address in further posts or videos.
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.
Do you want to learn programming with Greenfoot? Do you speak German? Is your German better than your English?
Then this may be your lucky day.
Frajo Ligmann, a school teacher near Aachen, Germany, has started to produce German language versions of the Joy Of Code videos. At time of writing, he has produced six videos already, which you can see on his Youtube channel. And he is working on more, which should appear as time goes on.
Producing videos is a lot of work and very time intensive, so be a bit patient if you’re itching to see more. If you’re happy to watch these in German, bookmark his page and leave him a comment, either on his page or right here below this post.
Many thanks to Frajo Ligmann for this amazing contribution to our community!
The BlueJ/Greenfoot team are quite a small outfit (currently four people), but we are looking to hire two more team members.
The official job advert is here, but there’s a better starting point if you’re interested: Neil, one of our team members, has just written a blog post about these two new positions. Read this first, and then get in touch if you think this might be for you!
Finagles’ 8th Rule: Teamwork is essential; it allows you to blame someone else.
Today, we’re finally getting our breakout game into a playable state! Yes!!
See how to implement functionality to recognise when the ball hits a block, and make the block disappear. This is really the centrepiece of our program – from now on, everything else is detail.
Concepts discussed: collision detection, removing an object from the world
Download (scenario as of beginning of this episode): breakout-v7.zip
90% Rule of Project Schedules: “The first 90% of the task takes 90%
of the time, and the last 10% takes the other 90%.”
— (source unknown)
One more time, discussions of loops.
Loops are such an important concept, and there are so many variations, that it is really important to get practice with them and get them properly into your head. To this end, we’re looking one more time at loops here before moving on to some new concepts in the next episode.
Today, we’re using a really important, fundamental loop pattern: A while loop with a simple loop counter. It looks like this:
int i = 0;
while (i < NUMBER)
{
doSomething();
i = i + 1;
}
Watch the video, and try to memorize this pattern. It will come in handy later!
Concepts discussed: loops, while loop
Download (scenario as of beginning of this episode): breakout-v6.zip
The First Law of Programmer Creativity: “The cost of software maintenance
increases with the square of the programmer’s creativity.”
— (source unknown)
We continue with our breakout scenario, an also with our investigation of loops. Jumping right ahead, I show you both how to write a nested loop, and why and how never to do it.
Concepts discussed: loops, while loop
Download: breakout-v5.zip