#learnable programming

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.

It's a long long article, but I really recommend you read it. Then think about how Eclipse of Visual Studio should really be like, in a year labeled 2012.

In an introductory course to programming in the Technion Computer Science faculty, the staff went out and built a web-based environment in which you write code, as it auto-compiles and runs, running basic tests against the code. This has been lauded as a success and an excellent way to teach students how to address developing code (TDD, playing with what you have etc).

The next big step, is seeing the memory blocks and data structures. And the step after that is linearizing time as just another dimention, just like the linked article suggests.

You really should read the article.

How do we get people to understand programming?

We change programming. We turn it into something that's understandable by people

[...]

Thought experiment. Imagine if you bought a new microwave, took it out of the box, and found a panel of unlabeled buttons.

Imagine if the microwave encouraged you to randomly hit buttons until you figured out what they did.

Now, imagine if your cookbook advised you that randomly hitting unlabeled buttons was how you learn cooking.

Learning cooking is not about guessing the functionality of your kitchen appliances. It's about understanding how ingredients can be combined.

Likewise, guessing the third argument of the "ellipse" function isn't "learning programming". It's simply abarrierto learning. In a modern environment, memorizing the minutia of an API should be as relevant as memorizing times tables.

The environment is responsible for making meaningtransparent. The environment must enable the reader toeffortlessly read the program, to decode the code, so she can concentrate on genuine programming concepts -- how the algorithmic "ingredients" combine.

[...]

Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?

[...]

In his influential essay No Silver Bullet, Fred Brooks makes the case that software is inherently "invisible and unvisualizable", and points out the universal failure of so-called "visual programming" environments. I don't fault Fred Brooks for his mistake -- the visual programming that he's thinking of indeed has little to offer. But that's because it visualizes the wrong thing.

Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.

Dump the parts bucket onto the floor.

(Like these LEGOs). 

In Part I we talked about some great points from Bret Victor's Learnable Programming.

Here's what he got wrong: towards the end of the piece he calls visual programming languages "worthless". However, one of his major design principles is creation by reacting- i.e. "dumping the parts bucket on the floor."  Yes!  Visual programming languages do a great job of this.

In most visual languages, the available programming "parts" are all there for the user to see.  In the Hopscotch IDE (which is similar to MIT's Scratch) there's a library section with usable methods organized by function. This serves a dual purpose: first, as Victor describes, it allows the user to gain inspiration from the tool set.  A kid seeing a pile of Legos might notice some wheels and decide to create a bike--seeing the tool inspires the creation. 

There's another important advantage to visual programming that Victor doesn't mention. When the tools are all ready to use there is no way for a user to break the program with a simple typo. No language designer should underestimate the immense barrier a new user experiences when coming up against unforgiving syntax rules.

Almost every kid who's come through our programming classes has had spelling mistakes, typos and syntax errors that stop their program from working. And this is not an uncommon barrier for new learners.  For someone new to coding, the idea that everything has to be typed perfectly for anything to work is a foreign concept- where else in life are you so constrained? This early frustration is often disheartening enough to permanently turn them off from programming.

If you're involved with teaching programming or building new languages/IDEs, by now you've probably read Bret Victor's excellent essay about the epistemology of programming. Wow. What a clear and thoughtful piece. Part of what's great about his approach is that he doesn't subscribe to the coder-as-ninja school of thinking where coding is just really hard and only really amazing and smart people are able to do it. He believes many programming languages and development environments are hard because of poor design decisions. He actively wants to make coding more accessible to everyone, and has outlined a set of concrete ways to make it more so.

Victor's (9000+ word!) essay follows on his totally awesome Inventing On Principle talk, which inspired a lot of people (including us, and the Dean of CS at the Kahn Academy) who think a lot about teaching and learning programming. He outlines many of the exact frustrations Jocelyn (and any non-coders) have struggled with upon first encountering computer programming, and then goes on to provide solutions to them with video demonstrations of an awesome IDE we wish existed in real life (Bret are you building this please?). 

Although we have a lot of thoughts in in response to his essay, we want to avoid a 9000+ word response post so we'll stick to some of his big points and best-of visuals: 

Granularity:  Victor uses a cooking analogy for the first part of his essay discussing programming environments.  

 "Imagine a cooking show, ruthlessly abbreviated.  First you're shown a counter full of ingredients. Then you see a delicious souffle. Then, the show's over. Would you understand how that souffle was made? Would you feel prepared to create one yourself? Of course not.  

Victor's primary assertion is that most programming languages and ways of teaching programming are not granular enough. They don't allow a learner to see the steps that, for instance, an if/then loop takes through various commands and at various stages in the loop. The loop just executes instantaneously. Without a step-by-step illustration of where the certain conditionals stop and start, a learner has to struggle through reconstructing the logic at each stage. If each step were slowed down and made transparent, a new programmer could quickly gain a deep understanding of how different control structures shaped code.

Clear vocabulary and syntax:  This is another area any new programmer struggles with--what do the methods and parameters even mean? We love this analogous image:  

Why do we consider the code acceptable and the UI not? Why do we expect programmers to "look up" functions in "documentation", while modern user interfaces are designed so that documentation is typically unnecessary?

Yes. With the "ellipse" method above, a new user has no idea what each of the four parameters represent. It's time consuming and annoying to figure it out via trial and error. Victor correctly calls "inline help" actually just proper labeling. It would be awesome to have a language/IDE that could at least give some hint as to what each of the parameters stand for. As a former MS Excel jockey, Jocelyn saw how this feature in Excel hugely aided the learning and retention curve. You could begin to type a function in a new cell, and an autocomplete with a reminder of the necessary and optional parameters (aka "inline help") would pop up.  

Abstraction:  One of the main reasons to bother coding anything at all is to add layers of abstraction to a static set of commands. Without the ability to vary parameters, Victor points out, why would you bother programming, say, an ellipse, when you could make one much more easily and quickly in a drawing program.

However, it takes time to understand how to make a specific description "generalizable." Just throwing a new programmer into the deep end of a for loop with a bunch of variables does not aid in comprehension. What is helpful is to allow the learner to add successive layers of abstraction.  The learner starts out with typing up a static and concrete set of instructions. Then she can slowly add in a variables and parameters to begin making it into dynamic code.

These are just a few of the points Victor covers in his essay. He's very comprehensive and even provides a checklist for his ideal system to learn programming. We love the IDE that his video clips demonstrate.  Now, the trick is getting someone to make it!   

As the readers of this blog know, we've spent the last five months building out our own language. The Hopscotch IDE is a visual programming language, so we can't discuss this essay without addressing a point that Victor makes at the end, about how traditional visual programming languages don't solve the Learnable Programming problem any better because they visualize the code and static structure, rather than the data and dynamic behavior of the code.