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.
Bret Victor's essay is a very lucid and thoughtful trip through the challenges of designing systems to teach programming -- absolutely well worth a read for anyone interested in teaching coding and an absolute must (along with MindStorms!) for anyone designing a learnable programming environment.
















