Today I will show you what tools and support Greenfoot gives you to transition from Stride to Java, once you are ready to step into a fully text-based editor. But first, as a bonus, we will see how you can include Stride code in a text document.
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.
Two computing practitioners from an Ada shop in New York, Dr. R.B.K Dewar and Dr. E. Schonberg, who are also professors emeritus at New York University, have recently slammed Java as a first programming language. Their article has received quite a bit of attention and created wide discussion.
I think they are completely barking up the wrong tree.
Dewar and Schonberg report some observations, and than jump to conclusions that are not in any way supported by the observations or their argument.
Specifically, they state that today’s students are lacking certain skills (low level programming and formal methods), and then go on to blame the use of Java as an introductory language for this problem.
To state my conclusion upfront: They describe a badly designed curriculum, and then blame one programming language for the education’s problems.
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.
We all agree that Java needs simplicity – we just don’t agree what that means.
Several things came together recently that made me think about simplicity in the Java language again, and what that might mean. And one thing is clear: simplicity is not simple!
Events that prompt me to write about this again were feedback I recently received about another blog entry (where I discussed simplicity in more general terms), a discussion by the Java Posse guys about new language features, and my own teaching. (First term is about to draw to a close in our parts of the world, so I’ve just been through 12 weeks of teaching another cohort of freshmen programming in Java again.)
The executive summary is: I think many of the recent discussions for changes to Java are in danger of pulling the language downhill fast, and the term “Simplicity” has different meaning to different people that cause directly contradictory results for language design.