MindTrains

Bret Victor has written a wonderfully thought provoking essay on designing a programming system for understanding programming.  In it he critiques a number of existing 'learn coding' environments and examines in detail what he feels is missing, and suggests some alternative approaches illustrated by videos showing how they might work.

At the end he lays down a challenge to designers of learnable programming environments to answer a series of questions (or go back to the drawing board!) so here goes:

Does the environment allow the learner to...

read the vocabulary? -- Is meaning transparent? Is meaning explained in context, by showing and telling?

For MindTrains, the vocabulary isn't words as such, but track pieces.  However there are two elements to this.  Firstly, the pieces that make up the normal flow of the program are pretty obvious to anybody who has played with a train set.  However, secondly, it is the special pieces of track, with track-side features, that I anticipate containing functionality (in the prototype, this is where operations are made on the train's carriages and input is collected and output is displayed).  Here is where there is definite room for improvement.  The prototype has no help features or explanatory text and therefore, without changes, would fail here.  However, these things could easily be added and, in particular, Bret's suggestion of showing, in context what each track-side feature would do is a real inspiration.

follow the flow? -- Is time visible and tangible? At all meaningful granularities?

So this is the real strength of MindTrains: it clearly shows and allows the programmer to follow the flow.  Time is very visible and tangible as the execution point (train) is clearly seen moving through the code (track).  With the addition of video-style fast-forward and rewind controls it makes it easy for events to be replayed to analyse why things occurred in a particular way.  Bret's examples show more complex animation code than I think MindTrains would ever be used for, and the discussion of granularity is again probably more important for more powerful systems.

see the state? -- Does the environment show the data? Show comparisons? Is hidden state eliminated?

In MindTrains, the data is held in the train's carriages and would be visible on screen at all times -- a little like the cells in a spreadsheet show the data.  In Bret's essay, he combines timelines with graphic interpretations of things like colour and angle of rotation in a very Edward Tufte-like visualisation.  I really liked the use of images over numbers for showing in a concrete way what these values would do -- however, again because I don't believe MindTrains would ever be used for very complex development it is unlikely that the timeline would provide much value, and I would be concerned that, done badly, it might add to the cognitive load.

create by reacting? -- Is something on screen as soon as possible? Is the parts bucket on the floor?

MindTrains easily meets these requirements as the 'parts bucket' is right there as a bunch of visible pieces of track, making the extent of possibilities immediately clear and encouraging experimentation.  Making it put things on screen as soon as possible is also pretty trivial -- the MindTrains programmer can modify the track while the code is running.  Here some additional functionality to stop the train falling off the end of the track would help (i.e. pausing when there is an interruption in the rails) and combined with the ability to rewind a few steps I believe it makes meaningful 'live' coding easy.

create by abstracting? -- Can the programmer start concrete, then generalize?

Here Bret raises two ways that programming allows you to generalise: using variables to start constant, then vary; and loops to start with one, then make many.  I have witnessed this watching my own children code -- writing Scratch programs as a simple list of instructions is an easy starting point -- however getting them to make use of loops and variables, rather than just copying and pasting again, is actually quite tricky.  My belief is that the MindTrains metaphor strongly encourages students to experiment with loops and conditionals (points), probably because that's the standard toy train track configuration.  I still remember our delight when my six year old daughter created an infinite loop (a simple circular track) in her first go at using the prototype.  By making the train carriages the holders of variables, these are a first class (pun intended) aspect of the metaphor too, however I think more careful thought into how to encourage their use (vs constants) may be needed.  For example, perhaps all values in the system should be stored in carriages -- doing away with literal constants entirely.

Does the language provide...

identity and metaphor? -- Is the computer's world connected to the programmer's world?

Yes, yes and thrice yes.  MindTrains has a very strong metaphor (the toy train set, in case you missed it) that adds some very powerful cogs to the mental gearbox.  (Oh, and I have read MindStorms!)

decomposition? -- Can the programmer break down her thoughts into mind-sized pieces?

Hmm, this one's a bit more tricky.  MindTrains 'programs' do quickly sprawl out of control once you get beyond the simplest code.  This may not be a problem, as I do envision the software being used as 'step 1' of the coding journey and not as a fully blown system for writing sophisticated programs.  However, that said, being able to package up a bunch of functionality and hide it away is absolutely crucial to writing decent code, both from a software engineering perspective of re-use and maintainability, but also in terms of freeing you to think.  I therefore had sketched out the idea of adding 'magic' tunnels to the track that would allow your train to be taken to an entirely different land, with its own track, in which sub-routines could be created and re-used.  I haven't developed this further, but it seemed like it should work -- particularly if the new land was visibly 'stacked' on top of the land with the 'calling' tunnel entrance.

recomposition? -- Can the programmer put diverse pieces together?

Well, building on the magic tunnels (taking you to MindTrains tracks in a new land) it would be possible to compose your program from remixing different areas.  One issue that would crop up pretty quickly is that the carriage names (variables) would need to be consistent otherwise the code would not work.  However, this might be easily fixed by allowing the entrance to the tunnels to be prefixed with interchange points where the variables have to swap over into a new train with the correct carriage configuration (signature) for the new land (function).  Again I believe this would work, and incrementally builds on the metaphor without fatally undermining it.

readability? -- Is meaning transparent?

As MindTrains isn't an alphabetic code, this is slightly difficult to answer.  However, let's pick up on Bret's main point which, I believe, is consistency.  This allows logical deduction when reading code and educated guesses when writing code.  In the examples he gives this is mostly about supplying parameters to library function calls.  Here, I could gloss over this challenge by saying that because the functions would not be typed, and are picked from the palette of track pieces, there is little room for error.  Since every bit of track behaviour would be parameterised by the content of carriages on the train then it simply becomes a matter of standardising these and providing suitable context-sensitive documentation.  These things are all true, however, it breaks down as soon as you hit the user-supplied functions (the magic tunnels) as the metaphor changes.  The great thing about languages like Smalltalk is that they are consistent from the ground up.  There is no difference between your objects and the ones provided by the system -- this gives the programmer a great example to follow.  I therefore think that this aspect of MindTrains does require more thought.

Conclusion

So, in summary, does MindTrains make it through Bret's checklist intact?  More or less I think!  It was certainly a useful exercise to examine, more critically, the design assumptions I'd made -- particularly around the role of contextual documentation (something I'm terrible at providing) and how to enable modularisation of MindTrains code.

Are there any things that I would add to the checklist?  One that I think that is missing is:

who is the system for? -- Which programming concepts are its focus?  What results does it encourage?

I think that, as programmers, we are often lulled into a false sense that, because any sufficiently powerful (Turing complete) programming language is equivalent to any other language that it is possible to create the 'one true way' of learning to program.  However, that's clearly not the case as there are many languages and environments, all with their own strengths and weaknesses that make certain styles of programming easier (or harder) and certain types of resulting programs easier (or harder).

Therefore this question is about moderating ambitions -- doing a few things well, rather than lots of things badly -- and being up front about it!  

So how would I answer this for MindTrains?

The system is for real programming novices (not necessarily limited to young kids!) who perhaps are not familiar with programming at all.  It is designed as an accessible primer in basic concepts, rather than a fully fledged environment for 'real' coding.  In some ways it aims to make playing with the code (trains and tracks) interesting in and of itself -- rather than than putting the focus on the side effects of that.  It's selling point won't be 'you can write a game/website/app!'  It's based on the Montessori-style philosophy of getting a 'feel' for maths through physical manipulation of beads and blocks before moving on to the abstract techniques, and tries to emulate that in the manipulation of train, carriages and tracks to lay the mental foundations for programming.

Tom Armitage's short radio programme argues that learning to write computer code means learning to think in a modern way, and that it should spur creativity: the possibility of doing entirely new things. 

This reminds me of a group discussion I had earlier in the year where I was extolling the virtues of having learnt to program.  I was (somewhat passionately) explaining that it had given me new ways to look at the world and had proven useful in many more ways than simply providing me with a career.

I then stated my belief that all children could benefit from this, but I was interrupted mid-flow by someone who said that they could not think of anything worse than forcing all children to think in this way.

I have to admit that I was shocked into silence at this point, but it has bugged me ever since.

I think the position that they were coming from was that they believed that learning logical thought would somehow rob children of their creativity.  As if learning is part of some zero-sum game that means that becoming a programmer would not leave space for artistic freedom.

I clearly do not think this is the case -- it simply adds another capability to your mental toolbox.  In exactly the same way that learning to use a drill doesn't mean that you forget how to use a paintbrush!

MIT's App Inventor allows anyone to create Android mobile apps using a block-based visual programming language (like Scratch).  Originally created and run by Google the software has now been donated to, and been made open source by, the Massachusetts Institute of Technology.

I found it a bit fiddly to set up, relying as it does on a login to a web-based frontend screen designer, a locally installed Java web start application and a bunch of steps to connect it to your phone (if you want to test your code on a real device).  I can imagine that using it in a classroom environment would be tricky unless you were very confident, or working with a small number of students.

However, that said, it is very satisfying to be able to quickly create a simple application that makes use of the touch screen or accelerometers; the sense of achievement is much higher than you would expect (perhaps because you don't normally think about programming these devices).

The two window approach (the frontend designer and the code editor) highlight a problem common to pretty much all software development systems -- that of representing the separation between the world that the code inhabits, and the world that the code affects.

Dr Tilly Blyth from the Science Museum's report on 'The Legacy of the BBC Micro' makes fascinating reading for someone who lived through that period of computing history.  It documents how the BBC Micro was developed and attempts to evaluate its impact through various bits of research and a survey.  In its conclusion it tries to draw some lessons from that period that may be relevant to the current debate on teaching computer science.

Two quotes stand out for me, one from a respondent who had learned to program from typing in magazine listings "It wasn’t so much that I learned how to make something up from scratch but that it impressed on me the shape of programs: that you needed to construct little subroutines for all the alternatives and knit everything together and that the only way to do this was to have a clear sense of the structure, the overall shape if you like.”  And another describing what should be taught in schools: "I believe we should teach computer history as well as teaching kids the basics of computer programming (no specific language, but the logic involved)."

To celebrate the centenary of Alan Turing's birth, Google have posted an interactive Turing Machine doodle.

Users are challenged to modify a simple program made up of some basic instructions (including setting, comparing and branching/looping) to make a series of binary numbers that encode the word Google.  The programs are then run, and the puzzle solved through trial and error.

Building railroads on the computer can be fun!

NI LabVIEW is a mature graphical programming (a.k.a visual programming) environment used for measuring and control in scientific experiments.

It has particularly good support for writing mutli-threaded or multi-process code and makes it much more obvious what's 'going on' (or going to go on) than comparable code written in a traditional text-based programming language.

Due to its accessibility, NI LabView technology was also selected by Lego to be used as the basis of its Mindstorms robotics programming software.

Presumably because of its heritage, I think that the LabVIEW language shows data flow more clearly than execution flow, although both are visible.

In 2006, Saeed Dehnadi and Richard Bornat published research into teaching programming that showed that programming aptitude did not follow a linear distribution, but instead that students fell into two groups: those that grokked it, and those that didn't.

Initially they thought they had found a way of predicting which group an individual student would fall into, but more recent research found that this predictor was not quite as accurate as they'd originally imagined.

Their most recent paper describes that the most significant skill predicting success in learning programming is actually the ability 'to spontaneously build and consistently apply a mental model of program execution'.  Their assertion is that this skill is an inbuilt trait, and that teaching programming will be unlikely to be successful for those that lack it.

The Lego Duplo Intelli-Train is another real world toy that has elements of behaviour that are far closer to real programming.  Here, instruction blocks are placed in the track that cause the train to execute different behaviours.  Crucially, sometimes these also depend on what cargo it's carrying, or which driver is in the cab.

In the above video, the brick instructs the engine to pause until the train has been refuelled (a bit like waiting for input) -- but there are other examples, such as unloading and reloading cargo blocks.  While the sets are no longer manufactured, you can see a lot of the behaviours in MrJabolgo's YouTube playlist.

MindStorms lead me to discover the Lifelong Kindergarten group at MIT.  The description of this project in particular, tangible programming with Lego bricks, very much sums up the philosophy of what I want to achieve with MindTrains.

The head of the local Montessori school kindly gave me this book when she found out about my interest in teaching programming.  Having played with Logo when I was at school (although oddly I mostly remember seeing it on TV) I was fascinated to read about its creation and philosophy.

In the foreward, "The Gears of my Childhood"*, Seymour Papert describes how having a solid physical understanding of cogs and gears (gained from playing with a toy) turned into a powerful mental tool for dealing with related, but way more abstract, mathematical problems.

In a similar way, I believe that a carefully designed train set could give people a powerful way to think about programming.

Searching for something similar, I turned up the Turing Train Terminal: a Turing machine simulator made using a model train.

It's an art project built by Severin Hofmann and David Moises, based on the ideas of Adam Chalcraft and Michael Greene.

In this interpretation, the track is Turing's strip of tape, with the locomotive 'reading and writing' states as it moves over and sets the position of the points.