The micro:bit is supposed to be a breakthrough educational tool that will introduce physical computing to the masses, starting with 11- to 12-year olds. However, even physical computing needs code and this raises the question of which language to use. 

Having written the same program, the game Commando Jump originally created in Basic for the BBC Micro, using each of the major code editors provided on the BBC micro:bit website I should be able to answer this question. But there isn't a clear cut choice and its more a case of weighing up the pros and cons of all the options. 

The criterion by which you judge a language depends on what you are going to do with it. For the micro:bit the objective is to have something that can be programmed by complete beginners in small but creative projects and this is a very difficult standard to meet. 

There are currently four main choices on the Create Code section of the BBC micro:bit website:

1. Microsoft Block Editor
   A graphical drag-and-drop language that is based on the Touch Develop scripting language. The blocks can be converted to Touch Develop script. 
   
   
2. Microsoft Touch Develop
   A "menu" based approach to constructing programs in a scripting language.
   
   
3. Code Kingdoms CK Editor for JavaScript
   A graphical drag-and-drop editor for a subset of JavaScript. The blocks can be converted to JavaScript and vice versa, but only a subset of JavaScript can be used.
   
   
4. MicroPython
   A traditional code editor for a subset of Python.

Picking which of these to use is a tough task as there are positive and negative aspects of each. 

None of the four is a complete implementation of any of the languages that you will find in the bigger world. Both MicroPython and Code Kingdoms JavaScript are subsets of the standard language, but the Touch Develop script is close enough to most modern languages for it not to be too much or an issue. 

All of the micro:bit languages suffer from a number of shared problems. The process of running a program is a little awkward. You have to compile or download the code that you have constructed and then copy it to the micro:bit to run it. This is slow and far from interactive. It makes debugging for example more difficult than it should be.

Three of the languages have simulators provided, which avoids the problem, but what you can do with a simulator is limited. The fourth MicroPython does have a simulator, but isn't on the website.

The problem is that the write code, compile, download, run cycle is a little long if you don't use a simulator and if you always use a simulator why did anyone go to the trouble to build the real thing. 

No Debug?!

None of the four editors provides anything like adequate debugging facilities. Even though they have simulators, not one of the languages provides a break point facility or a variable inspector. You can't single-step through a program and all you can do is use print statements to send debug messages somewhere. In the case of MicroPython there is a serial console and a REPL that can help with debugging. In the case of the other three you have to figure out debugging methods for yourself.

There is a serial library for Touch Develop that can be used to display debug information on a console, but you have to hunt for it and its use isn't mentioned anywhere else I can find. It isn't enabled by default.

In short debugging facilities are limited and what does exist is well hidden. 

If this was a trial, the judge would have to stop the proceeding at this point and instruct the jury to return a guilty verdict. 

A teaching language that lacks good debugging facilities not only makes it harder to find bugs, it also makes it harder to demonstrate to the student what is actually happening. Of course, if you keep programs very simple then neither of these is a barrier to teaching programming, but it is a barrier that will be reached if that teaching is successful.

When we move beyond debugging, each of the alternatives has its individual problems.

Let's take a look at each one in turn.

Microsoft Block Editor

The Block Editor looks a lot like Scratch, but it isn't as full function by any means. This isn't a problem for the complete beginner, but it does limit how far the student can go before having to change to something else. 

It is worth pointing out that there is nothing wrong with a block-based language for learning to program. The student meets all of the fundamental ideas that make a programmer - loops, conditionals, variables and, most important, how to implement an algorithm. In other words, from a teaching point of view a blocks language, is not a second class language and it can make algorithms seem real. 

However the quality of this particular block language isn't that good. It is fine for the complete beginner and very short programs. The editor itself can be frustrating at first and it does take time to get used to. 

The limitations of the Block Editor are quite severe. The biggest problem is that there are no functions or subroutines. This means that programs have to be written as a single chunk and there is no opportunity for modular programming.

This isn't a problem right at the start, but it means any user is going to have to move to something else as soon as they get even slightly ambitious.  There are functions in Touch Develop and this is one way in which it is more powerful than the Block Editor and this makes it a suitable follow-on approach. However, both have only a limited for loop that runs from 0 to n-1.

The Block editor only provides an if statement with no else clause. You can program with just these two simple constructs, but they can make otherwise simple programs more complicated for no good reason. 

Overall the Block Editor is a reasonable way to get people started on programing but it runs out of usefulness quite quickly if the student takes to programming.