David's talks always have these funky looking editors.
But here's one of the famous ones on GIL.
Beware though, his talks are known to be devastating to the programmer, resulting in serious head injuries, trauma, headaches and other fun stuff.
Happy to answer any questions you may have. :-)
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.
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.
Seems like not that big of a deal considering it’s geared towards beginner programmers?
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
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... :-)
This is but a start and I expect Mu will evolve as computing education matures (hopefully) beyond the current state of affairs.
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?
(edit: the 2nd question is answered here: https://codewith.mu/en/tutorials/1.0/moving-on)
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).
Which links to here:
Which links to github (Watch button):
I guess they didn't want "users" to accidentally think they need GitHub or read the "developer docs".
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.
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)?
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.
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.
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.
The editor seems to use some Python 3.6.5 (where ever that comes from), while on my system 3.7.0 is installed.
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
So Mu is actually not a "simple editor", but a full Python distribution :-)
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.
why did you choose to focus on creating an entirely new editor vs creating a very opinionated plugin for vscode ?
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. ;-)
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).
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
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. ;-)
How do they both compare?
At the risk of stating the obvious, this is for making code human writable, not human readable.
"Python is a language that helps make code readable, Mu is an editor to help make code writable."