Jan 292018
 

I recently dived into the rabbit hole of educational computers and came across a site which made a big song and dance about how Python is a great deal more complicated than BASIC. Well that is perhaps arguably correct, but the comparison they made was grossly unfair :-

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

from random import randint
from time import sleep
import sys

string = "Hello World!"
while true:
  attr = str(randint(30,48))
  out = "\x1b[%sm%s\x1b[0m" % (attr, string)
  sys.stdout.write(out)
  sys.stdout.flush()

  sleep(1)

Now for the criticisms :-

  1. The first line (“#!/usr/bin/env …”) is nothing to do with Python; and in fact a BASIC program should also include this if it wants to run in the same way as a Python program under Linux. The “#!” is in fact a directive to the Linux kernel to tell it what script to pass the rest of the file through.
  2. The second line (“# -*-…”) also has nothing to do with Python; it is a directive to an editor to tell it to use the UTF-8 character set. Why doesn’t the basic equivalent also include this?
  3. Now onto the Python itself … first of all there are a whole bunch of imports which are done in the verbose way just so that you can call sleep rather than time.sleep; I generally prefer the later (which would result in the import time rather than from time import sleep). But yes, in Python you have to import lots of stuff to get anything done, and it would be helpful for quick and dirty scripts if you could just import lots to get a fair amount of ordinary stuff loaded.
  4. The rest of the code is … um … obviously designed to make Python look bad and glossing over the fact that Python runs in the Linux runtime environment whereas the BASIC equivalent does not – it has a BASIC runtime environment.

That last point is worth going into more detail on – the BASIC code was written for a BASIC runtime environment, and one method of sending output to the screen. Linux has many ways of writing to the screen, and the chosen method above is perhaps historically the worst (it only works for devices that understand the escape sequences; there is a curses library for doing this properly).

So is Python unsuited to a quick and easy learning environment? A quick hackers language? As it is, perhaps not, but that is not quite what Python is designed to be. And with a suitable set of modules, Python could be suitable :-

import lots

white True:
  screen.ink(random.choice(inkcolours))
  screen.paper(random.choice(papercolours))
  screen.print("Hello World!")

  time.sleep(1)

(That’s entirely hypothetical of course as there is no “screen” module)

I’m not qualified to judge whether BASIC or Python are better languages for beginners – I’ve been programming for around 35 years, and the BASIC I remember was very primitive. But at least when you compare the two languages, make the comparison a fair one.

Jul 082010
 

I have just spent the weekend doing all sorts of stuff that you won’t be interested in because it’s really boring (moving the main desktop machine, etc.) with News 24 on in the background. About every 4 hours I’ve been treated to Chip or Chop or whatever it is, proclaiming that home computing in the good old days was far better than it is today.

What a load of rancid rhinoceros dung! There is of course an element of truth to it, but in reality home computing back in the 1980s was a continual struggle with limited resources – we often had less than 32Kbytes of memory to play with. Yes that is 32Kbytes not 32Mbytes! The first computer that I was employed to work with had 4,000 times as much memory as the first computer I used; and 2,000 times as much as the one I spent a lot of time writing software for. Of course the machine I am writing this with has no less than 4,000,000 times as much memory as my first machine!

When we look back in time to early home computing, we tend to use nostalgia tinted glasses. In addition to the limits on memory, early home computers had a number of other drawbacks :-

  • Graphics were ridiculously bad. If you were lucky you had two colours at 640×256 resolution. If you were unlucky, graphics were made up of special “blobby” text characters that could produce “graphics” of a resolution of something like 80×50!
  • The screen was typically a discarded old colour TV … big and fuzzy. Even if you were lucky enough to have a colour monitor, it would usually refresh at a rate guaranteed to produce eyeball frenzy.
  • Sound quality was a little below par. You could get computer music – see the Commodore’s SID files – but the likelihood of  anything approaching the quality of 128Kbps MP3s just wasn’t going to happen.
  • Storage was extremely small in capacity and very slow. If you were lucky you had access to floppy disk drives with around 80Kbytes to 320Kbytes (there were floppy drives with 1Mbytes of storage available but they were not common), and these were slow.

Not that there is anything wrong with nostalgia of course – I run a few software machine emulators to play around with the computers of my childhood. And in one particular sense those old 1980s home computers did have one advantage over modern computers that modern machines do not have.

They were very easy to get trivial results out of.

Fire up a Commodore PET, and less than a second after switching on, it would type “READY?” at you. And it does mean that … it is ready for you to type the commands needed to load a program from tape or disk, or for you to start writing a program. No loading of an operating system; no complex IDE to learn. Just you, the computer and the keyboard.

Despite the primitiveness of the interface, the immediacy of the results is very attractive to new hackers of child age. For instance, a simple program can produce interesting results for a child :-

10 for i = 1 to 1000
20 for j = 1 to 20
30 print tab(j); "Name"
40 next j
50 for j = 20 to 1 step -1
60 print tab(j); "Name"
70 next j
80 next i

Such a simple program produces a snake of your name down the screen; with a few modifications a child can produce more interesting graphics. And many home computers of the time came with far more extensive manuals that would teach BASIC programming.

Whilst BASIC is perhaps an unfortunate language for language purists and probably does teach a few bad habits, it does have one big advantage over more “proper” languages. It is easy to produce simple programs to produce simple results. Of course there is nothing preventing us from creating a better BASIC than the original with enhanced features, but the key is not programming purity, but ease of use and the ability to produce interesting results easily even if that means losing flexibility.