703 karma · joined October 26, 2008
I guess "just Google for Mu" won't work any more. Beginner coders are just gonna love "Firmware as a service". ;-)
That's why you're seeing the behaviour you report.
However, you could also use your system Python and do: pip install --user mu-editor
"Python is a language that helps make code readable, Mu is an editor to help make code writable."
love it
I was one of the volunteers who contributed to the BBC micro:bit project under the auspices of the Python Software Foundation. I actually wrote the browser based editor and, like a conscientious developer, tested it on teachers. The feedback was pretty resounding: while the browser is convenient the limitations of not being able to connect to the MicroPython REPL, having to download a hex file, copy it to the device and wait in order to run your code was also a stumbling block.
It was a rainy Sunday afternoon and I asked myself, "how hard can it be to write a simple editor that was a native application so I could connect to the REPL and automate the flashing of the device?"
Fast forward a bit and Mu appeared, teachers used it with the micro:bit and started asking for it to be a "generic" editor for Python (not just micro:bit). The Raspberry Pi foundation's education team also wanted a generic Python editor based on the feedback they'd received from teachers and learners and so they supported me to make the editor modal (i.e. there's now Python3, PyGame, Adafruit and micro:bit modes) with a visual debugger for Python 3 mode.
So, be careful what you hack on a Sunday afternoon... I certainly wasn't expecting this to happen. ;-)
In a similar way to another respondent, I use vim because my first computer at university had it (well, Vi) and it's always there.
Mu is a code editor, Jupyter is more an unfolding of thought and code (i.e. they're different).
My aim is to complement and amplify the amazing work that Jupyter are doing and suggest people look into using Jupyter "proper", in the "Moving on from Mu" tutorial page (https://codewith.mu/en/tutorials/1.0/moving-on).
This is but a start and I expect Mu will evolve as computing education matures (hopefully) beyond the current state of affairs.
Regarding state/flow... that's partially handled by the visual debugger in Python3 mode (I explain this in a beginner friendly way here: https://codewith.mu/en/tutorials/1.0/debugger).
There could be lots of ways to do state/flow, but implementing a very simple debugger has the additional advantage of progression: it's a powerful tool coders will come to use with professional development environments as they grow in skill. I made the debugger very much with the Alan Kay quote referenced here (https://codewith.mu/en/about) in mind.
FWIW, I'm actually a classically trained musician (I trained at the Royal College of Music in London and played professionally for a number of years), and spent most of my 20s involved in music education. Music education has so much to teach computing education (although I concede I'm probably biased in this opinion) and I wanted to ape the "do the real thing, but at the right level" approach music educators (like my wife) do. She's a cellist and often runs workshops with kids as young as 5 who want to learn to play a string instrument. The first thing she does? She gives them a real string instrument (although it may be a 1/4 sized violin or cello - it's still a proper instrument) and lets them play (in both fun and musical sense of the word).
It turns out that if you want to be a musician, you have to learn to do things musicians do. Likewise, if you want to write software, it's probably a good idea to learn what software developers do.
Having said that, I like the innovation and shift of perspective from people like Bret Victor, so as always, it's a balancing act. We want people to learn about the rules, traditions and history of [music|coding] so they can become effective participants in the current world of [music|code] but then we also want them to innovate, experiment and push boundaries. This sense of breaking rules should definitely be part of education.
I hope this makes sense... :-)
In many schools the projector used in the front of the class is old and/or inadequate. Depending on the conditions, some work better with "light" applications, others better with "dark" ones, and some are so bad the only solution is a "high contrast" look (which also aids those with visual impairments -- education and the tools thereof should try to be accessible to all).
Like zooming in/out, this was a bit of a favorite complaint of teachers which was very easy to fix in order to help them overcome the widespread hardware inadequacies. I guess the moral of the story is: "assume nothing".
Hope this makes sense. ;-)
* Licensing - if you use one of the installers (for OSX or Windows) you're presented with the GPL3 as part of the installation process.
* Mac OSX package (and to the same extent, the Windows installer) - Mu comes with everything bundled in so you don't have to mess around installing a bunch of stuff to make it work. We did it this way after asking for feedback from school network administrators who always said some variation of "make my life as simple as possible". Mu is only just less than 4k lines of Python so, you're right in thinking that the rest of the installer is Qt and a bunch of other stuff (like Tk/tkinter, needed for Python's turtle module to work, something many teachers have told us they need). We also bundle PyGame, iPython, Matplotlib, Numpy etc etc... so they're just there by default if you simply install Mu. In this sense, Mu is a sort of "instant Python for education" (just add learners). ;-)
* Bundling - I'm happy for Mu to be bundled if this were useful to another project although I guess this depends upon what use case you're thinking of. For example, Mu is already "bundled" (in a sense) in Raspbian as a recommended package. If in doubt, just reach out.
The rational for deciding features is three-fold:
* A positive answer to, "is it going to make it easy for a beginner to write, execute and change code?" is the first requirement (we check this with user research -- I've observed lessons, code clubs and other beginner-related activities as well as interviewed teachers and learners to find out how they react).
* Alternatively, we checked the features the Raspberry Pi Foundation had feedback about. For instance, the zoom in/out buttons were one of the most requested features from teachers in feedback to the RPi education team. When I demoed this to teachers for the first time there were gasps of amazement (which made me smile, given what a simple / easy to implement feature this is). This is extraordinarily useful in a classroom situation and for learners who may have a visual impairment (such as older learners with bad eyesight... a group I had never initially thought would want to learn... but hey... I rather like the idea of Granny coding Python). ;-)
* Can we demonstrate an obvious progression from Mu's (simple) implementation to a similar feature in an editor to which the user is likely to graduate? For example, the visual debugger is very simple, but looks similar enough to a "proper" debugger in a professional IDE that a beginner graduating to such an environment won't feel out of their depth.
Once a feature is "in" a lot of time and effort is spent making it as simple yet useful as possible. This is likely to be the first time someone will have used such a feature and we need to ensure that the intention is clear, the use is obvious and the outcome useful from the perspective of the learner/teacher.
We also have a "rule of three" when it comes to "nice to have" features... if three people independently ask for something we try to implement it (a good example being toggling on/off of commenting).
The point of Mu is to be the first editor you use... it introduces you to the various concepts and capabilities of IDEs in a simple, approachable and coherent way so you quickly graduate to something like VSCode.
As I say in my PyCon talk (linked to in another answer), if you're still using Mu as your main editor after becoming proficient in coding, you're doing it wrong (and should graduate).
Hope this makes sense.
Mu is largely based upon the feedback given to the Raspberry Pi Foundation from teachers and students who have used IDLE.
My talk at this year's PyCon mentions some of this in passing: https://www.youtube.com/watch?v=T5IAf5vGGSk
I spent a LOT of time working with beginner programmers and saw many examples of learners finding their way into documentation and sources of information that were unhelpful, intimidating or not intended for them. Chaos, confusion and disappointment would ensue and this would take a significant amount of time and effort to undo. https://codewith.mu/ and https://madewith.mu/ are both websites for the target users of beginner programmers or those teaching coding (Python).
Mu's developer docs are in the "usual place" for Python projects (mu.rtfd.io) and I hope they make sense to any experienced developer.
All feedback most welcome.
Happy to answer any questions you may have. :-)
Perhaps PySide's return will encourage some competition in the Qt space for Python. For example, I wish it was simple to create a cross-platform installer for stand-alone Python apps that use Qt. Current solutions suffer from the 80/20 rule where the 20 usually contains something essential.
I estimate around 80 people volunteered time to bring Python and associated tools (such as the browser based editor, command line tools and a native editor called "Mu" https://mu.readthedocs.io/en/latest/) to micro:bit.
At the heart of all this work was the creator of MicroPython, Damien George who volunteered a huge number of hours to bringing a full reimplementation of Python3 (without standard library) to micro:bit. Check it out, it's awesome. MicroPython is both a reimplementation of Python 3 but on the micro:bit also has music, a simple speech synthesiser, funky display functions, radio and a simple file system all built in. :-)
Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS?
Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.
In the UK the government said, "make it so" and failed to provide training or resources for the many computing teachers who don't know how to program (which is most of them since the vast majority of UK based computing teachers come from non-computing subjects like business studies).The difference in quality of teaching, expectation of attainment and learning resources is staggering.
I wish NZ well, but I hope they realize that the teachers are fundamental in making this a success. A lack of investment in teacher training or classroom resources will make this dead in the water.
(Caveat - I was involved in the MicroPython side of things. So good to see the other dev environments represented in the comments here.)
Hurrah! :-)