I’ve been at work on Enchanting 2 for a while now, and hereby unveil it:

Enchanting 2 aims to make it easier for kids to program robots than Enchanting 1, by:

letting kids program in a lively environment, activating changes to the code as quickly as the kids think about them. [v1 took nearly a minute to make a change because the code had to be re-uploaded and re-compiled]

making the flow of the code more transparent, showing what happened and how.

allowing roboticists to collaborate more easily by working together on separate computers.

letting you have more than one program stored on your robot. (And, as a bonus, with the robot scripts being XML files they are well-suited for version control).

And, now I need to get some gear to use with my Pi. Sensors and such. I’m getting a Gertboard through Newark Electronic/Element 14, and I’ve got a BrickPi already. There are tons of other interesting devices that work with the Pi … like the PiBrella or TiddlyBot … let me know in the comments if there is anything in particular you’d like to see supported … so I’ll know a few things I should order : )

I have some ideas for a next major version of Enchanting, and would love some ideas and input at this formative stage.

Why? Why a new major version?

I’ve found that, while Enchanting is easier (and more powerful) than alternatives for programming the NXT, kids still do not understand what is going on, and why a program works or does not work. My aim is to fix this. I want kids to understand programming, and enjoy it, and be active in creating and using technologies, and not just passive consumers of the same.

I have found a great essay by Bret Victor called “Learnable Programming”. I want to incorporate several of these ideas into Enchanting.

In particular, I want students to be able to pause a program, and to be able to scan back in time and see how the sensor and variable values have changed, and which paths the program took in execution. I can see that if there is a (really simple) simulator component (like NXT-on-Stage, but probably as a separate application), it would be possible to allow a user to pause a program, tweak a value, and see how that affects a robot’s progress. (In particular, this could be interesting for seeing how different values affect a line follower, or for tweaking a PID controller). See this video, from 12:00 minutes to 14:40, for an idea of what I mean.

The other reasons I want to create a new version of Enchanting include:

there are new devices out that would be nice to support. (I’m most interested in the BrickPi, but I did pick up an EV3, as there is a lot of demand for its support).

there are some misfeatures in the current Enchanting that’ll be very difficult to fix:

Enchanting does not communicate changes in lists between the UI and the robot.

There are various connection issues that are difficult to reproduce, diagnose, and fix.

The fact that you can only have one Enchanting program on the robot at a time.

The code/compile/upload/test loop is too long and hinders understanding.

I’ve been contemplating how on earth I might achieve these aims.

The best idea I’ve come up with is that an Enchanting application, running on the robot, is sent code from the computer (or loads it from a file), and runs it, interpreting each command as it gets to it. It would be sort or like an emulator, a virtual machine, or an interpreter. When a command is run, any resulting value or state change is retained, so that it can be displayed in the user interface. [It might even be nice if two people can connect to the robot simultaneously and code together. That is much easier said than done, though.]

When a user has paused a program, they get a list of which commands were run, and when, and what the result was. The program is very interactive. I am learning towards supporting WiFi connections only. Perhaps bluetooth (ugh!) or USB connections might be possible at some point. I think the first target machine will be the BrickPi, but perhaps a simulator or EV3 are possibilities. I do think the NXT will come later.

Here are some of my preliminary thoughts on the design of the interpreter engine:

There is lots to figure out.

Oh, did I mention that I am presenting in Edmonton to teachers and computer technicians from across Alberta, Canada, on Enchanting in late November, and have an unreasonable dream that I’ll have something to show them of this new version?

I do wonder about changing some technologies.

Programming in Squeak Smalltalk is great, but few people desire to spend the time to learn it, and it makes it harder to help with the project. It may prove fruitful to use Snap! v4, written using HTML5 technologies, as a basis. (I just can’t help but think of all the work I’ve put in to modifying Scratch that would have to be redone. And the result could not even pretend to run the UI on a Raspberry Pi [which would be nice]. But being able to run it from an iPad or a mobile device is a big plus.)

I’m actually not a big fan of Java, either. I will be more than delighted if I don’t have to include a Java Development Kit with a future version of Enchanting. I’d been toying with programming some things in C++, but, am seeing that if I want to be nimble, it would be ridiculous to rewrite the great things that are working now and can be reused. (Time to set up an IDE right, as I can test the VM code on a computer.)

And, github is all the rage these days. Perhaps hosting code there would help. (I do so love bzr, though).

Lastly, I wonder if having multiple sprites that you can program is confusing. I’ve never thought so before I read what the Learnable Programming essay says about having a powerful metaphor.

I’d love to hear some thoughts, and to know if others are interested to keep up or help as this evolves.