While learning a new language you will notice how the often enthusiastic literature available dispenses adjectives with quite some generosity. Apparently every new language out there claims to be more “expressive” than the previous. This is an easy claim when comparing to plain C, which nowadays ranks among the high level languages barely above the level of raw assembly and just a notch higher than hand coded binary.
Few have made a real effort to verify such claims and tried to establish a metric (link, link) but there is nothing like trying yourself, using possibly a test case that truly matters to you.
In my recent experimentations with Python (on a PIC), I witnessed with my eyes what Python expressiveness truly can be.
I have been playing with the MX7 Multimedia Board from Mikroelektronika and wanting to take advantage of the QVGA display and touch screen, I was looking into porting the well known GOL libraries (a GUI development library part of the larger free graphics package from Microchip, aka MLA Graphics).
After a quick attempt at binding the existing library to Python, I realised that it was an intrinsically lost cause. Graphical user interfaces scream for object oriented design and that is exactly what the MLA-GOL lib attempts to deliver albeit sticking to an artfull, yet plain, C coding technique reminiscent of Windows 3.1 (circa 1995) style. This has the enormous advantage of being portable across all microcontroller architectures (8/16 and 32-bit) using a multitude of C compilers (at least five at the last count) and covering a product portfolio of approximately 500 devices or so… short of a miracle!
But once I had made the leap to Python, and the larger processors (RAM rich) required to run it, all that value was lost, in fact it had become a dead weight. A complete re-write was in order, using Python from the ground up ( meaning from the MLA Graphcis primitives up).
EZ.py
Off I went to develop a small Python module that I decided to call EZ.py, inspired by somewhat similar efforts in the Python community better known as EZGUI and … friends.
Long story short, there are two numbers that summarise well the outcome of my effort:
- It took me only a couple of nights work to flesh out the basic functionality
- The total code size turned out to be ridiculously small
While I struggle to quantify the first, sorry I don’t keep a fine count of my free time allocation, especially the dark hours, but my son goes to bed at around 9pm and I never work past midnight …
I can measure the second one very well: that is 300 lines of code in Python.
By comparison the basic set of GOL widgets does cover some 8,700 lines of code (semicolons, excluding header files and widgets that don’t have a parallel in my code)
That would set the expressiveness meter at a 20:1 ratio or more but the case is admittedly an extreme one. Here some of the reasons that I could think of, that could help explain the extraordinary performance:
- Python does memory management and handles “lists” natively
- Python Object Oriented features allow for inheritance mechanisms that reduce enormously code repetition in a GUI widget design
- Python has dynamic typing which eliminates a lot of the “type casting” clutter present in GOL
Quiz: How many lines of code does it take to implement the below dialog box using GOL and respectively Python?
Answer: 1 line of code in Python (using the EZ module), lost the count in C using GOL (guessing a couple hundreds, probably you are going to need the GDD too in order to help you place elements around in a nice and proportional way)
