To me (and many others), Python is the greatest computer language ever (even though Perl’s Larry Wall wrote the coolest statement about programming ever). I started programming in GW-Basic when I was 12. I’ve written Pascal, Cobol, Assembler, C (MPI), Visual Basic (MTS and MSMQ, anyone?), ASP, PHP… Yes, even the occasional Perl (list is by no means exhaustive; at some point in the future expect a separate blog article on all the languages I’ve ever written stuff in). Never have I been able to learn a language faster, and have been able to get accomplished things in faster. While at Pathomation, for the longest time I was the curator and chief implementor (is that an official job title?) for PMA.python: a Pythonic SDK interface on top of their proprietary PMA.core tile server and API.
Python has several great libraries for visualization, like Matplotlib, Seaborn, and Bokeh.
However, you deal with Python long enough and you do run into use cases where it would be more convenient to just be able to do things at a bit of a more fundamental level.
Enter PIL, or, in its more recent version: PILlow: one simple application is that you use it to create image objects, from which you create canvases, on which you then draw.
There are tons of tutorials out there, there is documentation, and there is the Stack Overflow repository of excellent Q & A when you’re stuck with something.
But how about teaching one’s own a new skill? How do you really know?
MSX graphics
Remember the demo scene? It’s still alive, but has become a rather niche phenomenon.
As an aspiring programmer-teenager, I was in awe of these guys. I wanted to be able to do these things (I got into a assembler “putpixel” competition at the university; I got mine down to 12ms, but a friend beat me going as low as 9ms).
At some point, I picked up a second-hand book on how to do computer graphics in MSX BASIC. It contains 40 simple programs that do an excellent job at explaining the fundamentals of drawing, perspective, etc. I think at the time I translated it into Pascal.
I figured it was time for yet another translation exercise: from one of the oldest programming languages to one of the newest, as it may.
Downloads and DIY instructions
At this point, I’ve translated the first 15 programs of the book into Python, and I’m making them available as both downloadable Jupyter notebooks and (executed) PDFs. So just choose your poison. The PDFs are great to just skims through, get an appreciated for some archeological code digging. The notebooks are great if you want to start playing with these yourself (but you’ll need Jupyter to run them, of course).
- Part 1: (rather simple) graphics
- Part 2: Cartesian coordinates
- Part 3: Polar coordinates
The Jupyter .ipynb files can be downloaded as a single .zip file.
At some point in the future, when I’m done translated the complete list of all 40 recipes (can you really call 20 lines of BASIC-code a program? ), I’ll probably add these onto GitHub as a cloneable repository, as well.
Programming language characteristics
It was an interesting exercise to translate BASIC code to Python. And we’re talking about basic BASIC here, too; not the fancy QuickBasic that Microsoft came out with in the nineties.
Anybody remember the (in)famous 640k statement? It’s amazing what they could do with it. A couple of things about BASIC in particular struck me as “I didn’t remember that they were that far ahead of their time!”:
- The use of statements like DEF FNX(X)=… That’s a prototype for today inline function definitions, isn’t it?
- All trigonometric functions are available in the language right away. No need to import a separate math library first. Another way to look at this: math was once considered a basic features of any programming language. Now it’s an optional gimmick. Ok, I’ll put off the tinfoil hat again now.
- For-loops could iterate over float values! With Python, you need another import of numpy.arange() for that.
- Multiple statements on one line; while it makes sense to prevent this through language design to prevent cluttered code, things like variable initialization oftentimes really don’t require multiple lines. The tuple-workaround in Python then seems more like a hack than an elegant solution.
But of course we love Python. Jupyter is totally my preferred workspace environment these days; and I’m getting (re)certified on DataCamp‘s Data Science track, as well (more on that in a separate post).
The web is ripe with Python declamations, of course.
For that it’s worth, here are the things that I noticed during this exercise:
- Constants! The 4*ATN(1) hack is clever, but having math.pi is just so much easier.
- Swapping variables around in a single line of code by using tuple unpacking.
- Forced indentation. Those nested IF-statements (admittedly due to the version of BASIC used in the book) were painful to read.
- No need for screen-refreshes; text and graphics output (after all; the goal of my project was to explore PIL a bit more) all nicely go in the same environment.
Conclusion
A language is only a tool. It’s what you do with the language that matters. Digging through my old books uncovered some true gems of what computers were able to accomplish in the early days and how creative people were.
It turns out those hidden gems can still be revived today, because a pixel is still a pixel.
It’s my hope that this post inspires some people to get started with computer graphics themselves. Because even with generative AI, fundamentals are still worth learning.