Are there any talks in particular that you recommend? I love to watch live coding to see how other programmers have their development environments set up.
As it was mentioned in another comment, its hard to find a link to the source code of this, or even to get the information, whether this is open source, and what licence.
(Answer: https://github.com/mu-editor/mu/, licence is GPLv3). For some people, this is some of the most important question before they would try out a new app.
Also, one detail which was hard to find, but interesting for me: This is build using PyQt5.
About the MacOSX package: It's about 430 MB. This is a lot for such a simple editor. Is this just because of PyQt5 which is bundled together with it? Isn't it possible to strip that down? I would have expected something like 5 MB or so.
Also, another question: Is it possible to have this bundled into another existing app? E.g. I have an app where the user could write simple Python scripts to automate something (e.g. the smart playlist logic in a music player), and I was wondering whether I can have a simple editor just inside the app. However, your licence is problematic for this usage, as my apps usually have a BSD or MIT licence or similar. Maybe consider to use LGPL?
* 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.
As an educator, I appreciate the decision to bundle libraries such as PyGame, Matplotlib, etc with the editor. Although it's important for new coders to learn how to install libraries, it doesn't need to be one of the first things they learn. It's really nice to be able to install an editor, show students a few lines of code, and have it do something more than just print some text to a terminal. (Although, for the record, printing text to a terminal is still immensely satisfying to many new programmers. It makes them feel like they're really programming.)
I've been teaching programming off and on for many years, and I'm teaching another intro course this fall. I can't wait to give Mu a try with students.
Thanks for all your hard work, and the clarity of thinking that's gone into this project.
It's great to see a development tool with this take in the Python ecosystem! I always thought that things like turtle are underappreciated for educational purposes, and having them out of the box in the standard library is a point in favor of Python as a great teaching language. But you took this to 11. :)
And it should be mentioned that @lordmauve was a collaborator in Mu's development, without whom it wouldn't exist. (Cheers Dan... hope you're enjoying the t-shirt...) ;-)
This looks great! I was looking for something similar to Dr Racket but for python. I am going to use this in a beginner's course in programming for high school students.
I guess you have already seen this article: http://worrydream.com/LearnableProgramming/ , any plans on getting some features there implemented? Especially seeing state/flow over time would be immensely helpful for beginners. The state inspector panel is good enough for now though!
Another simpler thing that would be nice is to have some explanations when you hover on keywords/functions
I know Bret Victor's work very well - it's thoughtful, thought provoking and the sort of stuff that makes me go on long walks to think further (a good thing).
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 love how clean the interface is. What makes it right for beginners? Are there some special features that you’ve taken out or put them in that would help a beginner?
I took the RPi education team's feedback as a starting point and spent lots of time watching, testing and working with teachers and beginners to work out what works best given a context with beginners and/or teachers trying to deliver classes.
This is but a start and I expect Mu will evolve as computing education matures (hopefully) beyond the current state of affairs.
Thanks for sharing your approach (saw your background on music) which is fascinating and absolutely agree that there could be things we could pluck from music education into computer education. I’m also based in the UK and am exploring how to advance data science education - your ideas have gotten me thinking.
What's been your rationale when deciding what are the most essential features?
Do you envision Mu as being someone's learning-to-code editor, then "graduating" to one of the big players or you think one can "grow into a programmer" and keep "living" in Mu?
* 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).
Hey .. I just came across Mu in the context of the BBC Microbit. From a few days of hacking with it, I must say I am very impressed. The ability to flash code to the microbit, the automatic install of libraries .. I remember thinking "I'm going to get an error message now". When things just worked, I went wow!
the one thing that helps beginners immensely that i have only seen in pycharm is a workspace - i.e. all the live objects currently in scope. is such a thing possible with mu?
I really like that in the tutorials, there is a “Moving on from Mu” page. It shows that there is a clear understanding of the goals and scope that Mu should strive for.
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.
My 9 and 11 years olds write Python in VIM, and have been for about two years. Learning VIM itself can be fun, if you teach it properly. And it is a skill for life.
I'm 38 and use vim since Amiga days and vi before that and would never even consider giving vim to anyone starting out!
How do you teach kids that? I know kids learn fast, but still. Aren't they in a phase where they ought to catch on 'normal' things first in apps, isn't wrestling with vim averting they concentration from what they should be paying attention to (python)?
Hi. When I was about 9, I asked my dad to teach me to program, and he started with vim. Yes, it was a bitch to pick up, but I don't think it really detracted from learning and it's still what I use today so it can't have been that traumatizing.
> isn't wrestling with vim averting they concentration
> from what they should be paying attention to (python)?
Quite the opposite. Instead of teaching them "use this arrow key" I'm teaching them "use this mode". And since they are paying mostly attention to the Python, the VIM skill that they are picking up along the way is hardly even noticed.
We started with a goal, in our case it was to recreate the car from the `gti` command (git wrapper). I created a file with maybe a dozen lines of 72 spaces, and let them get to work. They started with basic hjkl navigation and the i command, then they learned to replace with r and jump to specific location with /. After that I was simply answering their questions, as they already understood that everything has a shortcut.
It is entirely not clear to me which Python binary this editor uses by default. It is most definitely not the one that the `python3` command on my system is set to. Hence, it finds none of my packages.
The editor seems to use some Python 3.6.5 (where ever that comes from), while on my system 3.7.0 is installed.
As mentioned elsewhere, the feedback we got from educators was that they just wanted everything packaged in with Mu, including a working version of Python.
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
I now did install it with Pip, and while the REPL now sees my correct Python version (3.7.0), it still does not know any imported packages that are installed in this system Python. Unfortunately, there also does not seem to be any setting in the editor where I can change which Python it uses, nor can I see which one has been chosen for me.
VSCode is for professional developers... while this may look beautifully simply (because it is) to experienced developers like you and me, it still isn't particularly "friendly" for beginners.
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).
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. ;-)
Actually, Jupyter is used in Mu: the Python3 REPL is an iPython notebook. ;-)
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).
my first editor was visual basic 6, (aim/aol/progz) days. I've seen it posted on twitter and really like the interface, I think it will be very useful, I guess we had to learn the "hard" way.
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".
As someone who doesn't write python regularly, wasn't python supposed to be human readable for non coders? Or not need an IDE to be understood? Clearly very different messages being transmitted here.
I don't see how the two things contradict. You still need a "run" button for even the most readable code. And syntax formatting, auto-complete etc is always going to be useful no matter what.
At the risk of stating the obvious, this is for making code human writable, not human readable.
[1]: https://youtu.be/FsvmT2Ir7B8?t=26m
[2]: https://github.com/dabeaz/thredo