[Microbit-Python] micro:bit Mu/MicroPython questions

[Matthew Jadud]

Dear all,

@ntoll suggested I post my thoughts to this list. They're on the long side.

For background, I'm taught introductory through advanced computer science
and electronics/embedded systems courses at the college level since roughly
1999. For years, I contributed significantly to a small, portable runtime
for the concurrent/parallel language occam, which gave us the ability to
run 100+ concurrent processes on devices as small as the ATmega328. It
never quite took over the world, but I did learn the joys of building a
portable bytecode interpreter for multiple architectures, and associated
toolchain support.

There is much I do not know, and little that I know about Micro:Python and
it's ecosystem. What I have discovered from teaching with it this term is
that there are things I need/want in order to execute good pedagogy. I'm
happy to contribute my time to working on Mu and associated tools to make
these tools better for me (and others).

At a high level, in terms of design and development, the "philosophy" (in
the README) doesn't get us down to enough detail to really have a
discussion. It is not possible to evaluate whether someone "understands" an
IDE. "Easy to use" is highly subjective, and also not easily evaluated.
Without personas that clearly indicate who the user is, and testing with
users representative of that user (or, feedback from educators working with
those users), these are spaces where we might easily devolve into
disagreement that is subjective and personal (and grounded in the
experience of experts) rather than grounded in a target user's experience.
For context, I lived/worked with members of the BlueJ team for 5 years; I
have more than passing experience/exposure to the life of a pedagogic IDE
in and out of the classroom.

I'm going to offer comments about what I know/think I need/want. I'll
number these for easier reference.

---

1. The ability to turn on/off style checking/linting.

There's an overwhelming number of distracting errors for a novice. My
students are beginning to ignore the arrows, and they've barely begun
programming. This is a problem, because some of those errors matter. BlueJ
(used to?) show one error at a time; DrRacket has language levels. Mu
throws an industrial-grade linter at the students on day one. It needs to
either be tunable, or able to be turned off. Right now, it's causing
students to rapidly begin ignoring errors...

2. Projects vs. Files

I need the ability for students to save a project of files vs a single
file. Think Arduino. Why?

3. I need the ability to distribute starter projects.

I would like to ship a piece of starter code for a project, with a library
of support code in a separate file. Asking students to reset their
micro:bit, upload using the "filesystem browser," (which is buggy), make
sure they get the right files... and then begin writing their code is too
complex for students on day one.

4. Starter projects should be accessible through a project manager.

This might be akin to the library installation interface of the Arduino
environment, or how PXT does it. I'm OK if students have to paste a Github
URL into a dialog. In a perfect world, they can enter one URL at the start
of the term, and the repository is a "meta library," where all future
extensions/projects go. This way, I can say "install starter project one,"
or "install starter project three," and they never have to leave the course
project library. Allowing multiple libraries/project repositories (think
apt) would be fine with me.

I'm aware libraries and starter projects are different.

5. Starter projects and libraries should both be installable.

When ladyada produces a new library for the New Awesome Board of Greatness,
or even for an Existing Board of Greatness, or someone writes a library for
the micro:bit that I want my students to use, they should be able to
install it, and access it. Perhaps even with

from new_library import *

by making sure the

a) include path is correctly set, and
b) the library is automatically transferred to their micro:bit.

6. The icons need to be smaller for some screens.

They're huge, take up too much real estate (eg. when the REPL is open), and
I worry that they're not accessible to screen readers. Hopefully they're
standard widgets. This might just be a personal thing, but I have some
students with lower-res devices, and code + REPL eat a lot of vertical
space.

7. microfs does not work well when an error is showing.

I've been experimenting with microfs; it seems to hang when a syntax error
is crawling its way across the micro:bit. This is painful. Perhaps this
means microfs is better replaced with pyOCD, or similar, or perhaps the
runtime for micro:python needs to be changed.

I might be doing something wrong here. This is from my (quick) experience
of throwing together a tool or two of my own that wrap microfs/uflash, so I
could be Doing Something Wrong.

8. I wouldn't mind a simulation API.

But, that's in the "I want a pony" category. I'm thinking PXT and it's
simulator... but, the API piece is so that the Circuit Express can be added
along side the micro:bit, along side The Next New Awesome Python Board,
along side...

9. Project sharing/submission.

Think Scratch/etc. However, this comes later. An infrastructure for
projects, however, and integration with git, get the mechanisms in place
for this kind of code-based-sharing-community-building.

10. Extensions API.

Well, if we're strapping fake horns onto the pony, we might as well solve
half (or more) of these problems by exposing the core editor and its
functionality through an extensions API, so you can say "Do what you want:
here's the API. Have a blast." This created a vibrant ecosystem for BlueJ,
enabled a good bit of research on learners using it as well.

---

Those are a few thoughts from a few weeks of teaching with these tools. In
part, I want some of the library functionality because I don't like the
MicroPython API. I won't expand on the pedagogic reasons extensively (this
is long already), but I really want a transition from PXT to Python (or,
just be able to control the introduction of concepts), and to do so, I want
a functional interface that hides the objects. I can do that if I can wrap
the existing API.

Shiffman's "Learning Processing" does an excellent job of providing a
pedagogically ordered introduction to Java(esque) in his text, by
introducing one new concept at a time. That's impossible with the micro:bit
as MicroPython is currently organized.

from microbit import *

while True:
  sleep (1000)
  display.scroll("Hi")
  sleep (1000)
  display.show(Image.HAPPY)

introduces concepts of:

* library import
* looping
* booleans
* function calls
* objects
* object methods
* object static members

The benefit of Arduino's setup()/loop() is that they're both functions,
they have clear meaning, and the student never has to modify them for many
of their introductory experiences. Granted, there's syntactic wrapping that
happens around them, but it makes sense, and provides a clear foundation
for every program a student writes. I'd like to be able to hide some of
these things, so when I introduce objects, it's intentional, and does not
involve telling students lies, or glossing over details. The above code
could become

while True:
  show_string ("Hi")
  sleep (1000)
  show_image(HAPPY)
  sleep (1000)

although, that's debateable: HAPPY becomes a "magic variable". That might
be OK. It might not. But, if I'm able to have them import a
library/tool/mode that automatically imports my library of

from makecode import *

in the background, then I can deal with that in my own way (and other
educators can choose to deal with it in theirs).

---

This got long.

@ntoll suggested I post my thoughts to this list. I would be happy to
contribute to the community. That is, if there's space to develop a roadmap
for Mu, in conjunction with others, that starts moving towards a teaching
environment that supports pedagogically motivated modes of interactions
with code and hardware. I have taught with hardware for the past 5 years,
and really enjoy it. I like teaching with Python, and think the
micro:bit/Circuit Express/etc. are great platforms for students to learn
with.

Yours,
Matt

-- 
Matt Jadud
Pronouns: he/him/his
Associate Professor of Digital and Computational Studies (Chair)
Bates College
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20171017/5c4beb53/attachment.html>