From mjadud at bates.edu Tue Oct 17 08:30:54 2017 From: mjadud at bates.edu (Matthew Jadud) Date: Tue, 17 Oct 2017 08:30:54 -0400 Subject: [Microbit-Python] micro:bit Mu/MicroPython questions Message-ID: 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: