The Mu Editor
Background
If you follow me on Twitter you'll not be surprised to hear that I'm involved in the development of an editor called Mu. As a matter of fact I've been loosely involved with it more or less from its inception as an offline editor for the Python micro:bit effort.
When I first helped out with a bit of bug-fixing and the like, I was doing so out of a sense of community helpfulness and because of my friendship with Mu's originator and principal developer, Nicholas Tollervey. I didn't have a huge investment in the project myself and I wasn't honestly sure how far it would go.
While I still "Watched" the project (in the Github sense) I had nothing to do with it really until about a year after that first commit when someone raised a bug about a disappearing selection marker when using the keyboard. Now it happens that I know the person who raised the bug for reasons completely unrelated to Python, Mu or anything else. And the simple fact of that coincidence (plus my interest in what looked like an obscure issue) led me to dive in and fix that particular problem.
And I've watched the project get picked up and used by teachers and others who appreciate what it does. As ever with these sort of things, it also helps if you get mentioned by people like the Raspberry Pi Foundation, the micro:bit Foundation, AdaFruit etc.
Last night was the 2nd "Mu Moot" (the 1st was a meetup of developers in the, appropriately punny Mu-seum Tavern). There were overlapping sets of Developers, Users and Educators together at Kano. And that get-together led me to talk a little about Mu and why you would use it.
Why would you choose Mu?
I must be honest: this was my first question as well. There is absolutely no shortage of editors out there of all shapes and sizes. Even though Mu aims squarely at the education market, there are other offerings out there which do the same.
One answer to get out there right away is: you might not. There's no hard-sell: if Mu works for you in your situation, use it; if it doesn't, use something else. In fact, one of the Tutorials is precisely about Moving on from Mu. It's never been an aim of Mu to be an all-embracing editor. In fact, it's been a specific aim not to be an all-embracing editor. It's right there in the first paragraph of the README.
But now, having encountered in person and online, people who have said that Mu helps them, I think I would put forward the following points which seem to be headline reasons:
It's uncluttered
It makes working with the micro:bit easier
It makes working with PyGame/Zero easier
It makes working with Python easier
You can see a pattern emerging there, can't you? Although I wasn't involved, I'm aware that Nicholas has taken a fair amount to time to speak to teachers and other interested people to see what they need from an editor. And the point is that, as developers, we might be surprised at what a teacher considers important. (A "teacher" here will generally refer to a Secondary School teacher in a classroom situation, but could also include out-of-school clubs, Code Clubs or anyone trying to work with beginner coders, young or old).
Mu for teachers
The point is that most teachers don't want to have to deal with the mechanics of installing Python, installing various support libraries, working out where on a filesystem an editor is storing its files, how to run those files and so on. They want to get their pupils writing code which they can run as easily as possible.
Of course, in the abstract sense, we all recognise that there's a learning experience to be had there. Learning how to install Python and what the pitfalls are. Or even learning to build it from source with its dependencies. Learning about pip and about virtual environments. Learning about filesystems and running from the command line.
The trouble is that most teachers are dealing with a class of 30 students who may or may not be even marginally invested in the subject. A dedicated after-school club or lunchtime session could be run for those who are keen to learn. In a lesson situation, the teacher will want to get up and running just as soon as possible.
Batteries Included
I'm not sure who coined the expression but Python has long been described as coming with "Batteries Included". The so-called Standard Library has code to do a lot of different things. Over the years, especially as the package ecosystem around Python has grown a lot, there's been a bit of a shift of emphasis towards preferring 3rd-party packages which can iterate faster and keep up especially with security rather more easily than built-in packages. But Python still comes with an impressive spread of functionality.
If you download one of the Mu installers you also get an array of useful libraries, in addition of course to a full version of Python 3 with all its standard library. Of particular interest are: support for the micro:bit and Adafruit products, plus Pygame Zero. The point isn't that you couldn't get these things otherwise. But that, again, you're saving the teacher the headache of installing those things with their dependencies. (And of possibly having to negotiate the school systems admin).
Not just us?
I've already noted that Mu is trying to meet the needs of an audience of educators, not just (or not even) an audience of developers. And that, insofar as it has managed to do that, it's by dint of actually going out and asking and observing working educators or those (such as the Raspberry Pi and micro:bit foundations) who support them.
But another "not just us" constituency are those for whom English isn't a native language. I can't find the initial Tweet but a few months ago, Nicholas started to call out to people to submit translations of the editor text (the buttons, the help and so on). Glancing down the locale directory in the source, I can see that we currently support: German, Spanish, French, Japanese, Polish, Portuguese, Chinese, Vietnamese and Swedish. And English. There are instructions for how to go about translating and most of those translations have come from -- or been improved by -- people outside the core team. If you feel you could offer a translation, please check the open issues list to see if anyone's already offering, and then try to follow the instructions and ask for help if you need it.
But there's even more beyond the language translations. We're conscious that educators are often dealing with a range of difficulties from visual impairment to dyslexia and other learning difficulties. There are several issues which discuss things like problems with screen-readers or specific fonts & colours for dyslexic coders. To get a real-world trial, Nicholas worked with Ben Mustill-Rose who is severely visually impaired and who attempted to use a screen reader to work with Mu.
In short, as a project, we're keen to support as many people as much as we can while trying to keep to the spirit of a stripped-back editor which gets on with the job and then stays out of the way.
Bells and Whistles? The Rule of Three
Mu has always had this aim of being a simple editor. Uncluttered, just enough buttons to do what's needed in a classroom situation, no multi-level menus, support commonly-needed libraries. But people always want something else, something which isn't supported. The fallback answer is always: if you're looking for an editor to do X plus Y then Mu probably isn't the editor for you.
Ultimately it'll be down to the developers, and to Nicholas in particular to make a call on whether to go ahead with an addition or not. But for a long time, he's had a practical metric: the Rule of Three. If three people independently request a feature or a change, we can consider it a serious prospect.
Of course things are added for other reasons sometimes. Or not added even if three people want them. But having a rule of thumb helps to set the expectations of people wanting to add bells and whistles.
The Future?
At yesterday evening's Mu Moot, Nicholas outlined a sort of short-, medium- and long-term vision for Mu. One concern of his is to raise the "bus factor" of the project, which currently sits just above one. It's not that someone else couldn't take on the technical aspects of Mu; I think anyone of us who have contributed to the codebase could probably do that, albeit with a little support in niche areas. Rather, the whole dynamic of the project is currently driven by Nicholas and if he fell away, the project probably would too.
But we also need to get more people using Mu in order to get the feedback of whether it's genuinely useful for a wide range of people -- primarily educators, but in fact anyone who finds a use for a simple editor with some useful side-functionality, such as talking directly to micro:bits or running Pygame Zero code directly or showing plotted data directly in the editor.
If you want to see what people are doing with Mu, have a look at https://madewith.mu. If you want other people to see what you're doing with Mu (even if it's just "using it in a classroom to get stuff done") then submit your project and/or just ping the team and let us know about it.
The good thing is that people are contributing not just questions & suggestions but also code changes and language translations. Companies like Adafruit and Kano can see the benefit of hooking up the kit they sell with an existing editor which can be easily extended to use it. And there's talk of a web mode using, perhaps Bottle to produce simple web-based projects for A-level students.
And what else?
Well the best comment made last night was from Jon, a teacher at a school in Croydon, who says that his pupils want the Mu logo to be a cow rather than a snake, because you're "Coding with Moo". (Or a kitten, apparently, because then you're "Coding with Mew").