[Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API )

Damien George damien.p.george at gmail.com
Wed Sep 23 11:44:26 CEST 2015


Thanks Michael, that's a great read and good to have a "mission
statement" to make decisions by.

We do need to remember that Touch Develop and Code Kingdoms provide an
alternative to (Micro)Python (and MP provides an alternative to them)
and having alternatives already increases the adoption and use of the
device.  Some students might find the blockly interface more
inspiring, while others like Python.  So it's important that we
provide something *different* (and I think Python is providing a
little more computer-science rigour than the other offerings).

We must also remember that we're bound by the Python language itself
-- and the Python way of doing things -- so that places some
restrictions on API design.

I think though that we can slightly modify our API design to fit
better with Michael's statement.  I propose:

1. We replace microbit.pins.p[0-20] with top level names microbit.pin0
.. microbit.pin20.  This removes a "namespace" level but still keps
things clean (pin0.write_digital(1) is pretty obvious).

2. We revert to microbit.button_a and microbit.button_b.

3. On entering the REPL we execute from microbit import * to make all
names available.  Then it's very easy for a student to do
display.print('hello!'), and other things.  We should ensure that
there are no short names in the microbit namespace that could easily
clash with other names.

4. We should have from microbit import * written automatically at the
start of the script in the editor (currently we have import microbit).
That way students have immediate access to the functions/objects, but
they can change that line to import microbit if they want.

I think other decisions, like whether we use read_digital,
digital_read or set_digital_value, are neither here nor there and
don't affect the "first impressions" of the device (but still we'll
try to choose sensible and consistent names).  For the students that
are hard to reach and engage, as long as the teacher can get them a
REPL, they can type display.print('hahaha') and get something working,
I think that's the best we can offer.

Python's learning curve is shallow but long.  And we can make the same
thing on the microbit: the first thing kids do (display.print) should
be super easy to do.  And from there it should be a gradual learning
curve towards more fun and advanced things.  And the learning curve
should continue for a long time for those more advanced students.  I
think we can do that.






On Wed, Sep 23, 2015 at 10:02 AM, Michael <sparks.m at gmail.com> wrote:
> [ This email has become a bit longer than I intended but I think it's
> important to say, since this was a great question, and deserves a proper
> answer. It's passionately it seems, but certainly isn't critiquing anyone or
> any API! ]
>
>> What is the goal of micro:bit?
>>
>> Is it to teach 11 year-olds good programming skills?
>>
>> Or is it to inspire 11 year-olds with an interest in problem solving, STEM
>> etc.?
>
> While I don't think (and I doubt you do either) this is either/or, you're
> right, there is a trade off.
>
> The goal of micro:bit is very much the latter. To INSPIRE a generation.
> Quite literally.
>
> Why?
>
> Over the past 10 years the numbers of children taking computing in the UK
> dropped dramatically. At A-Level - where they should be able to come out of
> school with useful skills (I know I did) - esp if they get an A or a B - the
> numbers dropped below 4000 children nationally taking A-Level. Out of those,
> less than 200 were young ladies, and out of those less than 50 got grade A
> or B at A-Level. (ie more women at the Django Girls track at pycon UK gained
> useful skills than young ladies as recently as 2013 - which is when I last
> crunched the stats. (I've got graphs that show this if people are really
> interested)
>
> There are improvements across the board since 2013, and the curriculum is
> there to teach those good skills.
>
> The micro:bit is NOT there to replace the curriculum, or teachers. It is
> designed very heavily with the start of Key Stage 3 in mind - both in
> computing but in design technology, science and textiles as well. (Key Stage
> three is the first three years of seconday school for those like me who
> never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn stuff
> without the pressure of exams in secondary school, ages 11-14)
>
> It isn't designed to replace anything else on the market. It is designed
> however to help and ENTICE people get the first rung on the ladder whereby
> they they think the ladder might be worth climing.
>
> It's aim is to INSPIRE.
>
> Who is it intended to inspire?
>
> Geeks? No. They'll get interested anyway. None of us on this list is now or
> ever has been the target audience.
>
> Kids with inspired, inspiring, engaged teachers? No. They're awesome, this
> is intended to help them inspire their kids, but they're not the audience.
> They'd find *something* however, without this. (this also means any teacher
> who attended Pycon UK is also NOT the audience, since they're already
> engaged.)
>
> The audience is the child who has yet to be turned off computing (but will
> be or perhaps has been) because they've had 6/7 years of homework in primary
> school and for the past 4 of them they've probably been using computers to
> write up and draw up their homework, and to open their eyes to the idea that
> they can create something cool.
>
> The idea is to simply make it as simple, as possible, as accessible as
> possible for the child who who when exposed to this stuff becomes
> interested. (After all, by the time they reach A-Level, that's 36,000
> children who were turned off by the curriculum)
>
> It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years
> pre-GCSE in a school where a teacher teaches the bare minimum of the
> simplest curriculum, which they chose because they don't know very much at
> all.
>
> It's the child who's teacher thinks "I won't teach that that yet, because
> there'll be nothing for next year".
>
> It's the child who's teacher was until last year a Business Studies teacher
> and thinks that the move to teach coding is a stupid and annoying one, and
> that there's no point teaching year 7 or 8 anything now because by the time
> they reach year 9, the curriculum will change back again after a failed
> experiment.
>
> It's for the child who can't get access to a library because they live in
> the highlands of scotland, or orkneys, or Falklands.
>
> It's for the child who thinks "I can't spell, I can't do anything" - but
> they CAN do this, and suddenly they have a world of opportunity before them,
> and it turns out 4 years later they're undiagnosed dyslexic.
>
> It's for the child who's teacher only goes over any idea once, and generally
> only covers what's on the BBC Bytesize website, because they know the BBC
> puts a lot of effort into making that cover the curriculum (whether it
> achieves that is another matter), and they believe rightly or wrongly that's
> enough, and the child is ill that one day and it's never repeated.
>
> (I can think of specific representative teachers for each of these)
>
> In short, the target audience is for a child, just out of primary school,
> who's parents don't care, who's teaching support doesn't care, and doesn't
> think they can do things, and to inspire THEM that they can.
>
> It's for children who have never touched code, and are only doing so because
> their teacher is telling them to, and think they're the wrong sort of person
> (a common view amongst girls), and given half a chance they'd be doing
> something else.
>
> It's a device aimed at supporting EVERY child, including the "weakest"
> child, they child who believes they *can't* either because they really can't
> (there is a bell curve for everything), or simply because they've never been
> told they can (and needs to hear it). It's a device aimed not at you, or me,
> or our younger selves, but at everyone. It's aimed at the person you see in
> the shop who now is a checkout person, and was once 11. It's aimed the
> street cleaner you see, but when they were 11. It's aimed at the office
> worker who is bored with their work, and solves problems every day, but was
> once 11.
>
> This was the reason that the prototype had a flat API, since you only look
> in one place. It was based on watching real users and seeing the problems
> they have (the events prototype that came earlier). It's based on experience
> of working with children of all abilities - the ones with dyslexia,
> dyspraxia, ADD, or just plain average, or below average intelligence.
>
> Every other possible audience involved benefits from those decisions.
>
> Now, I'm not going to bikeshed the API - until I get to review what's been
> proposed - since that's really unfair and disrespectful to those who
> graciously gave up their time on monday, for which I'm very thankful.
>
> Given the choice, in this project I choose inspiration, not correctness,
> every time. You could say people often say "Make it work, make it work
> right, make it fast", but before that there has to be the decision "to
> make".
>
> On that basis, I didn't even require this line:
>
>     from microbit import *
>
> Or this:
>
>     import microbit
>
> The functions were just considerded builtins to the device. I can see why
> every other python programmer balks at this, but this is precisely the
> approach that pygame zero takes (I'd not seen that before pycon uk, so my
> impression could be wrong there).
>
> That said, to put this into perspective, if we inspire just 3% of children
> to change their minds and start climbing the ladder, then we haven't just
> done good, but we will actually have reversed 15-17 years of decline in this
> field, and that will hit in 2020. (rather than 2028 - which is when the
> first set of primary kids starting the new curriculum will leave school)
>
> Hmm. That was longer than I expected. Sorry about that.
>
>
> But I do know the answer to this question - the goal of the micro:bit is
> very simply INSPIRATION, and that should be the trade off here. (But yes,
> correctness matters)
>
> As I said though, this isn't posted to critique or support any particular
> API. It's just intended to explain the thinking behind the device, and the
> impact on my thinking when building the prototype and designing its API. I
> also think that the decision won't be mine and shouldn't be mine either, and
> I'll support whatever decision IS made, proudly and loudly.
>
> While getting resources and materials done ASAP does matter, sacrificing
> that for spending a day or two discussing whether an API is the right one -
> especially with regard to the tensions between ease of use and "correctness"
> is good.
>
> Pythonic-ness good. Micro-bitty-ness, better :-)
>
> Regards,
>
> Michael.
>
> (and once again, sorry about the length of this, but I feel pretty
> passionately about this :-)
>
>
> On 23 September 2015 at 00:25, Alan <alainjackson at hotmail.com> wrote:
>>
>> Sometimes when agreement doesn't come easily it can be because the goal
>> isn't clear to everyone.... which made think that perhaps the goal isn't
>> clear to me.
>>
>>
>>
>> If it's the first, then there's a strong case to make our designs
>> "proper", even at the expense of making things a bit more difficult for the
>> novice initially.
>>
>> If it's the second then the emphasis changes and it's more weighted
>> towards accessibility, I think.
>>
>> I realise I've been assuming the goal is the second and I'm happy to be
>> corrected if it's not.
>>
>>
>> In my mind the micro:bit is it's own fun little problem solving universe.
>> It doesn't have a web browser or built in games (yay!) - it's only going to
>> do what you make it do. It's amazing that you can program it in python. Even
>> if it happened to use some non-standard variant of python or its API wasn't
>> completely "proper" it wouldn't really bother me... iff we're aiming for the
>> second goal. If we're aiming for the first, it would bother me.
>>
>>
>> When I suggested a flat version of the API I wasn't just thinking about 11
>> year-olds and their typing or spelling ski11z, I was thinking about teachers
>> and myself. I'm wondering if, in the classroom (which is only one situation
>> of its use), it's going to feel more like "live coding". It really did for
>> me when we were all round the table at pycon and Nick was saying "You've got
>> 20 minutes to make something interesting", and I was coding on the REPL,
>> continuously recreating my program with the up arrow and finding out the
>> command history is only 10 lines.
>>
>> If these thoughts aren't useful or are bike-shedding, please ignore them.
>> I don't want to waste your valuable time and distract you from the cool
>> stuff you're doing.
>>
>> Cheers,
>>
>> Alan
>>
>> ________________________________
>> Date: Tue, 22 Sep 2015 23:13:17 +0100
>> From: david at thinkingbinaries.com
>> To: microbit at python.org
>> Subject: Re: [Microbit-Python] Flat API
>>
>> I'm sure both GCSE and AQA specifications talk about abstraction and
>> decomposition - how can you do that without functions??
>>
>> All our 11 year olds use functions in the schools I work with. We
>> introduce functions in Adventures in Minecraft (aimed at 11-15 year olds and
>> mostly syncronised to the GCSE curriculum) in chapter 3 and use them
>> extensively through to chapter 10 as a way to build up and test programs in
>> small incremental steps.
>>
>> I personally think OCR are wrong on this.
>>
>> D
>>
>> ___________________________________________________________
>> 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 22 September 2015 at 16:09, Michael <sparks.m at gmail.com> wrote:
>>
>> Cool. I was more worried I'd offended you. Glad I haven't :-)
>>
>> (it's very difficult to tell over email, so try to err on the side of
>> caution!)
>>
>> To explain where I'm coming from perhaps better,  I've been hanging out on
>> the computing at school forum now for 2-3 years (or more), and randomly
>> reply to python queries on there, and been rather surprised to see this
>> response sort of response from time to time - either to my replies or to
>> other people's:
>>
>>  ...  thanks for taking the time to write it. Although the fact that you
>> recommend using functions also reminded me that we are not in the right
>> territory: Functions are outside the scope of OCR GCSE programming, believe
>> it or not (they are present in the AQA specifications though, so maybe I
>> should switch…)
>>
>>
>> (this was in a response to a simple question about validating input data,
>> and simply suggested simple "isint" and "isfloat" functions to avoid
>> repeating the same logic over and over...)
>>
>> That's a little scary to me, and it's always at the back of my mind -
>> because it's a far more common perspective. That comment incidentally is
>> from a teacher who is teaching 14-16 year olds rather than 11-12 year olds.
>> (and yes, there were plenty of other replies from other teachers saying that
>> was the wrong approach)
>>
>> It's interesting actually, if this was an API for CodeClubs (even for the
>> same age range), I wouldn't even have worried at all.
>>
>> Anyway, I'll wait to see the bike now before I start suggesting training
>> wheels or a different colour shed :-)
>>
>> Regards,
>>
>>
>> Michael.
>>
>> On 22 September 2015 at 15:49, Larry Hastings <larry at hastings.org> wrote:
>>
>>
>>
>> On 09/22/2015 02:05 PM, Michael wrote:
>>
>> Hi,
>>
>>
>> Sorry if I've offended you (it looks like I might've done).
>>
>>
>>
>> Naah, no worries.  And I didn't realize you weren't there yesterday--I
>> didn't get everybody's names.
>>
>> This is private, but I can post this to the list if you like,
>>
>>
>> /arry
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________ 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
>>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>


More information about the Microbit mailing list