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

[Nicholas H.Tollervey]

+1

N.

(at work so brevity required)

On 23/09/15 10:44, Damien George wrote:
> 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
>>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150923/eeb2ce9e/attachment.sig>