Love hate Python

There was Visual Basic 6 (VB6)... and then there was Python.  Both are interpreted languages (i.e. they run from a high-level script rather than being compiled into machine code). Both claim to be easy to program with and both have a huge following. Python is current whereas VB6 is no longer supported.  Python is free whereas Microsoft have made VB6 neither free nor available but say that it is superseded by VB.NET.  But these are very different languages. Having sharpened my teeth on plain BASIC (e.g. BASIC PLUS in college days, QuickBASIC running under MSDOS) I progressed to VB6 which I used extensively for creating test software to exercise electronics I have designed in the course of my work.

In case I ever have the privilege of helping homeschoolers here with teaching computer science, I figured I ought to learn a current language. I did a bit in C# a few years back for a work project and, whilst C# is a very powerful language (meaning you can do certain complex things with minimal coding), I found its syntactical gamut too much for my poor brain. So, what more suitable to up-and-coming programmers than Python, or so I have been told?

Many years ago I authored some QuickBASIC code that would display prime numbers in a square spiral.  The essential part took a mere 20 lines of script, and here's the output, limited to the VGA 640x480 screen resolution of the day with each integer represented by a single pixel. You can click on each image to zoom in.

The point of the program, apart from being an exercise in graphical output and being cool, is to highlight the mainly diagonal line patterns that prime numbers arranged in this way make. Anyway, this became my first Python challenge.

Here's the output of my Python code - a bit prettier because now each integer is represented by a 4 x 4 pixel square. Value 1 is plotted as a blue square, otherwise primes are red and non-primes grey. The essential part was almost 100 lines of code and took a long time to code. OK, so I am a novice but even so...  I tested it with three different algorithms for finding the primes - the fastest involved saving the primes in a Python list.

And here's the same in VB6.  It was so much easier to do the graphics part in VB6.  Python graphics is anything but intuitive and seems to employ the longest path to achieve the least credible results, whereas in VB6 you simply drag and drop graphic widgets and then click on them to open their respective code space. That they are event driven is taken for granted unlike Python.

Oh, and although no-one on ever claimed VB6 was fast, without pausing to do animated screen redraws I found my VB6 code ran about twice as fast as with Python.  I tried different prime algorithms but found the VB6 code ran fastest by dividing each integer numerator by all the denominators from 2 up to the square root of the numerator, which for large integers involves many more test divisions than did my Python code. That VB6 was still significantly faster says something in its favour.

And then, although Python is an interpreted language like VB6 or QuickBASIC, it has no native integrated development environment (IDE) so testing and debugging entails constant swapping between your chosen text editor (I used Notepad++) and the command line.  Although there are 3rd party IDE's and I am currently investigating Microsoft "Visual Studio Code" which, surprisingly, is free.

So do I love Python? Well, not yet, certainly! 

If you don't see sharp you'll be flat

Visual C# is a strongly typed, object orientated and managed programming language. As opposed to the computer's native computer assembler which is not typed, orientated or managed at all.

If I've lost you already, it's likely to only get worse so, if I were you, I'd go find something else to do.

The point I am making is that IMHO the education of all serious programmers ought to start with assembler before moving on to a high level languages like C#. Because otherwise they will inevitably fall into the traps of unnecessary obfuscation, abstraction, bloating, redundancy, and other such anti-Occam's Razor-isms that force the rest of us to buy ever increasingly complex computers.  The young people of today won't believe you when you recall surprisingly complex software that used to run within the MSDOS memory limit of 640Kbyte. Not that complexity is bad per se - nature is full of it!

"Managed" means the language depends on, in this case, the gargantuan Microsoft .NET framework and cannot run without it. Which means the programmer does not have full control of the machine and the very simplest program still needs all that framework code.

The objects in "Object orientated" are packages of code that are called by the main program rather like subroutines of assembler-speak but with many more bells and whistles which are nice but only when needed. C# forces the programmer to use objects even when something less heavy would be more efficient all in the interests of readability and self documentation.

"Strongly typed" means that every quantity is forced to be of a specified type. Like when Mickey Mouse is doing his homework and asks "what is 3 + 4?" and Pluto replies "Is it apples or bananas?"

The computer itself only knows about "bits" aka binary digits that are either "on" or "off".  Groups of these can represent either instructions or data according to context. The computer doesn't care if the data describes apples or bananas. That's the programmer's job. Just as it is the mathematicians job to decide how to use an algebraic symbol or the what to use the digits 0 to 9 for. So when C# insists that a symbol must describe e.g. apples, that distinction is purely in the mind of the compiler (the software that converts a high level language like C# into assembler).

Which is all fine and dandy until it gets out of hand.  Like when the QuickBooks SDK interface which I have been working with requires me to use their programmer's name for a value that, to the computer, is just an integer and woe betide if I spell or capitalise it wrongly.

This morning I read a news article reporting how, when a certain Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. This is a prize example of the point I am making. There is no reason why a programming language should not define a special value to mean that a variable or database field has not yet been assigned, but to confuse a string of characters "Null" with that value is unforgivable.

I came across a new word recently that describes this nonsense nicely: cruft = badly designed, unnecessarily complicated, or unwanted code or software.

The end of an era?

Long, long ago, when dinosaurs roamed the land, before even the internet and google, in fact in 1993, I commissioned a genius called MDG (who wrote software for me at the time) with the job of buying my business a new computer. The result was my much cherished DIAMOND brand 486-DX2-66MHz. CPU's did not need fans in those days. This machine was top of the range with VESA accelerated disk and graphics cards, and it has served me faithfully until - argghhh - this morning it went belly-up. Thankfully the hard drive is still intact and I have been able to plant it in a DRDOS friendly pentium machine that happened to be handy.

I tried Googling components of this machine in the hope of help, and was met with emotionally loaded words like "antique" and "museum". The idea that anyone might still use such a behemoth is apparently beyond their ken. Our local Apple expert, Joe, sniggers when he comes in the office and I happen to be DOSsing.

Tsien BoardMaker 2 and BoardCapture is why I use this DOS machine. This software is for creating electronic schematics and designing printed circuit boards (PCB). Regrettably Tsien no longer support BM2, wanting instead to rent you their more expensive Windows BM3.  But there are still many engineers who still use BM2 because it is so fast (screen redraw on a 486-DX2-66MHz is faster than screen redraw in many Windows graphics programs running on current machines). And because its user-interface is so intuitive. And because, even though it must operate within the DOS 640kbyte memory limit, I have yet to design a board that exceeds its memory limited capacity. And because it does all I want and I know I would have to invest a huge amount of time to learn a new CAD program.

Which only goes to show how HORRIBLY inefficient modern software is. If only programmers now-a-days wrote to the same standards as that in BM2, think how powerful their software would be.

Occam's razor

Eric Isaacson programmer par excellence

Occam's razor in the vernacular might be "Keep It Simple Stupid!".  William of Ockham was a 14th century logician and Franciscan friar. He wrote in latin but, roughly translated, Wikipedia has it as a principle of parsimony, economy, or succinctness used in logic and problem-solving.

I try to apply the principle in my work as an electronics design engineer. I often use Microchip PIC processors in my designs, mostly 8-bitters, and typically code in assembler. Recently I have tried my hand at 'C' (just the ANSI flavour) - apparently it is the "way to go" and, anyway, one's hand is forced by the need to use C-friendly libraries.  But I hate the verbosity and obfuscation of 'C'. What requires little thought and a few simple statements in assembler can consume hours of research and require far more typing in 'C'. In short it contravenes Occam's razor.

OK - I like the way 'C' encourages good structure and offers ready made functions to save one having to re-invent the wheel. But couldn't these good things have been provided in a simpler, more intuitive way? So I figured I would create a new language and call it 'Occam' - but I am too late - Occam already exists but is not at all the 8-bit job I was looking for.

'C' poses itself between low level (i.e. assembler) and high level languages. It's not that I have anything against high level languages - they have their place - just that I hate unnecessary verbosity, and not only in the field of programming.

Long ago in the heyday of MSDOS I purchased and used A86, an assembler for the PC. The author Eric rightly claims that A86 "is the finest assembler available, at any cost under any terms, for the Intel 86-family of microprocessors". No painful setup red-tape is required - you write your assembly statements, assemble and, hey presto you have an executable.  That's as good an example of Occam's razor as you'll get.


Shalom is often translated as 'peace' but means much more - well-being, completeness, wholeness, health, soundness, tranquility, prosperity, fullness, rest, harmony, the absence of agitation or discord. How is 'shalom' encoded in brain neuron-patterns?  Similarly, a high level programming language command like "draw a 3D cube with rendering" – who cares how it is encoded? Except that you do care at the hardware level I work at. I care about every bit and every micro-second and, for some applications, only assembler will fit the bill.