[Microbit-Python] The BBC reveal the device to the media

Damien George damien.p.george at gmail.com
Wed Jul 8 10:17:16 CEST 2015


David, I'd just like to clarify a few points regarding MicroPython and
its use on the micro:bit:

1. MicroPython does not aim at all to replace TouchDevelop and all the
goodness that the existing TouchDevelop environment brings.  Instead
MicroPython provides a different (and more traditional) way of
programming the device and therefore gives more options to those who
have one, and more options to teachers to decide what's the
best/easiest way for them to teach their students.

2. If Python is to run on the device then MicroPython is the easiest
way to make this happen.  The report by Nicholas points out that it's
going to be very hard to put a Python-like front end on the
TouchDevelop system.

3. A lot of the niceties that you bring up about the TouchDevelop
environment could also be implemented on top of the MicroPython
paradigm (eg online sharing of code, libraries).  Now that we know
that the core technology works (ie MicroPython runs), if we get the
approval from the BBC that this is the way to go then we can get to
work making the MicroPython+micro:bit ecosystem as easy and enjoyable
as possible to use.

4. The limitation of script size is not about flash but rather RAM.
The script must be compiled on the device so needs a certain amount of
RAM to hold the bytecode.  Hence the limitation.  An alternative would
be to compile to bytecode off the device (eg in the cloud) and run the
bytecode from flash.  Then you would be allowed to write very large
scripts.  But this means you are relying on internet connectivity and
an online service.  As per point 1 above, MicroPython tries to bring
something different to the table in terms of no reliance on the web
(among other things), and I think it's good to keep this property.
Also note that with BLE enabled the traditional solutions
(TouchDevelop, mbed) don't get much RAM/flash to play with and the
programs you can write are going to be limited.

Cheers,
Damien.


On Wed, Jul 8, 2015 at 8:05 AM, David Whale <david at thinkingbinaries.com> wrote:
> Hi Nicholas,
>
> I'm not ignoring you lot, just been *very* busy these last few days, from
> all angles, and will be still for a week or so, sorry!
>
> I'm thinking through the proposals to think what I could add to the already
> excellent comments and observations made by others.
>
> I think, still, I'm really drawn to the power of having a blocks like
> interface with a "show code" button that shows the python, to provide a
> smooth and natural transition for coders from a visual paradigm to a text
> paradigm - think of it as the python equivalent of the web "view source"
> where people look behind the scenes on a web page, work out how it works,
> start hacking their own html, get into a bit of javascript, get into a bit
> of php, and many get into computing that way.
>
> There is a subtle but important difference between a "show-code" option
> (Michael's origional blockly) and a "convert forwards only" option (blocks
> to touch develop one way conversion) - both with their own benefits and
> pitfalls and differences.
>
>
> I also need to personally think through whether two pages of code on a
> 128/256K device ("twice the size of game of life") without the bluetooth
> connectivity, gives enough opportunity for doing useful and engaging things
> with that amount of code. I'm not sure about that one yet, to be honest. It
> seems we've burnt a large amount of code space to get a tiny amount of user
> app space. One way to frame this might be to roughly calculate what
> percentage of flash is the interpreter and runtime, and what percentage is
> user code - how does this compare to the existing blocks or touch develop
> solutions (hard to compare as code density might differ significantly). But
> if it's 95%/5%, interpreter/user app, I'm really not sure about that. Be
> nice to have a ball park figure on the split at present. Is that all
> interpreter, or is it libraries too - I''m guessing it's not possible to
> strip unused libraries due to the dynamic nature of python?
>
>
> Could we show the python experience to a bunch of 11 year olds and a bunch
> of school teachers, perhaps, and see what they think of it - that is the
> target audience, after all?
>
>
> There's also *something* there that Michael mentioned about the contained
> experience of working inside the ecosystem of a website with all the
> interactions and sharing that happens, compared to an offline editor with an
> independent community on a separate page - I've not quite thought through
> both sides of that yet properly. There definitely is something about the
> immersive experience of the community and tutorials and examples and editor
> all being in one place, that I hadn't really seen before this BBC project -
> there's a "thing" there I'm trying to form some view on, but it does feel
> very exciting when you use it.
>
> The TouchDevelop shared online library feature is a stroke of genius that I
> hadn't realised until I experienced it first hand this week - perhaps an
> option to "import" and it does a live search for community contributed
> libraries and just includes them for use like the TouchDevelop experience
> does? Just a thought. The immutable published library concept gives
> educators in particular a way to focus learners on the important learning at
> the top of the app, whilst giving them drill-down to the detail if they want
> it - I've learnt more about TouchDevelop by clicking through the library
> detail than I have by reading any documentation, to be honest.
>
> There is also that thing about teachers have spent a couple of years
> up-skilling in Python, and something new and different is coming along. It
> would be good to provide a range of directions both in and out of the
> experience for learners and teachers, so they both be attracted to it, and
> drawn onwards to the next thing, in new and interesting ways. Python could
> be as much a "draw in" to the experience, as well as a "draw out and
> onwards" to bigger systems like Raspberry Pi, for example.
>
> Still thinking, but these are my initial thoughts for now. Sorry to be less
> than helpful at this stage.
>
> David,
>
>
> ___________________________________________________________
> David Whale, B.Sc (Hons), MIET
> Software Engineer and IET Schools Liaison Officer, Essex
>
> email:  dwhale at theiet.org
> twitter: @whaleygeek
> blog:  blog.whaleygeek.co.uk
>
> Co-author of the new book "Adventures in Minecraft" - lets get kids coding!
>
>
> On 7 July 2015 at 14:46, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>>
>> On 07/07/15 14:20, David Whale wrote:
>> > Tony hall mentioned python several times and so did dara o brien at the
>> > public launch today.
>> >
>>
>> Great stuff! I hope it went well.
>>
>> David, would be interesting to get your perspective on the Python work
>> we're doing.
>>
>> *Everyone* - David is the point man for the Institution of Engineering
>> and Technology (who are also a BBC partner). David also writes awesome
>> books on Minecraft and Python programming.
>>
>> :-)
>>
>> N.
>>
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>


More information about the Microbit mailing list