This post is further detail that I today discussed in Discord today, where we were discussion about Python’s general popularity and usefulness in the general use despite the memes that it is a “bad programming language”, because of its simplicity, incredible amounts of libraries and ease of use for beginners that might not understand what exactly it is that they are doing, which is not fault against anyone, but ignorance.

Oh MicroPython… you are so… complicated.

I actually loved MicroPython because of how easy and straightforward it is to initially program, but when you try to do complex calculations, it will proceed to lie down flat with the following:

• How much numpy and scilab (and in turn, but not crucial in embedded, matplotlib) is baked into the Python ecosystem solutions that cannot easily be refactored using Python list types. God forbid you program control systems.
• ulab exists to mitigate this, but you have entirely build your own MicroPython flash version to bake this into your firmware, with the unwritten risk that it does not have every numpy and scilab function because of the compelling reason that Python really isn’t tiny flash drive friendly - 10% of your 2MB is available, which means that you can only write 200kB of Python code, which will compatibility libs it can leave one easily with only being able to use 20kB of space to write this in without having to redneck debug where to put gc.mem_free() and hoping it doesn’t brick itself.
• Thonny… Gosh, Estonian pride and joy that isn’t Skype. You are the only user that used REPL correctly (the JetBrains plugin is still broken after multiple months now), and you have all the necessary tools and are doing what you can. But damn, are you frustrating - not being a tiling manager nor Wayland friendly. I want to love you in the same way as I would MicroPython, but you don’t have to make this so challenging. Random REPL connection losses, having to look up where the TTY is in /dev/* this time, plotter memory leaking into 20GB if you, god forbid, collect sensor data without delays, clipboard often broken in both Windows and Linux (X and Wayland), no easy way to look up /lib/ code when it crashes. Just death by a thousand cuts.
• A splintered ecosystem with guides and troubleshooting because of CircuitPython and MicroPython coexisting, the only saving grace being CircuitPython compatibility layer Blinka for MicroPython - but no other way around. Which takes even more precious space away. Forcing one to pick MicroPython to get help through Pimoroni, or CircuitPython from the Adafruit community

But it is with positives, which has a significant advantage over most embedded programming languages, such as:

• Incredibly newbie-friendly for first-time dabbling in embedded programming and needing not to use extra probing tools.
• There is extensive and easy-to-follow documentation for embedded solutions in MicroPython Arduino’s C/C++ language, yet it needs to come close to it.
• There is so much library support, and it doesn’t force people to get stuck learning very long chapters in electronics to get past it and make their own thing. (Although you sometimes should learn and comprehend the concepts along the way)

The points are short, sweet and straightforward - which means, in summary, MicroPython is good. Python is heavy on memory space, but it is a fantastic feat that it was made for a microcontroller, but it sacrificed ACID principles and memory space in the process. It is not amazing - just good and exceptional.

Once you proceed to do control engineering and heavy vector and matrix calculations, or something that needs consistent logging - it will slowly become your greatest possible enemy.