Small Basic and the EV3. Time to go play.

I saw a couple of blogs mentioning that Small Basic now has an extension that will interface with the Lego Mindstorms EV3 robot.  Being a Small Basic fan I had to give it a try so I borrowed an EV3 from one of the students.  Five minutes after figuring out how to move the program from the computer to the robot with the proper app I had the robot running around on my floor.  Oh boy, is this going to be fun.  Draw it on the screen with a turtle then draw it on the floor.  Kids are going to have a blast.  Having what is now a dual purpose kid friendly language is going to be so cool.  I have run the Mindstorms NXT with Python and Java but they were just a bit difficult to get setup for the kids.  They were also both a bit feature short.

I have programmed the NXT in Java, Python, NXT-G, Scratch (Enchanting) and RobotC.  NXT-G is just a pain.  It has the usual problems with D&D languages; lack of room to see the program, not method friendly, and using the wires to pass variables is a mess.  NXT-G also does not seem to get users ready to transition to a more traditional language.  Not always a necessity for home users but at a school I want to be able to have a bit more structural similarity in the languages.  At least in Scratch a loop looks like a line code loop.  Enchanting uses Scratch to program the NXT robot but it was a bit of a pain to implement and was a bit buggy.  RobotC is by far the most versatile, feature rich and transitional but the price sort of takes it out of my options to use at school.  (If it ain’t free, we cannot afford it.)  Having Small Basic, by far my favorite transition language from Scratch to Python/Java/VB languages, with this extension is just frosting on the cake.

So far all I have done is a For loop in an attempt to draw a square.  It is going to take some tinkering to get the 90 degree angle right and to see if there is a motor synchronization command so the robot will go straight.  (The motors are never exact so the robot has a tendency to curve off the straight.)  I like it when kids have to tinker to get things to work.  It looks like getting the sensors to work is going to be not as simple as RobotC or NXT-G, the extension only seems to see the raw input and the programmer has to figure out what to do with it, but that can just add to the problem solving.  I will have to dig through a couple of example programs to get an idea how things work but it should be fun.  Now if I can just get kids that have EV3s to loan them to the school.  I have eight NXT kits so I just need the bricks.  I am going to have to put the word out when school starts.

Looking on line I see there are attempts to build a Scratch/EV3 interface.  The setup requires using leJos, a Java virtual machine that allows the brick to be programmed with Java.  More stuff to play with.

There is just something about a job that requires I play with Legos and robots and kids.  I love my job.  Now I need to go home and play with my robot.

Back to the MOOC.

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.

MOOC Assignment Wakes Good Idea Fairy

 

We got the first programming assignment for the APCS Principles MOOC I am taking.  Here it is:

You will develop one program using Snap!. Your program must address the following requirements:

• Include the basic programming elements of Snap! For example, programs should demonstrate appropriate use of numbers, text, variables, statements, mathematical expressions with arithmetic operators, logical and Boolean operators and expressions, and lists. Your program must have at least 5 if or if/else statements and at least 3 loops.
• Demonstrate the creation of abstractions to develop and manage the complexity of the program; your program must have three blocks that you create. You must have at least one Reporter and one Predicate. At least two of the blocks must also have parameters.
• Describe the creative process and the use of algorithms as building blocks of the program.
• Include comments that help the reader better understand your code

I was sitting there thinking why is this assignment so confusing and difficult to me.  Then it hit me, it is backwards.  I usually have a task I want to do, a game idea or an assignment program I have dreamed up or some program from a book.  This assignment wants 5 ifs, 3 loops and so on.  It is just weird building from that direction.  When given a task or assignment to program I can just go through the planning and design steps and away she goes.  With this assignment I have to dream something up that fits the criteria.  I have a problem when I dream something up.  Typically when I dream something up from Good Idea Fairy Land part way through I reach an “OMG, what have I done to myself?!” stage.  So several years ago I decided the Good Idea Fairy was a bad spirit.  This assignment requires I wake the Good Idea Fairy.  This is a bad thing.

I can understand the idea of this backward approach, it really kills the chance of plagiarism, but it sure is awkward.  Not only do I have to design and code, but I have to think of something to design!  Not my strong point.  Coming up with ideas is not a problem, I have lots of those.  Coming up with an idea that I can do with Snap! in the time allotted and that does not turn into a can of worms because I did not have the time to tinker with it is a problem.  I have had Good Ideas before and usually discover I have bit off more that I can really want to chew.  Oh well, no matter what it is bound to be fun and a new learning experience.