People who know me would know that I volunteer at a coding club for young people. They program in Scratch and Python. School is back soon, so it should be a good time to consider what to do for the upcoming term. In particular, I want to think about why Python is not as popular as Scratch at school, and what we as developers volunteering at coding clubs can do about it.
One obvious reason Python is disadvantaged is game engines do not provide assets. And we have to be honest, as software development professionals, design skills are not our expertise. It is not just the visual aspect either. In fact, you can see all the aspects of designing a web application in the side bar of Material Design page, but in a nutshell it's visual, audio, interaction, usability and many more. We often leave such design work to specialist UI/UX designers, if we consider such work at all.
But what are other things that make Python less considered at school?
Python requires installation
One thing I found while working with the club is many children had problems installing Python at least once. This is not to blame Python, though. This is actually a drama caused by us, software development professionals. We each try to help people install Python in our own way, so in the end a new person in Python gets instructions from all over the Internet, each setting things up for their own use of Python. Some instructions even take the opportunity to advertise their products. As a result, the new person is confused by these totally different instructions.
Even in Windows itself, there are many ways to install Python. Previously the only way was to download from Python website and install. Now Microsoft Store has an installation option. Visual Studio Code, although doesn't install Python, does ask one to install its Python extension when opening a Python file. And guess what? The extension is also called "Python". We've had several cases where a young person came to us and said "I installed Python from VS Code. Why do I need to download Python again?" when they had installed the Python extension, not the interpreter. I admire their cyber security awareness, though.
 |
| The "Python" extension in Visual Studio Code |
Visual Studio Code also asked some children to install Jupyter Notebook and run code from there. The problem is, since our club makes games mostly, there will always be an infinite loop somewhere, like root.mainloop() in Tkinter and turtle.done() in Turtle. A cell with these lines in them never terminates, and execution of subsequent cells will be blocked. Game programming is not like exploratory data analysis, whose process can be made linear, so Jupyter Notebook is not suitable for this usage. In this case, it is the assumption of using Python for data analysis that caused the problem.
Scratch has none of these problems.
So what can we do about it? I think good places to look for inspirations are software workshops. At PyCon US 2023, many data-related workshops used interactive notebooks that the audience could run in Google Colab without installing anything other than a browser. As I mentioned, notebooks are not suitable for game development, but it is helpful for demonstrating concepts and algorithms used in games. Libraries like pygame support standalone use of its functions without a main loop. The pillow library or matplotlib.pyplot.imshow also allows drawing a single frame to show the result. We can go a long way with just these in terms of content, and those content should motivate children to go through the installation process.
MATLAB Expo used an online version of MATLAB for its workshops. The equivalent in Python is the Trinket project. It starts a VM for every Trinket sketch, so it can run Python as-is. It even supports pygame, for a fee, by sending code written in the browser to the VM and then streaming the screen pixels and sounds back to the browser. This overcomes the limitation of notebooks mentioned above. But be careful. Streaming pixels every frame can introduce delays, and if you're hosting your own virtual machines, it can also increast cost dramatically. Usually what happens in games is, data are streamed every frame, but the local installation draws the data onto the screen.
I've also been looking at PyScript, which is promising since it allows running Python straight in the browser without server communication. This reduces the cost of streaming and of course the latency. The big problems are three. First, PyScript is still very alpha. Its API can break at any time. Second, PyScript installs dependencies in the virtual environment in the browser every time the applet is loaded. This introduces a significant delay when the page is first loaded. Third, I'm not yet certain how PyScript interacts with device interfaces (joystick input, for example) and OS window manager. These can be limitations on what can be achieved in the browser.
Ultimately, the solution is to understand what is actually done when installing Python and Python libraries. With this knowledge, navigating different installation instructions becomes possible, and one will be able to see through the instructions and make adjustments according to what has already done. But, this requires almost the same effort of breeding a staff software engineer in an organisation, which many might not be able to afford. I sugggest we at least take one step in that direction though, because perceived difficulty scares.
Python is viewed as not beginner-friendly
I asked Google Bard why Python is not as popular as Scratch at school, and one of Google Bard's bullet points was:
Python is not as well-suited for teaching the basics of programming. Scratch is designed specifically for teaching the basics of programming, such as loops, conditionals, and variables. Python is a more general-purpose language that can be used for a wider variety of tasks. This can make it more difficult to teach the basics of programming with Python.
This reflects the popular belief that Python is more advanced, and that has put many people off. But, if Python is advanced, why would it put people off as opposed to attract them? Remember in a game when you learned of a powerful weapon and searched online how to obtain it? Why is this not happening to Python? The idea that it is advanced seems like a cover story. Behind the cover are the frustrations that new Python programmers (children) face. They are completely normal, but because they're not seen in Scratch, an illusion of Python being unfriendly is built up.
One example of this is errors. Python gives errors when things are not right, for example, when one tries to access a key in a dictionary that does not exist. Python errors are always shown with a stack trace. In IDLE (the default Python shell installed), the stack trace is shown in red. At other places it is shown in the same colour as the console settings. Now imagine you wrote a game that you're ready to try, and you ran it, and a window flashed by with a large dump of red text in the console that you did not understand. Just this bunch of text can scare many children away already.
Code
bear_dict = {"fur_colour": "green"}
print(bear_dict["green"])
gives an error because key "green" does not exist in bear_dict.
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
print(bear_dict["green"])
KeyError: 'green'
As software developers, we like errors. Or rather, we'd like the compiler/interpreter to warn us when things are potentially incorrect. The stack trace shows where the error occurred and what type of error it was. This is much better than giving no error and nothing else but a wrong result. Sometimes error messages can even point to a correction like this one.
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
sys.paths
AttributeError: module 'sys' has no attribute 'paths'. Did you mean: 'path'?
But obviously not all errors are this friendly.
 |
| Python 3.11.4 IDLE showing a syntax error "Unterminated string literal" |
We as develoers can read it because we know what a string literal is. In fact, this has been made much more friendly. In Python 3.6 IDLE this was simply shown as "Unexpected EOF", which is completely cryptic not only to a young person, but in fact any new Python programmer. They will need to know what an EOF("end-of-file") character is, how a file is read in C (remember CPython is implemented in C) and why an EOF character is not expected here, only to realise it is missing the other half of a quotation mark. The language we use in our software not just affects how users (in this case, young people) see it, but also reflects what we are. See this talk from Kate Gregory titled "Oh the Humanity" from CppOnSea 2019.
One challenge in teaching young people about errors is there aren't many real-world examples. We developers are so experienced at fixing problems that, as soon as we see an error like the above, we fix it immediately. We tend not to keep records of the errors we had, unless that error has caused an outage in the staging environment. With my previous client I often wrote a long email detailing what the error was, how it caused the outage, and what we can learn from the error about the language or the library. This would often be appreciated by the app manager and could sometimes even start an achedemic discussion. Other than that, there is no record.
But errors can happen anywhere. How comes Scratch doesn't give any error? There are many guards in Scratch that prevent errors from happening in the first place. For example, when accessing a property of a sprite, only properties in that sprite will be shown in the dropdown of the block, so it is not possible to select a property that does not exist. In the example below, the bear sprite has a property fur_colour but no others, so it is not possible to select "green" like we did above. At other times, Scratch simply swallows the error and does nothing. This is horrible to professional developers, but somehow makes Scratch look beginner-friendly.
 |
| Attempting to access a property that does not exist in the Bear sprite in Scratch |
There's not a place to showcase projects
Now we need to think about why that Python is advanced is not attracting young people like a powerful weapon in a game does. I think the reason is simple, you can't be what you can't see. This statement is heavily used today in diversity campaigns. In a sense, we are seeing a lack of diversity in project showcase space. Scratch projects can be shared anywhere on the Internet, and of course at school. Some schools even have a studio on Scratch. But a place to share Python projects that's runnable and running (i.e., not just source code)? Not that many.
The previously mentioned Jupyter Notebook hosting services and Trinket are places to consider, but they each has their challenges. Since this post is already longer than what I expect, I will defer this to another post. In the meantime, I think it would be much more appropriate if I do some experiments myself before posting about it.