Back to the MOOC assignment. Instead of reinventing the wheel (or waking the Good Idea Fairy) I thought I would just adapt one of my old programs to Snap!. Snap! looks like Scratch so I will grab one of my Scratch programs and I am done. Snap! is not Scratch. Things that work in Scratch do not work in Snap!. Collisions for example. Hide a sprite in Scratch and it is not subject to collisions. Hide a sprite in Snap! and it is still subject to collisions. Do you how long I looked for a syntax error before I started testing this hypothesis? Way to long. My Asteroids game works great in Scratch. In Snap! it requires quite a bit of recoding.
Of course now I have to figure a way of getting the assignment requirements into a fairly simple game. I will add complexity to achieve the needed elements. I can do that. I am good at making simple things complex.
Learning a new language is always good for hours of entertainment. Learning a language that looks identical to one you already know, but isn’t, just adds to the entertainment value.
I am not a big fan of Scratch. I use Scratch in my Programming I class because it is an easy introduction to programming and the kids can build some fun little games. I have a couple of assignments I have been giving the kids for quite a few years and I have the variations of those assignments down pat. Once the kids have the general idea of loops, decisions and what not we move on to Small Basic. The quicker the better. Working with this Asteroids modification has caused me to re-examine Scratch (and Snap!). After a few hours I have come to the decision I am really, really not a big fan of Scratch or Snap!. I like all my code in front of me or at least on different screens. Each sprite having its own code window is just a pain. Flipping back and forth to remember what the sprite is doing just drives me batty. The little detail that a custom block will not execute when the block is open for editing had me chasing non-existent errors for a while. There is no good way of following the execution of the program, no good way I can see of debugging. As soon as the program gets big it is almost impossible to keep track of the flow. It is probably more of a mindset than anything else but I will never be a fan. For me Scratch is great for writing simple little animation games and for teaching some very basics without having to worry about typing and syntax. Beyond that it is time for line code and a good IDE.
I feel the same about all the drag-and-drop languages I have worked with. They are just awkward. Complexity is not their forte. It is possible to do cool things with them but in the end they are teaching tools with a limited use. The fact that many of them do animation so nicely makes it tempting to keep the kids working in these languages because the kids are willing to work in them. I think only having kids do a programming course where all they see is drag-and-drop is a big mistake for their CS education. Kids often take only one semester of programming, they have to see a line code language in that semester. Nothing fancy; Small Basic, Arduino (not really a language but whatever), RobotC, Python or something along those lines. It is possible to have fun in those language and still educate. It is possible to keep kids awake in a line code class if the assignments are kept interesting. Just do not bury them in some geeky math based coding assignment. Save that for the second semester. Most of the second semester will be the geeky “I like programming” kids.
Now back to the MOOC. The only language the students (mostly prospective APCS Principles teachers) will see in this MOOC is Snap!. People have a tendency to teach how they learned. Using a drag-and-drop as the only language is a mistake in my opinion. I think a lot of first year CS/programming teachers start way behind the Eight Ball when it comes to languages. They have got to see more. They do not need to be expert coders but they have to know what is out there and why it is there.